Added missing methods in jdk.internal.misc.Unsafe native peer. Few methods were deprecated and new methods were introduced in java-12. This patch includes the missing methods and its implementation in jdk.internal.misc.Unsafe native peer.

Fixed java.lang.String.computeStringHashCode native peer . Previously (in java 8 and lower versions), String values were stored as characters, and the string hash was computed as,

where s[i] was a character. This changed in java 9 and above versions, where s[i] is of type byte. Therefore, the existing logic didn't work since it tried to get char array instead of byte array. This PR fixed this issue by changing the logic to get byte array.

Added and implemented checkOutOffBounds method in java.lang.String model class. checkOutOffBounds method checks for StringIndexOutOfBoundsException by checking if the string offset is negative or greater than the string length.

Since module system was introduced in java 9, the accessibilty of classes entirely depends on the modules instead of packages. Modularity adds a higher level of aggregation above packages. With module system, all the classes are dependent on the module info. Every class has its own module info. Module info contains details about class module. One such case which caused issue in JPF is Package.getPackages.

Package.getPackages inernally calls the Module class method which again calls Package class, and as a result of mutual dependency between the two classes, the call to Package.getPackges was going into an infinite loop, causing a StackOverFlowError.

This issue occured because the logic in setting bootstrap method (JVMClassInfo.setBootstrapMethod) to get enclosing lambda or class, was unable to partially resolve the classes. Hence everytime when enclosing class was not found, the class of again loaded if not already resolved. In this case, before Package class getting fully resolved, the Module class was called which again was not resolved. Hence resulted to infinte loop.

This issue was fixed by adding model class for Module class. Since the model classes are already resolved at JPF load time, when Package class calls Module class, the ClassLoader fetches the resolved model class.

Another issue related to Package class was, package version info initialization. A few fields related to Package were missing and were moved to the inner class VersionInfo of Package class. This issue was fixed by resolving VersionInfo class and initializing the fields in this class.

Added and implemented missing methods getDefinedPackage and getDefinedPackages in java.lang.ClassLoader model and native peer classes

ClassLoader.getResource was failing to fetch resource as the class path was missing module path. Fixed this issue by adding module path to class path.

Modified ClassLoader.getResources method logic. The ClassLoader.getResources method returns an Enumeration. Previously, the method used an ArrayList to store the resource URLs and converted the ArrayList to Enumeration, which was returned by the method. The URLs were not able to be added because of type mismatch which occured due to the changes in host JVM's implementation.

This issue was fixed by storing the resource URL's in an Enumeration insted of storing it in an ArrayList and return the Enumeration instead the converting Arraylist to Enumeration and returning it.

Removed model class for Module class and added logic to get partially resolved classes when seting bootstrap method (inJVMClassInfo.setBootstrapMethod).

Also, added Class.getModuleName method to model and native peer classes to get module name of a class. The method is implemented in the native peer to make use of the host JVM's Class.getModule. Using Class.getModule, and based on whether the resolved or loaded class is a JPF class or not, the module name was added to the class path in Class.getResource accordingly. This fixed the issue with Class.getResource method.

Added getUnalignedLong method to jdk.internal.misc.Unsafe class native peer. The implementation of Arrays.equals was changed since java 9. It leverages vector-based techniques to access and compare the contents of two arrays (to make the comparison efficient). To access the contents of the array, Unsafe.getLongUnaligned is used. This method uses Unsafe.getLong to get value of the array based on the offset value.

Since, the type of the array was not long, JPF was throwing an exception. This was becasue the offset value passed to Unsafe.getLongUnaligned method was the index of the array instead of the offset value. The offset value should have been,

Hence Unsafe.getLongUnaligned logic was not woking as expected. And since the method calculating is a host JVM class, the solution to this issue was to add and implement Unsafe.getLongUnaligned in Unsafe native peer class. The native peer method, uses the type of the array instead of offset to return the right value.

Class.newInstance was deprecated in Java 9. It can be replaced by clazz.getDeclaredConstructor().newInstance(). But the problem is that getDeclaredConstructor returns any constructor without regarding the access level. Hence, clazz.getDeclaredConstructor().newInstance() was not throwing any exception when instance of inaccessible constructors were created as JPF's implementaton of Constructor.newInstance was not checking access levels of constructors.

Fixed this issue by adding logic to check access level of the caller class in Constructor.newInstance native peer.