Slashdot Mirror
Summary of JDK1.5 Language Changes
An anonymous reader writes "Over at java.sun.com, there's an informative article about the new features in JDK1.5. Some of the changes like generics are nice and should make some things easier. Some of the enhancements to me are purely sugar, like enumerators. When it comes down to it, once the code is compiled, it's the same. The thing I hope is, some of this new syntactic sugar doesn't result in more obfuscated code. Unlike some people, I feel using programming shorthand leads to increased maintenance. This is especially true when you have to debug a complex application."
check out eclipse -- a very sweet java IDE.
http://www.eclipse.org/
http://www.xemacs.org ;-)
what more do you need?
If you want a *real* IDE, I'd check out IntelliJ's Idea product. It's a few hundred $$$. Lots of folks like Netbeans and IBM's Eclipse as well (sorry, no url to eclipse, but I'm sure you can find it). The latter 2 are opensource.
May no camel spit in your yogurt soup.
Eclipse is "the awesome." It's feature-filled and relatively easy to use. Being free is a nice plus, too.
My roommate told me about it, and once I started using it I never looked back.
GeekNights!
Late Night Radio for Geeks!
Not knowing much about C#, is Java 1.5 "borrowing" features ?
I see two trends: being a better C++ (typesafe enums and parameterized types), and borrowing features from Lisp (code metadata, auto boxing/unboxing). I don't like to tie developments like this to particular people, but I wonder how much Guy Steele has do to with the Lisp-like features, if in fact he is still working at Sun.
How does free sound? http://www.eclipse.org/
AFAIK they will not be breaking existing code... If anything, they had to go out of their way (e.g. the ugly foreach statement) to ensure backward compatibility. In 1.4, the assert keyword might have caused problems, but now I don't think that's the case.
It's good to see enumerators formally supported, but you were not really _forced_ to use plain ints up to now. It is just some sort of an anti-pattern, which everybody seems to be using happily.
The type-safe enum pattern shows the correct way of handling enumerations. And you can the Jakarta Commons Lang library to make it a bit easier.
While eclipse is great, Netbeans has more features. I prefer eclipse because it uses a native interface and has refactoring. The most feature-rich IDE I've used for Java, however, is netbeans. If you don't mind a slow user interface it's a great tool to look at.
Developers: We can use your help.
But don't forget that features like Metadata have been a part of Java for at least a year via the widely used open source XDoclet project. It's only now being added to the Java standard because XDoclet is so popular and it makes writing EJBs *a lot* easier. XDoclet's ideas about metadata came from the Aspect-Oriented-programming movement, not C#.
The idea of autoboxing came from C++ where you can define your own conversions. Autoboxing becomes necessary to reduce syntax clutter when you add Generics to Java. This is because the Java implementation of Generics only works for Objects, not base types.
Foreach and enum is in more languages than you can shake a stick at, so you can't say they came from C#.
The "static import" idea is new. If C# has it, then it's likely Java took it from C#. Other than that, I can't see anything that Java took from C#.
As a pro Java developer, I want to use the native 'int' type in order to save memory, have less garbage collection, and perform better. Catching errors at compile time is helpful too. I think it is unreasonable for Sun not to include specializations for native data types. If I want to have an ArrayList of 10,000 ints I should be able to use 'int'.
The link on this page states up to 10x performance but I've seen it work up to 30x performance - and you can run the code below to see this for yourself.
NOTE:
30 = 7272727/236966 where:
1. 7272727 = 2nd iteration of Int2IntHashMap!
2. 236966 = 15th iteration of HashMap (Hot spot had 12 more iterations to optimize)
http://fastutil.dsi.unimi.it/
package com.wss.utils.test;
import java.util.*;
import it.unimi.dsi.fastUtil.*;
public class TestFastUtil {
public static void main(String[] args) throws Exception {
int count = 400000;
int timerCount = 20;
long start, end;
Integer tmp;
HashMap hashMap = new HashMap(count);
for (int timer=0; timer timerCount; ++timer) {
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
hashMap.put(new Integer(i), new Integer(i));
}
end = System.currentTimeMillis();
System.out.println("HashMap put(Integer, Integer) count:" + count +
", put/s:" + (count / ((float)(end-start) / (float)1000)));
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
Integer in = new Integer(i);
tmp = (Integer)hashMap.get(in);
if (!tmp.equals(in))
throw new Exception("failed equals()");
}
end = System.currentTimeMillis();
System.out.println("HashMap get(Integer) count:" + count +
", get/s:" + (count / ((float)(end-start) / (float)1000)));
}
timerCount = 100;
Int2IntHashMap int2IntHM = new Int2IntHashMap(count);
int j;
for (int timer=0; timer timerCount; ++timer) {
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
int2IntHM.put(i, i);
}
end = System.currentTimeMillis();
System.out.println("Int2Int put(Integer, Integer) count:" + count +
", put/s:" + (count / ((float)(end-start) / (float)1000)));
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
j = int2IntHM.get(i);
if (i != j)
throw new Exception("Int2Int failed equals()");
}
end = System.currentTimeMillis();
System.out.println("Int2Int get(Integer) count:" + count +
", get/s:" + (count / ((float)(end-start) / (float)1000)));
}
}
}
Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ (Java Web Startable)
...especially since the assert keywork is, on Sun's JDK, only compiled to a bytecode construct if you request it be at compile-time.
No bytecode changes are required. There have been "test" implementations out since Java 1.2. You can get the current 1.3 release atc es s/adding_generics/
http://developer.java.sun.com/developer/earlyAc
This isn't the forum for a detailed discussion, but I actually prefer enumeration classes now over simple enumerations. The basic idea is to write a class something like:
final class Color {
String c;
private Color (String color) { c = color; }
String toString() { return c; }
static final Color RED = new Color("red");
static final Color BLUE = new Color("blue");
static final Color GREEN = new Color("green");
}
You can then treat this class like a type-safe enumeration. It doesn't have all of the nifty features that you'll see in languages like Ada, but it has the nice property of allowing you to attach whatever information you want to the enumeration class.
You can also use this approach to create self-initializing classes, e.g., a list of states (including full name, postal abbreviations, shipping zone, etc.) from a database. You can access the enumerated values through a collection class, a "lookup" method, or even reflection.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Interested in Generics?
A Compiler for generic Java has been available for years:
You can check out Pizza/GJ here or here
Generics
The new Java generics are really weak compared to C++ template support. This is probably partially due to difficult in compiler support and also complexity (templates are without a doubt the most complex feature of C++). I was disappointed though in Java generics mainly due to lack of any kind of specialization support and also about the strange paradigm used for Iterators (instead of an iterator being class defined with a consistant interface, it's an external class that just behaves that must wrap a behavior around the class).
Enhanced for loop
This is for_each() in C++. Now, with for_each, you have to use function objects which is arguable as to whether it's more readable. Fortunately, Boost has developed a boost::lambda class that allows for code to be used as the third parameter. This is _really_ neat.
Autoboxing/unboxing
I presume this means that primatives can't be used in generics.. That's kind of sad. This isn't a problem in C++.
Typesafe enums
This would be a nice linguistic pattern to have in C++. As it stands, the equivalent would be:
struct Coin { enum { penny, nickel, dime, quarter }; };
Static import
This can be achieved via using in C++. Of course, Java doesn't even really have a namespace paradigm so it's not really a fair comparision.
Metadata
This is.. well.. strange. I didn't see the syntax for doing something like this. If it is just keyword/code replacing, then an #include directive would work just as well.
int func(int a);
func((b += 3, b));
-- Jack
This is what he said about Java and the likes.
Also here.
The method compareTo is supposed to override the method in Comparable, which takes an object. So they create a bridge method that overrides it normally:
I used to wonder why Java doesn't haver operator overloading. But it just occurred to me that overloading doesn't actually do anything except make misleading code. Think about it... what can an operator do that a normal method can't? Some would argue that operators make the code more readable, which they do. But they also obscure the difference between compiler reserved words and programmer defined words. Which is as dumb as being able to redefine "while". OTOH, in Lisp you can redefine +, even for integers.
Thanks a lot Sun for posting absolutely no information about the progress of this JSR. At least Doug Lea has posted a little information.
Hi,
;-)
Well, generics remind me of C++ templates
They're not quite the same; C++ templates are essentially glorified preprocessor macros with
some relatively small checking and a rather baroque
underlying functional language. Generics are more
concrete than that.
Not to mention that attached to variable name doesn't make code any more attractive to look at.
It would be really neat to have type inference there
It appears that Java's way to solve run time errors is to screw the bolts as tight a possible during compile time.
That's the idea, and that's also what I try to do when writing programs. Why should I have to write half a dozen test suites for some simple program property if the type checker can tell me whether it'll work right?
Remember: Compilers don't do type checking just to optimise, but also to catch programming errors. And Generics allow you to catch a much more interesting class of these.
-- Christoph
It's called competition and it's a good thing. That's why, ironically, Linux will be a good thing for Windows users. It won't be good for MS's finances but that only impacts MS stock holders, employees and suppliers so I could care less.
There was a preprocessor named jpp floating around a few years ago that supported operator overloading for Java. It seems to have vanished off the net in the meantime, though I'm sure I have a copy somewhere. True operator overloading is supposed to be added to Java at some point, IIRC.
In the meantime, perhaps we should write a new preprocessor, the "Operator Overloading Preprocessor System" or OOPS. jpp seemed like a good idea (it offered several features beyond operator overloading). Java coupled with a good preprocessor is a fine idea. ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
http://www.intellij.com/idea/
...richie - It is a good day to code.
Generics
No such thing in C#.
Enhanced for loop
expression needs to implement IEnumerable, or declare a GetEnumerator that returns an IEnumerator
Autoboxing/unboxing
Typesafe enums
Metadata
Sun has been burned once when they introduced the assert keyword and broke thousands of programs that use the JUnit testing framework. The bustage occured because JUnit already used the keyword as an identifier, for the assert() methods. A token can't be an identifier, so everyone's tests broke with 1.4 I applaud Sun from learning from that fiasco and avoiding a repeat.
I am actually using the initial implementation of this on our current project and it is very nice. Actually have fine grained synchronization control makes it much easier to deal with a lot of thread synchronization problems. It has also helped us greatly reduce deadlock and detect deadlock because locks and waits can time out and report to you that they have timed out rather than just happily returning like Object.wait() does today. All in all this, along with generics, is probably the best new feature that is being added in jdk 1.5
Next version of C# will have generics support. Unlike the Java implementation, it will support generics at level at which not only do you get syntactical sugar / compile-time type safety, you get collection and other classes with improve performance.
Furthermore, next version will include other nifty features such as lambda-style anonymous methods.
my favorite language (extension) for the vm has always been pizza. It gives you said generics, but also
- first-class functions and
- algebraic types (think functional pattern matching)
all three compatible with the original jvm 1.0 specification.But to be honest: this seems to be a real great step for java. programmer with a certain need for aesthetics (and self regard) can now really use this language...
Sounds to me like they just slurped in XDoclet, just like they slurped in Log4J in the 1.4 release.
This is exactly what the new Java enums do. You just get to type a lot less and you can use them in case statements.
autopr0n is like, down and stuff.
Don't forget about the JDEE!
The instances are created when the class is loaded, and there's only one copy of each value. It's essentially like you're using int constants, except they're pointer constants instead, so you can dereference them to get more information than just equality. It's essentially the same as
public class Season {
static public final Season spring = new Season();
static public final Season summer = new Season();
static public final Season fall = new Season();
static public final Season winter = new Season();
private Season() { }
};
Except it's only one line, there are useful additional methods (like a toString), and you can use it in a switch statement.
(this next bit is a very simple and very halfassed explanation in pseudo C. flames from C programmers about the bad syntax will be ignored. i got a D in C so F it)
Inlining works like this. You write a function and assign it a variable name. Then, any place you want that function, you use the variable name. The "precompiler" converts any instance of the variable name into the original function. EX:Later, if you use the term PISETUP it will be replaced with that code by the precompiler.
This was a good way to facilitate rewriting the same thing over and over, while maintaining speed, and a single location to change/fix the function. Unfortunately, it was also a good way for lazy programmers to obfuscate code by creating precompiler directives and variables for common language patterns. EX:Used to make:into:Shorter, yes. But harder to read, much harder to understand, and absolutely confusing for the poor newbies. Kind of like learning how to read from logs of an AOL chatroom.
One of the big "innovations" of Java was the elimination of the precompiler, which made sense. Java runs object code, not directly runnable byte code, so it is in essence already performing the tasks of the precompiler. The virtual machine "compiles" the code while it is running, to optimize for the individial physical machine, no matter what it may be.
The idea worked IMO because, now that you can cut, paste, and find and replace (with regular and replace expressions), you don't really need these replacements. Might as well just be verbose as you want to be. Might as well use tiny little functions since inlining doesn't work anyway.
Besides, since Java is interpretted and recompiled while it's running, you don't gain anything from inlining. Any "contextual" function (the function as written in the code) might become "inlined" when run by a good virtual machine program that performs "Just In Time" (JIT) compilation. Call void incrememtI(){ i++; ) a lot? The compiler will notice this, and replace calls in the stack to incrememtI() with the actual code this function contains.
This is why Metadata is a bad idea, or could be. No real benefit to the code, not much of a benefit for the "thorough" developer, and yet there's a real chance for lazy folks to create disgusting, hard to maintain code. This is never a good idea...a lot of coders think that obfuscated code makes them more valuable to employers. Not half...they'll axe you first if they think you're playing the obscurity game and will not give great references if you leave first.
Of course, if all Metadata does is replace:with:Then it may be worthwhile. Time, and the Java Community, will tell.
(PS: Used to work for/with a Pat Doyle, but he's not you)
Hey freaks: now you're ju
No, it reads like it was written by a programmer who understands what lambda expressions are and that the sort of 'generics' proposed for Java are cheap 'under erasure' model.
All of these proposials have been around forever, I was attending talks on pretty much the same Generics syntax at JavaOne two or three years ago... and I've been using the same kind of enum classes since Java 1.1.
C# didn't add generics at the start as they were waiting for Java to solidify how to do them.
Also, Java has a bit more of a wait for new features since Java goes through a real standards body instead of just being defined by what Microsoft wants. And of course lots of real production code that can break if you get things wrong.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
If you use Generics, your code will only run in 1.5 VMs. This was a marketing decision. Prototype versions of the Java compiler could previously use Generics and produce code for older virtual machines like the 1.1 VM.
r ead=389987&tstart=0&trange=15
r ead=321534&tstart=30&trange=15
Sun made this decision by itself without listening to its users and even censored its discussion. You can read about in the Generics message board:
http://forum.java.sun.com/thread.jsp?forum=316&th
http://forum.java.sun.com/thread.jsp?forum=316&th