Support JDKs with strong encapsulation
@peter-lawrey arbeitet bereits daran.
Seit 24.5.2023.
Bewertung
Dieses Issue wurde noch nicht bewertet.
Beschreibung
Recent JDK versions, such as JDK 17, strongly encapsulate their internals, see JEP 403.
Therefore using your library fails for these versions by default because the internal JDK fields are not accessible:
java.lang.RuntimeException: java.lang.reflect.InaccessibleObjectException: Unable to make public java.lang.Iterable com.sun.tools.javac.file.JavacFileManager.listLocationsForModules(javax.tools.JavaFileManager$Location) throws java.io.IOException accessible: module jdk.compiler does not "exports com.sun.tools.javac.file" to unnamed module @c86b9e3
at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:168)
at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100)
at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94)
at net.openhft.compiler.CachedCompiler.compileFromJava(CachedCompiler.java:112)
at net.openhft.compiler.CachedCompiler.loadFromJava(CachedCompiler.java:151)
<omitted>
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make public java.lang.Iterable com.sun.tools.javac.file.JavacFileManager.listLocationsForModules(javax.tools.JavaFileManager$Location) throws java.io.IOException accessible: module jdk.compiler does not "exports com.sun.tools.javac.file" to unnamed module @c86b9e3
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
at net.openhft.compiler.MyJavaFileManager.invokeNamedMethodIfAvailable(MyJavaFileManager.java:214)
at net.openhft.compiler.MyJavaFileManager.listLocationsForModules(MyJavaFileManager.java:77)
at jdk.compiler/com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager.listLocationsForModules(ClientCodeWrapper.java:388)
at jdk.compiler/com.sun.tools.javac.code.ModuleFinder$ModuleLocationIterator.hasNext(ModuleFinder.java:138)
at jdk.compiler/com.sun.tools.javac.code.ModuleFinder.scanModulePath(ModuleFinder.java:294)
at jdk.compiler/com.sun.tools.javac.code.ModuleFinder.findAllModules(ModuleFinder.java:187)
at jdk.compiler/com.sun.tools.javac.comp.Modules.getUnnamedModuleCompleter(Modules.java:1434)
at jdk.compiler/com.sun.tools.javac.comp.Modules.setCompilationUnitModules(Modules.java:471)
at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:265)
at jdk.compiler/com.sun.tools.javac.comp.Modules.initModules(Modules.java:231)
at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.initModules(JavaCompiler.java:1021)
at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:919)
at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152)
... 133 more
This can be worked around by using --add-opens jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED, but that is rather cumbersome and brittle.
Would it be possible for this library to not rely on JDK internals (possibly at the cost that the user has to provide additional arguments)?
- Vorherrschende Sprache
- Java
- Sterne
- 708
- Forks
- 147
- Ø Merge
- 4 T. 17 Std.
- Gemergte PRs (30 T.)
- 1
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus OpenHFT/Java-Runtime-Compiler
-
Class unloading issueOffen
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 25/100
OpenHFT/Java-Runtime-Compiler#136 ·
-
Problem with gradle en eclipse because of automatic modulesEvtl. wieder frei @yevgenp hat das vor 847 Tagen übernommen, und es ist kein Pull Request offen. Offenreview
OpenHFT/Java-Runtime-Compiler#130 · 2 Kommentare · 1 zugewiesene Person ·
-
Race condition on Java 11/17 on 23 branchEvtl. wieder frei @peter-k-lawrey hat das vor 1158 Tagen übernommen, und es ist kein Pull Request offen. Offenreview
OpenHFT/Java-Runtime-Compiler#123 · 1 zugewiesene Person ·
-
Add support for a white list of packages expected to be compiledEvtl. wieder frei @peter-lawrey hat das vor 1223 Tagen übernommen, und es ist kein Pull Request offen. Offenreview
OpenHFT/Java-Runtime-Compiler#122 · 1 zugewiesene Person ·
Alle Issues in OpenHFT/Java-Runtime-Compiler
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
refinedmods/refinedstorage2#1414 · 1 Kommentar ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
-
In Java's `LongBoundedSum`, setting `lower` to `Long.MIN_VALUE` under-estimates the sensitivityOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 73/100
google/differential-privacy#489 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
link-check link-check:manual
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100