We are planning to upgrade our Tomcat from 4.1.31.
Our's is an Axis 1.4 application where we have our web services.
Request you to suggest the latest stable version of Tomcat 5 or Tomcat 6 suitable for our application. And the things to consider while upgrading.
Will the existing 1.4 Java code base works smoothly on Tomcat 5 or 6?
And going further we may write the code in JDK 1.5 as well. So, having Java 1.4 code and Java 1.5 code together, will create any problems?
Kindly suggest.
Please share your upgradation experiences.
Thank You :)
Tomcat 6.0.26 is the latest stable release.
It requires JRE 5.0 or later, so if you are truly stuck on 1.4, you'll need to download the latest 5.5 release, which requires a compatability package to run on 1.4.
My advice: bite the bullet and make the necessary changes for your application to function on 1.6. It is only going to get more and more painful to upgrade (and to continue to code in 1.4) as time goes on.
Go to Java (1.)6; it really makes doing web services like yours easier and it's really widely available now.
If you are going to upgrade I would recommend first doing some tests with java 6 + the existing codebases. If that seems to work, go to Tomcat 6.
Perhaps also upgrade some Axis libraries while you're at it, or leave it as is if it still works.
In my experience you can get to trouble by migrating to Java 5 (and thus 6), especially with XML. My memory has something like a class name clash between Java 5 and an old version of Xerces, but I could be mistaken.
Related
I have a doubt about java upgrading
I have applications running in java 6, for example.
And I wanto to upgrade my java to a 7 or 8
My doubt is: What is the best way to upgrade mi current java version?
Or how can I do it?
This applications currently are productive, so this means I has to upgrade the java version witouth affectate it.
I'm very confused about this, hope you can help me
There's only one way to do it:
Upgrade the JVM
Recompile the code and fix any errors that the JVM complains about.
Regression test the code running under the new JVM and make sure the functionality is unchanged.
Take the opportunity to see if there are any advantages to adding new features (e.g. java.time package, lambdas, java.util.function package, etc.)
No one should be running on any JVM other than 8 or 9. JDKs older than 8 have passed the end of their support lives. They are not getting any more security patches.
You are making the excuse that everyone tries when faced with currency issues: "The code is working fine. Why change it?"
Unfortunately there's a price to falling behind.
I'd advise you to upgrade as soon as possible. Stop the excuses.
JDK 9 is the current version. Current or current-1 is usually acceptable; current-3 is not.
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 need to upgrade the source code for an existing Java EE 1.4 application to Java EE 7. What I need to do primarily? Any particular steps in order which I need to follow?
You are looking into a time difference of 10 years between 1.4 and 7, which in the IT is huge.
Replacing the old J2EE parts by Java EE code basically means rewrite the whole application - so it very much depends on what exactly needs to migrated and how much you can control this scenario.
From an own project where I had to deal with J2EE code I can recommend - if rewriting is not an option - to make the old application run on a new application server and only migrate small parts of it, if possible into a newly deployed application. This worked well, we still have J2EE code in the application and even add/fix small parts in the old code, but it runs together with Java EE code. One thing you have to take care about is the entity manager, because it leads you into trouble if you persist the same data via both ways.
Other than the obvious syntactical changes, I'd suggest looking at what libs you're using and seeing if those are now supported under 7.
When moving application code across versions, most of the time the jump is backwards compatible (I'd say in your case it won't be given such a massive jump) but one of the biggest factors will be if you're using legacy third party code, you'll need to find new supported versions of those products.
This includes say, if you're using a legacy application server and upgrading that. After all this then you can start to consider any syntactical changes that your IDE should help you with :)
I'd recommend WebSphere Migration Toolkit (an Eclipse plugin). Although it's primary usage is to look for a changes, when migrating from other platforms to WebSphere, it will scan your code, jsp pages, xml files and detect any Java, Java EE related issues also. So you will have rough idea what will need to be changed e.g. in relation to JDK changes.
See some info about that toolkit:
WebSphere Migration Toolkit
WebSphere Migration Toolkit download
Other WebSphere migration tools
I just need clarifications related to JBoss Application Server. I've developed a project which is compiled in Java 6. And it is deployed in Jboss 5 version. Till now I didn't find any problem with the application. But I want to know will there be any possibility that Jboss will have any backward compatibility problem. Or does Jboss needed upgradation with respect to Java version. Any suggestion would be appreciable.
Thanks,
Marshal.
Even if JBoss 5 is compiled with Java 5 there shouldn't be compatibility problems at a language level.
As for the libraries there might be a problem but those that JBoss requires should have been taken care of. This leaves you with core libraries that JBoss might have replaced in its class loader hiearchy and thus might have an older version. In that case you could put those libraries into your application and effectively override the JBoss versions on a per-application basis. We did that with some XML libs (IIRC JAXB was one of them).
As an alternative - as suggested by #Geziefer - use a JBoss 5 version specifically compiled for Java 6.
Our desktop-only product at work has been using JDK 1.4.2 until now (also 1.4.2 JRE shipped with product). I am trying to convince the management to let us upgrade to a newer version in order to get the performance, API/features and developer comfort benefits.
Since 1.5 has reached EOL transition, I'm I thinking of the upgrade to 1.6.0_10 directly (update 10 chosen as it is a major one).
In terms of code, all compile errors are just variable names called enum which I have renamed and the product works fine.
The question is
Whether this upgrade is recommended/fine i.e. skipping 1.5 ? are there any catches
If yes then should I upgrade to 1.6u10 or the latest 1.6 available ?
Thanks
I would say if you are going to do the upgrade then go for whatever the latest update is. You may actually get some free performance gains going with 1.6, I know some JVM improvements have been made since 1.4.
In general, Java is fairly good in being backwards compatible.
In case there is a need to find out what has changed in the Java platform from 1.4 to 6, the following is a list of changes that Sun has listed for each release:
Java 5: New Features and Enhancements
Java 6: Features and Enhancements
There's always a possibility that any specific release may contain a bug affecting you, or that your code depends on some unspecified behaviour of standard API classes that has since changed, but in general, upgrading to the latest Java release is recommended and relatively painless. You should of course test the product extensively on the new JRE.
It's Java, it's not a dirty scripting language which changes its syntactic, its grammar, and its API every minor release.
Backward compatibility is one of the major features of Java.
Just did it (Swing app) from 1.3 to 1.6 :)
Works (according to UAT testing) perfectly OK (except some changes required for awt UI). PTE shows some memory consumption reduction (not much), and the server side works somewhat faster (I tend to think it's due to GC improvements and string intern()).
In any case, you have to do it because of EOL, and 1.6 is not much different from 1.5. So I'd say 1.6 definitely.
Whether this upgrade is recommended/fine i.e. skipping 1.5 ? Are there any catches
I think it's a good idea to skip 1.5 and go directly to 1.6 and there is absolutely no requirement that forces you to go through 1.5.
If yes then should I upgrade to 1.6u10 or the latest 1.6 available ?
I'd go for the latest. Actually, I think 1.6u16 is the current major release.
I would recommend upgrading to Java 6 over 1.5. As there would already be a need to test your app against the new JRE regardless of the version you choose, you may as well take advantage of this opportunity. Instead of incrementing your upgrade twice (once for 1.5 and later for 1.6) and requiring a test cycle twice, you can get it out of the way once. While you are at it, upgrading to the most recent version available would be perfectly fine.
We recently upgraded our Swing-application (lots of drag and drop) from 1.4 to 1.6 to get the concurrent facilities, and we have not seen a single issue which is due to Java itself. We also want to go to the Nimbus Look and Feel since the Windows look and feel doesn't look and feel like Windows.
The killer feature you should show your boss, is how to attach to the application using jvisualvm to introspect the running program in case of issues.
Swing apps can definitely have issues version to version. We have had issues every upgrade (1.3 to 1.4 and 1.4 to 1.5 and we stuck our toe into 1.6 - and more issues). However, there is no reason to spend time on 1.5. Go straight to 1.6, the latest release, you won't be saving any time by going to 1.5, you will just spend a bunch of time testing on 1.5 and then do it again at some point in the future for 1.6. Much more economical to jump to 1.6.
A lot of minor revisions fix issues, so sticking to 1.6_u10 is just inviting issues. u10 was a big upgrade (unlike its name implies) as far as Swing is concerned, and several of the releases after that addressed issues that came to light after u10 was released.