Slashdot Log In
Sun to Fully Open Source Java
Posted by
Soulskill
on Wed Apr 23, 2008 04:20 PM
from the free-refills dept.
from the free-refills dept.
Dionysius, God of Wine and Leaf brings news that Sun Microsystems will be removing the last restrictions on Java to make it completely open source. Sun wants Java to be easily available for use in Linux distributions. We've discussed the steps Sun has taken to open-source Java over the past couple years. From Yahoo! News:
"'We've been engaging with the open-source community for Java to finish off the OpenJDK project, and the specific thing that we've been working on with them is clearing the last bits that we didn't have the rights,' to distribute, Sands said. 'Over the past year, we have pretty much removed most of those encumbrances.' Work still needs to be done to offer the Java sound engine and SNMP code via open source; that effort is expected to be completed this year. Developers, though, may be able to proceed without a component like the sound engine, Sands said.
Related Stories
[+]
Sun Open Sources Java Under GPL 535 comments
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."
[+]
Sun Lowers Barriers to Open-Source Java 144 comments
Shyane writes "Sun Microsystems is making it easier for open-source programmers to ensure their Java versions meet the company's compatibility requirements, but the deal extends only to those involved in Sun's own open-source Java project. The program grants access to its Java Technology Compatibility Kit to anyone with an open-source Java project that is based substantially on Sun's open-source Java software and governed by the GPL. Programmers need access to the test kit to prove that a project is in compliance with the Java specification. Projects that pass Sun's compatibility kit tests also can use the official Java logos for free."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Better late than early (Score:3, Funny)
Kudos to Sun for waiting so long to open source it. Had it been FOSS back when my company was trying to decide what language to standardize on, we might have picked it instead of Python. Thanks!
Re:Better late than early (Score:5, Informative)
Parent
Re:Better late than early (Score:4, Interesting)
Parent
Re:Better late than early (Score:4, Insightful)
We were looking for something cross-platform, and at that time Java was every bit as proprietary as VB and other close dead-end languages. I understand why Java wasn't FOSS at that time, but that still made it ineligible as a serious contender for long-term development. Had Sun made Java's openness a goal a lot sooner, many companies (including mine) might have chosen it over whatever else they decided upon.
Parent
Re:Better late than early (Score:5, Insightful)
Who cares? We're a company, not a bunch of broke kids, and don't have problems spending money if we need to. "Free as in speech" is much more important to us than "free as in beer", even though the lack of price tag is a nice bonus.
Parent
Re:Better late than early (Score:5, Interesting)
Parent
Re:Better late than early (Score:5, Interesting)
The big problem has been Sun's corporate mindset. Until recently, key decision makers at Sun, both on the business side and the R&D site, seriously believed that they were smarter than everybody else, and had no need to listen to anybody else's ideas. That's why Sun stuck with SPARC processors so very long after it became obvious that commodity processors were the future — SPARC architecture is superior to x86, end of discussion. It's also why Sun's first attempt to move to commodity systems (by spending $2 billion for Cobalt Networks) was a total disaster: the Cobalt people couldn't get any respect from the rest of Sun, and quickly moved on. I can think of many other examples.
I was a contractor at Sun/JavaSoft in '98, and saw this attitude all over the place. In some cases, I couldn't get access to the FrameMaker source for key specifications because the spec owners feared "forked" copies of the specs!
The really sad thing is that many of these people were every bit as smart as they themselves thought they were. But their raw intelligence was often wasted, because you need a certain willingness to collaborate to create a real product.
I recently came back to Sun as a regular employee. I like to think this intellectual arrogance is no longer a major problem here. Part of this is the example set by current upper management, which seems to understand the problems I describe. But the big reason: most of the my-way-or-the-highway geniuses have been hired away by Google.
Parent
Re:Better late than early (Score:5, Interesting)
Parent
Re:Better late than early (Score:5, Informative)
Sun thought that Java was going to be the Next Big Thing
And rightly so considering the last 13 or so years of development in the industry.
Java lost a lot of ground in the back-end space to Python, Ruby, and others
I'm going to go out on a limb here and say that this remark is probably only true regarding FOSS projects. Looking at this statement from a commercial development point of view is another ballgame entirely.
Job search hits from Dice.com
Lets be honest, the industry as it currently stands runs on Java and .NET. This is not to say that OSS and the languages mentioned above are not gaining ground quickly, but I think its important to keep a historical perspective regarding the status of Java. Java really was/is the Next Big Thing, and it will almost certainly become the next COBOL in terms of the amount of code which will need to be maintained decades from now.
Parent
Re:Better late than early (Score:4, Funny)
Job search hits from Dice.com
Java [dice.com]: 15786 jobs
Python: [dice.com] 1395 jobs
Ruby: [dice.com] 757 jobs
C/C++ [dice.com] 6283 jobs
BTW, same site says:
Excel: 10742 jobs
Coffee making: 22 jobs
Micromanagement: 96539 jobs
Yelling on Employees: 1 job (Junior Technolohist)
Parent
Re:Better late than early (Score:4, Funny)
What, you meant static typing check on function declarations? Well, you can have that in Python [oakwinter.com], too. But I can't see how that single feature can make a language suitable for enterprise work.
Parent
Re:Better late than early (Score:5, Informative)
Uh, huh. A quick reality check over at dice shows number of jobs for java = 15831, number of jobs for python = 1396, number of jobs for ruby = 759. The same search over at Monster shows number of jobs for java > 5000, number of jobs for python = 1256, number of jobs for ruby = 663.
Did we forget about this [news.com]?
Parent
Re:Better late than early (Score:5, Informative)
Sun was talking about open sourcing java for many years, but it was only fairly recently (december 2006) that they actually annouced the license they planned to use and gave us a little taste of code (not that said code was much use on it's own). and promised all of the JDK "except for a few components that Sun does not have the right to publish in source form under the GPL" would be released by march of the next year
Then when it came we discovered that those few components included serveral major parts of the graphics subsystem. Progress to getting high quality replacements for those components and getting them into the official codebase has been rather slow and is still not complete.
Also it was only last febuary that they opensourced anything from the java6 codebase, before that everything they released was from the java 7 alpha codebase, hardly ideal for production use (though a couple of linux distros shipped the code anyway because they considered it better than nothin).
This article doesn't really tell us anything we didn't know already.
Parent
Re:Better late than early (Score:4, Funny)
Dear moderators, i would like to take this opertunity to perform a little victory rickroll as seen here [youtube.com]
For the record OO, also has a clause that stops it being fully GPL, thats why neo office code cant be used, because sun want to take open source contributions and use them in their proprietary version of open office
Go on mod me down, it will only make me stronger
Parent
Re:Better late than early (Score:4, Interesting)
You say that as though there's a difference. We were migrating from a legacy codebase in Visual FoxPro, and learned well the lessons against using sole-provider solutions. The absolute last thing we were willing to do was throw ourselves again to the mercy of someone else's whims. With Python, and now Java, we get to keep some of that control.
Parent
Re:Better late than early (Score:5, Insightful)
Dead last?! Spoken like someone who has never been fucked over. Just wait 'til a proprietary compiler/runtimelibrary vendor tells you, "No, we're not ever fixing that. And you can't fix it, either." It's even better when you have to tell the same thing to your client.
Sympathies to the FoxPro guy. I was once a Clipper guy. I don't know whether the availability of maintenance is number 1 or 2 on my list, but it's waaay up there. Never again. Never fucking again will I have that kind of shit in my life. I'll get out of IT and flip burgers for a living, before I write another line of code that has miserably crippled and hopelessly unmaintainable dependencies.
Parent
Re:Better late than early (Score:4, Interesting)
That is exactly how we feel about it. FoxPro certainly isn't my choice of development environments, but our old code runs - and runs well. The only reason we're migrating away is that it's officially a dead language, and it's crazy to keep developing on something whose owner has said has no future.
So that's how we ended up on Python. Java probably would have done most of the same stuff, and it'd probably be easier to find Java programmers where I live, but we weren't going to fall sucker to that problem again.
Parent
Re:Better late than early (Score:4, Insightful)
By "we" he probably means "a group of knowledgeable developers who are lucky enough to be employed somewhere that they can choose the best tool for the task instead of having to go with whatever the PHB thinks is the hot buzzword this week." It's very true that the "real world" can be a difficult place, but people with attitudes like yours don't help make it any better. Fortunately, there are businesses where management knows enough to get the hell out of the way and let the developers make their own decisions on which tools to use.
Parent
Kudos to them, I guess (Score:5, Interesting)
Re:Kudos to them, I guess (Score:5, Informative)
Also, if you read the article, you will see that the new and improved Open Source Java will be missing some features (ie sound). So this isn't so much open-sourcing Java as it is removing the last offending bits that cannot be open-sourced and hoping they will be coded back in.
Just my $0.02.
Parent
Re:Kudos to them, I guess (Score:5, Interesting)
I suspect I'm with the majority of
Parent
Re:Kudos to them, I guess (Score:5, Insightful)
Not caring about licensing questions probably means that you've failed to consider them in depth. That probably seems like a very reasonable choice - if you wanted to worry about legal issues you would have gone to law school - but it's also very short sighted.
"Freedom" seems abstract and irrelevant until you find out that the elegant technical solution you want to implement is disallowed by the license of some component you're using. This rarely happens immediately, because you wouldn't have picked a tool if it didn't let you do what you initially wanted, but it comes up pretty frequently when you try to do something that you didn't initially consider.
Examples:
- You design your application using Oracle as the database. $20,000 a server seems fine - until you realize that the whole design would be more elegant if you moved a bunch of logic into the database and replicated it a bunch of times (say... at each client site). But $20,000 * 100 sites isn't in the budget, so you're forced to scrap the best technical solution for legal reasons.
- You design a data entry interface in Flash. The project expands, and it turns out that it'd be more effective if the users used tablets rather than PCs to do their data entry. So you bring on a hardware team, and they tell you that ARM tablets cost 1/3rd what x86 tablets would cost. Sadly, there's no flash player on ARM - and with your budget it would have been a simple port, too.
Far from being irrelevant and abstract, the issue of licensing is directly relevant to anyone selecting software to build anything important (software or any business process). Proprietary licensing means usage constraints - both explicit constraints like the limited set of Flash platforms and economic constraints like the per-server Oracle license fee. Developing on proprietary stuff is like working in a mine field - sometimes you have to do it, but it's sure as hell something you want to avoid.
Parent
Re:Kudos to them, I guess (Score:5, Insightful)
Seeing into the future is *really hard*. Given a choice between a proprietary platform with potential future licensing woes and a high quality free platform, selecting the free platform simply due to licensing is a good first approximation at the right choice.
Parent
Re:Kudos to them, I guess (Score:5, Informative)
Before I bought my Mac in summer 2006, I was a FreeBSD user. At the time, FreeBSD users were not able to download FreeBSD binaries of the latest versions of Java due to a licensing agreement IIRC; instead, they had to either download a binary of the older version, download the Linux binary and use FreeBSD's Linux binary emulation, or download the source code of Java (with a very restrictive license) and compile it, which took a long time. Now that Java will be fully open-source in the near future, life for FreeBSD users (as well as other platforms where Java is unsupported) would be much easier, as pre-compiled binaries would be allowed to be distributed without Sun's permission. A lot of us don't have the time to waste multiple hours compiling software.
Parent
Re:Kudos to them, I guess (Score:5, Funny)
And the rest of us use Gentoo. If this new "open source" Java takes less than a week to compile, I will be extremely disappointed in Sun's efforts!
Parent
Re:Kudos to them, I guess (Score:5, Funny)
Now those children blindly agree to the somewhat less arbitrary GPL which they are incapable of understanding.
This is truly a magnificent day!
Parent
Re:Kudos to them, I guess (Score:5, Funny)
Parent
Re:Kudos to them, I guess (Score:5, Insightful)
I suspect that the closed sourcing is also why support for Java on non-priority systems has lagged behind. It's been a while, but I used to support Java apps that were running on FreeBSD. At the time, the state of Java there lagged behind the big three (Linux, Windows, Solaris) considerably- the latest versions of of the JDK/JRE weren't always available, and when they were there were sometimes weird bugs lurking in them that would cause applications to puke. Support for other languages wasn't anywhere near as far behind because it was much easier for BSD developers to track changes in the source of languages that primarily targeted Linux.
For that matter, despite Suns attempts at making Java a universal platform, support on some platforms has been better than others. My employer bought a 3rd party Java HR application for employees to use for leave/VK time reporting, with the promise that it would work for any system since it's Java (a lot of people have Linux or Mac). No such luck. It's interface is an applet that works on only certain versions of the JRE under windows. Maybe the vendor is just incompetent, but Java is supposed to simplify the writing of cross-platform applications. I strongly suspect that these kinds of problems are a consequence of Sun keeping the source closed: priorities on development of the JRE/JDK had to be constrained by Sun's resources and economic priorities. No matter how enthusiastic the user community on lower-priority operating systems, they couldn't fix problems themselves.
Parent
Re: (Score:3, Insightful)
Re:Kudos to them, I guess (Score:5, Insightful)
Parent
Re:Kudos to them, I guess (Score:4, Interesting)
I installed ejabberd, an Erlang-based Jabber server on FreeBSD this week from ports. For some reason it needed a JDK to install. Normal ports installation didn't work because FreeBSD doesn't have a distribution license. I had to download the file manually, put it in the right directory, then go back to the Sun website, register an account there, log in, download a timezone update, and put that in the right directory too. Only at that point could I install it. And I didn't even want Java in the first place!
The whole process was pointless (it's not like my manual downloading gained Sun anything worthwhile) and felt like a throwback to downloading Slackware floppy disk images back in the early 90s. Every other piece of software I've installed through ports has been downloaded and installed automatically, like it should. But because of this idiotic imaginary property idea, I've got to mess around trying to make the computer happy instead of it doing work for me. This is 2008, I shouldn't have to jump through hoops for bullshit reasons.
Parent
Re:Kudos to them, I guess (Score:4, Informative)
And the reason for that is that Sun grants special permission to Linux and OpenSolaris distributions to do so under the DJL [java.net]. From the FAQ [java.net]:
See FreeBSD listed there? Have a look around the site, every single mention of operating systems permitted under this agreement is specifically scoped to Linux and OpenSolaris only. That's why Ubuntu has a head-start on FreeBSD, not because they are better at packaging.
Parent
Re: (Score:3, Interesting)
And because Java itself wasn't in any of the distro repositories, no program that depended on java would be in the repositories either. So any java program I wanted to run was going to be annoying to install, so I would often try and find an alternative in a more usefully supported lan
Re:Kudos to them, I guess (Score:5, Informative)
Parent
Re:Kudos to them, I guess (Score:4, Informative)
You talk about "trouble competing" - it hasn't had to compete. There is no choice, in the minds of management everywhere. It has been a massive, enormous success (measured in terms of penetration) in the enterprise, and there are so many lines of deployed Java running everything from corporate IT to banking to network management systems that it is truly astounding. Most of it sucks, of course, but my point is that your comment implies Java is on shaky ground in terms of acceptance, and that is totally naive, particularly in the corporate world. When I go to meet clients about projects, there is no debate about which language we're going to use, unfortunately. It is a de facto corporate standard.
And even for the web front ends, I see GWT getting more and more popular, so who knows. When Google makes their contractors use a particular technology, it tends to leak out and get deployed all over the place as those contractors become enamoured of it.
Parent
MySQL (Score:3, Insightful)
Re:MySQL (Score:4, Insightful)
Parent
Re:MySQL (Score:5, Informative)
Parent
What fate awaits GNU Classpath? (Score:5, Interesting)
jdb2
Re: (Score:3, Informative)
What, (Score:5, Funny)
open source vs license questions (Score:4, Insightful)
Does this mean the Classpath exceptions will be removed? Not clear. Kind of a problem for some if it is removed.
FTA: "Once Java is 100 percent open source, it can be shipped as part of Linux, Sands said. Ubuntu has distributed Java as separately available commercial software, he noted. But once Java is fully open source, it can be offered as part of the free Ubuntu distribution and other Linux variants, Sands said."
For me, and I assume most people interested in open development platforms - the real question about using Java will be around the license (once it is open source) and what that means in terms of success, options, and longevity for the projects we build.
Will this mean a 64-bit plugin sooner? (Score:5, Informative)
Re:Will this mean a 64-bit plugin sooner? (Score:4, Interesting)
IcedTea works pretty well on my X64 Debian system: http://en.wikipedia.org/wiki/IcedTea [wikipedia.org]
I still have a Sun 1.6 JDK installed, which I use for all my development work; however, IcedTea is my default JRE, and I've not had any issues so far. It's eased my need for a Java plugin. no more 32bit firefox^W Iceweasel for me!
Parent
Browser Plugin (Score:5, Interesting)
Let's bet on how many PR they can generate! (Score:4, Insightful)
Re:What will happen to GNU Java? (Score:5, Insightful)
Parent
Re: (Score:3, Interesting)
I still want to know when the ARM hardware support for Java will have public specs: Jazelle, as found on ARMv5TEJ and ARM6 cores. The ARM926ej-s cores (ARMv5tej) are some of the most widely used ones. ARM6 is found in Nokia N800 series. Until Jazelle specs become available, none of those chips can leverage the hardware support for Java using a GPL'd JVM. They have to buy a JVM from somewhere else. This affects the JVM used with Android, for one example. It increases the runtime footprint of JVMs on e
Re:Sun's source code (Score:4, Funny)
No good, you wouldn't be able to see it when doing a nightly build.
Parent
Re:This is good news... (Score:5, Insightful)
Major distros will ship proper java by default (some already are shipping java builds based on the code sun has released so far with bits from elsewhere to try and plug the gaps) and they will be able to patch it themselves to backport security fixes or fix issues with new versions of libraries (there was a bad one involving sun java 6 and a new version of some library recently, I don't remember the details but I do remember sun took ages to get a fix out).
Parent