[jedit:bugs] #4118 BeanShell error: module java.base does not "opens java.lang" to unnamed module
"Björn Kautler" via jEdit-devel <[email protected]> Fri, 13 Oct 2023 23:53:02 -0000
| Newsgroups | gmane.editors.jedit.devel |
|---|---|
| Message-ID | </p/jedit/bugs/4118/381c1cbef564de034dc7ffc01e5cac511c0f8cbd.bugs@jedit.p.sourceforge.net> |
The point why the snippet first works and then not anymore, is the usage of classes in a macro suddenly changes configuration.
By default `Capabilities#accessibility` is `false`.
This means BeanShell does not try to do `setAccessible` and alike.
There is exactly one place where this is set to `true`, which is when a class (named or anonymous) is found in a BeanShell code that is executed.
The current implementation in `ClassGeneratorImpl#generateClassImpl` has the comment
> // Scripting classes currently requires accessibility
> // This can be eliminated with a bit more work.
and then calls `Capabilities.setAccessibility( true );`.
This call succeeds if the classes `AccessibleObject` and `ReflectManagerImpl` are found and the security manager does not object to the call `String.class.getDeclaredMethods();` which is meant as basic reflection check call.
We could easily add a check whether an actual `isAccessible` call on some private field or method succeeds, or with updating to Java 17 or 21 we could just hard-code the value to `false` or remove the `ReflectManagerImpl` class which should have the same effect.
On the one hand this would maybe not be bad, as it adds consistency to the behavior.
Currently, things work one way unless some BeanShell snippet with a class definition is invoked and then suddenly start to behave differently, which could mean they start to fail while worked before, start to work while failed before or continue working but change behavior.
On the other hand, only that change would mean that no BeanShell snippets that define classes are supported anymore and things that maybe worked before after executing such a snippet might not work anymore. The latter is maybe not so tragic, but I'm not sure how bad it would be to not support classes anymore.
On the other hand, someone could have a look at what the comment means with "This can be eliminated with a bit more work." and maybe do that more work ourselves, then it might be better acceptable to disable the accessibility capability permanently.
---
**[bugs:#4118] BeanShell error: module java.base does not "opens java.lang" to unnamed module**
**Status:** open
**Group:** Regressive (new to devel)
**Labels:** macro
**Created:** Fri Apr 22, 2022 04:03 PM UTC by blurredd
**Last Updated:** Fri Oct 13, 2023 10:33 PM UTC
**Owner:** nobody
I see the following BeanShell error when running a macro that appends to a StringBuilder:
```text
Sourced file: C:\Users\User\AppData\Roaming\jEdit\macros\StringBuilderTest.bsh unknown error: Unable to make public java.lang.AbstractStringBuilder java.lang.AbstractStringBuilder.append(java.lang.String) accessible: module java.base does not "opens java.lang" to unnamed module @7c75222b : at Line: 2 :
in file: C:\Users\User\AppData\Roaming\jEdit\macros\StringBuilderTest.bsh
: sb .append ( "test" )
at org.gjt.sp.jedit.bsh.Interpreter.eval(Interpreter.java:696)
at org.gjt.sp.jedit.BeanShell._runScript(BeanShell.java:343)
at org.gjt.sp.jedit.BeanShell._runScript(BeanShell.java:291)
at org.gjt.sp.jedit.BeanShell.runScript(BeanShell.java:217)
at org.gjt.sp.jedit.Macros$BeanShellHandler.runMacro(Macros.java:1108)
at org.gjt.sp.jedit.Macros$Macro.invoke(Macros.java:530)
at org.gjt.sp.jedit.gui.InputHandler.invokeAction(InputHandler.java:343)
at org.gjt.sp.jedit.jEdit$3.invokeAction(jEdit.java:3417)
at org.gjt.sp.jedit.jEdit$3.invokeAction(jEdit.java:3399)
at org.gjt.sp.jedit.EditAction$Wrapper.actionPerformed(EditAction.java:225)
at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1972)
...
```
StringBuilderTest.bsh:
```java
StringBuilder sb = new StringBuilder():
sb.append("test");
```
I'm using jEdit 5.6.0, java version 17.0.2 on Windows 10 Enterprise.
---
Sent from sourceforge.net because [email protected] is subscribed to https://sourceforge.net/p/jedit/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
--
-----------------------------------------------
jEdit Developers' List
[email protected]
https://lists.sourceforge.net/lists/listinfo/jedit-devel