Addressing Deprecated API Usage: public static SecurityManager getSecurityManager() {....} has been deprecated since Java 17

[eklaDFF]

While compiling the current version of JPF on Java 17, there is failure while compiling. The reason is, current JPF uses a API which has been deprecated since Java 17.

Here is the deprecated API public static SecurityManager getSecurityManager() {....}

[cyrille-artho]

Can you please give some more information? Are there other APIs that have been removed that JPF for Java 11 is using right now? How many usages of these APIs are in the source code? What is the suggested replacement for such APIs?

[eklaDFF]

/Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/sun/reflect/annotation/AnnotationType.java:28: error: cannot access SharedSecrets import jdk.internal.misc.SharedSecrets; ^ bad source file: /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java file does not contain class jdk.internal.misc.SharedSecrets Please remove or make sure it appears in the correct subdirectory of the sourcepath. /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:55: error: cannot find symbol private static JavaUtilJarAccess javaUtilJarAccess; ^ symbol: class JavaUtilJarAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:56: error: cannot find symbol private static JavaLangAccess javaLangAccess; ^ symbol: class JavaLangAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:57: error: cannot find symbol private static JavaLangInvokeAccess javaLangInvokeAccess; ^ symbol: class JavaLangInvokeAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:58: error: cannot find symbol private static JavaIOAccess javaIOAccess; ^ symbol: class JavaIOAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:59: error: cannot find symbol private static JavaNetURLAccess javaNetURLAccess; ^ symbol: class JavaNetURLAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:61: error: cannot find symbol private static JavaNetAccess javaNetAccess; ^ symbol: class JavaNetAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:62: error: cannot find symbol private static JavaIOFileDescriptorAccess javaIOFileDescriptorAccess; ^ symbol: class JavaIOFileDescriptorAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:63: error: cannot find symbol private static JavaNioAccess javaNioAccess; ^ symbol: class JavaNioAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:64: error: cannot find symbol private static JavaAWTAccess javaAWTAccess; ^ symbol: class JavaAWTAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:65: error: cannot find symbol private static JavaObjectInputStreamAccess javaObjectInputStreamAccess; ^ symbol: class JavaObjectInputStreamAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:66: error: cannot find symbol private static JavaObjectInputFilterAccess javaObjectInputFilterAccess; ^ symbol: class JavaObjectInputFilterAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:67: error: cannot find symbol private static JavaObjectInputStreamReadString javaObjectInputStreamReadString; ^ symbol: class JavaObjectInputStreamReadString location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:70: error: cannot find symbol public static JavaLangAccess getJavaLangAccess() { ^ symbol: class JavaLangAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:74: error: cannot find symbol public static void setJavaLangAccess(JavaLangAccess jla) { ^ symbol: class JavaLangAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:78: error: cannot find symbol public static void setJavaLangInvokeAccess(JavaLangInvokeAccess jlia) { ^ symbol: class JavaLangInvokeAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:82: error: cannot find symbol public static JavaLangInvokeAccess getJavaLangInvokeAccess() { ^ symbol: class JavaLangInvokeAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:93: error: cannot find symbol public static void setJavaNetAccess(JavaNetAccess jna) { ^ symbol: class JavaNetAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:97: error: cannot find symbol public static JavaNetAccess getJavaNetAccess() { ^ symbol: class JavaNetAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:101: error: cannot find symbol public static void setJavaNetURLAccess(JavaNetURLAccess jnua) { ^ symbol: class JavaNetURLAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:105: error: cannot find symbol public static JavaNetURLAccess getJavaNetURLAccess() { ^ symbol: class JavaNetURLAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:111: error: cannot find symbol public static JavaUtilJarAccess javaUtilJarAccess() { ^ symbol: class JavaUtilJarAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:117: error: cannot find symbol public static void setJavaUtilJarAccess(JavaUtilJarAccess access) { ^ symbol: class JavaUtilJarAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:122: error: cannot find symbol public static void setJavaIOAccess(JavaIOAccess jia) { ^ symbol: class JavaIOAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:128: error: cannot find symbol public static JavaIOAccess getJavaIOAccess() { ^ symbol: class JavaIOAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:137: error: cannot find symbol public static void setJavaNioAccess(JavaNioAccess a) { ^ symbol: class JavaNioAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:140: error: cannot find symbol public static JavaNioAccess getJavaNioAccess() { ^ symbol: class JavaNioAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:148: error: cannot find symbol public static void setJavaIODeleteOnExitAccess(JavaIODeleteOnExitAccess jida) { ^ symbol: class JavaIODeleteOnExitAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:152: error: cannot find symbol public static JavaIODeleteOnExitAccess getJavaIODeleteOnExitAccess() { ^ symbol: class JavaIODeleteOnExitAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:159: error: cannot find symbol public static void setJavaIOFileDescriptorAccess(JavaIOFileDescriptorAccess jiofda) { ^ symbol: class JavaIOFileDescriptorAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:162: error: cannot find symbol public static JavaIOFileDescriptorAccess getJavaIOFileDescriptorAccess() { ^ symbol: class JavaIOFileDescriptorAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:171: error: cannot find symbol public static JavaObjectInputStreamAccess getJavaObjectInputStreamAccess() { ^ symbol: class JavaObjectInputStreamAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:180: error: cannot find symbol public static void setJavaObjectInputStreamAccess(JavaObjectInputStreamAccess access) { ^ symbol: class JavaObjectInputStreamAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:184: error: cannot find symbol public static JavaObjectInputFilterAccess getJavaObjectInputFilterAccess() { ^ symbol: class JavaObjectInputFilterAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:191: error: cannot find symbol public static void setJavaObjectInputFilterAccess(JavaObjectInputFilterAccess access) { ^ symbol: class JavaObjectInputFilterAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:195: error: cannot find symbol public static void setJavaAWTAccess (JavaAWTAccess jaa){ ^ symbol: class JavaAWTAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:198: error: cannot find symbol public static JavaAWTAccess getJavaAWTAccess(){ ^ symbol: class JavaAWTAccess location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:202: error: cannot find symbol public static JavaObjectInputStreamReadString getJavaObjectInputStreamReadString() { ^ symbol: class JavaObjectInputStreamReadString location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:209: error: cannot find symbol public static void setJavaObjectInputStreamReadString(JavaObjectInputStreamReadString access) { ^ symbol: class JavaObjectInputStreamReadString location: class SharedSecrets /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/java/lang/String.java:149: error: cannot find symbol StringCoding.Result result = StringCoding.decode(cset, x, offset, length); ^ symbol: class Result location: class StringCoding /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/java/lang/String.java:149: error: cannot find symbol StringCoding.Result result = StringCoding.decode(cset, x, offset, length); ^ symbol: method decode(Charset,byte[],int,int) location: class StringCoding /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/java/lang/String.java:246: error: cannot find symbol return StringCoding.encode(x, coder(), value); ^ symbol: method encode(Charset,byte,byte[]) location: class StringCoding /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/sun/reflect/annotation/AnnotationType.java:52: error: cannot find symbol AnnotationType at = SharedSecrets.getJavaLangAccess().getAnnotationType(annotationClass); ^ symbol: variable SharedSecrets location: class AnnotationType /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/sun/reflect/annotation/AnnotationType.java:97: error: cannot find symbol SharedSecrets.getJavaLangAccess().setAnnotationType(annoCls, this); ^ symbol: variable SharedSecrets location: class AnnotationType /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:86: warning: [removal] ensureClassInitialized(Class<?>) in Unsafe has been deprecated and marked for removal unsafe.ensureClassInitialized(c); ^ /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:107: warning: [removal] ensureClassInitialized(Class<?>) in Unsafe has been deprecated and marked for removal unsafe.ensureClassInitialized(java.net.URL.class); ^ /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:113: warning: [removal] ensureClassInitialized(Class<?>) in Unsafe has been deprecated and marked for removal unsafe.ensureClassInitialized(JarFile.class); ^ /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:154: warning: [removal] ensureClassInitialized(Class<?>) in Unsafe has been deprecated and marked for removal unsafe.ensureClassInitialized(File.class); ^ /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:164: warning: [removal] ensureClassInitialized(Class<?>) in Unsafe has been deprecated and marked for removal unsafe.ensureClassInitialized(FileDescriptor.class); ^ /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:173: warning: [removal] ensureClassInitialized(Class<?>) in Unsafe has been deprecated and marked for removal unsafe.ensureClassInitialized(ObjectInputStream.class); ^ /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:186: warning: [removal] ensureClassInitialized(Class<?>) in Unsafe has been deprecated and marked for removal unsafe.ensureClassInitialized(ObjectInputFilter.Config.class); ^ /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java:204: warning: [removal] ensureClassInitialized(Class<?>) in Unsafe has been deprecated and marked for removal unsafe.ensureClassInitialized(ObjectInputStream.class); ^ /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/java/lang/System.java:68: error: cannot find symbol SharedSecrets.setJavaLangAccess( createJavaLangAccess()); ^ symbol: variable SharedSecrets location: class System /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/java/lang/System.java:168: warning: [removal] SecurityManager in java.lang has been deprecated and marked for removal static SecurityManager securityManager; ^ /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/java/lang/System.java:170: warning: [removal] SecurityManager in java.lang has been deprecated and marked for removal public static void setSecurityManager (SecurityManager newManager) { ^ /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/java/lang/System.java:174: warning: [removal] SecurityManager in java.lang has been deprecated and marked for removal public static SecurityManager getSecurityManager() { ^

[eklaDFF]

Major Problem is due to the SharedSecrets class. And also some are marked for removal.

[eklaDFF]

SharedScerects class have 5 usage

[cyrille-artho]

Well, SharedSecrets is a major source of incompatibilities between OpenJDK and Oracle's JDK. So I'm quite happy if we can get rid of it when supporting newer versions of Java. The question is how complex the new APIs are and how hard it will be to support them.

[cyrille-artho]

Maybe your OpenJDK 11 version is too old. Mine is from 2024 (but one from 2023 definitely works as well):

$ java -version
openjdk version "11.0.22" 2024-01-16
OpenJDK Runtime Environment (build 11.0.22+7)
OpenJDK 64-Bit Server VM (build 11.0.22+7, mixed mode)

[eklaDFF]

Is your OpenJDK "Microsoft" build or "oracle" ?

And please let me know for the above screenshot attached for the package declaration problem too

below the reference

[cyrille-artho]

In my case, I use the build from Mac Ports. Yes, the JRE has to match the JDK, otherwise, almost no Java program you compile will run (on a different environment than what it was compiled for).

[cyrille-artho]

From your screenshot above, it looks like IntelliJ is not intelligent enough to understand the full source file structure. Just use Gradle from the command line to compile JPF and bin/jpf to run it, and it should work with no problems.

[eklaDFF]

Hi Sir, your guide was helpful. Now I am correctly analysing the compilation error causing points in Java 17. I have installed both Java 11 and 17 from MacPorts. And building on Java 11 was successful. (via Gradle in Command line)

Should I delete some the comments in this issue to make it clean ?

& I will come up with your question about complexity for new supporting APIs .

[eklaDFF]

Hi @cyrille-artho , While searching for the first error "JavaUtilJarAccess" in both Java 11 and Java 17 (openjdk) source code, found that this is an interface and moved to "jdk17u-dev/src/java.base/share/classes/jdk/internal/access/JavaUtilJarAccess.java" from "jdk11u-dev/src/java.base/share/classes/jdk/internal/misc/JavaUtilJarAccess.java"

Do you think that it is creating the problem ?

[cyrille-artho]

No, simply renaming the package declaration and moving the class to the right place will fix this. However, other errors may appear after that change. Essentially, you have to resolve them one by one until you can run the tests, and once you can run the tests, many are likely going to fail under Java 17. At that point, the procedure repeats: you analyze the root cause of some selected test failures and try to fix it, which makes more tests succeed. Eventually, you have fixed all tests. For Java 11, this took a couple of years, but I hope the changes from Java 11 to Java 17 are smaller, so at least getting the regression tests to work should be easier. We'll still have to support some popular new language features for Java 17, at some point.

[cyrille-artho]

Hi Sir, your guide was helpful. Now I am correctly analysing the compilation error causing points in Java 17. I have installed both Java 11 and 17 from MacPorts. And building on Java 11 was successful. (via Gradle in Command line)

Should I delete some the comments in this issue to make it clean ?

& I will come up with your question about complexity for new supporting APIs .

Removing some comments referring to Java 11 would probably be helpful, so we can focus on Java 17 here.

[eklaDFF]

Which IDE should I use ? As you see how IntelliJ was indicating error for package declaration in the Screenshot. Is your Eclipse ?

[cyrille-artho]

I don't use an IDE, but I compile JPF with Gradle from the command line. Different IDEs have just too many settings that are hard to control, so it is not feasible to support all of them. A command-line-based build is always reliable and reproducible (given that the dependencies are met).

[eklaDFF]

I was asking for an editor where I could rewrite the code only. While compiling I will use the Command Line.

[cyrille-artho]

We don't have any particular preference. Many of us use vim. You can use any editor you like, but some editors who try to compile and analyze the code may get confused by the fact that we have "model classes" that replace Java library classes at run time for the application that JPF runs, but JPF itself still uses the regular Java library classes of the host JVM. Any discrepancies between our model classes and the library classes of the host JVM may result in "red code" in an IDE. As long as you can still work with the rest of the code base, this is not a problem, but for the model classes, some help or autocomplete features may not work correctly (and even insert incorrect code).

[eklaDFF]

Hi @cyrille-artho , I have changed the directory with "access" and then complied them on Java 17. Below is the fresh compilation errors

Task :compileClassesJava FAILED /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/java/lang/String.java:149: error: cannot find symbol StringCoding.Result result = StringCoding.decode(cset, x, offset, length); ^ symbol: class Result location: class StringCoding /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/java/lang/String.java:149: error: cannot find symbol StringCoding.Result result = StringCoding.decode(cset, x, offset, length); ^ symbol: method decode(Charset,byte[],int,int) location: class StringCoding /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/java/lang/String.java:246: error: cannot find symbol return StringCoding.encode(x, coder(), value); ^ symbol: method encode(Charset,byte,byte[]) location: class StringCoding /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/java/lang/System.java:168: warning: [removal] SecurityManager in java.lang has been deprecated and marked for removal static SecurityManager securityManager; ^ /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/java/lang/System.java:170: warning: [removal] SecurityManager in java.lang has been deprecated and marked for removal public static void setSecurityManager (SecurityManager newManager) { ^ /Users/ekla/GSOC/jpf-core/src/classes/modules/java.base/java/lang/System.java:174: warning: [removal] SecurityManager in java.lang has been deprecated and marked for removal public static SecurityManager getSecurityManager() { ^

There is two different types of error. One is for use of deprecated API "SecurityManager" and other is "StringCoding.Result". Currently focusing on "StringCoding.Result", found that in openjdk11 there is "StringCoding.Result" defined but in openjdk17 only "StringCoding" is defined without subclass "Result". How should be resolve it, should we think to create one our own ?

[eklaDFF]

@cyrille-artho , please let me know, till I am searching for any documentation related to subclass "Result" removal.

[eklaDFF]

"StringCoding" class is used to encode and decode the String (i.e. byte[ ]). Now trying to understand that how can we use the only there methods present there (in openjdk17).

`class StringCoding {

private StringCoding() { }

@IntrinsicCandidate
public static boolean hasNegatives(byte[] ba, int off, int len) {
    for (int i = off; i < off + len; i++) {
        if (ba[i] < 0) {
            return true;
        }
    }
    return false;
}

@IntrinsicCandidate
public static int implEncodeISOArray(byte[] sa, int sp,
                                     byte[] da, int dp, int len) {
    int i = 0;
    for (; i < len; i++) {
        char c = StringUTF16.getChar(sa, sp++);
        if (c > '\u00FF')
            break;
        da[dp++] = (byte)c;
    }
    return i;
}

@IntrinsicCandidate
public static int implEncodeAsciiArray(char[] sa, int sp,
                                       byte[] da, int dp, int len)
{
    int i = 0;
    for (; i < len; i++) {
        char c = sa[sp++];
        if (c >= '\u0080')
            break;
        da[dp++] = (byte)c;
    }
    return i;
}

} `

[eklaDFF]

@cyrille-artho , Please correct me if my analysis is wrong.

Any String is in either UTF or ASCII encoded. So, using implEncodeAsciiArray(.......) method, we can encode a UTF coded String to ASCII coded (and it will be termed as decoding of UTF coded string). And using implEncodeISOArray(........) method, we can encode a ASCII coded String to UTF coded String (and it will be termed as decoding of ASCII coded string)

[cyrille-artho]

Hi Ekla, According to what I know, Java 11 introduced a variable string encoding that is either ISO-8859-1 (a superset of ASCII that includes many languages from Western Europe) or UTF-8. UTF-8 can encode any string but requires more memory. This applies to strings in memory. String encodings are a bit complicated in Java; their encoding in the bytecode (.class files) differs from their encoding in memory, which may (for some JDKs and platforms) differ from how they are written to a file. For JPF, we do not necessarily have to support a memory-efficient encoding, but the model classes have to behave consistently w.r.t. the regular JDK.

[eklaDFF]

Hi @cyrille-artho , GSOC proposal submission has been started. I want to apply for this as proposal. Let me know what should I mentioned for higher acceptance. And also I have created a proposal, should I send you ?

[cyrille-artho]

In general, the main criterion that we apply for a proposal is the chance of success. Factors that are indicative of that are the quality of the proposal, the quality of reports on the issue tracker, and the quality (and existence of) prior pull requests. The latter is the most relevant criterion. A prior PR does not necessarily have to relate directly to the proposal.

[eklaDFF]

So, should I implement above method (StringCoding methods) to resolve the error ? If the effect will be undesirable, we will re consider it later.

[cyrille-artho]

Yes, please try this. We will only really see what side-effects changing that method has once we try it. It is possible that all existing tests pass with the change, but that the functionality is not well tested with the current test suite. If that seems to be the case, think about a possible unit test or two that can enhance the coverage of how string encodings are tested.

[eklaDFF]

While implementing the given methods in StringCoding class, we have encountered variable initialisation problem.

/Users/ekla/GSOC/JPFjava17/jpf-core/src/classes/modules/java.base/java/lang/String.java:164: error: variable value might not have been initialized } ^

Apart from this, I have noticed that in current jpf version there is huge similarity between jpf's defined String class and jdk11's defined String class. It seems that the jpf's String class have been adjusted for jdk11 String class. Is it would be good to try the same for jdk17 ?

[cyrille-artho]

Hi, Yes, sometimes we have to adapt our model class to remain compatible with changes in the JDK. It looks like value is always initialized in one of the constructors. Use a compiler that does not try an imprecise static analysis on the code, and the code should compile.

[eklaDFF]

Hi @cyrille-artho , I have tried to adapt our model class 'String' to make compatible with Java 17.

We getting new errors at import statement .

Why the model class 'Unsafe' is not imported ?

[cyrille-artho]

I think Unsafe has been deprecated and removed with JDK 17. Please look to see how it can be replaced; it is possible that the functionality of Unsafe is now handled by several classes, and Random likely uses only a few of its methods, so we only need to find a way to replace these.

[eklaDFF]

Actually Unsafe is in the same location. Only few classes were moved to different class.{Some classes from */misc were moved to */access but Unsafe class is still in */misc directory.}

So we recreated a new package (new package structure is same as before) and moved our Unsafe class to that folder. But compiling them are causing error.

[cyrille-artho]

Please check that the module names, module encapsulation/exports are also updated as needed. The first part of the path is the module name, so it should be java.base (not java/base).

[eklaDFF]

Hi, it worked.

Here is the new errors

/Users/ekla/GSOC/JPFjava17/jpf-core/src/classes/modules/java.base/java/lang/invoke/JPFFieldVarHandle.java:23: error: class is not allowed to extend sealed class: VarHandle (as it is not listed in its 'permits' clause)
public class JPFFieldVarHandle extends VarHandle {
       ^
/Users/ekla/GSOC/JPFjava17/jpf-core/src/classes/modules/java.base/java/lang/reflect/Proxy.java:72: error: method generateProxyClass in class ProxyGenerator cannot be applied to given types;
    byte[] proxyClassFile = ProxyGenerator.generateProxyClass(proxyName, interfaces, Modifier.PUBLIC | Modifier.FINAL);
                                          ^
  required: ClassLoader,String,List<Class<?>>,int
  found:    String,Class<?>[],int

[cyrille-artho]

It looks like the API was redesigned, so the new API under Java 17 no longer offers the expected function. Try to study the new API and see which function(s) you can use in place of the old one. A web search or even a ChatGPT query can also help; I recommend this as a starting point.

[eklaDFF]

public abstract class VarHandle implements Constable {

From above code, it is clear that VarHandle is not a sealed class. But why does the compiler throws the error

error: class is not allowed to extend sealed class: VarHandle (as it is not listed in its 'permits' clause)
public class JPFFieldVarHandle extends VarHandle {
       ^

[cyrille-artho]

I think your IDE shows the wrong source of VarHandle. In OpenJDK, it is sealed. There does not seem to be much code reuse from VarHandle in JPFVarHandle, so you can change inheritance to delegation to avoid the conflict with VarHandle now being sealed.

[eklaDFF]

Hi, even in OpenJDK-17 git source, Varhandle is not a sealed class.

It is difficult for me to use delegation with an abstract class like Varhandle. What I figured out that all those overridden methods from Varhandle are blank code (methods with empty body). In the body of those methods, comments are given "This methods are implemented in corresponding peer". So I removed the inheritance and then build was successful.

Please let me know, is it legal ?

[cyrille-artho]

You're right, you'd have to add an adapter class that can be instantiated. If the inheritance is not needed in the first place, I agree that it's much simpler and better to remove it.

[eklaDFF]

Hi, after the successful build, I ran first example.

It have throw an error that there is no method named getReferenceAcquire in Unsafe.java.

Actually in Java17 getReferenceAcquire method is introduced in Unsafe.java. And getReferenceAcquire‎ method has been used in ConcurrentHashMap class. But the getReferenceAcquire method calls getReferenceVolatile method defined as native in Unsafe.java class.

What should I do now ?

[cyrille-artho]

It's a great success that you got JPF to build on Java 17! What you now see is a common problem. Non-native method often have dependencies on native method because they call them (directly or indirectly). In this case, the "native peer" in JPF is closely coupled with the internal implementation. JPF has its own reference handles, which can be converted to objects or vice versa. As you now have a version that compiles against Java 17, can you please make a patch? We will create a new branch java-17 for this.

[eklaDFF]

I have created the patch files, and they are saved locally. Where do I have to upload them ?

[cyrille-artho]

Please make a pull request (PR). I have created a new branch java-17 against which you can make the pull request.

[eklaDFF]

Hi, while pushing the changes to remote repo, there is an error

Is this ok for now ? If it is, should I create pull request ?

[eklaDFF]

Analyzing it carefully, I found out that build (./gradlew buildJars) is successful with gradle but checks (./gradlew check) are causing a lot of errors

[cyrille-artho]

Yes, that is to be expected. Building JPF successfully against Java 17 is a first major milestone, so it is fine to create a pull request against branch java-17 with it. After that, resolving the failing tests (and adding a couple of new tests to check if JPF handles new features in Java 17 correctly) will be a lot of work, and each improvement can be merged as another PR on that branch.

[eklaDFF]

I have created Pull Request, review them. (Initial build for Java17 #441)

[cyrille-artho]

Thanks, I've added a comment. There is one line in build.gradle with what looks like a duplicated entry; the rest looks good to me.