Java generics support in Eclipse V3.1

Discussions

News: Java generics support in Eclipse V3.1

  1. Java generics support in Eclipse V3.1 (9 messages)

    The generics support in the Java programming language is one of the most significant syntax change in its history. In his article, Neil Ford highlights how Eclipse has responded and adapted to the changes wrought by generics to the Java language. He demonstrates how to take full advantage of generics from within Eclipse. Generics are supported in the Quick Assist, the Quick Fix, refactoring, and project preferences. He then goes on to demonstrate a few of the subtle and more important aspects of generics.

    Is the current level of support for the new Java 5 language features good enough or is there still a long way to go for the IDE’s to catch up?

    Threaded Messages (9)

  2. Java generics support in Eclipse V3.1[ Go to top ]

    The level of support for new Java 5 language features has been good enough for quite some time in NetBeans...

    Eclipse will seemingly always lag on language feature releases since they feel the need to write their own compiler tooling.

    Perhaps when the JSR 199 stuff is integrated into JSE, Eclipse will drop their own compiler tooling?
  3. Jess, I think you just have no idea what Eclipse has its own compiler for. That implementation practically allows on-the fly incremental compilation with delays close to 10..20ms. Just think about it for a moment.

    It is also looks like features of the JackPot project that Sun talking about for several years but which nobody haven't seen yet, already provided by Eclipse platform.

    All in all I don't think it would take big effort to incorporate JSR-199 API into Eclipse toolset, which already showed quite flexibility on the projects like AspectJ that is extending jdt platform and compiller with new language grammar.
  4. Jess, I think you just have no idea what Eclipse has its own compiler for. That implementation practically allows on-the fly incremental compilation with delays close to 10..20ms. Just think about it for a moment.It is also looks like features of the JackPot project that Sun talking about for several years but which nobody haven't seen yet, already provided by Eclipse platform. All in all I don't think it would take big effort to incorporate JSR-199 API into Eclipse toolset, which already showed quite flexibility on the projects like AspectJ that is extending jdt platform and compiller with new language grammar.

    I'm not saying there are not reasons for it. However, the approach delays adoption of new language features. It also delayed support of Java 5 language features for other projects which have moved to JDT, e.g. Tomcat 5.5 (though in this case you could go back to javac via configuration if you needed Java 5 feature support).
  5. Java generics support in Eclipse V3.1[ Go to top ]

    Actually I think the compiler changes were the least part of it. A lot of work went into the new refactorings, completions, quick-fixes and so on that Generics enabled... and nobody really knew what refactorings etc would be useful until beta testers got their hands on early versions.

    Having said that, Eclipse was admittedly a little slow off the mark with the Java 5 support. Still, I hope and expect that Sun will not introduce any further changes in the Java language as significant as Generics for quite some time.
  6. computer science and the real world[ Go to top ]

    As an ex academic researcher I can appreciate exotic languages and features. However, there's a grey area between practical usefulness and theoretical soundness. Java Generics provides a nice mix of practical features and soundness but it doesn't go all the way. Some think that's a missed chance and maybe it is. However, generics as it is now is quite useful and practical.

    I've tried using generics in some project recently and I liked how much more clean my code becomes without all the useless casting. Eclipse helped me get used to the syntax by sugesting some fixes and autocompleting stuff. I'm sure there's some more advanced stuff waiting to be discovered with it but for day to day usage it's immediately useful like this.

    Ironically the problem people complain about most, the lack of proper generics in arrays, is such a problem because people are so used to arrays because of the casting problems you used to have when using collections. I use arrays as return types all the time for instance because returning a List of objects just isn't typesafe and causes typecasts in depending code.

    That's no longer an issue with generics, so you can use collections without losing typesafety. That, IMHO is a real improvement.
  7. http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid_1.html
  8. Java generics support in Eclipse V3.1[ Go to top ]

    Our team adopted Java 5.0 back in November 2004 and incrementally adopted the 3.1 milestone builds as they came out througout the first 6 months of this year. We found the product to be remarkably stable from an early stage, with few serious bugs.

    As the entire team was learning the Java 5 features, we started manually coding in generics (and enums, varargs, annotations etc). A few times we complained that autocompletion and refactoring would help, but the absence didn't stop us. When a new milestone came out our pairing sessions were really fun as we discovered new features appearing in the IDE.

    The real point of my post is to say that although 3.1 came out in June - we've been using Java 5 features for ages now and have 3 projects in production. It's a real credit to the Eclipse project that the quality of the builds was what it was. (Our experience with the Web Tools hasn't been nearly as smooth though).

    As for Generics - yeah sure they can be misused/abused like any language feature. How many reader's have seen abuses of java's reflection API's in regular application code for example?

    In my opinion, the number 1 productivity enhancement we got from Java 5 and Generics was the ability to extend the JMock library to create "Typesafe Mocks" which results in code like this:

    <code>
    public clas MyTest extends TypeSafeMockObjectTestCase

    private TypeSafeMock< MyInterface > mockInterface = typeSafeMock( MyInterface.class );

    mockInterface.registerMethod().doIt( "Value" );
    mockInterface.expectsLastRegisteredMethod( once() ) .withEqualArgumentsToRegistration()
    ...
    </code>

    In summary, we've got typesafe, generic mocking capability in our test code with full refactoring capabilities (no methods in Strings anymore).

    We couldn't/wouldn't go back!

    Cheers
    Jason King
  9. Java generics - compile time only[ Go to top ]

    In this interview: http://www.ondotnet.com/pub/a/dotnet/2005/10/17/interview-with-anders-hejlsberg.html

    Anders Hejlsberg - creator of csharp explains that dotnet generics are much better than java generics, because in dotnet you can use reflection with generics. In java you cannot, because generics in java are compile time only.
    All generics information is lost at runtime, so you cannot use reflection with it.

    Can anyone comment on that ?
  10. Not quite[ Go to top ]

    The parameterized type information is available via reflection. I believe that this is possible because the generic type information is stored as class file attributes on the declarations. Have a look at the new java.lang.reflect.Type interface. Also look at the same old Field and Method classes to see where generic information is being returned.

    It is true that the generics support is only "skin-deep" but some effort was made to expose it via reflection. The reflection support seems sufficient enought to allow libraries like Hibernate to determine actual collection types, etc at runtime.

    The fact that the information is available via reflection is not trivial. As I recall from early discussion, Sun made this judgment call to include reflection on generic types because it was the right thing to do going forward. I think this is what actually started the idea that introducing generics would require them to increase the class file version, thus making generics compiled code incompatible with earlier VMs. As I recall, the community was outraged at the time because the prototype generics compilers were able to work their magic without a new class file version and many considered reflection support to be optional. I'm personally glad Sun did include the reflection support, even though their implementation of it ended up being a breaking change.

    Also, let me say that I was using the Eclipse milestone releases from about November to do real work with Java 5/Generics. I have always been impressed with the quality of Eclipse milestone builds, and about the only time you will find me using an actual official release build is during the quiet period just after an official release (such as 3.0 or 3.1). As someone pointed out, the Eclipse team did not just release Eclipse as "Java 5 Ready" when they got syntax hilighting, code completion, and their compiler (which rocks btw) working for Generics/Annotations/Enums (which, as I recall was around the November timeframe -- even earlier if you downloaded the preview Java 5 JDT support for 3.0, which was available since before it was called "Java 5"). They took the extra time to make sure that all of these features had deep integration in refactoring, quick fixes, wizards, etc. These are the features that IMHO make Eclipse stand out from NetBeans, and I am glad that the Eclipse team took the time to do it right.