-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Make IGV start on GraalVM 24.0.1 #11409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
@@ -117,7 +117,7 @@ | |||
<module>ViewerApi</module> | |||
</modules> | |||
<properties> | |||
<netbeans.version>RELEASE220</netbeans.version> | |||
<netbeans.version>RELEASE260</netbeans.version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this change I can built regularly:
/graal/visualizer/IdealGraphVisualizer$ JAVA_HOME=/graalvm-21/ mvn install
and then execute on GraalVM 24.0.1 (which was failing previously):
/graal/visualizer/IdealGraphVisualizer$ JAVA_HOME=/graalvm-24 mvn -f application/ \
-Dexec.vmArgs= -Dexec.appArgs= \
nbm:cluster-app nbm:run-platform
@@ -45,7 +46,12 @@ | |||
public class GraphTypeModeSelector implements ModeSelector { | |||
@Override | |||
public Mode selectModeForOpen(TopComponent tc, Mode mode) { | |||
if (tc.getLookup().lookup(InputGraph.class) == null) { | |||
try { | |||
if (tc.getLookup().lookup(InputGraph.class) == null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With following command line the execution gets further:
why IGV needs to access graphio.parsing from a JDK and how you want to make sure it gets the right version on different JVMs, is beyond ambitions of this PR... |
I'm already looking into this and as you say it's more complicated than just bumping to RELEASE260. We don't want to access jdk.graal.compiler.graphio.parsing.model from the JDK as there is already a module in IGV that contains this code. The presence of jargraal in GraalVM seems to break this and I'm not sure how to stop that. An Oracle JDK24, which contains only libgraal, doesn't have this problem but the actual unit tests fail other ways. The IGV application seems to run ok for me though. I guess your exception fix above is probably related to the jargraal problem though. |
I've got a working update at #11421 including a workaround for the GraalVM JDK 24 IGV problem. Could you test it out? |
…sion from GraalVM
fc540aa
to
3637a2d
Compare
I see. I didn't realize it before. In such case, the 3637a2d is the right fix.
Done. It seems to be broken: #11421 (comment) - probably 3637a2d is necessary. |
Thanks for that fix. I'll try that out. If it can resolve our GraalVM 24 jargraal issue that would be great. |
That seems to have improved things, but I still need to disable JVMCI or I get exceptions like this when processing filters:
Maybe other modules need to have the OpenIDE-Module-Hide-Classpath-Packages stuff? |
I just added it to every manifest.mf and that seems to have resolved the problem. I'm respinning my changes with all your suggestions. Thanks! |
I have problems launching IGV on GraalVM 24.0.1. It yields following error:
The problem is that JDK 24 has removed SecurityManager support and as the NetBeans Platform launcher needs to be adjusted to that. Such an adjustment has happened in NetBeans 26. Hence upgrading.