Discussions

News: JDK 5 in Practice

  1. JDK 5 in Practice (24 messages)

    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

    Threaded Messages (24)

  2. Good Article![ Go to top ]

    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!
  3. Good Article![ Go to top ]

    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 :-)
  4. Good Article![ Go to top ]

    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.
  5. Printfriendly Link[ Go to top ]

    An application exception has occured: Value for parameter 'listener' in component Blog/printFriendly.link is null, and a non-null value is required.
  6. JDK 5 in Practice[ Go to top ]

    Just a note "about the author": Cedric is not anymore at BEA but at Google.
  7. typedef in java[ Go to top ]

    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?
  8. Awaiting Eclipse support...[ Go to top ]

    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.1M3
    As 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.
  9. Awaiting Eclipse support...[ Go to top ]

    Embrace IntelliJ Idea, its working *now*
  10. Awaiting Eclipse support...[ Go to top ]

    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.
  11. Awaiting Eclipse support...[ Go to top ]

    I do work on annotations more or less for 6 months now.
    Notepad-like IDE for six months is a pain, truely believe me ;-)
  12. Awaiting Eclipse support...[ Go to top ]

    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.
  13. When will app server vendors use 1.5[ Go to top ]

    Does anyone know the timeframe for when app server vendors will start using the 1.5 JVM?
  14. Drat...[ Go to top ]

    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
  15. JDK 5 in Practice[ Go to top ]

    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!
  16. JDK 5 in Practice[ Go to top ]

     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
  17. JDK 5 in Practice[ Go to top ]

    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?)
  18. JDK 5 in Practice[ Go to top ]

    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.
  19. JDK 5 in Practice- Kerberos[ Go to top ]

    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
  20. Don't Repeat Yourself[ Go to top ]

    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
  21. Don't Repeat Yourself[ Go to top ]

    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.
  22. Don't Repeat Yourself[ Go to top ]

    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.
  23. Wake up Cedric ;)[ Go to top ]

    ... 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)
  24. Wake up Cedric ;)[ Go to top ]

    ... 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
  25. Backward compatibility[ Go to top ]

    "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.