-
Notifications
You must be signed in to change notification settings - Fork 344
Support Java 10 for JPF CORE
jpf-core currently builds and runs on Java 8. In this work, we introduced partial support for Java 10, leveraging the new features like modularity, strong encapsulation, while also handling the deprecates and removes.
JEPs that introduce internal changes to JPF include, but not limited to:
- Project Jigsaw
- JEP 220: Modular Run-Time Images
- JEP 254: Compact Strings
- JEP 259: Stack-Walking API
- JEP 260: Encapsulate Most Internal APIs
- JEP 277: Enhanced Deprecation
- JEP 280: Indify String Concatenation
JDK Release Notes
Split packages are not allowed since Java 9's Project Jigsaw (packages having the same name exist in different modules). So in order to compile a model class we need to patch it. But since we had sources for multiple modules in the same tree in src/classes, we first separated them into directories based on their respective modules, for ease of compilation.
The new directory structure looks as follows:
├── classes
│ ├── gov
│ │ └── nasa
│ │ └── jpf
│ ├── modules
│ ├── java.base
│ │ ├── java
│ │ │ ├── io
│ │ │ ├── lang
│ │ ├── jdk
│ │ └── internal
│ └── java.logging
│ └── java
│ └── util
These are then compiled, as follows:
javac --patch-module java.base=src/classes/modules/java.base
java.logging=src/classes/modules/java.logging src/classes
Summary | PR(s) |
---|---|
Changes made to be able to successfully compile MJI model classes | #28 |
String model class is modified, to follow a structure similar to the standard String class in JDK 9 and later which uses a byte array plus an encoding-flag instead of UTF-16 char array to represent the String.
Summary | PR(s) |
---|---|
Update String model class to comply with JEP 254 | #39 |
Add support for Compact Strings | #119 |
Update String#length to comply with JEP 254 |
#129 |
Add package private constructor java.lang.String#String(byte[], byte)
|
#137 |
Add method java.lang.String.getBytes(byte[], int, byte)
|
#136 |
Remove invalid assertion in String#getBytes(byte[], int, byte)
|
#144 |
Implementation changes were also made to some of the methods that construct ElementInfo(s) for String objects, in gov.nasa.jpf.vm.GenericHeap, since the String#value
field, has changed from char[]
to a byte[]
Summary | PR(s) |
---|---|
Refactor other String related classes and methods to comply with JEP 254 | #133 |
Most methods in JPF_java_lang_String had failed as the value
field have changed from char[] to a byte[] since JEP 254. So instead of retrieving the value field, and performing operations on that value field to return a result (which is now complex as the value field now being a byte[] and having a coder which specifies different encodings), we turn JPF String object into a VM String object using MJIEnv.getStringObject
and then delegates the method call to that VM object.
Summary | Commit(s) |
---|---|
Refactor JPF_java_lang_String to fix invalid casting of value field | 1ccefdf |
Accessor methods that are being used to retrieve class URIs were modified to comply with the new URI structure introduced by the new Module System. The new path entry also includes a path segment that specifies the module name of that class.
Before:
/path/to/container/java/lang/Object.class
After:
/path/to/container/java.base/java/lang/Object.class
Summary | PR(s) |
---|---|
Update JVMClassFileContainer#getClassURL to comply with Module System | #100 |
Update JVMClassFileContainer#getModuleName | #121 |
As stated in the JDK 9 Release Notes the system property sun.boot.class.path
has been removed. Moreover, rt.jar has been removed since JEP 220 and is replaced by the new runtime. This causes JPF to fail resolve standard Java classes (classes that we don't have model classes for).
So if a class is not found in the classpath, now we try to load that class from the run-time image.
Summary | PR(s) |
---|---|
Add gov.nasa.jpf.jvm.JRTClassFileContainer | #102 |
Following PRs address UnsatisfiedLinkError(s) that appears due to missing NativePeer classes and NativePeer methods.
Summary | PR(s) |
---|---|
Add NativePeer JPF_java_lang_StringUTF16 | #117 |
Add NativePeer JPF_java_lang_StackStreamFactory | #122 |
Implement missing, and/or unlinked native methods in Unsafe | #105 |
Add NativePeer method for Reflection#getClassAccessFlags(Class) | #123 |
Rename JPF_sun_reflect_Reflection to JPF_jdk_internal_reflect_Reflection | #104 |
Rename JPF_sun_misc_VM to JPF_jdk_internal_misc_VM | #116 |
Changes made to MJI model classes, primarily to prevent NoSuchMethodError(s):
Summary | PR(s) |
---|---|
Add accessor methods for SharedSecrets#javaNetURLAccess | #110 |
Add accessor methods for SharedSecrets#javaObjectInputFilterAccess | #112 |
Add accessor methods for SharedSecrets#javaLangInvokeAccess | #131 |
Add java.lang.Class#getModule to MJI model class | #125 |
JEP 260 encapsulates most of the JDK's internal APIs, so that they are inaccessible by default. So to break the encapsulation, and to access them in non-modular context, --add-reads
, --add-exports
, or --add-opens
command-line options are being passed to relevant ant compile and run targets.
<compilerarg value="--add-exports"/>
<compilerarg value="java.base/jdk.internal.misc=ALL-UNNAMED"/>
Summary | PR(s) |
---|---|
Open jdk.internal.misc to UNNAMED module in tests | #108 |
Summary | Commit(s) |
---|---|
Modify ant target -compile-classes | 880b4ca |
JEP 277: Enhanced Deprecation had introduced several new compiler warnings. We were able to fix these warnings that had appeared in the build logs.
Summary | PR(s) |
---|---|
Suppress warnings with @SuppressWarnings annotation | #77 |
Remove explicit manual boxing in main, peers, and tests | #58 |
Suppress warnings in which Number constructor is used intentionally | #58 |
Add new auxiliary class EnumerationAdapter to ClassLoader | #92 |
Replaces all the occurrences of clazz.newInstance() | #66 |
Refactor URLClassLoaderTest.testGetPackage to testGetDefinedPackage | #80 |
To access caller information, StackWalking API is used instead of the non-standard sun.misc.SharedSecrets.
Summary | PR(s) |
---|---|
Use StackWalker instread of sun.misc.SharedSecrets | #24 |
Move/Refactor ReflectionTest -> StackWalkerTest | #83 |
Remove unused imports | #23 #26 #36 |
Add new entries to .gitignore to ignore IDE/OS and auto-generated files | #4 |
Setup Travis to automatically build against oracle-jdk 10 | #92 |
Remove methods that have been removed from JDK | #40 |
Override hashCode where equals are overridden | #86 |
Other | #63 |
JPF is yet to support indified String concatenation which was introduced in JEP 280. It will fail to handle invokedynamic calls to methods in StringConcatFactory which are typically used as bootstrap methods for invokedynamic call sites to support the string concatenation.
Work-in-progress
Issue: VMClassInfo$Initializer.setBootstrapMethod ArrayIndexOutOfBoundsException #53
Summary | PR(s) |
---|---|
Add a new constructor BootstrapMethodInfo(enclosingClass, cpArgs) | #101 |
Please contact us by creating an issue. We are trying to fix the process below, which no longer works.
-
How to obtain and install JPF
- System requirements
- Downloading
- Creating a site properties file
- Building, testing, and running
- JPF plugins
-
Developer guide
- Top-level design
- Key mechanisms
- Extension mechanisms
- Common utilities
- Running JPF from within your application
- Writing JPF tests
- Coding conventions
- Hosting an Eclipse plugin update site