Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

error: [junit] cannot load system class java.lang.Object #50

Closed
gayanW opened this issue May 21, 2018 · 5 comments
Closed

error: [junit] cannot load system class java.lang.Object #50

gayanW opened this issue May 21, 2018 · 5 comments

Comments

@gayanW
Copy link
Collaborator

gayanW commented May 21, 2018 •
edited
Loading

When running tests compiled with Java 9 and later, results in the run time errors look like the following:

[junit] Picked up _JAVA_OPTIONS: -Xmx2048m -Xms512m
[junit] Running TypeNameTest
[junit]   running jpf with args:
[junit] [SEVERE] cannot load system class java.lang.Object
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.521 sec
[junit] gov.nasa.jpf.vm.ClassInfoException: class not found: java.lang.Object
[junit] 	at gov.nasa.jpf.vm.ClassLoaderInfo.getResolvedClassInfo(ClassLoaderInfo.java:363)
[junit] 	at gov.nasa.jpf.vm.SystemClassLoaderInfo.getResolvedClassInfo(SystemClassLoaderInfo.java:147)
[junit] 	at gov.nasa.jpf.vm.VM.getStartupSystemClassInfos(VM.java:445)
[junit] 	at gov.nasa.jpf.vm.VM.initializeMainThread(VM.java:564)
[junit] 	at gov.nasa.jpf.vm.SingleProcessVM.initialize(SingleProcessVM.java:130)
[junit] 	at gov.nasa.jpf.JPF.run(JPF.java:611)
[junit] 	at gov.nasa.jpf.util.test.TestJPF.createAndRunJPF(TestJPF.java:675)
[junit] 	at gov.nasa.jpf.util.test.TestJPF.noPropertyViolation(TestJPF.java:806)
[junit] 	at gov.nasa.jpf.util.test.TestJPF.verifyNoPropertyViolation(TestJPF.java:830)
[junit] 	at TypeNameTest.testArrayCloning(TypeNameTest.java:58)

Possibly because of the new Module System, the class URI of the generated .class files in the build destination directory are different than previously, which makes JPF classloader to fail resolve the model classes from jpf-classes.jar

JDK 8

build/classes/
├── java
│   ├── io
│   ├── lang
│   │   ├── annotation
│   │   ├── ref
│   │   └── reflect

JDK 9/10

build/classes/
├── java.base
│   ├── java
│   │   ├── io
│   │   ├── lang
│   │   │   ├── annotation
│   │   │   ├── ref
│   │   │   └── reflect

https://travis-ci.org/javapathfinder/jpf-core/builds/381450375#L3059-L3073
gayanW added a commit to gayanW/jpf-core that referenced this issue May 21, 2018
@gayanW
Rearrange class files in jpf-classes.jar
f4f2c63 
Before Java module system (introudced in JDK 9), once compiled, all
compiled classes are nested inside the destination directory, based on
their respective packages. So for instance,

build/classes/
├── java
│   ├── io
│   ├── lang
│   │   ├── annotation
│   │   ├── ref
│   │   └── reflect

But when compiled with Java 9/10, directory structure of the destination
directory for the generated class files is as follows.

build/classes/
├── java.base
│   ├── java
│   │   ├── io
│   │   ├── lang
│   │   │   ├── annotation
│   │   │   ├── ref
│   │   │   └── reflect

So if we are to include classes from build/classes directory as a
fileset into jpf-classes.jar, as done previously, like:
    <jar jarfile="build/jpf-classes.jar">
      <fileset dir="build/classes"/>

.. JPF classloader will fail to resolve the model classes, because the
class urls are different than previously.

[junit] gov.nasa.jpf.vm.ClassInfoException: class not found: java.lang.Object
 at gov.nasa.jpf.vm.ClassLoaderInfo.getResolvedClassInfo(ClassLoaderInfo.java:363)
 at gov.nasa.jpf.vm.SystemClassLoaderInfo.getResolvedClassInfo(SystemClassLoaderInfo.java:147)
 [SEVERE] cannot load system class java.lang.Object

So this restructure the files in jpf-classes.jar (same as before)
without introducing any implementation changes to the code.

Fixes: javapathfinder#50
gayanW added a commit to gayanW/jpf-core that referenced this issue May 21, 2018
@gayanW
Rearrange class files in jpf-classes.jar
a153214 
Before Java module system (introduced in JDK 9), once compiled, all
compiled classes are nested inside the destination directory, based on
their respective packages. So for instance,

build/classes/
├── java
│   ├── io
│   ├── lang
│   │   ├── annotation
│   │   ├── ref
│   │   └── reflect

But when compiled with Java 9/10, directory structure of the destination
directory for the generated class files is as follows.

build/classes/
├── java.base
│   ├── java
│   │   ├── io
│   │   ├── lang
│   │   │   ├── annotation
│   │   │   ├── ref
│   │   │   └── reflect

So if we are to include classes from build/classes directory as a
fileset into jpf-classes.jar, as done previously, like:
    <jar jarfile="build/jpf-classes.jar">
      <fileset dir="build/classes"/>

.. JPF classloader will fail to resolve the model classes, because the
class urls are different than previously.

[junit] gov.nasa.jpf.vm.ClassInfoException: class not found: java.lang.Object
 at gov.nasa.jpf.vm.ClassLoaderInfo.getResolvedClassInfo(ClassLoaderInfo.java:363)
 at gov.nasa.jpf.vm.SystemClassLoaderInfo.getResolvedClassInfo(SystemClassLoaderInfo.java:147)
 [SEVERE] cannot load system class java.lang.Object

So this restructure the files in jpf-classes.jar (same as before)
without introducing any implementation changes to the code.

Fixes: javapathfinder#50
@gayanW gayanW mentioned this issue May 21, 2018
Merged
@cyrille-artho
Copy link
Member

Thanks!
Your patch includes, in addition to java.base, also java.logging and "gov/nasa/jpf/.class", "org/junit/.class". Are those also necessary? Will the test(s) run successfully without them?
I am rather reluctant with putting JUnit's classes into jpf-classes.jar (that's not where they should be), and I think the same goes for JPF's classes.

@gayanW
Copy link
Collaborator Author

gayanW commented May 21, 2018 •
edited
Loading

@cyrille-artho
I think you're right. So I ran tests with Java 8 on the master branch without including either 'gov/nasa/jpf/.class', or JUnit classes into jpf-classes.jar. And it didn't make any difference to the test results. They all do pass as before. I'm not sure why these being added before though.

@cyrille-artho
Copy link
Member

Sorry to appear to be nitpicking, but can you please try to remove the line removal on line 431? This creates a second hunk in the patch. Simply add an empty line again, and the resulting pull request will be smaller.
In general, patches without white space changes are easier to merge and handle.

gayanW added a commit to gayanW/jpf-core that referenced this issue May 22, 2018
@gayanW
Rearrange class files in jpf-classes.jar
7291a7e 
Before Java module system (introduced in JDK 9), once compiled, all
compiled classes are nested inside the destination directory, based on
their respective packages. So for instance,

build/classes/
├── java
│   ├── io
│   ├── lang
│   │   ├── annotation
│   │   ├── ref
│   │   └── reflect

But when compiled with Java 9/10, directory structure of the destination
directory for the generated class files is as follows.

build/classes/
├── java.base
│   ├── java
│   │   ├── io
│   │   ├── lang
│   │   │   ├── annotation
│   │   │   ├── ref
│   │   │   └── reflect

So if we are to include classes from build/classes directory as a
fileset into jpf-classes.jar, as done previously, like:
    <jar jarfile="build/jpf-classes.jar">
      <fileset dir="build/classes"/>

.. JPF classloader will fail to resolve the model classes, because the
class urls are different than previously.

[junit] gov.nasa.jpf.vm.ClassInfoException: class not found: java.lang.Object
 at gov.nasa.jpf.vm.ClassLoaderInfo.getResolvedClassInfo(ClassLoaderInfo.java:363)
 at gov.nasa.jpf.vm.SystemClassLoaderInfo.getResolvedClassInfo(SystemClassLoaderInfo.java:147)
 [SEVERE] cannot load system class java.lang.Object

So this restructure the files in jpf-classes.jar (same as before)
without introducing any implementation changes to the code.

Fixes: javapathfinder#50
@gayanW
Copy link
Collaborator Author

gayanW commented May 22, 2018

Np. Done.

cyrille-artho pushed a commit that referenced this issue May 22, 2018
@gayanW @cyrille-artho
Rearrange class files in jpf-classes.jar (#51)
1e02daf 
* Rearrange class files in jpf-classes.jar: Change java/x to java.base/java/x.

Fixes: #50

* Exclude JPF and JUnit classes from jpf-classes.jar
@cyrille-artho
Copy link
Member

cyrille-artho commented May 22, 2018 via email

gayanW added a commit to gayanW/jpf-core that referenced this issue Jul 10, 2018
@gayanW
Update JarClassFileContainer to comply with new class URI structure
5b688be 
This is related to the issue javapathfinder#50 which is about JPF failing to load
model classes from jpf-classes.jar due to different URI structure of the
.class files being introuduced in Java Module System.

The previous workaround introudced by the PR javapathfinder#51 is specifically for the
jpf-classes.jar And JPF will still fail to locate classes from the other
jar files.

Thus this reverts it. And make a implementation changes to
JarClassFileContainer which is JPF's universal continer for loading
classes from any jar file.
@gayanW gayanW mentioned this issue Jul 15, 2018
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@gayanW @cyrille-artho