Sun Microsystems plans to simplify its Java license for commercial software companies.
Sun looks to sweeten Java License
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This article doesn’t actually contain any information. Why not just wait for the announcement tomorrow?
The Java license was already pretty straight-forward for commercial use where it is easy to include the JRE in products, for example. I guess any simplification would be good, though.
I’d rather Sun stay on the cautious course and keep Java consistent across implementations and platforms as much as possible. There is too much danger from Microsoft or IBM forking Java for Sun to cave quickly into the demands that Java be fully open sourced. At least when Microsoft attempted to fork Java, Sun was able to force Microsoft to go the C# route. While the scope of the consequences of this are debatable, at least the branding confusion that Microsoft wanted to maintain came to an end.
What do you mean by “forking Java”? Microsoft already forked Java (from my point of view), and it’s called C#. Which goes to another point:
What’s the matter in forking Java (in a non-compatible way)? As long as you don’t call it “Java”, it’s fine. Which goes to another point:
Sun could sweeten the Java license, and at the same time maintain compatibility between implementations. They’d just need some “Java Approved” stamp or something like that to approve the different implementations.
Finally, i don’t see the point in simplying Java for commercial use… it’s already “nice” for commercial use.
Victor.
A quick translation given their history says it will not be a truly open license. And for all those about to tell me about “open” Solaris, I ask, where’s the code????
So far Sun is all talk, all obfuscation, no action.
Trust me if they could kill linux and roll back the clock to the “trust your vendor, don’t worry about the details” world, they would, but they can’t.
Sun must use the CDDL with java NOW.
“And for all those about to tell me about “open” Solaris, I ask, where’s the code????”
This question has been asked dozens of times, and dozens of times in reply people point out the OpenSolaris Pilot Program, its real human participants, and the official release of OpenSolaris this summer.
There’s even a timeline laid out at http://www.opensolaris.org.
i don’t know if thats good or bad, i guess it wont affect devs..
anyway, i’m still waiting for j2re1.5 (or1.4.2) to be released for linux/ppc, if that’s ever gonna happen
Few of the free linux distributions ship with java by default because the licensing is incompatable with the debian social contract. Instead they are circumventing java in two ways: Mono and gjc. Mono provides a great alternative to java because it is free and because GTK+# gui building is much more attractive on the client side than the java alternatives. GJC will be a problem for them because it will allow people to compile the few good java programs (eclipse?) and then ship the resulting binaries without actually shipping a java system.
We’ll see how the announcement pans out. I suspect it won’t make all that big of a difference because of the limited range of hardware platforms that the linux java implementations run on. It’s also simply not going to compare to the Mono licensing terms until they open source it. The other problem is that there are several killer mono apps now (Beagle, Dashboard, etc) that would get it pushed into the GNOME desktop, but there’s not such a strong set of client side apps that people would care about.
Michael
The day that Sun works with Debian to get a license that is compatible with Debian’s social contract is the day that I’ll become interested in Java. Well at least they’re trying to improve the situation.
I mean for the end product I do not see the reason to distribute whole jre. If I just put jre along with my application why the hell I can’t just use classes I need?
More some native compilers could compile my program to the executable. I think everyone will be happy with it (I saw many customers saying “I need to install 14Mb to run your aplication of 36kb???”
it has all been worth it. i hate pissing rounf with a new install setting up appz that should by rights be installed already.
Yes, SUN sweeten the license for us. I’m switching to Mono immediately Monodevelop becomes capable, if Java still remains proprietary.
Beyond C# (token ECMA submission), Mono provides no protection against any patents in .NET. While Sun’s Java implementation is not fully open source, there are GNU Java projects that are open source and not at risk of Sun pulling out the patent poison pill on them. Also, it would be fair to say that the completeness of open source Java is similar to the completeness of Mono, so I’m not sure of any genuine advantage of Mono, except to Windows developers looking for an easier way to Linux.
The advantages are as follows:
1). Mono is free software, Java is not.
2). Mono can be easily deployed due to its free license, Java cannot.
3). As a result of it’s free license, Mono can already run on a multitude of free operating systems and platforms, that Java cannot. When are gonna see Java for Linux on PPC64 for instance?
Take a peak at all the resources going into making a free Java platform, that’s all the resources that could have been available to SUN if they didn’t have a phobia for free software developers.
Keep playing games and fooling around SUN, and Mono will soon become the fancy of free software developers. You’ve had ten freaking years to woo them, but you keep fucking up.
> 1). Mono is free software, Java is not.
Java is free enough as it doesn’t carry any price and you can have access to all of the source code related to the Java prlatform. If you want something changed, take part in JCP. Java has a huge ISV backing and any conspiracy theories of Sun “controlling” and keeping Java hostage are a bunch crap from GPL hippies. Mono on the other hand is tangled mess of legal encomberances than mean nothing but trouble — go ahead walk on the mine field, M$ will sue your ass before Mono has any success. Mono is for hippies, Java is for people that mean business.
> Mono can be easily deployed due to its free license, Java cannot.
WTF are you talking about? Java can be deployed no harder anywhere it is available than stupid Mano. Java as a platform does not limit deployments by any license. Talking out of your ass again?
> When are gonna see Java for Linux on PPC64 for instance?
May be you should talk to IBM about that, they are the full Java licensee and is the pimary benefactor from PPC64. IBM has got everything it needs to give you Java for Linux on PPC64 and Sun has absolutely nothing to do with it. It is foolish to expect Sun to port the JVM to all platforms imaginable, this is why the ISV’s implement their own JVM’s based on Sun’s spec, they’ve done it for years (HP, IBM, Intel, SGI, etc. have their own JVM’s for their respective platforms)
> Mono will soon become the fancy of free software developers
Yeah, wishful thinking. Developing for Mono or expecting anything tangible out of Mono anytime soon is like pissing in the wind — it is a selfdefeating effort. Mono will never catch up with .Net and even if it will, M$ will make sure it stops there. Mono is a mess both technologically and legally, it won’t be anything more than just a curiosity.
there are GNU Java projects that are open source and not at risk of Sun pulling out the patent poison pill on them
Sun holds patents on Java and, last I looked, they only say they won’t sue people who pass the TCK. Since it is currently impossible for an open source project to pass the TCK, how is an open source Java implementation any less dangerous than Mono? At least .NET is a real specification.
(If you don’t believe me, read the second paragraph here: http://java.sun.com/j2se/1.5.0/docs/relnotes/license.html)
Anonymous said: “Java is free enough as it doesn’t carry any price and you can have access to all of the source code related to the Java prlatform. If you want something changed, take part in JCP. Java has a huge ISV backing and any conspiracy theories of Sun “controlling” and keeping Java hostage are a bunch crap from GPL hippies. Mono on the other hand is tangled mess of legal encomberances than mean nothing but trouble — go ahead walk on the mine field, M$ will sue your ass before Mono has any success. Mono is for hippies, Java is for people that mean business.”
Ahem, I see you need lessons on what free software is. It is pathetic that a Java proponent does not know Java’s class libraries are closed source and proprietary.
Anonymous said: “WTF are you talking about? Java can be deployed no harder anywhere it is available than stupid Mano. Java as a platform does not limit deployments by any license. Talking out of your ass again?”
Have you been living under a rock?
http://java.sun.com/j2se/1.5.0/jdk-1_5_0_02-license.txt
Seems your ass is the one that’s doing a lot of talking.
Anonymous said: “May be you should talk to IBM about that, they are the full Java licensee and is the pimary benefactor from PPC64. IBM has got everything it needs to give you Java for Linux on PPC64 and Sun has absolutely nothing to do with it. It is foolish to expect Sun to port the JVM to all platforms imaginable, this is why the ISV’s implement their own JVM’s based on Sun’s spec, they’ve done it for years (HP, IBM, Intel, SGI, etc. have their own JVM’s for their respective platforms)”
Don’t be obtuse. We all have the full Java license. Maybe you should spend some time reading and understand it before spouting animal dung. The license is restrictive silly.
Anonymous said: “Yeah, wishful thinking. Developing for Mono or expecting anything tangible out of Mono anytime soon is like pissing in the wind — it is a selfdefeating effort. Mono will never catch up with .Net and even if it will, M$ will make sure it stops there. Mono is a mess both technologically and legally, it won’t be anything more than just a curiosity.”
Funny, SUN zealots said that about Linux 3 years ago. Today, Solaris is struggling to keep pace with Linux.
> 1). Mono is free software, Java is not.
Java is free enough as it doesn’t carry any price and you can have access to all of the source code related to the Java prlatform.
So, in essence, Java isn’t free software. So why are you arguing with him? Because it’s “free enough” for you?
If you want something changed, take part in JCP. Java has a huge ISV backing and any conspiracy theories of Sun “controlling” and keeping Java hostage are a bunch crap from GPL hippies.
Sun is the only entity which can change what is in the base Java distribution. I would say that is pretty powerful. There is also no formal specification for Java which means, without access to Sun’s source code, it is probably impossible to build a fully compatible class library. Go look, every commercial JVM out there uses Sun’s class library for a reason.
Mono on the other hand is tangled mess of legal encomberances than mean nothing but trouble — go ahead walk on the mine field, M$ will sue your ass before Mono has any success. Mono is for hippies, Java is for people that mean business.
And Java is the same legal mine field at this point for any free implementations. Unless you pass the TCK, no patent grant for you. And since there is no way for a free software implementation to pass the TCK … well, you should see where that is going.
Oh, and there really aren’t that many hippies in Morman country (which, for everyone that doesn’t get it, is a statement which is pointing at the fact that Mono’s biggest backer is Novell … not really the pinnacle of “hippies” and rather real business like IMHO).
> Mono can be easily deployed due to its free license, Java cannot.
WTF are you talking about? Java can be deployed no harder anywhere it is available than stupid Mano. Java as a platform does not limit deployments by any license. Talking out of your ass again?
I would guess, since the original poster was talking about free software, that Linux distributors can include Mono without any license troubles. Something coming with the distro is certainly easier to deploy then an after install download.
> When are gonna see Java for Linux on PPC64 for instance?
May be you should talk to IBM about that, they are the full Java licensee and is the pimary benefactor from PPC64. IBM has got everything it needs to give you Java for Linux on PPC64 and Sun has absolutely nothing to do with it. It is foolish to expect Sun to port the JVM to all platforms imaginable, this is why the ISV’s implement their own JVM’s based on Sun’s spec, they’ve done it for years (HP, IBM, Intel, SGI, etc. have their own JVM’s for their respective platforms)
But I thought Java meant WORA. Oh, wait, that’s actually Write Once, Run on whatever Sun thinks is important. I’m going to go out on a limb and bet that if Java was free software, WORA would be a lot more true than it is right now.
> Mono will soon become the fancy of free software developers
Yeah, wishful thinking. Developing for Mono or expecting anything tangible out of Mono anytime soon is like pissing in the wind — it is a selfdefeating effort. Mono will never catch up with .Net and even if it will, M$ will make sure it stops there. Mono is a mess both technologically and legally, it won’t be anything more than just a curiosity.
Well, there are already interesting Mono projects available right now. And who cares if Mono catches up with .NET, all the interesting stuff in Mono is Gtk# and GNOME# and whatnot. Now, that doesn’t mean that Mono will actually become really popular among OSS developers, but to say that it’s a “selfdefeating effort” and “expecting anything tangible out of Mono anytime soon is like pissing in the wind”, well, that’s a bunch of crap that isn’t even true today.
> Ahem, I see you need lessons on what free software is. It is pathetic that a Java proponent does not know Java’s class libraries are closed source and proprietary
Your argument is rather pathetic, you get the source for the Java class libraries with every JDK download. Ever tried looking what’s in src.zip in your JDK download? If you wish you can always reimplement the libraries yourself and quit whining about it. You *can* implement your version of JVM and class libraries if you wish.
> Have you been living under a rock? http://java.sun.com/j2se/1.5.0/jdk-1_5_0_02-license.txt Seems your ass is the one that’s doing a lot of talking.
I don’t think pointing to license file counts as an argument, what exectly in the license you think is restrictive in respect to deployment? I see you’re trying real hard to make a point, but I don’t think it is working.
> Don’t be obtuse. We all have the full Java license. Maybe you should spend some time reading and understand it before spouting animal dung. The license is restrictive silly.
Err, dude what is this drivel you’re trying to pull here. IBM has implemented its own versions of JVM for AIX, OS/400, and zOS. I see absolutely no obstacles to IBM developing a version of JVM for Linux on PPC64. IBM on the other hand chooses to scream about open sourcing Java and other crap instead of getting to business and delivering.
> And Java is the same legal mine field at this point for any free implementations. Unless you pass the TCK, no patent grant for you. And since there is no way for a free software implementation to pass the TCK … well, you should see where that is going.
Java is not a legal mine field and it withstood the test of time for almost 10 years already without any major faults. As for the TCK, that is the whole point of Java — to have standardized runtime environments that *guarantees* to run your code anywhere regardless of the JVM implementation. If it wasn’t for TCK M$ and others would have ran with their own versions of Java making it a complete mess. TCK is one the reasons Java became such a huge success.
So let me get this straight. Sun offers a patent grant on Java as long as the implementation passes the TCK. Opensource implementations of Java will never be able to pass the TCK.
So GCJ, Kaffe, Classpath, etc are not eligible for Suns patent grant. This is better than Mono how?
> So let me get this straight. Sun offers a patent grant on Java as long as the implementation passes the TCK. Opensource implementations of Java will never be able to pass the TCK.
I don’t see a reason why an open source implementation of Java would never be able to pass the TCK. If the implementation satisfies all the rules, requirements, and tests in the TCK, it will pass. It is just none of the open source implementations of Java are good enough to pass the test, you can’t blame Sun for that.
Still a little confused.
—
The open source boys dont have access to the full spec, its either to closed, to incomplete or to expensive, or simply left unpublished to actually build a full implementation of (say) Swing.
Next to that the compatibility testing kit is not available for usage (you are only allowed to delete it, in the last and only public release).
…
Its like this; Sun allows you to re-implement their software so Java looks like an open standard, but Sun does not say exactly what that software does (since the spec is incomplete), does not allow you to find out if it actually is the same (by allowing you to run the compatibilityKit) and Sun is still creating new features in Swing and others on a daily basis without altering the published specification.
—
http://www.javalobby.org/java/forums/m91827375
Is this true?
“how is an open source Java implementation any less dangerous than Mono?”
Even though the OSS Java projects haven’t all passed the compliance tests, Sun has included Kaffe and JBoss, for example, right in their own presentations about Java implementations. There are OSS members of the JCP itself, such as Apache, JBoss, and MySQL. Sun simply has shown no evidence that they have any ill intent towards OSS projects. In fact it seems they try to encourage such projects.
If someone can show me something from a Microsoft executive with Mono in it cast in a positive light, that would go quite a ways in improving my opinion of Microsoft. So far, Microsoft’s track record in playing nice with alternative implemenations is not good (DR-DOS, OS/2, Stacker, Netscape, Samba, Kerberos, MS’ Java, web standards, Office files, etc.).
Anonymous said: I don’t see a reason why an open source implementation of Java would never be able to pass the TCK. If the implementation satisfies all the rules, requirements, and tests in the TCK, it will pass. It is just none of the open source implementations of Java are good enough to pass the test, you can’t blame Sun for that.
You don’t! Well for starters, you must be a JCP member. Membership is anywhere from $2000 to $5000 per year. You must sign stupid and silly agreements, among many other needlessly bureaucratic and frustrating barriers. It is an exercise in frustration. SUN does everything it can to inhibit truly “open” participation. Worse of all SUN owns, manages, and dictates the TCK suite, so you have to do every bloody thing through them. Do you see how SUN intentionally marginalizes free software developers?
“Its like this; Sun allows you to re-implement their software so Java looks like an open standard, but Sun does not say exactly what that software does (since the spec is incomplete), does not allow you to find out if it actually is the same (by allowing you to run the compatibilityKit) and Sun is still creating new features in Swing and others on a daily basis without altering the published specification.
—
http://www.javalobby.org/java/forums/m91827375
Is this true?”
If that were really true, no one would ever be able to create independent implementations and pass compliance tests. Obviously people have (e.g, IBM). Also, Sun doesn’t release changes to Swing daily. They only update their JDK a few times a year, so it seems the people complaining in that thread are exagerating a bit.
Reading that (Javalobby) thread further and this comes up.
—
Sun has not yet published a final, JCP approved specification of, say, all the Java Language and VM changes that happened since 1.2. Instead, Sun decided to cement them as a de-facto standard by the power of their implementation, and maybe, if we’re lucky, document them, and their semantics a few years later. Which is pretty poor performance for something that’s supposed to be a ‘standard’.
A specification for all the different Java Class File format versions, for example, is overdue for more than 5 years now, as far as I recall. Sun never bothered to document those silent, backwards-compatibility breaking changes to the general public in form of a finalized JCP ‘standard’, but they probably were passed on to the licensees, and bread crumbs of information on them are there on various mailing lists, if you know what to google for.
Many of the ‘drafts’ created by the JCP are not released under a license that allows actually implementing them, they are ‘for internal discussion only’. The drafts are pretty useless if the only information about some compatiblity-breaking change is a draft that prohibits implementing it.
The ‘Java is an open standard (for suitable definitions of the words ‘open’ and ‘standard’)’ Sun-speak does get somewhat boring after a few years.
—
Why dosent Sun just publish Java as a real standard like MS did with C#/CLR ?
“”
If that were really true, no one would ever be able to create independent implementations and pass compliance tests. Obviously people have (e.g, IBM).
“”
According to that JavaLobby thread:
—
From reading the licensing stuff on the Sun website, IBM and Apple have actually PAID for a source code license.
—
http://www.javalobby.org/java/forums/m91827451
If that were really true, no one would ever be able to create independent implementations and pass compliance tests. Obviously people have (e.g, IBM). Also, Sun doesn’t release changes to Swing daily. They only update their JDK a few times a year, so it seems the people complaining in that thread are exagerating a bit.
As I pointed out earlier in this thread, every compatible version of Java available right now uses Sun’s class library. There is, to the best of my knowledge, no compliant independant implementation of Java. There are several compatible versions of the VM, but there is no class library spec to implement at this point, how could you do it?
I don’t see a reason why an open source implementation of Java would never be able to pass the TCK. If the implementation satisfies all the rules, requirements, and tests in the TCK, it will pass. It is just none of the open source implementations of Java are good enough to pass the test, you can’t blame Sun for that.
The open source implementation would need to get access to the TCK first. How, pray tell, are they supposed to do that?
SUN tried to standardize Java a few years back, but they had issues with the ISO committee. They wanted absolute control over Java which is in stack contrast with the requirement of a technology becoming a standard.
It’s simple. Java is not open, nor is it a standard. It is run, controlled and dictated by SUN. They don’t give a shit about programmers, and they’ll use Java only to their benefit, as opposed to the benefit of the general users of the Java platform.
Even though the OSS Java projects haven’t all passed the compliance tests, Sun has included Kaffe and JBoss, for example, right in their own presentations about Java implementations. There are OSS members of the JCP itself, such as Apache, JBoss, and MySQL. Sun simply has shown no evidence that they have any ill intent towards OSS projects. In fact it seems they try to encourage such projects.
That’s fantastic. And Microsoft has never preemptively sued someone over patent infringement. It doesn’t change the fact that Sun can sue any open source Java implementation until they pass the TCK. Which, in my book, puts both of them in exactly the same situation … we’re hoping that some large corporation is going to continue to be benevolent. I’d prefer it if it was actually specified in the license.
If someone can show me something from a Microsoft executive with Mono in it cast in a positive light, that would go quite a ways in improving my opinion of Microsoft. So far, Microsoft’s track record in playing nice with alternative implemenations is not good (DR-DOS, OS/2, Stacker, Netscape, Samba, Kerberos, MS’ Java, web standards, Office files, etc.).
Microsoft has talked about Mono in various discussions to show that .NET is an open standard. Again, seems exactly the same as Sun.
If someone can explain how open source Java is any safer legally than Mono, I’d be happy to listen. But this Sun == Good, Microsoft == Bad doesn’t work for me.
> Repeat after me. “The Java class libraries are closed source and proprietary!” The class files distributed with your JDK do not represent source code. If you knew anything about Java programming, development and deployment, you wouldn’t confuse Java class files for Java source code. Reverse engineering the class files is against the law, read the damn license!
Dude are you on crack or something, I’m not talking about class files you freaking moron, I’m talking about the src.zip file that contains the sources for the classes in the Java class library. The fact that you did not know such a basic thing seriously makes me doubt that you know anything about Java development. You sound like you scored your arguments from Slashdot.
> Any of these terms effectively bar Linux distributions, or any free software operating system, from bundling and distributing Java. Oh, and there are a still a magnanimous amount of restrictions that trumps on a free software developers’ freedom, but I’m not going to get into that.
Did you even read the license snip that you posted yourself? You can redistribute JRE all you want if you maintain its integrity and do not interfere with the libraries. What’s so limiting in that?
> You don’t! Well for starters, you must be a JCP member. Membership is anywhere from $2000 to $5000 per year. You must sign stupid and silly agreements, among many other needlessly bureaucratic and frustrating barriers. It is an exercise in frustration. SUN does everything it can to inhibit truly “open” participation. Worse of all SUN owns, manages, and dictates the TCK suite, so you have to do every bloody thing through them. Do you see how SUN intentionally marginalizes free software developers?
I will actually agree with the above, the current practice is not very inviting for the grass roots development with no commercial backing and I hope Sun would simplify that. But any ISV with the exception of the smallest can easily afford to certify their JRE against the Java Compatibility Test Kit. And for big giants like IBM, Oracle, HP, etc. there are absolutely no obstacles on the way to certifying their own JVM’s. IBM chose to bitch and moan about Sun not open-sourcing Java only for self-serving political reasons and not out of some altruistic motivations.
Anonymous said: Dude are you on crack or something, I’m not talking about class files you freaking moron, I’m talking about the src.zip file that contains the sources for the classes in the Java class library. The fact that you did not know such a basic thing seriously makes me doubt that you know anything about Java development. You sound like you scored your arguments from Slashdot.
Oh boy! I give up on you. What about proprietary don’t you get?
Anonymous said: Did you even read the license snip that you posted yourself? You can redistribute JRE all you want if you maintain its integrity and do not interfere with the libraries. What’s so limiting in that?
You cannot. Read the license again, and this time slowly! Especially the clauses in license to redistribute. I don’t know of any operating system that bundles Java on it. Shit, even Windows doesn’t have Java bundled. And for fuck sake, read the freaking article. Even SUN admits it needs to make its license less restrictive to commercial vendors. Sheesh. Do I also need to emphasize the license is non-exclusive, non-transferable and limited. In the license to redistribute section, it talks about the only time I’m allowed to distribute Java. But the did you bother to read the assortment of restrictions? They are laughable.
”(i) you distribute the Software complete and
unmodified and only bundled as part of, and for the sole
purpose of running, your Programs,”
What if I want to bundle it to run other people’s programs?
“(ii) the Programs add
significant and primary functionality to the Software,”
What is significant?
“(iii) you do not distribute additional software intended to
replace any component(s) of the Software,”
Why? What if my program works only by replacing such components?
“(iv) you do not
remove or alter any proprietary legends or notices
contained in the Software, (v) you only distribute the
Software subject to a license agreement that protects Sun’s
interests consistent with the terms contained in this
Agreement, and”
WTF? Why the hell should I give a damn about SUN’s interests?
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) incurred in connection with any claim,
lawsuit or action by any third party that arises or results
from the use or distribution of any and all Programs and/or
Software.”
Haha! You gotta be kidding me!
Given the above, you’d have to be daft to distribute Java, unless you redraft special agreements with SUN, like the big boys do. But what about the little boys?
> I don’t know of any operating system that bundles Java on it.
SuSE, RedHat and Mandrake distribute Java with their distributions without any dramas, same thing goes for IBM with AIX just to name a few. Fact of the matter is you’re not that limited with the distribution of JRE with your software, simply distributing a JRE won’t land you in any trouble.
I don’t think Red Hat or Mandrake distributes SUN’s proprietary Java. Each individual user has to agree to the SUN license, since it is non-transfarable. IBM has exclusive rights to redistribute their proprietary implementation of Java. So they can do as they wish. Novell/SUSE, well, they are big boys. I’m sure they have made sweet deals with SUN to redistribute Java.
And that’s the whole point. I’m not a multimillion dollar corporation. Several free software developers aren’t. SUN what about us? The license is just too restrictive for Java applications and Java to be deployed without fear of SUN hanging me by my scrotum tomorrow. With Mono, there’s no worries. It’s free software. Do as you wish with it, whether you are a big boy or small boy. And I don’t need to join any silly committee to make contributions to the code base, or to tweak it to work on Linux PPC, oh wait, it does.
Java the technologies.
Java the brand.
Java the language.
Java the virtual machine/runtime.
Java the compiler.
Java the platform.
Java the specs.
Java the API.
Java the implementations.
Which “Java” you talking about?
As some of you talking about
Kaffe, which an answer for some of those “Java”s .. like vm.
Or gcj, for compiler. Classpath for api.
But they are all different + govern by different terms/licenses.
I mean if you haven’t yet defined what you will discussed on,
the discussions can go anyway, no direction, ..and actually a bit “no point” to discuss .. since may be you talking about different thing from other people.
While Sun’s Java implementation is not fully open source, there are GNU Java projects that are open source and not at risk of Sun pulling out the patent poison pill on them.
It is true until SUN exists. But if SUN go out of business the new owner of java can sue the open source implementations. And the M$-SUN agreement for their license porfolio IMHO not operative for open source implementations – the M$ also can sue this implementations.
IBM provides JDK 64 bit for PPC Linux and can be downloaded from IBM developerworks site. But IBM Java’s security, encryption is different from SUN’s implementation. Recently I’ve tried to deploy an J2EE application which has been developed using JDeveloper and Oracle J2EE component (BC4J, ADF, etc.),and unfortunately it can only be run on Sun JVM because it’s hard coded to use Sun’s specific security method/class. Even every J2EE implementation from many parties isn’t 100% compatible so we can’t get warranty Java application will run on anything. Perhaps I have a wrong perception about Java.
Which was so far ‘intentionally left blank’ in the SCSL. If you want to use Sun’s source code commercially *in any way*, you need to sign a contract with them (see Attachment D), that costs real hard undisclosed sum of money, and comes with all sorts of fascinating strings attached.
Preliminary J2SE 1.5 source code licensing terms talked about setting that fee to 0 USD for commercial use, as far as I recall, but that wasn’t passed on into the license (SCSL 2.3) yet. They may also chose to liberate some of the really bizarre provisions in Attachement D. That’s as far as I can see Sun simplifying the SCSL 2.3 for commercial use, after praising it for years as the best license ever, as good as open source, and what not
There is an SCSL 3.0, too, which is pretty bogus as well, so if they are in a particularly funny mood, they may announce switching to that instead of SCSL 2.3.
cheers,
dalibor topic
Some light reading:
http://www.gnu.org/philosophy/java-trap.html
There’s been progress with gcj & classpath with Redhat focussing on freeing eclipse and openoffice from “non-free” Sun derivatives.
From the classpath website, they only in November reached JDK 1.0 API compatibility. [JDK 1.1 was released back in 1997!] So as a Java developer I can be confident that my J2SE 1.4 will work on OS X, Windows and x86 Linux using a TCK tested JRE.
(The *BSDs has no TCK endorsed 1.4 ports (yet!) however, they can run Linux binaries through translation)
Perilously, it may work on a GNU JVM, depending on completeness.
Hopefully classpath will catch up and soon become 1.4.2 compliant, including web start/ browser plugin support – if not in a TCK sense at least achieving “API compatible” status, as they claim for JDK 1.0
Then the only Java trap will be as now: as far as I know only Sun’s JVMs support J2SE 5.0 – A quantum leap in terms of the core language.
Peace everyone.
Calm down, pal.
I see absolutely no obstacles to IBM developing a version of JVM for Linux on PPC64. IBM on the other hand chooses to scream about open sourcing Java and other crap instead of getting to business and delivering.
IBM can’t open source Java, AFAIK. Why? Because IBM uses Sun’s class libraries. All the proprietary implementations (IBM, Apple, Oracle, etc) use Sun’s class libraries. And if you use Sun’s class libs, you’re subject to their license.
Basically its like this: Sun owns IBM’s Java.
Do you see now why Sun is the only one who could open source Java? I’m not asking for them to open it (it would be nice, but whatever, i’m tired of this, i’d rather reimplement it). I’m just pointing you to the fact that Sun owns all those Java implementations.
Victor.
The open source implementation would need to get access to the TCK first. How, pray tell, are they supposed to do that?
They are already beginning the process:
http://www.advogato.org/person/robilad/diary.html?start=64
Victor.
Actually, we’re a little bit further since monday, I just haven’t blogged about it yet [1]. I’ve received an inquiry from Onno on behalf of the TCK board for more information, and I am currently compiling it. When I’ve got the reply done, it will go on my blog as well.
cheers,
dalibor topic
[1] Fixing cross-compilation issues for 1.1.5, and tackling a bizarre darwin5 frX vs fX floating point register naming assembler issue atm. Supporting 50+ platforms can be fun ocassionally, but it’s also pretty educational.
… “Recently I’ve tried to deploy an J2EE application which has been developed using JDeveloper and Oracle J2EE component (BC4J, ADF, etc.),and unfortunately it can only be run on Sun JVM because it’s hard coded to use Sun’s specific security method/class. Even every J2EE implementation from many parties isn’t 100% compatible so we can’t get warranty Java application will run on anything.” …
That’s nothing wrong with the Java VM/API itself.
What wrong is the implementor, and all the vendors who use that Sun internal classes (sun.*).
Sun has already explicitly warns developers not to use those classes.
http://java.sun.com/products/jdk/faq/faq-sun-packages.html
(note the date of the document, it’s 1996! Almost ten years that the document is there, but it seems some vendors never read it!)
If anyone like to do any security/crytography thing,
she/he should use the standard java.security and javax.crypto packages.
http://java.sun.com/j2se/1.5.0/docs/guide/security/index.html
If every play by the rules, it will be of course a truly “Write Once, Run Anywhere”.
Code that uses unspecified com.sun classes is not portable per definition, and locks you in into the specific version of Sun’s VM it was written for. Avoid it as good as you can.
It’s pretty unfortunate that Sun has started dragging APIs into com.sun namespace, like JDI or Doclets. Sigh. Left hand, meet right hand …
cheers,
dalibor topic
I think sun.* is different from com.sun.*.
The first one is not supported at all.
The later is supported.
But is not part of the J2SE platform
(It is included in the JDK but not part of the J2SE, see
http://java.sun.com/reference/api/index.html
-> “Non-J2SE APIs included in JDK: APT, Doclet, JAAS, JDI, JDWP, JGSS, JNLP, JPEG, Management Extension, Management MIB, Plugin DOM, Taglet”)
Some of com.sun.* packages are tools for developers,
that once the program is successfully compiled,
the user don’t need them to run the program.
i.e. these packages are not part of the Java runtime,
only part of the Java development kit
e.g. Java Debug Wire Protocol (JDWP) and Doclets, you use it only in development process.
Some of com.sun.* packages are implementation of the standard interfaces.
e.g. com.sun.security.auth.* for javax.security.auth.*
You may see com.sun.* more or less as org.w3c.*, org.ietf.*, org.omg.*, org.xml.* … a “vendor package”.
In this case, the vendor is Sun.
” I think everyone will be happy with it (I saw many customers saying “I need to install 14Mb to run your aplication of 36kb???””
it’s the same thing for .net, mono…
Alright, the folks above really trying hard to put Java in a bad light are just spinning their wheels in the mud. It is obvious Sun’s plan is to make Java as open as possible while protecting that “Java” means that your stuff will _work_. Just think: if Sun fully open sourced Java, Microsoft would take it within minutes, “tweak” it, and then stuff it in Windows Update–and Sun’s lawyers would have to sit on the sidelines! It would be insanity! The only recourse would be some years-long “Antitrust II: Microsoft Never Learns”.
Another reason to use Mono instead of Java on Linux is that Java GUI only works with US keyboards and locale. On e.g. European locales and keyboards various keys becomes untypable. What keys you loose depends on the locale.
This makes java a non option for cross platform development.
For furter info see the Sun bug page:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4799499
This bug is number 18 on the top 25 bugvote list, and it has been around since the introduction of Java 2. If I remember correctly that would be about FIVE years. During this time Sun have occationally closed the bug unfixed.
No wonder Linux developers prefer Mono.
GCJ works very well so long as you don’t use Swing, and since Mono doesn’t have Winforms, I’d say their about even in that area. Both projects are implementing them though. GCJ with SWT or Java-GNOME is a dream.
GCJ + SWT
http://www-106.ibm.com/developerworks/library/j-nativegui/
Java-GNOME
http://java-gnome.sourceforge.net/
Thanks a lot for the clarification. Your explanation sounds plausible. Is there some official specification on/rationale for this confusing naming scheme or some other official source for it?
cheers,
dalibor topic
Hi Dalibor,
read
http://java.sun.com/products/jdk/faq/faq-sun-packages.html
My understanding of com.sun is that those packages are, obviously, written by Sun but not essential to the JVM.
So Swing started as com.sun.java.swing but was (a) too cumbersome an import and (b) included in the 1.2 core.
However com.sun.java.swing.plaf packages remain for L&F implementations. If Classpath creates their own L&F implementations, presumably they’d use a gnu prefix.
In which case it’s bad to rely on these package names if not running a Sun-derived JVM!
from
http://java.sun.com/docs/books/jls/second_edition/html/packages.doc…
“7.7 Unique Package Names
The first component of a unique package name is always written in all-lowercase ASCII letters
and should be one of the top level domain names, currently com, edu, gov, mil, net, org,
or one of the English two-letter codes identifying countries as specified in ISO Standard 3166, 1981.
For more information, refer to the documents stored at ftp://rs.internic.net/rfc, for example, rfc920.txt and rfc1032.txt.”
So I think this clearly said that sun.* packages are not follows the naming convention
(as those packages are not intended to be used elsewhere anyway,
see http://java.sun.com/products/jdk/faq/faq-sun-packages.html ,
.. so no need to follows the convention ?).
Does it convincing?
(hmm… I’m afraid not.)
—-
For me I think what Sun put in the com.sun.* is just the thing that they don’t want it to be part of the Java platform (runtime).
Probably because it is not necessary for the end-user.
Or may be in that area the developer prefers choices than compatibility.
e.g. the cryptography package — if there’s an implementation that offers a crypto that is stronger than Sun’s reference implementation .. developer should be able to use that better implementation (as long as he/she calls it via the standard interface and do include that package with his/her distribution, this is fine).
Or for Doclet package, some developers may like to use XDoclet more. No need to make this as an integrated part of the platform.
Also note that other Java vendors don’t need to make their implementation to compatible with com.sun.*.
As it not part of the Java platform.
To this point, I feel that Sun only try to keep things in their control just as less as possible (just only enough to guarantee platform compatibility).
My conclusion:
java.* and javax.* <— the Java platform (every Java vendor should implement these + comply with spec)
com.sun.* <— just another package/program that runs on the Java platform (the vendor can do anything with that), not different from org.abc.*, fr.test.*
sun.* <— internal package of X company, not intended to be used by others (and also undocumented)
correct me if there’s something wrong
just typing too long,
Pete already answered that.
Thanks Pete, and Danke bact’ for your clarifications.
So I guess it boild down to this:
sun.* -> sun specific, undocumented, always avoid if you want to run on any other runtime. Not part of J2SE API.
com.sun.* -> sun specific, may be specified, may be not. avoid if unspecified if you want to run on other runtimes. Not part of J2SE API.
cheers,
dalibor topic