Slashdot Mirror
Sun Releases First GPLed Java Source
An anonymous reader writes "You can now get GPLed JVM sources from Sun. Everyone seemed to be expecting the desktop version (J2SE) but J2ME has been released first. It looks to be buildable for Linux x86, MIPS, and ARM platforms. Sun now calls it 'phoneME.' Enjoy."
And people already started hacking it and combining it with all kinds of interesting existing free java projects to product MIDPath
Seems the GNU Classpath, Kaffe, GCJ, etc projects really want to Collaborate and work together with Sun according to their latest release notes. 2007 might be a pretty interesting year for Java and GNU/Linux (and mobile devices!)
Pfft, you've got the source, get to work!
And I also want this running on the Super Nintendo this time tomorrow, *snap *snap
- "Scientia non habet inimicum nisp ignorantem"
You are really, really, really comparing apples to oranges here.
Mono is comparable, yes.
However, Qt, GTK and wxWidgets are all just GUI toolkits! You still need a programming
language (Pascal, C++, Perl, even Java(!)) to use these. Installation will be easier,
though. I'm personally looking forward to "apt-get install sun-java" or somesuch.
Also, it will soon (when J2SE comes out) be possible to write better integration with existing
apps, such as better (faster, more modern) browser applet plugins. That, I'm looking
forward to.
(Oh, and now that the sources aer GPLed, it should be really easy to make this thing run on *BSD if it doesn't already)
With great numbers come great responsibility!
Hint: the rest of the world doesnt go on EST. Its not 7am where I am, its halfway through the working day for me - try to think outside your own country, Java usage isnt limited to the US.
While I applaud the Mono team for all their hard work, it is not comparable to Java. Hell, Microsoft's .Net is not comparable to Java yet. With Java, you have a 10+ year old tried-and-true platform. You have 10+ years worth of class libraries written, most Open Source, that eliminate 50%-75% of your workload when writing any application..
.Net does some things better than Java, like Windowing. But Mono's Windows.Forms is brand new and hardly what I could call enterprise-ready.
Sure,
They are freeing up the crown jewels, and the significance of that fact should not be underestimated. Free as in 'gratis' and free as in 'libre'.
I am not a Sun employee, but I am a Java dev., and I would like to remind people of Sun's contributions to open source over the years. While the press communications of executives have muddied the waters, Sun have done more in the past for open source than a certain "Think Free" company. That company pressed for open sourcing Java and then bitched about the choice of the GPL.
I would love to see the source to Websphere (not the Geronimo 'Websphere' product, but the real deal).
${YEAR+1} is going to be the year of Linux on the desktop!
And here was me thinking that the domain name would be more relevant to where the server was hosted/run rather than where its users came from.
"When I grow up, I want to be a weirdo"
I dont have much idea of licensing issues associated with JAVA and GPL but I think it is going to change the things drastically. I guess all the difficulties in making JAVA work properly on a system is only because the open-source vendors can't implement JAVA so freely in contrast with other real open-source things like mono... I hope the JAVA will come properly installed on systems from now onwards and one doesn't need to dig around sun's website to download binaries and then follow some tutorial on internet to set the variables appropriately !
Sun did what nobody expected, opensourced its greatest (both in terms of size and of completeness) and industry leading development platform. Now productivity at the grasp of even the most rabid opensource zealot.
Now what? You are going to tell it's "too late"? I will tell you what is going to happen, Mono has just lost any reason to exist and to be used. It will always be an outdated and slow piece of software, always playing catch up with the latest features of
To properly build executables for the Linux/ARM target platform, a Linux/i386 build platform must meet the following requirements:
* Red Hat Linux distribution version 7.2 - 9.0
* Java 2 Platform, Standard Edition (J2SE(TM)) Development Kit (JDK(TM)) version 1.4.2
* GNU Make version 3.79.1 or later
* GNU Cross Compiler (GCC) 3.4.6 or later
* Doxygen version 1.4.1
* Development Kit for the Java Card(TM) Platform 2.2.1
To set up the Linux/i386 build environment, you must do the following things:
* Acquire Monta Vista Developer Tools
* Set Linux platform environment variables
Acquiring Monta Vista Developer Tools
To build phoneME Feature software for the Linux/ARM (P2 board) target platform, you must acquire the MontaVista CEE 3.1 ADK developer tools.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
The quality of the code varies from source to source. Thus making it sub par. Their documentation is okay, since it's produced from the source code and is shown to the public. Atleast on the .java source. But overall I think their code it crap, but not nearly as bad as Mozilla was. The really irritating thing with the rt.jar source code, which has always been viewable, is that they don't follow their own java formatting conventions. There's going to be a lot of available "Janitorial" positions available once all the code get realeased in March (I think they said march). The only thing that really worries me is the JCP process. Linux works well, because in has a benevolent dictator at the top. Translation, it has a vision/direction. JCP's are commitiees, and that will slow down OS/FOSS development efforts. I imagine/hope that ClassPath will stick around and add features/ be the eqivilent of a development branch. There are things I'd like to see added to that language that would never make it through a commitiee (I just can't spell that word this morning, sorry). But by having a development unstable branch, maybe some of these things can be tried out and proven in the field, then added back into the mainline trunk. The JCP seems to work well, but I'm really curious to see if it can keep up with OS development.
http://www.mhall119.com
I am very happy that Sun Microsystems open sourced its Java and OpenSolaris products. If I buy my own server hardware, I will certainly prefer Sun. Contrast this with Microsoft, which is known for its Embrace-Extend-and-Extinguish practices, its preference to its own shared source licences for the very few lines of code that they ever made public, their aggressive hiring of some open-source people (why? to silence them with dollars?), and shadowy agreements with GNU/Linux vendors. Sun initially tried to use CDDL, but now took a bold step by adopting GPL and releasing actual, useful, working code under it. This means that Sun has open-minded people in its management.
To be serious for a moment, I honestly hope that this encourages ports to the Wii, XBox 360, and PS3. Java is an extremely capable game programming language at this point, and could potentially save programmers a great deal of development and debugging time. In fact, the only thing that's been holding developers back from using Java is that it doesn't port to the major consoles. If that were to change...
Javascript + Nintendo DSi = DSiCade
It's kind of amusing, when you think about it, that what Sun really got out of their lawsuit against Microsoft for their (really, really minor, especially relative to stuff like what Netscape did) modifications to Java was a pure competitor in .NET.
You mention .NET's ability to easily (I'd say "relatively easily") link to native code as a big detriment, but in many .NET implementations that's not used at all. It's easier to work with disparate code like that through a SOAP or database interface. In practice you see a lot of .NET front-ends to traditional servers via a SOAP integration. You see less of it used as a replacement for traditional MFC code, the kind of thing where such integration would be most useful.
But getting back to the enterprise, .NET's largest problem in terms of enterprise software is not that it's less mature than Java (in many ways I'd say that Microsoft took the good stuff from Java and improved it a lot) but rather that it's locked to Windows. Maybe you haven't noticed, but Windows is not a very good server operating system -- not very reliable, not very fast (except in very specialized situations), certainly not scalable. It's all very well and good that you can drop a couple of hundred boxes in there to scale to huge applications, but when you could run the same application on a single Sun you're really not making a cost-effective choice. (I wish I were making that up, but it is actually pretty typical to be able to replace as many as 100 Windows servers with a midsize Sun or two, and that is true not only of stuff like IIS/ASPX versus Apache/whatever that are differentiated by more than OS but also for directly comparable stuff like databases and ETL). Push Windows hard and it will break, often. It's nuts to put it in critical places (although that is done, a LOT, and people pay the price in ongoing maintenance).
Having said that, .NET is probably the single best GUI implementation framework I've seen yet (although that may be damning it with faint praise), and Windows, at least aside from the malware issue, is a pretty fine desktop. In that domain it shows what Java could have been if Sun had been even remotely competent (rather than giving us stuff like AWT and the Swing abomination). We're going to see a lot of .NET on the desktop because it is pretty much best-of-breed. More power to it.
Java is today, and has been since at least the late '90s, often used in enterprise situations. Whether or not it's appropriate in a lot of those situations is debatable, but it is deeply integrated into the core operations of a lot of companies at this point. Personally I feel that JMS is not very good at its job and J2EE as a whole is a steaming pile of dung designed by people who wouldn't know a good application architecture if it ran over their foot, but Java as a whole and these things in particular are out there and being used by a lot of people -- and at least in some cases doing a good job.
It is certainly possible to build robust, reasonably efficient large-scale Java applications. It is even easier to do that in Java than it is in C++, especially if you avoid some of the more ridiculous parts of J2EE. But that doesn't mean it's easy to build that kind of thing, and as you might expect there are a large number of really awful Java applications out there (just as the majority of large applications built on all the other languages out
jim frost
jimf@frostbytes.com