Download 3d Interface Exodo 3g Desktopx Theme
Theodora Glime
My conclusion, at the time, was that Java was a dead-end for desktop development, unless I wanted to deploy as an applet - and by that time, Applets were even getting tired, when compared to lighter, faster technologies like Flash.
By Java 1.3, the user experience for applets was so fraught that Applets were only practical in an institutional setting where the system administrators had complete control over the software installed on the clients. It was no longer a practical way to add simple interactivity into web pages.
By 2001, applets had pretty much run their course. Flash had supplanted it as the standard for browser-based interactive media, as it was simpler, lighter, faster, and had a better install base (I recall something like 99% of computers had it installed).
It was around that time that Apple publicly announced that they would be embracing Java as a first-class citizen on Mac OS X. Java would come preinstalled with OS X, and Swing would be given a Native Mac theme so that they would look and feel just like a native app. This meant that you could ship a Java app to Mac users and be confident that it would run, and look good.
Some assignments required the use of particular libraries or programming languages. E.g. I recall an Operating Systems assignment on threads that required the use of the pthreads library, and, thus required us to use C.
I kept downloading and playing with Netbeans up until 3.5.1. As soon as I tried that version I started building an app with it and never stopped. It was definitely a killer app moment. Nearly twenty years later I'm refreshing the app for a new release. I kept trying to use eclipse over the years but never understood why it was even a thing compared to Netbeans.
This is the first in a series of articles about the history of Java on the Desktop, from my perspective as a developer who started working with Java in the late \u201890\u2019s. I\u2019m writing this, partly as a background for why I created jDeploy, a developer-friendly desktop deployment tool for Java. Despite the ominous tone of this article\u2019s title, I believe that Java is a compelling platform for modern desktop applications. Stick around for the whole series to find out why.
Java was the official language of choice for teaching computing science when I was in university in the late \u201890\u2019s through early \u201800\u2019s. There were a few courses that required us to use C and C++, but all of the fundamentals were taught in Java. For the pedantic reader, I should also clarify that they were taught in Java, as opposed to just taught Java. In University Computing Science programs, they don\u2019t actually teach particular programming languages. They teach concepts, and use programming languages to demonstrate those concepts. As a student, you\u2019re expected to learn the programming languages on your own time. Some courses had hard requirements, like \u201CThis assignment must be done in Java\u201D, but, for the most part, and especially in upper-level courses, you were free to do assignments in whatever language you felt comfortable with1.
When I entered University, my exposure to Java had been limited to Applets, and I didn\u2019t have enough experience to know Java\u2019s place in the world or what it improved over the technologies that came before it. However, I did have a sense that we were being ripped-off somehow - that it was just a toy language, and all \u201Creal\u201D development was done in languages like C++. There was always some guy in the back-row of the class with a trench coat and messy beard who let his feelings about the superiority of C++ be known.
\u201CJava is slow\u201D, they would say, and anyone who had ever used a Java GUI application, or a webpage with an applet, would have no choice but to agree. The only desktop applications I remember from that era that were written in Java were development tools (ArgoUML, and NetBeans come to mind), and they were buggy and slow. Oh so slow. It felt like you were working in molasses, as there was a lag on everything from scrolling to opening menus.
Professors who were enamoured with Java\u2019s potential would insist that, with its just-in-time compilation, Java was actually quite fast - and, \u201Ctheoretically\u201D would run just as fast (or faster) than C++ once a code path was compiled. But we weren\u2019t buying it. As far as I was concerned, the emperor had no clothes.
Another thing that made Java feel \u201Csecond class\u201D was the fact that the apps we built weren\u2019t native apps. After you had \u201Cbuilt\u201D your app you would end up with a bunch of .class files or, if you were \u201Cadvanced\u201D, a .jar file that could only be run if the computer had Java installed. I was jealous when my BCIT and college friends would show me their projects, and they would be proper, real-life executables that you could double-click, and they would run, just like a real professional application - complete with all of the expected menus at the top of the window or screen.
I remember asking one of my profs about the possibility of producing a native executable, and he responded with \u201Cwhy would you want to do that?\u201D. \u201CThat would negate all of the cross-platform benefits of Java. Once you compile it to a native executable, it isn\u2019t cross-platform anymore\u201D.
He suggested that I look into Java WebStart, if I wanted to deploy my app as a desktop application. That would allow users of Mac and Windows to install my app more easily than if it were a native bundle. WebStart sounded interesting, but it still felt like I\u2019d been offered a bowl of soup, when I was asking for steak. Even if WebStart would allow me to distribute my app, it still required the user to have Java installed. (Albeit, at this point in time, circa 2001, Java came preinstalled on most computers), and it would seem foreign to users who were used to being able to download just double-click it to open it.
Furthermore, after experimenting with a few WebStart apps, it was apparent that the result was mediocre at best. The apps were always slow to open as they would download the updates, and they didn\u2019t quite integrate properly into the operating system. There was a feature that would allow you to save an alias for the app on your desktop, but it never worked very well.
I\u2019m sure that there were third-party tools at the time that would allow you to package a Java app as a native executable, but I\u2019m just as certain that they were expensive, and \\\"windows-only\u201D. I was briefly excited about GCJ, the GNU compiler for Java that claimed to be able to compile Java down to machine code, but it only worked with a subset of APIs and didn\u2019t support Swing - so GUI was out unless you wanted to use a native GUI toolkit.
Applets were groundbreaking in 1995 as they allowed you to have interactive 2D graphics and animation for the first time right inside a webpage. In the beginning (Java 1.0), the Java interpreter shipped as part of the browser, but it wasn\u2019t long before the model changed to use the system\u2019s installed Java runtime via a plugin.
Originally, all you needed to do to embed your applet was upload your .jar file (or .class files) to your web server, and add an tag in your webpage. Unfortunately, this simplicity wouldn\u2019t survive. As new versions of Java were released, and Internet Explorer entered the scene, the HTML code required to embed your applet became increasingly complex, with different tags used for different browsers and versions or Java. The tag was advertised as the correct way to embed an applet in a \u201Cmulti-browser\u201D environment, but Internet Explorer used the tag and Mozilla used the tag.
And things got even harrier when you tried deal gracefully with systems that didn\u2019t have Java installed. The embed code that was generated by NetBeans, when you build an applet is quite complex, and includes javascript to try to detect if Java is installed, and provides a download link to download Java from Sun\u2019s website if it is not.
Applets, by this time, were also giving Java a bad name, as security exploits were regularly being published, that were publicized as \u201CJava security exploits\u201D. This gave the false impression that anything written in Java was a security threat, even though these \u201Cexploits\u201D generally only applied to Applets. They would linger around for many years to come, but mostly as a legacy technology.
By the time I started working with Java, its original GUI toolkit, AWT (Abstract Windowing Toolkit) was already considered old, and its new \u201Clightweight\u201D toolkit, named Swing was all the rage. To make a long story short, AWT was a \u201Cheavy-weight\u201D toolkit, meaning that it provided an API for working with native widgets. The problem with a heavy-weight UI library is that it is difficult to maintain, and is limited by the components that are available in the underlying platforms. Swing, by contrast, was a light-weight toolkit, meaning that it draws all of its own widgets, which is much easier to maintain, and makes cross-platform interfaces much easier to build.
Swing had a pluggable UI so that it could be styled to mimic the look of the native platform. When run on a Mac, a Swing UI would look the same as a native Cocoa app. When run on Windows, it would look like Windows, etc\u2026. It also allowed for custom look and feels that didn\u2019t conform to any particular platform. It was very flexible.
7fc3f7cf58