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."

Comments

Misleading Headline

[AKAImBatman]

"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. :-/

Re:Misleading Headline

[Coryoth]

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.

Jedidiah.

Re:Misleading Headline

[nickos]

Remember the Unix wars fiasco?

Re:Misleading Headline

[AKAImBatman]

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.

Re:Misleading Headline

[WindBourne]

while source code for the java languages is opened and available, what the "pundits" have been calling for is the source code to the virtual machine and the compiler. That is C code and is NOT opened. In fact, the lack of openness led to gcj and the other java vm.

Re:Misleading Headline

[Coryoth]

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.

Sure, but they will still own and control the Java trademark and they can simply bar such bait-and-switch advertising. Microsoft can fork Java all they want, they just can't call it Java, nor Java comnpatible. Besides MS is unlikely to do any such thing now since their efforts are heavily sunk into C# and .NET.

Jedidiah.

Re:Misleading Headline

[squiggleslash]

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.

Re:Misleading Headline

[Coryoth]

Which interestingly enough took place between proprietary systems, not open ones. In that sense the UNIX wars are more akin to the battle between Java and C# and .NET (which could, indeed, be seen as damaging to the VM market). That is to say, regardless of what Sun does with Java they are already facing the same sorts of problems.

Jedidiah.

Re:Misleading Headline

[AKAImBatman]

what the "pundits" have been calling for is the source code to the virtual machine and the compiler

WindBourne! I'm shocked to hear such garbage from you!

Current "Stable" JVM - <= 1.5 (SCSL)

"Unstable" JVM Branch - 1.6 (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

[DragonWriter]

But they DO care about IBM or Microsoft creating a VM that advertises compatbility, but actually pulls the bait-and-switch routine.

One way to manage that risk might be to pull a page from the (oddly enough) pen & paper RPG world -- when Wizards of the Coast adapted the open source idea to those kind of games by releasing the core of D&D/3e under its Open Gaming License as the d20 System Reference Document, it faced similar concerns, so its content licenses requires surrendering rights that the user would otherwise have to, e.g., nominative fair use of trademarks, so that while you can make derivative works, you can't (except by complying with a more restrictive trademark license) advertise or promote them using "product identity" associated with D&D or the d20 System. Applying the same idea back to software wouldn't be that hard. OTOH, there is a limited degree to which you can exercise control over OSS -- that's rather the point.

Re:Misleading Headline

[Arandir]

Unfortunately, one of OSI's core requirements is forking.

There are ways to minimize forking. For example, a license could require modifications be distinct from the original (ei. patching). The QPL license does this. But a far easier way is to simply trademark the name (already done), and only permit it to be used on the original (or approved) code bases.

Re:Misleading Headline

[FooBarWidget]

"No Java trademarking,"

Why? Open source does not imply no trademarking. Look at RedHat for a good example. As this post said, Sun can make it so only compatible VMs can call themselves "Java". Isn't that THE ideal solution? Why don't people spend more time discussing this instead of yelling "OMG open source java evil nonononono!!!!" all the time?

Re:Misleading Headline

[pianomahnn]

In the amount of time it took you to write why we need to pull our heads out of our butts, you could've posted some useful links.

Re:Misleading Headline

[FatherOfONe]

Ok, I will throw out an example.

Microsoft says "Great Sun open sourced Java". We will take it bundle it with windows, change all the underlying code so that it actually uses windows API's, remove anything that competes against our stuff like SWING, EJB's, Servlets, messaging API's et al, and make it so that our Java only runs on Windows, and even if you try to run a "normal" Java application , it will not work unless you change it to support com.microsoft.xxx libraries, and jump through a ton of hoops.

Now you and I would say that we would NEVER code to that, but the reality is that the management dorks out there would say that we would have to because it is on 95% of the worlds computers. Thus who really is the standard? It would be the defacto standard, much like IE is today. It sucks but it is the reality of the situation. Trust me, this has happened to me before and the best thing that EVER happened to our development staff was when Microsoft "dropped" support of Java. The management dorks had runs Sun's JVM and suddenly stuff started to work well and we could code to open standards, not Windows standards.

So, on one hand I hope that Sun does open source Java to shut up all the people bitching, but the last thing I want is IBM or Microsoft doing their own fork. I as a developer do not EVER want to have to change my code to run on some specific platform or JVM. If I wanted to do that I would code in C++. Heck it is open, and if peopl code to "standards" they can just port their apps with little trouble.... Oh wait that never really worked out did it?

The good news is that at the point Microsoft probably won't mess with Java, they have to worry about a bunch of other stuff, but that won't stop IBM.

Re:Misleading Headline

[HaeMaker]

Forking? They are worried about FORKING? Do you know how many FORKING Javas I have on my manchine to cover all the stinking apps that require a specific version of Java?

Let it fork, it can't POSSIBLY get any worse.

Re:Misleading Headline

[AKAImBatman]

You want some links? Huh punk?

http://developers.slashdot.org/article.pl?sid=04/1 1/06/1556215
http://developers.slashdot.org/comments.pl?sid=142 758&cid=11963910
http://developers.slashdot.org/comments.pl?sid=185 508&cid=15325710
http://it.slashdot.org/article.pl?sid=05/10/31/122 0257
http://it.slashdot.org/comments.pl?sid=166862&cid= 13914658
http://developers.slashdot.org/comments.pl?sid=149 147&cid=12515951
http://developers.slashdot.org/comments.pl?sid=149 147&cid=12501483
http://developers.slashdot.org/comments.pl?sid=185 508&cid=15309562

Every story. EVERY FUCKING STORY. The links are posted by someone EVERY FUCKING STORY. Does anyone listen? NO! They're too busy WITH THEIR HEADS STUCK UP THEIR ASSES to pay any attention!

So you'll have to excuse me IF I'M A LITTLE PISSED OFF AT THE MOMENT.

Re:Misleading Headline

[Coryoth]

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.

Jedidiah.

Re:Misleading Headline

[KidSock]

... EVERY FUCKING STORY. Does anyone listen? NO! They're too busy WITH THEIR HEADS STUCK ...

Get a grip dork. Maybe you should try building model airplanes or going outstide. I think the mold in your mom's basement is getting to you.

Re:Misleading Headline

[Anonymous Coward]

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!"

Which would all be well and good if it weren't for the presence of bugs in the JVM that date back to very early releases (i.e. Java 1.1 and Java 1.2) that appear to have simple fixes and haven't been fixed because the groups within Sun are playing political football with them. Go look at the bugs at the top of bug parade and check out how long they've been in the JVM.

Re:Misleading Headline

[Anonymous Coward]

There is of course a simple solution to this issue. Just license it under the GPL and Microsoft won't touch it with a 10 foot pole. IBM on the other hand....

Re:Misleading Headline

[p3t0r]

In the eweek article Schwarts is actually quoted stating the license will be OSI compliant:

If Sun goes down the path of open-source licensing Java, it would use an OSI (Open Source Initiative)-approved license, he added.

c'mon, that doesn't sound all to bad now does it?

Re:Misleading Headline

[Anonymous Coward]

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.

And if you don't avoid stagnation and paralysis, forking is a good thing.

Re:Misleading Headline

[Schraegstrichpunkt]

Sounds like Firefox. Or even Debian (though Debian is a lot more liberal with the use of its trademark.)

Re:Misleading Headline

[FatherOfONe]

If Sun can stop anyone from using the word "Java" then we agree, but if they allow forks then it appears that Microsoft could call it MsJava and change their vm to also accept Java compiled code.

I am not talking about a complete rewrite of a language like they did with .Net and C#. I am talking about them having control of a JVM. We have lived in that world and it sucked, I don't think anyone wants to go back to it again.

As far as IBM goes they still own a lions share of the server market and could easily fork J2EE. That would also suck.

Now I keep asking myself "what problem are we trying to solve?" People want the source to Java... No problem. They want to write their own JVM? No problem. They just need to pass the certification. Is that free? Nope. Do you have a passion for 3D game programming and want to help develop Java3D? No problem, get on the JCP and I am sure your help will be greatly appriciated. Want to help out with the core API's? No problem again, much like Linux though, it may not be accepted. So I ask again. What problem are we trying to solve?

How is this going to make my life as a Java developer any better?

How is this going to make the average computer users life better?

I am not trying to be a jerk here. I am just curious if I am missing something obvious.

Re:Misleading Headline

[arodland]

"Open Source" doesn't conflict with "name protection".

See for example the GFDL and the Artistic License for clauses restricting the naming of derivative works, and the BSD license for a clause restricting "endorsement".

Besides which, unless a license specifically makes itself "incompatible" with trademarking, then the following case will generally hold: if the license would grant you the right to distribute a modified version, but a trademark prevents you from distributing it under a given name, then the license doesn't permit you from distributing a modified version under that name. See for example Section 7 of the GPL.

In short, Java can be released in an "open source" manner without necessarily loosening Sun's hold on the name "Java", or the Java standards or certification.

Re:Misleading Headline

[Panaflex]

It's pretty simple overall -

The primary reason to Open Source java is so that they can get their Vm installed on every unix box out there. They get a huge "bump" when Fedora, RedHat, Suse, Debian, you name it has Java running. Microsoft may even jump in too, if there's incentive.

And then the vendors, developers, and distributions WILL code using Java - make no mistake.

The great HAZARD for Sun right now is that Mono (aka Novell) will make that jump first and become viable enough to essentially shut out Java.

Which, I personally would not oppose. I'm no Java fan, and I'm REALLY NOT a MS fan.. but C# is cleaner and nicer to learn overall - especially if you've ever done JNI.. ack bleah. JNI is the bane of the universe.

Re:Misleading Headline

[Bob9113]

But they DO care about IBM or Microsoft creating a VM that advertises compatbility, but actually pulls the bait-and-switch routine.

Uhhh, don't they already have this? Jikes, VisualJ++, and whatever the .net version of Java is come to mind.

Re:Misleading Headline

[AKAImBatman]

Oh, I agree whole-heartedly. If Sun makes it OSI compliant, it would be a boon for the Java industry. The problem is that they can't really have it both ways. They can't not allow forking while simultaneously meeting the OSI's requirements. It's one or the other. I'm sure Schwartz is looking for a loophole, but he'll have a hard time finding it.

IMHO, it would help a lot more if Sun were to simply make Java binaries easier to distribute. They keep removing licensing restrictions, but they never actually grant permission for Operating Systems to include their binaries. (I actually spoke with a Java Product Manager on the issue to confirm that was a problem.)

Thankfully, that is finally changing. If the recent news is correct, Sun may soon be allowing Java to be carried by any distro that wishes to do so. Combined with the annoucement of FreeBSD binaries, things are starting to look up, up, up. :-)

Re:Misleading Headline

[RedHat Rocky]

Speaking as someone who us a simple end user of java software, I don't give a crap about JVMs. What I care about is does the app work? And so far, the typical answer for anything beyond simple toys is "No".

Note, I'm not a Java developer. I just want the apps to work in an efficient manner. Open Source would be nice, but works like it is supposed to would be good enough.

To say that Java at this moment is an example of good, community developed software is just wrong. Sure, it might be better than a traditionally developed piece, but the picture of software goodnes it ain't.

Re:Misleading Headline

[sfjoe]

So Java will never be able to make the pundits happy.

You spelled 'pundits' wrong. It's 'o-b-s-e-s-s--i-v-e f-a-n-b-o-y'.

Re:Misleading Headline

[DrSkwid]

BSDi / FreeBSD / OpenBSD / NetBSD / Dragonfly

and, of course, the definitive pre-emptive fork :

Minix / Linux

Others I can think of

Mozilla / Firefox

Postgres / Postgres95 (now PostgreSQL)

Can I count OS/2 / Windows ?

Debian / Ubuntu

While I was googling for forks I found these :

http://mako.cc/writing/to_fork_or_not_to_fork.html

http://producingoss.com/html-chunk/forks.html

Re:Misleading Headline

[Thrakkerzog]

Perhaps they mean the source code to the interpeter, not the class library?

Re:Misleading Headline

[DragonWriter]

It is available (you can get it). What it is not is "open" as in "available under an open-source license". The two are not the same, despite the fact that a lot of big companies selling proprietary software occasionally make source code "available" and pretend that has the advantages of making it "open source", even going so far as to call available source "open".

Re:Misleading Headline

[fbg111]

This time, you can be sure that they would stay precisely inside the letter of the law.

Just GPL the source code, and then MS couldn't use it without sharing the Windows source. That'll fix em. Since Sun has already open-sourced Solaris, what do they have to lose?

Re:Misleading Headline

[AKAImBatman]

Perhaps you should be chastised for failing to read this thread?

The source code to Java (ALL the source code) has been available under the SCSL for nearly a decade. The JRL license is new, but it's used on the development branch of Java.

And people wonder why I blow a gasket about these things?

Re:Misleading Headline

[Andrew Tanenbaum]

All I have to say is Emacs

Re:Misleading Headline

[grammar fascist]

Remember the Unix wars fiasco?

I think I saw that movie once. It had something to do with Owen Softfounder and System Vader or something. Entirely forgettable. Oh, and those head buns were so 70s.

Re:Misleading Headline

[strstrep]

Do you mean the BSD license?

"Neither the name of the University of California, Berkeley nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."

Re:Misleading Headline

[Decaff]

The real problem with Sun's strategy

This is hilarious. Sun release a language and make it freely available. Open sourcers complain. Just about everyone else uses it. Sun make the source code available under a restricted license. Open sourcers complain. Java gets even wider adoption. Sun opens up the source even more (with the Java 6.0 project). Open sourcers still complain. Java becomes the number one language in Sourceforge. Sun finally allows distribution of the JRE as part of Linux packages and promises to open source Java.

Open sourcers STILL complain.

If you had any idea about the state of Java in the IT industry, you would realise that Sun really, really don't have to work to get Java 'out there' - Java has become the dominant server-side development language, and .NET isn't even coming close to nipping at Java's heels. Compared to Java use, C# barely registers.

Face it - Sun's strategy has worked.

Re:Misleading Headline

[JebusIsLord]

hence the difference between the terms "open source" (meaning that the source is openly available) and "free software" (meaning that the source is free as in freedom).

Re:Misleading Headline

[greenrd]

OTOH you could view it like this:

Sun doesn't support Java on Linux. Open sourcers complain. Now, they do, thanks to open sourcers complaining.

Sun doesn't support Java on Linux as a tier-1 platform. Open sourcers complain. Now, they do, thanks to open sourcers complaining.

Sun doesn't release source code for Java. Open sourcers complain. Now, they do, thanks to open sourcers copmlaining.

Etc.

Re:Misleading Headline

[greenrd]

Well, not quite all the source code. The SCSL does not cover the version of javac included in Java 1.5 or older versions (I don't know about Java 1.6). But that doesn't matter, because the Eclipse Java compiler is open source, and just as good if not better (it certainly has better warnings than javac in Java 1.5).

Re:Misleading Headline

[Decaff]

OTOH you could view it like this:

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!

Re:Misleading Headline

[AKAImBatman]

The SCSL does not cover the version of javac included in Java 1.5 or older versions

??? I think you're confused. The JavaC compiler is there under j2se/src/share/classes/sun/tools/javac. Considering that each version of the SCSL code is used to build successive versions under Linux/FreeBSD, I have a hard time believing that the source code isn't included!

Download the source code and see for yourself.

Also, the Generics compiler was released separately when Sun was testing it. The full source code is there if you'd care to play with it.

Re:Misleading Headline

[shaitand]

You seem confused. Successful forking is essential to proper free software but it is not what sun is aiming for. Sun wants to remain at the helm of Java, they don't want another fork, even if that fork is successful and forked for the right reasons. Sun would not be happy with a java.org fork that everyone and their dog adopted and left Sun to be just another contributor instead of running the show.

Me, I want a true open product that can be forked if Sun mismanages it.

Re:Misleading Headline

[shaitand]

With a proper free license like the GPL this is a non-issue. Any changes Microsoft made would have to be distributed with the binary. First Microsoft wouldn't touch the GPL with a ten foot pole (in no small part because of their smear campaigns that said they love open source and hate the GPL because it's terms don't allow them to steal the source), second the only way microsoft could take the ability to run the show away from Sun would be gain greater acceptance of their fork.

That is valid forking in action. Forking is a good healthy open process. Preventing forking is a bad thing for everyone. It means that if Sun mismanages Java then there is would be no way for someone else to step up to the plate. With successful forking in place then the software progresses via evolution with the most fit fork surviving. If Sun Java dies in a fork friendly environment it is because they had less fit genes.

Re:Misleading Headline

[dnoyeb]

Sun is worried about IBM forking there code. Which is predictable. Or what about Microsoft trying to take another jab at Java. its not Open Source developers they fear.

Re:Misleading Headline

[emjoi_gently]

Just pointing out that this is just wrong, 1999 style thinking.

There are a good number of solid, serious, Java desktop apps out there nowdays. Limewire for one.

Re:Misleading Headline

[squiggleslash]

If you had any idea about the state of Java in the IT industry...

Who are you addressing? Because you quote a few words from my comment, and then talk about "open sourcers" "complaining" no matter what Sun does, something that has nothing to do with anything I wrote. Indeed, depicting me as yet another "open sourcer" is utterly ridiculous given my comments.

The full comment was, of course:

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.

That's absolutely right and I dare you to find holes in that, rather than dubious and irrelevent complaints about "open sourcers".

Re:Misleading Headline

[Coryoth]

Sun would not be happy with a java.org fork that everyone and their dog adopted and left Sun to be just another contributor instead of running the show.

I never claimed they would be happy with that. All I'm claiming is that if they don't want that to happen all they have to do is not mismanage Java, and not provide any reasons for such a fork to get any traction.

Jedidiah.

Re:Misleading Headline

[voxelz]

It depends on whether they prohibit or merely discourage forking.

The Java source code is already available to the public, but the current license prohibits forking. I'm not sure what a license such as the GPL would do other than allow forking of Java. What is the motive behind wanting to fork Java? Personally, I think Sun does a great job developing Java, and the source code is available to anyone who wishes to learn from it or contribute patches.

Re:Misleading Headline

[Anonymous Coward]

No, because Sun's Java offering doesn't qualify as "open source" either. Basically, the license conditions allow you to read and run the code, and not much else - you're not allowed to change it and then distribute your changes, a key requirement for it to be called 'open'.

"Available Source" would probably be a fair description.

Re:Misleading Headline

[aCapitalist]

If you had any idea about the state of Java in the IT industry, you would realise that Sun really, really don't have to work to get Java 'out there' - Java has become the dominant server-side development language, and .NET isn't even coming close to nipping at Java's heels. Compared to Java use, C# barely registers.

In the alternative universe that you live in that all might be true. The fact is that Microsoft's server software now outsells all of proprietary Unix combined and keeps on climbing in market share. And of course we don't need to discuss the desktop. Java was never even a blip on the desktop radar screen...even in the open source world. But it's not just .NET/Mono that is intruding on Java's server space. You've got LAMP and RoR. And those solutions are chipping away at Java on the low-end. By the time Java only has the very high-end server space left, it'll be all over.

Sun still hasn't realized that Java (the platform), and not Java (the language), is what's important.

Re:Misleading Headline

[bwt]

Why on earth is Sun so obsessed with forking? If they don't do something soon clones like gcj are going to get good enough to run most things, and then the risk of splintering the development community will be very large because people will want to follow an open source java work-alike.

Re:Misleading Headline

[SEE]

Um, no. Open, like free, has more than one meaning. It'd be exactly as accurate to say:

hence the difference between the terms "open source" (meaning, as per Oxford English Disctionary, source "that may be used, shared, or competed for without restriction") and "free software" (meaning that the source is free as in gratis).

Re:Misleading Headline

[FST777]

If M$ bundles their new runtime with Windows without calling it Java, the average Joe finds that he can play Java-games and do his online banking without those questions on his screen he got years ago.

Re:Misleading Headline

[antonpiatek]

IBM already releases its own version of java. IBM Java.
It has a license with Sun to release its own derivative of Java when included with its products.

Most of the work is performance improvements, but AFAIK there is nothing stopping them doing what they want with it already, only that it cannot be shipped seperately

Re:Misleading Headline

[Decaff]

That's absolutely right and I dare you to find holes in that, rather than dubious and irrelevent complaints about "open sourcers".

The hole in that is that it is now factually wrong. The license has changed as of a couple of days ago.

Re:Misleading Headline

[Decaff]

In the alternative universe that you live in that all might be true. The fact is that Microsoft's server software now outsells all of proprietary Unix combined and keeps on climbing in market share.

I suppose you do realise that one of the most important deployment platforms for J2EE is Windows Server? You are confusing 'server operating systems' with 'software deployed on those operating systems'.

And of course we don't need to discuss the desktop.

Where Swing has a bigger presence than Webforms.

Java was never even a blip on the desktop radar screen...even in the open source world.

Wrong. Java has substantial use for internal desktop development.

But it's not just .NET/Mono that is intruding on Java's server space. You've got LAMP and RoR. And those solutions are chipping away at Java on the low-end. By the time Java only has the very high-end server space left, it'll be all over.

What a set of delusions! Mono simply doesn't exist as a server solution, and RoR, for all its hype, is hardly used at all for serious commercial development.

You need to take your Microsoft blinkers of and take a look at the real world. Java use is still growing - check any technology analysis or job market survey.

Re:Misleading Headline

[IAmTheDave]

which could, indeed, be seen as damaging to the VM market

Competition in any market is a good thing.

The ideal number of serious competitors in a space is, and will always be, 2.

So I really don't see it being bad for the VM world.

Re:Misleading Headline

[AKAImBatman]

AFAIK there is nothing stopping [IBM] doing what they want with it already

You mean, other than the license that requires that IBM verify it's JVM against Sun's Compatibility Testing before they can release a new version?

Why do you think Microsoft lost their license to Java? Because they look at Sun funny? No! Because they failed the compatibility testing and tried to tell Sun to shove it.

Re:Misleading Headline

[petermgreen]

say you find a bug in java, you can fix it for yourself but you can't fix it for your clients.

you have to wait for it to propogate back through sun and if they ignore it you have no recourse.

Also do you remember xfree86? the maintainers became worse and worse pricks eventually cumulating in a license change that was generally found unacceptable (most notablly it would have created licensing issues with linking GPL apps with xlibs). It was forked from a point before the license change and development quickly got going again with little loss. The fresh leadership has also lead to a radial sanitisation of the source tree that wouldn't have been feasible before.

Now suppose the same thing happened with java, noone else can take over maintainership because of licensing issues, so we would stuck with either continuing to redistribute old binaries in which we can't fix or update anything (Which is ok in the medium term but very bad in the long term, i386 and even amd64 WILL NOT be dominent forever!) or doing a complete rewrite (which is happening anyway because of distro politics but is far easier said than done).

Forking is the long term lifeblood of true opensource software allowing the software to outlive its authors interest (whether personal or commercial) in it. It also allows experimental features to be developed on a fork (and later possiblly reintegrates).

Re:Misleading Headline

[Dukhat]

What about the incompatibilities between Netscape's Javascript, Microsoft's JScript, and ECMAScript? Microsoft didn't have to say Jscript is Javascript compatible in order for people to use it, they just included it in their browser. If Microsoft includes a forked Java VM called Lemonade in their OS, only a small percentage of people will download an official Java-compatible VM to run Java applets and applications.

Re:Misleading Headline

[Anonymous Coward]

Convenintly leaving out LAMP from that rebuttal ... Priceless.

Re:Misleading Headline

[aCapitalist]

I suppose you do realise that one of the most important deployment platforms for J2EE is Windows Server? You are confusing 'server operating systems' with 'software deployed on those operating systems'.

Well, duh. Because Windows is the most prevalent operating system in the world. But "important" means nothing. Of course the "most important" stack for Windows Server is .NET.

Where Swing has a bigger presence than Webforms.

That statement just shows how clueless you really are. They don't call it TheServerSide.com for no reason. Java failed on the desktop years and years ago because Sun thinks Metal is a "good thing". Not to mention that Swing (although affords flexibility), is a cumbersome API. That's why the Swing guys are developing a new "framework" on top of Swing. Too little, too late.

Wrong. Java has substantial use for internal desktop development.

"internal"...that's nice. What, because Swing is such shit that it's an embarrassment to release anything outside of the office. Or most likely, the server side guys occassionaly get sick of generating HTML.

What a set of delusions! Mono simply doesn't exist as a server solution, and RoR, for all its hype, is hardly used at all for serious commercial development.

But just because of the .NET, Mono is important and can only grow. On the open source desktop, Mono is already way more popular. Maybe Sun should've stopped trying to push that Swing crap and actually make a couple Java-gtk+ apps years ago. After all, Gnome is Sun's desktop. Too little, too late.

RoR is still new tech, but nobody is really questioning it's approach. That's why we have all the spinoffs based on Rails idioms. Oh, and just goto Jroller.com on any random day and see all the java developers blogging about it. You need to take off your blinders and see reality.

And as the AC pointed out, you totally neglected to mention LAMP which is absolutely chewing up Java on the low end.

You need to take your Microsoft blinkers of and take a look at the real world. Java use is still growing - check any technology analysis or job market survey.

Oh, because Dice.com told you so? Java has peaked and most developers recognize it's shortcomings (way too verbose). C# suffers from the same problem too, but there's just more language options on the .NET stack out of the box. Sun keeps on thinking that Java (the language) is what counts, when in reality its the JVM and class libraries.

And back on topic, Open Sourcing Java will not change a damn thing either way.

Re:Misleading Headline

[dadragon]

How is this going to make my life as a Java developer any better?

Maybe not your life as a Java developer, but it will make mine easier. I will be able to use the *BSD ports without jumping through massive hoops to get them installed and working. That will make me happy.

Re:Misleading Headline

[Amorya]

Use the forks...

Its Simple

[Bill, Shooter of Bul]

Use a spoon. Not only does it prevent you from forking, but its really hard to fragment anything with it.

Re:Its Simple

[enrevanche]

Unless your spoon is a spork!

Re:Its Simple

[Anonymous Coward]

There is no spork.

Re:Its Simple

[LordOfTheNoobs]

#define spork(a) fork(a)

sweet...

Re:Its Simple

[Surt]

Unfortunately, there is no spoon.

Re:Its Simple

[misleb]

Ya know, one of these days I am going to learn to be a little quicker to the punchline. Congrats.

-matthew

Re:Its Simple

[Schraegstrichpunkt]

What if your spoon is too big?

Re:Its Simple

[Anonymous Coward]

Then your anus is bleeding?

Re:Its Simple

[javaDragon]

Yes, but there is no spoon...

Less talkin' more openin'

[Whiney Mac Fanboy]

C'mon Sun, we're sick of hearing about the pending open sourcing of Java. Show us the license!

I know, I know, Sun's afraid that Eclipse is going to... well eclipse the sun, but c'mon! make it GPL, retain the trademark and you won't believe the explosion in Java coding you'll see!

Re:Less talkin' more openin'

[Anonymous Coward]

...but c'mon! make it GPL...

Oh please no.

Re:Less talkin' more openin'

[cfoushee]

If they were to license it under the GPL that would kill it because all the commerical applications that rely on it would then have to go GPL as well. They would have to use something more like the LGPL or the apache license model so that commerical appication can leverage off it and still have their own licensing.

Re:Less talkin' more openin'

[BrainInAJar]

More likely, Sun will make the source CDDL like the rest of their free-software (and hardware :) ) offerings

Re:Less talkin' more openin'

[Anonymous Coward]

meh, java will still suck open-source or not

it has no purpose. you have to compile it but it's not as fast as a native language. you have to compile it so it's not as flexible as a scripting language. it loses on all fronts.

arguably it's also too object orieneted (the death of smalltalk as well). a good language allows you to program cleanly in various styles so you can make the most of your algorithms.

Re:Less talkin' more openin'

[briansmith]

The commercial users would just license it under the existing (non-GPL) terms instead of the GPL, like they do already. This would be similar to how MySQL is licensed.

Re:Less talkin' more openin'

[penguin-collective]

If they were to license it under the GPL that would kill it because all the commerical applications that rely on it would then have to go GPL as well.

No, not at all. There are many cases in which a runtime and compiler are GPL, but allow commercial applications to run on them.

Re:Less talkin' more openin'

[aCapitalist]

They would have to use something more like the LGPL or the apache license model so that commerical appication can leverage off it and still have their own licensing.

You can forget about LGPL too. There are huge numbers of corporate lawyers who immediately axe using any software that has any kind of GPL license.

No dates, no places, no timetable...

[Anonymous Coward]

but some more comment here:

http://computerworld.co.nz/news.nsf/news/EE511308E E9AA6A7CC257170006C0371

You can't prevent it.

[mungtor]

That's why they have resisted it for so long. Now it will just be one more thing where there are sneaky, annoying inconsistencies between distributions. Nothing will be "broken", but things will end up being implemented slighly differenty and some portability will be lost.

I guess it doesn't *have* to happen, but there seem to be more than enough people that want to take Java away from Sun that it's inevitable.

Re:You can't prevent it.

[Anonymous Coward]

If java goes GPL, there is no reason to take it away from sun.

Also, significant forks are unlikely for such a large project. Only small projects can take getting forked left and right, but with a large body of source code the amount of people required to actually get anywhere with a fork is too large for it to happen without a very good and powerful reason.

Sun will remain the center of gravity for java GPL or no. Because that's where the action will be.

Re:You can't prevent it.

[DragonWriter]

That's why they have resisted it for so long. Now it will just be one more thing where there are sneaky, annoying inconsistencies between distributions. Nothing will be "broken", but things will end up being implemented slighly differenty and some portability will be lost.

But that's already potentially happening; there are OSS Java implementations already, the only guarantee of consistency with Sun's standard is the attention to detail of the OSS community. Any threat Sun faces from forking its code (whether elsewhere in the community or by big players like Microsoft) is already a danger, as the existing OSS java code can be forked. Open sourcing its own Java implementation may be the best way for Sun to manage those risks, which are past the point where Sun could prevent them from existing, anyway.

Huh?

[WgT2]

*picks jaw off floor*

Must be trying to keep up with the times.

Re:Huh?

[dgatwood]

Well, for one thing, it is slower than native code. For another, its garbage collection has a tendency to result in really bad performance stalls, making it useless for anything involving real-time (eve soft real-time) performance. So it's worse than just about anything other than scripting languages in that regard.

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, making it not much more OS-independent than C when it comes to open source development. The result is that any apps that are very complex at all will utterly fail to "run anywhere".

For another, there is little incentive to ship a single binary for multiple hardware platforms. The extra overhead of building a binary for another platform is negligible once you get past the OS-dependent stuff (which Java for the most part fails to solve). If you have to do extra work for each platform anyway, you're 80% of the way to doing it right....

Next, Java generally fails to result in apps that match the native OS look and feel, so Java apps tend to seem very foreign on any platform on which you run them. They don't integrate well with other apps, don't do a good job of supporting OS services, etc. This makes them far less ideal from a UI perspective than writing in C/C++. With C and C++, assuming you separate out the interface properly, it is possible to write an app in which the vast majority of code is shared across platforms, but the UI portions are per-platform. This allows much tighter platform integration for a relatively small amount of effort. You just can't do that sort of thing with Java in any practical way.

Finally, Java makes it hard to add debug functionality into your code without a performance hit. You can do this trivially in C with #ifdef code that makes the debug code fall out entirely. All you can do in Java is run-time testing, which hurts performance. The more debug code, the bigger the hit.

The bottom line is that pretty much any compiled language has great advantages over Java. Platform independence was made out to be the be all and end all of software design, but it turns out that most people would rather have software that runs well than have software that runs everywhere.

Re:Huh?

[Anonymous Coward]

>Finally, Java makes it hard to add debug functionality
>into your code without a performance hit.

You are utterly clueless about Java. Log4j: if(_log.isDebugEnabled()) _log.("tiny hit on this");

Re:Huh?

[Anonymous Coward]

The bottom line is that pretty much any compiled language has great advantages over Java. Platform independence was made out to be the be all and end all of software design, but it turns out that most people would rather have software that runs well than have software that runs everywhere.

Allow me to disagree, and to provide an example that shows that lots of other people disagree too:

MS Windows

It hasn't run all that well until quite recently, and it runs on commodity hardware.

Lots of people would rather have something that works pretty well and Is Available Now over something that will be better than sliced bread in a year or two. That's not quite the point you make, but it's related:

You can develope some app once and deploy it on every reasonably modern OS out there, or you can make 2+ related apps which are seldom released at the same time. When was the last time MSOffice was in sync on Windows and Mac (I don't know)?

Coming up with an app that "runs well" and takes advantage of a multiple OSs' features is considerably more work than the alternative.

OTOH, I fully agree with your garbage collection performance complaint. I see that as the main reason action games haven't really got off the ground in Java... performance is important, and cannot be relied on. You can TBS and match-3 all day, but the moment you try to get a reliable frame rate, you're toast.

--Mark

Re:Huh?

[AKAImBatman]

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.

Re:Huh?

[JustinKSU]

>Finally, Java makes it hard to add debug functionality
>into your code without a performance hit.

You are utterly clueless about Java. Log4j: if(_log.isDebugEnabled()) _log.("tiny hit on this");

His point is that that is a runtime check. While the application is running it has to ask LOG4J the question "Am I in DEBUG mode?" This takes takes a few cycles to check the variable in memory to see what debug level we are in.

On the other hand the with C you can put #ifdef statements in code to tell the compiler to completely include or exclude sections of code based on a compile time variable. This increases the efficiency of non-debug builds because no runtime checks are made.

The disadvantage of the second approach is that you have to have separate builds for debug and production versions, whereas with LOG4J you can dynamically change the level using a config file. You might even be able to change the logging level at runtime* (not sure about this, but I don't see why not).

The guys over in Apache claim that debug level check's "cost is typically in the 5 to 50 nanosecond range" This being the case, it's really a non-issue IMHO. But I do believe the original poster knows what he is talking about.

~Justin

Re:Huh?

[Anonymous Coward]

Generally hate this method of responding, but here goes:

Well, for one thing, it is slower than native code

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.

For another, its garbage collection has a tendency to result in really bad performance stalls, making it useless for anything involving real-time (eve soft real-time) performance

Hence the reason for the related JSR and Sun's implementation.

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, making it not much more OS-independent than C when it comes to open source development. The result is that any apps that are very complex at all will utterly fail to "run anywhere".

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.

For another, there is little incentive to ship a single binary for multiple hardware platforms. The extra overhead of building a binary for another platform is negligible once you get past the OS-dependent stuff (which Java for the most part fails to solve). If you have to do extra work for each platform anyway, you're 80% of the way to doing it right....

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.

Next, Java generally fails to result in apps that match the native OS look and feel, so Java apps tend to seem very foreign on any platform on which you run them.

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.

They don't integrate well with other apps, don't do a good job of supporting OS services, etc

Not quite sure what you mean there.

With C and C++, assuming you separate out the interface properly, it is possible to write an app in which the vast majority of code is shared across platforms, but the UI portions are per-platform.

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.

This allows much tighter platform integration for a relatively small amount of effort. You just can't do that sort of thing with Java in any practical way.

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. You can do this trivially in C with #ifdef code that makes the debug code fall out entirely. All you can do in Java is run-time testing, which hurts performance. The more debug code,

Re:Huh?

[jeks]

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:

static final boolean asserts = ... ; // false to eliminate asserts

if (asserts) assert <expr> ;

Re:Huh?

[Serpent Mage]

I can't believe I'm about to defend java. It is sort of like shooting yourself in the foot but I really can't let this fud go on either.

Well, for one thing, it is slower than native code.
This myth has long since been dispelled. The java language compiled code running on a running virtual machine has actually proven to have faster startup/take down time, more efficient code executions, and oh thats right runs FASTER then compiled native code. Why you ask, simple. The virtual machine is architecturally specific and the virtual machine knows to reoptimize code at runtime to take advantage of your specific architecture. Native compiled code on the other hand are often compiled for the lowest common denominator and/or require a lot of extra work and instability in many cases when trying to optimize towards a specific architecture.

its garbage collection has a tendency to result in really bad performance stalls
More fud. There are many optimized routines used by the garbage collectors these days that it results in practically no stalls what so ever. Why do you think most of the fortune 500 companies use JAVA based webservers like WebLogic and SunOne and such. You don't think that there is a ton of garbage generated by 1000's upon 1000's of rapid connections slamming a webserver?

So it's worse than just about anything other than scripting languages in that regard.
You really should learn the difference between a scripting language and an enterprise grade industrial programming language. I'm so shocked by this comment that I am left speachless that anyone could even make such a ludicrous comment.

Java generally fails to result in apps that match the native OS look and feel
Swing yes. AWT perhaps yes and no. It does match the native OS look and feel but yes it does have a few issues. the SWT toolkit however is well undeniably native cause well it is actual native OS toolkits. Several examples you should look at ... eclipse and azerus stand out off the top of my head as the best examples of COMPLEX guis that take advantage of the native os features, looks, and feel.

which means that there are all these OS-specific extensions to add things like audio support
Um ... audio support is not an os-specific extension. It comes as part of the standard runtime environment.

Java makes it hard to add debug functionality into your code without a performance hit.
Again not at all true. In fact I make use of this many times. The logging api even allows you to set debug specific configurations on a class by class level so you could have portions of the code in debug mode and at any point in time dynamically change all that WITHOUT taking a performance hit. News flash, if (logger.isDebugEnabled()) { /* do code */ } is NOT any kind of performance hit at all. It is actually invaluablly more useful in enterprise grade applications where PEFORMANCE is critical because it also allows you the ability to introspectively examine the application internals.

The bottom line is that pretty much any compiled language has great advantages over Java.
Total load of crap. Java has the 1 great advantage that it is faster, more stable, more efficient code production capability for any kind of real application. You can without a shadow of a doubt produce more code, faster, and more stable in less time with Java then you can with your other compiled languages.

Re:Huh?

[fimbulvetr]

It has been false for years now. Ever since Chris Rijk published his earth shattering benchmarks.
Give me one example of a well known basic java gui application that is as responsive as any give kde/gnome app, takes a modest amount of memory and is bug free enough to use basic features, and I will change my opinion about java from "Memory hungry, bug ridden, slow, incompatible with itself, bloated piece of shit" to some thing maybe a point or two higher. No piece of java software I've ever run has impressed me. From proprietary java software I use at work to applets on the web, azureus, eclipse, limewire, oracle's applications, and the hundreds of apache tomcat/ant/jboss environments I used to setup and host for customers, I have never seen any java application where I've just said "Wow, that just worked.".

Those benchmarks are next to useless. I'm not saying they're wrong, I just don't see java performing better or even on par with other applications I use.

Re:Huh?

[Anonymous Coward]

I don't think this sort of hype helps anyone. The Java code generation story is indeed solid (although the toy benchmarks you cite are meaningless). The real issue is garbage collection. It requires around 3 times more memory (or 7 times more) than explicit memory management to achieve equivalent performance -- less memory means more garbage collections. Unfortunately, more memory means longer pauses. Worse, if physical memory runs short, it's a paging disaster (although this can be fixed). Java - and garbage collection - are great technologies, but it's important to acknowledge their limitations (and try to address them).

Re:Huh?

[rpdillon]

If you cannot space the cycles, simply use assertions. They do not cost anything at runtime.

Re:Huh?

[Zontar The Mindless]

...I have never seen any java application where I've just said "Wow, that just worked."

Well, that is exactly what I said when I found oXygenXML.

It's a damn fine XML editor (and a bunch of other things handy for working with XML). I use it every single day in my job, which involves lots of writing, updating, validating, and transforming monstro-DocBook XML files. A couple of my teammates and I went into absolute hysterics when we found it, because it Does What We Need It To Do, does it fairly quickly and painlessly, and it does it on *nix, Windows, and OS X.

I still can't believe it's a Java app sometimes.

Re:Huh?

[Anonymous Coward]

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.

Re:Huh?

[dgatwood]

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 is provably true. The proof is trivial, in fact. Java is non-native bytecode. Therefore, at some point in time, that bytecode must be translated. This takes time. Therefore, unless that translation generates dramatically better-optimized code than the compiler toolchain, performance is, by definition, slower, and even if the code -is- dramatically better-optimized code, for a short execution, execution will generally take longer. Now you can either take that translation hit up front or during execution. You can cache the native code so you only have to translate it once. Regardless, you still pay that penalty, which is still provably a loss of time. No amount of benchmarking can disprove that.

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.

Audio input wasn't added until 1.3. We're only talking about five years for something I could do on an Apple II in the mid 1980s. That's a pretty basic feature which has been common in the computer world as long as I can remember. At that rate, by the time there's a way to interface with (Mac OS X) spotlight searching or (Linux) Xrender transparency in Java, I'll probably be retired.

They don't integrate well with other apps, don't do a good job of supporting OS services, etc.

Psst!

Care to elaborate on that? Even if the specific example of audio was a bit out of date, the point still remains that it is a separate development environment, which means that it is always trailing way behind the state of the art. Since few OS services are bridged except those that are fully cross-platform, a Java app cannot fully take advantage of the latest technologies in any OS. Jack of all trades, master of none.

Re:Huh?

[AKAImBatman]

Good point! The assert facility slipped my mind. (Not something I use often.) :-)

Re:Huh?

[Anonymous Coward]

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.

"Oops, sorry, I was wrong, my mistake."

Well, at least *somebody* says it around here!

Re:Huh?

[ThatFunkyMunki]

Azureus. http://azureus.sf.net/link

Re:Huh?

[owlstead]

"It is provably true. The proof is trivial, in fact. Java is non-native bytecode. Therefore, at some point in time, that bytecode must be translated. This takes time."

That may be, but if you acquire information while the code is running, then you may be able to speed things up a bit. Normally, natively compiled code does not do that. Besides that, this is all theoratically speaking. The same argument was used against C: anything you did should be slower than assembly, no? It turned out that compilers won from assembly most of the time: computers are much better in following guidelines and testing for optimum performance than users are.

Besides that, I would not mind spending a bit of time for added reliability and security on 90% of my applications.

"Since few OS services are bridged except those that are fully cross-platform, a Java app cannot fully take advantage of the latest technologies in any OS."

That depends. Some things are enabled automatically. But one of the main points is write-once, run-anywhere. Sure, you can get out of that using JNI, but you may have to rewrite certain bits. On the other hand, how do you know that an application that you write runs smoothly on another machine if you used C++? What if it is an older machine?

In my opinion, the main advantages of Java are the simplicity of the language, the well-documented and largely very understandable API, the availability of a very large repository of usefull components (check out Apache!), the inherent security architecture...the list goes on. Even if you were 100% right on the previous two points, there is enough merit in Java to take it seriously. And if you look at the penetration rate of Java, well, it's HUGE. Mobile phones, smart cards, TIVO's, blu-ray will use Java, embedded devices and of course many businesses that take security and reliability seriously.

Re:Huh?

[Anonymous Coward]

Mod parent up. That's more accurate than the fanboy grandparent post.

Re:Huh?

[Notrace]

Even better: The Eclipse plugin for OxygenXML ... :-)

Re:Huh?

[corvair2k1]

It is provably true. The proof is trivial, in fact. Java is non-native bytecode.

Ok, sounds good so far...

Therefore, at some point in time, that bytecode must be translated. This takes time.

Uh huh, uh huh... Sounds reasonable

Therefore, unless that translation generates dramatically better-optimized code than the compiler toolchain, performance is, by definition, slower, and even if the code -is- dramatically better-optimized code, for a short execution, execution will generally take longer.

This is a true argument. For short programs, startup time is a factor with the Java Virtual Machine. However, you also need to mention that, if your program's that short, does it really make a difference if it takes .01 or .21 seconds to complete?

Furthermore, you seem to have completely written off the fact that the code is not going to have better optimizations than the machine code produced by a C compiler. Java actually has the advantage here, because some optimizations cannot be performed statically (as a C compiler would have to do).

Now you can either take that translation hit up front or during execution. You can cache the native code so you only have to translate it once. Regardless, you still pay that penalty, which is still provably a loss of time. No amount of benchmarking can disprove that.

Sorry, but it's not Q.E.D. Besides, if a fair benchmark is showing Java as faster... Wouldn't you want to question your interpretation, instead of holding your fingers in your ears and repeating "My theory says Java can't be faster!"?

Re:Huh?

[Walles]

Compiler researchers have known for years there is an order of magnitude difference between native and interpreted code across the board.

Considering JRockit compiles all code into machine code before running it, that's a non-argument.

Everybody knows that going by car is faster than walking. That doesn't imply that some car is necessarily faster than some other.

Likewise, everybody knows that native code is faster than interpreted. That doesn't mean that gcc's native code is necessarily faster than JRockit's. Yet, that's the argument you're making above if I understand you correctly.

Re:Huh?

[master_p]

How nice to read your post the same day we decided to use a native lib for image manipulation, effects and display for one of our apps! because Java's libs were VERY SLOW...

Re:Huh?

[petermgreen]

Ever since Chris Rijk published his earth shattering [aceshardware.com] benchmarks.
lets take a look at his results then.

in the non infinite life ones the best C result beats the best java result every time.

In the infinite life one C does a lot worse.

In the fibonachi numbers test java clearly wins.

In the fft test the results are all over the place.

So the answer is for tight number crunching work java and C are comparable. For retarded use of reccursion (the fibbonachi test) java clearly wins.

For memory allocation java is by default better than C (especially GCC) BUT a good coder has far more chance to optimise in C. I bet if "set = (int*)malloc(4*sizeof(int));" was replaced by a custom cache of fixed size blocks things would speed up big time. In java every object gets its own block on the heap and theres nothing you can do about it. It gets even worse if you wan't an array of structures (i didn't notice any of theese in his tests) as java forces you to put every element of the array in a seperate block on the heap.

He also didn't make much use of the standard libraries many of which suck, though they are admittedly getting better nowadays. There are also a lot of gotchas from the way the JVM optimises (for example the performance of direct bytebuffers will plummet if non direct bytebuffers are used in the same VM).

So to summerise: In terms of actual execution of code its a toss up, In terms of memory allocation it depends if the coder can be bothered to optimise. In terms of standard libraries its pretty damn poor and in terms of startup time its barely acceptable especially the first time you start a java app after boot. I'd say java loses in the overall performace stakes even though its certainly possible to make benchmarks that it wins.

Re:Huh?

[Anonymous Coward]

Rijk's results were incredible for their time. However, time has marched on and Java has gotten even faster. If you look at the second benchmark he posted (which is already 4 years old!) Java did even better than it did in Rijk's benchmarks.

There's further dicussion on the topic at this link.

Re:Huh?

[petermgreen]

yeah theres been some more tweaking but overall the same problems still persist. In mustang for example they are planning to "fix" the bytebuffer issue by adding special optimisations for bimorphic classes. but afaict it will still slow to a crawl if unrelated code decides to create its own bytebuffer descendents.

Once code is written i don't expect changing another part of the app to radically effect its performance like that.

And to take one of the articles examples why isn't the vector class marked as deprecated so people know its a performance killer?

Also the pointers issue is way overblown. An array will never point to anything other than the array so thats a non-issue from an optimisers point of view and a pointer can only (legitimately) modify a local variable if a pointer has been taken from that local variable (this is an issue with reference perameters but then java forces you to use objects for those which isn't the pinnicle of efficiancy either).

Java can perform as well as or even better than C provided:
1: The app is fairly long running and/or something else on the system has already brought the VM into disk cache.
2: The C app follows the same stupid design patterns (such as overuse of the allocator) that java forces you into (this is one big issue with comparative benchmarks, the C code seems to have been written by someone who either wasn't bothering about performance or was trying to make the code as close to the java version as possible).
3: The C app doesn't use inline assembler for critical sections or the inline assembler is done badly.
4: The Java app either avoids the standard libraries completely in anything remotely critical or uses only those bits that were written by someone with a clue about performance.

Re:Huh?

[Anonymous Coward]

slow Java. heh.
http://chromethegame.com/en/show.php?003

slow'n'lazy porogrammers, now, that's ...
umm...
me? ;P

Re:Huh?

[Anonymous Coward]

The Sun JVM was mentioned by name. There are many, many JVMs out there by many different people. Including many embedded Java JVMs and even realtime ones used in robotics.

While there are many native Java compilers out there, including GCC, they are not highly optimized nor fully featured it seems. GCJ at this time barely matches the Sun JVM which just goes to show how a native app could perform as poorly as an interpreted one. But in the general case optimized native code performs one order of magnitude better than interpreted code. For that matter, Sun's own HotSpot JVM has contained a JIT compiler since JDK 1.3. So you must consider even Java is cheating a little.

Even when compiled to native code, though, Java must still behave like Java. Which means it retains some of its "interpretedness" behind the scenes. Things like Java's implementation of reflection and dynamic class loading prevents some more aggressive native optimizations.

loooong

[Anonymous Coward]

This is going to be one loong /. discussion.

Especialy the "I told you so" parts :)

Hey, Look!!!

[adminsr]

Free Beer!!!!!!!

Re:Not such big news after all...

[s31523]

Come on now.. I see java all over the web, so I guess the answer to who cares would be a lot! Even in this here Slashdot page, I see the java tag used all over the source code for this page.

C'mon Jeanie! *Please* get back in your bottle!

[pla]

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...

Don't release the source code.


Oops.

Re:Not such big news after all...

[Anonymous Coward]

Really, who cares about Java any more?

Just about everyone except you.

I can't believe anyone modded this troll up. Isn't the fact that he's posting at +0 a tipoff to anyone?

How to prevent forking and fragmentation

[gronofer]

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.

Re:How to prevent forking and fragmentation

[Anonymous Coward]

Agreed. For a fork to steal Suns thunder it needs to attract users and developers, which means it must offer significant advantages, which means it must have developers working on those features. Catch 22-ish.

Without serious missmanagment on suns part, no fork will be able to compete enough to even muddy the waters.

Re:How to prevent forking and fragmentation

[Anonymous Coward]

Well said. If Sun allows enough good changes into their source. a fork will be unnecessary. And if they use a GPL-like licence, nobody can redistribute their changes without allowing Sun to use them as well. That means they will never be beaten in competition unless they decide to be stupid and not listen to their user base.

Re:How to prevent forking and fragmentation

[SpinJaunt]

If Sun is doing a reasonable job maintaining the source code

That is EXACTLY the only probable cause of a fork, as long as Sun can continue make the best available version of Java.

The only downside to a fork is the Java trademark. Sure I can live with a Java-compatible fork, but how confusing will it be for others (the non-technically inclined) when all they want is a Java that just "works the way it used".

Re:How to prevent forking and fragmentation

[Yaztromo]

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.

That presumes that there isn't an 800lbs. gorilla sitting in the next room just plotting to catch you unaware and clobber you.

In the current OSS world, there is a sort of agreed upon level of friendliness between projects. Projects may compete, but they also cooperate, and everyone is more focussed on creating the best project they can, and not just trying to kill off the other guy.

Microsoft, however, is a business -- and their business has always been to kill off (or buy out) their competition. Playing fair doesn't figure into the equation. They control the platform that 90+% of users are running on their desks, and they control a LOT of developers, both inside and outside Microsoft (and we've all met the type -- the developer who is so sold on using all Microsoft technologies, they'll use a poor solution and write 200 lines of code to do what you could do in 6 lines of code in another, non-MS environment, just because their solution is based on Microsoft technologies).

So how is this for a scenario: Microsoft comes out with a new release of Visual J++.NET based on Open Source Java, but changes the bytecode generated subtly to make it incompatible with other JVMs (or, perhaps worse, decides to add a few of their own keywords to the language, and ties them directly into Windows-specific APIs). They don't call it Java -- they call it "Visual J++.NET", however the pro-Microsoft developer probably already associates "J++" with (what they think of as) "Java", and decides to use it for all of their Java development.

Suddenly the Java world is flooded with code that only works on MS VMs. Microsoft winds up controlling a huge percentage of the Java developers of the world, and can start dictating the Java APIs and features developers use (as they can just start sticking whatever they want into their implementation, and as they have a huge army of 3rd party developers who will start using these features, the rest of the Java world has a choice: either implement the new MS features into the VMs on other platforms, or try to maintain Java purity and lock themselves out of a lot of applications developed on Windows, and create confusion for end-users by requiring them to have two competing VMs installed on their systems).

MS could also start bundling their modified VM with each and every Windows machine. When a desktop user encounters a "pure" Java application that they can't run, they'll either demand from developers versions of these applications which are specifically designed for the MS VM, or simply won't use these applications. This will be especially bad for things like applets and Java WebStart.

I can see all sorts of ways this could be bad for Java (and Sun). Unfortunately, Sun can't maintain the status quo either: they're losing ground in the Windows world (and it could be argued they never had a lot to begin with: while I'm sure there are a lot of Java developers on Windows, outside of some server-side stuff there really isn't a lot to like about actually running Java applications on Windows), and need the Open Source Linux world no their side in a big way. Sun would be fine if it wasn't for the fact that there are so many developers out there sold so completely on the "One Microsoft Way" when it comes to development tools and environments -- Microsoft has a stranglehold on a lot of devs out there, and those devs don't care about MS's dirty tactics so long as they have a huge captive audience to sell solutions to.

Yaz.

Re:How to prevent forking and fragmentation

[gronofer]

I think this concern is outdated. Now that Microsoft have .NET they are hardly likely to put much effort into Java.

I think even at the time such problems could have been avoided by releasing Java with a GPL licence. Most likely Microsoft simply wouldn't have touched it on those terms. Any changes they made would have been available to anyone in any case. Even if the "market decided" to prefer Microsoft's version over Sun's, it's would hardly have been the end of Java.

Now with a dominant .NET on the other hand, what would be Sun's position in the desktop computing world? The supplier of a browser plugin for use by a few legacy web games.

Re:How to prevent forking and fragmentation

[Yaztromo]

I think this concern is outdated. Now that Microsoft have .NET they are hardly likely to put much effort into Java.

I continue to disagree. Microsoft would simply co-opt the OSS Java code into the .NET framework.

They may be concentrating on .NET, but that doesn't mean they don't have an interest in driving people away from Java and into the .NET fold. Such a move could achieve both -- merge OSS Java into .NET, push MS-only developers into using it and pushing it at everyone else, and suddenly mainline Java is forced to accept Microsoft modifications. Before long, OSS Java is simply a shim into .NET, and Java becomes meaningless.

Yaz.

Re:Oh, dear lord

[__aaclcg7560]

That would explain why the lines are long at Starbucks... the employees drink Java. As long as they get the whip cream in with my grande mocha, I really don't care.

Re:Not such big news after all...

[__aavhli5779]

Slashcode is written in Perl.

Change the title

[clevelandguru]

The title should read "Sun to Open Source Java". The source code has been available for a long time.

Forking

[Anonymous Coward]

A SABDFL is the answer. I don't think any fork of the Linux Kernel is very popular, thanks to Linus

Huh?

[Bill, Shooter of Bul]

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?

All true.

[James A. V. Joyce]

To be frank, I'd rather Sun hadn't open sourced Java, because that would probably reduce its (admittedly already very poor) uptake still more. As you can tell, I'm not a big fan. In trying to overcome the disadvantages of both compiled and interpreted languages, it actually incorporates them all: 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, which is inadequate for the majority of I/O intensive operations. The list goes on and on.

Re:All true.

[mypalmike]

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, which is inadequate for the majority of I/O intensive operations. The list goes on and on.

While the following benchmarks are somewhat biased, they fairly reflect the speed of the previous generation of Sun's JVM. The latest one (5.0) improves upon this.

http://kano.net/javabench/

Java's not the perfect tool for everything, but in my experience, it's great for making server applications that need to be reliable, maintainable, and fast, in that order. This is roughly the order in which many businesses need their software to be.

Re:All true.

[Anonymous Coward]

... Java['s] (admittedly already very poor) uptake ...

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.

Re:All true.

[kent.dickey]

I can't keep track of the dates of each benchmark being run at the kano.net site, but you should visit: http://www.freewebs.com/godaves/javabench_revisite d/. They say some of the Java benchmarks are flawed, and once they are made more fair to C++ (i.e., not being unfair in major ways), then C++ does much better. As in, C++ almost always beats Java.

Benchmarking is easy to do wrong, and if you're getting unusual results, you may want to look into it closely.

Trademark usage.

[Anonymous Coward]

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.

Re:Trademark usage.

[magicjava]

That's how Java works already. You can change the source however you want. You can distribute those changes. You just can't call your changes "Java" unless you get certified.

Re:Trademark usage.

[Anonymous Coward]

Because if everybody starts forking java and introducing minor incompatabilities your gonna see an issue like what happened with the Microsoft VM for java. Where programs compiled for one won't work on another system... This would dilute and potentially hurt java acceptace big time if the whole write once, run anywhere concept got broken.

What Sun has to ensure is that the core of Java is NOT forked to death and helps maintain the continuity of Java, fragmentation and rampant forking would only hurt it, even if you implement "licenced" java trademark the unlicenced ones would cause a bit of chaos.

Re:Trademark usage.

[DragonWriter]

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.

One thing that limits the ability of Sun to do this is the existence of "fair use" in trademark law, which is less well-known among most people, I think, than copyright fair use. Particularly relevant is the opportunity for nominative "fair use", which would let people advertise the fact that their product (which couldn't be named "Java" as a marketted product), was designed to run Java software.

Re:Trademark usage.

[Dunbal]

provide feedback on how to best get there and prevent forking and fragmentation.

      What they fail to realize is that once they let the source code go, there is no way to prevent anything at all. That's what freedom is about. Or is it that they think they can put it "partially" in the public domain and still retain some control?

      Sorry Sun, it's all or nothing here.

Re:Trademark usage.

[MemoryDragon]

That already is done that way, every JDK which calls itself java has to pass several million compliance tests. It works pretty well with every java related official api, and there already has been a coexistence of various apis that way. Tomcat for instance being an offical servlet runner, JBoss an official JEE Server and MyFaces as compliant JSF 1.1 implementation. I dont know the plans of Sun, but probably it will be resolved that way.

Re:Trademark usage.

[thomas.galvin]

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.

Java has two big things going for it: productivity, due to lessons learned from years of fighting with C++'s syntax, and general platform neutrality. Sun's biggest fear is that the first will be separated from the second.

The big push behind a lot of the toolkits, et al, that have been released in the last couple of years is "make Microsoft irrelevant." That's what Google is doing now, with its push towards web services. It's what Netscape tried to do with its platform. And it's what Sun tried, and to an extent is still trying, with Java.

For ages, Microsoft has owned "the" platform, so if you wanted to develop an application, you pretty much had to play by their rules, and, via the power of positive feedback, if you wanted to use an application, you pretty much has to be on Microsoft's platform. Platform neutral environments change the game, and that is why Google, Sun, etc are so interested in them, and why Microsoft is so afraid of them.

Now, let's say Sun releases Java as an open source package. Microsoft then makes a bunch of extremely useful enhancements to the language, but somehow manages to tie them to the Windows API. They're still technically open source, but useless unless you're running Vista. It calls this enhanced language "Lava" and tosses it at the developers.

Will being tied to Windows prevent people from using this language? Yes, some of them. But some of them will say "hey, I'm still reaching 90% of the world, so who cares?" and happily adopt Lava. That's a true fork in the language, and a realization of Sun's biggest fear: someone, particularly a competitor, benefiting from all of Sun's hard work, but not contributing to the community in any real way, and holding up their own incompatible language as the "real" future of Java. Er, Lava.

Re:Trademark usage.

[Anonymous Coward]

>>
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.

Great idea, that also worked really well for this obscure clone called "Linux" .... oh, wait

no way!

[NanoWires]

no way! Hell froze over

You want to prevent forking?

[Trigun]

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.

Re:You want to prevent forking?

[magicjava]

No offense to Perl fans out there, but Perl doesn't have a Microsoft and and IBM trying to purposely introduce incompatable forks.

Making Java open source, in the sense of a GPL or similar license, will kill Java.

Re:You want to prevent forking?

[Anonymous Coward]

Making Java open source, in the sense of a GPL or similar license, will kill Java.

Considering GCJ/Classpath is around, why isn't Java dead yet?

Re:You want to prevent forking?

[Arandir]

On the other hand, there are a ton of forks off of Mozilla.

Re:You want to prevent forking?

[blamanj]

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.

Re:You want to prevent forking?

[DragonWriter]

As there are already OSS Java implementations, which can already be forked, all Sun does by not going open source is reduce their own ability (given the viral nature of the OS licenses involved) to embrace a threatening fork before it becomes so divergent and well-established that it splits the user base badly.

Further, having the gold-standard implementation open to the community might present Java with a competitive advantage over .NET (which has a multiplatform OSS implementation, too); and the risk from .NET is probably a bigger threat to Sun's relevance than any Java fork.

Re:You want to prevent forking?

[Anonymous Coward]

GCJ is a fork to the extent that some developers are opposed to standard Java features that GCJ doesn't support (ie Swing).

Re:You want to prevent forking?

[Anonymous Coward]

Considering GCJ/Classpath is around, why isn't Java dead yet?

Did IBM or MS backed up GCJ/Classpath?

Re:You want to prevent forking?

[nuzak]

> Making Java open source, in the sense of a GPL or similar license, will kill Java.

Then it deserves to die. This is not Uncle Joe-Bob's job going south to NAFTA, so what on earth inspires such protectionist claptrap for Java's sake? This is code. Evolve or die.

Microsoft has .NET and doesn't give a fig about being kicked around by the Java crowd anymore. There's even IKVM for when you still want Java. As for IBM, what was their unpardonable crime? Writing a new toolkit? That they didn't gobble down the dog's breakfast that was Swing and demand seconds?

Re:You want to prevent forking?

[Bob9113]

And standing behind them also means listening to them, even the ideas that you don't like.

Hear Hear! Where's my "javac -autobox=warn" and "javac -autobox=no"? That's the first thing I'm going to do if they make it legal to modify. JCP response was slightly less diplomatic than, "No." Is Long.valueOf( myPrimitive ) really so hard that they had to make it impossible for me to prevent autoboxing?!? /rant. Everything else in Tiger is awesome.

Re:You want to prevent forking?

[the eric conspiracy]

That is nothing. How about Java with destructors and a sizeof method.

Re:You want to prevent forking?

[Bob9113]

How about Java with destructors

finalize isn't good enough? I know it's not guaranteed to run, but I think it only fails to run if you kick the plug out of the wall or kill -9. Do C++ destructors run when you kill -9? How does finalize miss the mark? (genuinely curious to learn more)

and a sizeof method

Now there's one I can get behind. There is at least one good OSS library out there for doing it though. Reply if you want it, I'll dig up a link.

Re:You want to prevent forking?

[the eric conspiracy]

If finalize was good enough you wouldn't have GenericServlet.destroy().

Re:You want to prevent forking?

[Bob9113]

If finalize was good enough you wouldn't have GenericServlet.destroy().

Servlet.destroy() is for instances that are not being GC'd (ie: finalize will not be called - but if you followed the same design, nor would destroy be called in C++). It is called when they are taken out of the front line because they haven't been called in a while. Finalize works with servlets, it just doesn't get called until the servlet engine is shut down. Servlet.destroy() is specific to servlets because servlet engines create one instance of the servlet at engine start and keep it for the life of the engine. Servlet.init() and Servlet.destroy() are not like ctors and dtors in C++, they are to enable servlets (which are singleton) to have allocation and deallocation during the singleton's tansition to/from service.

C++ could have an equivalent of Servlet.destroy() too. If you wrote a C++ service engine, which supported singleton service handlers, it would actually make a lot of sense for your engine to have methods equivalent to Servlet.init() and Servlet.destroy(). Of course, you'd want to name it something other than destroy() - maybe finalize() just to be funny :)

Also, you can make finalize() come into play with servlets by having each service call construct an instance of some ServiceHandler class that takes a Request and Response, and goes out of scope at the end of the service call (whence it will be GC'd and finalized). Write ServiceHandler.finalize() and you're good to go.

Or are you just saying you don't like the GC controlling when finalize is called - that you don't want a GC at all for your application? If that's the case, then, umm, don't use Java. It's not the right tool for apps that need fine-grained control of memory deallocation. Open Sourcing Java won't change that - the GC is pretty fundamental to the way Java code is meant to be written. The GC is an intentional trade-off, like Perl's lack of type safety. Java without the GC wouldn't be Java.

Re:You want to prevent forking?

[oreaq]

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 could also argue that a major fork is just happening, SWT vs Swing. And it sucks.

Re:You want to prevent forking?

[Listen Up]

You obviously do not develop in an enterprise environment. Java and specifically J2EE currently commands between 95%-99% of the enterprise computing market with 1%-5% being commanded by other technologies such as .NET. The truth is that the major computing world doesn't give a damn about .NET and are building more and more Java infrastructure at a feverish pace. Microsoft does give a damn about Java and is working very hard to convince people of any advantage to .NET.

Sun's relationship and history with IBM is much more complex than you appear to understand.

You can only use the term "Java" if you pass tests

[geoffrobinson]

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?

Re:Not such big news after all...

[Peter Trepan]

IANAP(rogrammer), but I can see how it would make a variety of things possible within the open source community.

For instance, if one knows exactly how Java works, one should be able to make code intended for a Java VM compile into native binaries. That means that every Java app out there, and there are a lot, should be able to run much faster and in native windowing environments within Linux - and that Java code written natively for Linux would also be (somewhat) portable between platforms using VMs.

Again, I'm not a programmer, so someone correct me if I'm wrong.

Re:Not such big news after all...

[magicjava]

Again, I'm not a programmer, so someone correct me if I'm wrong.

You're not wrong, but such tools already exist. IMHO, all this will do is lead to incompatible versions of Java.

GPL'ing java would be bad...

[mark-t]

LGPL'd maybe.

But GPL'ing it would create the requirement that every project that used it would also have to be GPL'd because at runtime everything links to its runtime environment.

Which would make the commercial use of Java impractical.

I can't think of a faster way to kill it that to put the GPL on it.

Re:GPL'ing java would be bad...

[Maxmin]

every project that used it would also have to be GPL'd because at runtime everything links to its runtime environment.

Really? You're saying that for applications which link to the Java class libraries, they'll have to be GPL'd as well? I thought that the GPL had an exception for "links-to" versus "extends" or "based-upon."

Re:GPL'ing java would be bad...

[Anonymous Coward]

dual licence

Re:GPL'ing java would be bad...

[Whiney Mac Fanboy]

LGPL'd maybe.

*slaps forehead*

Of course - you're completey correct.

Re:GPL'ing java would be bad...

[AuMatar]

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.

Re:GPL'ing java would be bad...

[Anonymous Coward]

Really? You're saying that for applications which link to the Java class libraries, they'll have to be GPL'd as well? I thought that the GPL had an exception for "links-to" versus "extends" or "based-upon."

You mean LGPL?

Re:GPL'ing java would be bad...

[BrainInAJar]

I thought that the GPL had an exception for "links-to" versus "extends" or "based-upon."

No it doesn't. That's why Stallman himself made glibc LGPL. It's also why you see very few commercial Qt applications ( gtk+ is LGPL, Qt is essentially GPL unless you pay for it)

Re:GPL'ing java would be bad...

[squiggleslash]

No, GPL's fine. It will help prevent a certain type of "embrace and extend" forking.

As far as ensuring the GPL license doesn't leak into applications that run over the Java run-time system, you simply supply an additional, optional, license, that allows for linking code with a pre-built binary distribution of Sun's Java using the published APIs. Developers can choose which they use on a project-by-project basis.

Re:GPL'ing java would be bad...

[mark-t]

You might as well just use the LGPL then.

Re:GPL'ing java would be bad...

[squiggleslash]

No, that wouldn't help at all.

Re:GPL'ing java would be bad...

[codemachine]

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.

Re:GPL'ing java would be bad...

[mark-t]

If they were going to open it up, I think what they SHOULD do is have a clause in it that forbids anyone else from calling a product derived from it Java, or including the term Java in the name of any potential fork. Sun can own the trademark to Java, and easily prohibit anyone else from using the name, even if a product is derived from it. That would allow Sun to retain control over what is recognized as "real Java", and would still give people that want it to be openned up what they want: the source. Meanwhile, Sun is free to incorporate any changes that the community makes into Java and make them official if they so desire (or refuse them, if that's what they want too). Seems like a win-win-win situation for everybody.

Re:GPL'ing java would be bad...

[Overly Critical Guy]

The natural human response to ideas and entertainment is to share them. This is the phenomenon of story-telling.

This has got to be one of the lamest justifications of piracy I've ever read.

Re:GPL'ing java would be bad...

[rohan972]

He didn't mention piracy. Maybe he's advocating changing the laws. IIRC copyright didn't origianlly cover music, for example. Perhaps he believes in the rule of law, and obeys it, but also believes in democracy, so works to change the law. If so, he would be far from the only one to take this stand.

Re:GPL'ing java would be bad...

[Listen Up]

They are control freaks when it comes to their projects.

Why, because Java is Sun's creation and Sun's code? What kind of goddamn whiny communist idiot are you? Sun has spent millions of dollars and man-hours creating Java and if they don't want to let anyone else tell them what to do with it then that is their own damn prerogative. More power to them.

If Sun hadn't been at the reigns for this long, especially with their unparalleled relentless pursuit of a truly platform agnostic programming language, Java would be in a much worse position today.

Re:Not such big news after all...

[Anonymous Coward]

People have been able to see how Java works for quite some time now. You just have to agree to a very restrictive and invasive license that no free software developer would agree to.

My guess is they will release it under CDDL, like OpenSolaris. For all of Sun's idiocy, I appreciate their graceful march to death.

Criteria #1

[TopSpin]

Whatever 'how' you come up with must satisfy one simple criterion: make it possible for the major Linux distributions to include the Sun JVM, runtime (tailored to whatever degree necessary to work well,) and source, in their product.

Re:Oh, dear lord

[Ohreally_factor]

Gee, given your handle, is it any surprise what sort of Java you'd be focused on?

Isn't that just the API?

[Cybert8]

I don't think the VM and compiler apps have been open-sourced.

Re:You can only use the term "Java" if you pass te

[magicjava]

Is there any reason why such an approach wouldn't work?

That approach works great. That's the license they already have.

Just don't break it, please

[mattypants]

Although the source for the reference platform has been available for some time, the fact that it may become 'free' means forks are inevitable, and that's the only thing that's missing from Java, namely the freedom to fork it. Mind you, if the C++ crowd get hold of it that's what it will be... completely forked.

Look at all the shiny forks...

[Anonymous Coward]

Oh, hey Sun, look at all the forks Python has, I mean it's IMPOSSIBLE to code for it because of all the variations and lack of a standards body! Keep fighting this evil demon called Freedom and don't give in!

Get your forks ready....

[cfoushee]

I bet IBM is just foaming at the mouth ready with its fork just ready to scoop up the source code and create some stiff competition of who has best version of java. Look at SWT and eclipse and you'll see just how much they have accomplished without the source code.

Re:Get your forks ready....

[Cereal Box]

IBM already has their own cleanroom JVM. Anyone who HASN'T already seen the Sun JVM source code can write their own JVM (and there are already some opensource ones). It's all just a matter of manpower.

Re:Get your forks ready....

[Decaff]

Look at SWT and eclipse and you'll see just how much they have accomplished without the source code.

Eclipse is OK, but SWT is now a largely discredited waste of time.

Re:Get your forks ready....

[aCapitalist]

Eclipse is OK, but SWT is now a largely discredited waste of time.

That would be true if Swing didn't look like shit. And no, Mustang isn't out yet.

Java and the DISPLAY variable

[Chemkook]

My favorite Java feature is that it works well when you export the DISPLAY.

Some excellent examples of this are
Java in Mozilla, OpenOffice, Veritas NetBackup and UGS TeamCenter products.

I too think that it's important that Java does not get forked.

Oh well, that my 2 cents.

Re:Java and the DISPLAY variable

[frostfreek]

Unless I am missing something, that is a testimony to the X Window System and not Java; Java does not need to know anything about networked displays, but rather it simply needs to use the standard X (and GL) client libraries.

So... your favourite Java feature is something written in C around 25 years ago?

Re:Java and the DISPLAY variable

[Anonymous Coward]

Don't forget that the DISPLAY variable is optional, you don't need a XWindow system.
Have you heard of the -headless=true option?

Re:Java and the DISPLAY variable

[Anonymous Coward]

Don't forget that the DISPLAY variable is optional, you don't need a XWindow system.
Have you heard of the -headless=true option?

So headless operation, without remote display is now your favorite feature? Command line only operation is available in almost every language ever invented. Ever try C or C++?

Re:You can only use the term "Java" if you pass te

[Anonymous Coward]

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.

Actually exactly that can be done with the GPL (though as some rightly pointed out, LGPL or GPL+linking exception is a better idea) or any other license + a trademark. Redhat does exactly that.

Is there any reason why such an approach wouldn't work?

I don't see why it wouldn't, it certainly would prevent the scare of broken Java imlementations, though Sun would have to overcome their fears in that regard.

The Media Is Retarded

[wasabii]

"""A group of developers could split off from the main Java community and form a second, independent group that follows an independent course. This could lead to confusion with developers and cause Java to lose focus.""" Am I the only one tired of hearing nonsense like this? Java has already been forked. Multiple times. There are already open source implementations of both the VM and the base class libraries. These implementations are distributed by default in most big Linux distributions: RedHat, Ubuntu, at least. I know. I started the port of Eclipse 3.0 to Ubuntu/Debian. It runs on GCJ and Kaffe or IKVM. All very high quality *FREE AND OPEN SOURCE* virtual machines. It uses Classpath as it's base class libraries. Exactly what more is there to fear? There are ALREADY other entities out there who have "forked". Why don't most people realize this?

Re:The Media Is Retarded

[magicjava]

Well, if those products are already out there and already open source, how can the OSS flag-wavers claim that Java can't be open-sourced?

How quickly people forget what Microsoft tried to do to Java. The only thing that saved Java was it license agreement.

Re:The Media Is Retarded

[Anonymous Coward]

Yeah, all that shit is a pain. Now to install Java, I have to uninstall all the crap that they call Java, but isn't, and install the real stuff.

Isn't open source wonderful?

Re:The Media Is Retarded

[kaffiene]

Fork != Clean Room Implementation

Re:The Media Is Retarded

[wasabii]

From the markets point of view, they are functionally equivelent.

Re:The Media Is Retarded

[Anonymous Coward]

Indeed. The primary reason I care about Java being re-licensed as a Free system is that I hope it will *cut down* on the number of different JVMs I need to have installed to get anything to work reliably.

Re:The Media Is Retarded

[wolverine1999]

I'm not aware that Microsoft wanted to open source Java?

Do you know something I dont?

Re:The Media Is Retarded

[kaffiene]

I think you'll find that this is patently, provably false. If they were equivallent, the market would be using these clean room implementations now. The fact that they're not, and that people call for Sun to OSS SUN Java proves that there's a difference according to the market.

Java is written in...

[Merdalors]

Java is written in Java

Really? Not in C/C++? How do you get the first compiler to run on a new architecture? Probably a cross-compiler.

(Not a troll: genuinely curious & ignorant)

Re:Java is written in...

[ToasterofDOOM]

WHOOSH! on a kinder note, It is written in C/C++, it was just a joke.

Re:Java is written in...

[Anonymous Coward]

The original, vanilla compiler was written in C. The Hotspot compiler (which is now the free one) was written in C++ (http://www.research.att.com/~bs/applications.html search for Sun).

The libraries are apparently a hodge-podge.

Re:Java is written in...

[Anonymous Coward]

Really? Not in C/C++? How do you get the first compiler to run on a new architecture? Probably a cross-compiler.

There are a few options, of which you pointed out one (cross-compiler). Other options are, for example: Write a simple (non-optimizing) compiler in assembly or another language that is available on that architecture and bootstrap from there or write an interpreter in assembly or another language available on the architecture and use that to let the compiler compile itself.

Re:Java is written in...

[Anonymous Coward]

The libraries are apparently a kludge.

Fixed that for ya.

Why is this a surprise?

[Were-Rabbit]

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.

Re:Why is this a surprise?

[BigCheese]

Aha! So Sun has figured out how to Use the Schwartz.

Sorry, that name just begs for a Spaceballs reference.

Re:Why is this a surprise?

[Anonymous Coward]

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).

No doubt. I'm about ready to order one of those Opteron powered bad boys. Since they use a Tyan motherboard you can upgrade them to dual core. They're vetted to run Linux, Solaris x86, and Windows. A great deal for around $800!

Re:Not such big news after all...

[RetroGeek]

That means that every Java app out there, and there are a lot, should be able to run much faster

Compiling has trade-offs. You must target the end environment (CPU, OS), and also try to optimize code (for the target CPU). But you can only do static optimization.

Modern JVMs optimize on the fly. So the more you use a particular path through the code, the more it will be optimized (obviously only so far...). See this article: "The dynamic nature of the Java language provides opportunities for better optimization based on runtime profile information, and this is a significant advantage of a Java dynamic compiler over a traditional static compiler."

So having a compiled executable may not yield faster run times. It may have faster load times, which is where most of the perception of slowness comes from.

I use a rather large Java IDE (Eclipse) for development. It takes 10-15 seconds to load up the IDE from a cold start (2.1 GHz laptop). After that it is just as fast as I can type, which includes on-the-fly error/syntax checking, code assist, and so on.

Forking is the beauty of open source

[clawoo]

You don't want to fork your project, keep it for your bloody self... How could the code be free if you prevent it from evolving in various, now unthinkable ways?

I can hear it now...

[greg_barton]

Cue the slashdot crowd, with cries of, "IT'S NOT ENOUGH!"

okok, but why

[l3v1]

Don't get me wrong, I'm all pro-FOSS, still... We have this: http://java.sun.com/j2se/1.5.0/source_license.html and I don't see how this "new" turn of events will further help Java. I think it will be like with OO.org, it's open still, only a handfull of devs care about it for various reasons. I really like Sun as a company and as a source of hw and sw (no, I'm in no way affiliated or related) and I hope this turn will be in the right direction.

How? Three words:

[caudron]

General Public License

Seriously, there's a reason it's so popular. It ensures that noone can hijack the project and the source code will be legitimately free. You will make the most people happy with your decision if you go that route. Anything else will be seen as hedging your bets.

Tom Caudron
http://tom.digitalelite.com/

Re:Not such big news after all...

[Anonymous Coward]

Slashcode is a POS from 1996. As are the mentalities of slashdot's posters

Re:Not such big news after all...

[wasabii]

There are already open source, free, and feature complete Java Virtual Machines. There are also open source and nearly complete class libraries. Check out kaffe, gcj and classpath.

These can run most non-Swing applications perfectly. They are distributed By Default in Redhat and Ubuntu. Eclipse runs on them, Tomcat runs on them. Most Java applications run on them. This is old news.

It is not under question how "java works". It's easy. It's well published and well known.

"Look at Perl."

[Dystopian Rebel]

Just so I fully grasp your analogy, do you mean Perl < 6.0, which was damnably hard to read, or Perl >= 6.0, which will be impossible to understand?

Re:Not such big news after all...

[mypalmike]

Even in this here Slashdot page, I see the java tag used all over the source code for this page.

For the bazillionth time, Javascript is not Java. I can't believe there are people on /. who don't know this.

When and If this happens...

[Linus Sixpack]

Are the various demagogues of Open Source going to track how the new license helps Java grow?

I'd say that this is a classic situation where Java will not be the only thing worth studying. Once the license is decided and the code is even more out there for even more possibilities will we see IBM do even more with it? Will we see schools teach more Java because it has passed open source muster? Will this help it gain market share? Force M$ to open its languages? What about a new free Delphi?

I hope everyone, including Sun, is pleased with the outcome of this. Its not everyday such a big player takes this step. What do people think will happen?

We'll have to see. :)

LS

Re:Oh, dear lord

[__aaclcg7560]

That would explain all the Java I was taking at school. Of course, the fact that it took the school three years to find the money to upgrade the Microsoft site license to .NET was probably a coincidence while Java was so big.

forks are good

[DennisInDallas]

if people didn't like 'em, they wouldn't happen.

Twenty years ago people were all the time telling me that the biggest problem with unix was all the different versions, nobody was ever gonna use it if they couldn't be certain tht the version they picked will still be around in ten years. They were for the most part MVS bigots (or CDC cybernaughts).

I've heard a lot of the same stuff 'bout linux, mostly from windows washers.

This talk about forks doing harm to java is pretty much the same type of FUD.

I just see Emily Latella saying "Forks are good! I think there should be more forks. Just imagine how much more the Chinese could have contributed if they hadn't spent so much time fumbling around with those chopsticks..." Finaly, Chevy leans over and whispers "fork me"

Re:forks are good

[Kimos]

Twenty years ago people were all the time telling me that the biggest problem with unix was all the different versions

Well guess what, it's 20 years later, and do you know what the biggest complaint and resistance I get when talking to people about Linux? "It's so fragmented and spread out, I don't know what to choose or where to find what I'm looking for."

I love Linux. I like the compatibility and reliablity of Java. But I do think that a fork of Java by another one of the big guys would undermine most of what makes it a good language to write your applications in. As has been said above, are good in most cases, but I do believe that this is an exception...

YES

[JavaLord]

I can't wait to make the Javalord JVM. Soon the internet will be overrun with craplets that only work on my JVM. MUHAHAHA

In other news..

[dmt99]

Duke Nuke'em forever will release their source code....

Re:You can only use the term "Java" if you pass te

[VGPowerlord]

They're afraid that someone will linux it.

That is, come up with a new implementation that will become more popular than the original.

Open Source? Nah...

[zyche]

I don't care one bit about Sun Java as open source. Sure, it could be nice, but do you really think that a great number of amazing programmers would eagerly step up and immediately start to maintain and improve Java? And in that doing a better job than Sun & JCP is doing right now? Don't think so...

However, there is one thing Sun could do... one very important thing: remove the stupid click-through license on downloading the Java source-code. That one thing would mean that the BSD portstree or Gentoo portage could build Java from source - unsupervised. Today it's a total pain to manually download a bunch of distfiles. Even the patches can't be distributed without a click-through license. That sucks.

But then ofcourse, legal redistribution of Java binaries wouldn't hurt either...

But Open Source Java? Nah... Not really needed.

Re:Open Source? Nah...

[motiz88]

They're doing just that. That's what "open-sourcing Java" means: Making the code available under an open source license. It doesn't necessarily mean switching to a community development model - that's just how the open source community has generally chosen to do things for its own convenience.

(Not to mention your implication that they'd fire their Java dev team or something because "it's open source now". WTF?)

Anyway, Sun's keeping the Java trademark - They will still have exclusive control over what gets released under the "Java" name. They're not giving up one bit of control. Rather, they're throwing away the unnecessary restrictions that have been a pain in the necks of Java developers and users all these years. Hats off to them.

Re:Open Source? Nah...

[neurojab]

Sure, it could be nice, but do you really think that a great number of amazing programmers would eagerly step up and immediately start to maintain and improve Java? And in that doing a better job than Sun & JCP is doing right now? Don't think so...

Absolutely. We're not just talking about volunteers here. There are a lot of companies out there with a lot invested in Java. I'm sure they would love to have the opportunity to improve the core platform. Sun would still be involved in the maintenance, no doubt, so you'd be giving the cream of the crop of software engineers the ability to improve the platform, instead of a select few.

My case in point; At last year's JavaOne, there was a speaker (can't remember his name) that went into an insane level of detail on problems with finalizers, and he didn't work for Sun. If you gave him a swat at fixing the problem, it would just be taken care of, instead of being something that programmers have to "watch out for".

But Open Source Java? Nah... Not really needed.
I disagree 100%. Not going open source means you lose the inherent benefits of that model. Sure, Java is already "good", but there are thousands of ways to improve it (it's still catching up to SmallTalk in many ways). Why not let the interested parties do so?

Try the Artistic License?

[Anonymous Coward]

I know that Perl goes under the OSS "Artistic License" that, basically, says that there's only one true "Perl" out there.

I wonder if it would meet their requirements? Sure, there might be forks, but they'd no longer misleadingly be called "Java" so...

Then again, they might end up with Ruby or Python type competitors, so I dunno :)

Re:Try the Artistic License?

[Julian Morrison]

Not coincidentally, new Perl (version 6) has abandoned this model. They're going for "the spec is definitive" rather than "the implementation is definitive". There are already two-plus implementations of Perl 6, the most far ahead of which isn't even the official version.

At this late date, who cares.

[jmorris42]

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.

Re:At this late date, who cares.

[TopSpin]

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.

See here for a credible precedent.

Re:At this late date, who cares.

[Anonymous Coward]

They're only doing it because GJC, ClassPath, and the Mono stuff are taking off in popularity. Past history has shown that they won't make their license compatable with these projects (GPL, LGPL) because they'd be raided for code to improve these rather than vice versa.

    Michael

Re:At this late date, who cares.

[aCapitalist]

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...

No, those that care about freedom are worrying about real freedom and not joining some religious software cult invented by Jim Jones...err, I mean Richard Stallman.

Provide a superior product.

[Anonymous Coward]

The best thing they could do is release it under a very liberal license (like the MIT license), but continue to maintain it. As long as they provide a solid platform, that is suitable for most people, the community won't have any incentive to switch.

Projects only often get forked when there are major philosophical or technical issues. Other than that, people do tend to coexist, even if they disagree on certain points. It's rare that the two forks of the same project both become very popular.

Take the XFree86 project, for instance. It was the main X11 implementation on many systems for years. Licensing issues developed, and a fork was made. Now X.org is more popular. Once people saw that X.org had benefits over XFree86, there was a mass exodus from XFree86. There was very little strife in between.

GCC is another example. The EGCS fork was created due to problems with the development process. They coexisted for some time, but in the end EGCS won out.

Then there's the whole DragonflyBSD/FreeBSD split, and the NetBSD/OpenBSD split. I think we can all agree such splits were for the better. They allowed certain corners of the community to better focus upon their goals, and now we have fantastic platforms each with their own strengths and weaknesses.

Regardless of the fork, the main thing to keep in mind is that there must be a high degree of dissent in the community to allow for a fork to be useful. As long as Sun keeps everyone mostly happy, or happy enough not to want to fork, it's not an issue they have to deal with.

Re:C'mon Jeanie! *Please* get back in your bottle!

[misleb]

Don't release the source code.

Or another option is to not piss off contributors by rejecting suggestions and otherwise being resistent to change. Nobody is going to bother forking if Sun remains responsive to the community.

-matthew

Re:C'mon Jeanie! *Please* get back in your bottle!

[Bogtha]

There is demand for a Free implementation of Java and its standard libraries. One way or another, it will happen. The question is, how is it going to happen?

One way is for Sun to keep a tight grasp on Java and not open-source their implementation. That means a from-scratch implementation has to be written.

Another way is for Sun to open-source their implementation. That way, alternative implementations don't need to be written.

The question is; which do you think will produce most divergence? A competing, from-scratch implementation, or a continuation of the existing implementation? I think it's obvious the latter is the obvious solution if Sun genuinely want to retain interoperability between implementations.

TeX

[Ambush Commander]

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?

Still has Unacceptable Terms!

[Cyclops]

Sun also grants you a non-exclusive, non-transferable, royalty-free limited license to reproduce and distribute the Software, directly or indirectly through your licensees, distributors, resellers, or OEMs, electronically or in physical form or pre-installed with your Operating System on a general purpose desktop computer or server, provided that:
(...)
b) the Software is distributed with your Operating System, and such distribution is solely for the purposes of running Programs under the control of your Operating System and designing, developing and testing Programs to be run under the control of your Operating System;

So no Java for other software developemtn, Ubuntu can only distribute for software made that only works on Ubuntu.

c) you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software;

So Ubuntu can't package it in such a way that gcj and java reside on the same system (forget alternatives)

you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees)

So Mark Shuttleworth must have been quoted before reading. Sorry Mark, Sun tried to fool you and the Free Software community!

At this time, I stopped reading the license as it's irrelevant. gcj is turning proprietary java irrelevant by the day.

Re:Still has Unacceptable Terms!

[NorthDude]

Maybe because it has not been open sourced just yet?

Re:Still has Unacceptable Terms!

[Cyclops]

Did you bother to read the terms? Those are from the new license. Sun's capitalizing on the confusion created by the "open source" term, which was created to put your focus away from your freedom rights.

Re:Still has Unacceptable Terms!

[Per Bothner]

Eh - the "open sourcing" of Java is *future* tense.
So your headline is rather beside the point ...

Re:Still has Unacceptable Terms!

[Cyclops]

Real "open sourcing" maybe, but they claim it's already "open source", but controlled "open source". Read The Brave New License. I wrote excerpts from it.

GPL + DFSG compatible

[swbrown]

A meaningful license would be a GPL and DFSG compatible Open Source license. Anything else is just jerking the community around and won't change the resistance to Java, or could cause forks.

IBM? Microsoft?

[Julian Morrison]

Firstly, IBM are the good guys nowadays. They like open source, because they make their money selling integrated systems and it's nice if someone else does the donkey work.

Second, MS may be as evil as they ever were, but the whole "they'll fork Java" thing is so 1990s. Java is (a) very very solidly entrenched in its serverware and small cross platform app niche (b) a competitor to their flagship C#, so the last thing they want is draw people back to Java, of any fork or species.

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".

Re:IBM? Microsoft?

[Schraegstrichpunkt]

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.

Re:IBM? Microsoft?

[Anonymous Coward]

Not to mention that fact that the source is already available...and has been for a looong time. Bleh.

Re:IBM? Microsoft?

[ultranova]

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".

How nice of Microsoft to debug Java for Sun :). After all, in a popular OS project, a serious known bug is likely to be fixed very soon.

No, the last thing Microsoft wants is Sun to be able to say that "Java source code has been thoroughly inspected by thousands of hobbyists as well as corporations, including Microsoft". Especially since the end result would be faster, more reliable Java.

Re:Oh, dear lord

[Ohreally_factor]

should we start calling you "non-dairy" or "half and half"?

Re:You can only use the term "Java" if you pass te

[bill_mcgonigle]

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.

It's worked well enough for the C camp. Has Java been submitted as an EMCA or ANSI or ISO standard? Of course there are multiple competing compilers which I guess is what Sun wants to avoid.

This is good for the community; maybe not so much Sun. It will at least force Sun to stay on their toes; maybe by doing so they'll manage to invent a new business along they way (and disappoint Cringely).

forking is good

[cinnamon colbert]

because it will condem java to the obscurity to which it deserves to go.
everytime java activates, my computer slows down.
why shd i put up with this ?

A Microsoft fork can eventually kill java

[Fedarkyn]

"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"."

No.

like before, M$ will be able to ship inside windows a m$ java virtual machine with limited compatibility with the real java. This alone will be a major blow in the java brand, where everyone will see applications breaking in every desktop while .net apps seems more stable.

On the other side you will have J++ (or whathever name they will give it) in visual studio and claim that is the same java, but will be a M$ fork designed to run with optimizations in windows machines and behavig strangely in other VM's. No one will care about this in the beginning as 90% of the desktop machines are running windows, but will split the Java community into 2, a Java for windows community and a Java cross platform community.

To make a long story short, will be the end of Java as a cross platform language/platform

Re:A Microsoft fork can eventually kill java

[DragonWriter]

like before, M$ will be able to ship inside windows a m$ java virtual machine with limited compatibility with the real java.

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? It doesn't matter if the open source java originates with Sun or someone else, as long as it exists Microsoft can do that. Seems to me its better for Sun to open source its own implementation rather than risk some competitor putting its market power beyond a project forked from one of the other implementations, which has the added advantage of being open sourced. I mean, is it better for Sun if IBM or Microsoft tries to fork an open source Sun JVM, or if Microsoft forks another implementation, and because its open source and Sun's isn't, that implementation gets redistributed with other open source projects and Sun's doesn't? Once a clean-room open implementation exists that Sun doesn't control, it can no longer prevent Microsoft or someone else attempting to "embrace, extend, and exterminate". The way it maximizes its influence over what happens is by running the best java open-source project in the marketplace.

Re:A Microsoft fork can eventually kill java

[AKAImBatman]

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.

Re:A Microsoft fork can eventually kill java

[Overly Critical Guy]

I'm afraid I just can't take your post as a valid point, because you didn't use "M$" enough.

Re:A Microsoft fork can eventually kill java

[squiggleslash]

I wasn't aware of that. That kind of undermines the argument that Microsoft was trying the "extend and embrace" route to killing Java with proprietary incompatibilities, and suggests their motive in creating extensions really was to improve it. They just went about it the wrong way.

Or maybe they didn't, maybe they presented their improvements to Sun, which at the time didn't really have a community development process, and Sun rejected them.

Either way, supporting an Free Software project and documenting their extensions and asking the FS project to include these features doesn't mesh with the E&E strategy they've always been painted as using.

Re:A Microsoft fork can eventually kill java

[AKAImBatman]

That kind of undermines the argument that Microsoft was trying the "extend and embrace" route to killing Java with proprietary incompatibilities

Uh, no. At the time Microsoft was embroiled in a lawsuit with Sun over those very extensions. Microsoft payed for Kaffe either to help their case, or find an outlet to disrupt Java while they were locked up in a court case. Microsoft's intentions were anything but noble.

Re:A Microsoft fork can eventually kill java

[squiggleslash]

Adding the extensions to Kaffe wouldn't disrupt Java, as the extensions would be open, documented, and thus possible to incorporate into a standard distribution. It might disrupt Sun's control over Java, but that would be over a period of years. The fundamental concept of "Write once, run everywhere" wouldn't be affected, and if the extensions were useful, Java itself would become more viable at the end of it, not less.

It's possible Microsoft were trying "to help their case", I'll give you that. It would be nice to think of Microsoft as occasionally good, once in a while. Maybe they'll inject a little funding into Mono one day, with no court case to encourage them.

Re:A Microsoft fork can eventually kill java

[AKAImBatman]

The problem is that these extensions made versions of Java that used them, incompatible with the main distribution. In addition, they were all to solve problems that Java already had solutions for, but in a "different" way. Last but not least, they were designed to fail silently so that people would think that Sun's JVM was the bad one.

For example, the delegates feature that Microsoft added (completely not necessary) required the programmer to put actual class infotmation in the comments of the code. Not even a keyword extension, but in the comments! There was no way that Sun would put such idiocy into the main branch of Java, and Microsoft knew it. The result was that Sun handed Microsoft their collective asses in the courtroom.

Re:A Microsoft fork can eventually kill java

[duffahtolla]

It doesn't undermine anything if you look at what MS actualy did.

If I understood it right, the MS extensions conflicted with the standard java.* packages. This was not a mistake. The proper way to to add extensions would be to create your code in something like com.microsoft.NewClass. Sun says don't mess with the java.* stuff.

MS intentionally ignored the restriction and in addition to adding new classes in the restricted package, MS rewrote the order of a few parameters to some key Java classes within in the java.* package. Thus killing compatibility from the very start.

I don't remember the exact classes but the effect was like this:

Sun: void foo(int ip, int port) ..

MS: void foo(int port, int ip) ..

The changes that were like this served no other purpose other than to fragment the market.

MS got sued, lost and now cant touch java (MS-java is still 1.1.8, no?).

So they try to touch it indirectly through Kaffe. As far as MS is concerned Kaffe = SCO. Give em some money and let them mess with the competition.

Why is Linux forking considered a bad thing?

[Richard Steiner]

The freedom to fork the Linux kernel has resulted in varieties of Linux running on all sorts of platforms, including many that that the mainstream kernel development team has absolutely no interest in.

That's the beauty of being able to fork the code -- people can use it as the basis for scratching their own itch.

The freedom to fork Linux distributions has resulted in something that most markets identify as "competition", something which the x86 desktop OS market hasn't seen in some time.

In spite of Sun's touching concerns, this can actually be a healthy situation, and usually is.

Re:Why is Linux forking considered a bad thing?

[John Hasler]

Forking is bad for those who want control. It's good for everyone else.

Re:Why is Linux forking considered a bad thing?

[Richard Steiner]

I can accept that. :-)

I suppose this will end Java innovation for me

[bill_kress]

Personally, I'll probably stop at a near-future release and not go forward. I'm guessing I'm not the only one.

I expect java will fork a few times, then the forks will fork. It will quickly descend into dozens of incompatible custom builds while those who want to get work done stick with 1.5 or 2.0 or whatever sun ends with.

I imagine an official sun build going forward for a while--pulling along behind it an ever-increasing pile of hanging-on junk projects. Eventually it will lose it's steam because of the fragmentation of the user base and the requests to "Keep up" with features in these side versions until it grinds to a complete halt.

All this time, committees will be adding "Features" that sun has been holding off on. Features that might save a programmer two keystrokes or allow some trixy maneuver while sacrificing "just a little" readability (like Generics did--IMO sun is already moving too fast!).

I guess now I'll start the search for the next beautiful language that can pull itself up above the fray--above the garbage that is the syntax of Ruby, C++, VB and all these other pretenders.

I suppose that it is possible that Sun will manage to keep control over the language definition via licensing, but I'm not going to hold my breath.

It's been fun.

Re:I suppose this will end Java innovation for me

[DragonWriter]

I guess now I'll start the search for the next beautiful language that can pull itself up above the fray--above the garbage that is the syntax of Ruby, C++, VB and all these other pretenders.

Depending on exactly what you mean by beautiful, and what other criteria you have, you might consider REBOL (which suffers, among other things, from not having an open source implementation) or maybe something like Alice. I mean, I think either is, in its own way, more "beautiful" than any of the more popular and widely used languages like VB, C++, Java, etc.

Re:I suppose this will end Java innovation for me

[bill_kress]

REBOL looks interesting--I'm going to look at it further, I love the idea of combining metadata with code--something Java was just getting into with annotations.

Alice seems at a (admittedly quick) glance like another catch-all language.

Beautiful to me means the language definition must be as small and simple as possible while delivering the ability to keep your code as close as possible to fully factored (no repeating lines or patterns) while retaining optimum readability.

Structures and patterns that eliminate errors are also great as long as they don't require boilerplate code or impear readibility (for instance, I'd love a "nonull" keyword in Java to force an exception if a given variable ever becomes null.)

As I view it--anything code structure that does not directly improve either readability or the ability to factor out repeated code should be deliberatly excluded from the language definition.

Thank you for the references!

Re:I suppose this will end Java innovation for me

[Oswald]

I'll say this much: that is the most (apparently) heartfelt paean to Java I've ever read.

It's a matter of taste, I suppose, but I don't think I can agree with you about Java being beautiful. Practical, pragmatic, even wise I can accept, but beautiful is right out.

Anyway, don't give up on its future just yet. I can't see anybody's fork gaining a lot of mindshare unless Sun just stops doing anything at all with the language.

Re:I suppose this will end Java innovation for me

[bill_kress]

I suppose some might find APL beautiful in the way an abstract set of paint splotches is pretty.

C is somewhat beautiful in it's simplicity--absolutely trivial to implement a compiler, but the fact that they targeted writing simple compilers kinda bums me out.

C++ is simply UGLY, makes COBOL look somewhat pretty. They managed to take all the worst parts of C and add some really ugly junk syntax.

Basic is certainly readable but the syntax is bizarre and random. Even with the new constructs and quasi-OO ability, it's still sloppy.

Java has the small language definition of C (most of the syntax follows the exact same pattern), removes nearly all the boilerplate of C++, makes constructs like extending classes, threading and references so consistent and simple that you nearly ever have to refer to any sort of documentation.

On top of this, Garbage Collection adds to the object manipulation abilities by allowing you to create an object and just pass it off into the wilderness without having to keep track of who's going to destroy it. Trust me, this requirement of monitoring classes for distruction makes OO programming in C significantly more difficult--makes it almost impossible to "Think" in OO.

As if this was not enough, Relfection, annotations and Javadocs are all indispensable and gorgeous.

Now, I have to admit that it will never have the look of an APL program which is pretty much a piece of abstract art in itself, but otherwise I gotta say I absolutely love this language.

Re:I suppose this will end Java innovation for me

[Thundersnatch]

If you're looking for the cleanest-looking, most-readable syntax out there... what about Python? Readability and maintainability was a primary design goal.

Re:You can only use the term "Java" if you pass te

[Bob9113]

Anyone can use the code... Is there any reason why such an approach wouldn't work?

I'd have to toss in "can modify and redistribute." Open Source ain't Open Source if I can't let others try my dodgy hack.

Why isn't there an Open Source Java already?

[Anonymous Coward]

The Java specs (for JVM and language) are published, right?
If there is such a demand for an Open Source Java why hasn't someone just gone ahead and released their GPL/BSD/etc implementation of Java? With the superior Open Source development model it shouldn't be too much effort...

fragmentation is the point of open source!

[m874t232]

There is no way to prevent fragmentation. Open source projects fragment when a single code base can't serve every community anymore, or when the people running the project are screwing up. That's a good thing. Giving users the freedom to fork an open source project when they choose is what open source is all about. The concept of open source without the ability to fork and fragment doesn't make sense.

Sun is right to fear fragmentation; the minute they open source Java, they will lose control. Personally, I think that's a good thing for Java. but Java zealots disagree. In any case, I stopped worrying about it. It's taken Java only 10 years for its spectacular growth, but it can disappear even more quickly than it has grown. if Java continues along its current path, it will collapse under its own weight and become irrelevant in 5-10 years.

Re:fragmentation is the point of open source!

[RichiP]

Nobody likes fragmentation. Least of all the people who initiate the fragmentation itself. Unfortunately, it sometimes becomes necessary to do so if there is disagreement in the way a project is handled.

In this case and as a one-time Java software developer, I would definitely NOT want fragmentation in Java's implementation. I'm hoping that Sun can somehow release the source to be freely viewed and modified *with the constraint that any modifications made will comply with the JSRs*. No, it is not totally free, but it adheres to the philosophy of sticking together to be more effective. If someone wants changes, let it be done under the auspices of the JCP. I would agree to that kind of a license if and only if Sun relinquishes control of the JCP to the public.

Re:fragmentation is the point of open source!

[m874t232]

Unfortunately, it sometimes becomes necessary to do so if there is disagreement in the way a project is handled.

You make it sound as if it's a personality issue. It may be, but usually, it's real technical or licensing issues that cause projects to split.

In this case and as a one-time Java software developer, I would definitely NOT want fragmentation in Java's implementation.

It's telling that you talk about "fragmentation in Java's implementation" because that's what Java really is: a single implementation.

In any case, Sun's obsession with control has lost them the desktop market, the applet market, and the numerical market. All they have left is education and a sliver of the enterprise server market. The reason why the Java community doesn't want fragmentation anymore is because all the people who have needs different from Sun's and yours have left in frustration.

I would agree to that kind of a license if and only if Sun relinquishes control of the JCP to the public.

I doubt it matters much anymore. Java has a specific market segment, the platform is what it is, and I don't see people coming back anymore or investing the energy to fix it; it's just not worth it--we have better choices.

It's nothing to do with proprietary systems...

[Anonymous Coward]

...It's to do with cash.

The more you have invested, the more it's worth sticking with. If the cost of maintaining your own branch is cheaper than migrating to another, you stick with the branch you've got...

All you need to do is make the features you need on the branch, and make a lot of money on that, then the only reason you'll consider merging with another branch is if it's financially advantagous (sp?) to do so.

Invest a lot of money on a particualar branch, it'll not be financially viable to merge with another. The longer the branch lasts, the less likely to merge it is. Therefore it's a battle of money.

Don't you remember the non-standard java implementation Microsoft had?

good move

[unk1911]

i think this is a great idea. one of my biggest annoyances with writing java apps has been that if i ever wanted to release my programs and didn't want to make any assumptions about my users (mainly that they had any version of java already installed on their system let a lone a level of java that matched my own level) i would have to deploy a very heavy 50MB JRE with my 100K app... i think with the opening of the java source, much like in the linux world, someone will repackage the JRE and just keep the very bare-bones essentials so that instead of deploying a 50MB+100K apps i can deploy a 5MB+100k app.

--
http://unk1911.blogspot.com/

Re:good move

[Anonymous Coward]

The JRE is 16MB not 50MB.

Give me a break...

[Eric Damron]

Suggesting that Microsoft wouldn't bundle a look-a-like product in their monopoly OS and then do exactly what the parent post suggests (start making small changes) makes you sound naïve. For God sakes man, they did already try it once!

Microsoft hasn't learned to play fair and not cross that good ol' antitrust line. They wouldn't think twice if they decided that they could destroy Java that way.

Re:Give me a break...

[Coryoth]

Suggesting that Microsoft wouldn't bundle a look-a-like product in their monopoly OS and then do exactly what the parent post suggests (start making small changes) makes you sound naïve. For God sakes man, they did already try it once!

Yes, they tried, they failed, they moved on. At this point there's little reason in trying to poison the Java JVM well because their investment is in .NET. Throwing on a JVM, even a poisoned on, only dilutes their push now. Besides, Sun can still bar Microsoft from calling it Java, or claiming it to be Java compatible, at which stage what's the point for Microsoft to even bother? Back when Java mattered Microsoft was more than willing to fuck things up, but they're now making quite respectable headway with .NET and simply don't care anymore.

Jedidiah.

Re:Give me a break...

[muyuubyou]

You seem to ignore they only failed BECAUSE OF THE LICENSE and the ruling it caused.

I'd bet my lucky pants MS would try again. MS is never afraid to open different fronts to kill competition, riding their monopoly cash cow.

Re:Give me a break...

[Anonymous Coward]

For God sakes man, they did already try it once!

Twice. First with their own Java runtime, and then with .NET.

By now, Java is only popular in the Java community. The OSS community has more or less given up on Java, and gone for Microsofts Java-clone .NET instead.

If I had to decide between Java and .NET for a project, what would I choose? There is Java, which runs on Solaris, may or may not come standard with Windows, and can't be compiled for whatever OS I need to run it on. Or I can go for Mono / .NET, which will make my program run Windows and any unix-ish system, including even Solaris.

So far, Microsoft is winning the game big time. This is a desparate attempt from Sun to finally win back the OSS community.

at last!

[ChristTrekker]

I will finally be able to run Tomcat on my NetBSD/mac68k box without waiting for Kaffe to mature. Hooray!

Re:at last!

[Anonymous Coward]

It's a trap! :)

cheers,
dalibor topic

Re:C'mon Jeanie! *Please* get back in your bottle!

[Anonymous Coward]

Well, as a developer, I will tell you THE one and only way to prevent forking and fragmentation...

Don't release the source code.

What? You claim that, say, Microsoft doesn't have huge issues with code forking in different versions of operating systems and office products? Several bugs, including the XPSP2 ping of death coming back are direct results of forking off old code and trying to tie things back together. Forking and fragmentation will happen internally anyway, especially if a company ever gets bought. What happens to Java if Sun goes belly-up and gets bought by Microsoft?

It's a Mistake

[Majeric]

Java's strength is in the bredth of the standards that are defined for it. Look at C++, the only libraries people use with any great consistency are the ANSI standard libraries and they are infintesimally smaller than the Java Standard Libraries.

Use Ada's model

[ChrisA90278]

A "fork" will happen no matter what. What needs to be prevented in an incompatable fork that is non-standard Java. They need to prevent others from taking over the standard. One way that has worked is the way Ada did it. There are many Ada compilers (including the Open Source gcc Ada front end) but the language spec for Ada is closely followed by everyone. What they should do is hold onto the trademark but offer to let anyone use it whos Java implementation passes a large test suit. By "large" I mean something like a 100,000 lines of Java code. Should there ever be a problem they can extend the test suite. After all the whole point of OSS it so people can change the software. The first time one guy checks it out of CVS and make an edit you have a "fork" but hopefuly these get checked back into the main brabch after so testing

Re:C'mon Jeanie! *Please* get back in your bottle!

[killjoe]

Right to fork is the most important one in the open source definition. Where do these guys live??

Why now?

[Anonymous Coward]

So, after resisting for years, let's see what is happening in the GNU world to change Jonathan Schwartz mind

Re:Why now?

[Dewin Cymraeg]

So now kaffe is still several years behind Sun.

Big catch up ;)

I wouldn't want my live application server to discover its bugs.

Somehow, I don't think Sun are too worried about this!

Fragmentation won't happen

[johansalk]

Perl, Python, Ruby, and so on. All are Open Source yet not fragmented. Look at TCL, though it lacks a "dictator" like the others above, it still has not fragmented.

Mea culpa.

[WindBourne]

Me too; When did this come about; Could not do it before.

Re:Mea culpa.

[AKAImBatman]

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.

Re:Mea culpa.

[Anonymous Coward]

Hmmmm; Figures.

I got out of java coding back in that time. Since then I have not paid as close attention. Guess I need to pay attention more before opening the mouth.

Thanx.

WRONG

[twistedcubic]

It's just TOO LATE!

Re:Not such big news after all...

[bluefoxlucid]

Compiling has trade-offs. You must target the end environment (CPU, OS), and also try to optimize code (for the target CPU). But you can only do static optimization.

Modern JVMs optimize on the fly. So the more you use a particular path through the code, the more it will be optimized (obviously only so far...).

Don't forget runtime optimization like that has trade-offs, namely that you have data-code confusion. Data is not code. The stack, heap, and writable shared and anonymous memory are data; when these are executed, we usually see nasty things like security holes (Code Red, Slammer, Blaster, Zytob/Mytob...). Preferred solution is to make sure the only stuff we execute came with the program-- i.e. an image and shared libraries.

Any bug in the JRE-- and we love assuming it's perfect-- can be exploited. We can't deploy proactive protections against it unless we use slower disk-based solutions-- write the generated code to a file, mmap() the file executable. From a security standpoint, we can't make "guarantees" mathematically; we can only speculate on the language's design and the hope that it is implemented properly. (By contrast, we are otherwise hoping that the program is implemented properly; and if that fails, that the OS implemented its prot properly; failing that we're finally screwed).

I really don't like runtime code generation, because it requires runtime code execution.

Use the Java Trademark !

[Khalid]

Sun owns the Java name right ? so people can fork the source code as they want if Sun refuses this forked "thing" to bear the Java name, then it can't be called this way, it's as simple as that. Only the Sun blessed version will be allowed to use the Java name. I don't see any risk of forking here.

GNU Classpath

[Anonymous Coward]

Unfortunately for Sun, Java will be Open Source with or without them. GNU Classpath is already mostly Java 1.4 compliant.

They basically have a choice. They can either make the Sun JVM the defacto JVM now by complying with open source demands, or they can be the stodgy corporate-only JVM while everyone else uses GNU Classpath. Even by fixing the Sun JVM license the people working on GNU Classpath aren't going to stop. They want a GNU, true open source alternative. Do we need any reminder on how the UNIX / Linux battle played out?

So like the Sun execs have said, it is not whether the JVM will be open source. It is HOW it will be. Will it be Sun or GNU Classpath in 5 years? Clearly, Sun realized this and is scrambling to make it happen before it is too late and a thriving community leaves them in the dust like with Solaris v Linux.

Uh, am I missing something?

[dnaumov]

JAVA source code has been freely avaible for many years now. If that wasn't that case, you wouldn't be able to for example, build the native FreeBSD JDK...

Re:Uh, am I missing something?

[smash]

That's the virtual machine, not the source code to the program that generates the virtual machine, the libraries, etc.

smash

IBM wont fork JEE (formerly J2EE)

[CypherOz]

As far as IBM goes they still own a lions share of the server market and could easily fork J2EE. That would also suck.

Why? IBM is committed to open computing and standards. IBM will/do drive standards, but as for forking - that would hinder the IBM strategy.

Re:Not such big news after all...

[owlstead]

There have been very few problems with the JVM so far. The good thing is that the JVM is a very small target to hit, and it's pretty easy to test it and make sure it works correctly. Everything that runs inside the Java JVM, including all libraries that do not directly call native code, is bounds checked. Many of the examples you have pointed out would never have worked inside a Java VM, where buffer overruns are *very* unlikely. I believe up till now one has been found.

The VM does make a very clear distinction between data and code. If you want to create code, you will have to pass the byte verifier. And if that is using a security scheme for e.g. applets, you cannot even write to disk. Maybe the underlying system cannot see that it is data or code, but who cares? Of course any bug in the JRE (that is visible to a Java program, pretty unlikely) can be exploited. But the JRE has proven to be a very stable environment. Much more so than any other runtime environment I've encountered so far.

You are also trying to make a distinction between native code environment and the Java environment. There really isn't too much difference. But while normal, native, platforms are horrendously complex, use pointer arithmetic, huge numbers of instructions etc. etc. Java runs in a pretty well understood and much less complex environment, where most of the risks of a native platform have been rooted out. All in all, Java is pretty well suited for security and stability.

If you don't like runtime code execution, I would advise you to stay as far away from your computer as possible.

No, that's not the issue here.

[Ayanami Rei]

The "problem", if you will, is that no distribution comes with a Sun standard JVM. Why? Not allowed to distribute it. Licensing issues.

That is unacceptable. If Sun can just change the license a little then Red Hat, Novell, FreeBSD ports ... they would be HAPPY to build, maintain, and bundle JVMs and JREs for Sun for all their supported platforms and have it installed by default.

Instead we have to do stupid shit like the jpackage-sun-jre SRPM which essentially downloads a file from the Sun website, makes you look at a EULA, expands it, and repackages it as a binary RPM. Utter useless horseshit. Projects like blackdown java and jpackage (which exist primarily as technological measures to circumvent/handle issues due to Sun's licensing) are proof that there's something wrong with the One True Release model that Sun has been pushing.

The ramblings of a few OSS advocates who have never coded a bit of java in their lives is not the issue here. That's just noise that distracts from the real issues.
In fact, the only reason why they rant is because they look at their Fedora box and say: "Hey, where's the java package?" They go on the forum and ask, "WTF?". The response they get back is "Lol Sun suxors java isn't open sauce looool". Which isn't really true, its just Sun is being assisine about groups like Fedora distributing it.

It's everyone else who hates having to jump through hoops to standardize on java on whatever platform they want to play with who are complaining. Sun is finally listening to them. Hopefully someday soon my RHEL 5.0 extras CD will come with official Sun RPMS and SRPMS for all my platforms. One can dream.

Fear of Forking

[kabloom]

Have a look at Rick Moen's essay Fear of forking to see in more detail what causes successful forking.

ultimately

[penguin-collective]

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.

Ultimately, the only way to prevent forking is to do such a good job at managing the project and on the technical side that few people will want to use a fork.

I don't think that Sun is up to that standard, and it's pretty clear that Sun themselves doesn't think that, otherwise they wouldn't be so worried about forking.

The goal is to get Java included in Linux distros

[ChaseTec]

Sun's press release
Offical Sun JDK Distros Project
Like a lot of people are already saying, you've been able to get the JDK source code for a long time now. The goal here is to fix the things that keep most Linux distro from including a JRE/JDK.

strategy backfired

[penguin-collective]

Remember, Microsoft already tried to pull that routine with the NON-OSS version of Java.

Microsoft didn't need Sun's source code to create an incompatible version of Java, as the existence of .NET shows. Microsoft even provides tools to let you convert all your Java programs to the .NET platform, but the reverse migration is pretty much impossible since .NET has functionality that Java cannot emulate efficiently.

By not permitting Microsoft to fork Java and create a somewhat incompatible version, Sun has created a competitor for itself that is far, far worse than a slightly incompatible "Microsoft Java".

And the icing on the cake is that Sun was such an ass when it came to dealing with the open source community when it came to Java that they have antagonized large parts of the open source world. They've also dropped the ball technologically on Java (there wasn't much debate on 1.6 because few people outside Java's core zealots give a damn anymore). The open source community has instead created its own, open source, high-quality implementation of .NET, with the effect that .NET and Mono are already far more prevalent on Linux distributions than Java.

The notion that Sun could control Java by playing hardball was hubris, and it backfired. Now, a few years later, Sun is scrambling trying to pick up the pieces of their broken strategy. And Schwartz still doesn't get it--he is still trying to square the circle and come up with a "non-forking OSS license".

Re:strategy backfired

[muyuubyou]

By no means it is worse having .NET competition than the effective overtaking of Java under Windows by MS, then an induced crackdown in compatibility among platforms.

Java still has the upper hand, by a long shot. Every same individual knows .NET goes where MS wants it to go, and it's an understatement Windows is the preferred platform and support for the rest relies partly in "volunteers" in the long term. I wouldn't lock myself into .NET at any cost.

Re:strategy backfired

[chris_mahan]

I am going to agree. Java is just too far behind. It's the new COBOL.

American programmers are moving away from it (those that know how to see the future at the bottom of the coffee mug) because they realize that doing java in a corporate job is being at the end of the chain in a 60+ man project with all the remotely creative decisions done by people before the programmers, and they are just implementers of badly-written 500 pages spec that absolutely lack any spark of brilliance, all the while fearing outsourcing by Cognizant and IBM Global Services (yes, India, China, and various sundry other countries) and fighting against newly-minted foreign-born H-1 Visa-holding programmers who think that $63,000/yr would just be quite satifactory and who are itching to take on any project and demonstrate to foggy-eyed managers how many more lines of code they can produce than said American Programmers.

Enter Ruby, Python, and the very esoteric language known as C, and many other beasts (see Factor): tools all for the Great American Hacker to weave magical dream machines that web-service, self-introspect, metacode themselves, and baffle any attempt at explanation but are Rather Tiny, Dastardly Clever and Entirely Fast Enough; coded in 4 days rather than 3 months (as promised) + another 9 months (because management can't see Sunk Costs when it stares them in the face)of which said programmer grandly pronounce, chest a-puffing: "I was instrumental in the design, implementation, and maintenance of the Garguantuan multi-million dollar soul-crushing Monstruosity", would rather effacably mumble "I dabble in computers" and return to watching the "you got an f" veedub commercial on youtube as soon as fleet-footed managers have returned to their dens of power with doors and minds that close.

Forget .NET. Go with Python. It has features that .NET doesn't support yet. They do try (see IronPython), but the Python C implementation has been years in the making is the love child of some of the brightest out there. It's getting to be plenty fast for most tasks, and is so insanely easier to use than java that it's not even funny. Classes are namespaces. Think on that a bit. Then, go run amok in Ruby land, following Matz's fantasy. At last, embrace the Way of UNIX, as so eloquently expounded by none other than ESR.

Java is fighting a rear-guard action. The language is 10 years old. It should be so much better by now. Python is the same age as linux, both 15-16 years old. They are more mature, more robust, more accepted and accepting.

Alas, many will claim that java and .Net have more robust libraries, constructs, and frameworks. I shall remind you all that the way of UNIX leads to simplicity and depth of understanding. See Master Foo and the Ten Thousand Lines. (for those who grok that, see Master Foo Discourses on the Unix-Nature).

Re:strategy backfired

[ynohoo]

Java is just too far behind. It's the new COBOL.

Hey, quit insulting COBOL! COBOL is lean & mean compared to that bloated Virtual Machine. While the OOPs paradigm is useful for GUI interfaces, it can cripple data access. BTW, have the Java GUIs stopped sucking yet?

Re:strategy backfired

[chris_mahan]

Yeah, you're right. I wasn't comparing languages. I was thinking of the perception in corporations.

Re:strategy backfired

[penguin-collective]

Java is fighting a rear-guard action. The language is 10 years old.

Actually, except for the new-fangled C-like syntax, the language is really more than 30 years old.

Forget .NET. Go with Python. It has features that .NET doesn't support yet.

Python is a lovely and productive scripting language, and I think it's great for many of the things people use Java for. But nice as it is, some features (e.g., the use of hash tables to represent objects) just aren't heavy-duty enough for me. Overall, when it comes to dynamic languages, I think Smalltalk is still the overall best design, 25 years after its creation.

However, .NET and Mono are persuasive: between IronPython and Boo, it is a great and productive programming environment that, unlike either Java or Python, covers everything from low-level systems programming, to application programming, numerical programming, and scripting.

wake up--it's already happened

[penguin-collective]

Microsoft says "Great Sun open sourced Java". We will take it bundle it with windows, change all the underlying code so that it actually uses windows API's, remove anything that competes against our stuff like SWING, EJB's, Servlets, messaging API's et al, and make it so that our Java only runs on Windows, and even if you try to run a "normal" Java application , it will not work unless you change it to support com.microsoft.xxx libraries, and jump through a ton of hoops.

The already did this. It's called .NET. It's an open standard and there are open source implementations. It provides excellent desktop integration on Windows and Linux. It gives you a choice of native toolkits or cross platform toolkits. It's technically superior to Java and the implementations are better than Sun Java. Recent Linux distributions include a dozen or so Mono applications as part of the Gnome desktop, and they work so well that most people won't even know it. Even Gnome's desktop search is based on it. And both Microsoft and Mono provide backwards compatibility with Java (you can even run Eclipse on top of Mono).

By giving the finger to both Microsoft and the open source world, Sun really screwed themselves.

Re:wake up--it's already happened

[Anonymous Coward]

"The already did this. It's called .NET. It's an open standard and there are open source implementations. It provides excellent desktop integration on Windows and Linux. It gives you a choice of native toolkits or cross platform toolkits. It's technically superior to Java and the implementations are better than Sun Java."


Wow, someone smells like bullshit :)

do NOT download this--it's a trap

[penguin-collective]

The fact that Sun has made it easy to obtain Java source code under license by merely clicking through is a trap; it lulls people into the belief that they can download the source code without consequences. It is cynical and deceptive to say that the source code is available without being clear how seriously encumbered it is. Windows source code is available under restrictive licenses as well, but frankly, I consider the fact that you have to do more than click through a license a bit more honest than what Sun is doing.

Let me say it again: do not donwload Sun's Java source code unless you are absolutely clear of what the legal implications are. Sun is serious about their licenses and they have enforced them in the past when it suited them. Neither the JRL nor the SCSL are open source licenses and violate many of the implicit assumptions you may make about downloadable source code. In addition, keep in mind that significant aspects of the Java platform are patented by Sun, so that it's not clear that merely having source code, even if you could use it, would help you.

Bugfixes!

[Max Threshold]

Now we can start contributing bugfixes for the long-standing bugs in the standard API.

Well, we could always contribute them. But hopefully now they'll actually get applied.

Re:Bugfixes!

[oglueck]

Now we can start contributing bugfixes for the long-standing bugs in the standard API.

The API source is already available and you get it in the src.zip file of every JDK. It also includes the com.sun.* packages. So in theory you could always fix those API bugs in your own fork of the standard API making your applications incompatible with the rest of the Java world.

What Sun is talking about now, is releasing the source code of their VM implementation.

Re:Bugfixes!

[Max Threshold]

"making your applications incompatible with the rest of the Java world"

Exactly.

I'm hoping that the licenses will permit redistributing the modified VM and API. Maybe a de-facto standard "community" version will spring up with all these years of fixes applied.

Re:C'mon Jeanie! *Please* get back in your bottle!

[Anonymous Coward]

They cannot include all suggestions, because huge number would be detrimental to the language (and runtime).

Now, just add one and one and see if you got two.

The next OpenOffice.org will bundle its own Java

[mi]

They already bundle everything they can, except for the C/C++ compilers (but including their own copy of STLport).

I'm confident, it is only the Sun's restrictive licensing, that prevented them from bundling Java as well. Not any more...

Of course, you will still be able to use the already installed Java using the --with-system-java switch, but it will subtly break various things, because the OO.o's automated builds would never use it themselves.

Re:C'mon Jeanie! *Please* get back in your bottle!

[Baki]

The java community is many orders of magnitudes bigger than that of any other product. Also the members of the community themselves are, next to individual developers, the largest software companies in the world. Sun could never be 'responsive' to this community in general, since a lot of its members have conflicts of interest and widely different opinions. I think Sun does quite a good job of reconciliating these interests. But still, forking, when so much money is at stake, remains a very big risk and cannot be prevented by being responsive.

Just as much as a "trap" as the GPL

[Anonymous Coward]

What does it matter that the JRL or SCSL licenses put "limits" on what you can do? So does the GPL. At least Sun is upfront with their clickthrough license. Maybe it seems scary that you have click "I Accept", but if you download GPL source, you have also accepted the GPL license terms. It is just implied.

JRL and SCSL are open source in that anyone can download the source today, and not pay anything.

JRL and SCSL are not "Open Source" because they are not GPL. So what? GPL has some restrictions and so does JRL and SCSL. Until the world switches to BSD or Artistic licenses (which have even fewer restrictions), we have to accept GPL, JRL, and SCSL.

GPL to the Rescue

[anandsr]

If preventing forks (as in forks made by proprietory interests), then GPL is the way to go. The GPL makes it stupid for anybody to make a fork unless they think that the present leadership is not doing its job properly. So Microsoft or IBM will not make a fork because it will be better to just contribute to the base. Proprietory forks are disallowed by GPL and OSS forks cannot survive because there is an inherent bias in merging the forks, because it improves the code base faster. As past has shown us before (GCC fork, X11 fork), they only happen when the current leadership is not working well. These kinds of fork are a good thing.

BTW no non-viral license can do the job of preventing forks effectively, and that includes BSD and others. Not to flame BSD users but BSD license is great in instances where you want a particular protocol to be used everywhere including proprietory implementation. I would think it would be good if there is an ODF implementation in BSD License then everybody except MS would use it. And we will have a similarly working ODF readers. BSD TCP/IP stack is a reason why TCP/IP is so popular. But preventing forks is not one of its features.

Check your distribution

[eldacan]

Does your linux distribution come with Sun's Java? No? Well once Java is open-sourced, it will.

Java out of the box, that's a big change.

Re:first post?

[Anonymous Coward]

Sure it is :)

Re:C'mon Jeanie! *Please* get back in your bottle!

[misleb]

I wouldn't consider your average Java developer to be part of the Java community (as far as the source code for the VM and compiler is concerned). The vast majority of Java developers don't give a crap about the source code to the JDK. To say that all Java developers are part of the JDK community is like saying all open source C programmers are part of the gcc community.

-matthew

It's all in the Money, Honey

[lon3st4r]

...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 essentially, they want to stay in business - and don't want to give away code for free to competitiors. What if IBM/MS/any_other_company takes their code, repackages it and calls it "Their-Own-Kawa(TM)"? Their lead in the business as the premier Java would be lost.

I think they're thinking at it, purely from a business point of view. And it wouldn't help if the Chinese get a whiff of it (no offence intended).

More fragments

[Tylerious]

Get ready for the fragmentations! Here comes FreeJava, NetJava, OpenJava, JavaOne, FreeJavaOne, NetJavaOne, OpenJavaOne.. JavaFree, JavaOpen, JavaOpenFree, JavaFreeOpen..

Re:C'mon Jeanie! *Please* get back in your bottle!

[Anonymous Coward]

I forgot to mention, you're hi-larious, in the way that retards are.

You feel bad for them, but it's still funny when they jack off in public.

Re:How? Three words:

[Anonymous Coward]

Interesting. Could you please provide a definition of derived work (as opposed to mere aggregation) in the context of Java bytecode and JAR files?

Re:C'mon Jeanie! *Please* get back in your bottle!

[shish]

Well, as a developer, I will tell you THE one and only way to prevent forking and fragmentation...

Don't release the source code.

We've already got Sun java, MS java, IBM java, Apache java, and GNU java -- most of them created because of sun's restrictive licensing.

Compare similarly sized open source projects -- the linux kernel, the mozilla suite, openoffice, X, etc. All those put together have had fewer forks and fragments than java, and in all cases it wasn't so much a fork as a new path, leaving the old to die, returning us to the state of a single good branch.

Open Source Java?

[Anonymous Coward]

And this is the genius of Sun's licensing of Java. Sun, being a fairly poor as a software house, managed to slow down every single one of their competitors that adopted their Java technology. Sun was able through this licensing to dictate the pace of innovation effectively slowing down everyone to a grinding halt.

More here: http://spellchecked.blogspot.com/2006/05/open-sour cing-of-java_17.html