Slashdot Mirror
Sun to Release Java Source Code
pete314 writes "After resisting for years, Sun Microsystems CEO Jonathan Schwartz at JavaOne this morning said that he will release the source code for Java. The company is asking developers to provide feedback on how to best get there and prevent forking and fragmentation."
"After resisting for years, Sun Microsystems CEO Jonathan Schwartz at JavaOne this morning said that he will release the source code for Java.
:-/
BZZT! WRONG! Java source code has been available for YEARS! (And no, I'm not going to bother linking. If you don't already know where to find the SCSL and JRL licensed code by now, you need to pull your head out of your butt and Google it.)
This article is nothing but a blurb that suggests that Sun is looking at Open Sourcing Java. (What the Slashdot pundits have been screaming for, for years now.) Unfortunately, one of OSI's core requirements is forking. So Java will never be able to make the pundits happy.
Javascript + Nintendo DSi = DSiCade
No, thats the LGPL. GPL is everything that extends it or links to it. LGPL is only for the code itself and not linking code. Thats why glibc is LGPL instead of GPL.
I still have more fans than freaks. WTF is wrong with you people?
Even in this here Slashdot page, I see the java tag used all over the source code for this page.
/. who don't know this.
For the bazillionth time, Javascript is not Java. I can't believe there are people on
There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
I think that the reason Java doesn't want forking is to make sure that a program one person writes will always work on all Java interpreters. Sounds familiar to Knuth's concepts about TeX. The way they achieved it was by prohibiting new derivatives from being released under the same name (see http://en.wikipedia.org/wiki/TeX#License) and those using TeX in their name must pass a rigorous test suite. The license is not GPL compatible, but perhaps Java could adopt something similar?
Actually, that could be a good enough reason for them to release it GPL, and have a dual license option for some other Sun licenses.
However, I think they are more worried about Eclipse than MS at this point, and I doubt Eclipse would shy away from forking a GPL Java. Sun doesn't want the source of forks to be available for them to use - they want no forks to begin with. They are control freaks when it comes to their projects.
Really it'll come down to IBM and Sun working out some arrangement where the code for Java is available under an OSI license, but where Sun still has some sort of the control it desires. Given that Java is developoment is partly a community process anyhow, you'd think there would be some way they could attain that.
You are delusional. Like or dislike the language, but it's had the fastest, strongest uptake of any language in the history of programming languages. It went from zero in 1994 to being almost neck-and-neck with C++ by 1998. In other words, it did in four years what C++ took nine to do, more if you amortize some of C's growth into C++'s history.
Popularity isn't everything, but don't try to say Java isn't popular. Do some searches on some job sites and see how many Java programmer jobs there are.
you get the slow startup times associated with JIT, and slow execution due to fiddling with bytecode. Let's not forget that the only type of optimisation carried out on the bytecode is peephole optimisation
Now you're just trolling. Slow startup time: sure. With the jdk 1.3, you had around an additional 700 ms. startup time penalty that you didn't have with C code; since then, it's gone down. These hundreds of milliseconds are enough to make Java a bad choice for a program like "ls" which gets run constantly, but is irrelevant for server use.
And the fact that little optimization is done on the bytecode ignores the huge amount of optimization that the hotspot compiler does; optimization that in some cases a statically optimized language like C++ cannot do.
Well, for one thing, it is slower than native code.
Patently false. It has been false for years now. Ever since Chris Rijk published his earth shattering benchmarks. (More recent benchmarks here.)
It's now down to the skill of the programmer. A good programmer will write speedy code, and a bad programmer will write garbage. Who'da'thunk?
For another, its garbage collection has a tendency to result in really bad performance stalls
When was the last time you used Java? 1.1? The modern hotspot JVM uses a generational collector which should NEVER stall during runtime unless it begins running into memory pressure. Go try this game and tell us how many stalls you see. If you think that's too "simple", try this one.
For another, its portability has been hampered by not fully supporting interesting OS features, which means that there are all these OS-specific extensions to add things like audio support,
Is there something wrong with the javax.sound packages? I'm REALLY thinking that you haven't tried Java since 1.1.
They don't integrate well with other apps, don't do a good job of supporting OS services, etc.
Psst!
Finally, Java makes it hard to add debug functionality into your code without a performance hit.
That's just a weak argument. Debugging info can really screw up a codebase and should be removed after debugging. But if you're wedded to the idea, get one of the three billion preprocessors that are available.
The bottom line is that pretty much any compiled language has great advantages over Java.
The bottom line is that you haven't used Java since the days of 1.1, but you feel that you're fully qualified to make statements about a platform you know nothing about. Whether you intend to or not, you are trolling, sir. So I would ask you to stop spreading FUD by not commenting on Java until you are again familiar with the platform.
Javascript + Nintendo DSi = DSiCade
Statement with no proof, got to love that. If you even bother googling "java vs c++", you'll see plenty of benchmarks that demonstrate pretty much speed parity at non-GUI tasks.
Hence the reason for the related JSR and Sun's implementation.
Not much to argue although the JDK is constantly expanding to incorporate new features. The trick of course comes in when you have to decide - if feature X is only available on Windows, does one include it? Generally however, this is only an issue for the desktop - a space it's been struggling in. The enterprise market doesn't tend to face this issue.
Umm... the JVM comes for a wide variety of platforms - even the ones for which Sun doesn't release the JVM, the companies developing the OS do (i.e. AIX, MacOS). And you say that Java fails to solve the OS-dependent stuff - compared to C/C++ it's far far ahead. I mean look at something like Netbeans - no OS dependent stuff (except maybe some look and feel). So you're argument is just flawed in so many ways.
When was the last time you actuall used Java. Swing's come a long way and integrates very cleanly into the OS (if done correctly). And it's also getting faster with every release.
Not quite sure what you mean there.
With Java you don't even have to do that saving on development time. Not to mention that with C/C++ you have to be familiar with the appropriate OS-specific API. With Java, there's only 1.
Define "relatively small" and what features you're adding that make integrate it better. And with Java you can do it in a more practical way - that's why there are 3-party libraries such as the Java Desktop Project
Finally, Java makes it hard to add debug functionality into your code without a performance hit.
That's just a weak argument. Debugging info can really screw up a codebase and should be removed after debugging. But if you're wedded to the idea, get one of the three billion preprocessors that are available.
Actually, you can use the assert facility (since Java 1.4, I believe) to achieve something similar as a pre-processor out of the box.
Specificly, about 60% down the document, the following can be read regarding removing any assertion code from the resulting class files:
Removing all Trace of Assertions from Class Files
Programmers developing applications for resource-constrained devices may wish to strip assertions out of class files entirely. While this makes it impossible to enable assertions in the field, it also reduces class file size, possibly leading to improved class loading performance. In the absence of a high quality JIT, it could lead to decreased footprint and improved runtime performance.
The assertion facility offers no direct support for stripping assertions out of class files. The assert statement may, however, be used in conjunction with the "conditional compilation" idiom described in JLS 14.20, enabling the compiler to eliminate all traces of these asserts from the class files that it generates:
So, after resisting for years, let's see what is happening in the GNU world to change Jonathan Schwartz mind
While I make my living programming Java, I think it is a stretch to say Java performs on par with C. Perhaps good implementations in Java are better than bad implementations in ... whatever, but in the general case an interpreted language is one order of magnitude slower than a natively compiled one. For the record, XML Spy is a piece of shit, and I question whether its implmentation is even "natively compiled." Granting it is for the sake of argument, it's still a piece of shit and it's no surprise an enterprise XSLT engine written in Java outperformed it.
Check the great language shootout . I certainly don't believe these benchmarks are perfectly fair, but I do think that Java and C are well represented languages. The results speak for themselves. Java isn't even close to C in memory or runtime efficiency.
I can speak from experience that garbage collection IS a serious issue in corporate IT. Many enterprise applications that are loose with object creation can quickly create objects faster than they are collected and crash the container. This is under heavy load. Of course, a C application with a memory leak does not even have the benefit of garbage collection to save it. But C applications are generally FAR more memory efficient (just look at the shootout!). It is no secret that Java also has severe memory footprint issues (Hello 2 gb Websphere instance). In C you can malloc a chunk of memory and continually repurpose it where in Java you must continually create and throw away objects. Yes, the whole operation is optimized, but the differences are like night and day. They say Java 1.6 "Mustang" will address the footprint issues, but there is no way it will be nearly as efficient as C.
Java is many wonderful things. It is a highly productive language thanks to the best libraries and components. No other language can boast that kind of consistency and interoperability.
But do stop fooling yourself. The Sun JVM is slower than GCC compiled code. Compiler researchers have known for years there is an order of magnitude difference between native and interpreted code across the board. Don't use bogus benchmarks and ignore the fact that different language implementations have real performance characteristics to match their capabilities.
What stops them from adopting one of the existing open source VMs, "embracing and extending" it (still open source, of course), and doing that now?
You do know that Microsoft gave the Kaffe project money, right? The stipulation was that Kaffe had to add Microsoft extensions to its codebase. Turns out, Kaffe never managed to produce a competitive VM (though it's looking pretty good these days) and thus never had the impact that Microsoft had hoped for.
Javascript + Nintendo DSi = DSiCade
Well, it's been available since 1999. Seeing as it has taken slashdot—oh about—7 years to figure it out, you can understand why I'm a little peeved over the number of responders who've claimed that the source isn't available.
If you have a problem with the SCSL license, fine. If you have a problem with the JRL license, fine. But to claim that Sun hasn't released the source code? That's just frustrating.
Javascript + Nintendo DSi = DSiCade