Cedric Beust has been in a position to actually code with JDK 5 for over six months. He has written up his thoughts on the new features, and how he has found them to be in practice.
He discusses the new for loop, Annotations, Static Imports, varargs, Enums, Autoboxing, and Generics.
Read JDK 5 in Practice
-
JDK 5 in Practice (24 messages)
- Posted by: Nuno Teixeira
- Posted on: November 05 2004 16:15 EST
Threaded Messages (24)
- Good Article! by Sebastian Kuebeck on November 06 2004 11:40 EST
- Good Article! by Emmanuel Bernard on November 08 2004 11:55 EST
- Good Article! by Pavel Tavoda on November 09 2004 03:27 EST
- Good Article! by Emmanuel Bernard on November 08 2004 11:55 EST
- Printfriendly Link by Alex V on November 08 2004 11:28 EST
- JDK 5 in Practice by Alex Vasseur on November 08 2004 11:48 EST
- typedef in java by Carlo Marchiori on November 09 2004 02:56 EST
- Awaiting Eclipse support... by Dave Minter on November 09 2004 12:54 EST
- Awaiting Eclipse support... by Emmanuel Bernard on November 09 2004 16:23 EST
-
Awaiting Eclipse support... by Dave Minter on November 10 2004 05:20 EST
-
Awaiting Eclipse support... by Emmanuel Bernard on November 10 2004 05:48 EST
- Awaiting Eclipse support... by Dave Minter on November 10 2004 11:58 EST
-
Awaiting Eclipse support... by Emmanuel Bernard on November 10 2004 05:48 EST
-
Awaiting Eclipse support... by Dave Minter on November 10 2004 05:20 EST
- Awaiting Eclipse support... by Emmanuel Bernard on November 09 2004 16:23 EST
- When will app server vendors use 1.5 by Dave M on November 09 2004 12:55 EST
- Drat... by Donald Smith on November 09 2004 14:14 EST
- JDK 5 in Practice by J K on November 09 2004 15:17 EST
- JDK 5 in Practice by Cedric Beust on November 09 2004 16:06 EST
- JDK 5 in Practice by Clive Brettingham-Moore on November 09 2004 19:34 EST
-
JDK 5 in Practice by Dave Minter on November 10 2004 05:25 EST
- JDK 5 in Practice- Kerberos by Clive Brettingham-Moore on November 11 2004 10:06 EST
-
JDK 5 in Practice by Dave Minter on November 10 2004 05:25 EST
- Don't Repeat Yourself by Eamonn McManus on November 10 2004 07:55 EST
- Don't Repeat Yourself by Carlo Marchiori on November 10 2004 09:25 EST
- Don't Repeat Yourself by DONDI IMPERIAL on November 10 2004 07:47 EST
- Don't Repeat Yourself by Carlo Marchiori on November 10 2004 09:25 EST
- Wake up Cedric ;) by pazzaglia jean-christophe on November 10 2004 10:04 EST
- Wake up Cedric ;) by Cedric Beust on November 10 2004 17:39 EST
- Backward compatibility by Jean-Pol Landrain on February 21 2005 06:30 EST
-
Good Article![ Go to top ]
- Posted by: Sebastian Kuebeck
- Posted on: November 06 2004 11:40 EST
- in response to Nuno Teixeira
I think that JDK 5 will show it's real power
once people learn how to use it's feautres in day to day's work and combine the new stuff with their existing best practices.
To the generics example:
First, you derive from the peremetrized class
to avoid the overhead in declaration, second
you'll probably want to change some of the
Hasmap's behaviour and soon you'll encapsulate
it. Next, you feel like deriving the new class
from an interface and you end up doing what
you did before you had Generics.
One thing to the TestNG Javadocs:
Maybe it's just a matter of taste but I don't
like The interface names beginning with an 'I'
like ITest for the simple reason that it's
the Interfaces that should be used, not the classes.
It's not really a problem if the implementation's
name is somewhat ugly since it's normally not used
directly. Interfaces should have sound names
since they are heavily used! -
Good Article![ Go to top ]
- Posted by: Emmanuel Bernard
- Posted on: November 08 2004 11:55 EST
- in response to Sebastian Kuebeck
I think that JDK 5 will show it's real poweronce people learn how to use it's feautres in day to day's work and combine the new stuff with their existing best practices.
I can tell you that coming back to the good old JDK 1.4 style (wo Collection Generics) *is* painful. I miss my 5.0 at work :-) -
Good Article![ Go to top ]
- Posted by: Pavel Tavoda
- Posted on: November 09 2004 03:27 EST
- in response to Emmanuel Bernard
Same here. At work I have to use 1.4 and it's so difficult to live without nice for loops and generics. Specially interfaces between programmers are better with generics.
Also GUI stuff in 1.5 (programmable page flipping and buffering) is very good. -
Printfriendly Link[ Go to top ]
- Posted by: Alex V
- Posted on: November 08 2004 11:28 EST
- in response to Nuno Teixeira
An application exception has occured: Value for parameter 'listener' in component Blog/printFriendly.link is null, and a non-null value is required. -
JDK 5 in Practice[ Go to top ]
- Posted by: Alex Vasseur
- Posted on: November 08 2004 11:48 EST
- in response to Nuno Teixeira
Just a note "about the author": Cedric is not anymore at BEA but at Google. -
typedef in java[ Go to top ]
- Posted by: Carlo Marchiori
- Posted on: November 09 2004 02:56 EST
- in response to Nuno Teixeira
The typedef in java is done simply by coding an empty class
class A extends B {}
You can find examples of this practice also in the jdk itself (see the inner class Lock in the ReferenceQueue implementation).
It would be nice to have this practice supported by the compiler. I mean, since we don't want to override anything typedef could be applied also to final classes and to primitive types (maybe through autoboxing?). So we may write
class A extends B;
class UserCode extends java.lang.String;
class AgencyCode extends int;
Through these typedefs one obtains strongest type checking and also method signature may become more explicit: when I use a library class without source code, you see methods like
void someMethod (int arg0, String arg2, String arg3)
which is not very suggestive. Instead if we had
void someMethod (UserCode arg0, AgencyCode arg2, String arg3)
it would be different, woundn'it? I submitted an rfe to Sun, but it was rejected saying I must go through the community. So, what do you think? -
Awaiting Eclipse support...[ Go to top ]
- Posted by: Dave Minter
- Posted on: November 09 2004 12:54 EST
- in response to Nuno Teixeira
While I've done a lot of playing to familiarize myself with the new syntax, I'm really waiting for Eclipse support before starting to adopt Java 5 properly. I don't suppose I'm alone in this.
Personally I found the 3.0 milestone builds to be so unexpectedly reliable that I intend to adopt the first 3.1 milestone build to provide full Java 5 language support.
If you're interested, the state of play with 3.1M3 released on 5th November is:
Supported:- Enumerations
- Static Imports
- Varargs
- Generics
- Enhanced For
- Hex Floating Point Literals
Not supported:- Annotations
- Autoboxing
According to the release notes for 3.1M3As of M3, the Eclipse Java compiler is passing 97.95% of the JCK 1.5 compliance tests, up from 96.8% for M2. Only 223 more tests to go, out of 10863.)
So it looks like they're getting really close to the point where I can adopt it. Hurrah!
Dave. -
Awaiting Eclipse support...[ Go to top ]
- Posted by: Emmanuel Bernard
- Posted on: November 09 2004 16:23 EST
- in response to Dave Minter
Embrace IntelliJ Idea, its working *now* -
Awaiting Eclipse support...[ Go to top ]
- Posted by: Dave Minter
- Posted on: November 10 2004 05:20 EST
- in response to Emmanuel Bernard
But I don't like it. Why shouldn't I wait a month or two for the IDE that I do like to acquire the features in question? It's not like there's a massive hurry or anything.
Dave. -
Awaiting Eclipse support...[ Go to top ]
- Posted by: Emmanuel Bernard
- Posted on: November 10 2004 05:48 EST
- in response to Dave Minter
I do work on annotations more or less for 6 months now.
Notepad-like IDE for six months is a pain, truely believe me ;-) -
Awaiting Eclipse support...[ Go to top ]
- Posted by: Dave Minter
- Posted on: November 10 2004 11:58 EST
- in response to Emmanuel Bernard
I do work on annotations more or less for 6 months now.Notepad-like IDE for six months is a pain, truely believe me ;-)
That's lovely, you use your IDE. Since I loathe it, I'll just wait, thanks. None of my clients will be using Java 5 for at least another 6 months or so while any bugs shake down. -
When will app server vendors use 1.5[ Go to top ]
- Posted by: Dave M
- Posted on: November 09 2004 12:55 EST
- in response to Nuno Teixeira
Does anyone know the timeframe for when app server vendors will start using the 1.5 JVM? -
Drat...[ Go to top ]
- Posted by: Donald Smith
- Posted on: November 09 2004 14:14 EST
- in response to Nuno Teixeira
I was hoping Cedric would be the first to say what a bad idea mutable enum's are... I need someone to say it quick before everyone starts doing it. :)
- Don -
JDK 5 in Practice[ Go to top ]
- Posted by: J K
- Posted on: November 09 2004 15:17 EST
- in response to Nuno Teixeira
What really surprised me about JDK1.5 is that Sun totally ignored very fundamental warts in the previous versions so they could put in some fancy (yet, IMHO, mostly optional) functionality.
Here's what I'm talking about: instead of a foreach, I'd much rather have a non-stupid implementation of Calendar, a java.io.File class that acutally represented a file instead of just being a String pretending to be a file, get rid of the old deprecations, put support for symbolic links... I could go on and on.
Java's a great language, but there's some dumb dumb code in the JDK that needs to be ousted! -
JDK 5 in Practice[ Go to top ]
- Posted by: Cedric Beust
- Posted on: November 09 2004 16:06 EST
- in response to J K
instead of a foreach, I'd much rather have a non-stupid implementation of Calendar
You will take the enhanced for loop out of my cold, dead hands ;-)
--
Cedric -
JDK 5 in Practice[ Go to top ]
- Posted by: Clive Brettingham-Moore
- Posted on: November 09 2004 19:34 EST
- in response to J K
Here's what I'm talking about: instead of a foreach, I'd much rather have a non-stupid implementation of Calendar, a java.io.File class that acutally represented a file instead of just being a String pretending to be a file, get rid of the old deprecations, put support for symbolic links... I could go on and on.Java's a great language, but there's some dumb dumb code in the JDK that needs to be ousted!
I'll agree there, accumulation of legacy code is always a problem, but it's not always easy to remove (AWT springs to mind). Your examples are really puzzling though
Just wondering what exactly is stupid about the Calendar?
It's cumbersome, sure, but that is the underlying nature of our time system.
A file is identified by file name, which is a String I'm not sure what more a file could be.
I assume you mena link creation? I was under the impression that symbolic link navigation is supported implicitly under unix, and since Windows doesn't have symbolic links that pretty much covers it (believe me, Windows "links" are not symbolic links).
I'm excited about the new version, the extra util & concurrency stuff was long overdue, pity that despite all the new security features there is still no standard way to request kerbros service tickets (it must be there for JGSS, but JGSS-API is really not doing it for me; who uses streams, anyway?) -
JDK 5 in Practice[ Go to top ]
- Posted by: Dave Minter
- Posted on: November 10 2004 05:25 EST
- in response to Clive Brettingham-Moore
Do you need the raw ticket, or just the capabilities they provide? The JGSS-API can do most of the things you might want to do with a raw ticket, so well worth pursuing that; works well with ActiveDirectory too (it's mixing AD and MIT Kerberos that reputedly causes problems).
There's some nice example code in the SSO section of the Apress book on Portlets (disclosure: I'm co-author, and I wrote that code) which you can download from their site without buying the book.
Dave. -
JDK 5 in Practice- Kerberos[ Go to top ]
- Posted by: Clive Brettingham-Moore
- Posted on: November 11 2004 22:06 EST
- in response to Dave Minter
Do you need the raw ticket, or just the capabilities they provide? The JGSS-API can do most of the things you might want to do with a raw ticket, so well worth pursuing that; works well with ActiveDirectory too (it's mixing AD and MIT Kerberos that reputedly causes problems).There's some nice example code in the SSO section of the Apress book on Portlets (disclosure: I'm co-author, and I wrote that code) which you can download from their site without buying the book.Dave.
Busy for a few days.. just in case you're watching the discussion - I was aiming to authenticate (yes, mostly AD SSO usage) web services using the oasis WSSE. The kerberos ticket would be neede - it is passed embedded in the SOAP header (the SOAP body would be encrypted with the session key). SSO with a cachable credential, built in key transport & session expiry, sweet (the for the application the messages need to be cachable as well).
Although it would be possible to trick GSS into getting a ticket & then fetching it out of the subject credentials this was a little too back door for my tastes.
I've fallen back on a solution using public key encryption (client determined session key) & PKCS#5 HMAC authentication without SSO (which wasn't a core requirement).
The security mudule is well isolated so I'll be keeping an eye on Kerberos/AD SSO as a potential upgrade.
Clive -
Don't Repeat Yourself[ Go to top ]
- Posted by: Eamonn McManus
- Posted on: November 10 2004 07:55 EST
- in response to Nuno Teixeira
Concerning the problem with this:
Map<String, List<Account>> accounts =
new HashMap<String, List<Account>>();
you can simply define Util.newMap() and write:
Map<String, List<Account>> accounts = Util.newMap();
See http://www.artima.com/weblogs/viewpost.jsp?thread=79394 -
Don't Repeat Yourself[ Go to top ]
- Posted by: Carlo Marchiori
- Posted on: November 10 2004 09:25 EST
- in response to Eamonn McManus
I consider this solution worse that the problem.
This kind of repeating is inherent in type safe languages. You have always written
File file = new File ("a.txt");
This time, it's only what you repeat is a beat more verbose.
If I remember it right, C++ has a syntax shorcut for this, something like
File file ("a.txt");
but I'm not sure. It may be useful in java too. -
Don't Repeat Yourself[ Go to top ]
- Posted by: DONDI IMPERIAL
- Posted on: November 10 2004 19:47 EST
- in response to Carlo Marchiori
You have always written
File file = new File ("a.txt");
This time, it's only what you repeat is a beat more verbose.If I remember it right, C++ has a syntax shorcut for this, something like
File file ("a.txt");
but I'm not sure. It may be useful in java too.
If I remember correctly
File file = new File ("a.txt"); and File file ("a.txt"); have different meanings in C++ the former declares an object on the heap (which you need to reclaim later). The variable "file" in this case points to a pointer to the object not the actual object itself. The later declares an object on the stack (which is automatically "cleaned" for you when the variable goes out of scope). In this version the variable "file" points to the actual object. -
Wake up Cedric ;)[ Go to top ]
- Posted by: pazzaglia jean-christophe
- Posted on: November 10 2004 10:04 EST
- in response to Nuno Teixeira
... I can not believe that you spent 6 months
trying out only the new Tiger sugar - tarte a la creme ...
By any chance, did you try out the Metadata (Annotations) features ? Are they easy to use ? How do they compare against 'doclet' ?
Amicalement
jean-christophe (alias pizza92) -
Wake up Cedric ;)[ Go to top ]
- Posted by: Cedric Beust
- Posted on: November 10 2004 17:39 EST
- in response to pazzaglia jean-christophe
... I can not believe that you spent 6 monthstrying out only the new Tiger sugar - tarte a la creme ...By any chance, did you try out the Metadata (Annotations) features ? Are they easy to use ? How do they compare against 'doclet' ?Amicalementjean-christophe (alias pizza92)
Wow another echo from my past comes to haunt me.
Not only have I used annotations but I've actually participated in defining them :-)
--
Cedric -
Backward compatibility[ Go to top ]
- Posted by: Jean-Pol Landrain
- Posted on: February 21 2005 06:30 EST
- in response to Nuno Teixeira
"but as long as most developers find some of these features useful and that backward compatibility is preserved"
Sorry, but after five years in Java, I still don't understand why backward compatibility is so crucial. I've never really needed it in my work. Moreover, I have the feeling that backward compatibility is a slow down in the development of the language: all the bright new language constructs introduced in J2SE 5.0 could probably have been implemented in a mcuh better way by throwing the backward compatibility out.