If I build my own, tinkered version of rt.jar (called my-rt.jar) from the Oracle JDK 7 sources and hook it in with the bootclasspath mechanism, like this,
$ java -Xbootclasspath/p:/path/to/my-rt.jar -cp /path/to/h2-1.3.174.jar main
then, I can't even load the H2 driver at the beginning of my application:
// Application's main.java
public class main {
public static void main(String[] args) {
// ...
Class.forName("org.h2.Driver"); // Line 145
}
}
The above results in the following exception:
Exception in thread "main" java.lang.ClassNotFoundException: org/h2/Driver
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:190)
at main.main(main.java:415)
However, if I remove the -Xbootclasspath/p switch and with everything else the same as before, I can load the driver fine, and the rest of application too works fine too.
So, is there anything peculiar going on inside the initialization of a JDBC driver (such as H2's) that's preventing me from using the bootclasspath mechanism? Or, is there anything peculiar about the bootclasspath mechanism that it won't allow the loading of a JDBC driver like H2?
I'm out of things to try. For example,
I've even re-built the H2 driver from its sources and made sure that both my application and the driver are using the identical version of javac.
I've tried the above both from Eclipse and from command-line.
I've tried it on 2 different machines.
All yield the same exception.
Btw, my tinkered my-rt.jar has a very simple edit to it: It simply adds a public static int counter to java.lang.Object. Before the Class.forName(...) line above, I'm able to verify that I can indeed print the value of counter when the bootclasspath switch is enabled.
The strange thing is, even if I comment out this counter field in java.lang.Object but continue prepending my-rt.jar (that is as good as the original rt.jar, only recompiled andn prepended), even then I cannot get the H2 driver to be found/loaded!
(I've posted this on the H2 google group too but getting no response there. Maybe, those folks don't think this is an H2 problem, so I'm asking here.)
I've nailed it. Here's what I did.
I first prepended the original rt.jar to the original rt.jar, like so:
$ java -Xbootclasspath/p:/path/to/orig/rt.jar -cp /path/to/h2-1.3.174.jar main
And the exception disappeared! This clearly told me that the bootclasspath/p mechanism was no way interfering with the loading of the H2 driver.
So, I then unjarred the original rt.jar and diff'ed it with the unjarred contents of my-rt.jar, I found around a whopping 8000 files missing from my-rt.jar:
$ wc -l *.list
11285 my-rt.jar.list
19059 rt.jar.list
30344 total
So, obviously, my-rt.jar that I built from the official src.zip had tons of stuff missing from it. No wonder, H2 driver was having loading troubles.
To further confirm, this time I copied over only my tinkered java/lang/Object.class to the unjarred contents of the original rt.jar, and lo and behold, the H2 driver continued to load just fine.
Thus, the name src.zip is a terrible misnomer. Because it does not have everything needed to build rt.jar, it should be called partial-src.zip (or, something like that) instead.
Related
The following method :
private void startServer() { // snippet that starts the server on the local machine
try {
RemoteMethodImpl impl = new RemoteMethodImpl();
Naming.rebind( "Illusive-Server" , impl );
}catch(Exception exc) {
JOptionPane.showMessageDialog(this, "Problem starting the server", "Error", JOptionPane.ERROR_MESSAGE);
System.out.println(exc);
}
}
throws this exception :java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: Interfaces.RemoteMethodIntf
When i start my project, i am greeted with the message in JOptionPane saying problem starting the server and then the above exception. What could be the reason for this ?
I don't understand why does the last statement of exception says class not found exc when i have imported the right packages
There are four cases of this exception.
When exporting: you didn't run 'rmic' and you didn't take the steps described in the preamble to the Javadoc for UnicastRemoteObject to make it unnecessary.
When binding: the Registry doesn't have the stub or the remote interface or something they depend on on its classpath.
when looking up: the client does't have these things on its classpath.
When calling a remote method: you either sent something to the server of a class not present on its CLASSPATH, or received something from the server (including an exception) of a class not on your CLASSPATH: in both cases possibly a derived class or interface implementation of a class or interface mentioned in the remote interface's method signature.
This is case 2. The Registry can't find the named class.
There are several solutions:
Start the Registry with a CLASSPATH that includes the relevant JARs or directories.
Start the Registry in your server JVM, via LocateRegistry.createRegistry().
Use dynamic stubs, as described in the preamble to the Javadoc of UnicastRemoteObject. However you may then still run into the same problem with the remote interface itself or a class that it depends on, in which case 1-3 above still apply to that class/those classes.
Ensure that case (4) above doesn't occur.
Use the codebase feature. This is really a deployment option and IMO something to be avoided at the initial development stage.
Remote Server Error:RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: mathInterface
The error very simple to solve to be perform following steps:
For example your java file consider D drive
Start rmiregistry D drive( example D:\start rmiregistry)then don't start rmiregistry on the other drives, it will yield the above error
(Wherever your file is, start rmiregistry)
I will try to explain it as better as possible what I did:
1st. I declared the classpath variable like follow:
set classpath=%classpath%
set classpath=C:\compiler
set classpath=C:\compiler\libro\cap07\rmi\hello\Hello.java
set classpath=C:\compiler\libro\cap07\rmi\hello\Server.java
set classpath=C:\compiler\libro\cap07\rmi\hello\Client.java
(All in one lineset:
set classpath=%classpath%;C:\compiler;C:\compiler\libro\cap07\rmi\hello\Hello.java;C:\compiler\libro\cap07\rmi\hello\Server.java;C:\compiler\libro\cap07\rmi\hello\Client.java)
(I'm not sure if the .java files were nesesary, but I also wrote them for doubts).
2nd. I compilered with the line javac -d C:\compiler Hello.java Server.java Client.java. Where C:\compiler is the root directory like src on Eclipse IDE.
3rd. I ran the start rmiregistry line. (and don´t matter where you run it, it's the same).
4th. I ran:
start java -classpath C:\compiler -Djava.rmi.server.codebase=file:C:\compiler/ libro.cap07.rmi.hello.Server
You already know C:\compiler, but you need define packages address on the last to that the command can find the .class files. Open any .java file and copy the package address without packages sentense. You will see when you open the src directory (in my case C:\compiler), you find all directory sequence created. When this command line is created correctly, no matter where you will run it, C:, D:, src, anywhere it wil run.
5th. And finally, I ran the Client class with:
java -classpath C:\compiler libro.cap07.rmi.hello.Client
In conclusion, if the classpath variable won't created or it's to created wrong or the sentence of 4th point is not addressed well the JVM throws the same or similar error. Search there!
(Sorry my english).
You can launch rmiregistry from anywhere but you have to make sure that the compiled classes are already in your classpath. For example:-
E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes>set classpath=%classpath%;E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes <ENTER>
E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes>c: <ENTER>
C:\>rmiregistry
And the above should work fine.
In general, if you launch rmiregistry from the root location of the compiled classes (above example it is E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes), that will work because . (dot - current directory) is already set in your classpath.
But as soon as you remove . (dot - current directory) from your classpath, the above working condition will also fail.
Hope I have explained in details.
I got this same issue, and a different solution worked for me. I was running two different IntelliJ projects, with a copy of the interface in each project. One of them was in a package, and the other one wasn't, and that was what was causing this error.
Solutions:
Make sure the interface copies aren't in a package.
Make sure the interface copies have the exact same package name.
I keep getting java.lang.NoClassDefFoundError: Could not initialize class net.sf.jasperreports.engine.util.JRStyledTextParser
The full stacktrace is:
java.lang.NoClassDefFoundError: Could not initialize class net.sf.jasperreports.engine.util.JRStyledTextParser
net.sf.jasperreports.engine.fill.JRBaseFiller.<init>(JRBaseFiller.java:108)
net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:69)
net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:57)
net.sf.jasperreports.engine.fill.JRFiller.createBandReportFiller(JRFiller.java:200)
net.sf.jasperreports.engine.fill.JRFiller.createReportFiller(JRFiller.java:215)
net.sf.jasperreports.engine.fill.JRFiller.fill(JRFiller.java:115)
net.sf.jasperreports.engine.JasperFillManager.fill(JasperFillManager.java:583)
net.sf.jasperreports.engine.JasperRunManager.runToPdf(JasperRunManager.java:455)
net.sf.jasperreports.engine.JasperRunManager.runReportToPdf(JasperRunManager.java:870)
com.evnica.interop.main.ReportServlet.createReport(ReportServlet.java:119)
com.evnica.interop.main.ReportServlet.doGet(ReportServlet.java:96)
com.evnica.interop.main.ReportServlet.service(ReportServlet.java:79)
javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
I have searched for the solution and found a bunch.
Could not initialize class net.sf.jasperreports.engine.util.JRStyledTextParser
JasperReports NoClassDefFoundError exception on net.sf.jasperreports.engine.util.JRStyledTextParser
and about 10 more (this is my first question so I can't enlist them all).
I have tried:
To set java.awt.headless=true.
I did it within code:
static {
System.setProperty("java.awt.headless", "true");
System.out.println(java.awt.GraphicsEnvironment.isHeadless());
}
(returns true as expected).
I did it in JVM Options:
I set CATALINA_OPTS to -Djava.awt.headless=true. Echoes as expected.
It didn't help.
I tested it with.jrxml with DejaVu Sans and included jasperreports-fonts-6.2.2.jar in the path, and I tested it with Sans Serif. I checked which fonts were available to JVM and tested with them. No success.
There were suggestions to check versions of jasperreports jars - I checked it too. I have all the jars of 6.2.2. version:
jasperreports-6.2.2.jar,
jasperreports-fonts-6.2.2.jar,
jasperreports-javaflow-6.2.2.jar.
I use joda-time-2.9.3 (have no idea how it's connected to the problem, but one advice was to use joda; I used it from the beginning anyway), project SDK is java 1.8.0_51 (there was an advice to update to 8 - not relevant as I already use it), and my Tomcat is OK (the absent work folder caused similar problem in one of the cases).
What am I missing?
EDIT:
While debugging I came to a method initializeGrophEnv() in JRGraphEnvInitializer class, which throws a util.graphic.environment.initialization.error:
AVAILABLE_FONT_FACE_NAMES.addAll(Arrays.asList(GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames()));
It's interesting that the method getAvailableFontFamilyNames() in SunGraphicsEnvironment returns a valid array of 274 elements (printscreen from debugger under link):
First of all, thanks everyone for help. You responded so fast, and made me dig deeper =) The problem is solved.
My error was to have both jasperreports-6.2.2.jar and jasperreports-javaflow-6.2.2.jar in the libraries. As you remember, the last method in the stack trace was the initialization of JRBaseFiller. The presence of two jars caused a conflict, as both contain a package net.sf.jasperreports.engine.fill with a JRBaseFiller class in it.
I left the jasperreports-javaflow-6.2.2.jar only. It didn't work on its own. I added two more libraries: jfreechart-1.0.19.jar (previous versions didn't contain all the needed classes) and jcommon-1.0.8. The java.lang.NoClassDefFoundError is gone.
I am manually constructing the classpath for my Play/Scala/Akka application so I can use the ScalaTest runner to test my application during different stages of a CI pipeline without the need to recompile. However, I get the following error:
java.lang.NullPointerException:
at com.typesafe.config.impl.Parseable$ParseableResources.rawParseValue(Parseable.java:509)
at com.typesafe.config.impl.Parseable$ParseableResources.rawParseValue(Parseable.java:492)
at com.typesafe.config.impl.Parseable.parseValue(Parseable.java:171)
at com.typesafe.config.impl.Parseable.parseValue(Parseable.java:165)
at com.typesafe.config.impl.Parseable.parse(Parseable.java:204)
at com.typesafe.config.impl.ConfigImpl$1.call(ConfigImpl.java:368)
at com.typesafe.config.impl.ConfigImpl$1.call(ConfigImpl.java:365)
at com.typesafe.config.impl.ConfigImpl$LoaderCache.getOrElseUpdate(ConfigImpl.java:58)
at com.typesafe.config.impl.ConfigImpl.computeCachedConfig(ConfigImpl.java:86)
at com.typesafe.config.impl.ConfigImpl.defaultReference(ConfigImpl.java:365)
Here is the command I am running:
/usr/lib/jvm/java-7-openjdk//bin/java -Xmx256M -Xms32M -Xbootclasspath/a:$BOOTCP -classpath '""' -Dscala.home=/usr/opt/scala -Dscala.usejavacp=true -jar /home/nick/repos/testrunnnertest/lib/scalatest.jar -R target/scala-2.10/test-classes -o
The value for $BOOTCP is a massive list of dependencies including the application jars, the dependencies in .ivy2 and the folders containing the config files (/conf, /test/resources). I copied this command from the Scala shell script. I also used the value for $BOOTCP as the value for -classpath, but I still had the same problem.
This problem only happens when I run my acceptance tests which are spinning up a Play Framework Test Server. So it seems likely that it is a problem loading the main application configs in /conf rather than the /test/resources configs which appear to load find when the Unit and Integration tests happily run.
Coming to this question pretty late, but did you ever figure it out? Which typesafe config version is on your classpath?
Line 509 on master doesn't look like it could be quite the right line: https://github.com/typesafehub/config/blob/master/config/src/main/java/com/typesafe/config/impl/Parseable.java#L509
so you may have a version with slightly different source.
Version 1.0.2 line 509 looks maybe more likely: https://github.com/typesafehub/config/blob/v1.0.2/config/src/main/java/com/typesafe/config/impl/Parseable.java#L509
On that line most likely the class loader is null I guess? It's supposed to come from here in that trace: https://github.com/typesafehub/config/blob/v1.0.2/config/src/main/java/com/typesafe/config/impl/ConfigImpl.java#L365
Which in turn comes from: https://github.com/typesafehub/config/blob/v1.0.2/config/src/main/java/com/typesafe/config/ConfigFactory.java#L380
So one theory is that the thread has no context class loader set in the case where it throws an exception. I can't tell you why that's the case in your scenario, if it is, but perhaps it is a lead.
I don't think typesafe config should throw NPE this "late" in any case so I created https://github.com/typesafehub/config/issues/155 to fix this up. However it most likely is ultimately a problem in play and/or how you're setting things up that the thread context class loader is null and no other class loader was provided to ConfigFactory methods.
This is assuming that the NPE is from a null class loader, I don't think that's necessarily the problem, but it looks plausible from that stack trace.
Firstly I would like to say that I'm new to Java programming and Sybase.
I have a problem with connection to Sybase database.
To establish the connection I have done:
Installation of jdbc driver for advantage db;
Set environment variable named CLASSPATH with url value to adsjdbc.jar (I installed jdbc drivers in c:\AdvJDBC so the path is c:\AdvJDBC\JDBC\adsjdbc.jar );
Then I'm tried to import drivers in my code:
public class SybaseCon {
public static void main(String[] args){
Class.forName("com.extendedsystems.jdbc.advantage.ADSDriver");
}
And I'm getting an error:
Exception in thread "main" java.lang.ClassNotFoundException: com.extendedsystems.jdbc.advantage.ADSDriver
I have searched for the solution in advantage jdbc driver help, but I found nothing that could resolve my problem.
Workaround:
My Java version: jdk1.7.0_03
Advantage file db: 11.0
Advantage jdbc driver: 11.0
First, make sure that your CLASSPATH variable is actually set in the environment that you think it is.
Typically, in Windows, if you set the environment variable in the system settings, open command windows (and your open IDE) won't see the setting. You have to close and re-open them for it to take effect.
Try adding this to your code, just before the Class.forName line:
System.out.println(System.getProperty("java.class.path"));
It will show you the classpath that your application is actually using.
Second, you'll probably have a much easier time if you specify the classpath using java's preferred path notation, which happens to align with unix/linux format - using forward slashes. Try using
java -cp /AdvJDBC/JDBC/adsjdbc.jar
In Eclipse I get this eror:
Exception in thread "main"
java.lang.UnsatisfiedLinkError:
com.nokia.mid.impl.isa.util.SharedObjects.nativeSetTable(Ljava/util/Hashtable;)Ljava/util/Hashtable;
I can see SharedObjects, but nativeSetTable doesn't seem to be a method. It might however be hidden -> I don't have access to the source code.
This was my code:
connection = (HttpConnection)Connector.open(this.url);
This is the trace:
Exception in thread "main" java.lang.UnsatisfiedLinkError:
com.nokia.mid.impl.isa.util.SharedObjects.nativeSetTable(Ljava/util/Hashtable;)Ljava/util/Hashtable;
at
com.nokia.mid.impl.isa.util.SharedObjects.nativeSetTable(Native
Method) at
com.nokia.mid.impl.isa.util.SharedObjects.createTable(SharedObjects.java:465)
at
com.nokia.mid.impl.isa.util.SharedObjects.(SharedObjects.java:181)
at
com.nokia.mid.impl.isa.io.GeneralSharedIO.(GeneralSharedIO.java:67)
at
com.sun.midp.io.ConnectionBaseAdapter.checkForPermission(ConnectionBaseAdapter.java:236)
at
com.sun.midp.io.ConnectionBaseAdapter.openPrim(ConnectionBaseAdapter.java:205)
at
com.sun.midp.io.ConnectionBaseAdapter.openPrim(ConnectionBaseAdapter.java:178)
at
com.sun.midp.io.InternalConnector.openPrim(InternalConnector.java:254)
at
com.sun.midp.io.InternalConnector.open(InternalConnector.java:153)
at
javax.microedition.io.Connector.open(Connector.java:138)
at
javax.microedition.io.Connector.open(Connector.java:120)
at
javax.microedition.io.Connector.open(Connector.java:104)
I think that nativeSetTable() is protected or private, that's why you don't see it. And moreover nativeSetTable() is a native method, which means that it is based on native code (already compiled for a specific processor and available in a specific lib [ie. a DLL]).
UnsatisfiedLinkError means that this particular method couldn't be retrieved and executed properly.
Thrown if the Java Virtual Machine cannot find an appropriate native-language definition of a method declared native.
This means that your Java ME emulator must have missing librairies. You should try to reinstall it.
Resources :
Javadoc - UnsatisfiedLinkError
I guess you are coupling your source code with the wrong version of the nokia mid library.
It could be that your runtime classpath is using a different version of the jar where SharedObjects lives, when compared to your compile-time classpath in Eclipse. I would double-check your classpath settings.
Ok, I found one reason:
I created a test class in java to test my code, just a plain java file (with main method). And I ran it as a plain java application. Then, it doesn't work. But after I tried it in a Midlet, I didn't get the error!