You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2006/04/05 12:53:11 UTC
[classlib] Switching to a 5.0 compiler
A while ago we agreed to switch to a class library compilation story
that would allow us to use 1.5 Java syntax on a 1.4-compatible VM (i.e.
using syntax that is erased by the compiler).
Here's where I'm at...
Using the Sun compiler:
Specifying source=1.5 and target=1.4 (understandably) fails as an
invalid option set, but there is an undocumented and unmaintained option
that, AIUI, was introduced during the syntax transition to full 1.5
support. On Sun-based compilers we can specify source=1.5 target=jsr14
and get some support for erased 1.5 syntax.
Using the Eclipse compiler:
In the Eclipse JDT UI you *can* specify source=5.0 target=1.4 and I
successfully ran code written using generics on a 1.4 VM. However, the
Eclipse batch compiler does not allow this source=5.0 target=1.4
combination; and when I asked why the answer was that the UI usage is
wrong and will be fixed to prevent that combination.
Unless we void the warranty on the compiler by making non-API calls into
their code we cannot therefore use the Eclipse to do back-level
compilations.
Geir voted -1 to the proposal if it meant that we could only use one
compiler, so I have looked around thought a bit more about it ...
Using RetroWeaver:
Retroweaver (retroweaver.sourceforge.net) is a bytecode weaver that
takes 1.5 class files and modifies them to run on 1.4-compatible VMs.
It is BSD-licensed.
The weaver does a bit more than we actually want in that it not only
rewrites the class file format (to remove class literals, synthetic
access specifiers etc) but also replaces references to some runtime
dependencies (replaces StringBuilder with StringBuffer,
Float.valueOf(float), etc.)
I've had a brief exchange with Toby (the author) and he indicated that
it would be possible to make some mods to retroweaver to do the format
changes without the runtime changes. So using retroweaver in our build
process is a possible step.
Putting a v49 requirement on VMs:
Given that the changes in the class file format are relatively modest,
we could require that Harmony compatible VMs are able to consume 1.5
format class files, even if they do not support the full 5.0 APIs at
this point. We would provide 1.5 level class libraries in all places
except where it requires new VM APIs (reflect, concurrent, etc). This
is rather distasteful though since it means that we are 1.4++
Stay at 1.4 syntax until the VMs can do full-on 1.5 support
At some point we want the VMs to offer full 1.5 support so perhaps we
just wait for that day. That would leave some very tasty contributions
languishing in JIRA longer than we would like.
Comments?
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Switching to a 5.0 compiler
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/5/06, Etienne Gagnon <eg...@sablevm.org> wrote:
> I think that using Sun's javac and Eclipse with their undocumented and
> unsupported options during the "transition period" seems the cleanest
> strategy for both class library and VM maintenance. I see no trouble
> having such a dependency for a limited period of time (a few months).
+1. Anyway we will have VM with 1.5 support. We just need to wait for
a while, right? If we have simple workarround which solves the problem
for the moment why we should invent something else?
Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Switching to a 5.0 compiler
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> 2006/4/5, George Harley <ge...@googlemail.com>:
>> Hi,
>>
>> Using the Sun 5.0 javac with the "jsr14" target it is possible to do a
>> complete compile of the Harmony Java source and successfully run the
>> tests on the existing VME. That means we could add in more contributions
>> that depended on 5.0 language features being understood instead of
>> letting them queue up.
>>
>> So +1 from me for using the straightforward but undocumented "jsr14"
>> target as a purely temporary measure to keep things moving onwards.
>
> +1
Well you'll have to persuade Geir to remove his -1 for only working with
a single compiler first :-)
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Switching to a 5.0 compiler
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/4/5, George Harley <ge...@googlemail.com>:
> Hi,
>
> Using the Sun 5.0 javac with the "jsr14" target it is possible to do a
> complete compile of the Harmony Java source and successfully run the
> tests on the existing VME. That means we could add in more contributions
> that depended on 5.0 language features being understood instead of
> letting them queue up.
>
> So +1 from me for using the straightforward but undocumented "jsr14"
> target as a purely temporary measure to keep things moving onwards.
+1
Thanks,
Mikhail
>
> Best regards,
> George
>
>
> Etienne Gagnon wrote:
> > I think that using Sun's javac and Eclipse with their undocumented and
> > unsupported options during the "transition period" seems the cleanest
> > strategy for both class library and VM maintenance. I see no trouble
> > having such a dependency for a limited period of time (a few months).
> >
> > Etienne
> >
> > Geir Magnusson Jr wrote:
> >
> >> Tim Ellison wrote:
> >>
> >>> Using the Eclipse compiler:
> >>>
> >>> In the Eclipse JDT UI you *can* specify source=5.0 target=1.4 and I
> >>> successfully ran code written using generics on a 1.4 VM. However, the
> >>> Eclipse batch compiler does not allow this source=5.0 target=1.4
> >>> combination; and when I asked why the answer was that the UI usage is
> >>> wrong and will be fixed to prevent that combination.
> >>>
> >> LOL! How about suggesting that users find it useful right now?
> >> ...
> >> It seems like we have two options - Sun and Eclipse, and because the
> >> eclipse compiler is CDDL, and can be integrated into our build system,
> >> we seem to be safe.
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Switching to a 5.0 compiler
Posted by George Harley <ge...@googlemail.com>.
Hi,
Using the Sun 5.0 javac with the "jsr14" target it is possible to do a
complete compile of the Harmony Java source and successfully run the
tests on the existing VME. That means we could add in more contributions
that depended on 5.0 language features being understood instead of
letting them queue up.
So +1 from me for using the straightforward but undocumented "jsr14"
target as a purely temporary measure to keep things moving onwards.
Best regards,
George
Etienne Gagnon wrote:
> I think that using Sun's javac and Eclipse with their undocumented and
> unsupported options during the "transition period" seems the cleanest
> strategy for both class library and VM maintenance. I see no trouble
> having such a dependency for a limited period of time (a few months).
>
> Etienne
>
> Geir Magnusson Jr wrote:
>
>> Tim Ellison wrote:
>>
>>> Using the Eclipse compiler:
>>>
>>> In the Eclipse JDT UI you *can* specify source=5.0 target=1.4 and I
>>> successfully ran code written using generics on a 1.4 VM. However, the
>>> Eclipse batch compiler does not allow this source=5.0 target=1.4
>>> combination; and when I asked why the answer was that the UI usage is
>>> wrong and will be fixed to prevent that combination.
>>>
>> LOL! How about suggesting that users find it useful right now?
>> ...
>> It seems like we have two options - Sun and Eclipse, and because the
>> eclipse compiler is CDDL, and can be integrated into our build system,
>> we seem to be safe.
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Switching to a 5.0 compiler
Posted by Etienne Gagnon <eg...@sablevm.org>.
I think that using Sun's javac and Eclipse with their undocumented and
unsupported options during the "transition period" seems the cleanest
strategy for both class library and VM maintenance. I see no trouble
having such a dependency for a limited period of time (a few months).
Etienne
Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>> Using the Eclipse compiler:
>>
>> In the Eclipse JDT UI you *can* specify source=5.0 target=1.4 and I
>> successfully ran code written using generics on a 1.4 VM. However, the
>> Eclipse batch compiler does not allow this source=5.0 target=1.4
>> combination; and when I asked why the answer was that the UI usage is
>> wrong and will be fixed to prevent that combination.
>
> LOL! How about suggesting that users find it useful right now?
>...
> It seems like we have two options - Sun and Eclipse, and because the
> eclipse compiler is CDDL, and can be integrated into our build system,
> we seem to be safe.
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [classlib] Switching to a 5.0 compiler
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Etienne Gagnon wrote:
> Tim Ellison wrote:
>> my point is that we could hack the Eclipse batch compiler to make it do
>> something it is not meant to do (source=1.5 target=1.4). If we get
>> burnt then we'll have nobody to complain to ;-)
>> ...
>> As it stands we have no option to use the Eclipse batch compiler
>> (without tweaking it and therefore I assume bringing a modified JAR into
>> our SVN for people to use etc. -- yuk!)
>
> Wouldn't the following be sufficient:
>
> 1- Put the (probably very small) patch in our repository.
> 2- Update make/depends.xml to fetch eclipse sources.
> 3- Update the build procedures to apply the patch and build/rebuild
> eclipse when necessary.
If we can avoid having to get the full code and rebuild, that might be
nicer. I figured that we could simply write our own code that calls the
eclipse internals, but since I don't actually know what needs to change,
I'll shut up now...
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Switching to a 5.0 compiler
Posted by Tim Ellison <t....@gmail.com>.
Yes, that would work.
Regards,
Tim
Etienne Gagnon wrote:
> Tim Ellison wrote:
>> my point is that we could hack the Eclipse batch compiler to make it do
>> something it is not meant to do (source=1.5 target=1.4). If we get
>> burnt then we'll have nobody to complain to ;-)
>> ...
>> As it stands we have no option to use the Eclipse batch compiler
>> (without tweaking it and therefore I assume bringing a modified JAR into
>> our SVN for people to use etc. -- yuk!)
>
> Wouldn't the following be sufficient:
>
> 1- Put the (probably very small) patch in our repository.
> 2- Update make/depends.xml to fetch eclipse sources.
> 3- Update the build procedures to apply the patch and build/rebuild
> eclipse when necessary.
> =>
>
> * Very small increase in repository
> * Longer *initial* build, but no change to next ones.
> * We have 2 compilers: Eclipse & Sun => Geir's condition is satisfied
>
> :-)
>
> Etienne
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Switching to a 5.0 compiler
Posted by Etienne Gagnon <eg...@sablevm.org>.
Tim Ellison wrote:
> my point is that we could hack the Eclipse batch compiler to make it do
> something it is not meant to do (source=1.5 target=1.4). If we get
> burnt then we'll have nobody to complain to ;-)
> ...
> As it stands we have no option to use the Eclipse batch compiler
> (without tweaking it and therefore I assume bringing a modified JAR into
> our SVN for people to use etc. -- yuk!)
Wouldn't the following be sufficient:
1- Put the (probably very small) patch in our repository.
2- Update make/depends.xml to fetch eclipse sources.
3- Update the build procedures to apply the patch and build/rebuild
eclipse when necessary.
=>
* Very small increase in repository
* Longer *initial* build, but no change to next ones.
* We have 2 compilers: Eclipse & Sun => Geir's condition is satisfied
:-)
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [classlib] Switching to a 5.0 compiler
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>> A while ago we agreed to switch to a class library compilation story
>> that would allow us to use 1.5 Java syntax on a 1.4-compatible VM (i.e.
>> using syntax that is erased by the compiler).
>>
>> Here's where I'm at...
>>
>>
>> Using the Sun compiler:
>>
>> Specifying source=1.5 and target=1.4 (understandably) fails as an
>> invalid option set, but there is an undocumented and unmaintained option
>> that, AIUI, was introduced during the syntax transition to full 1.5
>> support. On Sun-based compilers we can specify source=1.5 target=jsr14
>> and get some support for erased 1.5 syntax.
>
> Ok
>
>
>>
>> Using the Eclipse compiler:
>>
>> In the Eclipse JDT UI you *can* specify source=5.0 target=1.4 and I
>> successfully ran code written using generics on a 1.4 VM. However, the
>> Eclipse batch compiler does not allow this source=5.0 target=1.4
>> combination; and when I asked why the answer was that the UI usage is
>> wrong and will be fixed to prevent that combination.
>
> LOL! How about suggesting that users find it useful right now?
My understanding is that there is a spec compliance issue, hence...
>> Unless we void the warranty on the compiler by making non-API calls into
>> their code we cannot therefore use the Eclipse to do back-level
>> compilations.
>
> Warranty? From Eclipse? <chuckle>
(that was a joke BTW, I guess it needed a winky)
my point is that we could hack the Eclipse batch compiler to make it do
something it is not meant to do (source=1.5 target=1.4). If we get
burnt then we'll have nobody to complain to ;-)
>> Geir voted -1 to the proposal if it meant that we could only use one
>> compiler, so I have looked around thought a bit more about it ...
>>
>>
>> Using RetroWeaver:
>>
>> Retroweaver (retroweaver.sourceforge.net) is a bytecode weaver that
>> takes 1.5 class files and modifies them to run on 1.4-compatible VMs.
>> It is BSD-licensed.
>>
>> The weaver does a bit more than we actually want in that it not only
>> rewrites the class file format (to remove class literals, synthetic
>> access specifiers etc) but also replaces references to some runtime
>> dependencies (replaces StringBuilder with StringBuffer,
>> Float.valueOf(float), etc.)
>
> <geir runs away screaming>
Come back, take a deep breath.
This would only be doing what the source=1.5 target=1.4|jsr14 is doing.
> [SNIP]
>
>> Comments?
>
> Thanks for doing this.
>
> It seems like we have two options - Sun and Eclipse, and because the
> eclipse compiler is CDDL, and can be integrated into our build system,
> we seem to be safe.
As it stands we have no option to use the Eclipse batch compiler
(without tweaking it and therefore I assume bringing a modified JAR into
our SVN for people to use etc. -- yuk!)
> Sun isn't going to change, I'd bet, and in the event Eclipse does, we
> simply fork it. :)
>
> This really is a temporary situation. Maybe the thing to do is
>
> 1) get as much non-1.5 things done as possible this week or two (yes, I
> know it's "Java 5" now, but calling it 1.5 is a good parallel to 1.4)
We should do this anyway.
> 2) do a snapshot and also make a branch, for discussion sake call it
> branch_1.4, which is unsupported and not an official objective of the
> project
Hmm, you mean branch so that VMs can implement the VMI to that level
before moving on to 1.5?
> 3) In head, get going w/ erasable 5 stuff under the assumption that
> we'll be able to use Sun and Eclipse, for a while anyway.
... and use a source=1.5 target=1.5 compiler setting, and run it on...a
new IBM VME? Is that what you were thinking?
> 4) If anyone feels sufficiently motivated, they can add to branch_1.4 if
> we get more good code that we'd want to make available to the other 1.4
> VMs out there, but again, it's not something we as a project would
> commit to do - people could work on it as they see fit...
I see more people chomping at the bit to use 5.0 syntax rather than
continue on 1.4 -- we are just waiting for the VMs to catch up ;-)
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Switching to a 5.0 compiler
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> A while ago we agreed to switch to a class library compilation story
> that would allow us to use 1.5 Java syntax on a 1.4-compatible VM (i.e.
> using syntax that is erased by the compiler).
>
> Here's where I'm at...
>
>
> Using the Sun compiler:
>
> Specifying source=1.5 and target=1.4 (understandably) fails as an
> invalid option set, but there is an undocumented and unmaintained option
> that, AIUI, was introduced during the syntax transition to full 1.5
> support. On Sun-based compilers we can specify source=1.5 target=jsr14
> and get some support for erased 1.5 syntax.
Ok
>
> Using the Eclipse compiler:
>
> In the Eclipse JDT UI you *can* specify source=5.0 target=1.4 and I
> successfully ran code written using generics on a 1.4 VM. However, the
> Eclipse batch compiler does not allow this source=5.0 target=1.4
> combination; and when I asked why the answer was that the UI usage is
> wrong and will be fixed to prevent that combination.
LOL! How about suggesting that users find it useful right now?
>
> Unless we void the warranty on the compiler by making non-API calls into
> their code we cannot therefore use the Eclipse to do back-level
> compilations.
Warranty? From Eclipse? <chuckle>
>
> Geir voted -1 to the proposal if it meant that we could only use one
> compiler, so I have looked around thought a bit more about it ...
>
>
> Using RetroWeaver:
>
> Retroweaver (retroweaver.sourceforge.net) is a bytecode weaver that
> takes 1.5 class files and modifies them to run on 1.4-compatible VMs.
> It is BSD-licensed.
>
> The weaver does a bit more than we actually want in that it not only
> rewrites the class file format (to remove class literals, synthetic
> access specifiers etc) but also replaces references to some runtime
> dependencies (replaces StringBuilder with StringBuffer,
> Float.valueOf(float), etc.)
<geir runs away screaming>
[SNIP]
> Comments?
Thanks for doing this.
It seems like we have two options - Sun and Eclipse, and because the
eclipse compiler is CDDL, and can be integrated into our build system,
we seem to be safe.
Sun isn't going to change, I'd bet, and in the event Eclipse does, we
simply fork it. :)
This really is a temporary situation. Maybe the thing to do is
1) get as much non-1.5 things done as possible this week or two (yes, I
know it's "Java 5" now, but calling it 1.5 is a good parallel to 1.4)
2) do a snapshot and also make a branch, for discussion sake call it
branch_1.4, which is unsupported and not an official objective of the
project
3) In head, get going w/ erasable 5 stuff under the assumption that
we'll be able to use Sun and Eclipse, for a while anyway.
4) If anyone feels sufficiently motivated, they can add to branch_1.4 if
we get more good code that we'd want to make available to the other 1.4
VMs out there, but again, it's not something we as a project would
commit to do - people could work on it as they see fit...
... ?
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org