----- Original Message ----- > On Mon, Oct 15, 2012 at 12:05 AM, Andrew Hughes > <gnu.and...@redhat.com> wrote: > >> Fair enough. What needs to happen for us to move on to 1.7 and > >> eventually 1.8 which both have classfile format and language > >> changes? > > > > Even OpenJDK doesn't do this for all class files and 1.8 is not > > going to be > > released for nearly a year. > > > > The only one I see a point in is 1.8 when we start to implement > > code that uses > > lambdas. The rest don't give a significant advantage against > > preventing ease > > of building the code. > > One of the problems is that GNU Classpath needs 1.6 APIs and VM > features to run applications written in JRuby and Scala and I expect > them to start relying more on 1.7 features soon. > > So we're now in a situation where GNU Classpath still pretends to be > 1.5 (with additional APIs) but the VMs need to advertise 1.6 and 1.7 > support... >
Yes. But this has nothing to do with the bytecode format produced. That only matters if the bytecode for these APIs uses features of these new versions. What version is reported is up to the VM. I'd like VMs to start reporting 1.6, if not 1.7 TBH. There have been 1.6 APIs for a long time. That said, we could move to producing 1.6 bytecode after the next release. I'm planning to do a 0.99.1 release once I've got a few more bug fixes committed. > On Mon, Oct 15, 2012 at 12:05 AM, Andrew Hughes > <gnu.and...@redhat.com> wrote: > > As a prerequisite, gcj would still have to be able to build if > > these changes were > > integrated. It currently doesn't have a 1.7 compiler. That's > > something I'm looking into > > with getting support for the latest ecj into Classpath. > > That would be awesome. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
