Skip to content

Latest commit

 

History

History
246 lines (181 loc) · 15.1 KB

Support-Java-10-for-JPF-CORE.md

File metadata and controls

246 lines (181 loc) · 15.1 KB
Raw

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:

JDK Release Notes

Compiling MJI model classes

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

Update MJI model class for java.lang.String to comply with JEP 254

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

Update NativePeer class for java.lang.String to comply with JEP 254

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

Changes to class URI(s)

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

New JRTClassFileContainer to load classes from the run-time image

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

Changes to NativePeer classes

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 to MJI model classes

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

Handling Access Warnings

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

Deprecations in the JDK

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

Miscellaneous

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

Currently unsupported features

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