harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject [drlvm] Loading 50:0 format class files (was: Re: [vote] Declare the signed source for r809832 as 6.0 Milestone 1)
Date Thu, 03 Sep 2009 07:35:11 GMT
On 02/Sep/2009 22:46, Mark Hindess wrote:
> In message <4A9EDFAE.4000509@gmail.com>, Tim Ellison writes:
>> On 02/Sep/2009 18:28, Mark Hindess wrote:
>>> In message <4A9E6944.9080609@gmail.com>, Tim Ellison writes:
>>>> On 01/Sep/2009 08:30, Mark Hindess wrote:
>>>>> There was some agreement that we should create a 6.0 milestone
>>>>> so I'm going to begin a vote.  If anyone feels that three days
>>>>> isn't enough time to complete testing then please just ask for
>>>>> more time.
>>>>>
>>>>> I have created a signed source archive for this revision and made
>>>>> it available at:
>>>>>
>>>>>   http://people.apache.org/~hindessm/6.0m1/
>>>>>
>>>>> Please test these artifacts and then vote for declaring these
>>>>> source archives as 6.0 milestone 1, and opening up the remaining
>>>>> frozen code trees for general development once again.
>>>>>
>>>>> This vote will be open for at least 3 days, or until all binding
>>>>> votes have been cast (if earlier).
>>>>>
>>>>> If the vote is successful, binary builds from that level will be
>>>>> made available on the download page.
>>>> How is this going to work if the DRLVM cannot load class files
>>>> compiled for 1.6 ?! See HARMONY-6317
>>> It will load some class files compiled for 1.6.  For instance, if
>>> I compile classlib with hy.javac.{source,target}=1.6 then it runs
>>> eclipse.
>> I was referring to the ability for the candidate to run applications
>> compiled with target 1.6 (not the classlib compiled with target 1.6).
> 
> I know but loading classes from a classlib compiled as 1.6 level class files
> is a good test that using classes without 1.6 features are generally okay.

I see, though classlib compiled as a 1.6 format source/target may also
exhibit the same problems.

The changes that went into JSR202 include:
 - split verifier support
 - increase various size limits
 - adding support for class literals
 - minor changes to support Java language changes

I'm assuming that the problem in DRLVM is the loading on class literals.

> As I wrote later, SwingSet2.jar works for me - I've tried several version
> all with 1.6 level class files - on linux/x86.

The first thing I tried was java -version (which reported the wrong
version number) and the next was SwingSet2 from Sun JDK 6.0b16 which
failed to load classes -- so it was not a great start!

The SwingSet2 shipped with IBM JDKs works ok, so I assume that they
compile it differently.

>> AFAIK Eclipse doesn't have any 1.6 level class files.
> 
> Of course.
> 
>>> Do you think we should hold off releasing any 6.0 milestones
>>> until the VM supports all 1.6 features?  If no one is planning to
>>> implement these we might not make any 6.0 releases for a rather long
>>> time and so the 6.0 classlib code wont get released/exercised?
>> No, I understand this is an early driver, so if there are some
>> limitations then putting them into the README is fine.  However, if we
>> cannot run any 1.6 class files then that is a show stopper IMHO.
> 
> Sorry, it wasn't clear from the JIRA you pointed to that you couldn't
> run *any* 1.6 class files, I assumed the problematic classes used 1.6
> specific features.

I can run some class files compiled with the 1.6 compiler.  I haven't
checked the class file format but assume that they are Major 50 Minor 0
format, in which case as I said above I think we should understand the
limitation we have got and mention it in the readme.

>> I also think we should fix HARMONY-6330, even in the first milestone,
>> as that is just silly.
> 
> Well, please vote -1 and save anyone wasting more time testing. ;-)

Ok.

>>> I'm fine if we decide not to make a release now but we should decide
>>> exactly what the "must have" features are for milestone 1.
>> Agreed.  But I think we need to make a quick decision about whether
>> the relevant branches need to remain frozen or not.
> 
> If windows is as bad as you say then I'd be inclined to delay 6.0M1
> until after 5.0M12 to give us time to fix it.
> 
> And re-open the entire code base ASAP.

I'm happy to keep testing, and if we can make progress quickly then
let's press ahead, but otherwise let's open all the code and give the
6.0 stream a bit more attention before attempting the 6.0M1 again.

Regards,
Tim


Mime
View raw message