Java 5 - The Gems and the Duds
Java 5 is, in my opinion, the greatest incremental release of Java since Java 2 came on the scene - JDK 1.2 ,way back in the day (1998 or so).
I've been coding with Java 5 now for just six months and I just wanted to touch on some of the great things in Java 5 that, for the first time, make me want to tell Java developers to
upgrade NOW!
THE GEMS
1) Java.util.Concurrent
For those of us that write multi-threaded programs, this API is a god-send. I'm sad to say that I did not know about the existence of this library prior to it's inclusion in the JDK and wish I had, as it would have made my life so much easier (See oswego link)
When writing Multi-threaded programs you spend so much time writing code to
1) Create and maintain thread pools e.g. add new threads to handle increases in load
2) Block until threads have done something
3) Threads polling shared data structures (ouch synchronization issues!)
etc. etc.
There's also the nasty surprises that you hit when you realize that simple things, like incrementing an integer, are not guaranteed to be Atomic!
Now with things like Executors and Futures and also faster thread-safe collections (e.g. ConcurrentLinkedQueue), there's just a TON of fabulous stuff here.
Brian Goetz has written a load of great articles on the framework (not to mention Java Concurrency in Practice which he wrote with several others).
See for Example
Put JDK 1.5's Executors to Work for You also
Structuring Concurrent Applications in JDK 5.0 and
Executing Tasks in Threads
When put together, these pieces make it much easier to write multi-threaded applications, and best of all, it makes them easier to understand and helps reduce the appearance of nasty bugs that are very common to such inherently unpredictable programs.
2) Generics
I always had a love-hate relationship with Java Collections - the interfaces were so friendly and easy to use, but being one who loves strong and static typing, I hated passing around a java.util.List or Map without really knowing at compile time what objects might be lurking inside and might trip me up with a good ole ClassCastException at Runtime!
So the addition of Generics was a big plus.
3) CachedRowSet
Probably not as "on the radar" as #1 or #2 are the advances in JDBC 3.0 that are included in Java 5. In particular javax.sql.CachedRowSet.
In a nutshell "A CachedRowSet object is a container for rows of data that caches its rows in memory, which makes it possible to operate without always being connected to its data source. Further, it is a JavaBeansTM component and is scrollable, updatable, and serializable."
Finally we can pass a "ResultSet"-like object around between classes, between layers or between tiers. Then we can update it, delete rows, add beans etc. and then send it back to the database for "Syncing" up. Wow!
Also buried in JDBC 3.0 - the caching of prepared statements is a welcome addition. Anything that puts the onus on the Driver rather than the coder is a boon!
4) Annotations
Anything that makes J2EE programming easier is a boon (esp. less classes to write!)
THE DUDS
Well there's actually only one . . .
Autoboxing
There's really only one dud in Java 5 and that's autoboxing. Now I love the foreach loop, and removing boilerplate (casting) code is always a good thing. But introducing the possibility of more NullPointerExceptions is a tough price to pay.
See this ServerSide article for a good summary.
In the end I just configured my IDE (Eclipse) now to create an "Error" anytime it sees any boxing and unboxing conversions.
The key issue is, after 8+ years of Java programming and fixing several *NASTY* NPEs, I really didn't need my job doing NPE fixes to get any harder or more frequent :-(
TOO EARLY TO TELL
1) Varargs
Haven't really used Varargs in Java enough yet so it's too early to tell - looks like a positive but hopefully there's no landmine buried there like for Autoboxing!
2) Enums
In general I'm leaning towards liking Enums in Java but I have to really play with them a bit more before deciding. Java is an OO language and these are like Classes/Objects and yet not - so I'm not 100% sure of how they should be treated in practice. Probably some best practices will emerge!
In Conclusion
Sun and the JSR leads have done a really good job, the only pain being a new IDE setting, but the gains are fabulous. I look forward to more of the same in Java 6 (now open source eh!?)
HOLD THE PRESSES . . . .
Here's one I forgot to mention but also goes in the "Gems" section - now in the Thread class you have a method that will return a Map from a Thread object to an array of StackTraceElement objects. See Thread.getAllStackTraces() . What a really useful tool to aid in diagnostics / debugging.
Labels: java
posted by Frank Kelly at 10:19 PM
View blog reactions
7 Comments:
Hey, check out this site - these guys pay you up to 30 percent money back for all of your normal online purchases! How does it work? They give you the money they earn from their affiliates whenever you buy through them. Click here for more info
11/21/2006 8:51 AM
The only problem autoboxing has caused me is that I've accidentally done == comparisons on Integers. I haven't seen a NullPointerException because of them, although yes, I know it's possible.
Instead, I avoid null in my code, through using the builder pattern instead of allowing half-initialised objects, and through using the Maybe type that I've stolen from Haskell (see http://functionalpeas.googlecode.com/svn/trunk/src/fpeas/maybe/) in the case that I actually want a 'nothing' value.
CachedRowSet is a good addition, thanks for the heads-up on that.
11/21/2006 11:09 AM
Hmm...
What an enum is good for?
I only know them from my experience with C, and I'm not sure I like to see them in java.
Well, an enum is good for enumerating small finite sets. They can be a design disaster unless you are absolutely certain that you have a small finite set that you want to enumerate which will not be extended, for then you can quickly create a set, and expressions using enums can be computed quickly; code using enums can be made more obvious.
A common use for enums is to create a set of flags in C programs that can be used as a way of message passing. Also, one can use it to 'tag' some data with a type (where the type is an element of an enum).
In java, they would probably serve as a cheap alternative to making yet another subclass. Routines created using enums are generally not very extensible.
11/21/2006 2:41 PM
An enum is just a poor man's alegraic data type. See a real language if you want to get a feel for an alternative frame of reference.
I think I might need to write up a blog of the inherent contradictions within generics - maybe then you'll change your mind.
Finally, let's look at variable argument lists - implemented as arrays. Enough said I hope?
11/21/2006 8:03 PM
My personal favourite at the moment is the String.format method. It makes constructing strings so much neater, removing the need to manually concatenate a bunch of strings together. Sweet!
11/22/2006 11:57 AM
Personally, enum is my favorite new feature. In cases where you have a (closed) set of related constants, replacing those with an enum generally results in way less code that is safer, more readable, and has more functionality (auto toStrings is a big win).
I actually think I'd count generics as sort of a mixed gem/dud. From a usage point of view, I think it's usually worse (easily bleeds from descriptive into annoying complicated). From a class / framework implementation point of view, I find it generally helps to state intent more than it hurts. Overall, I could do without it.
11/22/2006 2:39 PM
I'd like to have some syntax for autoboxing, which will return default value if the underlying object is null. It could be for example i:default
some stupid sample:
int sum(Integer a, Integer b) {
return (a : 0) + (b : 0);
}
But I don't know how can it be handled in enhanced for loop
int sum(List<Integer> list) {
int sum = 0;
for (Integer i : list) {
sum += i : 0;
}
return sum;
}
11/24/2006 2:49 PM
Post a Comment
Links to this post:
Create a Link
<< Home