I'm working on updating a large old Java application to Java 17.
It was on Java 11. Note that we build in Eclipse, and all the projects that are part of this application have Java 1.8 compatibility turned on.
Now that I've updated it all to Java 17 (and updated the truckload of .jar files we use to their latest versions as well), I'm getting a problem with a code generator plugin we wrote.
I was able to rebuild the plugin .jar and it seems to be valid. The problem is that when it runs, it fails With this msg:
The method parse(File) from the type DataModelParser refers to the missing type ParserConfigurationException
Since the class definitely exists, I'm assuming it's running into the issue where Java doesn't like being able to find the class in 2 places.
using Ctrl-Shift-T, I find the class available from Java 17 (expected) and "C:\Users\JohnLuss.p2\pool\plugins\javax.xml_1.3.4.v201005080400.jar"
That jar is part of Eclipse - so why does Eclipse have jars that conflict with java 17?
HOW can I make this work? Is there any way to exclude the Eclipse jar?
Related
No matter what I try, Eclipse complains about QName not being found... It is indeed on the Classpath. It doesn't cause any other issues, I can compile and run, it just always shows that it can't find it.
Eclipse Java EE IDE for Web Developers.
Version: 2018-09 (4.9.0)
Build id: 20180917-1800
OS: Mac OS X, v.10.14, x86_64 / cocoa
Java version: 11
All I did to make Eclipse to recognize it correctly was move the Java 11 Library up above the Maven Dependencies in Order of imports and Exports... I do not have an explanation as to why this corrected it or even a theory as to why but it works.
Some people who reported similar problems had a module-info.java created.
If you have done that:
either remove it, if you don't need the module system's features
or add a matching requires java.xml; statement to it (assuming you mean javax.xml.namespace.QName). Actually there should be a quickfix that offers to do that, if you use the qualified name in the code and have an error there.
(actually it sounds suspicous that you say you can actually compile and run your code - maybe the errors are just in places that are not used by your test run?
I'm trying to build a large Open Source project in Eclipse; it uses Maven so I've installed the various plugins (m2eclipse etc) but I'm a little unfamiliar with this setup.
I can build and run the particular JAR I'm interested in with no issues. However, when the newly built JAR tries to open a large ZIP file, I get this:
Exception in thread "main" java.lang.RuntimeException: java.util.zip.ZipException: invalid CEN header (bad sig
nature)
at org.opentripplanner.graph_builder.impl.GtfsGraphBuilderImpl.buildGraph(GtfsGraphBuilderImpl.java:17
9)
at org.opentripplanner.graph_builder.GraphBuilderTask.run(GraphBuilderTask.java:127)
at org.opentripplanner.graph_builder.GraphBuilderMain.main(GraphBuilderMain.java:51)
Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(Unknown Source)
I did some research and it seems that this error means that java.util.ZipFile can't read the file because it's in ZIP64 format. Apparently this was fixed in Java 1.7, so dutifully I've updated the JDK on OS X, and tried to change the Maven project by right-clicking on it in Eclipse, then altering the Project Facet, which in turns seems to have updated the JRE libraries in that project to 1.7:
However, this doesn't work - I still get the error even having re-built the whole project.
Is it possible that the old java.util.zip is still being pulled in from somewhere? I'm not too familiar with how linking works in Java, can older JDKs be 'embedded' like this within dependencies? Or does the java.util.zip just get used that's on the target machine? (this is definitely JRE 1.7) I know for a fact that the code throwing the exception is actually contained within a separate JAR that's pulled in as a Maven dependency:
Do I need to track down and re-build this external JAR against Java 1.7, is that the issue here? Or is there a concept of a Maven 'parent project' that's regressing my new JRE 1.7 back to 1.6? Sorry if these questions are naive.
I originally thought that it would be as simple as just updated the JRE on the runtime machine, but apparently not. So how do I resolve this error?
Assuming that the problem is really caused by using an older version of Java, then rebuilding is not going to make any difference. The real problem is that your application JAR is running on an older JRE.
In the command shell you are using to run your application, run java -version. That will tell you what JDK / JRE will be used when you then run java -jar yourApp.jar ...
The most important point in relationship with maven is bear in mind that the source of the truth is the pom file in Maven and NOT the IDE anymore. So changing the compiler version must be done in the pom.xml file and NOT in the IDE.
Maven ignores what JRE are you using in eclipse, you have to force it with the maven compile plugin config. Here is how in this link http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html But with version 1.7 instead of 1.3
I wish to load my applet with JRE version 1.6.0_14. I have installed updates 14, 17, 24 and 35. I am using <object> tag with classid to load version with update 14.
in this case, the applet get loaded with update 35 and then again with update 14. on the java console on update 35 no error noticed and on Java console of update 1.6.0_14 we see the following error.
java.lang.ClassNotFoundException: sun/net/www/protocol/http/NTLMAuthenticationCallback
How to avoid higher version JRE to be used? And how to avoid the class not found error?
It is a serious security risk to run with a lower version of the JRE. Not when you run your own applet, cause you trust your own code. But others ought to refuse running it. You, yourself, should be wary when browsing the net with a browser that does not have the latest version of the JRE installed.
The JRE installer installs the Java Plugin into your browser and one single version of the Plug-in will always be started, independent of the Java version you request. The Plugin will then run the applet in the JRE that is specified in the classid of your object tag. The versions available to the Plug-in are configurable in the Java Control Panel.
This leaves the question of why your application won't run with a recent version of java 1.6. The Plugin got a big overhaul in 1.6.0_something into what's called the Next Generation Plug-in. Maybe that is what is giving you trouble. You can indicate that you wish to use the old Plug-in on your machine in the Java Control Panel on the advanced tab. ("Enable the Next Generation Java Plug-in (requires a Browser restart"). I'd think it's interesting to know if disabling the Next Generation Plug-in solves your issue.
We have a Java EE 5 project developed using Netbeans 6.7.1 with Glassfish v2.1. Trying to open this project with Netbeans 6.9.1 with Glassfish v3.1 there are many errors concerning missing types.
Is Java EE 6 backward compatible with Java EE 5?
The missing libraries generally revolve around:
javax.xml.rpc.ServiceException;
javax.xml.rpc.Stub;
org.jvnet.staxex.StreamingDataHandler;
com.sun.xml.ws.fault.SOAPFaultBuilder;
Any ideas?
[Update]
It seems that not all of the required libraries are being added to the classpath for a Glassfish 3.1 project automatically. The main missing jar is jaxrpc-api-osgi.jar under glasshfish3/glassfish/modules/. If I add this jar manually all the problems go away. Why would this be the case? Why isn't the jar added automatically as is done using NetBeans 6.7.1 with Glassfish 2.1?
[Update]
I managed to hunt down org.jvnet.staxex.StreamingDataHandler; and com.sun.xml.ws.fault.SOAPFaultBuilder; via:
com.sun.xml.internal.org.jvnet.staxex.StreamingDataHandler;
com.sun.xml.internal.ws.fault.SOAPFaultBuilder;
Looks like some package changing went on. Still, this doesn't fix my problem with javax.xml.rpc.Stub; and javax.xml.rpc.ServiceException; not being added to my classpath correctly. I don't feel it's right to add the jar manually.
Wulfgarpro
Nothing is ever completely backwards compatible, but having those classes not showing up at all is suspicious. At least the first two are definitely in Java EE/Java 6. If there were incompatibilities I'd expect something like parameter mismatches or methods not found.
First place I'd look is at the Netbeans project setup -- I'd bet a small amount of money that your classpath.search path doesn't include something you need.
javax.xml.rpc is present in both EE 5 and 6. So this can't be about API version incompatibility. There must be a problem with the way your Netbeans project is set up.
I fixed the problem by uninstalling all JDK, JRE, and NetBeans. Reinstalling, the issue was rectified.
WulfgarPro
I was trying to compile a Grails application referencing third party JARs on Mac OSX. Although my system's JRE and JDK is set to Java 1.6 I always got a Compilation error: java.lang.UnsupportedClassVersionError: Bad version number in .class file
when accessing classes in the JAR. Also when testing an existing Grails app the default stats of the app where showing that it's running with Java 1.6. So I really didn't have more ideas than to try to change the Java settings in Eclipse - I thought that's stupid as I'm not using Eclipse for the devlopment of this application - but voila - now the compilation of my app on the command line works just fine!
Can anyone explain me what Eclipse is doing here behind the scenes?
I've had set the JAVA_HOME manually before with no effect.
The JDK (JAVA_HOME) used to launched eclipse is not necessarily the one used to compiled your project.
To see what JRE YOU y can select for your project, check the preferences
General > Java Installed JRE
By default, if you have not added any JRE, the only one declared will be the one used to launched eclipse (which can be defined in your eclipse.ini).
You can add any other JRE you want, including one compatible with your project.
After that, you will need to check in your project properties (or in the general preferences) what JRE is used, with what compliance level: