Login  Register

Re: Jogl/Jogamp on Java 9 no compatible graphics context

Posted by Predrag Bokšić on Jan 09, 2018; 3:51am
URL: https://forum.jogamp.org/Jogl-Jogamp-on-Java-9-tp4038012p4038500.html

Let us all calm down, focus, and be friends. No one deserves to be a programmer.

This is a very treacherous terrain: we have the unspecific library files that carry the same names all over the place. Long tutorials keep failing us even if we rewrite them ourselves; there's a lack of proper documentation, the corporations tend to forget us, and the entire planet is undergoing updates that are destroying the functionality of everything. If you look through Google, you know there's no single solution.

I have a feeling that it is exceptionally demanding to pay attention to the details that are ultimately difficult to track. Maybe you should know that people who perform the chaotic moves are using a natural algorithm that enables them to win despite the odds or expectations. Everybody wins in the end. Here, we've found some solutions to the problems by testing. It would be nice to publish them so that the small community of users can see these findings.

I feel embarrassed to make a git-commit because I am a little bit shy and inexperienced. I made just a few small changes in the Java3D library _only_ and now it works with the JDK 9 on iMac. I thought that I wrote almost-well on this topic, but I did not make any further comments. It would be constructive for me to know if there is any better way of debugging the library. Now, we'll need to write down nicely the WebStart solution for Windows 10 as well.

You see, I like to put the comments inside the source code, which shifts the rows down. They're like breadcrumbs. I left a few notes, so that you could search for the string "JVM 9" in the source code of the j3d-core.jar. Let us focus on the file /j3d-core/src/javax/media/j3d/JoglPipeline.java. There, you will find the method private void doQuery(). In this method, in the line 8631, you will find the following line: context.destroy(); This line needs to be removed. That is the minimal change that you need to make to continue after the crash. :-)

I am kind of stupid, so I also removed the line 8635, nativeWindow.destroy(); which is also the source of the potential crash. In the line 6539, I also removed the line glContext.destroy(); just because of a mere speculation that this code would be executed.

Let us now go to the line 8369, there you will find the line "while (tryAgain) {"
This line is the context in which the method private void doQuery() runs. I removed that line because it was useless.

These were the key workarounds for the Java3D bug.

I also examined the projects Jogl + Gluegen and made many, many experiments until I disassembled the whole thing. I determined that we could use the original Jogl + Gluegen without making any changes for all our Java3D projects.

However, Jogl is broken as well, in some sense. We know this by experiment. You can make a JoglQuad test project that uses the jogamp-fat.jar library _only_. That experiment also fails. Watch this... Let's say that we want to display the JoglQuad inside a JFrame or another type of window (except the JavaFX window).

    public static void main(String[] args) {
        final GLCanvas canvas = new GLCanvas();
        final Frame jFrame = new Frame("Jogl Quad drawing");
        final Animator animator = new Animator(canvas);
        canvas.addGLEventListener(new JoglTestWebstart());
        jFrame.add(canvas);
        jFrame.setSize(640, 480);
        jFrame.setResizable(false);
        jFrame.addWindowListener(new WindowAdapter() {
            @Override
            public void windowClosing(WindowEvent e) {
                animator.stop();
                if (OSInfo.OS.MAC.equals(OSInfo.getOs())) {

                } else {
                    jFrame.dispose();
                }
                System.exit(0);
            }
        });
        jFrame.setVisible(true);
        animator.start();
        canvas.requestFocus();
    }



If you execute jFrame.dispose(), the JVM crashes. So, the programmers should check their code for this pitfall to avoid the crash if they encounter any.

Of course, I did not want to offend you or anyone at all by posting these findings. :-)