Java 1.5 is still not a stable release, but it definitely improves the performance, reduces the memory footprint, and its networking support is much better. In addition, its computing speed is much faster, its multithreading support is smoother, and internally it uses much less locking operations on objects (notably in the processing of Strings). Finally, its garbage collector is faster, and better tuned, meaning that it uses internal memory in a more efficient way, and includes a memory defragmenter, meaning less swap on disk and better data locality. For performance critical operations, its support of asynchronous I/O, and audio is better tuned; it also includes the support for precompiled and shared classes, which means faster load-and-run, and a responsive application.
I don't think that there are more bugs in Java 1.5 than with Java 1.4.2. In fact, since Java 1.5 has been put into production, many bugs that are found in either platforms are updated in parallel in Java 1.4 and 1.5, because they share lots of common components. So the difference in the two platforms are less important: LimeWire uses the Java 1.4 platform which runs identically in Java 1.5. The difference in Java 1.5 is mainly in the core components that integrate the GUI: Swing and AWT components are based on Java2D, and they are identically on both platforms. But Java2D uses the native graphic APIs for the OS platform, and this includes DirectX (preferably to OpenGL on Windows), Qt and OpenGL on Linux, or MacDraw on MacOS...
Most freezes that users have experimented in the GUI have been solved in Java 1.4.2 face to Java 1.4.1, and retrofitted into Java 1.5 as well, becuase the support for native APIs is shared a lot between Java versions.
Networking components are mostly equivalent between Java versions, and they are mostly portable because they are written in 100% Java code (but note that Java 1.5 includes new StringBuilder objects instead of StringBuffers, which improves the performance in most cases because StringBuilder is not synchronized across threads; the numerous changes in Java 1.5 core classes is in the suppression of most unnecessary synchronization, and the extensive use of shared/reusable buffers to reduce the number of unique allocations and memory copies for temporary objects.
The main difference between Java 1.4 and 1.5 is the support for new language features like Generics (related but not equivalent to C++ templates), which LimeWire does not use, but that the source core classes bundled with Java can use. The binary format of class files is not equivalent, but LimeWire is compiled using Java 1.4 binary formats, without those extensions. There are also improvements in Java 1.5 regarding internationalization, with a more complete support of Unicode 4; this does not affect LimeWire which does not need or use now this.
Other improvements in Java 1.5 is that the customization of fonts is easier, supporting international fonts in a less platform-specific way. So Java 1.5 offers now a transparent support for all languages other than the default platform language. But LimeWire is built to run best in the default platform language, by letting users select these locales, and not necessary the English one.
Personnally, I have never experimented any Java VM crash or freeze since 1.5 is released, but I had a few ones with Java 1.4. Some reasons were caused by Java2D's use of DirectX, whose support in Java 1.5 is much improved, and includes more workaround for compatibility problems (notably with defective display drivers).
However I won't recommand the configuration of Java2D with OpenGL, because too many display drivers have not been so much extensively tested through OpenGL, and some of their interfaces are not multithread safe as they should, or do not work well with parallel applications. Other problems are in native font renderers, which have some known problems, solved in Java 1.5, but with partial workarounds on Java 1.4.
Things like OpenGL screensavers should be disabled in Linux, if you use LimeWire on this platform, and LimeWire will run better if your Java installation includes the support for Qt instead of OpenGL.
In most cases, crash/freeze bugs come from defects in display drivers, that don't implement the OS APIs as documented by the OS vendor, and that incorrectly assume that some events will come in some typical order, generated from the platform's graphical components. As Java bypasses most of these platform components, these events may come into a different order, still valid and possible as documented in the OS APIs, but causing, incorrect displays, hardware crashes, memory corruption, incorrect synchronization in multithreaded applications (like the platform's file explorer, or Java or LimeWire).
When you experiment such problems, get sure that you have the most up-to-date drivers for your display drivers, and that you don't use the "enhanced" but not certified versions of these drivers. Users that have tweaked their installation with such drivers are exposed to risks that such installation has not been eveluated and tested to support correctly all the OS features; Sun or Apple cannot test their Java installation across all hardware driver variants, but they do test them with the most common ones. This is a problem for those that use obsoleted display boards that were built by manufacturers that have stopped supporting them (notably all those many that had a 3Dfx board, which don't have any available upgrade that correct defects to support newer versions of their OSes). Those users are left with unsupported drivers for their new platform.
So a good question for those users is whever they should upgrade their OS, or if they should better buy a new PC or Mac with components made and supported on that platform: adding memory or changing disk will not solve those hardware-related problems, even if it theorically allows installing the new OS. The reality is that what they do is completely untested by all software providers, including Apple and Sun in their distribution of Java.
It is even more difficult to predict, for LimeWire, which networking platform will be used: this is a domain with lots of variants that are hard to reproduce, because there are specificities varying depending on technology (routers, broadband access types, proxies, addessing and naming, network autoconfiguration and discovery...) and that LimeWire does not have tested itself. Additionally, many bugs are produced by third-party networking components (including security tools like firewalls and antivirus), where there's often no definitive standard for interoperability...
The case of NAT routing is certainly one where LimeWire or any P2P application have difficulties to work with, because most Internet components were not designed for P2P. Things are changing, slowly, because P2P technologies are experimenting the same problems needed for other important technologies: grid computing, n-tiered applications, clusters and redundant hardwares, IPv6, mobile/roaming networks... With the new (basic) support for UPnP in LimeWire, we can adapt to those situations, but this will come progressively, because of the lack of a significant deployed platform to reproduce and experiment the problems and implement possible solutions.
So my response will be that Java 1.5 is recommanded now for most users, but if this fails for some of you, get back to Java 1.4 and check your hardware and OS components. LimeWire cannot be made to guarantee that it will work on all platform configurations and for all users, but LimeWire can be made to work with new standards. Java 1.5 is one of these new standards that is working so well for many. |