Community
Participate
Working Groups
Add early support for J2SE 1.5 features. The next feature release of J2SE is version 1.5 ("Tiger"), targeted to ship in the first half of 2004. While the contents of this release are still under discussion (JSR-176), this release is expected to contain extensions to the Java language, including generic types (JSR-014), enumerations, autoboxing, enhanced for loops, static imports (all JSR-201), metadata facility (JSR-175), and compiler APIs (JSR-199). Supporting these new language and compiler features will require major changes to the Eclipse Java compiler, JDT Core APIs, and JDT UI. Although Eclipse 3.0 will likely ship before J2SE 1.5 does, Eclipse should contain early support for J2SE 1.5 features wherever possible [JDT Core, JDT UI, JDT Debug] [Theme: J2SE 15. support]
*** Bug 37725 has been marked as a duplicate of this bug. ***
*** Bug 20805 has been marked as a duplicate of this bug. ***
I hope generics support can (and will) be implemented before other features, since it does not require to have 1.5 VM to run the code.
Please check bug #36142 , it seems that somebody has already started early implementation of generics. It would be probably good to mark this bug as 'depends on' #36142.
Bug 36142 describes changes to the DOM AST API, not the compiler internal ASTs. The compiler side is the core piece to migrate before anything. We will likely investigate some 1.5 support during 3.0 M5. We have a 1.5 grammar already which we can feed the parser generator we use (JikesPG). The difficulty is then that all our APIs and services should also support 1.5 (think codeassist, search, etc...). This is more challenging than just providing a compiler tool (which seems already quite tricky to achieve).
Thought I had already commented on this bug... Anyway, if there is no possibility to generate <1.5 compatible bytecode with 1.5 source with common java compilers (Sun/Ibm) (supposing no 1.5 specific libraries are used, just generic types), this feature will not be widely used until everyone has switched to 1.5 JREs, which will only occur in many years... Sun is already blocking with the assert keyword in 1.4, which does not permit to generate <1.4 bytecode even if it is the only 1.4 extension used, and I'm not sure this will change with 1.5... For more info, I posted the following on jdt newsgroup http://dev.eclipse.org/newslists/news.eclipse.tools.jdt/msg04204.html (but maybe it was a bit long... The 1.5 related part is at the end) Do some people have ideas how such things will be supported in the future JVMs/compilers ? I'm not following Sun newsgroups since their web interface is quite painful... Thanks --Steve
Attaching Eric's newsgroup post. My issue is very simple, And I do not yet understand why it has not been solved by JVM vendors (or designed like that at the beginning) Sorry it is pure java question only loosely related to Eclipse (I'll talk about it), but I would like to have your opinion on it. I have used asserts for years, and I could never write anymore a line of code without adding asserts in it. When developping, a good assert can save hours of debugging, either to you or to the people who use your code. I was very glad when the assert keyword appeared in java 1.4, and started using it extensively, and the benefit was immediate compared to the old java assert mechanism using classes. But.... I discovered that javac (at least Sun 1.4.x) was not able to generate 1.3 compliant code when the source contains assert keywords ! It just means that if you want your applications to work on 1.3 you cannot benefit of this 1.4 feature, even only during development ? Obviously this is a huge brake for code quality (IMHA), because not having access to the assert KW either leads to: - unasserted code - using old asserts, which is painful, so people tend not to write assertion code, which leads to the same result of unasserted code Generally the customers run the applications in unasserted mode, and would run them in asserted mode when there is an issue and the support requires them to do so in order to help the diagnostic. But for the reasons described previously, the java code tends to be unasserted, so no customer support will ask a customer to run in -ea mode and send back the result, because it wouldn't provide any additional info. And even too many developpers do not write assertion code, because they either are not used to it, or because they must generate 1.3 or even less compliant code. So why don't we have the possibility to do $ javac -source 1.4 -target 1.3 .... which would simply skip the generation of the assertion code ? Is there any compiler which allows that ? What do eclipse jdt folks think of that ? What is the status of the eclipse compiler concerning that ? In the old days of C/C++ we just provided macros and did what we wanted with them. They could generate no code in release, stop immediately the execution of the program in development mode before all got too corrupted, and in checked builds it could log information in a valuable file which could be redirected to the support and development teams for further investigation. I don't see any possibility in Java to do that yet. Providing such a feature (in at least a few compilers like IBM's and Sun's) would greatly improve the quality of most Java products, be they open-source or commercial. For example in eclipse: - Lots of cleanings (I count at least around 6-8 different assertion exception classes) - Running faster (e.g. I don't want my development workbench running assert) - Centralized way to select which packages/classes can assert when you develop, instead of trapping on exceptions you know no final user would see. Concerning the future, I'm really eager not only to try but to work daily with an 1.5 compiler, mostly for the typed containers/templates/whatever_they_will_be_named. But I am also really frightened that code using them could only work on an 1.5 jvm, whereas basically what you would want is : - to have your code work internally with typed stuff like List[MyClass], because it avoids thousands of errors which can only be detected at runtime and makes the code more readable/robust/maintainable - to have your 1.5 code cooperate with older code, e.g. - you could pass a typed list to <1.5 bytecode and it would work - you could cast an old list into a typed one, (but it could throw exception immediately or later if badly cast, ...) - to have your 1.5 source compiled as 1.x code, with all typed stuff becoming untyped and additional casts added automatically by the compiler - to have the compiler generate warnings/errors if you use new 1.5 features for which there is no emulation available in older jvms, like added packages) I know that the early support for 1.5 is a big task in Eclipse, but not being able to do with 1.5 what I listed before would severely reduces the need for most developpers/projects/companies of the 1.5 features if they have to wait for all their users to have adopted an 1.5 jvm... Which is likely not to happen before years ! I'm sorry this post is becoming quite long, and I'll stop it here. Maybe someone will throw light on these Java issues for me.
That was a great post, sorry I missed it back then (was away). The important fact on the language front to understand is that Sun has a monopoly on the language and there is very little we can alter it without losing the 100% compatible sticker. By allowing some assertions to be compiled for 1.3 targets would likely burn some of the compliance tests. Note though that some legacy code is using identifiers 'assert' which is the reason why they wanted to still honor it in 1.3 mode.
I don't see 1.5 support to be any different to 1.4 with respect to requirements for 1.5 runtime.
I really liked Eclipse/JDT for providing a way to use assert (that is source compatiblity = 1.4, assert = keyword) in a way that you could still generate 1.3 compatible code (with emulated asserts). It's a pitty that this feature was removed (it is, isn't it?). Actually, I don't care whether the compiler has a "100% compatibility sticker" or not if that only means I get the same problems with Eclipse/JDT as with javac and have the same stupid restrictions. I'd start using 1.5 style generics, for-loops and - most important - auto boxing and varargs parameters NOW if Eclipse would support that and could still generate class files compatible with JDK 1.3 and 1.4. For me, those features a nice syntactic extensions, but they could be dealt with on the source level only. If generics and friends require a 1.5 class file compatibility, it would take a long time until you could use them in projects because too often, old JDKs are required for deployment.
We never allowed to use assertions in 1.3 mode.
I could swear that worked once but I will believe you :)
Then it would have been a transient bug <g>
The assertion feature cannot workm in 1.3 mode, because the exception that needs to be thrown if the assertion failed is only defined in the 1.4 libraries.
I fixed the assert issue through Ant: write a task that copies all your sources to a tempo directory, but using a filter that removes all assert statements, then compile it with compatibility set to 1.3 or even 1.1. It's a rough solution: Ant doesn't offer a filter that's good for this job, so I'm forced to use coding conventions like this: assert "F".equalsIgnoreCase(val) || "0".equals(val): /*assert*/ "Table must use T/F or 1/0 for booleans, found: " + val; So my Ant task goes like that, <copy todir="${java.io.tmpdir}/build" filtering="true"> <filterchain> <tabstospaces tablength="1"/> <striplinecomments> <!-- Supports up to 5 levels of indentation --> <comment value="assert"/> <comment value="/*assert*/"/> <comment value=" assert"/> <comment value=" /*assert*/"/> <comment value=" assert"/> <comment value=" /*assert*/"/> <comment value=" assert"/> <comment value=" /*assert*/"/> <comment value=" assert"/> <comment value=" /*assert*/"/> <comment value=" assert"/> <comment value=" /*assert*/"/> </striplinecomments> </filterchain> <fileset.../> </copy> I'm not an expert in Ant so perhaps this could be made less ugly, but does the job for components that must be used by projects restricted to <1.4 JVMs. Eclipse would do a great service if it had a compiler option to ignore the assert statements automatically, when targeting JDKs under 1.3. I think it was a big mistake of Sun not to provide such option in javac; otherwise, much more people would be using asserts since long time... Asserts depend on new methods in reflection classes which cannot be replaced, so this feature cannot be pushed through JDK1.3'S throat, but most new language stuff in Tiger is only syntax sugar (source-to-bytecode transformation) or depends on new classes that *can* be installed in older JDKs' bootclasspath (see Sun's early access 1.5 javac). So I believe that early support in IDEs like Eclipse is CRITICAL to the adoption of Tiger's language enhancements, as developers will be able to use these and still target at least JDK 1.4.
*** Bug 47159 has been marked as a duplicate of this bug. ***
To the eclipse people intressted in assert statement for compilation target < 1.4, please read: https://bugs.eclipse.org/bugs/show_bug.cgi?id=6327 Why I note that here? Simple: The referenced bug report reads like "nice to have" and this bug report reads like "not possible without loosing Java compatiblity sticker". Now my question: What is the real reason for the eclipse team not to compile assertions for target < 1.4?
I have M6 up and running with jdk1.5 but not able to debug code, because M6 cannot attach to debug process. Just running code works at least in very early experieces.
I am running M6 (Version: 3.0.0, Build id: 200312182000) on Windows XP using 1.5 as the VM for Eclipse (using the -vm parameter) and as the VM for my programs. I can debug everything.
what I wanted to know is how to write 1.5 compliant (generic) java code in m6. is it possible? is there some magical flag i can turn on to make it work?
Not yet, because there is no source or any other compliance flags for jdk 1.5 in java compiler settings. They should be added to compiler properties for jdk 1.5 support.
Until full and official support is added - you can try this small hack that uses "javac": http://www.genady.net/forum/viewforum.php?f=6 Genady
*** Bug 51149 has been marked as a duplicate of this bug. ***
*** Bug 51323 has been marked as a duplicate of this bug. ***
I would like to see support for the new features of JDK 1.5 too. But in my opinion the eclipse 3.0 release may be shipped without it, just for the case it would delay the estimated release date (around July if I remember correctly). I think an earlier release date of 3.0 is more important then JDK 1.5 (which is still beta). The features of JDK may be added in a 3.1 release of Eclipse. And also I wouldn't mind to use a milestone build of 3.1 to learn and train all the new features of the JDK 1.5. Since the milestone builds normaly are in a very good quality. So delay the features about JDK 1.5 if necessary and just introduce it in 3.1. I wouldn't mind that much. 3.0 brings enough features to satisfy me.
We (users of the base eclipse) do have a choice of upgrading to a milestone build. But many, many others don't (users of websphere ect) So to wait for 1.5 features for 3.1 will mean for large community that they can't use eclipse (3.0) with 1.5 for quite sometime. this will also really be bad press. And you have now quite a few (i included) who really want to play with all the new things. (it is my further, at least i hope so :)) But eclipse can't handle it yet. So i wait. But i do think if for example IntelliJ, netbeans or Jbuilder will have 1.5 support build in much sooner then eclipse. People with switch just for trying 1.5 out. I admin that for most of those 3 it is much easier to do. Just code editor changes not compiler (as far as i know)
I believe that if eclipse does not support JDK 1.5 very soon it may lose large part of its user base to netbeans or CodeGuide which already supports JDK 1.5 in its editor. The plugin I wrote is hardly a solution, because it seems almost impossible to integrate it into existing JDT infrastructure. As to community contribution, it is hardly possible, because it is quite a large project, and the compiler code (the last time I checked) is very hard to understand or extend, with very little documentation. For some reason it reminds me of VAJ which was an excellent tool, but was always a year behind with its JDK support. It may have served well IBM's enterprise business plans, but for simple project development it became "@deprecated" really fast.
Just to give you an update. We are working on the 1.5 support, but we are not only implementing a compiler, but all integrated tools for it as well. We may disclose some of the intermediate states, but we don't want to challenge 3.0. You may expect some patches to be available, once we reach some stable points, and this will be merged into the main development stream only then. When applying these patches, you will enable some 1.5 features, and any feedback on these will be important to us. So far, we currently have a 1.5 parser available, but we need to bring it up to speed with respect to syntax recovery requirements for all our tooling (code assist, code select, etc...). This is quite a bit of work, but we should be able to make some good progress, given we are closing on our 3.0 feature list on other fronts.
We will try to have our JDT Core API reflect 1.5 evolutions by the 3.0 release. This will mostly impact the DOM AST, the JavaModel, code assist and search. Gradually, implementations will be backing up these new APIs, but this will enable some tool makers to start investigating 1.5 support in parallel to us implementing our layer.
We have been great supporters of Eclipse over the years, mainly because of its openness and bleeding edge features. We were looking forward to generic support in 3.0 since M1 came out but could not wait any longer. I don't think the decision to wait until JDK 1.5 release version come out is a good idea. We are starting a new project which won't be finished year and a half from now and will undoubtedly use 1.5 as its runtime. BUT we are starting the development RIGHT NOW, and we need to choose an IDE RIGHT NOW that will carry us through. PLEASE, PLEASE do all you can to integrate 1.5 features as soon as possible. Put out a patch if possible. We are running out of time!!
*** Bug 52140 has been marked as a duplicate of this bug. ***
I would strongly urge the Eclipse developer team to put the highest priority on implementing JDK 1.5. Don't wait until 3.1! This is the only thing currently keeping me from using Eclipse--I've been using the generics prototype compilers from Sun for years now. From my personal perspective, if you don't have generics support, nothing else matters. I bet a lot of other people feel the same way, or will as soon as they try compilers that *do* support 1.5.
In my projects, I use many of the new APIs available in 1.5. Even if I didn't use new 1.5 specific syntax, it's not possible to use the new APIs since they use features such as covariant return types that Eclipse does not accept. While Eclipse is not entirely useless for 1.5 development (I use it now, it complains alot, but I get by), it's quite painful and slow to develop with, so *please* make available a useable snapshots of the Eclipse 3.0 1.5 branch ASAP :-)
I second the motion on fixing this ASAP--*before* 3.0 finalizes, if at all possible. I, for one, will be switching to NetBeans for the moment, since that's what it takes to do 1.5. Whether I come back to Eclipse or not depends whether you get the support in before I decide I like NetBeans better.
I agree with others that support for 1.5 language changes is very important. I know that my development team will switch back to using IntelliJ IDEA if Eclipse does not support the new language features by June/July (regardless of the final Sun general release date). Rather than just complain about the current state/plans, I would like to see if there's any way I can help. It's been mentioned that the core compiler can already be fed a 1.5 grammar, and that the problems involve all the other parts that need to work on the resulting structure. Can some of the core Eclipse developers divide up this work, and then farm out the development to a wider group?
Although the J2SE JDK Beta 1.5 has been out for a couple of weeks, the final version is still some months off. Eclipse JDT uses an incremental Java compiler as the basis for the extensive tool support Eclipse provides (Java model, code assist, refactoring, ASTs, etc.). The compiler changes required to support new 1.5 language features are extensive. Although the language features appear to have settled down, the relevant 1.5 JCKs are not yet available. So while Sun may have a Beta in the field, it's still an active target. We are actively working on adding 1.5 support to Eclipse 3.0. We plan on updating the JDT Core APIs to include support for 1.5 language features in advance of having the 1.5 compiler to back them up. This will allow tools to get ready to handle 1.5 constructs. The compiler implementation behind it will take longer. Since the compiler must continue to compile the 1.3 and 1.4 dialects of the Java language as well as the new 1.5, we need to be careful not to jeopardize our position. We expect to provide improved implementations as patchs as we reach stable intermediate states. Eclipse 3.0 and J2SE 1.5 are likely to ship at around the same time (June). Our plan item is not committed because (a) we do not yet know whether we can complete the work in time to include it with 3.0, and (b) we will ship Eclipse 3.0 without 1.5 support if necessary. In the meantime, if you're eager to develop J2SE 1.5 programs with Eclipse, do check out some of interim solutions developed by members of the Eclipse community, such as http://www.genady.net/forum/viewforum.php?f=6, and discussed extensively in the Eclipse newgroups.
On the debugger side, Java 1.5 applications can be launch in run and debug mode in Eclipse 3.0M7. The Java 1.5 debug protocol between the VM and the debugger is backward with tee 1.4 version, so the Eclipse Java debugger can be used to debug Java 1.5 applications, with some limitations. The 1.4 protocol is used to get the information from the VM, so the name of the Java elements is displayed in Java 1.4 format (i.e. a element of type Vector<String> is displayed as 'Vector'). The debugger is currently updated to implement the 1.5 debug spec, and will be released soon. When this new version will be released, the Java elements will be displayed in Java 1.5 format, when debugging Java 1.5 applications. Breakpoints can be a bit tricky to set. The AST parser is used to finad valid locations where to set breakpoints. If your Class/Method contains some 1.5 code the parser cannot handle nicely, it may be impossible to set the breakpoint exactly where you want. Method breakpoints and watchpoints cannot be set on elements with a 1.5-like signature. The plan is to update the location verifier when the new version of the AST is released. Basic evaluations in classes with not too much of the 1.5 features in their code (no 1.5-like type declaration, method signatures, ...) should work. The evaluation engine need the compiler to be able to parse the code and resolve the symbols to work correctly. No real work can be done before the compiler meet these requierements. What 1.5 features can and/or will be supported need to be determined. The bug report for the basic Java 1.5 support in the debugger is bug 49882.
What are actually the features from 1.5 that are wanted most. First there is a more extensive library (as ever). That should not need to pose a problem. The biggest problem are the language changes. To sum them up: -Autoboxing -Enhanced for Loop -Generics -Metadata -Static import -Typesafe Enums -Varargs Not all of these changes are equally needed or equally complex. For example the metadata facility can be "handled" by optionally ignoring the metadata completely. Static imports should probably be straightforward. What I think we want is make some order of complexity and importance of these features and create patches with partial support. For me generics are most important (allthough they are probably most complex), after that enums, followed by the enhanced for loop. All these features actually produce class code that will run on an 1.4 jvm and could be enabled in some "experimental" mode. This would indeed require people to take advantage of class library changes to still use 1.5 (or the preview collections change), but could be a way to have people work with 1.5 and get the bugs out of it.
I've the same feeling as many here already expressed. We're all waiting too many years for Sun to provide the syntax enhancement. Now that the beta is available, we'd like to start using it NOW for future project. The beta feels quite stable and it's better IMHO to start now with a beta then to loose the enhancement for yet another project. I know, while I consider Eclipse/JDT the best free Java IDE right now, I'd probably switch to any other decent IDE that gives me complete JDK 1.5 support earlier. Unfortunately, IDEA doesn't support all 1.5 enhancements yet, too. If I should prioritize items, I'd come up with this list: 1) Support developing against 1.5 rt.jar, that is fix the covariant problems that for example cause a syntax error if you use StringBuffer#append(char) in your code. Support debugging with 1.5. 2) Support the new for-loop syntax. 3) Support autoboxing and varargs. 4) Support generics (4a accept them as valid syntax, 4b provide code completion that can deal with generics types (as IDEA can)) 5) Support enum and static imports 6) Support @metadata At least item #1 should be part of 3.0. I'd really love to see #2, #3 and #4a supported in 3.0, too. #4b might be tricky and #5 propably requires a lot of changes in jdt ui. As I don't see those things than important, I could wait for 3.1.
Re: comment#35 Helping is a good way to speed up the delivery of 1.5 support... as someone observed earlier on, the compiler internals are not well documented (these are not API by any mean), so it may be quite challenging to get started. But anyway, any help is welcome. I know someone offered to look at autoboxing. One area where the community could help still is testing. I mean writing some JUnit test suites, along the line of our compiler tests (see project org.eclipse.jdt.core.tests.compiler). It is one thing to upgrade our tooling, but it is another one to make it product quality. Test suites are key to achieve this. If anyone wanted to jump into it, it would be great for us; as we have no official test suites for it so far. This being said, we have currently a 1.5 grammar and parser, but still not an entire compiler (no name resolution, no flow analysis, no code gen - name resolution is likely the hardest). Re: comment#38. I also agree that generics are central to 1.5; and if only one feature should be shooted for, this is it. Now do everybody agree, or is there something simple (e.g. enhanced for loop) we should provide earlier to make people happy ? Re: comment#39 (1). I will release a fix for bug 51353, which will let our 1.4 compiler recognize 1.5 synthetics (numerous 1.5 bridge methods are now getting in our way when targeting 1.5 libs). This will go in our next integration delivery (no need to wait for a full 1.5 story).
I think each dev has differnt views about whats important for me #1 metadata (as an experienced c# programmer I really miss it) #2 enums #3 generics
Here is my take on prioritizing. Enhanced for loop - every developer will be probably using it several times a day. Makes program easier to write, read, and maintain. Probably not hard to implement. GIVE IT TO US NOW :) Static import - no time saving at all compared to the alternative using interface. Irelevant. Typesafe enums - one doesn't write new enums that often so even though they are easier to write and read than the alternative pattern, they are just not used as often as loops. I would say low priority. varargs - rarely used, alternative with the array passing works. Low. Autoboxing,Generics,Metadata are obviously very very (very, very...) important for all of us and obviously not easy to implement. Yet, looking at other eclipse subprojects one can see people wasting their ti... um, "working" on such important things like rounded tabs :). Well try making a survey and see if your customers are more interested in rounded tabs or, say, generics and see what they say. Cheers.
Is there any non-marketing statistic (or at least personal experience) about the speed and productivity gain by using the 1.5 features available?. I am really mad about 1.5 like everyone else I guess (just want to hold it in my hands to use it right out of the box). But look at autoboxing (do we really need this?) or generics? Whats the use of generics? Well sure it would be ease programmers life. I love generics since I 've used C++ for couple of years and it was one of the most missed features of Java for decades. And after hearing it will be introduced into JDK 1.5, I jumped in squares (well that was probably one year ago). But what's the objective gain? The feeling we have it now? I didn't used generics for years since Java simple doesn't offer it. And to sum it up, I won't die if I don't use them within a couple of month. We all have strategies to avoid casting. Mostly I create a custom fascade(?) for lists doing all the casting stuff for me. An overhead? Sure! Think about all the testcases... For every list that goes through more then one public method, a new fascade must be programmed and tested. Well copy and past saves a lot of time and it's a trivial work( by also using iterators only inside a method, I never,never share iterators). But I create no more then one list-fascade every week and it only takes me 10min to copy and past and test it. Sure I would use lists more often if I would have generics. But currently I am not up to. So what's the concrete gain (facts, opinions)? I think my gain would be a holy smile in my face and around 30minutes save per day. (for easier programming using all the other stuffs, without autoboxing and static import, which is dangerous in my opinion). Martin (Kersten)
Generics really should not be confused with C++ templates. Templates are way more general and powerful, and Java's implementation of generics is unfortunate to say the least. But anyway, this is all off topic really. Yes, it would be nice to have generics to play with, but as it is now Eclipse will probably not support them until at least March 2005.
Static import is a suspicious throw-back to #include from our homo-hableus roots (no, I didn't spell it right). Granted, what are generics but templates? However, generics are more than just syntatic sugar (as almost all of the other 1.5 enhancements are). Generics keep Java from drifting too far into the fully dynamic language mold. Sure, it sounds promiseing, but have any of you ever worked with Ruby? Great language. Lots of potential. But it's so dynamic that you have to try/catch an execption just to test for data type. I mean come on! But this is straying from the real issue of Eclipse implementing the 1.5 features. I think that you shouldn't even try to implement any features unless you're willing to implement all of them. Oh, and remember that the 1.5 beta is still only availible to JavaLobby members (:-J to all of you out there). So, it will probably be a feature that goes unused with many of the users. At the same time, N#$B#$@s has implemented the beta features. That's your number one competitor in the open source world. As such, if they support it, and you don't, you'll have people switching or even missing the mark altogether. Oh, just a little survey here: How many of you actually care about the enhanced for loop? I think the old one works just fine. In fact, I think that in straying from it, we loose yet another peace of Java's simple elegance.
beta 1 is available for public donwload from sun site now (about a month) real type safe enums are long overdue metadata is by far the most important thing in 1.5, you just dont realize it yet because you have never used it. C# has it and its incredibly useful for people trying to build pluggable systems, etc. For example it lets put the hibernate mapping instructions in the java source code not in an xml file somewhere. No more xdoclet junk, you can define whatever tags you like, the compiler understands it and its readable at run time. look for @ejb , @hibernate, @jdo ,...
In response to Daniel Spiewak (#45): You have some factual errors in your entry. First, The J2SE 1.5 Beta has been officially released to the public by Sun. The J2SE 1.5 Alpha (which was without documentation) was the 'Javalobby-only' release. Second, Netbeans doesn't really support the Java 1.5 features any more than Eclipse (not much anyway). It can compile the new features, but so can the Genady plugin discussed elsewhere. However, Intellij IDEA 4.0 and CodeGuide have some support implemented already. I wont bite on the comparison of Generics to Templates ;). In anycase, I digress. I wanted to put my vote in for this item, and put forth my ordering of importance: #1 Generics #2 Enums #3 Metadata (I see metadata being easier to support from a plugin perspective?) Thanks for all your hard work; your progress on Eclipse never ceases to amaze me.
Spiewak asks who cares about the enhanced for loop: I, for one, do... He says he likes the old one. Well, the old one isn't going away, but we're getting a new, more *elegant* one that is far easier to read and less prone to errors. Call it (and other 1.5 features) "syntactic sugar" if you like, but it could be argued that everything above machine code is syntactic sugar to some degree. It think it is very valuable to let the compiler do more work for us, so we can focus less on machine details and more on solving the users' problems. That's how software tools evolve. Also, why take an all-or-nothing approach to 1.5? If some of it can be supported sooner relatively easily, let's do it! My preferences/priorities: (1) generics (2) enhanced for (3) autoboxing (4) enums
Here is some update. We are making progress in the 1.5 stream, focusing on generics. Our support is coming along gradually, and we are now able to compile the following executable into something which a 1.5 VM can run <g>. public class X <T extends String> { T foo(T t) { return t; } public static void main(String[] args) { String s = new X<String>().foo("SUCCESS"); System.out.println(s); } void bar(X<T> t) { } } Don't get your hopes to high yet. There is still a lot of work ahead of us, but this is just to show progress. In particular, interactions with innerclasses are not yet supported, neither are fields, generic methods or wildcards. But we will get there, don't worry.
String is final. So does <T extends String> make sense?
It is legite code, though as you mentionned it is not the most interesting scenario where you would use generics <g>.
I just released the basic support for Java 1.5 in the debugger. See bug 49882 for more detail.
The reasoning behind the 'all or nothing' approach is simply this: we don't want to get confused and buggy code. For instance, at the moment genarics are partially supported by the compiler in the works. Can you immagine what would happen if that were released into Eclipse? We would start writing code with partial support for genarics that might break our code later. Also, if we do an early release like that, we'll confuse people who are just figuring out some of these concepts (like myself). I'm not familier with the concept of genarics whatsoever. If I were handed a copy of Eclipse with incomplete support for the feature, then I'd get a strange idea of what genarics are, costing my dozens of hours later on as I have to re-learn what I already thought I knew. Not a pleasant process at all. My point with the new for loop is that if no one is using it (I probably won't), then it's just a waste of Sun's time. Of course, that's not really a debatable issue now, so we can just drop it. Related to the developement: The absolute most important feature to me in the 1.5 if autoboxing. If we must release step by step, then I'd prefer that to be a priority in the release schedual.
Please re-read comment #28 and comment #36. We are NOT considering releasing the 1.5 branch intermediate evolution to Eclipse main stream, and will only make it available in early preview as soon as it matures enough for clients to use our IDE and/or investigate building tools for it. If you want to wait until ALL is available, then you'll simply need to waiter longer than others who want to pioneer and help us to get the bugs out.
Seriously, you guys are changing IDE just because eclipse doesn't support JDK 1.5 yet? I think there's the principle of scarcity at work here ("We don't have it so we really really really want it"). I've been using eclipse since before 1.0, and I'm so productive in it that I won't want to change to any other IDE and relearning it just for some syntactic sugar you can't probably use yet in real world applications. I also find it scary that some of the guys here are starting a project based on 1.5, which is still in beta 1. If I were a customer, I surely wouldn't want my software to be developed on 1.5 and released to me at the same time as the J2SE version itself is released. But I don't know. Maybe they're developing open source software. Or maybe it's an internal product. Come on, guys, NONE of the J2SE 1.5 enhancements is an "absolutely, absolutely important" thing. People have been developing and delivering solid applications in Java for almost a decade without autoboxing. You guys aren't gonna half your development time just because you have autoboxing. You won't get half as many bugs just because you have generics (in all likelihood, clueless developers toying around with generics will ADD the number of bugs you have). Surely it feels good, playing around and writing code in the new syntax is cool. But "absolutely, absolutely important"? Nah. I'd rather have a 3.0 eclipse that is absolutely, absolutely stable, reliable, with the default plugins all working correctly, and, if possible with this dang bug #9355 fixed (it's been YEARS already). Even if it means that it doesn't support 1.5 completely. Bring on the flamethrower...
1. Like it or not, 1.5 is a giant leap for Java (the next version will probably be one more, although maybe on a smaller scale) 2. "Generics" are not "syntactic sugar", neither "enhanced for". These are backed by code (i.e. new classes and interfaces) and can positively affect your code 3. Some 1.5 features may have important implications on design (I haven't had time to investigate this, but I read somewhere that class factories are prime candidates, as well as a couple of other common constructs) 4. It's not too early to start support for 1.5 5. Plenty of people are _very_ interested on what 1.5 has to offer. The IDE that supports as much as possible as soon as possible will have a definite advantage. 6. I'm all for "get 3.0 into release mode first" too. Although Eclipse is a standout among Java IDEs, it'll hurt if another IDE gets good 1.5 support earlier. Sorry for the 2c, but...
Sure, the language change quite a bit with 1.5 (how I'm glad I didn't upgrade my SCJP to 1.4--I'll just shoot for 1.5 when it's out). I disagree with you about enhanced for loop not being syntactic sugar. It just lets you type less code for the same thing. Generics... well that depends on one's interpretation of syntactic sugar :) I agree with you that it can positively affect your code... or negatively. It really depends on the developer. Operator overloading can positively affect your code... or negatively. But let's not go into that. I agree with you on your point 3, that it may have important implications on design. When you have generics, suddenly new design possibilities open up. However, I'm coming from the perspective of someone who's already had a huge existing code base, and in the middle of migrating to 1.4 now. (That's why I can't believe my eyes when I saw some guys already starting a project on 1.5. It's like, man! Who are their clients? You mean their clients will be kind and benevolent and understanding when there's a showstopper due to a bug in J2SE 1.5? Cool! Can I get one of those clients too?). Of course it is never too early to add support for 1.5. Hey, I'm all for it. Although I won't be using it for my work, I'd love to play around with 1.5 at home too. Hey, don't get me wrong. I am all for 1.5. If eclipse can support 1.5 by the time 3.0 is released, I'll be ABSOLUTELY ecstatic. But I agree with Philippe Mulet's priorities. What good would it be for eclipse to support 1.5 fully, if it is unstable or buggy? If it is an either/or, then I'm all for stability and the minimum number of bugs. Like this bug #9355 for example. It's been TWO years, and I believe (maybe misguidedly) that it is simpler to fix than adding J2SE 1.5 features, and other IDEs (VS.NET or jEdit) have had it for years as well, yet...
good comments...regarding bug #9355: the Eclipse text team is working on folding and you can track the progress in the status reports posted to eclipse- dev.
#bug 9355 must not be very important features. First it has not been fixed for years, yet more people still sign up to Eclipse. On the other hand, if people are willing to switch to new IDE because JDK 1.5 is not supported. It shows you how important JDK 1.5 is. Right there it tells you the order of the priority is. For me, If CodeGuide has better CVS or Subversion support, I don't mind paying $299 to switch. The productivity gain, or additional compile time-validation in JDK 1.5 worths the $299.
Some update from the compiler front. We have made good progress on the 1.5 stream, and are now able to: - disable 1.5 constructs when source level < 1.5 (sounds simple, but tricky when it comes to diagnosing problems in incorrect code, where you don't want to reveal 1.5 suggestions). - foreach statement support array collections - resolve generic type hierarchies, resolve generic type signatures - substitute parameterized types - combine generics and innerclasses (inner-emulation) - generate code sequence for additional casts - support for raw types, produce unsafe type operation warnings - produce all classfile attributes and signatures We have written some test suite for 1.5 features, please feel free to contribute to it (interact with us on jdt-core-dev mailing list to get going). Areas which need some more work: - cast/instanceof operations - generic binaries support (compile against generic libraries) - member types of generic types - generic method/field (with type parameters) - wildcards - covariance - foreach Iterable - other 1.5 features: autoboxing, annotations, enumerations, ... And these are only compiler topics, we still have to leverage all our tools to 1.5 awareness, think of codeassist, search, refactoring, etc... but we will gradually get there, don't worry. Remember that the official 1.5 fcs got postponed...
Actually, I should have written that the 1.5 fcs isn't scheduled before 2004Q3, see http://www.cs.colorado.edu/events/colloquia/docs/tiger.pdf#ggviewer-offsite- nav-12464208. Until fcs is out and official specs and compliance kits are available, we can't consider to be done, as we are only looking at a moving target.
Re-reading comment #61, I still haven't quite clarified my thoughts. Here is another take. I wanted to write in comment #60, that we had to be cautious about investing all resources in 1.5 effort, as 1.5 *may get* postponed, as no official date is out. The only information is Q3, which is still pretty vague. Anyway, we still have time ahead of us, and a 3.0 release to go in between, which we don't want to jeopardize.
Re <a href="#59">59</a>, <a href="#60">60</a>, & <a href="#61">61</a> ;) - Thanks for the update Phillipe; I appreciate you keeping everyone informed of your progress on the 1.5 front. In regards to the work that is becoming stable, will there be any technology preview patches that daring Eclipse users can sneak out of incubation and install on their environments? I'm aware that there a lot of layers of functionality between the compiler and the user, but I was just curious if you foresaw any opportunities to expose some functionality early in special downloads. Also, I'm aware that your efforts must be stable in many respects before a lot of the other layers (such as JDT UI work) can proceed full force. However, regarding items that probably have a smaller likelihood to change much if at all until final 1.5 release (such as the foreach loop construct), do you think that the Eclipse developers will be able to find synergies to surface these items and potentially some limited support at higher levels? Again, thanks for keeping us informed!
We want to post previews as soon as we reach some decent state. We don't want to waste your enthusiasm with a poor delivery <g>. And it will likely not have entire tooling support as too early to provide. This preview will then be a basis for other JDT players to evolve and gradually surface more features. We are still thinking whether we should provide a common bundle or separate pieces, but once we get there, this will be clarified.
Some more progress. We now have support for: - generic binaries support (compile against generic libraries) - wildcards - foreach (array & Iterable) - syntax recovery for type parameters - partial implementation of DOM AST for 1.5 FYI - first run of jck1.5 gives us a 95.5% compliance level, though we are missing lots of 1.5 features still. This means we will need to test it ourselves...
FYI - I just posted this to the mailing list: ================================================= Dear 1.5 fans, We just posted a snapshot of our current 1.5 effort (mostly compiler and generics) on the JDT Core website update section. This effort is named "Cheetah" and is still in its kitten stage; remember: it is *NOT* going to be delivered as part of Eclipse 3.0. We used an update site so as to ease deliveries for early adopters, as down the road it may comprise more JDT plug-ins as they convert to 1.5 branch. Please find more info at: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core- home/r3.0/main.html#updates If you find issues with it (and yes, you will <g>), then please enter a bug report against JDT Core, where you prefix the problem title with "[1.5]" so we can easily identify these issues; and please also mention the version of the Cheetah you are riding (see Eclipse help about plug-in details: e.g. 3.0.0.cheetah01). Remember this is just a snapshot of a very very early stage, The JDT Core team
Philippe, do you know if there's been a working win32 Eclipse build that can be used to test Cheetah? The page your comment points to recommends build R3.0(I20040407) and better (which means it's after the 3.0M8 milestone) - but there doesn't seem to have been a win32 build that's passed the testing process since then. I have tried a few of the integration builds, but got 'can not create view' errors going to the Java Browsing perspective.
This is indeed an issue, as stable builds are pretty rare these days. I am using I20040413, and finds it survivable; but I am not using the Java browsing perspective. I only use the standard Java perspective.
Dear 1.5 fans, The Cheetah is now able to digest generic methods and perform type inference. It also recognizes the Object.getClass() method and perform adequate substitutions (see 57784). Additionally, the new Cheetah does address the following defects: 58715 [1.5] The return type is incompatible 58631 [1.5] Cycle in hierarchy no longer detected 57784 [1.5] Object.getClass() need to be treated special ? 57784 [1.5] Errors using Arrays.asList(T []) 58461 [1.5] java.lang.VerifyError from enhanced for loop 53036 Incorrect highlighting for type problem in qualified type name Please retrieve Cheetah03 from our update site, and find more info at: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core- home/r3.0/main.html#updates Several people have reported installation issues. These are bugs in Eclipse itself. As a workaround, when installing the Cheetah, the platform will usually crash during restart; simply exit and restart once more. It should work ok from thereon, don't try to do anything before you do so. As usual, if you find issues with it (and yes, you will <g>), then please enter a bug report against JDT Core, where you prefix the problem title with "[1.5]" so we can easily identify these issues; and please also mention the version of the Cheetah you are riding (see Eclipse help about plug-in details: e.g. Eclipse Java Development Tools Core 3.0.0.cheetah03). We are now looking at covariance & bridge method support. The JDT Core team
Removing 3.0 milestone, since the Cheetah effort is scheduled for a later release.
Cheetah-05 is now available at usual update site.
Very cool. What are the key highlights for 05?
Dear 1.5 fans, Due to investment on release 3.0 front, the Cheetah development has slowed down a bit, but we are still making progress. In particular, cast/instanceof operations are now fully supported, along with extra diagnosis for unsafe type operations. Explicit parameterizations of message sends and constructor calls are also supported. Additionally, the new Cheetah does address the following defects: 62416 [1.5] An error has occurred when creating this (Java) editor 62292 [1.5] Missing receiver in parameterized message send 61507 [1.5] NPE in computeCompatibleMethod 60681 [1.5] Return type not strict enough 60563 [1.5] VerifyError when using generics and arrays 59258 Possibility to share compiler preferences for a shared project 60556 [1.5] Collections.unmodifiableList(List) 58978 [1.5] Generic method needs better error reporting 59983 [1.5] Internal compiler error 58903 [1.5] Implementing inherited generic methods Please retrieve Cheetah05 from our update site, and find more info at: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core- home/r3.0/main.html#updates A recent integration build is required, since the Cheetah has absorbed the latest API adjustments from Eclipse main stream. Therefore, Cheetah05 requires build I20040514 or better. The good new is that the installation issued have been addressed in this integration build, so installing the Cheetah should now be easy. As usual, if you find issues with it (and still, you should <g>), then please enter a bug report against JDT Core, where you prefix the problem title with "[1.5]" so we can easily identify these issues; and please also mention the version of the Cheetah you are riding (see Eclipse help about plug-in details: e.g. Eclipse Java Development Tools Core 3.0.0.cheetah05). The JDT Core team
Created attachment 10823 [details] stack trace after installing cheetah 0.5
Timo - pls enter a separate defect against Platform/Update with steps to reproduce.
Dear Eclipse developers, could you provide a zip file with sources for latest cheeta builds for these of us, who will debug and see really source with comments and not decompiled stuff? You can put a link to it next to the 'binary' link. I'm too lazy each time go to CVS repository (which web client on eclipse.org is seems to be broken for cheeta) and search where are some needed classes. This is also good for understanding/submitting bugs against latest jdt/cheeta builds. Keep a good work, Kind regards, Andrei
Andrei - Come on. Don't be so lazy and let the Eclipse team do the more important work of improving the compiler. Using CVS is not more work than unpacking a ZIP file.
Now we are at it. Could someone provide instructions on how to build it? I've fetched the sources for org.eclipse.jdt.core. However I haven't good a clue about what to do next. And i've been unable to find instructions anywhere
org.eclipse.jdt.core defines an Ant script for exporting deployable plugin: see org.eclipse.jdt.core\scripts\exportplugin.xml (use default target).
okay, ran the build script and it created plugin-export/org.eclipse.jdt.core_3.0.0 took the contents and replace eclipse/plugin/org.eclipse.jdt.core_3.0.0 with it. However I've been unable to choose any 1.5 settings just by doing this. Any magic twists?
Make sure you grabbed the contents of branch JDK_1_5 as instructed on: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core- home/r3.0/main.html#updates
I've created a mini tutorial that explains how to load cheetah from cvs and run it. Perhaps it's helpful. Please see http://www.3plus4.de/eclipse/cheetah.html
Dear 1.5 fans, The Cheetah strikes back, and is now based on the official Eclipse 3.0 release. Along with numerous bug fixes, we started enabling significant portions of JDT functionalities such as: - editor error reconciling, - outliner with labels showing parameterized/generic info, - code selection and hover, - code assist, - DOM AST, - JavaModel, - Java search, - type hierarchies, - attached sources for generic binaries Last run of latest JCK1.5 gave us a mark of 96.20% (408 failures to go). Remember that, for now, the Cheetah is still on diet, as it cannot yet digest covariance, autoboxing, enumerations, varargs or annotations. Please retrieve Cheetah06 from our update site, and find more info at: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core- home/r3.0/main.html#updates Note that the Cheetah download is bigger since it now comprises more components (JDTCore, JDTUI and JDTDebug). In the near future, the Cheetah will be directly hosted on official Eclipse.org update site. As usual, would you find issues, you should enter a bug report with a problem title starting with "[1.5]", so we can easily identify these issues. We will now consolidate the 1.5-aware tooling, and introduce new ingredients (like covariance) into the Cheetah diet. The JDT team ----------- PS: fix list for Cheetah06 is: 68837 [1.5] AST: Missing source range in parameterized type 68133 [1.5] VerifyError: Code segment has wrong length in class file 68863 Missing entry in local variable attribute 68440 [1.5] VerifyError with new for loop 64159 [1.5] call to addAll(Collection) incorrectly dissalowed 68602 [1.5] AST converter fails on local types 66424 [1.5] Collections in new style for loop 64417 [1.5] NPE in SourceTypeBinding.resolveTypesFor 68730 [1.5] No completion 65953 [1.5] Internal Compiler Error: ArrayIndexOutOfBoundsException 58470 [1.5] Source mapper fooled by generics 64336 [1.5] Signature does allow to create parameterized type signatures 68557 [1.5] ArrayIndexOutOfBoundsException in SourceTypeConverter 68006 [1.5] Invalid modifier after parse 65503 [1.5] "new" for-loop inside "old" for-loop gives error 65870 [1.5] AST creation fails when created with comments 64301 [1.5] Cast required where no cast should be required 63556 [1.5] Error when creating generic classes specializing distant parameters 63590 [1.5] Cheetah allows generic throws clause 63555 [1.5] Cannot put generic type fields inside static inner class 58722 [1.5] cannot extend interfaces
Given we merged all our 1.5 branches back to HEAD for development, and integration builds are starting again; we will no longer deliver separate patches as we used to for exposing 1.5 previews. If you want to exercise it a little bit, then please get the latest integration build.
This plan item is included on the initial draft 3.1 plan.
Jim writes in the 3.1 plan: 'Since the code for Eclipse 3.1 will be based on J2SE 1.4, we will be unable to "eat our own dog food" in regards to the new J2SE 5 features. This means we'll need to consider how best to achieve high quality.' J2SE 5.0 Schedule: ~October 2004 (beta 2 available now) Eclipse 3.1 Schedule: ~June 2005 If 3.1 is going to be that long coming out, would it be out of the question to base Eclipse 3.1 on J2SE 5.0 instead of J2SE 1.4.2? That would address the quality issue.
That looks impossible to me. Because it you do that then other platforms like the mac? will maybe out off luck. and there are companies with policies that they have to use a specific jre ect. Mostly they don't choose the latest and greatest.
Hopefully our 1.5 support should be ready much sooner than the final 3.1 release, and thus an intermediate milestone should expose it.
Anybody know the Mac schedule? Regarding corporate policies, you could use JDK5 and *only* run the Eclipse IDE with it, using JDK1.4 for everything else including the apps you are developing and deploying. You can even develop RCP apps against an Eclipse 3.0 + JDK1.4 target configuration if that's a consideration. JDK5 has some specific enhancements that would be beneficial to the development and running of Eclipse. Improved memory management is arguably the biggest one, but people can take advantage of that without Eclipse code changes. One that will effect Eclipse code is the new virtual machine tool interface (JMTI); that will have a huge impact on Debug Core and maybe other places. The sooner Eclipse developers can start coding to the new interfaces, the better shape support will be in. Another consideration is that if Eclipse 3.1 were to start requiring and using JDK5 now, all of us (developers and users) would have the opportunity to shake out bugs in the JDK that could be fixed before JDK5 FCS. After FCS, we'd have to wait until the next rev to get them fixed and who knows when that will be. References: http://java.sun.com/j2se/5.0/docs/relnotes/features.html#vm http://java.sun.com/j2se/5.0/docs/relnotes/features.html#tools
The Mac release of Java 1.5 is tied to the next version of OS X - 10.4 Tiger. According to the trade press and mac web sites, an early version of 1.5 was included on the OS X 10.4 preview discs distributed at Apple's developer conference a few weeks ago. The announced timetable for 10.4 is "first half of next year", whatever that means. It sure sounds like Java 1.5 won't be coming to the current OS X 10.3, but folks who have access to the preview builds of 10.4 should be able to try out Apples Java 1.5 support. Not sure how that would affect Eclipse 3.1.
Correct. At this point in time, all available knowledge to folks in the seed program says that Tiger (Java 1.5) is a Tiger (Mac OS X 10.4) feature; and that JDK 1.5 will not deploy on OS 10.3. - 10.3 initially shipped with installs of 1.3.1 and 1.4.1; currently supports 1.4.2_05. - 10.2 initially shipped with installs of 1.3.1; currently supports 1.4.1_01. - 10.1 only contains 1.3.1. Just as 1.4.2 was a 10.3 feature, 1.5 is a 10.4 one, and is tied to various changes to event loops, kernel changes, and system library updates.
Realizing we did not update this report in a while, here is some update about the 1.5 front. First, the Cheetah got merged into the 3.1 codebase in August. This means in order to experiment 1.5 coding, simply take a recent integration build from 3.1 stream (preferably milestone one). As of 3.1 M2, the changes to the Java tools to support J2SE 5.0 (aka 1.5) are proceeding nicely. The Eclipse Java compiler now handles generics, enhanced for loops, and hexadecimal floating point literals (at this point we're passing 96.8% of the JCK1.5 compliance tests). The other language additions - enumerations, annotations, static imports, varargs, autoboxing - make it past the parser, but are not yet being processed any deeper than that. Support for these other new language features will be introduced in future 3.1 milestones. Current estimates (still draft) for full JDT/Core support (i.e. compiler, search, codeassist, codeselect, formatting, model, dom ast). M3(nov05) - generics M4(dec17) - autoboxing, static imports M5(feb18) - varargs, enums M6(apr01) - annotations Note the compiler will always be ahead of the rest of the tooling, so it will be fully 1.5 enabled way before all tools have been leveraged (we expect at beginning of 2005).
In previous post: "preferably milestone one" referred to any milestone build, not just M1. Also, you may find visible progress on 1.5 in the "new and noteworthy" documentation attached to each milestone build: http://fullmoon.torolab.ibm.com/downloads/drops/S-3.1M2-200409240800/eclipse- news-M2.html
Is there are any chance to shift priority and have annotation support in the compiller at the earier time? There are number of posibilitier opened by the metadata facility and they can't be used with Eclipse without support in the compiller. One of the promising things is TestNG framework.
+1 to comment #94 from the Pollinate team
I think that enums should have a much higher priority - definitely higher than annotations. I think enums are the second most important feature after generics.
I vote for annotations. Annotations are an enabling technology, but enums are basically syntactic sugar. Early annotation support would enable early experimentation in clients that use the metadata.
FYI. Unfortunately support for annotations will require enum support, since enum is one of the allowed value types for annotations together with primitive types, String, Class, arrays and annotation.
+1 for doing annotations sooner. Other major IDE's has it, and it would help faster adoptions of annotations.
I would also like to cast a vote for placing annotations in a higher priority. JBoss is hoping to prototype an EJB3 development plugin for eclipse before the end of the year, and annotations are a must have.
I also vote for moving annotations towards the front of the list IMO the order of JDK5 lanugae features according to usefullness would be: generics enums annotations static imports autoboxing varargs The first three give a real leverage. The other are mostly syntactic sugar. The compiler is obviously more critical than the other layers. Processing annotations all the way to the class files will get you more early testers than flawless handling of generics in formatter, quick fix, refactoring etc.
The issue with formatter/quickfix etc. is that without (limited) support for generics, generics will make them fail (a bug). In any case the current generics support is also not flawless yet. Besides missing a big number of unchecked warnings that the sun compiler does generate I also found it to generate an unwaranted unchecked warning when creating a toArray handler for a custom collection I made. The main errors exist with unparameterised classes implementing a parameterised superclass. And failing to warn about some "broken" method signatures that do not "properly" override parent methods because of missing generics.
To stress the importance of annotations please see next feature request: https://bugs.eclipse.org/bugs/show_bug.cgi?id=75996 May be this does not fit for "early support for 1.5" but definitely worth discussing where it fits to. Comment and vote on it. Alex Pollinate Project.
*** Bug 76406 has been marked as a duplicate of this bug. ***
FYI - we have first cut of compiler support for: static imports, varargs, and enums (no recovery, no strong error detection) These are released in HEAD stream, and will thus appear in 3.1M3. We still need to work on autoboxing and annotations. Don't worry, we will not work on polishing existing features until we have some decent coverage of the missing ones.
Is there any way to get access to the progress of this bug without using the 3.1 milestone releases? I just checked out the third milestone and it looks great but unfortunately this is not an option for us since we use plug-ins which doesn't work with 3.1 yet and the plug-ins have not no plans to support 3.1 before it reaches RC state (always the same problem). I have tried the old cheetah implementation (which works with Eclipse 3.0) but this is too limited. We are currently working with a redesign of our product and we intend to use Java 5.0 to do this and if we can't use Eclipse we have to move to another IDE and I definitively don’t want that since I love Eclipse. Please make the progress available for 3.0.1.
"...but unfortunately this is not an option for us since we use plug-ins which doesn't work with 3.1 yet..." "...and if we can't use Eclipse we have to move to another IDE ..." Hmmm... Are you using *essential* plug-ins that work with 3.0.x _AND_ other IDE's, but not with 3.1M3? ;-)
Joakim, There are no plans to introduce massive changes into the 3.0.1 steam. All of the 1.5 work is going on in the 3.1 stream. You mention that using 3.1 milestone builds "is not an option for us since we use plug-ins which doesn't work with 3.1 yet." Legal 3.0 plug-in would work fine in 3.1 (pls report problems if you see otherwise). Is there something else stopping you from using the existing binary versions of those 3.0 plug-ins with your 3.1 development?
try one of eclipse own contributions: webtools. These things don't work right now (or the last one i tested) because they need plugin xxxxxx_3.0.0. But some plugins are now 3.1.0 This should really be handled better!!! If some plugin is asking for 3.0.0 then anything above it should just be fine.
Eyðun, I’m sorry that my comment was a bit strange. What I meant was that while Eclipse heavily relies on external plug-ins for tasks like web development for instance, other ide:s have a lot of these features built in. Take MyEclipse or IBM’s webtools contribution for instance, neither of these works in M3 (or M2). Since we want to have a descent ide for web development and use Java 1.5 at the same time I wanted to use the new features in Eclipse 3.0.1 and if this takes to long I’m afraid that we will look for alternatives. However I’m glad to hear that the plug-ins are supposed work and I hope that they will but right now they don’t. Check out MyEclipse for instance.
With a few changes, JDT/Core 3.1.0 should be able to perform on an Eclipse 3.0.1 platform, however this wouldn't provide latest UI enhancements wrt to 1.5 support (refactorings, quickfix, rendering). However, this would be close to the Cheetah spirit. Would this be an option if we revived the Cheetah once more ? (not to be part of an official 3.0.x delivery)
Having JDT/Core 5.0 support for 3.0.1 without having JDT/UI support will cause problems in all refactoring, source, quick assist and quick fix actions. Porting this back to 3.0.1 will not be an easy thing to do since we already started to use new platform API.
BTW, all future Webtools milestones are supposed to work with 3.1, according to the faq.
Joakim, I havn't tried to use WebTools on 3.1M3 yet - but I have just now switched to 3.1M3 from 3.0.1 - and I'm using MyEclipse... In which way does it not work for you? It seems to run ok for me. But then again - it has just been for the last 30 minuttes though... :-) I just pointed the the update manager to the extension location where I installed it under 3.0.1 and restarted eclipse.
Dear 1.5 fans, As a Xmas gift, we are pleased to deliver all J2SE 5.0 compiler support enabled. Forthcoming Eclipse 3.1M4 is going to include it. With this last round of additions (annotations and autoboxing),we reach 99.56% jck1.5 compliance; and is able to compile entire JDK 1.5 source libraries. There is still work to do to reduce the last 51 failures (out of 11331 tests), and we hope to achieve this during next milestone. The rest of JDT/Core services is also being leveraged, and while code formatter and DOM AST are 100% enabled, other tools are only delivering intermediate support for 1.5 features. We believe though that JavaModel, codeassist, codeselect and search are in a reasonable state at this point to enable developping 1.5 programs. Known issues on compiler front: - unsafe type (unchecked) warnings are not quite reliable yet - annotation circularities are not diagnosed - static import of method members is not working As usual, please keep reporting issues you find in latest, prefixing problem title with '[1.5]' for dragging attention.
I've problems to detect the status within this flat organization of this Issue. Thus I've created a Collection Issue ( Bug 80775 ). I've made 2 entries, but those must be completed to create the full dependency tree. This issue here has become very big - and worthfull comments/infromation gets lost. Possibly you should move your comments to the specific Issues once created.
As I said in my previous comment, supported features are all the ones which are part of J2SE 5.0, namely: - generics - enhanced for - autoboxing - covariance - enumeration - annotation
Comment 117: not all of those features were implemented fully. Please report the known issues within bugzilla, thus users hit on them when searching. I would like to use the issues within the tree: https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=80775 The tree does not reflect the real status, as it was obfuscated. As it seems that full implementation will take some more time, i've take the effort to ensure a consistent issue-tracking-system status: [GOVERNANCE] - Mr. Kent Johnson (IBM) Obfuscates Status and Relations of Issues http://www.eclipse.org/newsportal/article.php?id=220&group=eclipse.foundation
During the development of IBM products based on Eclipse and Java technology, we have run the Java compiler TCK suite using the Eclipse Platform 3.1 N20050225-0010 build and have verified that the Eclipse Java compiler has passed and is 1.5 compliant. Steve Wasleski IBM Rational
Considering compliance got achieved, as reported above. We will close this defect, and consider it fixed. Please log further issues as separate defects. Thanks to all for the huge feedback we received, it helped us greatly getting where we are now.
Verified in I20050330-0500
