Jikes, JikesRVM (formerly Jalepeno JVM), and SWT were all solid Java projects from IBM. I'm really sad that Sun didn't sell off Java to IBM before selling the rest of itself to Oracle ("the lawnmower", according to Bryan Cantrill).
I understand that a big part of Sun's value was in Java, but the many-core high-I/O-bandwidth server business was still valuable to Oracle and synergized pretty well with Oracle's business (outside of the legal department). The value to the world as a whole was much higher with IBM (or, at a second choice, Google) owning Java and Oracle (or some other high-I/O bandwidth enterprise product vendor) owning the Sun hardware business.
The Jikes compiler's startup time was so much faster than Sun's javac, and Java compilers perform very few optimizations when compiling source to bytecode. (My understanding is that the spec restricts which optimizations are allowed.)
JikesRVM (a JVM written in Java) had surprisingly good performance for a small research project. It's bootstrap process involved AoT-compiling itself, so it would have been not too big a leap to have a general non-GCJ AoT for Java years earlier, and (because it uses its normal second-tier JIT for AoT compilation) presumably not too difficult to get the hot paths all re-inlined and re-optimized even through the AoT-compiled code.
I think a very small minority of developers or users preferred the look of Swing (or worse, AWT) widgets to SWT. Sure, SWT widgets looked different across platforms, but the alien look of Swing/AWT widgets was very off-putting to users (and to a lesser extent, I tihnk, developers).
AWT used native widgets. It looked less alien than Swing.
Swing also had a theme engine (PLAF I believe it was called) that wasn't terrible. It could look like Motif or Windows or Apple had one that looked like Aqua, set as their default back when they bundled JVM. https://en.wikipedia.org/wiki/Pluggable_look_and_feel
Originally, that platform L&F was pretty bad - for example, fonts were rendered using some bundled engine (FreeType?), instead of the OS text APIs. On Windows, at least, this meant no ClearType, which made all Java apps on XP+ with default settings stick out like a sore thumb.
Bongo was by far the most advanced user interface toolkit and editor for Java of its time. It had a HyperCard-like GUI editor AND an interactive script editor that let you build and edit applications and user interfaces while they were running, just like HyperCard, instead of recompiling and restarting every time you made a change.
>In 1996, four programmers from the original Java-development team left Sun to form Marimba and produce industrial-strength Java-development tools for user interface and application administration. Bongo, one of Marimba's two shipping products, allows developers to create either a Java-application interface or a standalone Java-based application called a "presentation." A Bongo presentation resembles a HyperCard stack -- it allows developers to quickly create an application with a sophisticated user interface, but without the tedious programming of directly coding in Java or C/C++. Bongo's nonprogramming, visual approach makes it ideal for producing simple applications that don't involve a lot of processing, such as product demonstrations, user-interface prototypes, and training applications. Bongo is fully integrated with Castanet, Marimba's other product, a technology for remotely installing and updating Java applications.
I understand that a big part of Sun's value was in Java, but the many-core high-I/O-bandwidth server business was still valuable to Oracle and synergized pretty well with Oracle's business (outside of the legal department). The value to the world as a whole was much higher with IBM (or, at a second choice, Google) owning Java and Oracle (or some other high-I/O bandwidth enterprise product vendor) owning the Sun hardware business.
The Jikes compiler's startup time was so much faster than Sun's javac, and Java compilers perform very few optimizations when compiling source to bytecode. (My understanding is that the spec restricts which optimizations are allowed.)
JikesRVM (a JVM written in Java) had surprisingly good performance for a small research project. It's bootstrap process involved AoT-compiling itself, so it would have been not too big a leap to have a general non-GCJ AoT for Java years earlier, and (because it uses its normal second-tier JIT for AoT compilation) presumably not too difficult to get the hot paths all re-inlined and re-optimized even through the AoT-compiled code.
I think a very small minority of developers or users preferred the look of Swing (or worse, AWT) widgets to SWT. Sure, SWT widgets looked different across platforms, but the alien look of Swing/AWT widgets was very off-putting to users (and to a lesser extent, I tihnk, developers).