You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Gregory Shimansky <gs...@gmail.com> on 2007/09/04 16:59:47 UTC
[drlvm] DRLVM should accept Java6 classes now
Hello
As of revision 572698 DRLVM should not throw UnsupportedClassVersion
when it sees a class file compiled with Java6 compiler (or with -target
1.6 by ECJ 3.3). These class files should work with no problems with DRLVM.
For testing I used classlib (trunk) compiled with ECJ 3.3 with -source
1.6 -target 1.6 and all VM acceptance tests compiled with Sun's javac
from JDK 6.0.
--
Gregory
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Pavel Pervov <pm...@gmail.com>.
Do we need to make virtual machine backward compatible with previous
versions of class library?
Or what we are really trying to solve is "initial support of java6 - namely
java6 class file version - in DRLVM without branching"?
WBR,
Pavel.
On 9/18/07, Tim Ellison <t....@gmail.com> wrote:
>
> Sorry for the delay in responding...
>
> Gregory Shimansky wrote:
> > Gregory Shimansky wrote:
> >> Tim Ellison wrote:
> >>> Yuri Dolgov wrote:
> >>>>> we can make this constant definable by the build.
> >>>> That's a great idea. I agree.
> >>>
> >>> Would it be too expensive as a runtime check? i.e ask the classlib at
> >>> start-up if the VM should behave like Java 5 or Java 6, then we don't
> >>> even have to produce separate VM builds.
> >>
> >> I don't think it would be expensive in any way. This constant
> >> CLASSFILE_MAJOR_MAX is currently used only in 2 places, to check that
> >> class file version is supported by VM, and to define
> >> java.class.version property value on startup.
> >>
> >> This property could be defined by classlib code, and VM would use its
> >> value in class loader instead of hardcoded class version.
> >
> > Hmm now that I think of it there may be a recursion. To get a value of
> > java.class.version VM would need to load at least some classes from
> > classlib which would require knowing the supported class version of VM
> > side. But this property could be supplied by the launcher from the VM
> > command line.
> >
> > Launcher is still a part of classlib so there may be different version
> > of for Java5 and Java6.
>
> I wasn't thinking of running any java code to supply it, but how early
> do you need to know? Is it too late after create java vm? How about we
> notify you in the class library JNI_OnLoad for LUNI, i.e. call into the
> VM and set the java.class.version using the VMI functions.
>
> I'm reluctant to add extra login in the launcher since the VM should
> work equivalently when embedded in anyone's program.
>
> Regards,
> Tim
>
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Gregory Shimansky <gs...@gmail.com>.
Tim Ellison wrote:
> Sorry for the delay in responding...
>
> Gregory Shimansky wrote:
>> Gregory Shimansky wrote:
>>> Tim Ellison wrote:
>>>> Yuri Dolgov wrote:
>>>>>> we can make this constant definable by the build.
>>>>> That's a great idea. I agree.
>>>> Would it be too expensive as a runtime check? i.e ask the classlib at
>>>> start-up if the VM should behave like Java 5 or Java 6, then we don't
>>>> even have to produce separate VM builds.
>>> I don't think it would be expensive in any way. This constant
>>> CLASSFILE_MAJOR_MAX is currently used only in 2 places, to check that
>>> class file version is supported by VM, and to define
>>> java.class.version property value on startup.
>>>
>>> This property could be defined by classlib code, and VM would use its
>>> value in class loader instead of hardcoded class version.
>> Hmm now that I think of it there may be a recursion. To get a value of
>> java.class.version VM would need to load at least some classes from
>> classlib which would require knowing the supported class version of VM
>> side. But this property could be supplied by the launcher from the VM
>> command line.
>>
>> Launcher is still a part of classlib so there may be different version
>> of for Java5 and Java6.
>
> I wasn't thinking of running any java code to supply it, but how early
> do you need to know? Is it too late after create java vm? How about we
> notify you in the class library JNI_OnLoad for LUNI, i.e. call into the
> VM and set the java.class.version using the VMI functions.
>
> I'm reluctant to add extra login in the launcher since the VM should
> work equivalently when embedded in anyone's program.
This could work well if JNI_OnLoad for LUNI works before any Java code
is loaded. I think it works this way currently because when bootstrap
class loader initializes it loads bootstrap native libraries, LUNI first
of all.
I think it is the best solution!
--
Gregory
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Tim Ellison <t....@gmail.com>.
Sorry for the delay in responding...
Gregory Shimansky wrote:
> Gregory Shimansky wrote:
>> Tim Ellison wrote:
>>> Yuri Dolgov wrote:
>>>>> we can make this constant definable by the build.
>>>> That's a great idea. I agree.
>>>
>>> Would it be too expensive as a runtime check? i.e ask the classlib at
>>> start-up if the VM should behave like Java 5 or Java 6, then we don't
>>> even have to produce separate VM builds.
>>
>> I don't think it would be expensive in any way. This constant
>> CLASSFILE_MAJOR_MAX is currently used only in 2 places, to check that
>> class file version is supported by VM, and to define
>> java.class.version property value on startup.
>>
>> This property could be defined by classlib code, and VM would use its
>> value in class loader instead of hardcoded class version.
>
> Hmm now that I think of it there may be a recursion. To get a value of
> java.class.version VM would need to load at least some classes from
> classlib which would require knowing the supported class version of VM
> side. But this property could be supplied by the launcher from the VM
> command line.
>
> Launcher is still a part of classlib so there may be different version
> of for Java5 and Java6.
I wasn't thinking of running any java code to supply it, but how early
do you need to know? Is it too late after create java vm? How about we
notify you in the class library JNI_OnLoad for LUNI, i.e. call into the
VM and set the java.class.version using the VMI functions.
I'm reluctant to add extra login in the launcher since the VM should
work equivalently when embedded in anyone's program.
Regards,
Tim
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x34A day of Apache Harmony Gregory Shimansky wrote:
> Gregory Shimansky wrote:
> > Tim Ellison wrote:
> >> Yuri Dolgov wrote:
> >>>> we can make this constant definable by the build.
> >>> That's a great idea. I agree.
> >>
> >> Would it be too expensive as a runtime check? i.e ask the classlib at
> >> start-up if the VM should behave like Java 5 or Java 6, then we don't
> >> even have to produce separate VM builds.
> > I don't think it would be expensive in any way. This constant
> > CLASSFILE_MAJOR_MAX is currently used only in 2 places, to check
> > that class file version is supported by VM, and to define
> > java.class.version property value on startup.
> > This property could be defined by classlib code, and VM would use
> > its value in class loader instead of hardcoded class version.
>
> Hmm now that I think of it there may be a recursion. To get a value of
> java.class.version VM would need to load at least some classes from
> classlib which would require knowing the supported class version of VM
> side. But this property could be supplied by the launcher from the VM
> command line.
>
> Launcher is still a part of classlib so there may be different version
> of for Java5 and Java6.
yep, I thought about it too, but that should be easy to compile a
bunch of classes necessary to get this option in a special mode that
is java5 and is compatible with java6. To my memory, we should disable
jsr/ret instructions. Anything else?
--
Egor Pasko
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Gregory Shimansky <gs...@gmail.com>.
Gregory Shimansky wrote:
> Tim Ellison wrote:
>> Yuri Dolgov wrote:
>>>> we can make this constant definable by the build.
>>> That's a great idea. I agree.
>>
>> Would it be too expensive as a runtime check? i.e ask the classlib at
>> start-up if the VM should behave like Java 5 or Java 6, then we don't
>> even have to produce separate VM builds.
>
> I don't think it would be expensive in any way. This constant
> CLASSFILE_MAJOR_MAX is currently used only in 2 places, to check that
> class file version is supported by VM, and to define java.class.version
> property value on startup.
>
> This property could be defined by classlib code, and VM would use its
> value in class loader instead of hardcoded class version.
Hmm now that I think of it there may be a recursion. To get a value of
java.class.version VM would need to load at least some classes from
classlib which would require knowing the supported class version of VM
side. But this property could be supplied by the launcher from the VM
command line.
Launcher is still a part of classlib so there may be different version
of for Java5 and Java6.
--
Gregory
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x34A day of Apache Harmony Gregory Shimansky wrote:
> Tim Ellison wrote:
> > Yuri Dolgov wrote:
> >>> we can make this constant definable by the build.
> >> That's a great idea. I agree.
> > Would it be too expensive as a runtime check? i.e ask the classlib at
> > start-up if the VM should behave like Java 5 or Java 6, then we don't
> > even have to produce separate VM builds.
>
> I don't think it would be expensive in any way. This constant
> CLASSFILE_MAJOR_MAX is currently used only in 2 places, to check that
> class file version is supported by VM, and to define
> java.class.version property value on startup.
>
> This property could be defined by classlib code, and VM would use its
> value in class loader instead of hardcoded class version.
+1
> >> On 9/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
> >>> Egor Pasko wrote:
> >>>> On the 0x349 day of Apache Harmony Gregory Shimansky wrote:
> >>>>> Yuri Dolgov wrote:
> >>>>>>> Looking at the Sun's list of enhancements for Java6 [1] I found non
> >>>>>>> features specific to VM except for a small change in reflection API
> >>> [2].
> >>>>>>> So it seems to me that VM in Java5 and Java6 can be the same.
> >>>>>> Yes, that's fine. But why don't we just put this in Java 6 branch? I
> >>>>>> understand
> >>>>>> that our VM works fine with Java 6 classes, but what about classlib
> >>> and JIT?
> >>>>>> I think that throwing UnsupportedClassVersionError is just a tool
> >>>>>> which
> >>>>>> help to avoid unpredictable results.
> >>>>> Well, because there isn't a Java6 branch for VM. And I don't think
> >>>>> that a change in 1 line deserves to create one.
> >>>> +1
> >>>> alternatively: if it is one liner, we can make make it an option in the
> >>> build.
> >>>
> >>> After the patch that I've committed at 572698 the class version is
> >>> controlled by a single constant CLASSFILE_MAJOR_MAX in Class.h. Yes I
> >>> think we can make this constant definable by the build.
> >>>
> >>>>>> On 9/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
> >>>>>>> Yuri Dolgov wrote:
> >>>>>>>> Hello Gregory,
> >>>>>>>>
> >>>>>>>> I'm not sure what is the reason to support classes with version 50
> >>> if
> >>>>>>> don't
> >>>>>>>> support
> >>>>>>>> Java 6 features? Maybe it worth to make this changes in separate
> >>> Java 6
> >>>>>>>> branch to
> >>>>>>>> prevent confisions?
> >>>>>>> Looking at the Sun's list of enhancements for Java6 [1] I found non
> >>>>>>> features specific to VM except for a small change in reflection API
> >>> [2].
> >>>>>>> So it seems to me that VM in Java5 and Java6 can be the same.
> >>>>>>>
> >>>>>>> [1] http://java.sun.com/javase/6/webnotes/features.html
> >>>>>>> [2]
> >>>>>>>
> >>>>>>>
> >>> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
> >>>>>>>> On 9/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> >>>>>>>>> Stepan Mishura wrote:
> >>>>>>>>>> On 9/4/07, Gregory Shimansky wrote:
> >>>>>>>>>>> Hello
> >>>>>>>>>>>
> >>>>>>>>>>> As of revision 572698 DRLVM should not throw
> >>> UnsupportedClassVersion
> >>>>>>>>>>> when it sees a class file compiled with Java6 compiler (or with
> >>>>>>> -target
> >>>>>>>>>>> 1.6 by ECJ 3.3). These class files should work with no problems
> >>> with
> >>>>>>>>> DRLVM.
> >>>>>>>>>> Sould we create a java6 branch for DRL VM (as we did for classlib)
> >>> and
> >>>>>>>>>> move your update to the branch?
> >>>>>>>>> I don't think this deserves a real branch. The fact that VM accepts
> >>>>>>>>> classes of version 50 doesn't mean it is Java6 compliant. It also
> >>>>>>>>> doesn't make it non-Java5 VM in any way.
> >>>>>>>>>
> >>>>>>>>> On the other hand, if we make changes like in [1] it may break
> >>>>>>>>> compatibility with older Java5 code, and in such case we'll maybe
> >>> want
> >>>>>>>>> to create a separate branch.
> >>>>>>>>>
> >>>>>>>>> [1]
> >>>>>>>>>
> >>>>>>>>>
> >>> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
> >>>>>>>>>>> For testing I used classlib (trunk) compiled with ECJ 3.3 with
> >>>>>>> -source
> >>>>>>>>>>> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's
> >>> javac
> >>>>>>>>>>> from JDK 6.0.
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Gregory
> >>>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Gregory
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> --
> >>>>>>> Gregory
> >>>>>>>
> >>>>>>>
> >>>>> --
> >>>>> Gregory
> >>>>>
> >>>>>
> >>> --
> >>> Gregory
> >>>
> >>>
> >
>
>
> --
> Gregory
>
>
--
Egor Pasko
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Gregory Shimansky <gs...@gmail.com>.
Tim Ellison wrote:
> Yuri Dolgov wrote:
>>> we can make this constant definable by the build.
>> That's a great idea. I agree.
>
> Would it be too expensive as a runtime check? i.e ask the classlib at
> start-up if the VM should behave like Java 5 or Java 6, then we don't
> even have to produce separate VM builds.
I don't think it would be expensive in any way. This constant
CLASSFILE_MAJOR_MAX is currently used only in 2 places, to check that
class file version is supported by VM, and to define java.class.version
property value on startup.
This property could be defined by classlib code, and VM would use its
value in class loader instead of hardcoded class version.
>> On 9/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
>>> Egor Pasko wrote:
>>>> On the 0x349 day of Apache Harmony Gregory Shimansky wrote:
>>>>> Yuri Dolgov wrote:
>>>>>>> Looking at the Sun's list of enhancements for Java6 [1] I found non
>>>>>>> features specific to VM except for a small change in reflection API
>>> [2].
>>>>>>> So it seems to me that VM in Java5 and Java6 can be the same.
>>>>>> Yes, that's fine. But why don't we just put this in Java 6 branch? I
>>>>>> understand
>>>>>> that our VM works fine with Java 6 classes, but what about classlib
>>> and JIT?
>>>>>> I think that throwing UnsupportedClassVersionError is just a tool
>>>>>> which
>>>>>> help to avoid unpredictable results.
>>>>> Well, because there isn't a Java6 branch for VM. And I don't think
>>>>> that a change in 1 line deserves to create one.
>>>> +1
>>>> alternatively: if it is one liner, we can make make it an option in the
>>> build.
>>>
>>> After the patch that I've committed at 572698 the class version is
>>> controlled by a single constant CLASSFILE_MAJOR_MAX in Class.h. Yes I
>>> think we can make this constant definable by the build.
>>>
>>>>>> On 9/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
>>>>>>> Yuri Dolgov wrote:
>>>>>>>> Hello Gregory,
>>>>>>>>
>>>>>>>> I'm not sure what is the reason to support classes with version 50
>>> if
>>>>>>> don't
>>>>>>>> support
>>>>>>>> Java 6 features? Maybe it worth to make this changes in separate
>>> Java 6
>>>>>>>> branch to
>>>>>>>> prevent confisions?
>>>>>>> Looking at the Sun's list of enhancements for Java6 [1] I found non
>>>>>>> features specific to VM except for a small change in reflection API
>>> [2].
>>>>>>> So it seems to me that VM in Java5 and Java6 can be the same.
>>>>>>>
>>>>>>> [1] http://java.sun.com/javase/6/webnotes/features.html
>>>>>>> [2]
>>>>>>>
>>>>>>>
>>> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>>>>>>>> On 9/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
>>>>>>>>> Stepan Mishura wrote:
>>>>>>>>>> On 9/4/07, Gregory Shimansky wrote:
>>>>>>>>>>> Hello
>>>>>>>>>>>
>>>>>>>>>>> As of revision 572698 DRLVM should not throw
>>> UnsupportedClassVersion
>>>>>>>>>>> when it sees a class file compiled with Java6 compiler (or with
>>>>>>> -target
>>>>>>>>>>> 1.6 by ECJ 3.3). These class files should work with no problems
>>> with
>>>>>>>>> DRLVM.
>>>>>>>>>> Sould we create a java6 branch for DRL VM (as we did for classlib)
>>> and
>>>>>>>>>> move your update to the branch?
>>>>>>>>> I don't think this deserves a real branch. The fact that VM accepts
>>>>>>>>> classes of version 50 doesn't mean it is Java6 compliant. It also
>>>>>>>>> doesn't make it non-Java5 VM in any way.
>>>>>>>>>
>>>>>>>>> On the other hand, if we make changes like in [1] it may break
>>>>>>>>> compatibility with older Java5 code, and in such case we'll maybe
>>> want
>>>>>>>>> to create a separate branch.
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>>
>>>>>>>>>
>>> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>>>>>>>>>>> For testing I used classlib (trunk) compiled with ECJ 3.3 with
>>>>>>> -source
>>>>>>>>>>> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's
>>> javac
>>>>>>>>>>> from JDK 6.0.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Gregory
>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Gregory
>>>>>>>>>
>>>>>>>>>
>>>>>>> --
>>>>>>> Gregory
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Gregory
>>>>>
>>>>>
>>> --
>>> Gregory
>>>
>>>
>
--
Gregory
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Tim Ellison <t....@gmail.com>.
Yuri Dolgov wrote:
>> we can make this constant definable by the build.
> That's a great idea. I agree.
Would it be too expensive as a runtime check? i.e ask the classlib at
start-up if the VM should behave like Java 5 or Java 6, then we don't
even have to produce separate VM builds.
Regards,
Tim
> On 9/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
>> Egor Pasko wrote:
>>> On the 0x349 day of Apache Harmony Gregory Shimansky wrote:
>>>> Yuri Dolgov wrote:
>>>>>> Looking at the Sun's list of enhancements for Java6 [1] I found non
>>>>>> features specific to VM except for a small change in reflection API
>> [2].
>>>>>> So it seems to me that VM in Java5 and Java6 can be the same.
>>>>> Yes, that's fine. But why don't we just put this in Java 6 branch? I
>>>>> understand
>>>>> that our VM works fine with Java 6 classes, but what about classlib
>> and JIT?
>>>>> I think that throwing UnsupportedClassVersionError is just a tool
>>>>> which
>>>>> help to avoid unpredictable results.
>>>> Well, because there isn't a Java6 branch for VM. And I don't think
>>>> that a change in 1 line deserves to create one.
>>> +1
>>> alternatively: if it is one liner, we can make make it an option in the
>> build.
>>
>> After the patch that I've committed at 572698 the class version is
>> controlled by a single constant CLASSFILE_MAJOR_MAX in Class.h. Yes I
>> think we can make this constant definable by the build.
>>
>>>>> On 9/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
>>>>>> Yuri Dolgov wrote:
>>>>>>> Hello Gregory,
>>>>>>>
>>>>>>> I'm not sure what is the reason to support classes with version 50
>> if
>>>>>> don't
>>>>>>> support
>>>>>>> Java 6 features? Maybe it worth to make this changes in separate
>> Java 6
>>>>>>> branch to
>>>>>>> prevent confisions?
>>>>>> Looking at the Sun's list of enhancements for Java6 [1] I found non
>>>>>> features specific to VM except for a small change in reflection API
>> [2].
>>>>>> So it seems to me that VM in Java5 and Java6 can be the same.
>>>>>>
>>>>>> [1] http://java.sun.com/javase/6/webnotes/features.html
>>>>>> [2]
>>>>>>
>>>>>>
>> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>>>>>>> On 9/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
>>>>>>>> Stepan Mishura wrote:
>>>>>>>>> On 9/4/07, Gregory Shimansky wrote:
>>>>>>>>>> Hello
>>>>>>>>>>
>>>>>>>>>> As of revision 572698 DRLVM should not throw
>> UnsupportedClassVersion
>>>>>>>>>> when it sees a class file compiled with Java6 compiler (or with
>>>>>> -target
>>>>>>>>>> 1.6 by ECJ 3.3). These class files should work with no problems
>> with
>>>>>>>> DRLVM.
>>>>>>>>> Sould we create a java6 branch for DRL VM (as we did for classlib)
>> and
>>>>>>>>> move your update to the branch?
>>>>>>>> I don't think this deserves a real branch. The fact that VM accepts
>>>>>>>> classes of version 50 doesn't mean it is Java6 compliant. It also
>>>>>>>> doesn't make it non-Java5 VM in any way.
>>>>>>>>
>>>>>>>> On the other hand, if we make changes like in [1] it may break
>>>>>>>> compatibility with older Java5 code, and in such case we'll maybe
>> want
>>>>>>>> to create a separate branch.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>>
>>>>>>>>
>> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>>>>>>>>>> For testing I used classlib (trunk) compiled with ECJ 3.3 with
>>>>>> -source
>>>>>>>>>> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's
>> javac
>>>>>>>>>> from JDK 6.0.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Gregory
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Gregory
>>>>>>>>
>>>>>>>>
>>>>>> --
>>>>>> Gregory
>>>>>>
>>>>>>
>>>> --
>>>> Gregory
>>>>
>>>>
>>
>> --
>> Gregory
>>
>>
>
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Yuri Dolgov <do...@gmail.com>.
> we can make this constant definable by the build.
That's a great idea. I agree.
Thanks,
Yuri
On 9/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
>
> Egor Pasko wrote:
> > On the 0x349 day of Apache Harmony Gregory Shimansky wrote:
> >> Yuri Dolgov wrote:
> >>>> Looking at the Sun's list of enhancements for Java6 [1] I found non
> >>>> features specific to VM except for a small change in reflection API
> [2].
> >>>> So it seems to me that VM in Java5 and Java6 can be the same.
> >>> Yes, that's fine. But why don't we just put this in Java 6 branch? I
> >>> understand
> >>> that our VM works fine with Java 6 classes, but what about classlib
> and JIT?
> >>> I think that throwing UnsupportedClassVersionError is just a tool
> >>> which
> >>> help to avoid unpredictable results.
> >> Well, because there isn't a Java6 branch for VM. And I don't think
> >> that a change in 1 line deserves to create one.
> >
> > +1
> > alternatively: if it is one liner, we can make make it an option in the
> build.
>
> After the patch that I've committed at 572698 the class version is
> controlled by a single constant CLASSFILE_MAJOR_MAX in Class.h. Yes I
> think we can make this constant definable by the build.
>
> >>> On 9/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
> >>>> Yuri Dolgov wrote:
> >>>>> Hello Gregory,
> >>>>>
> >>>>> I'm not sure what is the reason to support classes with version 50
> if
> >>>> don't
> >>>>> support
> >>>>> Java 6 features? Maybe it worth to make this changes in separate
> Java 6
> >>>>> branch to
> >>>>> prevent confisions?
> >>>> Looking at the Sun's list of enhancements for Java6 [1] I found non
> >>>> features specific to VM except for a small change in reflection API
> [2].
> >>>> So it seems to me that VM in Java5 and Java6 can be the same.
> >>>>
> >>>> [1] http://java.sun.com/javase/6/webnotes/features.html
> >>>> [2]
> >>>>
> >>>>
> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
> >>>>
> >>>>> On 9/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> >>>>>> Stepan Mishura wrote:
> >>>>>>> On 9/4/07, Gregory Shimansky wrote:
> >>>>>>>> Hello
> >>>>>>>>
> >>>>>>>> As of revision 572698 DRLVM should not throw
> UnsupportedClassVersion
> >>>>>>>> when it sees a class file compiled with Java6 compiler (or with
> >>>> -target
> >>>>>>>> 1.6 by ECJ 3.3). These class files should work with no problems
> with
> >>>>>> DRLVM.
> >>>>>>> Sould we create a java6 branch for DRL VM (as we did for classlib)
> and
> >>>>>>> move your update to the branch?
> >>>>>> I don't think this deserves a real branch. The fact that VM accepts
> >>>>>> classes of version 50 doesn't mean it is Java6 compliant. It also
> >>>>>> doesn't make it non-Java5 VM in any way.
> >>>>>>
> >>>>>> On the other hand, if we make changes like in [1] it may break
> >>>>>> compatibility with older Java5 code, and in such case we'll maybe
> want
> >>>>>> to create a separate branch.
> >>>>>>
> >>>>>> [1]
> >>>>>>
> >>>>>>
> >>>>
> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
> >>>>>>>> For testing I used classlib (trunk) compiled with ECJ 3.3 with
> >>>> -source
> >>>>>>>> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's
> javac
> >>>>>>>> from JDK 6.0.
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Gregory
> >>>>>>>>
> >>>>>> --
> >>>>>> Gregory
> >>>>>>
> >>>>>>
> >>>> --
> >>>> Gregory
> >>>>
> >>>>
> >>
> >> --
> >> Gregory
> >>
> >>
> >
>
>
> --
> Gregory
>
>
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Gregory Shimansky <gs...@gmail.com>.
Egor Pasko wrote:
> On the 0x349 day of Apache Harmony Gregory Shimansky wrote:
>> Yuri Dolgov wrote:
>>>> Looking at the Sun's list of enhancements for Java6 [1] I found non
>>>> features specific to VM except for a small change in reflection API [2].
>>>> So it seems to me that VM in Java5 and Java6 can be the same.
>>> Yes, that's fine. But why don't we just put this in Java 6 branch? I
>>> understand
>>> that our VM works fine with Java 6 classes, but what about classlib and JIT?
>>> I think that throwing UnsupportedClassVersionError is just a tool
>>> which
>>> help to avoid unpredictable results.
>> Well, because there isn't a Java6 branch for VM. And I don't think
>> that a change in 1 line deserves to create one.
>
> +1
> alternatively: if it is one liner, we can make make it an option in the build.
After the patch that I've committed at 572698 the class version is
controlled by a single constant CLASSFILE_MAJOR_MAX in Class.h. Yes I
think we can make this constant definable by the build.
>>> On 9/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
>>>> Yuri Dolgov wrote:
>>>>> Hello Gregory,
>>>>>
>>>>> I'm not sure what is the reason to support classes with version 50 if
>>>> don't
>>>>> support
>>>>> Java 6 features? Maybe it worth to make this changes in separate Java 6
>>>>> branch to
>>>>> prevent confisions?
>>>> Looking at the Sun's list of enhancements for Java6 [1] I found non
>>>> features specific to VM except for a small change in reflection API [2].
>>>> So it seems to me that VM in Java5 and Java6 can be the same.
>>>>
>>>> [1] http://java.sun.com/javase/6/webnotes/features.html
>>>> [2]
>>>>
>>>> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>>>>
>>>>> On 9/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
>>>>>> Stepan Mishura wrote:
>>>>>>> On 9/4/07, Gregory Shimansky wrote:
>>>>>>>> Hello
>>>>>>>>
>>>>>>>> As of revision 572698 DRLVM should not throw UnsupportedClassVersion
>>>>>>>> when it sees a class file compiled with Java6 compiler (or with
>>>> -target
>>>>>>>> 1.6 by ECJ 3.3). These class files should work with no problems with
>>>>>> DRLVM.
>>>>>>> Sould we create a java6 branch for DRL VM (as we did for classlib) and
>>>>>>> move your update to the branch?
>>>>>> I don't think this deserves a real branch. The fact that VM accepts
>>>>>> classes of version 50 doesn't mean it is Java6 compliant. It also
>>>>>> doesn't make it non-Java5 VM in any way.
>>>>>>
>>>>>> On the other hand, if we make changes like in [1] it may break
>>>>>> compatibility with older Java5 code, and in such case we'll maybe want
>>>>>> to create a separate branch.
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>
>>>> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>>>>>>>> For testing I used classlib (trunk) compiled with ECJ 3.3 with
>>>> -source
>>>>>>>> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's javac
>>>>>>>> from JDK 6.0.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Gregory
>>>>>>>>
>>>>>> --
>>>>>> Gregory
>>>>>>
>>>>>>
>>>> --
>>>> Gregory
>>>>
>>>>
>>
>> --
>> Gregory
>>
>>
>
--
Gregory
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x349 day of Apache Harmony Gregory Shimansky wrote:
> Yuri Dolgov wrote:
> >> Looking at the Sun's list of enhancements for Java6 [1] I found non
> >> features specific to VM except for a small change in reflection API [2].
> >> So it seems to me that VM in Java5 and Java6 can be the same.
> > Yes, that's fine. But why don't we just put this in Java 6 branch? I
> > understand
> > that our VM works fine with Java 6 classes, but what about classlib and JIT?
> > I think that throwing UnsupportedClassVersionError is just a tool
> > which
> > help to avoid unpredictable results.
>
> Well, because there isn't a Java6 branch for VM. And I don't think
> that a change in 1 line deserves to create one.
+1
alternatively: if it is one liner, we can make make it an option in the build.
> > On 9/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
> >> Yuri Dolgov wrote:
> >>> Hello Gregory,
> >>>
> >>> I'm not sure what is the reason to support classes with version 50 if
> >> don't
> >>> support
> >>> Java 6 features? Maybe it worth to make this changes in separate Java 6
> >>> branch to
> >>> prevent confisions?
> >> Looking at the Sun's list of enhancements for Java6 [1] I found non
> >> features specific to VM except for a small change in reflection API [2].
> >> So it seems to me that VM in Java5 and Java6 can be the same.
> >>
> >> [1] http://java.sun.com/javase/6/webnotes/features.html
> >> [2]
> >>
> >> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
> >>
> >>> On 9/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> >>>> Stepan Mishura wrote:
> >>>>> On 9/4/07, Gregory Shimansky wrote:
> >>>>>> Hello
> >>>>>>
> >>>>>> As of revision 572698 DRLVM should not throw UnsupportedClassVersion
> >>>>>> when it sees a class file compiled with Java6 compiler (or with
> >> -target
> >>>>>> 1.6 by ECJ 3.3). These class files should work with no problems with
> >>>> DRLVM.
> >>>>> Sould we create a java6 branch for DRL VM (as we did for classlib) and
> >>>>> move your update to the branch?
> >>>> I don't think this deserves a real branch. The fact that VM accepts
> >>>> classes of version 50 doesn't mean it is Java6 compliant. It also
> >>>> doesn't make it non-Java5 VM in any way.
> >>>>
> >>>> On the other hand, if we make changes like in [1] it may break
> >>>> compatibility with older Java5 code, and in such case we'll maybe want
> >>>> to create a separate branch.
> >>>>
> >>>> [1]
> >>>>
> >>>>
> >> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
> >>>>>> For testing I used classlib (trunk) compiled with ECJ 3.3 with
> >> -source
> >>>>>> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's javac
> >>>>>> from JDK 6.0.
> >>>>>>
> >>>>>> --
> >>>>>> Gregory
> >>>>>>
> >>>> --
> >>>> Gregory
> >>>>
> >>>>
> >>
> >> --
> >> Gregory
> >>
> >>
> >
>
>
> --
> Gregory
>
>
--
Egor Pasko
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Gregory Shimansky <gs...@gmail.com>.
Yuri Dolgov wrote:
>> Looking at the Sun's list of enhancements for Java6 [1] I found non
>> features specific to VM except for a small change in reflection API [2].
>> So it seems to me that VM in Java5 and Java6 can be the same.
>
> Yes, that's fine. But why don't we just put this in Java 6 branch? I
> understand
> that our VM works fine with Java 6 classes, but what about classlib and JIT?
>
> I think that throwing UnsupportedClassVersionError is just a tool which
> help to avoid unpredictable results.
Well, because there isn't a Java6 branch for VM. And I don't think that
a change in 1 line deserves to create one.
> On 9/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
>> Yuri Dolgov wrote:
>>> Hello Gregory,
>>>
>>> I'm not sure what is the reason to support classes with version 50 if
>> don't
>>> support
>>> Java 6 features? Maybe it worth to make this changes in separate Java 6
>>> branch to
>>> prevent confisions?
>> Looking at the Sun's list of enhancements for Java6 [1] I found non
>> features specific to VM except for a small change in reflection API [2].
>> So it seems to me that VM in Java5 and Java6 can be the same.
>>
>> [1] http://java.sun.com/javase/6/webnotes/features.html
>> [2]
>>
>> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>>
>>> On 9/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
>>>> Stepan Mishura wrote:
>>>>> On 9/4/07, Gregory Shimansky wrote:
>>>>>> Hello
>>>>>>
>>>>>> As of revision 572698 DRLVM should not throw UnsupportedClassVersion
>>>>>> when it sees a class file compiled with Java6 compiler (or with
>> -target
>>>>>> 1.6 by ECJ 3.3). These class files should work with no problems with
>>>> DRLVM.
>>>>> Sould we create a java6 branch for DRL VM (as we did for classlib) and
>>>>> move your update to the branch?
>>>> I don't think this deserves a real branch. The fact that VM accepts
>>>> classes of version 50 doesn't mean it is Java6 compliant. It also
>>>> doesn't make it non-Java5 VM in any way.
>>>>
>>>> On the other hand, if we make changes like in [1] it may break
>>>> compatibility with older Java5 code, and in such case we'll maybe want
>>>> to create a separate branch.
>>>>
>>>> [1]
>>>>
>>>>
>> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>>>>>> For testing I used classlib (trunk) compiled with ECJ 3.3 with
>> -source
>>>>>> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's javac
>>>>>> from JDK 6.0.
>>>>>>
>>>>>> --
>>>>>> Gregory
>>>>>>
>>>> --
>>>> Gregory
>>>>
>>>>
>>
>> --
>> Gregory
>>
>>
>
--
Gregory
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Yuri Dolgov <do...@gmail.com>.
> Looking at the Sun's list of enhancements for Java6 [1] I found non
> features specific to VM except for a small change in reflection API [2].
> So it seems to me that VM in Java5 and Java6 can be the same.
Yes, that's fine. But why don't we just put this in Java 6 branch? I
understand
that our VM works fine with Java 6 classes, but what about classlib and JIT?
I think that throwing UnsupportedClassVersionError is just a tool which
help to avoid unpredictable results.
Thanks,
Yuri
On 9/6/07, Gregory Shimansky <gs...@gmail.com> wrote:
>
> Yuri Dolgov wrote:
> > Hello Gregory,
> >
> > I'm not sure what is the reason to support classes with version 50 if
> don't
> > support
> > Java 6 features? Maybe it worth to make this changes in separate Java 6
> > branch to
> > prevent confisions?
>
> Looking at the Sun's list of enhancements for Java6 [1] I found non
> features specific to VM except for a small change in reflection API [2].
> So it seems to me that VM in Java5 and Java6 can be the same.
>
> [1] http://java.sun.com/javase/6/webnotes/features.html
> [2]
>
> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>
> > On 9/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
> >> Stepan Mishura wrote:
> >>> On 9/4/07, Gregory Shimansky wrote:
> >>>> Hello
> >>>>
> >>>> As of revision 572698 DRLVM should not throw UnsupportedClassVersion
> >>>> when it sees a class file compiled with Java6 compiler (or with
> -target
> >>>> 1.6 by ECJ 3.3). These class files should work with no problems with
> >> DRLVM.
> >>> Sould we create a java6 branch for DRL VM (as we did for classlib) and
> >>> move your update to the branch?
> >> I don't think this deserves a real branch. The fact that VM accepts
> >> classes of version 50 doesn't mean it is Java6 compliant. It also
> >> doesn't make it non-Java5 VM in any way.
> >>
> >> On the other hand, if we make changes like in [1] it may break
> >> compatibility with older Java5 code, and in such case we'll maybe want
> >> to create a separate branch.
> >>
> >> [1]
> >>
> >>
> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
> >>
> >>>> For testing I used classlib (trunk) compiled with ECJ 3.3 with
> -source
> >>>> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's javac
> >>>> from JDK 6.0.
> >>>>
> >>>> --
> >>>> Gregory
> >>>>
> >>
> >> --
> >> Gregory
> >>
> >>
> >
>
>
> --
> Gregory
>
>
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Gregory Shimansky <gs...@gmail.com>.
Yuri Dolgov wrote:
> Hello Gregory,
>
> I'm not sure what is the reason to support classes with version 50 if don't
> support
> Java 6 features? Maybe it worth to make this changes in separate Java 6
> branch to
> prevent confisions?
Looking at the Sun's list of enhancements for Java6 [1] I found non
features specific to VM except for a small change in reflection API [2].
So it seems to me that VM in Java5 and Java6 can be the same.
[1] http://java.sun.com/javase/6/webnotes/features.html
[2]
http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
> On 9/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
>> Stepan Mishura wrote:
>>> On 9/4/07, Gregory Shimansky wrote:
>>>> Hello
>>>>
>>>> As of revision 572698 DRLVM should not throw UnsupportedClassVersion
>>>> when it sees a class file compiled with Java6 compiler (or with -target
>>>> 1.6 by ECJ 3.3). These class files should work with no problems with
>> DRLVM.
>>> Sould we create a java6 branch for DRL VM (as we did for classlib) and
>>> move your update to the branch?
>> I don't think this deserves a real branch. The fact that VM accepts
>> classes of version 50 doesn't mean it is Java6 compliant. It also
>> doesn't make it non-Java5 VM in any way.
>>
>> On the other hand, if we make changes like in [1] it may break
>> compatibility with older Java5 code, and in such case we'll maybe want
>> to create a separate branch.
>>
>> [1]
>>
>> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>>
>>>> For testing I used classlib (trunk) compiled with ECJ 3.3 with -source
>>>> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's javac
>>>> from JDK 6.0.
>>>>
>>>> --
>>>> Gregory
>>>>
>>
>> --
>> Gregory
>>
>>
>
--
Gregory
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Yuri Dolgov <do...@gmail.com>.
Hello Gregory,
I'm not sure what is the reason to support classes with version 50 if don't
support
Java 6 features? Maybe it worth to make this changes in separate Java 6
branch to
prevent confisions?
Thanks,
Yuri
On 9/5/07, Gregory Shimansky <gs...@gmail.com> wrote:
>
> Stepan Mishura wrote:
> > On 9/4/07, Gregory Shimansky wrote:
> >> Hello
> >>
> >> As of revision 572698 DRLVM should not throw UnsupportedClassVersion
> >> when it sees a class file compiled with Java6 compiler (or with -target
> >> 1.6 by ECJ 3.3). These class files should work with no problems with
> DRLVM.
> >>
> >
> > Sould we create a java6 branch for DRL VM (as we did for classlib) and
> > move your update to the branch?
>
> I don't think this deserves a real branch. The fact that VM accepts
> classes of version 50 doesn't mean it is Java6 compliant. It also
> doesn't make it non-Java5 VM in any way.
>
> On the other hand, if we make changes like in [1] it may break
> compatibility with older Java5 code, and in such case we'll maybe want
> to create a separate branch.
>
> [1]
>
> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>
> >> For testing I used classlib (trunk) compiled with ECJ 3.3 with -source
> >> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's javac
> >> from JDK 6.0.
> >>
> >> --
> >> Gregory
> >>
> >
>
>
> --
> Gregory
>
>
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Gregory Shimansky <gs...@gmail.com>.
Stepan Mishura wrote:
> On 9/4/07, Gregory Shimansky wrote:
>> Hello
>>
>> As of revision 572698 DRLVM should not throw UnsupportedClassVersion
>> when it sees a class file compiled with Java6 compiler (or with -target
>> 1.6 by ECJ 3.3). These class files should work with no problems with DRLVM.
>>
>
> Sould we create a java6 branch for DRL VM (as we did for classlib) and
> move your update to the branch?
I don't think this deserves a real branch. The fact that VM accepts
classes of version 50 doesn't mean it is Java6 compliant. It also
doesn't make it non-Java5 VM in any way.
On the other hand, if we make changes like in [1] it may break
compatibility with older Java5 code, and in such case we'll maybe want
to create a separate branch.
[1]
http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>> For testing I used classlib (trunk) compiled with ECJ 3.3 with -source
>> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's javac
>> from JDK 6.0.
>>
>> --
>> Gregory
>>
>
--
Gregory
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Stepan Mishura <st...@gmail.com>.
On 9/4/07, Gregory Shimansky wrote:
> Hello
>
> As of revision 572698 DRLVM should not throw UnsupportedClassVersion
> when it sees a class file compiled with Java6 compiler (or with -target
> 1.6 by ECJ 3.3). These class files should work with no problems with DRLVM.
>
Sould we create a java6 branch for DRL VM (as we did for classlib) and
move your update to the branch?
Thanks,
Stepan.
> For testing I used classlib (trunk) compiled with ECJ 3.3 with -source
> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's javac
> from JDK 6.0.
>
> --
> Gregory
>
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Alexey Petrenko <al...@gmail.com>.
Great news!
Thanks, Gregory.
SY, Alexey
2007/9/4, Gregory Shimansky <gs...@gmail.com>:
> Hello
>
> As of revision 572698 DRLVM should not throw UnsupportedClassVersion
> when it sees a class file compiled with Java6 compiler (or with -target
> 1.6 by ECJ 3.3). These class files should work with no problems with DRLVM.
>
> For testing I used classlib (trunk) compiled with ECJ 3.3 with -source
> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's javac
> from JDK 6.0.
>
> --
> Gregory
>
>
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Leo Li <li...@gmail.com>.
On 9/5/07, Yang Paulex <pa...@gmail.com> wrote:
> 2007/9/4, Gregory Shimansky <gs...@gmail.com>:
> >
> > Hello
> >
> > As of revision 572698 DRLVM should not throw UnsupportedClassVersion
> > when it sees a class file compiled with Java6 compiler (or with -target
> > 1.6 by ECJ 3.3). These class files should work with no problems with
> > DRLVM.
> >
> > For testing I used classlib (trunk) compiled with ECJ 3.3 with -source
> > 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's javac
> > from JDK 6.0.
>
>
> Cool! Thanks, Gregory.
Great!
>
> --
> > Gregory
> >
> >
>
>
> --
> Paulex Yang
> China Software Development laboratory
> IBM
>
--
Leo Li
China Software Development Lab, IBM
Re: [drlvm] DRLVM should accept Java6 classes now
Posted by Yang Paulex <pa...@gmail.com>.
2007/9/4, Gregory Shimansky <gs...@gmail.com>:
>
> Hello
>
> As of revision 572698 DRLVM should not throw UnsupportedClassVersion
> when it sees a class file compiled with Java6 compiler (or with -target
> 1.6 by ECJ 3.3). These class files should work with no problems with
> DRLVM.
>
> For testing I used classlib (trunk) compiled with ECJ 3.3 with -source
> 1.6 -target 1.6 and all VM acceptance tests compiled with Sun's javac
> from JDK 6.0.
Cool! Thanks, Gregory.
--
> Gregory
>
>
--
Paulex Yang
China Software Development laboratory
IBM