Slashdot Mirror
Will Sun Open Source Java?
capt turnpike writes "According to eWEEK.com, there's an internal debate going on at Sun whether to open-source Java. (Insert typical response: "It's about time!") Company spokespersons have no official comment, as might be expected, but perhaps we could hear confirmation or denial as early as May 16, at the JavaOne conference. One commentator said, "Sun should endorse PHP and go one step forward and make sure the 'P' languages run great on the JVM [Java virtual machine] by open-sourcing Java." Would this move Java up the desirability scale in your eyes? Could this be a way to help improve what's lacking in Java?"
I currently avoid Java like the plauge, my reasons are the same reasons that java isnt included in debian... http://www.debian.org/doc/manuals/debian-java-faq/ ch5.html#s-license-concerns
if they address those license concers i would be much happier...
"I reject your reality, and substitute my own" - Adam Savage
Microsoft's JVM was actually one of the fastest in the day and had extentions for a native GUI similar to eclipse. (Of course those extentions relied on illegal JVM tricks.) It was certainly much better than Netscape Java or early releases of Sun Java.
The main reason Java has a terrible reputation (IMO) is/was it's tendancy to hang/lockup/freeze your browser when an applet loads, and general clunkyness with Swing.
Business. Numbers. Money. People. Computer World.
Actually, FreeBSD were given a license at no cost by Sun, and any not-for-profit organisation with a need for access to a Sun-maintained compliance test kit can get it at no charge. So it's really just a matter of having the motivation to ask.
Kaffe and GNU/Classpath are excellent, active projects with dedicated developers. Notably, GNU/Classpath has recently passed the 99% code coverage mark measured against the Java SE specification. Apache Harmony was started because Apache won't use code licensed under the GPL, not because of any technical defect in the work of the Kaffe and GNU/Classpath developers. Harmony is also making excellent progress and has a skilled and active community. Both are committed to making compatible implementations of Java, but licensed under the licenses their communities need.
The SCSL is going away in Java 1.6 in favor of some much more liberal licenses. I'll be able to compile and use it on my production FreeBSD server at work and not worry about being "tainted" as a programmer.
3 437481
http://www.internetnews.com/dev-news/article.php/
Yared has long called for Sun to open Java, which, he said, is "great on the back end, but LAMP is great on the Web tier, as Google, Amazon, Yahoo, Flickr, MySpace and Friendster have shown.
Amazon is not LAMP.
People must be tired to mod you up. Performance isn't really an issue anymore and hasn't been for a couple of years. Blaming any perceived slowness on Swing is like saying C++ is slow because of Windows overhead. Most Java code doesn't make use of Swing (think server-side). As for the "122 ms", well, you just made that up.
Other problems with your post: Eclipse is an application; Swing is a language feature. A Smalltalk derivative (Squeak) is not a suitable replacement for Java. I'd go so far as to say Ruby and Python aren't either, though both are very powerful and are better suited to some tasks than Java.
Nice try at a troll...subtly nonsensical.
Pretty meaningless comment, unless you can supply some examples. I've done consulting and development for a number of large, lawyer heavy organizations, and none of them had a problem deploying Java solutions on linux. None.
"2. JVM is fat fat fat, it uses way more RAM than is reasonable."
Sadly uninformed, probably due to severe lack of experience with large applications. Per example, a couple of years ago I worked in a team that bid on and developed an application that, in a nutshell, receives up to 20Megs per sec of market data, breaks it up into itty-bitty messages, and then makes it available to any number of subscribing clients. Call it a proxy, if you will. We developed the app in pure Java, using the new NIO functionality. We competed with another team who started out in C, moved to C++ midway through, and were barely in a position to go alplha when we were ready to deploy. The client, since they were paying and had a lot of anti-Java staff, insisted on waiting, even though the delivery date had long since passed. When they finally had something to show, the apps were launched on identical hardware, and allowed to run 24/7. Our app ran smoothly, uninterrupted (except for a blown network interface) for the duration of the test. The other team had to restart their app several times a day, resulting in unnacceptable outages. Their restart time was, likewise, poor. Their app required 2Gigs to run. Ours ran happily under a Gig.
The client paid both teams for their efforts, then licensed our solution.
So, my quesion then is, where's the fat?
Can't speak on the licensing, I'd say that the technology itself however is the complication in deployment. Java has a tremendous number of rough edges and that is was is the problem.
Now, before I take a moment to rag on your ridiculous RAM comment, let me assure you that I hate Java from that ground up. I find it to be little more than a virus.
JVM is thin thin thin. The fact is that most non-Sun implementations of the JVM are tight and small. In fact, from a performance perspective, Java is typically superior to compiled languages because of how it handles RAM. Before you blow me off, let me justify my comment. Thanks to the Java license and NDA agreements, I in fact can not say where I learned this information, but I have extensive experience in this topic since I was forced for extended periods to suffer the Java VM on embedded devices.
Java is a relatively simplistic (though strangley complete to the point of OVER KILL!!!) architecture/language/etc... It provides a language matched to a virtual machine matched to a set of somewhat poorly written libraries.
What makes Java superior to compiled languages is that it compensates for several key factors. First I'll refine my definition of a compiled language to clearly specify C/C++/Pascal/other non-garbage collected languages.
1) Application Developers are not System Developers
Using C++ as an example, most application developers use the standard implementation of new and delete. This is fine, but the first thing to keep in mind is that memory allocation for a C++ application that makes use of a lot of small objects tend to pay a huge performance price. C developers regularly shoot down the performance of C++ without realizing that it's the limitation in the C allocation routines.
Object oriented programming is typically very heap intensive. In many cases, developers insist on iterating through strings and lists far too much. Students are even taught in the university that data structures should be used absolutely everywhere. Of course they are taught Big-O and Little-O, but unless you're actually implementing the data structure classes and types, very little importance is placed on performance of these classes.
Strings are abused regularly since even though the allocation unit size of the heap allocator is limited to blocks of 16 bytes (for example), programmers will actually reallocate the buffer for a string to resize it from 8 to 9 bytes in length. By reallocating, I mean they will in fact allocate a new 9 byte string, then copy the original to the new buffer and delete the original buffer.
Application developers pay very little attention to the actual internal mechanics of the classes and functions which they use. To a certain extent, I can forgive them since an application developer is expected to think differently than a system developer. When we depend on system developers to write applications, they're often extremely fast, but relatively unusable.
So here's where Java shines, because of the garbage collection system and because of the relocatable memory architecture, memory is managed in such a way which decreases the cycles spent in allocation and deallocation of buffers. A well written JVM actually will actually either when necessary or when time is available compress the heap to maximize performance and minimize heap consumption.
So although Java seems like a memory hog, it's actually not that bad given the number of allocations and deallocations being performed by the developers. Sadly, the extreme memory use you're talking about is related to the poor system level development skills of application developers stacked on the additional layer which abstracts even more from the developer therefore making it less practical for the developer to understand the internals of the system.
2) System Developers make Terrible Applications
A system developer is typically biased towards raw high level languages such as C (not C++) because their used to making use of the stack whereever po
In order to be allowed to use the trademarked term "Open Source" however, whatever license they choose must (a) comply with the Open Source Definition, and (b) be approved by the Open Source Initiative.
Did you even read the pages you were linking to? The Open Source Initiative's own certification page, that you linked to, has this to say, right in the first paragraph: "the term 'open source' itself [...] can't be protected as a trademark".
I can call anything I like Open Source, and nobody can do a thing to stop me. The new Evil Proprietary License (a viral license that infects any software in the same room with a deadly curse that can only be lifted by the sacrifice of your firstborn) could be called Open Source. What it couldn't legally be called is OSI Certified(tm).