Sun Releases First GPLed Java Source 206
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 if you want to play with it now... MIDPath (Score:5, Interesting)
And people already started hacking it and combining it with all kinds of interesting existing free java projects to product MIDPath [thenesis.org]
Seems the GNU Classpath, Kaffe, GCJ, etc projects really want to Collaborate [wildebeest.org] and work together [wildebeest.org] with Sun according to their latest release notes [gnu.org]. 2007 might be a pretty interesting year for Java and GNU/Linux (and mobile devices!)
so how long till... (Score:1, Interesting)
Congratulations to Sun and Thank You. (Score:5, Interesting)
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' [wikipedia.org].
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).
Re:Its 7:00 AM and its slashdotted (Score:3, Interesting)
Says who? Show me something that says more than 50% of Slashdot visitors are in the U.S. please.
And how do you figure
Something real good I guess! (Score:3, Interesting)
Re:And if you want to play with it now... MIDPath (Score:3, Interesting)
If SUN Java is GPL'd, why would anybody carry on with an alternative version? Do they really thing that they can do better than SUN? Usually they do worse.
Kaffe in particular has been a problem for my project because it lacks some of the library classes that are an assumed part of the platform. Kaffe with SUN's libraries would be much better for us. However, I've yet to see evidence that Kaffe with complete libraries would be better than SUN's own JVM.
The only reasons for continuing that I can see (other than inertia and possibly hubris) are (a) to have alternate reference implementations for bug comparisons (is it really worth the effort); (b) in case SUN change their mind and close the source again (unlikely, and one can always fork the last free version); (c) in case SUN discontinue their own Java product. Maintaining their own JVM must cost SUN billions and doesn't generate revenue directly. Could they be planning to cease development?
Re:Linux is great and all (Score:4, Interesting)
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...
Re:Mono is not compareanble either (Score:3, Interesting)
On the plus side, at least java mostly runs on those systems, which is more than I can say about
Re:Mono is not compareanble either (Score:2, Interesting)
1. HP Commandview SDM (for managing an HP VA7410 array)
2. Cisco ASDM (for managing Cisco firewalls. As of 5.0 they finally got it somewhat right, but it took nearly five years for what I consider a critical app. See my rant below.)
3. Rio Music Manager Lite (for managing the music on my Rio Karma in Linux)
They ALL suck. I mention just those three to illustrate just how broad a sampling of Java applications I've dealt with. The HP Commandview SDM application needed a few HP-UX kernel tweaks in order to perform fairly. Really. Kernel tweaks for a userspace application that SHOULD be part of HP-UX to begin with. Pathetic. I can't even rant about the Cisco ASDM app sufficiently to talk about how much... Let's see, where do I begin?
In the beginning I was handed a Cisco PIX to manage. It was all telnet. Life was good. Then there was an upgrade to the IOS that included a new Java based management tool called ASDM (it was actually called something else at first but I can't remember the name). It was meant to make life "easier". So I tried it. It looked OK. Now I had a GUI to manage the firewall and could potentially do things faster than before at the telnet prompt. Or at least that was the theory. So I had an IP network migration to work on moving one class C network to four class C networks. I couldn't afford downtime. Against my better judgment, our new network person suggested that we just use the GUI to take care of. Halfway through the renumbering the Java app lost it's network connection to the PIX due to exceeding some kind of timeout. That was all she wrote... The config was totally hosed. We lost half of the original config and only had half of the new config. We could restore from our backed up config but we'd lose the entire night's work and have to start over. It had already taken a good six or seven hours to get where we were.
Having had a good deal of experience with the telnet interface and knowing the wonders of X window system's cut and paste I thought that I'd just telnet in and alter the existing rules that way. Wrong answer. To accomadate some new fields that the GUI utility needed, the config format was changed into this horribly broken format that really forces you to use the GUI. The old config format used to contain all pertinent information to a NAT or port fowarding on one or two lines. Now there were multiple lines that gave the IP addresses "friendly" names. bascially labels with ID numbers. And the rules used the ID numbers or friendly names instead of the IPs. The lines that all related to one host or network's configuration were strewn about in the different blocks. So you'd have to find your actual rule, figure out what the ID or names were, see if that matched up to the IP you wanted to edit the rule for, etc... and it you did it wrong, you ended up with duplicate rules in the firewall with only the GUI created one showing up in the GUI and the CLI created one being largely invisible outside of the telnet interface.
So back to the Java GUI. We wound up having to read the old config in a text editor and then poke through even slower than before adding the rules that were now missing. In total we were up and working on this thing for 20 hours straight with downtime for multiple locations that extended four hours into their workday. The reason it was so slow was that the GUI kept crapping out every hour or two and we had to keep picking up slightly behind where we were each time. We saved the configs as we went along but that only shaved off a little time. When waiting for the changes to be applied by the Java GUI we were loathe to just kill the Java app when it took a long time because it gave us no indication as to how far it was in the application of the new rules.
Re:Linux is great and all (Score:3, Interesting)
More precisely, you'd just need the development kit. (Which, granted, is a pretty exclusive club.) Sony already support the micro version of OpenGL, so it shouldn't prove too difficult to port JOGL or LWJGL. Of course, my understanding is that a lot of the graphics programmers develop their own drivers for the consoles. So that part would probably remain unchanged, but with Java thunks. (Unless someone ports Java to the GPU, that is...)
In theory, it should already run on PS3 Linux; albeit a bit slow. I'm thinking more along the lines of running the game directly from a game disc.
BTW, Markus has already submitted his 4K entry [javagaming.org] for this year. Looks like he decided to do a Zuma clone this time around.
Re:Mono is not compareanble either (Score:2, Interesting)
>For starters, it seems, for our dev team at least, anything can be done in the Java world if you throw enough $$ at a "platform" or "Framework"...
>They also like to over develop stuff...
>Most likely a poorly written ap causing some memory buffer to overflow...
>...but I think it has long gone the way of PHP, where most developers have gotten lazy and sloppy.
Re:.NET and Java in the enterprise (Score:3, Interesting)
Personally, I rather find Swing to be one of the best, if not the best, in terms of properly designed API. Its main problem was ugliness and weird look, but Java 6 by and large fixed it, and MS shoot itself in the foot by making WPF - supposedly the next-generation Windows GUI API - look ugly.