My (Amateurish And Armchair Developer) Opinion Of Java - Java Applications, along with IDE and UI Issues
It shouldn't take a rocket scientist to explain why Java failed in the desktop space. When Java started to gain traction in the late 90's, lower-end Pentium 1 PCs were still very common among the masses. These users typically had sub-100Mhz PC's. Has anyone ever tried to run a Java application on a sub-100MHz PC! One can immediately tell the difference between a Java applet and a natively compiled program. If it was a full-featured Java program, and not just a simple applet; then all bets were off.
Corel Office For Java And WeirdX
I've recently installed OS/2 Warp 4 onto 86Box. OS/2 Warp 4 included a version of Java at installation. One of the selling points of Java, especially on OS/2; was that Java could run hundreds, if not thousands, of programs on OS/2. Since OS/2 already had a small software library to begin with, (especially in comparison to the heavyweight that is Windows) this was seen as a massive plus. In order to promote its inclusion of Java, IBM promoted the Java port of the Corel Office Suite. Well, I installed Corel Office (coj.zip on the Hobbes OS/2 Archive if anybody is interested) onto my OS/2 Warp 4 install on 86Box, which is configured as a multimedia PC with 48MB's of RAM and a Pentium 1 processor running at 75MHz. While this would seem a bit dated, even back in the day, but this setup would have still been typical for a lot of PCs at the time.
Good God, the pain of it all. Corel Office took like 15-20 seconds to launch. After it loaded, it didn't function correctly as the icons and menus did nothing. What little that did load felt stiff. WeirdX was just as bad. WeirdX is a X-Server written entirely in Java. This alone makes it an awesome program in theory. I love X-Servers and their ability to run X11 programs running on Linux or UNIX! In practice though, WeirdX is unusable on that setup. It took forever to open the program, and a long while before the terminal window that was exported from Mobaxterm on my Win10 host loaded into WeirdX.
Now on VirtualBox, both programs ran much better. WeirdX was actually quite usable. At least for the few X11 applications that worked with it, which was just RXVT, xCalc, and xClock. xNeko, and xDaliClock didn't display nothing at all, while xLogo had drawing issues. Corel Office on VirtualBox had icon black-out issues. However, it was loaded onto a VMware Player setup that was running OS/2 Warp 4.52. While it was much faster and useable, it felt odd and clunky in its execution. Corel Office was supposed to show the strengths of Java when running full-featured applications on various platforms. If anything, though, Corel Office quickly demonstrates Java's two biggest weaknesses of why it was not geared towards desktop applications.
There were two massive 800-pound elephants in the room. Performance was one of them. Encountered with this issue, many asked if it was possible to convert the JAR file to an EXE afterwards for performance gains. Those at the pulpit of Java would look down upon you as if you spoke hearsay. The whole point of Java was that you were now free from the EXE. However, this declaration still failed to address one of the core complaints, performance. This issue was later rectified with faster computers. However, one could argue that is hardly a groundbreaking solution to a problem that could be solved with optimization.
It didn't help that many who spoke the praises of Java being an awesome language for beginners were completely out of touch with reality. Yes, we can crap on Visual BASIC all we want, but that is an awesome language for beginners, not Java. When you want to introduce someone to programming who never EVER typed a line of code before, show them VB, not Java. Even better is oldskool QuickBASIC. One can learns C++ style "methods" of programing without being confused by the syntaxes of C++. One can build their own objects and classes in QB and VB, and then call those objects and classes when needed. Now granted, Java is a much more forgiving language than C++. However, one could liken Java to "C++ lite". Java was heavily influenced by it. Java was often described as a language that conformed to a "secured" model. What this implies is that you cannot execute code outside of the JRE, and the language also promoted much cleaner and efficient coding as one could write JRE classes that prevented memory leaks.
As mentioned earlier, for those who want to learn C++, Java is actually a language worth investing in as it allows for C++ concepts to be taught, and thus, put into practice once that user graduates from Java to C++ , or vice-versa. People who come from a C++ background could make very powerful use of Java. Java is recommended if you want to pursue a path down the C++ route.
However, as an introduction language, I still am not compromising my opinion here. Java is not a good language for those who never programmed before. I would argue that it would have been better to teach VB first, HTML/ASP.net, then C++ (Visual C++ or direct coding in Notepad++ with code being compiled in GCC), and then introduce Java. But this crap about Java being an awesome programming language for beginners comes from those who tout it because they're too cheap to buy a license for Visual Studio.
The fact is that while we can crap on Visual Studio all we want, Microsoft understands the needs of developers much better than Sun did. Microsoft had written awesome developer tools, along with a massive library of documentation covering the coding and API perspectives of their programming language. In all fairness, Sun had tried to provide their own (somewhat respectable) answer to Visual Studio in the form of the NetBeans/Forte IDE. I have used the older version of Forte a few times in the distant past. On one hand, I really like the IDE. It reminds me a lot of VB in a positive way. However, I could tell that the IDE felt clunky and sluggish. Not a surprise as the IDE components utilizes Java as well. Using NetBeans also exposed the other massive 800-pound elephant in the room: the UI
The UI
By default, Java applications don't have a predefined look. The GUI look of Java programs are defined by the Swing toolkit. In the case of Corel Office for Java or WeirdX, they conformed to the default look of the operating system. The fact is that as being platform agnostic, Java programs would always look out of place on the desktop because each of the major desktop environments have their own UI guidelines. Both Windows Explorer and the Macintosh Finder are going to have their own guidelines and rules about how applications on their respective platforms will look.
Despite that, Java programs can actually conform quite nicely to the OS that they are running on depending on the program. However, while the program "largely" conforms, the UI controls are still different enough to where they look out of place on whatever desktop they are running on, regardless of whether it's Windows, GTK/QT, MacOS, the OS/2 Workplace Shell, etc. Sun attempted to remedy this problem by providing GUI toolkits to where a skin is applied depending on the OS that the Java program detects. However, the skin was still just themeable bitmaps that look like the "OS", but not actually being a part of it.
Such, while the themes made Java applications look "more" native", one could still tell it was a Java program just by looking at it. It looked "mostly" like a native program without it actually being one. The word "imitation" would come to mind. Combine this with the performance issues, Java wasn't going to win any contest in the desktop realm.
On faster computers equipped with the Pentium II PC's, performance wasn't that bad. I remember running NetBeans on a PC with a Pentium II processor running at 266MHz and the performance in NetBeans was quite acceptable. You could still tell that the response time was slower compared to natively compiled programs, but not that bad.
Comments
Post a Comment