But there really contains code about launcher in Harmony/luni, and this part is maintained by Harmony classlib but not VM. :)
On 10/19/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
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]
-- Leo Li China Software Development Lab, IBM