2006/9/13, Paulex Yang <[EMAIL PROTECTED]>:
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?
We had a discussion about this month ago [1], and the main argument
against the launcher was "there may be several launchers, moreover
bootclasspath has to be set for any application that calls
JNI_CreateJavaVM". So no better place than luni natives was suggested
for the shared part of the bootlclasspath. BTW, there is reliability
fix HARMONY-1243 related to this and still unresolved...
But as kernel classes packaging is VM-specific, the VM should take
care of them. Evidently the same argument about launcher applies to
kernels as well, so current way with harmonyvm.properties is a sort of
workaround anyway.
And to handle the "-Xbooclasspath:" issue, there should be double
filtering: check user-supplied arguments then filter autoloaded ones
from harmonyvm.properties. Smells not really good ;).
More logical would be to get rid of handling harmonyvm.properties in
launcher entirely, leaving this to VM if it needs it.
[1] http://thread.gmane.org/gmane.comp.java.harmony.devel/11776/focus=11818
>
> --
> Alexey
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
