Exception in thread "main" java.lang.UnsatisfiedLinkError: java.io.FileInputStream.available0()I

[rmbarnett-rice]

This error goes away when the use of -Xbootclasspath/p:$SCRIPT_DIR/resources/artifacts/jar/rt_debug.jar is removed from start_bayou.sh

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsatisfiedLinkError: java.io.FileInputStream.available0()I
        at java.io.FileInputStream.available0(Native Method)
        at java.io.FileInputStream.available(FileInputStream.java:306)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:353)
        at java.io.FilterInputStream.read(FilterInputStream.java:107)
        at java.util.Properties$LineReader.readLine(Properties.java:435)
        at java.util.Properties.load0(Properties.java:353)
        at java.util.Properties.load(Properties.java:341)
        at java.security.Security.initialize(Security.java:90)
        at java.security.Security.access$000(Security.java:49)
        at java.security.Security$1.run(Security.java:71)
        at java.security.Security$1.run(Security.java:69)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.Security.<clinit>(Security.java:69)
        at sun.security.util.AbstractAlgorithmConstraints$1.run(AbstractAlgorithmConstraints.java:52)
        at sun.security.util.AbstractAlgorithmConstraints$1.run(AbstractAlgorithmConstraints.java:49)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.util.AbstractAlgorithmConstraints.getAlgorithms(AbstractAlgorithmConstraints.java:48)
        at sun.security.util.DisabledAlgorithmConstraints.<init>(DisabledAlgorithmConstraints.java:98)
        at sun.security.util.DisabledAlgorithmConstraints.<init>(DisabledAlgorithmConstraints.java:84)
        at sun.security.util.SignatureFileVerifier.<clinit>(SignatureFileVerifier.java:62)
        at java.util.jar.JarFile.initializeVerifier(JarFile.java:370)
        at java.util.jar.JarFile.getInputStream(JarFile.java:450)
        at sun.misc.URLClassPath$JarLoader$2.getInputStream(URLClassPath.java:977)
        at sun.misc.Resource.cachedInputStream(Resource.java:77)
        at sun.misc.Resource.getByteBuffer(Resource.java:160)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:454)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)

[rmbarnett-rice]

This error occurs immediately when start_bayou.sh is invoked.

[rmbarnett-rice]

No worries. That's not something I normally check for when committing either. The only thing that concerns me about Oracle is that there is some rumbling on the internet about them recently stopping support for command line installation of Oracle Java on Linux via command line. (e.g. apt-get install). In fact, I tried this yesterday and indeed it fails with 404 because Oracle has taken needed files down from their distribution server. So I think OpenJDK would be preferable for us because we can (as we do now) scriptify the installation of the whole system.

[rmbarnett-rice]

Somehow brew is still ok though.

[rmbarnett-rice]

Are you sure you didn't have that package already installed locally? Because those are the steps that the internet claims don't work anymore and I could not get to work 2 days ago due to Oracle pulling some files off their public web server.

Further, we have uncovered some parts of the Eclipse libraries that don't work under 1.9 (See https://github.com/capergroup/bayou/issues/162). So I'm not sure 1.9 is an option at the moment.

[rmbarnett-rice]

I think we should strive for uniformity of environment over doing JVM vendor checks. If we decide rt_debug.jar is the way to go, so be it, and we can update our process to ensure that this is the version installed. If that means installation becomes a manual process instead of a script, so be it. I think trying to manage issues with the extra variables of now divergent behaviors between JVM vendors introduces dangerous complexity.

[rmbarnett-rice]

Are smart variables something slated for the next askbayou.com release or for a release beyond that?

[rmbarnett-rice]

Ok. If you think side stepping vendor affinity is something we need for the end I can figure something out that will check which JVM is installed and decide then how to invoke.