harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm] Signed jars cannot be used in classpath
Date Wed, 05 Jul 2006 00:00:34 GMT
On Tuesday 04 July 2006 14:00 Alexey Varlamov wrote:
> > > This is AFAIK something that drlvm doesn't have in kernel classes at
> > > the moment. I think the correct way to fix the problem would be to add
> > > one and invoke it somehow... but I don't really know the subtleties of
> > > classloader hierarchy so I am not sure how and when it should be
> > > invoked.
> >
> > Hmm, yes that is something that needs fixing.
>
> I volunteer to look into this.

It looks like the most recent changes to classlib in file operations created 
an unresolved bootstrap dependency if security/ directory with its rules and 
policies is copied from classlib's lib/ to drlvm lib/ directory. In this case 
security cannot initialize correctly because the field 
FileInputStream.fileSystem is null at the moment when it is needed. Stack 
trace looks like this:

****** STACK DUMP: ************
java/io/FileInputStream.<init>(Ljava/io/File;)V (FileInputStream.java:66)
java/security/Security$1.run()Ljava/lang/Object; (Security.java:113)
java/security/AccessController.doPrivilegedImpl(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;

(NULL:-1)
java/security/AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;

(NULL:-1)
java/security/Security.<clinit>()V (Security.java:116)
org/apache/harmony/security/fortress/PolicyUtils$SecurityPropertyAccessor.run()Ljava/lang/String;

(PolicyUtils.java:148)
org/apache/harmony/security/fortress/PolicyUtils$SecurityPropertyAccessor.run()Ljava/lang/Object;

(PolicyUtils.java:127)
java/security/AccessController.doPrivilegedImpl(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;

(NULL:-1)
java/security/AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;

(NULL:-1)
java/security/Policy.getDefaultProvider()Ljava/security/Policy; 
(Policy.java:150)
java/security/Policy.getAccessiblePolicy()Ljava/security/Policy; 
(Policy.java:195)
java/security/Policy.getPolicy()Ljava/security/Policy; (Policy.java:131)
java/lang/ClassLoader.<clinit>()V (NULL:-1)
java/lang/Class.desiredAssertionStatus()Z (NULL:-1)
java/util/HashMap.<clinit>()V (HashMap.java:27)
org/apache/harmony/luni/platform/AdapterManager.<init>()V 
(AdapterManager.java:34)
org/apache/harmony/luni/platform/Platform.<clinit>()V (Platform.java:34)
java/io/FileOutputStream.<init>(Ljava/io/FileDescriptor;)V 
(FileOutputStream.java:119)
java/lang/System.createErr()Ljava/io/PrintStream; (NULL:-1)
java/lang/System.<clinit>()V (NULL:-1)
java/lang/Thread.<init>(Ljava/lang/ThreadGroup;Ljava/lang/Runnable;Ljava/lang/String;J)V

(NULL:-1)
java/lang/Thread.<init>()V (NULL:-1)

At first I was curious as to why FileInputStream.<clinit> is not in the stack, 
but I did bytecode dump and found that Sun's javac 1.5 optimized <init> 
methods to include <clinit> code into them. So it included line

private IFileSystem fileSystem = Platform.getFileSystem();

into constructor's code and so the value of IFileSystem FILE_SYSTEM from 
Platform was returned. But since Platform.<clinit> is clearly in the stack, 
Platform's <clinit> was not finished yet by that time. Dumping bytecode for 
compiled Platform shows that line 34 is really the assignment of constant 
NETWORK_SYSTEM which turns out to be null later down the stack.

This is a quite fundamental problem with classlib's bootstrap and we don't 
have any defined bootstrap sequence. When something is initialized in 
<clinit> there is no way to be 100% sure it is really initialized in many 
classes which are commonly used because <clinit> is called only once and 
bootstrap recursion may get to call some methods of a class before <clinit> 
actually completes. The workaround for this is instead of using

    Whatever WHATEVER1 = Something.something();
or

    Whatever WHATEVER2 = new Whatever();

do the following

    method() {
        if (WHATEVER1 == null)
            WHATEVER1 = Something.something();

        if (WHATEVER2 == null)
            WHATEVER2 = new Whatever();
    }

but this is ugly, inefficient and my in theory turn classlib bootstrap into 
infinite recursion.

I don't know a general solution for this. The order of class resolution, java 
compiler optimizations and other factors may affect the bootstrap sequence.

-- 
Gregory Shimansky, Intel Middleware Products Division

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