Open Sourcing Java, why?

Open Sourcing Java seems to be a hot topic nowadays. Everybody wants Java to be Open Source.

Although I am not an expert on the area I would like to express my opinion. After all that's the reason why I'm blogging.

One Java to rule them all

Go take a look at how many different SmallTalk implementations are out there. Quite a few, right?

Go take a look at how many different Scheme implementations are out there. Quite a few, right?

I like Scheme a lot. It's my favourite functional programming language. Simple, efficient, straight to the point. There're lots of implementation dependencies though. Mainly with libraries (although SLIB helps a lot). Open source people have built different implementations of libraries and there're no standards for those. Building a GUI with Scheme, for instance, is different for each implementation. That's a pain in the neck for Scheme. (If you wonder, my preferred Scheme implementation is SISC, a Java based one that can be found here.).

I wouldn't like to have Gnu-Java, IBM-Java, Microsoft-Java (they tried it hard, though) and the like around. It would be frustrating to generate Java code that is not portable between implementations. Filling in code with "if"'s for each implementation, going around implementation specific bugs. I don't like that. I don't think Java users want that either. Nor Sun customers. Nor IBM customers.

Java should be controlled by someone. Sun has done it fairly well during this years. I can't think of a reason why they shouldn't keep on doing that.

Being controlled does not mean people can't build implementations of it. It just means that implementations are controlled whenever they claim to be Java. IBM-Java JDK, for instance, is a perfectly valid Java implementation. So is Blackdown's. Kaffe has little gotchas, so I think (just think) it's not fully Java compliant.

To summarize: I think it's better to have a controlled Java standard. That's good for everyone.

Open Source

I am not an expert on Software Licenses. I know a little bit about GPL and LGPL, and a little bit about Sun Community Source License (SCSL). With SCSL I think you can:

- Download Java sources and modify them.
- Send enhancements and error corrections back to Sun, so they can be taken into account in future releases

Were you using GPL you'd be on the same situation, I think.

With the Java Community Process you can:

- Ask for new features in the Java language.
- Agree with the Java community and discuss with them about these features and enhancements.

So, what is the problem? Is it that the name is "Sun Community Source License" and not "Apache License"? Is it that it's Sun controlling that there're no different implementations instead of any other entity? Which entity should that be, and why? Is it that different companies have to agree with features and standards with the JCP? Who is that bad for?

I try to keep being open-minded, but I just can't understand why anybody else other than Sun should keep Java implementations compatible. Sun has been fair with the open source community for quite a long time. I can export my filesystems through the network thanks to Sun, for free; I can make presentations easily in Linux with Open Office, for free; I can build Java applications on Linux easily with NetBeans, for free; I am safe using Java because it's compatible between Windows, Linux and many other OSes.

I will try keeping to understand why an open source license other than SCSL is better for Java. At the moment I just can't understand it. Too limited I am, I acknowledge.

Comentarios:

on SCSL: "Were you using GPL you'd be on the same situation, I think." yes -- partly true. but in the case of SCSL you have to wait Sun to take your submission, and put it back to the main source. -- if Sun didn't take it, you can't do anything more. for GPL, if Sun didn't take it, you have a choice to distribute your fixed implementation. and yes, that's going back to the issue that you mentioned first .. it may breaks compatibility :( I'm the one who support the "controlled Java", "write once, run anywhere" is the Java value. But just want to tell you that if you like to convince other people, you have to understand GPL first ;) ---- imho, people still trust on Sun for its merit. but the thing that people more concerns about is that sometimes Sun react too slow to big issues. given a real-time Java for an example, the industries want real-time Java, but Sun cannot deliver what they want 'on time', so they have no choice and, in the end, have to go for the "J Consortium" -- http://www.j-consortium.org/ JCP sounds great. But only for big vendor. And the time frame for JCP is may be 'too long' for software world (last time I check, at least 6 month for first draft of proposal). so, imho, there're (at least) two choices 1) No need to open source Java. But Sun should response more quickly to the needs of industries and developers -- anyway, this will cost Sun a lot. And not everything that Java involves can generate income to Sun .. so this is more or less like throwing money away. 2) open source Java with some other license (that is not GPL), that allow to strict the compatibility. And then let the people outthere 'evolve' Java to their needs. -- this way Sun will spend less resources, but also lost some control over Java direction (but not compatibility). from another point of view, this will make Java more ubiquitous. in short words, open source is not that crucial for Java future. but open process (that EASY to join & involve) of Java development is a very important agenda.

Enviado por bact' en julio 05, 2004 a las 06:28 PM CEST #

You say "Being controlled does not mean people can't build implementations of it. It just means that implementations are controlled whenever they claim to be Java. IBM-Java JDK, for instance, is a perfectly valid Java implementation. So is Blackdown's. Kaffe has little gotchas, so I think (just think) it's not fully Java compliant." Releasing the source to the JDK/JVM as BSD or GPL licensed code would not affect Java compatibility requirements. Those two things just aren't related. Sun isn't obligated to allow everyone to use the name Java for whatever they want just because people can modify and redistribute the source code. It's still their trademark.

Enviado por Keith Lea en julio 05, 2004 a las 10:50 PM CEST #

I agree with this blog post. If Sun doesn't control it under SCSL then it would control it under L/GPL, the whole shebang doesn't matter. If you send a patch to Apache that the Apache QA group doesn't like, do they apply it anyway just because Apache is open sourced? I think not. You would have the EXACT same rights you do now if it were "open sourced". The only difference is, now you don't get to call your implementation of Java "Java" unless you pass testing. This debate is a bike-shed issue. Everyone thinks they understand the situation and they just want to have a voice in it all. It's unimportant to my working day. You want open source Java go bloody play with Kaffe. The devs are nice guys. They've already got a leg up on the whole deal. The other thing is, are YOU the open source evangelist going to contribute code? Somehow I doubt it... Just my two cents. :)

Enviado por JR Boyens en julio 06, 2004 a las 01:37 AM CEST #

Fix the license so that every Linux distribution can have Suns JDK installed by default. Something makes this impossible. Java isn't everywhere. I want it to be.

Enviado por Markus en julio 06, 2004 a las 01:44 AM CEST #

I'm sorry, but that's a horrible idea. Why won't a Linux distro install a JDK? I don't see the issue, I'm sure that if they could guarantee a recent version and timely updates Sun would oblige. In any case, changing a software license just to get it installed by default while not looking at the other harm it would cause is careless.

Enviado por JR Boyens en julio 06, 2004 a las 02:25 AM CEST #

Linux distros can't install a JDK because it would mean that they couldn't install gcc. The license states that you cannot ship the JDK on it's own - it has to be with a significant application, and you cannot ship it with any components intended to replace it (such as the Java work in gcc). This is why it is generally disliked. If open source people wanted ANYTHING, it is not the open-sourcing of Hotspot, they could even do without the open-sourcing of the class libraries. What they would like is a) the ability to join the JCP without being forced to be a licensee to the standard SCSL licensed implementation (which would basically mean that they couldn't develop externally), and b) the ability to use the test suite without licensing the SCSL code. People seem to be arguing frequently over this - Sun could make the TCK available to open-source groups to test the compatibility of their implementations, and alter the license that the JDK is under so that it can be shipped freely. If you read any of the free java mailing lists they don't say "oooh, marvellous, yes, we're doing that to fork from Sun", they actually care about compatibility quite a lot. They're also happy to write their own code. But they wouldn't mind access to the testing kit, which is also in Sun's interest as otherwise they may find that compatibility is a pipe dream.

Enviado por Andrew Shuttlewood en julio 06, 2004 a las 03:22 AM CEST #

First off, let me apologize as an open-source developer for the "demands" that've been made on Sun my some members of our community. If it helps, one particular one of these is largely considered a joke in the open-source world, as seriously as he's taken outside of it. Second (if I were being asked) what I'd rather see is for the Java specs to be more open. At present some of the library specs require you to promise not to work on an incompatible or incomplete version in order to read them. This means, essentially, that the Kaffe and gcj developers have to clone something they have no spec for - that's why Mono went so much faster. A lot of the disconnect between the open-source community and the present Java community comes out of a fundamental split: most present Java developers use it as a COBOL replacement, for server-side stuff; open-source guys tend to look on it as a C replacement, for building desktop apps quicker and more safely. That's why a click-wrap web download is such a problem: you can't build core apps in a language if the runtime isn't part of the core install. But to get to your question, open-sourcing the whole thing would allow more testing of new ideas in the field. I think this is one reason IBM wants it (I'm sure you can think of less altruistic ones). They did a lot of work on the J2EE standard, and EJB's ended up being a big pain in everyone's butt. With a looser licensing scheme you might have been able to do tests in the wild before making it a standard, and the whole Java community might have been spared a lot of hassle. Smalltalk is a horrible example of an open-source language; the free versions came well after the language had already splintered drastically. Scheme is a different beast. Unlike Java it's under-specified - libraries are incompatible because there is no standard to follow. Unlike Java it's used almost exclusively for teaching and research; therefore its primary users have no need for compatibility. Perl, Python and Ruby would be better examples: they started life free; their users do demand compatibility, and they get it.

Enviado por S. Hearn en julio 07, 2004 a las 01:07 AM CEST #

Unfortunately the blog is mistaken. There exists at least one very good implementation of CDC/Personal Profile on Windows CE that exists for 18 months already and is not for sale: CrE-ME (www.nsicom.com). This is not because it does not pass the TCK compatibility tests. And it would not help to call the product something else than a virtual machine for Java. It is because CrE-ME is based on code that is not open: Sun's reference implementation. The big problem is called licensing fees. Sun's unwillingness to open-source has nothing to do with standards. That is an excuse. It has everything to do with a narrow-minded business model that, if continued, will destroy Java and give to .NET the very big price that is waiting our there.

Enviado por rene leermakers en julio 07, 2004 a las 05:33 AM CEST #

"I wouldn't like to have Gnu-Java, IBM-Java, Microsoft-Java [...] It would be frustrating to generate Java code that is not portable between implementations." Thats funny; there are 4 versions for \*nix, IBM has at least 3 and the Mac has one. Since you obviously did not see that as a problem; your fear of incompatible Java versions seems kind of unfounded and silly.

Enviado por Thomas Zander en julio 07, 2004 a las 09:20 AM CEST #

Enviar un comentario:
Los comentarios han sido deshabilitados.
About

swinger

Search

Archives
« abril 2014
lunmarmiéjueviesábdom
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Hoy