Skip to Content
Author's profile photo Klaus Herrmanns

Why migrate from J2EE 6.20 to 6.40?

I’ve had this conversation very often over the last year or so: colleagues have developed applications that are already deployed successfully with many customers, everything is up and running nicely and now they are asked to decide whether (and when) to migrate it to J2EE 6.40.

Of course, SAP could just order its own employees to migrate SAP apps to the latest and greatest no matter what. But for developers outside of SAP that’s no answer – and even for SAP applications, it is clearly better to understand how 6.40 can help than just to migrate because 6.20 is being replaced with a newer release in SAP’s marketing slides.

This blog doesn’t focus so much on new features in the J2EE engine. If you have been waiting for these, for example for J2EE 1.3 support, it’s obvious that you want to go to 6.40 as soon as possible. But what if all the functionality you need has already been implemented nicely on 6.20? Here are some key considerations that might help you plan.

Yes, there is a difference between applications that are meant to be used by many customers as a standard product, and customer specific developments that will only run in one particular environment. But in my opinion, the key benefits of J2EE 6.40 for both types of existing applications are the following.

1. Improved stability and scalability

Behind the scenes of the J2EE APIs large parts of the engine architecture and implementation have been reworked to improve the scalability and stability of the engine. And first tests (for example, of the EP 6.0 in a lab stress test, or of a real life customer application in realistic stress tests before the go live) clearly indicate that J2EE 6.40 scales better and is more robust than 6.20 with many users and under high load.

The migration effort to profit from this is very limited. Yes, the 6.40 engine implements J2EE 1.3 instead of 1.2, but the J2EE APIs have mostly been extended, so everything that worked on 6.20 should continue to work on 6.40 (provided you have worked with the official J2EE APIs only).

The 6.40 engine also runs on JDK 1.4 instead of 1.3, so if your code happens to depend on some things that were changed incompatibly between these JDK releases (see Sun’s documentation) you may have to make corrections. From what I’ve seen so far the only area that needs major efforts here are Swing UIs, the other incompatibilities are rather minor, rarely used details.

Of course, all this is only an issue if your application’s user load profile does at least sometimes make the 6.20 engine hit its limits, so it will only be worth the effort in special cases.

2. Platform independence, especially via Open SQL

One of the reasons why J2EE apps become platform dependent despite Java’s “Write once, run everywhere” promises is that you start storing persistent data in some database and use database specific SQL code, JDBC drivers etc.

With the Open SQL infrastructure of the 6.40 engine you can change that – just like in ABAP, Open SQL gives you a platform independent set of SQL statements, and a database interface that hides all DB-specific details from the application.

You even get an SQL trace thrown in (try calling the URL http://[host]:[J2EE port]/SQLTrace and login with the engine’s Administrator user).

To profit from this, you do have to change your application by replacing the DB specific JDBC and SQL code with Open SQL. Again, this is only an issue if you do want to make your application platform independent – if you are happy to program and run on one particular DB only, Open SQL is not a top priority.

3. Supportability

The 6.40 engine comes with additional features that make it easier for the engine administrator (and SAP support) to monitor and troubleshoot the engine. Some of these features (heartbeat and other monitoring data that can be fed into CCMS) only need to be configured, others (for example, centralized logging and tracing using a new SAP logging&tracing API, distributed statistical records for analysis of performance problems) require that applications are instrumented to use the new APIs.

This is definitely worth a look for all applications bar the smallest ones. In fact, some of these supportability features have even been downported to 6.20, so you may want to look at implementing these features in any case.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Customer who already have implemented 6.20 don't really care if it can support multiple platforms. Truly speaking it only SAP who care and it help SAP lower its bills. If 6.20 is already working fine for customers then stability & scalibility want be a real issue. And if it is not working then SAP has some unsatified customers.
      Author's profile photo Klaus Herrmanns
      Klaus Herrmanns
      Blog Post Author
      I would be curious to hear from more SDN readers about this issue. Obviously, the point Piyush makes is valid for many customers. But I would expect that both scalability and platform independence can play a role in some customer projects.

      In particular, those projects that started out small (say, with a quick and dirty JDBC app using whatever database the developer happened to know and have handy) and then grew into a bigger applications with more widespread use than originally anticipated. And when you do find an application outgrowing its quick-and-dirty origins, I believe it is better to port it to Open SQL once, than to port it from one JDBC platform the the next, and then have to deal with it again as the DB platform is upgraded or changed again later.

      Author's profile photo Benny Schaich-Lebek
      Benny Schaich-Lebek
      Hi Piyush,
      for customers as end user you are true. But there are also partners and software houses who work under same conditions as we do: they have to deliver on their customers platforms.
      On the other issues let me give you a very clear statement: I personally promise you a product that is as scalable as the well known ABAP server and as stable as a Java Virtual Machine can get. And the year after we will go even beyound that.
      I bet my personal reputation on this.
      Author's profile photo Darren Hague
      Darren Hague
      640 sounds great, and the J2EE 1.3 support in particular looks good for the authorisation support. So, the big question for me is: when should I migrate? The answer is: when 640 is a supported platform.

      So, when does 640 become a supported platform? Any talk of migration is pointless until this is known - no enterprise will run on unsupported software.

      Author's profile photo Benny Schaich-Lebek
      Benny Schaich-Lebek
      Well Darren, the world is split between those who always want the latest software tomorrow and those who prefer to wait for stable, non-annoying enterprise usable stuff.
      Growing our bananas in customers garden is not quite popular these days and guess what SAP's point of view was about this for a long time.
      Why then do we talk about this here?
      Large projects which will start in 2004 have to be planned today. We want to make sure they consider our new kid on the block for this point in time.
      Author's profile photo Jens Jakob Andersen
      Jens Jakob Andersen

      It will be very interested to find more info about performance of the WAS 6.4, especially in a cluster setup - we are using BEA Weblogic today, version 6.1 and 7.1.

      And performance, runtime as well as management is a very important issue for us.


      Jens Jakob

      Author's profile photo Benny Schaich-Lebek
      Benny Schaich-Lebek
      Performance always is an issue and one that really depends on your use. The improvements we have seen over the last year are promising. Implementing the classic SAP architecture was a good idea and porting SAP's persistence level to Java, which enables table buffering in a cluster, should really blast existing apps to high speed...
      Author's profile photo Former Member
      Former Member
      We have lot discussions with SAP clients about this issue and it’s really not easy to explain why to migrate. I think new development can be one focus. Consolidation from separate Java environment (Apps server) is another focus. But then you have to consolidate organizational issue. Java people and SAP people have to work together. This is a management task and not a technical.
      Author's profile photo Former Member
      Former Member
      Yes. We planned to move to 6.40 because of our requirements but haven't
      informed of the release yet. It is available now?