Sun Open Sources Java Under GPL
prostoalex writes "The embargo is off, and Associated Press is reporting on Sun releasing Java under GPL. Sun is hoping that this step will attract more developers, as well as extend the lifespan of Java. The article notes that this is 'one of the largest additions of computer code to the open-source community', and that Java is currently being run on something like 3.8 Billion devices worldwide." From the article: "Rich Green, Sun's executive vice president of software, said the company hopes to turn more developers into Java programmers, who may then create additional software to support Sun products. 'The open-sourcing of this really means more — more richness of offerings, more capability, more applications that consumers will get to use,' Green said. 'The platform itself will become a place for innovation.' All the Java source code is expected to be released by March 2007, Green said. The move covers all Java technology, which includes software that runs on handheld devices, personal computers and servers."
Well, on a more practical note, this means that within a few months, I should be seeing a real, complete, working JRE sitting in the main repositories for Debian and Ubuntu. Sweet. We no longer have to go and fetch it ourselves or experiment with incomplete toolkits.
For the ideologues, knowing that there's one less piece of non-free software on your system is a real comfort. For me, personally, all that apparently remains are ATI drivers and Flash Player.
Yay!
~ C.
Sorry to pick on you, but you're the first person I've seen do it and there aren't too many comments on the article yet, so I thought I'd get in quick:
Java is not an acronym, its name should not be capitalised.
It's a minor thing I know, but I'm picky and pedantic enough* for it to irk me every time I see it.
(* goes with the territory; I'm an ex-physicist who moved over to programming. Equations and computers do not know what you mean, only what you say)
It's official. Most of you are morons.
Some more articles I have found, with some substance to them:
InfoQ, also mentions Glassfish.
eWeek.
There is also going to be a official webcast about this by Jonathan Schwartz and Rich Green 9.30 a.m. PT.
In related news, apparently Project Looking Glass, the 3d desktop, is likely to be included in the Ubuntu Feisty release.
Being bitter is drinking poison and hoping someone else will die
Linux Devices has a fairly comprehensive list of just what technologies 'GPL Java' encompasses. The std libraries are GPL with the classpath extension.
http://news.zdnet.com/2100-3513_22-6134584.html?ta g=zdfd.newsfeed
Comment removed based on user account deletion
Java Standard Edition libraries will be licensed with GPL2 + Classpath Exception which permits linking with non-GPL applications. So there isn't any problem if you don't want to use GPL compatible license for your Java SE programs, you can still use and distribute GPL Java with it.
From what I have read, it seems that Java will be dual-licenced, so anyone that do not feel good about GPL can use commercial licence. It seems like a win-win situation to me...
I have quoted two soundbites on my blog from videos that will be shown at the announcement tomorrow (the quotes are from the information that was (I believe) given to the press.
I've seen the video shorts (well some of them) that will be shown at the announcement. I think some folks will be surprised. RMS also makes reference to the java trap.
Tp.
Python is byte-compiled and executed too. That's what all the .pyc files are.
Java is as low level as PHP, and I don't know what the parent poster was referring with it being "more low level and general purpose". True, it is one of the big 3 with the 2 C's, but i'd say it's more specialized than Python. Few things make Java worthwile and console programs ain't one of them, for example. And more low level? Than what? Java is pretty much as high as you can go.
Azureus is the leading resource client because people really *must* have all the flashy graphics that show how much of a file is done in 47 shades or yellow, orange and green.
My english is sow-sow. Sowhat?
You've been able to do that for years - just not under an Open Source licence. Sun have provided the entire JDK source (including the VM code) under their own Sun Community Source Licence (see http://www.sun.com/software/communitysource/j2se/
You need a bunch of binaries to get it bootstrapped (i.e. it requires Java to build Java) but the result is entirely compiled from the source you can get from the above site.
GPLing it is a change of licence terms, not a change in the actual availability of the source.
Yes, Java Standard Edition libraries are licensed with GPL2 + Classpath Exception
Open source here has the same connotation as red communism.
You gotta love it when they compare a volunteer project built entirely out of free will to government which of course is founded on the principle of coercion.
Really, are these people off their rockers? Open source wouldn't be open source if everybody was forced to contribute -- it would be just another subsidy of organized coercion. What makes open source remarkable is that is founded on and depends on people contributing voluntarily -- they want to do it for themselves, not because some government is threatening them with prison or worse.
Just to make it clear: Java is going to have the GPL with the Classpath-exception, which explicitely allows to create closed source applications when using the standard libraries.
See Gosling's blog:
http://blogs.sun.com/jag/
and here you'll find the mentioned exception:l
http://www.gnu.org/software/classpath/license.htm
Richard Stallman discussed this in a Nov 1st interview. I've put a transcript online.
Please help publicise swpat.org - the software patents wiki
I want a GPL'd latte :-(
No need, latte is already distributed under a BSD license, which is GPL compatible.
Mozilla wouldn't let them ship a patched version while still calling it Firefox, and Debian want to make sure it works on all architectures they support, has security fixes backported, etc., none of which Mozilla can be bothered to do.
GPL does not prevent forking (and some forks will develop due to $$$)but if the forker abides by the GPL he has to publish his code for the forks, so Sun could have incorporated those changes making Sun java compatible with MS-J.
Not necessarily:
1. GPL doesn't require patent licenses to be granted.
2. Most of the modifications MS made to their Java implementation wouldn't have worked for Sun because they were heavily dependent on features of Windows that aren't present on any other OS. Sun could've easily reimplemented compatible extensions to Java if the only issue was access to MS's code. They didn't because doing so would have violated the spirit of Java as a cross-platform language.
Java will have the same the same exception to GPL for its classlib as GNU Classpath, so the GPL will not have any effect on code running in the JVM. (It has even fewer restrictions than the LGPL that forces derived works to allow reverse engineering)
Spelling/grammar nazis welcome (English is not my first language and I am trying to improve my spelling/grammar)
I wonder what is going to happen to these three projects?
GCJ will survive because it provides a facility that doesn't exist in the standard JDK (i.e., ahead-of-time compilation).
Kaffe will survive because it's BSD licensed.
Classpath will initially try to survive by copying large amounts of original Java code into itself, but I suspect will eventually become irrelevant as patches for classpath-using applications become available to allow them to use the original Java class library.
Let's hope now Java integrates all the good features of C#, like true generics.
That's easier said than done. A stable binary platform is important to the success of Java, and I suspect implementations of this kind of thing (of which there will be multiple) will result in a forked, fragmented platform with multiple implementations incompatible of interoperating with each other. Then an official Java distribution will pick up new features at probably only slightly faster rates than the current one, and the best of the features will be backported. We'll see slightly accelerated improvements in "official" Java because of the interest, but nothing dramatic, is my guess.
Java is NOT strictly interpreted language. HotSpot (http://en.wikipedia.org/wiki/HotSpot) mechanism dynamically compiles bytecode into machine code.
In theory, Python has Psyco that can do JIT-compiling, but in practice dynamic nature of Python prevents most of optimizations.
Debain wanted to distribute their own patched version of Firefox, the Mozilla people didn't want to get blamed for all the bugs introduced by Debian, the name change was the way to resolve that conflict.
My own sympathy goes unreservedly to Mozilla, as a software developer I know what a total pain Debian is to deal with.
With this step, SUN has became the largest commercial contributor to the free and open source software pool. OpenOffice.org, OpenSolaris, now JAVA - well, kudos!
NFS... Netbeans... JXTA...
Sun has been the biggest commercial contributor to Open Source for some time now... this just makes it even more so.
I see a couple of benefits of the GPL, namely that my favourite distributions can now supply Java as a standard part of the distribution, and that I should probably now be able to easily get ports of Sun Java to platforms I want to use (whereas I was limited to IBM or an older port from Blackdown before)
Sun can still maintain control over "Sun Java", which is what most people will use. Sure, people could fork and deliver versions that break the tests you mention, but it is unlikely many people will use them. There are forks of most major GPL packages out there, but for the most part people stick with the main tree.
The other advantage the GPL has over the existing Sun licences is that many people are unable to look at or work with the code from Sun because their employer forbids them. GNU Classpath is an example of this in open source - cleanroom implementations only, no peeking at the Sun JDK source, and make sure you don't sign any NDA's on the way.
I meant suitable as a Linux compatible license. Now distributions can include the JDK without conflict. Personally, I find Java's performance, stability, security, and reliability to be just fine.
And I want a link that doesn't crash Firefox 3 times in a row ...
I don't know what's on the page that's so evil for Firefox under Linux, but I had to open it in Epiphany to see ... meybe its another hint for me to get SuSE off my hd ASAP.
I haven't tried JSF, but I'm the sole maintainer of a Struts application. It works reliably, but changes are a pain in the behind.
s /Stripes+vs.+Struts
I have zero experience with the Stripes web framework, but this comparison between Stripes and Struts has an excellent illustration of the klunkiness of Struts: http://stripes.mc4j.org/confluence/display/stripe
"One of my prime frustrations with Struts is the fact that just to implement a single page/form, I have to write or edit so many files. And I have to keep them in sync, or else things start going horribly wrong. With Struts I have to write my JSP, my Action, my Form, a form-bean stanza in the struts-config.xml, an action stanza in the struts-config.xml, and if I'm going to do it the Struts way, a bunch of forward stanzas. And let's not go into the fact that since this is all stored in one xml file I'm continually facing merge conflicts with my team mates. Yes, there are annotations for Struts, but they are just literal translations of what's in the XML file, and they don't feel natural to me."
You may with to learn Struts anyway, because it's so common. But if you're builing a new Java web app from scratch and no one on your team is used to Struts, I'd investigate alternatives. The Struts project page even lists a few under the 'Similar Projects' heading. Now, extensibility, stability, and other buzzwords matter just as much as ease of initial configuration. So don't use speed of initial development as your sole criteria.
1. GPL doesn't require patent licenses to be granted.
If you redistribute code under the GPL, you give all the recipients rights to all the patents they need to actually use the code, and they can pass those rights on to others.
You have to remember that you are starting up a full virtual machine environment. That is going to have lots of overhead, especially at initialization. Anyone who expects to run "Hello, World" programs efficiently is a fool.
Java really does well with big server apps, where the cost of initialization can be amortized over a long period of time. Additionally, JIT compilation and live profiling really work well here.
Server apps really do well with Java. There are fewer opportunities to create difficult to track bugs, memory management handles the fragmentation issues, etc. The performance delta between a C++ and a Java server app is often fairly negligible* while the development time is often substantially faster and it is easy to move to other platforms.
* - A well written C++ app built for a generic processor architecture and a long running Java server app will frequently run about the same. The C++ app is stuck with the tuning choices made at compile time, while JIT and profiling available in Java will tune the Java app at run time, making up for the overhead of the virtual machine. If the "Gentoo" model is followed - the compiler is carefully set to provide maximum performance for a given machine - the C++ app can run substantially faster. However, the cost is that the binary can no longer be moved to a similar but not identical machine without rebuilding. This tuning activity typically requires lots of time and expertise, and generally makes environmental management efforts prohibitively complex. These solutions don't make their way into most real world environments.
Google uses Java a lot more than they do Python. The only people who bring up the Google-Python argument are people who either don't work for Google or don't know anybody who does. Within Google, Python is most often used for small scripts and internal applications that never go public. Almost everything else within Google is done with C,C++ and Java. Google has even made significant moves to standardize on Java.
C++ is not C++/CLI. C++/CLI is irrelevant outside of Microsoft corporate headquarters.
Irina Romanov
Am I the only person salivating at the possibility of writing code that will compile down to full binary on any platform and make use of hardware for graphics acceleration now, and possibly other things (GPU computational engines, anyone?) later?
Probably. You already could compile Java to virtually any platform using GCJ. Compiling the code to a native format doesn't help in accessing graphics accelerators, that's more a function of having the right libraries available.
IMO, the biggest advantage here is for the community to enhance the JVM, and include a fully functional JVM and Java libraries in Linux distributions. This also means that Java code that's already under GPL could also be included in these distributions. GPLed Java programs can now also ship the JVM with their programs, if they so desire.
That's a flash 7 bug. export XLIB_SKIP_ARGB_VISUALS=1 somewhere.
It's not a restriction, the one accepting the license gets more rights than from pure GPL.
I, for one welcome our new Duke overlord.
Well, he has been open sourced too, so there really is no escaping!
Being bitter is drinking poison and hoping someone else will die