2006/10/19, Leo Li <[EMAIL PROTECTED]>:
It is quite a dilemma: VM is free to choose the strategy of loading library
while the sequence is related to classlib.
In my opinion, it is classlib that has enough information and the
responsibility to decide the library loading sequence.
Since the launcher is in the control of classlib, is it possible that after
getting the JavaVM, manually load the required library then run the main
method?
Nope, the launcher is not a part of classlib and will not present in
all configurations (e.g. browser plugin or direct use of Invocation
API).
IMHO #3 is too crooked therefore inacceptable, and indeed we have to
state a VMI contract for loading natives needed by classlib: #1, #4 or
some other. I may suggest:
5. Reuse "bootclasspath.properties" solution. That is, there is always
mandatory hyluni lib, which can set up some property value indicating
a list of required libraries - as it is done now for bootclasspath
jars. After loading hyluni and calling its JNI_OnLoad, VM can read
this list and load other libs.
NB. Currently DRLVM follows #1, that's why it works.
On 10/18/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
>
> Alexey Varlamov wrote:
> > Can't we use lazy initialization here? I had similar experience with
> > this class in the past, and think it should not be so fragile to
> > initialization sequence. And definitely it should not affect whole VM
> > run.
> Hmm...lazily loading for Msg class is good, but I'm afraid it's not the
> "sweet point" of this problem, because in this case, the exception is
> *really* thrown by j.n.URL, so that you cannot avoid loading resource
> bundle(btw, I just found that the full stacktrace hasn't been pasted
> yet[1]). lI suspect the issue is that the hyarchive.dll/so has not been
> loaded yet when this exception happens, so I added this line to the
> static initialization part of ZipFile
>
> static {
> + System.loadLibrary("hyarchive"); //$NON-NLS-1$
> ntvinit();
> }
>
> The test codes pass happily. I want to commit this as work around if no
> one objects, but I still think a general solution for this kind of issue
> is necessary. There are several classes in archive module need native
> library, Adler32, CRC32, Deflater, Inflater and ZipFile, only explicitly
> load hyarchive here cannot guarantee bug free, and some other modules
> (nio, text etc) have same risk. I have some proposals:
>
> 1. Load classlib native libraries as early as possible in VM, as what we
> do for hyluni, this is safe but the concern is all the Harmony
> compatible VM needs to do this, unacceptable.
> 2. Load them early enough, like what we do now in IBM VME, the hyarchive
> is loaded during j.l.System static init, it was considered early enough,
> but sadly this case shows that we cannot image all cases, even for a
> relative general case
> 3. Create an init class like below, and all classes needs native library
> must load this init class at first, this works but works in ugly way...
> public class Init{
> static{
> System.loadLibrary("blabla");
> }
> }
> public class SomeClassNeedsNative{
> static{
> Class.forName("Init"); // the class loading should only
> happen once so that the native library is loaded only once.
> }
> }
> 4. Produce some contract like Jar_OnLoad() which is described in
> MANIFEST.MF, so that any class loader loading the jar at first time will
> execute that method, like JNI_OnLoad or so. This solution seems general
> and elegant, but needs yet another agreement between Harmony VM and
> classlib, further it may make the jar not compatible with other VM.
>
> Comments? More ideas?
>
> [1] java.lang.UnsatisfiedLinkError: java/util/zip/ZipFile.ntvinit()V
> at java.util.zip.ZipFile.<clinit>(ZipFile.java:50)
> at java.lang.J9VMInternals.initializeImpl(Native Method)
> at java.lang.J9VMInternals.initialize(J9VMInternals.java:177)
> at java.lang.J9VMInternals.initialize(J9VMInternals.java:144)
> at
> com.ibm.oti.vm.AbstractClassLoader.fillCache(AbstractClassLoader.java:95)
> at
> com.ibm.oti.vm.AbstractClassLoader.getResourceAsStream(
> AbstractClassLoader.java:134)
> at java.util.ResourceBundle$1.run(ResourceBundle.java:282)
> at java.util.ResourceBundle$1.run(ResourceBundle.java:1)
> at
> java.security.AccessController.doPrivileged(AccessController.java:179)
> at java.util.ResourceBundle.handleGetBundle(ResourceBundle.java:277)
> at java.util.ResourceBundle.getBundle(ResourceBundle.java:134)
> at org.apache.harmony.luni.util.MsgHelp$1.run(MsgHelp.java:114)
> at
> java.security.AccessController.doPrivileged(AccessController.java:179)
> at org.apache.harmony.luni.util.MsgHelp.setLocale(MsgHelp.java:112)
> at org.apache.harmony.luni.util.Msg.<clinit>(Msg.java:49)
> at java.lang.J9VMInternals.initializeImpl(Native Method)
> at java.lang.J9VMInternals.initialize(J9VMInternals.java:177)
> at java.net.URL.<init>(URL.java:296)
> at java.net.URL.<init>(URL.java:156)
> at
> org.apache.harmony.security.fortress.PolicyUtils.getPolicyURLs(
> PolicyUtils.java:445)
> at
> org.apache.harmony.security.fortress.DefaultPolicy.refresh(
> DefaultPolicy.java:278)
> at
> org.apache.harmony.security.fortress.DefaultPolicy.<init>(
> DefaultPolicy.java:184)
> at
> org.apache.harmony.security.fortress.DefaultPolicy.<init>(
> DefaultPolicy.java:173)
> at java.lang.Class.newInstanceImpl(Native Method)
> at java.lang.Class.newInstance(Class.java:1250)
> at java.security.Policy$1.run(Policy.java:156)
> at
> java.security.AccessController.doPrivileged(AccessController.java:179)
> at java.security.Policy.getDefaultProvider(Policy.java:151)
> at java.security.Policy.getAccessiblePolicy(Policy.java:191)
> at java.security.Policy.getPolicy(Policy.java:132)
> at org.apache.harmony.luni.util.PriviAction.run(PriviAction.java:133)
> at
> java.security.AccessController.doPrivileged(AccessController.java:179)
> at java.lang.System.setSecurityManager(System.java:825)
> at java.lang.System.installSecurityManager(System.java:155)
> at java.lang.System.completeInitialization(System.java:117)
> at java.lang.Thread.<init>(Thread.java:129)
> >
> > 2006/10/18, Paulex Yang <[EMAIL PROTECTED]>:
> >> A little further hack shows that, the cause is o.a.h.luni.util.Msg
> >> cannot be initialized so early, which is the exception message i18n
> >> helper class. Its static init codes try to load ResourceBundle but
> >> failed. The new i18n helper o.a.h.l.internal.nls.Messages has same
> >> issue. I modified the java.net.URL ln.296 as below, and the test
> passed.
> >> - throw new MalformedURLException(
> >> - org.apache.harmony.luni.util.Msg.getString(
> >> - "K00d8", spec)); //$NON-NLS-1$
> >> + throw new MalformedURLException("exception message
> >> here");
> >>
> >> Leo Li wrote:
> >> > Hi, all:
> >> > During the self-hosting of Derby, I found a security policy if
> is
> >> > applied will lead to errors in loading the class of JarFile. IBM vm
> >> > will throw java/lang/UnsatisfiedLinkError: java/util/zip/ZipFile.ntvi
> >> > while
> >> > drlvm will crash with "SEH handler: shutdown errorSEH handler: too
> >> many
> >> > shutdown errors..."
> >> >
> >> > Here is the testcase:
> >> >
> >> >
> >> > import java.util.jar.*;
> >> > public class TestJarFile {
> >> >
> >> > public static void main(String[] args) throws Exception{
> >> > System.out.println(JarFile.CENATT);
> >> > }
> >> >
> >> > }
> >> >
> >> > And the attachment is the derby_tests.policy.
> >> >
> >> > Then run:
> >> >
> >> > java -Djava.security.manager
> >> > -Djava.security.policy=derby_tests.policyTestJarFile
> >> >
> >> > Run passes,
> >> >
> >> > Harmony on IBM VM fails with java/lang/UnsatisfiedLinkError:
> >> > java/util/zip/ZipFile.ntvi
> >> >
> >> > Harmony on Drlvm fails with SEH handler: shutdown errorSEH handler:
> >> > too many
> >> > shutdown errors
> >> >
> >> > If the security manager is not specified, Harmony passes.
> >> >
> >> >
> >>
> >>
> >> --
> >> 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]
> >
> >
>
>
> --
> 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]
>
>
--
Leo Li
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]
