I am working on a Java-EE project involving Glassfish 3.1.2.2 and the client component is running with Java 7 Update 21. The Swing-based client was formerly based on Java 6 Update 38 until we decided to migrate to the new Java 7 Update 21.
I get the following compilation warning in Netbeans 7.3:
warning: Supported source version 'RELEASE_6' from annotation processor 'org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor' less than -source '1.7'
At this point, the compilation process hangs for about 1 minute.
Btw, we still have the javaee-api-6.0.jar referenced that is provided by the Netbeans platform (I think there's no javaee-api-7.0.jar available yet?)
Does somebody know the reason for this warning and how I can get rid of it ?
Any help highly appreciated - many thanks in advance.
It seems (I think) that the eclipseLink annotation processing for JPA is up-to-date until Java 6. You could make a Java 6 library with the JPA sources, and only there use eclipseLink annotation processing. Having a library never hurts, and later you may upgrade to Java 7 independantly.
Can't image using much Java 7 functionality in the JPA sources.
Java version 7 has more features as compared to Java 6. In netbeans, go to Tools-->Java Platforms and check whether your netbeans ponts to the latest version of JAVA.
I thing You have added unwanted library,first, you have to check your library of your project and delete the unwanted files there. On the other hand, you can retry it by copying only the JFrames and Main Classes into a new Project. But One thing, You have to replace the name of package as the new name.
Related
My application is based on Eclipse 3.8, and I'd like to know if it will run over Java.
I'm not using a newer version because it has performance issues. From my experience, Eclipse 3.8 is a lot faster compared to any newer versions of Eclipse.
Does someone know something about this?
UPDATE: The previous title may suggest that I want Eclipse 3.8 to be able to support the new features of Java 9. But, I really just want to know if I'll be able to run the application over Java 9 JRE.
Yes it works, but only with a small patch.
It fails because the org.eclipse.osgi bundle of Eclipse 3.8 (Juno) has no runtime profiles for Java 8 or Java 9. If you add those it works for me.
I made successful tests with an RCP-based app on target plattform 3.8.2 (http://archive.eclipse.org/eclipse/downloads/drops/R-3.8.2-201301310800/) running under Java 9 Oracle JVM under Windows 7.
What to do:
You have to patch the org.eclipse.osgi bundle:
strip signing information
manually add an entry for the Java 9 Runtime Enironment in the profile.list of the bundle and add a JavaSE-1.9.profile definition
E.g.: https://github.com/derWallace/org.eclipse.osgi
But no guarantees that this is a good deal for production!
No. Oxygen (4.7) and newer only is what's planned. If your performance findings are verifiable and repeatable, file bug reports about them.
I see in version JMockit 1.8 support for Jacoco was fixed, however this also went hand in hand with making Java 6 a minimum requirement.
Is there a way of getting version 1.8 to work with a build runtime of Java 5? Or even patching the fix for Jacoco into version 1.7? What changed, could I do it?
We can't upgrade our build servers for a few months, so this would really help us use this feature.
You can use Java 6 as compiler, and make a war 1.5 compliant. Anyway, the tests are not deployed on server side.... (Or I hope so)
I have been using ojdbc14.jar earlier and now want to upgrade it to ojdbc7.jar for supporting oracle12c.
But while connecting server gives error for "oracle/security/pki/OraclePKIProvider".
If I add oraclepki.jar to the classpath server starts up properly without any error.
I am trying to figure out what special got added in ojdbc7.jar that its asking me to add oraclepki.jar, As with ojdbc14.jar it never asked me to add oraclepki into my classpath.
Does anyone know what changes with ojdbc7 that's causing this error and what can be done to avoid adding oraclepki on classpath?
Check your classpath and make sure you remove the following: (if it exists)
-XX:-UseSplitVerifier
This is an issue recorded in the Oracle Support Database. If you have Oracle Support, you can find out more there. If not...
As Joseph Carroll states, removing the -XX:-UseSplitVerifier from your command line Java arguments might solve your problem. The UseSplitVerifier argument basically tells Java to use an earlier, less stringent, byte code verifier (which was sometimes used to get older byte code instrumentation tools to work when upgrading from Java 6 to Java 7). Unfortunately, it caused some problems when upgrading certain tools from Java 7 to Java 8. Other things you might do include (per Oracle):
Upgrade to a java 7 compatible bytecode instrumentation tool.
Or, as
a workaround, include oraclepki_121020.jar in the classpath. This is
a valid workaround in case upgrading to a java 7 compatible bytecode
instrumentation tool is not possible.
This article talks about why -XX:-UseSplitVerifier was added for using Java 7 with Oracle. This article talks about using the –noverify flag with Java 8 instead of -XX:-UseSplitVerifier.
I have a PowerMac and it is giving me bad version number on some .jars. I would love to make it seem like I am running Java 6. How would I spoof the version? Let me also say I am running PowerPC and Leopard
The most likely problem is that you have Java 6 JAR files and you are trying to run them on an old Java installation.
How would I spoof the version?
The answer to your question is that you can't. The way to run Java 6 specific JAR files it to use a Java 6 (or later) JRE or JDK.
The problem is that the format of Java class files has changed, and your installation can't cope with the new format. And this is not a gratuitous change that you can pretend doesn't exist. Java 6 (actually Java 5) has support for generic types, enums, annotations and other things. Assuming that the JARs contain code that uses these new language features, an older JRE simply won't know what to do with them.
There are two solutions:
Upgrade your Java installations to the required level on all machines. This is the best solution ... if it is an option ... because it means your users will get the benefit of security and bug fixes and performance enhancements. (And progress of your project won't be held back by the constraint of supporting legacy platforms.)
Compile all of your code for compatibility with the oldest version of Java that you still have to use. Either compile on the corresponding old JDK, or on a more recent JDK using appropriate -source / -target / -Xbootclasspath options ... as described by the javac manual page.
The catch with the second solution is that if the source code for the JAR files in question uses recently added Java language features or APIs, then recompiling for the older platform will fail. To fix this you will need to rewrite your code to replace the nice modern stuff with archaic stuff. Not a good solution, IMO.
The other possibility is that you are seeing corrupted JAR files. This is unlikely, but it can happen if you are using applets or webstart, and the server is delivering error pages instead of JAR files.
The third possibility is that you simply haven't configured your Mac's Java installation's correctly. Making Java 7 the default should allow you to run everything without class version problems. (Thanks #paulsm4) Note that I can't help you with that ... 'cos I don't use Java on a Mac.
I have a 3rd party JAR file that is compiled using Java 1.4. Is there a tool that can make the jar file compatible with Java 1.6? (Something like 'retrotranslator' but what does the reverse of it).
I tried decompiling the class files and re compile them in 1.6 but it fails.
Here is the issue:
My project uses 'rsadapter.jar' for was 5.1 and I had my project setup in Eclipse 2.0 + JDK 1.4 and it used to work fine. Now, I have migrated to Java 1.6 and Eclipse Ganymede (as per the requirements) and the same project (exactly same setup) started complaining about the missing class files in the 'rsadapter.jar'. I put the JAR in classpath explicitly too but it still could not load the classes. Then I changed the Java Compiler version to 1.4 and it started working.
Regards,
- Ashish
Classes compiled by JDK 1.4 should be usable in a Java 6 runtime as-is. If you have actually encountered a problem, please describe it.
Update: I can only reproduce this with types in the "default" package (that is, not in a package). Are the classes you are trying to use in the default package? Also, this happens to me regardless of the JDK version used to compile.
Update: Okay, after a little research, I realized that you can never reference a type in the unnamed package from a named package. Makes sense, but definitely not what you are running into.
I can compile code under JDK 1.4.2_19 and utilize it just fine in a Java 6 Eclipse project. I think that this problem is something specific to your environment. In this situation, I would backup Eclipse and recreate everything (JDK installation, workspace, projects) from scratch, to see if I could clear it up.
I had another issue with some legacy code written in Java 1.4.x: the authors loved enumerations and loved to name the corresponding variables 'enum'. They even used it for package names. And this prevents from compiling the code under Java 1.5 (or higher) quite successfully.
Changing that automatically is quite an issue.
May be you have defined Eclipse to throw compiler errors on use of deprecated methods or classes?