After seeing this shirt I almost started believing it. Then I noticed the following tag line:
Please do not attempt to wear the screen–this t-shirt is just an image!
Does this “magazine for PHP professionals” think so poorly of their readers that they have to tell them they’re looking at a computer screen? Maybe PHP types need that kind of reminder…
I spend a fair bit of time helping out beginning Java programmers. My favorite is when they ask why their swing code doesn’t work. When they post their stacktrace, there’s all the GCJ/GIJ classes. I explain to them how GCJ isn’t java and doesn’t (fully) support swing and that they should just download Sun’s VM and work with that. The problem with this scenario is multifaceted. For many, they use Debian (or some derivative) and the Debian ideologues choose ideology over functionality and ship a partial, non-certified implementation of a VM call it “java.” Beginners, unaware of the distinction, run into problems and blame Java rather than misguided package managers. Others get it closer to right, like gentoo, and make it relatively easy to install Sun’s VM. However, it’s not entirely the package managers’ fault.
Sun’s insistence on the pointless click-through license to download the VM make it impossible for most linux distros to sanely package a working java implementation. (The same also holds true for maven/ivy repositories but that’s another matter.) Since no one can redistribute the VM and many/most of the Sun provided libraries, automated package management becomes impossible and people, like RedHat/Fedora, end up shipping GCJ and calling it Java even though it is demonstrably not Java.
Now, I know some of you will point at Fedora Core shipping Eclipse all pre-compiled with GCJ but I’d like to point out that most of the hard stuff (the UI) is already native code. I have nothing against GCJ, per se, but calling it Java and making it the default Java package is misleading and, I think, just plain wrong.
Sun’s insistence on this licensing is leading to efforts like what our friends over at the Apache Software Foundation are working on: complete, reimplementation of all (major) java specifications with “sane” licensing terms that are freely redistributable. So rather than working with the community to speed the progress of these APIs, they’ve “forced” the community to reimplement things under terms we’re comfortable with. With yesterday’s announcement that McNeally stepped down as Sun’s CEO and Schwartz taking the helm, I’m hopeful we’ll see some progress on this front.
I know the issue has been beaten to death, but maybe now we’ll see a truly open source(tm) VM. I think the model of OpenOffice, Apache’s httpd, and Linux make a great model. Sun can keep the trademark and even “editorial” control over the main source tree. But greater freedom in using the VM can only lead to greater involvment from the community. Examples, like python, PHP, perl, and ruby show that languages can have open communities contributing without fragmentation. There are far too many bugs that have languished for far too long in the bug parade. Opening up the source to more traditional open source models can only help in the long run. I know many people who are turned away by the relatively draconian licensing terms the source is currently under.
Anyway, to return to my original point, Sun’s licensing is creating some awkward situations around the use and deployment of Java applications that serve no real practical purpose that I can see. I think it’s time to open it up a bit.
I don’t really think of sys-con.com’s linux site when I’m looking for Java news but this entry caught my eye. In it, he complains about the tendency of java libraries to make heavy use of patterns like the Factory pattern to provide as much flexibility as possible. He’s not the first one I’ve heard complain about this tendency.
So what’s the reason for this alleged over-engineering. The author goes on to praise his eventual perl solution for the speed with which he was able to solve his problem. Certainly one consideration for library selection is speed of development and ease of use. So why, as java developers, do we build in so much (often) unnecessary complexity? My personal theory is that from the start as (professional) java developers, we’re taught to think in terms of the enterprise. That means considering the myriad different platforms the application will run on: databases, operating systems, etc. And that’s certainly a valid concern but things like JDBC operate without all the Factory this and getInstance that.
So why are we so enamored with all this complexity? Is it really worth it? I’ve gotten used to much of it
