I will defer to your judgment that having any kind of Sun JRE is better than an IBM JRE, from a "selling" point of view.
>From a technical perspective, we agree that eventually you will need a high-performance JRE. I see a couple of paths: - Port/write a JIT for the Sun JRE for z architecture. A good JIT, especially for z, is really a very sophisticated real-time optimizing compiler; a rather large effort. BTW: will you be using OpenJDK? If so, are you sure that the customer applications will work? Most of the portability issues have to do with using non-API classes, which might not be in OpenJDK either. But if this were done, it would be easy to port it to Linux, which would be great. If you could pull this off so that the performance were comparable to the IBM JVM, there is a team of IBM JIT developers that would certainly get excited. This kind of competition would be great. - (Assuming that IBM ported their JVM from Linux z to Solaris z) Why not explore the possibility of running the Sun OpenJDK Java libraries with the IBM JVM? I'm not sure how difficult this would be, but it seems possible in theory. Alternatively, IBM somehow could add non-public Sun classes to their JDK so that compatibility issues are relieved. Again, customers whose applications only support the Sun JRE are saying that they don't conform to the public API. They will probably get whacked when they try to migrate to a new version of Java. These are likely the same goof-balls that complain how non-portable Java is, and how slow it is since it is "interpreted". Do these people really think that porting their Solaris workloads from Sparc or Intel to z will be easy, so long as they don't have to support a different JRE? Kirk Wolf Dovetailed Technologies On Thu, Apr 16, 2009 at 7:25 PM, David Boyes <[email protected]> wrote: > On 4/16/09 5:38 PM, "Kirk Wolf" <[email protected]> wrote: > >> That's fine; but without a JIT, migrating common Java workloads to >> Solaris z is a non-starter. For the z-architecture, it needs to be a >> rather sophisticated JIT. > > Give us a little time, OK? Neale's only had a week or so to get this far. > 8-) > > It's a known requirement. Baby steps...it's easier to sell eating the > performance hit for now than arguing about converting some application to a > different JDK. The next two steps are a LOT harder, and Kate is rationing > pixie dust this month..8-) > >> I agree with your points on JDK compatibility being a common issue, on >> all platforms. Most all of the problems end up being that the >> application code incorrectly uses Sun internal classes. Sun should >> have "fixed" this long ago by somehow preventing using of classes that >> aren't part of the Java API. > > Not my battle. I'm just tired of hearing "IBM Java isn't what our > applications people need". > > -- db > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
