"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.:-/
Unfortunately, one of OSI's core requirements is forking. So Java will never be able to make the pundits happy.
Sure they can - there are other ways to pevent forking than in the license. Look at most of the major OSS projects around and you'll see that there is very little in the way of forking - sure minor forks exist but they quickly die. Sun doesn't care about some minor fork of Java that 20 people use that eventually dies, they are worried about a significant competing standard that honestly splits developers between two different platforms. How often has that happened with big OSS projects? Hardly ever. The question is not so much "what can be done to prevent forking" but "what happens that causes a successful fork". The major examples of significant splits in the OSS world would be Emacs/XEmacs, gcc/ecgs, and XFree86/Xorg. In each of those cases the reason for both the fork, and the success of the fork, comes down to the original project stagnating and being unresponsive to change. Avoid that and you tend to avoid significant forks.
Sun doesn't care about some minor fork of Java that 20 people use that eventually dies
But they DO care about IBM or Microsoft creating a VM that advertises compatbility, but actually pulls the bait-and-switch routine. Remember, Microsoft already tried to pull that routine with the NON-OSS version of Java. It was the license that stopped them. This time, you can be sure that they would stay precisely inside the letter of the law. No Java trademarking, but no compatability testing either. Companies will start to rely on it for its Windows performance, and then Microsoft will start introducing subtle differences. Before you know it, users will blame Sun for being incompatible.
Microsoft's probable response to OSS Java, would be to comb through the source code for bugs, and call a press conference to announce "one gadzillion bugs found in open source Java, more probably exist".
I think the last thing Microsoft wants to do right now is to put "lots of bugs == bad" into people's minds.
You throw out a couple of scare scenarios here with either Microsoft or IBM making a mess of Java, but as far as I can tell they are just that, wild scare scenarios that simply aren't viable if Sun is at all on the ball. For starters Sun can keep the Java trademark and simply bar Microsoft and IBM from advertising whatever they care to sell as "Java". From there it is a question of exactly how either Microsoft or IBM is going to get their new language and VM (whatever they decide to call it - maybe microsoft will call it C# and.NET; no, wait, they already did that) to be dominant, or at least bootstrap it into being a competing standard. Microsoft can do that, as you point out, by leveraging their monopoly. The thing is they've already done that: C# and.NET. They can do that quite successfully whether Sun opens sources Java or not. So for Microsoft the argument is rather moot. What about IBM? They don't have a monopoly to leverage so they'd have to resort to the nasty tactic of making a better language and VM with better libraries to manage to get it to take off. But wait, they can only do that if Sun drop the ball in exactly the manner I described and let Java stagnate and become unresponsive to change. So we're back where we started. Sun open sourcing Java really isn't going to make a lot of difference unless Sun drops the ball themselves - which is exactly what I originally said.
Every, (and I do mean every) story on Java here on Slashdot has contained one of those two links. Most of them contain BOTH. Why? Because the trolls come out in force. The fact that you didn't take the time to look into the matter (I believe I suggested Googling for it) is disappointing and disheartening.:-(
It depends on whether they prohibit or merely discourage forking. Indeed, Sun could even go the trademark route with some success, with only the official Sun Java, and specific licensees (such as creators of alternative Java implementations that conform to the spec) being allowed to use the trademark. This is compatible with the GPL. The fact you can't call your fork "Java" doesn't mean your freedom to change and distribute it has been affected.
There's a more interesting issue here. Sun Java is an embarassment to the OSI. Over the last few years, by using a community driven development process, Java has improved leaps and bounds. Essentially, Sun said "What the Open Source movement says is right, except for the freedom part". And given the OSI keeps being at pains to argue that it's merely a front for software freedom, trying to encourage the development of free software by promoting community-driven development processes which, supposedly, rely upon the software being developed to be Free, this really doesn't hasn't helped it much.
Essentially, the OSI says "We must have free software, because free software means a community of interested parties can develop a program to a much higher standard than would otherwise be the case if it was proprietary. We describe this whole thing as "Open Source"."
Sun responds with: "Aha! But Java isn't free, and it too is developed by a community of interested parties, and they've generated a much higher standard of product than would otherwise have been the case if it wasn't developed using a community process. So your argument fails because you don't need software to be free to use your "open source" development model!"
ESR responds with: "You all suck. Set Java free!!!1!"
So why's Sun "open sourcing" Java? I think they're just looking at ensuring the official Sun implementation has wider adoption, by removing licensing barriers. Free software licenses happen to be a great way to get there. Sun wants to get Java "out there", especially with.NET nipping at its heels. The real problem with Sun's strategy hasn't been forsaking the development model advantages of the OSI's "Open Source", it's been that it's harder to integrate the official Sun Java, the reference implementation, with the non-Java world, because of licensing issues.
And as such, I don't think Sun gives a rats arse what the OSI thinks.
FWIW, I wrote about this in my journal [slashdot.org].
Sun doesn't support Java on Linux. Open sourcers complain. Now, they do, thanks to open sourcers complaining.
Sun didn't support Java on Linux because of open source pressure. They supported it because Linux was very successful commercially and so needed an implementation of the primary commercial development language - Java.
Sun doesn't support Java on Linux as a tier-1 platform. Open sourcers complain. Now, they do, thanks to open sourcers complaining.
Which is complete nonsense. Sun have supported Java on Linux as a primary platform for a very long time.
Sun doesn't release source code for Java. Open sourcers complain. Now, they do, thanks to open sourcers copmlaining.
You need to have a far better understanding of Linux and Java history.
I really don't think you understand how little open source matters in this respect. Java is already the number one development language in almost all areas of development - open source, server side, commercial application development. Sun has open sourced more lines of code in the past year than any other organisation - the entire Solaris codebase, and now they are doing this for Java. However, unless they deliver the entire source code as GPL directly to Richard Stallman, along with a grovelling apology for ever having doubted the true open source faith, some people will never be satisfied!
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.
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.
Well, as a developer, I will tell you THE one
and only way to prevent forking and fragmentation...
The code isn't going to fork itself. If Sun is doing a reasonable job maintaining the source code, they don't have much to fear from a fork. If they are not doing a good job, a fork would hardly be a bad thing.
by Anonymous Coward writes:
on Tuesday May 16, 2006 @04:01PM (#15344711)
What I don't get is why Sun have such a hissy fit over supposed Java incompatibilites introduced through forking of free licensed code. What's to stop them preventing people from calling derivitive versions 'Java'? Sun could implement strict compliance testing, a-la UNIX, to ensure that derivitives are compatible, and can license the 'Java' trademark for use by those compatible versions. Problem solved.
Create a strong community with strong corporate involvement. If somebody does fork the code, the project will either die or be assimilated back into the main branch. Don't worry too much about others, just make sure that Sun will stand behind an official community. And standing behind them also means listening to them, even the ideas that you don't like.
Look at Perl. It's open source, and hasn't really forked. It has, however, evolved.
Take a feature like generics. There were at least two implementations (Pizza, GJ) available a couple of years before JDK 1.5. That's a fork that could have happened easily.
There are also raging debates over how certain numerics extensions should be done. You could argue that a minor fork has already happened with logging. Some people have a strong preference for Log4j over the Java API.
You get three or four examples of good but different forks, and Java as a stable, uniform platform could be in trouble.
Anyone can use the code. You can only call yourself "Java" if you hit certain specs and pass some tests. In other words, if you can prove that you meet the Java standards (with API support etc), you can call yourself Java and use the source code. If not, you aren't Java. Feel free to use the source code.
This may not be a GPL license, but that's alright.
Is there any reason why such an approach wouldn't work?
Whereas I'm not surprised that Slashdot is bringing out the normal anti-Sun's-attitude-towards-Java dogma, is this really a surprise? Jonathan Schwartz is closer to being a pro-Slashdot geek than Scott McNealy ever was. If anything, McNealy was just an arrogant ass who liked staying in his ivory tower with Bill Gates and Larry Ellison. Schwartz has always shown to be more of a geek than McNealy, and releasing the source code to Java has been a "cry of the geeks" for a long time.
(Note that I don't use "geek" derogatorily as I fondly consider myself to be one.)
Sun is giving us a ton of surprises in the past few years with Schwartz on board - from AMD processors to their first, AFFORDABLE powerhouse workstations (Ultra 20). I'm not surprised by this move at all, but I also don't blame them for wanting to be able to protect one of their revenue streams. At least Sun is trying. I guess the Slashdot "make it free or forget it" is still too strong, based on the responses I've seen so far in this thread. Looks like when it comes to Java, Sun is damned whether they do or don't. Pity.
Seriously, at this late date in the game who cares anymore what Sun does? Those who care not for Freedom have already adopted Java and those who care are either using another language or are now firmly in the GCJ camp and, knowing Sun, won't leave for any bait & switch offer from Sun. I mean, raise your hand if you believe Sun's offer to "open source" Java will actually become a code dump under an OSI approved license. And the odds of it's license (and you can bet your last dollar it WILL be Yet Another License) being GPL compatible are null.
Even today's new initiative to loosen the binary license to permit distribution repackaging is being being greeted by a certain amount of scepticism just because it is Sun. Personally I'll believe it is for real (as opposed to a deal for certain select popular distros, much like the Firefox trademark bullcrap) if jpackage.org can finally ship a binary rpm.
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 [wikipedia.org]) 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?
Java offers nothing useful or exciting compared to what's out there.
What else is *out there*? c,c++,C#, Visual Basic, Python? If your going to tell me its terrible, I certainly understand that point of view, please at least tell me what you cosider to be better and what applications you have in mind. Just telling me its bad and not good for much, doesn't help much.
Any suggustions to what is out ther that holds such great advantages to Java?
Well, for one thing, it is slower than native code.
Patently false. [blogs.com] It has been false for years now. Ever since Chris Rijk published his earth shattering [aceshardware.com] benchmarks. (More recent benchmarks here [improve-technologies.com].)
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 [javaunlimited.net] and tell us how many stalls you see. If you think that's too "simple", try this one [wurmonline.com].
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.
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 [google.com] 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.
Misleading Headline (Score:5, Informative)
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.
Re:Misleading Headline (Score:5, Insightful)
Sure they can - there are other ways to pevent forking than in the license. Look at most of the major OSS projects around and you'll see that there is very little in the way of forking - sure minor forks exist but they quickly die. Sun doesn't care about some minor fork of Java that 20 people use that eventually dies, they are worried about a significant competing standard that honestly splits developers between two different platforms. How often has that happened with big OSS projects? Hardly ever. The question is not so much "what can be done to prevent forking" but "what happens that causes a successful fork". The major examples of significant splits in the OSS world would be Emacs/XEmacs, gcc/ecgs, and XFree86/Xorg. In each of those cases the reason for both the fork, and the success of the fork, comes down to the original project stagnating and being unresponsive to change. Avoid that and you tend to avoid significant forks.
Jedidiah.
Re:Misleading Headline (Score:5, Insightful)
But they DO care about IBM or Microsoft creating a VM that advertises compatbility, but actually pulls the bait-and-switch routine. Remember, Microsoft already tried to pull that routine with the NON-OSS version of Java. It was the license that stopped them. This time, you can be sure that they would stay precisely inside the letter of the law. No Java trademarking, but no compatability testing either. Companies will start to rely on it for its Windows performance, and then Microsoft will start introducing subtle differences. Before you know it, users will blame Sun for being incompatible.
Re:IBM? Microsoft? (Score:5, Insightful)
I think the last thing Microsoft wants to do right now is to put "lots of bugs == bad" into people's minds.
Re:Misleading Headline (Score:4, Insightful)
Jedidiah.
Re:Misleading Headline (Score:5, Informative)
WindBourne! I'm shocked to hear such garbage from you!
Current "Stable" JVM - <= 1.5 [sun.com] (SCSL)
"Unstable" JVM Branch - 1.6 [java.net] (JRL)
Every, (and I do mean every) story on Java here on Slashdot has contained one of those two links. Most of them contain BOTH. Why? Because the trolls come out in force. The fact that you didn't take the time to look into the matter (I believe I suggested Googling for it) is disappointing and disheartening.
Re:Misleading Headline (Score:5, Insightful)
There's a more interesting issue here. Sun Java is an embarassment to the OSI. Over the last few years, by using a community driven development process, Java has improved leaps and bounds. Essentially, Sun said "What the Open Source movement says is right, except for the freedom part". And given the OSI keeps being at pains to argue that it's merely a front for software freedom, trying to encourage the development of free software by promoting community-driven development processes which, supposedly, rely upon the software being developed to be Free, this really doesn't hasn't helped it much.
Essentially, the OSI says "We must have free software, because free software means a community of interested parties can develop a program to a much higher standard than would otherwise be the case if it was proprietary. We describe this whole thing as "Open Source"."
Sun responds with: "Aha! But Java isn't free, and it too is developed by a community of interested parties, and they've generated a much higher standard of product than would otherwise have been the case if it wasn't developed using a community process. So your argument fails because you don't need software to be free to use your "open source" development model!"
ESR responds with: "You all suck. Set Java free!!!1!"
So why's Sun "open sourcing" Java? I think they're just looking at ensuring the official Sun implementation has wider adoption, by removing licensing barriers. Free software licenses happen to be a great way to get there. Sun wants to get Java "out there", especially with .NET nipping at its heels. The real problem with Sun's strategy hasn't been forsaking the development model advantages of the OSI's "Open Source", it's been that it's harder to integrate the official Sun Java, the reference implementation, with the non-Java world, because of licensing issues.
And as such, I don't think Sun gives a rats arse what the OSI thinks.
FWIW, I wrote about this in my journal [slashdot.org].
Re:Misleading Headline (Score:4, Interesting)
Sun doesn't support Java on Linux. Open sourcers complain. Now, they do, thanks to open sourcers complaining.
Sun didn't support Java on Linux because of open source pressure. They supported it because Linux was very successful commercially and so needed an implementation of the primary commercial development language - Java.
Sun doesn't support Java on Linux as a tier-1 platform. Open sourcers complain. Now, they do, thanks to open sourcers complaining.
Which is complete nonsense. Sun have supported Java on Linux as a primary platform for a very long time.
Sun doesn't release source code for Java. Open sourcers complain. Now, they do, thanks to open sourcers copmlaining.
You need to have a far better understanding of Linux and Java history.
I really don't think you understand how little open source matters in this respect. Java is already the number one development language in almost all areas of development - open source, server side, commercial application development. Sun has open sourced more lines of code in the past year than any other organisation - the entire Solaris codebase, and now they are doing this for Java. However, unless they deliver the entire source code as GPL directly to Richard Stallman, along with a grovelling apology for ever having doubted the true open source faith, some people will never be satisfied!
Its Simple (Score:5, Funny)
Re:GPL'ing java would be bad... (Score:5, Informative)
C'mon Jeanie! *Please* get back in your bottle! (Score:5, Insightful)
Well, as a developer, I will tell you THE one and only way to prevent forking and fragmentation...
Don't release the source code.
Oops.
How to prevent forking and fragmentation (Score:4, Insightful)
Change the title (Score:5, Insightful)
Trademark usage. (Score:4, Insightful)
You want to prevent forking? (Score:5, Insightful)
Look at Perl. It's open source, and hasn't really forked. It has, however, evolved.
"Look at Perl." (Score:5, Funny)
Re:You want to prevent forking? (Score:4, Insightful)
There are also raging debates over how certain numerics extensions should be done. You could argue that a minor fork has already happened with logging. Some people have a strong preference for Log4j over the Java API.
You get three or four examples of good but different forks, and Java as a stable, uniform platform could be in trouble.
You can only use the term "Java" if you pass tests (Score:5, Insightful)
This may not be a GPL license, but that's alright.
Is there any reason why such an approach wouldn't work?
Why is this a surprise? (Score:5, Insightful)
(Note that I don't use "geek" derogatorily as I fondly consider myself to be one.)
Sun is giving us a ton of surprises in the past few years with Schwartz on board - from AMD processors to their first, AFFORDABLE powerhouse workstations (Ultra 20). I'm not surprised by this move at all, but I also don't blame them for wanting to be able to protect one of their revenue streams. At least Sun is trying. I guess the Slashdot "make it free or forget it" is still too strong, based on the responses I've seen so far in this thread. Looks like when it comes to Java, Sun is damned whether they do or don't. Pity.
In other news.. (Score:4, Funny)
At this late date, who cares. (Score:4, Insightful)
Even today's new initiative to loosen the binary license to permit distribution repackaging is being being greeted by a certain amount of scepticism just because it is Sun. Personally I'll believe it is for real (as opposed to a deal for certain select popular distros, much like the Firefox trademark bullcrap) if jpackage.org can finally ship a binary rpm.
TeX (Score:4, Informative)
Huh? (Score:4, Insightful)
What else is *out there*? c,c++,C#, Visual Basic, Python? If your going to tell me its terrible, I certainly understand that point of view, please at least tell me what you cosider to be better and what applications you have in mind. Just telling me its bad and not good for much, doesn't help much.
Any suggustions to what is out ther that holds such great advantages to Java?
Re:Huh? (Score:5, Informative)
Patently false. [blogs.com] It has been false for years now. Ever since Chris Rijk published his earth shattering [aceshardware.com] benchmarks. (More recent benchmarks here [improve-technologies.com].)
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 [javaunlimited.net] and tell us how many stalls you see. If you think that's too "simple", try this one [wurmonline.com].
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! [java.net]
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 [google.com] 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.