ack - thanks Nathan. Hopefully we can proceed further despite these bugs, and build up a local body of knowledge about what works and what doesn't (and all vote for our favourite Eclipse bug to be fixed).
Regards, Tim Nathan Beyer wrote: > +1 > > I'm for it, but we'll need to be careful as the Eclipse compiler isn't > perfect in regards to this functionality. For example, this bug [1] I ran > into with 3.2 that allowed me to do return type covariance when target 1.4 > was set. Not that these guys aren't doing a great job, but JLS3 added quite > a few complexities and it's only natural that there will be some bugs. > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=128560 > >> -----Original Message----- >> From: Tim Ellison [mailto:[EMAIL PROTECTED] >> Sent: Friday, March 17, 2006 4:35 AM >> To: harmony-dev >> Subject: [vote] Require compiler options that allow partial 5.0 language >> features >> >> As discussed on the list, there is a compiler option in the 5.0 >> compilers we use that allows source code containing a subset of Java 5.0 >> language features to be compiled into 1.4 compatible class files. >> >> Since this is quite a significant change I'd like to get a vote on >> whether the project should make this compiler option a necessity for our >> code. >> >> The positive outcome of this is that we can develop APIs that rely on >> those 5.0 language features, and run the resulting code on existing >> 1.4-compatible VMs. >> >> The downside is that we are using an undocumented compiler feature on >> the reference implementation (it is supported on the Eclipse compiler). >> >> [ ] +1 - Yes, change the build scripts to compile 5.0 code to 1.4 target >> [ ] 0 - I don't care >> [ ] -1 - No, don't change the compiler options (please state why) >> >> >> Regards, >> Tim >> >> -- >> >> Tim Ellison ([EMAIL PROTECTED]) >> IBM Java technology centre, UK. > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
