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.
Related
With the advent of Java 11, the common consumer JRE is 3 whole feature releases behind. Would it not make sense to update by now, or does Oracle just intend for developers to set their source compatibility to Java 8?
This is because they're switching to a long-term service (for stability) and non-long-term-service (for new features) model for support timelines. Java 8 was the previous LTS version, so for stability reasons, it has been the default version pushed on people and not 9 or 10.
Java 11 is their very latest LTS version, but it just came out. I'm assuming they want to iron out any found bugs before recommending it more generally, but you'd have to ask Oracle to find out for sure.
Today i received a request to make a plan to update an web application deployed in a tomcat 7 to Java 1.8 and the reason was the web site security.
So i would like to know if is really important to update our web application to java 1.8 and the real problems if we keep our server using java 1.6 deployed in a tomcat 7 ?
best regards
The biggest risk is probably not for your application. The risk from your customer's perspective is that the Java 6 runtime is vulnerable to many things. If your application only supports Java 6, they need to have that on their workstations, which they don't want to, because it makes their workstations vulnerable.
Your app may also be vulnerable if running on Java 6, see the list of updates here for example. It depends whether you are using any API that had a security vulnerability since then. But my guess is your customer is primarily worried about their workstations.
Most java 1.6 code should compile and be fine with version 1.8 of java.
Things what are already marked as deprecated in java 1.6 (or earlier) may have been removed from a later release (1.7 or 1.8). Any of these will be obvious if you just compile your existing code with a java 1.8 compiler.
As mentioned in another answer, security risks of java 1.6 are a good reason to upgrade. Also versions 1.7 and earlier are already officially end-of-lifed by Oracle so only version 1.8 gets public security updates. It is possible to get a subscription to for java 1.7 security updates from Oracle. I'm not sure if there is one available for any other versions of java.
Another concern may be "is there a java 1.8 version of my JEE container."
1.8 has been out for a while so I suspect that the answer is "yes".
Here is the Oracle Compatibility Guide
Last JDK 1.6 and JDK 1.8 update in 2016-07-19. All platform supported now but only Java 8 have public security updates. It's a good reason for update your jre/jdk. Java 8 support most feature of Java 6, you don't have problem with compilation. But some of methods be deprecated.
The conclusion is that we need to use technologies that are supported by
the developer to the full.
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.
Since the release of Java 8, I found myself slowly becoming dependent on Java 8-specific features (ex. lambda statements) on a library project that I have just started.
I have seen many other projects which, to this day, still build against Java 7, or even Java 6, causing me to second-guess myself.
Is it a good idea to immediately start building against the newest version of Java, or should I still use older versions?
Note that unlike those other projects that have started back when Java 6/7 was the newest version, mine was started recently when Java 8 is the newest.
There are two reasons I can think of that would require staying with a pre-Java 8 JVM:
You are writing a library that is being used by a large group of people outside your organization who are still stuck on a pre-Java 8 JVM. If you use the latest and greatest JVM, they won't be able to use your product anymore.
You are dependent on a 3rd party library that has not upgraded to Java 8 and breaks on Java 8.
Since you mentioned this is a new project, #1 is unlikely. Even if you plan on having external users, if it's a new project, requiring the latest version of the JVM isn't really an issue.
Number 2 is also getting more and more unlikely as the more popular 3rd party libraries have released updates to work on Java 8. Even the few stragglers are usually OK working on Java 8. For example I use an ancient version of hibernate with Java 8. I just don't use any Java 8 features in any mapped fields/entities.
Java 8 denotes a major change to the language since Java 5 (or perhaps its inception). If you are targeting specifically the changed language parts (which I guess you claim) then making it usable only by Java 8+ runtime makes sense.
When Java 5 occurred 10 years ago and you wanted to use all the new features introduced at the time (e.g. foreach statement, Enums etc.) into your own library development, what would you have done? I believe you would have made your library require Java 5 at the minimum. If you agree with that, then that (sound) logic applies consistently to your present situation as well.
For server side application, possibly a version or two prior to the current version as suggested by EJP.
On the client side however, I don't see any point in trying to support older Java versions. The JRE has been auto-updating since at least Java 6. It has gotten to the point where Java Web Start launched applications cannot specify an earlier than current JRE. Or rather, it can specify any JRE it chooses in the launch file, but that will be ignored in favor of the latest version installed on the user's computer.
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.