On Wednesday, August 10, 2011 3:14:26 AM UTC-4, Casper Bang wrote: > > > 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!). >
Oracle's Java apps have traditionally been "pollutted" with native extensions and Oracle-internal, low-level frameworks. I remember that some years ago many Oracle Java apps used the EWT (a windowing toolkit that much like SWT, planned to replace AWT/Swing, but unlike SWT they never walked the last mile to promote it more broadly and make it mature). > Ah I doubt if MFC and Visual C++ redistributable dll's are relevant to > my Linux installation of SQLDeveloper. That does raise an interesting > I guess on Linux it has/uses equivalent native libs... but even without that, you have have lots of (your fault's) unportable hacks. > 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. > This functionality can be provided by shell scripts; native launchers still have some advantages (remarkably on Windows), but the native code from SQLDeveloper goes much beyond launcher wrappers (it has those, too). > 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. > I can hear tens of HotSpot developers thinking "yeah, like that would be very easy and not have tons of tradeoffs" ;-) this stuff is hard, for one thing HotSpot Client and Server used to have very different LIR/HIR, calling conventions and many other structural diffs; only now with the Tiered work they became compatible enough to run side by side... but it's still a combo JIT, not a single JIT that can operate in "-O1" or "-O2" mode... let's see > 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 > CompressedOops now mostly avoids this problem, at least for Java objects in the heap; but (I think) not for code, stack, native heap, VM-internal structures, OS resources. Maybe the major delta is that we'd need a very mature port of the 64-bit HotSpot Client VM, so this can still improve. > 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. Static and shareable IT-caching requires to drop many agressive dynamic optimizations, so this enters a different discussion. Both .NET and Android are less advanced in the dynamic features than JavaSE, and HotSpot - often even Client - beats .NET's pants down in most benchmarks (well, except ones that depend a lot on extra typesystem things, like lightweight structs for complex numbers and such). But I always thought that for Client, the tradeoff would make sense... at least if Java's frameworks are not too over-engineered to rely a lot on advanced optimizations (like Swing is). A+ Osvaldo -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/M0MEydoLV9UJ. 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.
