> There are tons of software > much bigger than SQLDeveloper that routinely transition to major JDK updates > without a hitch.
As far as exercising client API's (i.e. Swing), I don't think there are "tons of software" much bigger. IDE's seems to be the single most successful class of Java client applications out there. But I may be tainted, having seen my share of Oracle software break on newer Java releases (Oracle Discoverer bitching for years over Java 6 also comes to mind!). > The real problem, most likely, is that SQLDeveloper is not a pure-Java app, > they have a bunch of DLLs - not just launcher stuff but things like > idenative.dll and jdevnative.dll. In the Oracle forum, they suggested to > copy JDK 7's bundled msvcr100.dll to improve compatibility with JDK 7. I've > tried that, no improvement at all; but that recommendation is a huge smoking > gun. The problem is that they have some crappy native dependencies that > they inherit from JDeveloper frameworks. Ah I doubt if MFC and Visual C++ redistributable dll's are relevant to my Linux installation of SQLDeveloper. That does raise an interesting point however, that Java's search for the lowest common denominator for client applications, can be a tough goal to meet. For example, there's no System.restart() API so even NetBeans (which we must assume is written by people who truly know how to do things) ships with native wrappers. > I too believe that Client, and also 32-bit, is on the way out, but that's > because of bleeding-edge improvements like the tiered compiler (JDK 7's), > CompressedOops and CompressedStrings. Even with all this trickery, the > 64-bit Server (or tiered Client+Server) VM will still use significantly more > memory than ol' good 32-bit Client VM. People still judge things like Java > vs. Flash or Chrome vs. Firefox counting the megabytes that each uses more > than the other - we are still distant from the day when a platform that > burns 100Mb more than another competing platform to run a similar app, is > not disadvantaged. There's no reason (that I can tell) for why there should be two distinct VM's, just make one that's adaptive and less black-n-white. That a 32bit VM uses less memory I suppose is primarily a consequence of pointers being ½ the size of 64bit, yet Moore's law will remedy this in less than a year. I actually just don't think Java was ever really optimized for client computing (for one thing, why not just cache the verified, compiled and optimized native code first time it's executed?) unlike i.e. Android and .NET. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
