The IBM 1.4.1 JDK has been built with gcc 2.95.3. This means it will run on SLES7 and SLES8. However, if you are running on SLES8 the default compiler is gcc 3.2. In addition to being the default compiler, 3.2 also has many performance improvements etc. over 2.95.3. In addition, gcc 3.3 will exploit many of the new hardware features to provide additional performance boosts. This is good news if you are running Java apps. (for example under Websphere or our own Tamino XML database engine). However, if you happen to write apps. in C++ that use the JNI (Java Native Interface) to exploit Java-based functions then under SLES8 you're in trouble. The C++ ABI changed from 2.95.3 to 3.x (fortunately the ABI is now stable). This means that C++ programs generated with 3.x are unable interface correctly with those built with 2.95.3. Therefore, the JNI is unusable for 3.x-based C++ programs.
The rationale behind using 2.95.3 is that the JDK would run correctly under SLES7 and SLES8. I maintain that the C++-breakage demonstrates that it doesn't. I have raised this issue with IBM and the response I get back from them is that "Yep, it won't work until a future release of the JDK. So wait or build your app. with 2.95.3". When that new release (1.4.x/1.5?) comes is not specified - certainly not in the near future. The alternative of using 2.95.3 is also an impost that our development organization would find too much to deal with (we've standardized on 3.2). If we want to exploit the performance boosts of the latest hardware then we'd be SOL. I understand that providing, for example, a 1.4.1.5 (or 1.4.2) built using 3.2 is not simply a recompile. However, having ported the Blackdown Java to Linux on S/390 I'm also aware that the certification testing process is, for the most part, completely automated. We have a business-case of why a 1.4.x would be a good idea, but we are just one voice in the chorus. Are there anyothers in "list land" that find this situation (a) problematic, or (b) having the potential to directly impact their business? I always find that "lowest common denominator" decisions are fraught with peril. Neale
