Summary of JDK1.5 Language Changes 839
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."
Generics (Score:3, Interesting)
Re:Generics (Score:5, Interesting)
Retro... (Score:3, Interesting)
not just sugar (Score:4, Interesting)
To add a property, say a String called name you have to write:
* The name of this object.
*/
private String name;
* The name of this object.
*/
public String getName() {
return name;
}
* The name of this object.
*/
public void setName(String name) {
this.name = name;
}
That's 16 lines of code for one property! This is tedious to write, and more importantly, very hard to read when you have many properties.
This could easily be reduced to something like:
* The name of this object.
*/
property String name;
expanded to exactly the same code as above by the compiler. Incredibly useful if you're, say, writing a lot of value objects in a j2ee scenario.
Re:Give billg his due... (Score:2, Interesting)
i've been a Java programmer (primarily) for 8 years, and just recently did a project in C# -- which i was dreading, but the language turned out to be OK, like Java with sops thrown to C++ diehards.
now, if Sun adds operator overloading (*shudder*), i'm jumping ship.
Re:Programming shortcuts (Score:4, Interesting)
Every language has idioms, and a programmer should use those idioms in preference to other allowable ways to do things unless they have a good reason. It's all just part of good style.
So C# is basically Ada without strong typing? (Score:3, Interesting)
Seriously, the "C# copied from Java/Java copied from C#" argument misses the point. There's a lot of prior work, and finding the right balance between usability and clutter is difficult. As much as I loved writing stuff like "for (value'range) do..." I would rather see a conservative approach to features since it's always easier to add stuff than remove it.
Re:Much, much more than syntactic sugar (Score:1, Interesting)
It will also make code easier to write in another way:
Modern java editors (in particular the almost magical Intellij IDEA) provide code completion based on valid types in a given context. The more the editor knows about the types involved, the better this feature will work.
Re:Why I don't like Java (Score:5, Interesting)
Typecasting is a tool -- do you really trust the compiler to recognize exactly what you mean in every scenario, throughout your hundereds of thousands of lines of code? I don't want to have the compiler (or run-time environment, or interpreter, whatever) to "guess" at what I mean -- I want to tell it exactly what I mean.
<flame> Perhaps this is why huge applications are usually written in languages requiring typecasting, and the "looser" languages are usually relegated to simple task duty.</flame>
Article didn't mention new concurrency stuff (Score:5, Interesting)
Bascially, the goal of JSR 166 is to do for concurrency programming what JDK 1.2 did for data structurs (Collections stuff). The gist is, you'll never need to use "new Thread()" or "synchronized" anymore, but rather you'll execute Runnables, use Locks and Semaphores, etc. Also, queues are *completely* reworked to be ultra scalable.
JSR 166 is based on Doug's concurrency package:
http://gee.cs.oswego.edu/dl/classes/EDU
OH, and there will be classes like AtomicLong which guarantee atomic 'compare and set' options for primitives.
Cheers!
Re:Generics (Score:3, Interesting)
List<Foo> list = new ArrayList<Foo>();
list.add( myFoo );
Foo otherFoo = list.get( 0 );
The compiler will interpret the second and third lines as if they said:
list.add( (Foo)myFoo );
Foo otherFoo = (Foo)list.get( 0 );
It's a pretty elegant way to incorporate type-safe generics without imposing any changes on the VM. I think the compiler changes would be relatively easy to implement -- nothing more than inserting casts at the appropriate places.
Re:Agreed.. (Score:5, Interesting)
(Just goes to show there will be differences of opinion and no such thing as "the" right way. Here's another example:
if( x == 5 ) { do something }
versus
if( 5 == x ) { do something }
Some prefer the second way because it puts the term which cannot be a valid lvalue on the left side, thus if you make the common typo of "=" instead of "==", you will get a compile error from it, which wold not happen for x = 5. But, it looks very odd to write it 'backward' like that, so some say the readability of doing it the 'dangerous' way makes it worth doing it that way.
There is no such thing as "the" best way, not even in Java.
Re:Write once, Rewrite forever? (Score:3, Interesting)
Huh? Where did you see that?
It looks like they're making changes so that new apps won't compile on older compilers, not that old apps won't compile on newer compilers.
They risked a backwards compatibility problem when they introduced that "assert" keyword in 1.4 but there is a compiler switch to turn it off if you have variables with that name. Before that, they haven't messed with the syntax since 1.1, when they added class literals (syntactic sugar) and inner classes (a major change). The new syntax was so bizarre that no older programs were affected. I don't see how the 1.5 changes are any different. Some of them look like a cat walked across someone's keyboard.
My company is stuck with having to support Java 1.1 because of Mac OS 9. (In fact, according to our demo download stats, the number and percentage of Mac OS 9 users is only going up.) So we use modern compilers when developing (no decent IDE works well with 1.1) but the nightly build script uses 1.1.8.
Inner classes were an immense change compared to most of this sugary 1.5 stuff (except generics). Work here a few months and you learn about all the bugs in the 1.1.8 compiler with respect to inner classes. There are a number of perfectly legal constructs that get flagged as errors. But I bet the same kind of thing will happen with generics.
I agree with the author (Score:1, Interesting)
Why is that bad you might ask? I mean who wouldn't want to do more in fewer keystrokes. Well there are a few major problems that I see:
1. There is a much greater ability to get into the "Perl factor" where there are 16 million ways to do the same thing. While having so many ways to get the same thing done is great if you are one or two folks working on a project, its terrible if you are 20-30 developers working on the same project. So these 'improvements' seem to push Java away from being a good Enterprise level language.
2. While none of the changes specifically target this, its movement away from being a systems language where the programmer is very close to the underlying action that the computer is doing. One of Javas greatest strengths is its ability to get deep into the bits (like C), and while this is not going away this seems to be where alot of the thinking is.
3. These 'improvements' will be all that some newer programmers learn. I think this will lead to a much greater number of java programmers who don't really understand whats going on and we will have a lot of confusion out there.
All of this because some people wanted to save a few keystrokes.
compiled java? (Score:2, Interesting)
When it comes down to it, once the code is compiled, it's the same.
If you're compiling, shouldn't you use a language which wasn't designed to be interpreted?
Personal comment (Score:1, Interesting)
The generics and the autoboxing are heaven sent from a language standpoint. The other stuff mostly is syntatic sugar and the static imports I really don't know if that is a good extension to keep the code readable. But the biggest gripes with java are not the language but two other things:
a) long loading times caused by the class loader class verifier mechanism
b) huge memory footprint thanks to mem hungry hotspot optimizations
What I really couldn't find is if those two issues will be adressed or postponed again.
Btw. if you like java but think that swing is slow in X check out the latest blackdown release, it is amazing what the blackdown guys did to swing. Also check out the 1.4 JDK for the mac, no difference to a native mac app speedwise.
Re:enumerators (Score:5, Interesting)
Evil thought: you could get relatively nice-looking static instances with methods if you combined enums with anonymous inner classes...
When will Java be 'frozen'? (Score:3, Interesting)
One of things that makes older more mature languages like Common Lisp (and perhaps Smalltalk) nice to work with is a feeling of both having really solid implementations and not breaking legacy code.
I like the idea of boxing and generics, but, these changes will affect old code (probably?) and the platform in general.
My vote would be to freeze the Java language (perhaps after 1.5) and concentrate on the following:
I would not like to see Java become a language designer's playground.
Because of great infrastructure software like servelt/JSP containers, (perhaps EJBs :-), XML utilities, solid web services support, etc. Java is a great platform.
Leave it alone (the sooner the better) except for improvements in the implementation.
-Mark
This is a sad day for me. (Score:3, Interesting)
To the many cooks who spoiled the broth: "Thanks a lot, assholes."
Re:Generics (Score:3, Interesting)
The JVM executes a checkcast bytecode instruction wherever there is a cast. It either does nothing or it throws a ClassCastException at you. (The instanceof instruction works the same way, except it puts a boolean on the stack instead.) But with generics, a runtime cast is never required IIRC. The compiler generates a one-shot collection class based on the generic that ONLY handles members of the type you've specified (e.g. String) and returns objects of that type, so the type checking is done statically. The entire purpose was to eliminate the runtime cast.
Re:Where is operator overloading? (Score:3, Interesting)
Re:enumerators (Score:5, Interesting)
I don't use ints for my enumerations anymore after reading Josh Bloch's Effective Java. The type-safe enum pattern he recommends is fantastic.
For those not sure exactly how it works, you simply create a class to represent an instance of the enum, and you make the constructor private so that no one can create their own instances. Then you just provide a public static instance of the class for each enum.
I used this pattern simply to achieve its intended effect of providing an enumeration, and then later found that by adding methods to the class, I could even give behaviors to the enumeration instances! Try doing that with an int. This was far more elegant than creating a giant "if" statement and performing conditional logic to test the value of the enumeration, because I simply used a polymorphic method call.
An example:
You get the main idea. No, not as fast as an int, but far more powerful.
Re:enumerators (Score:5, Interesting)
It's nice to see Java stealing something from C# for once
Maintenance (Score:2, Interesting)
Do you like seeing "public void setX()...public int getX().." a hundred thousand times to implicitly declare a bound property? Or would you rather see "published int x;" (to steal a line from C#) and be able to refer to x by field name rather than accessor method? I think simplifying code like this is a good idea. However, there is a dilemma created herein, as the example below will illustrate!
Thought Experiment #1
Assumption: Maintenance cost is directly correlated with program size.
Therefore: The more terse the language grammar, the easier programs written in the language are to maintain.
Thus: Perl.
At that moment, the programmer was enlightened.
"synchronized" vs. locks & semaphores (Score:3, Interesting)
I'm not sure how locks and semaphores are a step forward from monitors, which is what "synchronized" represents.
Are you claiming "synchronized" is inefficient? Did you see the developerWorks article [ibm.com]?
Are you claiming that such a high-level structure as a monitor is unnecesary for real programmers, who know what they're doing and will never screw up using synchronization primitives?
John.
Automatic boxing/unboxing (Score:3, Interesting)
Actually, I think that's a bad idea, since you wouldn't be able to tell a zero you put in a collection with one that you didn't. Personally I'd like to see this as an option, somewhere. perhaps as a parameter to Integer, so you could do Integer<0> or Integer<null> to chose the behavior of the class. The problem there is that it's not obvious what a parameter to integer would do. Although I suppose you could use an if statement.
Personally, I wished they would have thought up a more interesting way to do generics then the C++ model. I wonder if this is going to give us the full range and power of C++ templates in java.
Can someone please tell me why anyone uses Java? (Score:0, Interesting)
Enhanced "for" loop? Syntactic sugar. Oh and for God's sake, don't use new keywords. It'll be destabilizing.
The "split type system" in Java has always compromised Java's status as a true OOP platform. Seriously, this is supposed to be exciting? Java is how many years old and they've finally made it oh-so-easier to convert between primitive and class types? Aren't there enough conversions in a strongly typed language?
Typesafe Enum pattern, Constant Interface antipattern
Metadata programming. Now Java will have code that emits code before the compiler emits code. Well, there goes Java having no pre-processor. But in true Java fashion, it looks like this "framework" will be much, much harder to use than a pre-processor, so that's good.
Bottom line, Java is Byzantine, slow, bloated, and now playing catch-up. Want to avoid all this verbose, camel-cased code? Go C++. Yes, you'll have to learn how to write secure code, and yes, you'll have to use pointers, which are supposedly EXTREMELY DANGEROUS, and yes you'll have to learn about how your computer works a little more to be an expert. Of course, Java requires none of these things.
If you must go with some absolutely proprietary platform, then go C#. At least it's standardized. Oh, oh, Sun was going to do that with Java but then, you know, didn't.
Re:Programming shortcuts (Score:4, Interesting)
Enumerated types will save your ass the first time you change databases or some project manager adds a new "status level" in between DONE and FINISHED. They are much faster than using internalized strings, which is how I had been testing for this crap. Remember, once they hit the object code they're just constants anyway...
Foreach was easily the coolest thing about C# when I started using it, indexers were the second, and the code they create is FAR more maintainable than for(Object o = someList.FirstItem(); o != someList.LastItem(); o = someList.NextItem()){
Automagic "boxing" is a beautiful thing for newbie coders...I have had to teach so many the difference between a Byte and a byte that it isn't funny. I intend to use it, too...we pass in and out of the classes for char, int, byte, bool etc so often it makes sense to have the compiler/VM do our dirty work for us.
And generics...well, they look real queer in Java, where we've never used the syntax before. But they will save our behinds on reuse! Besides no doubt being faster, it will make more sense when typing collections of inherited objects. We have a BaseRecord class. We have an optimized BaseRecordColl class, usually full of different types of ChildRecord classes. If we can write the one collection class, and not have to explicitly cast each child op, it will save time, space, and hassle...and avoid calling the superclass methods of uncast subclasses!
Metadata is the only ingredient here that seems like it could cause trouble, and if it does it will be because people are using it wrong. Java is not a language that inlines...that's the whole idea of the JIT...and with today's cut and paste GUI IDEs, there's no need for programmers to use the lazy C declarations of the past. If people start doing so because it's neat, just nip it in the bud. Find/Replace when the code hits your desk. Eventually they'll get the hint.
Re:This is a sad day for me. (Score:2, Interesting)
Re:Shorthand programming (Score:3, Interesting)
Interestingly, ISO C defines shorthands for people with crap keyboards. You can type <% instead of { and %> instead of }. Also:
<: means [
%: means #
%:%: means ##
You get even more if you include iso646.h. Of course, the old compiler you were using may not have had these
Re:enumerators (Score:4, Interesting)
Needed feature (Score:3, Interesting)
Re:enumerators (Score:4, Interesting)
You simply do not need to use switch when you have polymorphism, which is a much more powerful mechanism and allows for much nicer scalable, maintainable, and readable code. Of course, this assumes that one has an understanding of OO.
If there is a problem with safe enums, it is with serialization and deserialization. There are a number of solutions available for that, however. Personally, I feel that those should have gotten in the Java libraries, not enums in the language, but oh well.
available such as , something that the safe enum provides, unlike the enumerations.
Where are shared jar files/JVMs? (Score:3, Interesting)
IMHO this is one the main shortcommings of Java. Every jar file is loaded into every process causing a huge memory footprint and long startup times.
When playing around with some java shells, that only load classes once and simulate processes as threads, I saw simple swing applications load in 0.1 secs and other significant speed ups.
I was hoping for it in 1.4.x and now it seems it won't even make it into 1.5. I realize that it will be hard to implement this in a platform transparent way.
Re:Retro... (Score:3, Interesting)
If they'd said "i" is now a keyword, that would have been more of a problem.
we can thank Microsoft for this (Score:3, Interesting)
Unfortunately, this doesn't quite make Java competitive with C# yet. Major missing features are:
Also, Sun's patents on core Java technologies and the lack of a well-defined, open Java standard are still serious problems. The fact that Swing is de-facto part of the Java standard but that Swing is as ill-defined as the Windows API is another problem because it makes it hard to create open source implementations of Java.
Re:More overloading evil... (Score:3, Interesting)
if (fooIsSafeToDo() && foo())...
This is guaranteed to work in C and Java, and to 99.9% in C++. So as a C++ developer you're forced to either always write
if (fooIsSafeToDo()) {
if (foo())...
or to keep writing code that will almost always work. That is, if you're even aware of the issue, which I'm sure most programmers are not.
If I understand your point, this can't happen in the common case where 'fooIsSafeToDo' is a null check, which is good, but doesn't really change the principle. And no, I haven't seen this one bite anyone, but I've seen plenty of other really obscure C++ traps wreak havoc.
Here's an other pet peeve, while I'm whining. Why is this unsafe C++ code?
getResource();
foo();
releaseResource();
because foo() may throw an exception, so this is a resource leak.