harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [drlvm] putting kernel.jar in jre/bin/default
Date Wed, 13 Sep 2006 05:42:30 GMT
Alexey Varlamov wrote:
> Looks like sending my reply failed, here is a second try:
>
>> I'm not sure I catch up what you mean, about Emma, Harmony's current
>> test coverage exclude list[1] shows that not all classes can be
>> instrumented, I don't think it is due to the position of kernel classes.
>
> Paulex,
>
> I'm sorry for causing confusion - I was a bit wrong. I experienced
> troubles with complete overriiding via "-Xbootclasspath:" argument,
> and just prepending "-Xbootclasspath/p:" works OK. Not all kernel
> classes are instrumented due to dependencies in instrumentation code
> itself, this is of course different thing.
Agreed.
>
>>
>> Further, for the special requirement(instrument, AOP, or so), anything
>> prevent the user to add "-Xbootclasspath/p" to replace the kernel class
>> implementation? Or, what's the difference on this between RI and current
>> Harmony?
>
> So the difference is that for "-Xbootclasspath:", launcher+j9 always
> stealthily prepend luni-kernel.jar to user-specified bootclasspath,
> while RI allows fully custom bootclasspath.
This is interesting. Yes, I think we should handle it, although it 
probably won't work to replace the kernel class implementation due to 
the VM dependency, we have no reason forbidding user to do this.

Just had a look at how the normal bootclasspath(luni.jar, text.jar...) 
is processed, the interesting thing is they are loaded by JNI_OnLoad of 
hyluni.dll(libhyluni.so), with the source codes located in 
modules/luni/src/native/luni/shared/luniglob.c (It is interesting 
because I thought it was in launcher, but maybe the original author had 
similar issues to get the absolute path of jre/lib/boot). And it takes a 
straightforward way to handle the "-Xbootclasspath": if this argument is 
passed in command line, just give up parsing the default bootclasspath. 
I have two thoughts on this:
1. If this is acceptable, we can deal with kernel class in similar way.
2. Supposing we can have better solution to locate the jre path, is 
there any chance to merge the both bootclasspath handling(kernel and 
normal) to launcher, so that it doesn't need to deal with bootclasspath 
twice?

Or any other proposals?
>
> -- 
> Alexey
>
> ---------------------------------------------------------------------
> 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
>
>


-- 
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
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