With InterClient 7.5.1 and 8.1.5, the creation of a new JDBC connection in Java 8 fails with
java.lang.NoClassDefFoundError: sun/io/ByteToCharConverter
This class seems to be referenced or used by the InterClient JDBC library.
The error does not occur with Java 7. Is there a way to work around this error?
This code reproduces the problem on Java 8:
package com.example.so25365952;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.logging.Level;
import java.util.logging.Logger;
public class Main {
interbase.interclient.Connection conn;
public static void main(String[] args) {
try {
Class.forName("interbase.interclient.Driver");
DriverManager.getConnection("jdbc:interbase://localhost/data/mydb.gdb", "sysdba", "password123");
} catch (ClassNotFoundException | SQLException ex) {
Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
}
}
}
Output:
Exception in thread "main" java.lang.NoClassDefFoundError:
sun/io/ByteToCharConverter at
interbase.interclient.Connection.connect(Unknown Source) at
interbase.interclient.Connection.(Unknown Source) at
interbase.interclient.Driver.connect(Unknown Source) at
java.sql.DriverManager.getConnection(DriverManager.java:664) at
java.sql.DriverManager.getConnection(DriverManager.java:247) at
com.example.so25365952.Main.main(Main.java:14) Caused by:
java.lang.ClassNotFoundException: sun.io.ByteToCharConverter at
java.net.URLClassLoader$1.run(URLClassLoader.java:372) at
java.net.URLClassLoader$1.run(URLClassLoader.java:361) at
java.security.AccessController.doPrivileged(Native Method) at
java.net.URLClassLoader.findClass(URLClassLoader.java:360) at
java.lang.ClassLoader.loadClass(ClassLoader.java:424) at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at
java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 6 more
Use db2jcc4.jar which is latest version. If you changed your mind to use Java 8 you need to use this.
I have the similiar problem and this change help me to fix the error.
The sun.* and sunw.* packages are internal and should not be used for exactly this reason. Seems like someone at InterClient screwed up. I'd advise you to contact them with a bug report, so they'll know to fix this for future releases.
If you can't wait for a future release, and are willing to break some licences (which I don't recommend of course). You may be able to create your own sun.io.ByteToCharConverter by copying the code from here, and adding it to the bootstrap classpath with -Xbootclasspath, but that would be a last resort.
sun.io.ByteToCharConvertor was deprecated in java 7. and it seems they remove it in java 8.
The answer to the question interbase.interclient.UnlicensedComponentException with the latest interclient.jar IB (v7.5.80) seems to work for me too. It suggests to use version 1.5 of the JDBC driver for Firebird. Fortunately this driver does not rely on deprecated sun classes and works with JRE 8.
I agree with Sergio, this is now an even older question! :-) But at my workplace, too, we are unfortunately as of 2018 for various reasons still using a super-old Interbase (v9, 2009). So at some point I too was unable to continue using the interclient.jar packaged with IBv9, because I would receive this same sun.io.ByteToCharConverter error. No doubt this was because the Java on my client machine was so much newer now. After all, it is 9 years later. But I did not want in my case to go with the solution of installing a legacy Java on my machine, as has worked for others.
So as a solution, on my client machine (Linux/Debian x64), I installed Interbase 2017, the latest at the time(*). But when installing, I only installed the IB Client (not Server + Client). The /opt/interbase/lib/interclient.jar that is packaged with the IB 2017 client works just fine now (no sun.io error). And yes, this IB 2017 (v13) interclient.jar works just fine connecting to our old IB 2009 server.
(I have to hand it to Embarcadero: They are still 'supporting' being able to connect to older versions -- at least in their interclient.jar and libgds.so. This makes sense as useful of course for those sysadmins who want to migrate from older systems to newer ones.)
(*) You can get a free trial version of Interbase from embarcadero. As far as I can tell, though, when you install it, if you install the Client only and use the interclient.jar, this does not require a license. Only installing the IB server (and depending on number of users/connections, etc) but that is nothing new to IB users/admins.
Works for us, at least, until we upgrade our server's IB version, or move to Firebird.
Hope this helps at least one other person out there.
This is an old question, but in case this helps someone:
Find the Java 7 rt.jar in the lib folder.
Open the file, and go to the folder sun/io.
Find the Java 8 rt.jar in the lib folder.
Open the file, and go to the folder sun/io.
Move all the .class files in the folder sun/io from the Java 7 to the Java 8 sun/io folder, except for Win32ErrorMode.class (this class was in both jar files).
Save the Java 8 rt.jar with the added classes.
This worked for me, using an old jdbc driver for SQL Server.
use
<!-- https://mvnrepository.com/artifact/com.ibm.db2.jcc/db2jcc -->
<dependency>
<groupId>com.ibm.db2.jcc</groupId>
<artifactId>db2jcc</artifactId>
<version>db2jcc4</version>
</dependency>
replace
<dependency>
<groupId>com.ibm.db2.jcc</groupId>
<artifactId>db2jcc</artifactId>
<version>10.1</version>
</dependency>
can Solve the problem
Related
Using journey browser project I have set up a simple maven project in eclipse, using the dependency provided on the page, I have tried to run the code example (also provided on the page)
And I get an NPE:
Exception in thread "main" java.lang.ExceptionInInitializerError
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:315)
at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:588)
at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:583)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.desktop/java.awt.Toolkit.getDefaultToolkit(Toolkit.java:582)
at java.desktop/java.awt.Toolkit.getEventQueue(Toolkit.java:1494)
at java.desktop/java.awt.EventQueue.isDispatchThread(EventQueue.java:1086)
at java.desktop/javax.swing.SwingUtilities.isEventDispatchThread(SwingUtilities.java:1493)
at com.codebrig.journey.JourneyBrowserView.<init>(JourneyBrowserView.java:78)
at com.codebrig.journey.JourneyBrowserView.<init>(JourneyBrowserView.java:71)
at JourneyBrowser.main(JourneyBrowser.java:13)
Caused by: java.lang.NullPointerException
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2646)
at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:830)
at java.base/java.lang.System.loadLibrary(System.java:1870)
at java.desktop/sun.awt.windows.WToolkit$1.run(WToolkit.java:118)
at java.desktop/sun.awt.windows.WToolkit$1.run(WToolkit.java:115)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.desktop/sun.awt.windows.WToolkit.loadLibraries(WToolkit.java:114)
at java.desktop/sun.awt.windows.WToolkit.<clinit>(WToolkit.java:129)
... 12 more
Can anyone explain what is happening and why here, I have tried this on 64bit windows with java Coretto 11(jdk11.0.7_10),I initially found a bug here, relating to loadLibray in open JDK and thought that maybe the problem, I just don't have a good enough understanding to work out how to get around it?
I'm not sure, but I think that Corretto bug is probably the one that is causing the problem. As noted, it is from their "upstream"; i.e the OpenJDK codebase. It was due to regression that appeared in jdk11.0.7 due to a backport of a fix for another problem. Apparently, the fix changes some internal JDK fields and that breaks application code. As JDK-8240521 puts it:
The backport of the JDK-8231584 changes internal JDK fields processing. The problem is that the many third-party applications copy-pasted a hack that depends on particular JDK implementation.
If I am reading the Oracle bug entries correctly, the reversion of the broken fix should be in JDK11.0.8. Alternatively, an earlier JDK 11 release than 11.0.7 shouldn't have the broken fix.
Let me know if changing your Java 11 install solves the problem. (If not, I'll see if I can get the line numbers to match up.)
I am encountering a "KeyGenerator not available" error when trying to create a SSL connection using Javax.mail.
The project was functional 3-4 years ago and it was updates to JDK1.8 and to the new JRE. I assume that it's the issue is some fundamental quirk from updating the project.
I've followed everything listed Here.
I added the path from JKD1.8.0_131/jre/lib/ext/sunjce_provider.jar to my project library so that it's both in the JRE library and the project classpath.
java.security.NoSuchAlgorithmException: SunTls12RsaPremasterSecret KeyGenerator not available
at javax.crypto.KeyGenerator.<init>(KeyGenerator.java:169) ~[?:1.8.0_131]
at javax.crypto.KeyGenerator.getInstance(KeyGenerator.java:223) ~[?:1.8.0_131]
at sun.security.ssl.JsseJce.getKeyGenerator(JsseJce.java:251) ~[?:1.8.0_131]
at sun.security.ssl.RSAClientKeyExchange.<init>(RSAClientKeyExchange.java:78) ~[?:1.8.0_131]
.....
I expected the code to create a connection at this point. What can I do to resolve this issue?
not sure why, but this method helped me in eclipse: https://www.codetd.com/en/article/9438315
Preferences -> installed JREs -> Edit your java 8 JRE and 'Restore Defaults'
You should update Java 8 to the current patchlevel anyway, but according to this issue, you will need at least patch level 192 instead of 131. This is an issue for OpenJDK, but for Oracle Java it seems to be the same.
I assume your code was connecting to a server that has been updated to TLS 1.2 since your last usage.
I got this error message in the console when I tried to run, I just switched laptops and I've wiped my old one. This project has always been stored in a USB so I use that to run it on my new laptop. (So I had to re-download all the applications), I need this to fix so bad due to its my project for class and I haven't record it and I'm supposed to do that and I don't want to fail the class please could u help thank u:
java.lang.NoClassDefFoundError: com/apple/eawt/QuitHandler
at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3119)
at java.base/java.lang.Class.getMethodsRecursive(Class.java:3260)
at java.base/java.lang.Class.getMethod0(Class.java:3246)
at java.base/java.lang.Class.getMethod(Class.java:2065)
at processing.core.PApplet.runSketch(PApplet.java:10751)
at processing.core.PApplet.main(PApplet.java:10548)
at processing.core.PApplet.main(PApplet.java:10530)
at robothead.Robothead.main(Robothead.java:8)
Caused by: java.lang.ClassNotFoundException: com.apple.eawt.QuitHandler
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:190)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499)
... 9 more
I at first download JDK 10 and I read it only works with JDK 8 so I download that and delete JDK 10 in hopes that stuff will return back to normal and it does not works. Also the project, I did it in java oxygen and I downloaded photon on my new laptop and click on the yes I want to convert the files thing so I decided to make a new workspace and copy paste the code but still got that error?Before it was MacBook Air and I switch to the MacBook Pro.
You are mixing up a lot of things.
The basic problem is that starting with Java 9 oracle made changes that lead to such errors ( see https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-C86F7403-7D7C-456F-8873-18C7F1BEDE2F).
So, in order to get this to work, you have to ensure that Java 8 is used. And that your Java 10 installation was really, fully removed. You should then check your eclipse settings to also ensure that it is pointing to Java 8.
My app works great with java 1.8 (and earlier), however when I rebuilt the application to use java 9, I receive the following stack trace. The reason for the update is because I need to use the new ProcessHandle.current(), which does not exist in earlier versions.
c:\>java -jar ./build/bin/DataMover.jar
DataMover Service: starting...
Exception in thread "main" java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
Caused by: java.lang.NoClassDefFoundError: org/glassfish/jersey/server/ResourceConfig
at dataMoverServerPackage.Main.main(Unknown Source)
... 5 more
Caused by: java.lang.ClassNotFoundException: org.glassfish.jersey.server.ResourceConfig
at java.base/java.net.URLClassLoader.findClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
... 6 more
For whomever is curious, here is the java version output.
c:\>java -version
java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)
Here is the relevant main() function.
public static void main(String[] args)
{
try
{
...
final ResourceConfig resourceConfig = new ResourceConfig(DataMoverServerResource.class);
I did research and read that the big difference between Java 6,7,8 and Java 9 is modules. In particular earlier versions of Java included the Java EE JDK, whereas Java 9 includes the java.se module, not the EE. All com.sun.* classes are inaccessible in Java 9, as I read. These pieces of information may or may not be relevant. I do not know the internal makeup of the jersey.server API, just some articles talked of that.
I am using a jar in jar loader, so the jersey stuff is in the base jar.
I am torn between an internal dependency issue on Jersey or the jersey jar. The loader seems happy just fails later at the java.base/jdk.internal, which tells me a module might be missing.
If there were an internal module, such as java.xml.bind, like I read in one post, which is included in Java EE, then the exception trace would indicate that and I would know to add that module using the --add-module option to java, such as --add-module java.xml.bind, but that is not the case here, at least with that module.
Here is a link to one possibly relevant article. Maybe the java.net is the problem, much like the at javax.xml.bind at the bottom of the stack trace in that question was the underlying cause. I discounted the ext folder answer in this question, as that question pertained to 1.8, which works for me and I have jar-in-jar. I note the question here because it keeps turning up on searches. This question was also not relevant, though similar. The list goes on.
I use Eclipse, but build using ant. The Jersey stuff libraries are in my Maven .m2 folder. I did right click on my project and select Maven > Update. That is at 2.7.
I came across this site, which talks about Java 9 migration. In the site, I read that if you add java.se.ee, you will have access to all Java EE modules. That recommendation failed, same output. The command that I tried was:
java --add-modules java.se.ee -jar ./build/bin/DataMover.jar
I did check SO and quite a few other sites but have turned up empty so far. Thoughts?
I'm trying to run a Java application and I get the following error message. The application itself loads correctly, it just appears to be certain parts of it that fail.
Nov 13, 2012 2:43:53 PM org.jdesktop.application.Task failed
SEVERE: My.Application$9#7c4f8358 failed: java.lang.NoClassDefFoundError: javax/media/opengl/GLCapabilitiesChooser
java.lang.NoClassDefFoundError: javax/media/opengl/GLCapabilitiesChooser
at jpl.mipl.jade.jadis.agile2d.swing.JOGLPluggableRenderer.notifyBeforeSetRootPane(JOGLPluggableRenderer.java:105)
at jpl.mipl.jade.jadis.StereoJFrame.setRootPane(StereoJFrame.java:264)
at javax.swing.JFrame.frameInit(JFrame.java:236)
at javax.swing.JFrame.<init>(JFrame.java:159)
at jpl.mipl.jade.jadis.StereoJFrame.<init>(StereoJFrame.java:172)
at StereoWS.DSStereoFrame.<init>(DSStereoFrame.java:70)
at StereoWS.StereoWSView$9.doInBackground(StereoWSView.java:1067)
at org.jdesktop.swingworker.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at org.jdesktop.swingworker.SwingWorker.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.ClassNotFoundException: javax.media.opengl.GLCapabilitiesChooser
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 14 more
I'm running OS X 10.8 fully updated, I've installed JDK 7 and, in frustration, Apple's Java development tools. The program relies on a number of external libraries, but these are supplied with the jar and I trust that the program does actually look for them in the distribution directory when it runs (the errors aren't due to those packages though, I believe). As far as I can tell everything that I need to run the application is either already installed or somewhere where the jar can find it
I don't know if there's anything else I need to do to set up the environment that I haven't done yet, so if anyone can suggest something, I'm all ears! I will provide any extra information needed, but I don't know what would help - I'm not a Java guru by any means.
I believe you are using Java3D jars from the old Oracle site in combination with the latest JogAmp JOGLv2, this will not work of two reasons A) the jogl.jar is now renamed jogl-all.jar B) internal namespace changes, all com.sun.* classes is now found under com.jogamp.* and this will confuse the old Java3D code that expects the com.sun.* namespace.
Both JOGL and Java3D is now maintained by members of the JogAmp community:
Background of the move: http://labb.zafena.se/?p=656
The only supported way to use Java3D today is by using the community maintained Java3D in combination with the latest JogAmp JOGL v2.
Tutorial on how to setup the latest community maintained Java3D in combination with JOGLv2.
Julien Gouesse: Java 3D est de retour [Java 3D is back]
http://gouessej.wordpress.com/2012/08/01/java-3d-est-de-retour-java-3d-is-back/