我在 Netbeans IDE 上运行 JSP 和 Servlet 时遇到问题

Question

I got a problem to run JSP file on Apache Netbeans 12.3 JDK 16.0 and I am using tomcat 9.0.45 on macOS BigSur. I'm not sure what is the problem actually. Could you please help me.And when I run the servlet file I got this error message.

java.lang.IllegalAccessError: class org.netbeans.modules.tomcat5.deploy.TomcatManagerImpl (in unnamed module @0x19f724b9) cannot access class com.sun.org.apache.xerces.internal.impl.dv.util.Base64 (in module java.xml) because module java.xml does not export com.sun.org.apache.xerces.internal.impl.dv.util to unnamed module @0x19f724b9
    at org.netbeans.modules.tomcat5.deploy.TomcatManagerImpl.run(TomcatManagerImpl.java:533)
    at org.netbeans.modules.tomcat5.deploy.TomcatManagerImpl.list(TomcatManagerImpl.java:372)
    at org.netbeans.modules.tomcat5.deploy.TomcatManager.modules(TomcatManager.java:718)
    at org.netbeans.modules.tomcat5.deploy.TomcatManager.getAvailableModules(TomcatManager.java:529)
    at org.netbeans.modules.tomcat5.optional.TMIDResolver.lookupTargetModuleID(TMIDResolver.java:56)
    at org.netbeans.modules.j2ee.deployment.impl.TargetServer.checkUndeployForSharedReferences(TargetServer.java:349)
    at org.netbeans.modules.j2ee.deployment.impl.TargetServer.checkUndeployForSharedReferences(TargetServer.java:322)
    at org.netbeans.modules.j2ee.deployment.impl.TargetServer.checkUndeployForSharedReferences(TargetServer.java:319)
    at org.netbeans.modules.j2ee.deployment.impl.TargetServer.processLastTargetModules(TargetServer.java:440)
    at org.netbeans.modules.j2ee.deployment.impl.TargetServer.init(TargetServer.java:170)
    at org.netbeans.modules.j2ee.deployment.impl.TargetServer.deploy(TargetServer.java:605)
    at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:221)
    at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:141)
    at org.netbeans.modules.j2ee.ant.Deploy.execute(Deploy.java:86)
    at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
    at jdk.internal.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:567)
    at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
    at org.apache.tools.ant.Task.perform(Task.java:350)
    at org.apache.tools.ant.Target.execute(Target.java:449)
    at org.apache.tools.ant.Target.performTasks(Target.java:470)
    at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1391)
    at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
    at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
    at org.apache.tools.ant.Project.executeTargets(Project.java:1254)
    at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:261)
    at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:574)
    at org.netbeans.core.execution.RunClassThread.doRun(RunClassThread.java:132)
    at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
    at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
    at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:81)

Answer 1

In Java 9, the Java Platform Module System has been introduced.

This also adds access rules.

In your case, the module java.xml does not export com.sun.org.apache.xerces.internal.impl.dv.util.Base64 but tomcat tries to access it nevertheless (The version of tomcat you are using may not support JPMS).

Here are three different approaches you could try:

Update Tomcat

Newer versions of tomcat might have fixed this issue. For example, tomcat 10 seems to support JPMS.

Add --add-exports java.xml/com.sun.org.apache.xerces.internal.impl.dv.util=ALL-UNNAMED to the JVM arguments.

When starting tomcat, you can add the JVM argument --add-exports java.xml/com.sun.org.apache.xerces.internal.impl.dv.util=ALL-UNNAMED to the command that starts tomcat. As tomcat is likely started via a script, this behaviour might be controlled with environment variables. Many scripts use the environment variable JAVA_OPTS for this. If you set the environment variable JAVA_OPTS to --add-exports java.xml/com.sun.org.apache.xerces.internal.impl.dv.util=ALL-UNNAMED (or add that to the environment variable) before starting tomcat, it might get picked up. Alternatively, you can manually add it to the command or use an environment variable like JAVA_TOOL_OPTIONS that gets picked up by the JVM automatically.

This configures the module java.xml to export the package to all unnamed modules (including tomcat) even if it does not do that by default.

See Java Platform, Standard Edition Oracle JDK 9 Migration Guide

If you need to use an internal API that has been made inaccessible, then use the --add-exports runtime option. You can also use --add-exports at compile time to access internal APIs.

See the docs on details what --add-exports does.

Remove the module-info.java

By doing this, Java could fall back to the old non-JPMS behaviour.

Answer 2

NetBeans 12.3 does not support JDK 16, so what you were attempting to do is unsupported.

Refer to the section on Deployment Platforms in the NetBeans 12.3 documentation:

Apache NetBeans 12.3 runs on JDK LTS releases 8 and 11, as well as on JDK 15, ie, the current JDK release at the time of this NetBeans release.

So try replacing JDK 16 in your NetBeans configuration with JDK 15, to see if the problem goes away. If the issue persists using Java 15 then update your question by replacing the JDK 16 stack trace with a JDK 15 stack trace.

As a related matter, since you mentioned that you are using Big Sur, you may also want to review NetBeans Bug Report NETBEANS-5037 NetBeans dialog windows in Big Sur . That may not be relevant for you, but it is also mentioned in the NetBeans 12.3 release documentation:

The current JDKs have an issue on macOS Big Sur, that causes freezes on dialogs. That could be fixed by applying the workaround described at NETBEANS-5037.