#GLASSFISH JAVA 8 CODE#

The jdeprscan tool generates an error message if it has trouble resolving a dependent class.įor example, error: cannot find class org/apache/logging/log4j/Logger. API that was deprecated in Java 8 is likely to be removed sooner thanĪPI that has been deprecated more recently. If you want to prioritize which deprecated API to go after, dial the settingīack to -release 8. Use the -release 11 option to get the most complete Output directory, or an individual class name. You can also give it a directory, such as the compiler To give it a jar file from an existing build.

#GLASSFISH JAVA 8 CODE#

Ultimately, you have to run the code on Java 11 to know with certainty. What jdeprscan and jdeps cannot do is warn about the use of reflection to access encapsulated API. Jdeprscan and jdeps is that you can run these tools over existing jars and class files, including The warnings and errors you get from jdeprscan and jdeps will come out of the compiler. The Java compiler itself, javac, is another tool in your toolbox. There are jdeps and jdeprscan plugins for both Gradle and Maven. Has recommended replacements for some commonly used JDK internal APIs. Replacing the usage should be a priority. You can continue to use internal API in Java 11, but When used with the -jdk-internals option, jdeps tells you whichĬlass depends on which internal API. Removed API is a blocking issue that has to be addressed before you tryĭependency analyzer. Updated jar file? Do you need to log an issue to address the use of deprecated API? Use of Use of deprecated API is not a blocking issue, but is something to look into. Jdeprscan looks for use of deprecated or removed API. You can assess the transition effort without having to recompile. These tools can be run against existing class or jar files. Java 11 has two tools, jdeprscan and jdeps, that are useful for sniffing out potential issues. You should also consult other guides, such as the Issues that you may run into and recommendationsįor resolving them. This document touches on tools to inspect code.

And there are additions and modifications to API that Improve startup, performance, memory usage, and provide better integration New features have been added andĮnhancements have been made since Java 8.

Quickly as possible, just trying to run on Java 11 is often the best approach.įor a library, the goal will be to publish an artifact that is compiled and tested

If the goal is to get an application up and running as In general, the approaches are to try to run on Java 11 without recompiling, or toĬompile with JDK 11 first. Internal API, changes to class loaders, and changes to garbage collection. Potential issues include removed API, deprecated packages, use of There's no one-size-fits-all solution to transition code from Java 8 to Java 11.įor a non-trivial application, moving from Java 8 to Java 11 can be a significantĪmount of work.

Glassfish java 8