When testing against an "all" target build using jtreg or from
the command line, the tests pass.

As part of the "images" target, various files are copied from the classes
directory into rt.jar and tools.jar. In particular, JarSigner.class
and JarBASE64Encoder are moved into tools, but just JarBASE64Encoder
is moved into rt.jar. JarBASE64Encoder is a new class introduced in
6219522.

Now, if you run from the command line tests like
J2SE_TESTS/sun/security/tools/jarsigner/JarSigning.java against the
image build (including RE's distribution of b24 and earlier),
you'll get errors like:

Exception in thread "main" java.lang.NoClassDefFoundError: sun/security/tools/JarSigner
        at JarSigning.main(JarSigning.java:42)

But when using *JTREG* against the image file created by images
build target, apparently somehow the tools jar file is consulted. In
the pre-6219522 world, the classes needed by the test
were only in the tools.jar. But post-6219522, I believe we have a class
(JarBASE64Encoder) loaded by the bootstrap class
loader while the tools are being handled by some other
class loader, which is producing access nasty errors like:

TEST: jarsigner/JarSigning.java
JDK under test: (/home/wetmore/ws/int/ws/control/build/solaris-sparc/j2sdk-image)
java version "1.6.0-internal"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-internal-wetmore_04_Mar_2005_18_39)
Java HotSpot(TM) Server VM (build 1.6.0-ea-b26, mixed mode)

ACTION: build -- Passed. Compilation successful
REASON: Named class compiled on demand
TIME: 7.071 seconds

ACTION: compile -- Passed. Compilation successful
REASON: .class file out of date or does not exist
TIME: 7.065 seconds
STDOUT:
STDERR:
Note: /usr/security/ws/mustang-integrations/ws/test/foo/jarsigner/JarSigning.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.IllegalAccessError: tried to access class sun.security.tools.JarBASE64Encoder from class sun.security.tools.JarSigner
REASON: Assumed action based on file name: run main JarSigning
TIME: 2.494 seconds
STDOUT:
STDERR:
java.lang.IllegalAccessError: tried to access class sun.security.tools.JarBASE64Encoder from class sun.security.tools.JarSigner
        at sun.security.tools.JarSigner.signJar(JarSigner.java:875)
        at sun.security.tools.JarSigner.run(JarSigner.java:196)
        at sun.security.tools.JarSigner.main(JarSigner.java:75)
        at JarSigning.main(JarSigning.java:42)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:83)
        at java.lang.Thread.run(Thread.java:595)

JavaTest Message: Test threw exception: java.lang.IllegalAccessError: tried to access class sun.security.tools.JarBASE64Encoder from class sun.security.tools.JarSigner
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.IllegalAccessError: tried to access class sun.security.tools.JarBASE64Encoder from class sun.security.tools.JarSigner

TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.IllegalAccessError: tried to access class sun.security.tools.JarBASE64Encoder from class sun.security.tools.JarSigner
--------------------------------------------------

There are 4 J2SE regressions, 1 JSSE, and 1 JCE regression failures.

Is JarBASE64Encoder supposed to be added to the NotJRE list
in the make/common/Release.gmk build? Should you be specifying
-classpath tools.jar? These should be investigated.

Thanks,


###@###.### 2005-03-08 02:22:35 GMT