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 Re: [classlib] update on running Harmony Classlib on GNU Classpath VMs
Date Fri, 07 Apr 2006 15:15:35 GMT
Weldon Washburn wrote:
> On 4/7/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>> I tried to give a complete explaination in the readme in JIRA
>>> Harmony-318.  It would be great if you could tell me what this
>>> document is missing or where it is unclear.
>> Ok, I'll take a look.  I think this adapter work is very important, it
>> would be good to discuss problems/progress on the dev list too.
> 
> Aha!  Let's now discuss the problems on the dev list:

Well I'm about to disappear for a week ;-) -- but this is likely the
best way of getting a broad discussion and comments.

> I added a bunch of VMxxxxx.java files to
> kernel/src/main/java/java/lang/   These files are only needed for GNU
> Classpath compatible JVMs.  Should we keep these files in this
> directory or should we create a separate directory?  It might make
> sense to create
> kernel/src/gnuclasspathadapter/java/java/lang/VMxxxxx.java

I would object to making the Harmony kernel GNU Classpath specific, so
why not make the adapter a separate 'project', i.e. just
	gnuclasspathadapter/src/java/java/lang/VMxxxxx.java

> GNU Classpath needs unique "pointer" classes.  We could put them at
> kernel/src/gnuclasspathadapter/java/gnu/classpath/Pointerxxxxx.java

or
	gnuclasspathadapter/src/java/gnu/classpath/Pointerxxxxx.java

> Thoughts on the above?

it's more important to get the code working than figure out where in the
Harmony repository it would end up isn't it?

Wherever it goes I expect it will simply be built into one or more JARs
that are put on the bootclasspath to run Classpath-oriented VMs (just
like any other VM provides its own own kernel implementation).

>>> Actually I could not get JCHEVM/cygwin to read the JAR files.
>> Is that an issue with JCHEVM or the JAR files do you think?
> 
> I think JCHEVM/cygwin inability to read JAR files is one of the
> problems that will go away if you ignore it.  In other words, someone
> has probably already fixed this problem in the latest download of
> JCHEVM.  Its not a biggie.  I can wait.

<shrug>

>>> I am working with a 2 month old copy of Harmony Classlib.  I would
>>> like to hold off the move to current Harmony Classlib until after I
>>> get the cygwin dlopen() problems solved.
>
>> Ah, ok -- I'll try and do the timeshift thing, but if there are fixes
>> that are required in Harmony classlib to make things work/easier for you
>> they will be applied to the current HEAD, and we can discuss what is
>> required for them to work in your local sandbox.
> 
> So far, the biggest thing has been where to put the new kernel files.

I guess I don't understand why the location of your adapter source code
is a big deal?

> The next item is likely to be the tool chain that the make files are
> using.  I worry that there is incompatiblity between *.dll's built for
> GNU Classpath environment and *.dll's built for Harmony Classlib.  It
> would be good if JNI compilant Windows *.dll's can plug-and-play on
> both Harmony and GNU Classpath environments.  I suspect Cygwin
> environment is involved.  Do you know if anyone has looked at this
> issue yet?

I haven't seen such interop problems -- hopefully somebody will chime in.

>>> I modified System.java to do a "VMRuntime.nativeLoad("hynio.dll");"
>>> This is a call into GNU Classpath JVM that will cause a DLL to be
>>> loaded.
>
>> (Two months ago:) IIRC there is an explicit call to
>> System.loadLibary("hynio") in the class libary code, so why do you need
>> to make that into a Classpath-specific call?
> 
> I checked just now.  I can't find evidence of hynio.dll being called
> in the version of Harmony Classlib kernel files I have.

It was there in the OSMemory class up to six days ago[1], but whatever.

[1]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/org/apache/harmony/luni/platform/OSMemory.java?rev=390453&r1=390038&r2=390453&diff_format=h

> In any case,
> when kernel_path is moved to the latest version of Classlib, the code
> that currently tries to loead hynio.dll should be replaced with the
> correct stuff.

It currently isn't loaded/used, those functions were moved into
lyluni.dll | libhyluni.so.

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


Mime
View raw message