I am facing an strange issue. I developed java web app in java 6 and when I hosted it on server, its shows error since its java 5 server. I have used annotations, hibernate, rest API in my code and now I want to transform my code with java 5 environment.
is it possible to do so? if yes HOW? Or is there any other workaround for this problem? Please let me know.
#all: This is the error i am getting:
I am not sure what your build process is but you need to compile your code for a specific target like java 1.5.
If you are using javac from the command line look at the -target switch
If you are using ant then look at the target property.
You will run into problems if you are using java 1.6 specific libraries. You will know this when you try and run your code/webapp.
I hope this helps.
You'll have to look at the individual errors and figure out what is missing.
The JPA annotations were already part of Java EE 5, so if "hibernate" is causing problems, it either means you are not in fact running on Java EE 5, or you're using hibernate-specific annotations. The REST annotations were indeed added in Java EE 6, but can be used in a Java EE 5 environment relatively easily by adding a JAR with the API as well as the implementation (e.g. Apache Jersey) to the app's class path.
BTW, there's some confusion here concerning Java SE vs. Java EE. You're clearly talking about Java EE features, but there is a big difference between Java SE (which most people think about when you just say "Java") and Java EE.
From your post, it seems you're using Java EE 6 features in a Java EE 5 environment. If your app. server doesn't support such features at its core level, such as sing Servlet 3.0 features in a Servlet 2.5 environment, then you're out of luck.
However, when using features that are libraries, like Hibernate, you can get away using it in a Java EE 5 environment.
Java 6 as a language remains the same as Java 5, however, libraries have changed. Likewise, using JRE classes and methods that are in 6, won't work in 5.
Update: from your screenshot, I see that you're using Java 6 compiled classes on an older version of Tomcat. Compile them for Java 5.
You are trying to run classes compiled against Java 6 on Java 5 (Tomcat 5.x uses Java 5).
You can upgrade to Java 6.
You can compile the classes to be Java 5 compatible by using "-target" argument to javac but this option is not going to help as the problem is occuring with the servlet api. JEE6 requires Java 6.
Related
I am using java 6 with GWT2.2.1, but the current requirement is to upgrade java from java 6 to Java 7. Is it possible to upgrade?
Your help will be appreciated.
Java 7 support was added in GWT 2.6.0. On the server side, you can use whatever Java version you like. However on the client side, you won't be able to use Java 7 features with GWT <2.6.0. You can use a Java 7 (or even 8) JDK to compile your project, just force it to use Java 6 (and of course, don't use features from Java >6 in your client side code), for example, using -sourceLevel 6.
We are currently using spring 3.2.9. We are thinking of upgrading that to a newer version. When I checked the documentation it says that
Along with 4.0 M1, we’ve released Spring Framework 3.2.3, containing
fixes for recently reported issues but also coming with OpenJDK 8 runtime
support. Spring Framework 3.2.x will support deployment on JDK 8 runtimes
for applications compiled against JDK 7 (with -target 1.7) or earlier.
Does that imply that I can't compile on Java 8?
Should I use spring version 4.0.x if I wanna compile with Java 8?
There is a best effort support of JDK8 in the 3.2.x line, as of 3.2.9+.
See SPR-11656 for initial support in 3.2.9 and SPR-11979 for bytecode support improvements in 3.2.10. Please note the support limitations explained in the comments.
For comprehensive support of JDK8, please upgrade to Spring 4.x - there's a dedicated wiki page explaining the upgrade path, and the Spring team made great efforts to make that upgrade experience really easy.
As per my observations, you can actually use spring 3 with code compiled in Java 8, as long as you do not use new java8 syntax in there (like lambdas) in the paths scanned.
So, you can use new APIs (streams ...), but not new syntax (lambdas...).
When I tried, I ended up with startup errors like org.springframework.beans.factory.BeanDefinitionStoreException: Failed to read candidate component class
Versions of the Spring Framework that are older than 4.0M1 do not work with classes that are compiled for Java 8.
Spring tries to Proxy these classes by reading class files, which won't work if they're "too new". If your #Service classes are compiled with Java 8 as the target, Spring will fail to load the classes on startup.
This means that you will have to upgrade to Spring 4.x.x, if you want to target Java 8 (and use lambdas, default implementations and so on).
I encountered this problem myself a few months ago with a project that uses Spring 3.x.x.
On the GlassFish homepage it is stated that
Java EE 7 requires JDK 7 or above, JDK 8 u20 or above is recommended for GlassFish 4.1.
So I am wondering, why it is recommended to use it under the JDK 8, as GlassFish 4.1 is a Java EE 7 application server?
Is it just because that I will be able to use the new Java 8 functionalities? Or are there deeper reasons for this like stability, know bugs etc.
So does the GlassFish really runs better on the JDK 8 than on the JDK 7, or may I ignore this statement and just install it under JDK 7, if I do not use the new functionalities provided under Java SE 8?
So I am wondering, why it is recommended to use it under the JDK 8, as
GlassFish 4.1 is a Java EE 7 application server?
I guess they just recommend to use the newest compatible non-beta Java version which in this case is Java 8. The Java EE specs version (in this case Java EE 7) which is implemented by Glassfish 4 and the JDK version which is required (or which can be used) to run the server are two different things.
Also note that Java 7 has its EOL (End of Life) in April, 2015. There will be no further updates for Java 7 so at some point you'll have to switch to Java 8 anyway.
Is it just because that I will be able to use the new Java 8
functionalities?
This could be one reason for you to use JDK 8.
Or are there deeper reasons for this like stability, know bugs etc.
I guess there may be some bugs in JDK 7 which are fixed or do not occur in JDK 8, but this shouldn't be anything critical. In terms of stability I think the values are similar when not the same.
So does the GlassFish really runs better on the JDK 8 than on the JDK
7, or may I ignore this statement and just install it under JDK 7, if
I do not use the new functionalities provided under Java SE 8?
I wouldn't say that Glassfish runs better, but I would also recommend to use the latest compatible Java version. But you can currently also safely ignore the statement and use JDK 7.
For some additional information, this spring.io blog post contains a nice summary about Java 8 in enterprise projects and with various application servers.
One reason that was understood for GF to recommend using Java 8 is to leverage on new functionality it offers, such as SNI support for example. However, GF itself is not yet making full use of it.
Looking at the documentation for NotNull under Java 7, you can see javax.validation.constraints.NotNull is a valid and documented annotation. However upon navigating to the same page for Java 8, I receive a 404.
Netbeans suggests to import com.avaje.ebean.validation.NotNull, which is not what I want (it doesn't support nearly as many placements).
I've heard of the tag NonNull instead, but I can't find java documentation nor can I import it in netbeans. What am I meant to be using in Java 8?
javax.validation is not part of Java 8, it is part of Java EE, and is still included in Java EE 7
Don't confuse Java SE and Java EE: Differences between Java SE and Java EE.
There is no Java EE 8 yet, it's in planning mode. You can use Jave EE 7's NotNull just fine. Just get the appropriate libraries.
There's obviously no javadoc for a library that doesn't exist, thus the 404 .
Note that specifying an import statement simply makes it possible to refer to types by their simple name rather than by their fully qualified name. It does nothing to actually provide the classes at runtime or compile time. You still need to find the appropriate libraries, possibly packaged as a .jar, and put them on your compile time and runtime classpath, as required.
The Java Preferences application on my OS X Lion workstation indicates that I have Java SE 6 v1.6.0_29-b11-402 installed (both 32- and 64-bit versions). Unfortunately, I need additional features at are only available in the Enterprise Edition.
A comment by 'Jesper' in 'How install a specific jdk on Mac OS X?' suggests that I need to use the Java supplied by Apple, rather than the one from Oracle/Sun. Unfortunately, it doesn't seem that Apple offers an Enterprise Edition of Java 6.
This leads me to ask a number of questions:
Did I miss something? Does Apple offer an EE of Java 6?
If 1 is true, how do I get it? Can it be installed 'side by side' with the Java SE 6?
If 1 is false, can a Oracle/Sun version be used? Is there a recommended installation location? I'm guess that the /System/Library/Frameworks/JavaVM.framework/Versions/ folder is not recommended.
The Oracle/Sun version seems to include a lot of extras (e.g. Glassfish) that I would prefer not to install. Can I install the core SDK w/o the extras? Will Tomcat 7 work as an alternative to Glassfish?
** edit **
This question is a result of another question that I posted: RESTful web service: java.lang.NullPointerException service.AbstractFacade.findAll. It seems that this particular error is a result of a missing annotation (#Stateless). This annotation is 'contained' in the javax.ejb.* namespace, which is contained in a .JAR file that is not on my workstation.
This led me to conclude that I needed the 'Enterprise Edition' of Java 6 (which would have the missing .JAR file and other dependent files). I suppose if there was a way to determine which .JAR file is missing (Netbeans 7 doesn't seem to help with this) I probably could just add it to the project and skip the EE hassles.
There is no such thing as a special runtime called Enterprise Edition of Java for any platform.
There is Java SE and there are simply some interfaces that an Enterprise Edition container implements.
Sun confused the market with the naming convention years ago when they came up with J2EE. It never was a separate version of Java, just some tacked on APIs that if a server implemented them and passed some certification, could call themselves a J2EE container.
They further confused the market when they started calling it Java EE 6.
If you are developing against these APIs all you need is the .jar files that contain these interface declarations. You can download these API .jar files which used to be called J2EE. But they are pretty useless by themselves.
But I doubt that you are wanting to write a Java EE server, you want to use one. If you want to use a server then you need to download a Java EE compliant server and use the .jar files it provides.
Every IDE worth using includes these in some form, usually by defining a Server that you will be deploying against. Tomcat isn't a fully EE container. It is a Servlet container, which is a subset of the full EE specifications.
As of OSX Lion, Apple doesn't supply a JDK anymore, it is only the Oracle one, which you apparently already successfully acquired.
Java EE 6 is a spec, with some accompany API represented as interfaces. Java EE 6 in and of itself is not an implementation of those APIs. If you wish to use the Java EE 6 APIs you will need to avail your self of a compatible Java EE Application Server. Glassfish is the reference implementation of Java EE 6, however there are other servers as well that are compliant. JBoss is another popular option.
These install easily on Mac OS X.
There is a Java EE download. http://www.oracle.com/technetwork/java/javaee/downloads/index.html On its own though, its not particularly useful unless you're trying to develop an application that is intended to run in multiple containers.
What you will typically want to do is to download a container and develop with that. e.g. Glassfish (available at same link above). This task can be made easier with support from an IDE such as Netbeans. You can download a version of Netbeans that already includes Glassfish and the Java EE APIs and just start working. Other IDE/container combinations are possible, usually there is some sort of plugin available.
The Java 6 JDK/JRE for OSX is still from Apple. They transitioned most of the code to Oracle however, and the OSX version of JDK 7 is close to release status, and it may be mature enough for your purposes. My best guess is that it is.