We Keep Coding

Java library only working on java 1.8

For a university assessment we're doing a large java project which makes use of a given external hardware that utilises a given java library to interact with it.
The main problem is that such java library only runs on java 1.8 (the reason is not clear yet) and just fails with newer versions of java.
Since the rest of the code (a few thousands) is written in java 9, it's obviously a hard task to rewrite everything without making uses of all the functionalities added since java 1.8
I have the following questions:
Is there a way to make the whole project back-compatible without changing thousands of lines of code? (or to make the library work with a newer version of java)
In the case there isn't such way, is there an easy way to see what needs to be changed to make the project compatible with a previous version of java?
Thank you in advance for any answer, any small contribution will be a great deal for us
Error stack trace:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000180005b00, pid=20224, tid=10952
#
# JRE version: Java(TM) SE Runtime Environment (9.0+11) (build 9.0.4+11)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (9.0.4+11, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [rxtxSerial.dll+0x5b00]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\works\Documents\GitHub\Software-Engineering\src\hs_err_pid20224.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.

JVM crashes when loading a native library

I'm working on a CD burner using java, where ( using JNI ) i must load some native libraries (DLL). Well, i know that to load a native library using "System.loadLibrary(libName)", the library must be set to one of the "java.library.path" paths, however if using "System.load(libPath)" there is no need for that.
So, i used to load all my native libraries using "System.load(libPath)" and that worked for all of them except a single one "BurnerCaller.dll" that causes a JVM crash with the error message below.
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (0xe0434352), pid=2280, tid=0x00000000000013a8
#
# JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build 1.8.0_92-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C [KERNELBASE.dll+0xaa7d]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Program Files\Java\MainWorkspace\NewAman\hs_err_pid2280.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
Here is the detailed result error.
The weird thing is that if and only if i put this library to the "bin" directory of the currently running JRE or JDK (that my application is using to run) it works like a charm.
Any help would be appreciated, thanks in advance.

Try other JDK (Oracle JDK, Open JDK, versions 6,7,8). make sure dll bitness (32 vs 64) match JDK bitness
Debug native code
It looks like pure native problem and you should use native tools.
If you have source code of BurnerCaller.dll you can attach(Visual Studio, WinDbg)\debug\fix it. At least you will see the stacktrace of native crash.
If you don't have the souce - just put it in java bin directory, the easiest way.
When system loader loads a library, it calls DllMain for this library, looks like the bug is somewhere around it.

JVM Segfaults when installing Matlab Distributed on Rocks CentOS Cluster

At work, I am trying to install Matlab Distributed Computing Server R2011a on a Rocks CentOS Cluster. Following the instructions, I mount the ISO and run ./install &. The installer shows a splash screen but then crashes and outputs the error message below.
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0x0000003d39471c7c, pid=29673, tid=1105340736
JRE version: 6.0_17-b04
Java VM: Java HotSpot(TM) 64-Bit Server VM (14.3-b01 mixed mode linux-amd64 )
Problematic frame:
C [libc.so.6+0x71c7c]
If you would like to submit a bug report, please visit:
http://java.sun.com/webapps/bugreport/crash.jsp
My boss and I found an article at http://greg.porter.name/wiki/HowTo:MatlabOnRocks by someone who has the exact same problem, but never figured out how to fix it. Has anyone else encountered this problem? If anyone has found a fix, I would be very interested in knowing what steps you took to fix this problem.

Sounds like a "try to run things on an unsupported platform"-issue.
In this kind of problems, ensure that you do this on a platform explicitly stated to support this combination. I do not believe that CentOS is a supported Oracle JVM platform.

It seem to be a general problem of java on memory limits set by cluster manager.
We are encounter this problem with SGE on Fedora Core 13.
see bug on fedora
Solution is to set limits to ~ 4 Go (not easy all the time ...)
or set environment

IcedTea and lwgjl

I have recently found myself on a Linux computer and am liking it so far.
However, I have been having an issue and dont really know the source. I am trying to make a java project that uses lwjgl in eclipse (something I have done in windows) but when I run the code my display window comes up black and blinking and I get this error report-
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f5004c70c98, pid=10427, tid=139981673781008
#
# JRE version: 6.0_18-b18
# Java VM: OpenJDK 64-Bit Server VM (16.0-b13 mixed mode linux-amd64 )
# Derivative: IcedTea6 1.8.1
# Distribution: Ubuntu 10.04 LTS, package 6b18-1.8.1-0ubuntu1
# Problematic frame:
# C [libX11.so.6+0x37c98] XQueryExtension+0x28
#
# An error report file with more information is saved as:
# /home/jeff/workspace/SpinDodge3/hs_err_pid10427.log
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
# https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
#
I have the sun java 6 jdk installed and I have tried pointing eclipse to that using the -vm command but this error is the same. Java projects not using lwjgl work. Is this because I am using lwjgl wrong, the way it interacts with icedTea (something which the -vm command seems to do nothing for), eclipse? I have no idea where to even start.
Has anybody here used lwgjl in Linux, do they have any ideas?
Thankyou
(also I can post the error log but it is pretty long, I dont know how much help it will be)
EDIT: After I changed the jdk in use it runs but only for one frame and then crashes with this error-
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fbfd4fb7c98, pid=2060, tid=140461906126608
#
# JRE version: 6.0_20-b02
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode linux-amd64 )
# Problematic frame:
# C [libX11.so.6+0x37c98] XQueryExtension+0x28
#
# An error report file with more information is saved as:
# /home/jeff/workspace/SpinDodge3/hs_err_pid2060.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
Any ideas?

Run sudo update-java-alternatives -l to see the different versions of Java on your system. Then run sun update-java-alternatives -s [java type] to set it as the default, which binds it to the commands java, javaw, etc.
In your case, you should run sudo update-java-alternatives -s java-6-sun as mentioned on the Java Community Documentation page.
Well it looks like Java isn't the problem. You should read about SIGSEGV and XQueryExtension; it looks like your Xlib or X11 is to blame.
If I were you, at this time I would follow the instructions; go to https://bugs.launchpad.net/ubuntu/+source/openjdk-6/ and submit a bug report, paste this error and attach the logfile (/home/jeff/workspace/SpinDodge3/hs_err_pid10427.log). See if the experts can redirect you to exactly where the problem lies.
Also, of course, make sure your system is updated. You don't want to report a bug that has already been fixed.

As far as I can tell this is an error with eclipse and openGL in Ubuntu 10.04. It happens regardless of the jdk used (I have tried both). However, I have figured out that this error is only thrown when the program closes and was not causing the problems I saw with the lwjgl rendering. Except for the build-up of error logs just ignoring this error has caused me no problems so far.

You are not executing with the Sun JVM but with the OpenJDK, and there are subtle differences. Switch Ubuntu to use the Sun JVM and try again.

Java VM: reproducible SIGSEGV on both 1.6.0_17 and 1.6.0_18, how to report?

EDIT: This reproducible SIGSEGV happens on a Linux machine with more than one proc and more than 2GB of mem, so Java is defaulting to the -server mode. Interestingly enough if I force "-client" there's no crash anymore... (I'm still not too sure what to do with my reproducible SIGSEGV but it's interesting nonetheless).
First note that this is a bit related but not identical to the following because in our case it's only a SIGSEGV that happens, and we can reliably trigger it:
JVM OutOfMemory error "death spiral" (not memory leak)
It's related because it happens when we feed our app with a "deluge of data": data are coming from text files and then number-crunched (yes, financial number crunching in Java).
I can reliably trigger a JVM to SIGSEGV using only valid Java code.
NOTE: I can invariably crash both JVM 1.6.0_17 adn JVM 1.6.0_18 and this question is not about how to workaround this issue (for example playing with VM parameters may fix the issue but I'm not after that, I want to know what to do with this always-reproducable SIGSEGV).
I've got a workaround which simply consists in using Java 1.5 when launching our app (while still using Java 1.6 to run IntelliJ IDEA, etc. on the same machine, simultaneously), but my question is if this should be reported or not and, if it should, how to report it knowing that the log itself contains proprietary information (the full hs_err_..._log).
Hardware error can be ruled out for:
this is happening on a workstation that regularly reaches months of uptime (I only reboot it when critical security patches affecting my trimmed down and hardened Debian Linux are issued, which really doesn't happen often) and on which applications never crash (making it very unlikely that it's an hardware issue on that machine [more below])
same application works perfectly on that same machine under a JVM 1.5 under the same load (this is how I'm testing the app: I simply launch it under a 1.5 VM)
same application works perfectly fine on more than one hundreds clients machine under the same (gigantic) load (never crashed once on Windows + JVM 1.5 or 1.6 and never crashed once on OS X + JVM 1.5 or 1.6 [a crash would mean an instant phone call from the client])
other application on that same machine and same 1.6.0_17 or 1.6.0_18 JVM never crash (for example I've got two instances of IntelliJ IDEA running as two different users on that same machine and they don't crash)
machine is tested with memtest "regularly" (before installing a new OS, which last happened when I installed Debian Lenny, not that long ago)
Here's the reproducible-on-demand SIGSEGV:
... $uname -a
Linux saturn 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 GNU/Linux
... $ export /home/wizard/jdk1.6.0_17/bin:$PATH
... $ java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
Launch the app, feed it a "deluge of data", wait a few seconds...
Then, invariably, for 1.6.0_17:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb76d0080, pid=30793, tid=2514328464
#
# JRE version: 6.0_17-b04
# Java VM: Java HotSpot(TM) Server VM (14.3-b01 mixed mode linux-x86 )
# Problematic frame:
# V [libjvm.so+0x4bc080]
#
# An error report file with more information is saved as:
# /home/wizard/hs_err_pid30793.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
(note that the line '[libjvm.so+0x4bc080]' is consistent for 1.6.0_17 at every SIGSEGV)
or for 1.6.0_18:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb77468f0, pid=722, tid=2514516880
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) Server VM (16.0-b13 mixed mode linux-x86 )
# Problematic frame:
# V [libjvm.so+0x4d88f0]
#
# An error report file with more information is saved as:
# /home/wizard/hs_err_pid722.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted
(note that the line "[libjvm.so+0x4d88f0]" is consistent for 1.6.0_18 at every SIGSEGV)
The problem is that the log file contains proprietary information
that cannot be shared.
Reproducing a "tiny test case" that reproduce the issue ain't realistic either: it's similar to the issue linked above, this only happens when a "deluge of data" is feeded to the app.
Note that the exact same application, on exactly the same hardware, with exactly the same JVM but another version of Linux (I had Debian Etch previously) did NOT trigger that SIGSEGV once.
But this doesn't mean the JVM isn't at fault: it could still be a JVM issue.
Should I report this and how? (keeping in mind that writing a "reproducible tiny test case" is delusional and that the log contains proprietary information that shouldn't be leaked). Should I just edit the log and send it?
What's the procedure to report such reproducible SIGSEGV when your log contains proprietary information and when a test case reproducing the issue ain't realistically doable?
Did any of you have success opening such a bug and then see it solved in a subsequent Java release?
Do you think it's good "for the Java community" to report such an issue or I just shouldn't bother because it's not important?

I got similar problem upgrading to JDK 1.6_18 and it seems solved using the following options:
-server
-Xms256m
-Xmx748m
-XX:MaxPermSize=128m
-verbose:gc
-XX:+PrintGCTimeStamps
-Xloggc:/tmp/gc.log
-XX:+PrintHeapAtGC
-XX:+PrintGCDetails
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath="/tmp"
-XX:+UseParallelGC
-XX:-UseGCOverheadLimit
# Following options just to remote monitoring with jconsole, useful to see JVM behaviour at runtime
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=12345
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=MyHost
I still didn't double check (it is a production environment), but I think the error was due to two reasons:
1) Wrong setting about heap and/or Permanent space (I think JDK 1.6 needs more space in heap and permanent than previous JVM versions) caused an OutOfMemoryError, but
2) in the wrong original setting somebody wrote
-XX:+HeapDumpOnOutOfMemoryError="/tmp"
and not
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath="/tmp"
so probably JVM was not able to write the heapdump and we got SIGSEGV only (previous versions wrote heap dump in the working directory).
Check -server -XX:+UseParallelGC -XX:-UseGCOverheadLimit options too. I think playing with VM parameters is not a workaround, but the right approach also because garbage collector (and not only) changed between 1.5 and 1.6.

The problem is that the log file
contains proprietary information that
cannot be shared. Reproducing a "tiny
test case" that reproduce the issue
ain't realistic either
If you can't provide Sun with a reproducible test case, they won't even look at it. Chance are good that they will ignore it even if you do provide a usable test case. The bug submission process at Sun leaves a lot to be desired.
Should I report this and how?
If you can't come up with a reproducible test case, don't bother. If they can't reproduce the issue, what do you expect them to do?
Note that the exact same application,
on exactly the same hardware, with
exactly the same JVM but another
version of Linux (I had Debian Etch
previously) did NOT trigger that
SIGSEGV once.
Does it work on a different box with the same hardware and same version of Linux?

If it helps, the bug submission link in your crash report has this disclaimer:
In addition, Sun Microsystems respects your desire for privacy. Personal data collected from this program will not be sold, given or shared with organizations external to Sun. We will use this data for communications with you to clarify issues regarding the report you submitted and/or status of that report. The issues that you report may be made available to other JDC Members or Sun customers, however your personal data will be kept confidential. If you are not comfortable with the above conditions, please do not press the Submit button. If you have any questions, please refer to our Privacy Policy.
Personally, I would report it if it was feasible to hand over the code segment in question with logs, if the data is not too sensitive (perhaps data can be masked or obfuscated in logs?).
It's impossible for you to really judge if the bug is "important" or not for others unless you can know what actually causes it. Reporting it might be the first step in Sun's engineers finding out the cause of something serious.

The very first question you should ask yourself is:
Am I using an officially supported Linux distribution?
If not, switch to one that is.
If you are, then report it to Sun!