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."
...as opposed to phoneFE?
...to "can you hear me now?"
The opposite of progress is congress
Whatever happened to 'hopscotch pheromone sidewinder'?
Not for enterprise or OEM Linux. It can now ship out of the box without any legal or community concerns, right on time for the "2007 will be Linux on the Desktop" comments. Isn't this what was wanted all along? finally it happens and everyone criticises it. At least it wasn't CCDL.
I never get used to these constant resurrections
Well yeah, phone you too!
Where's the love for FreeBSD, OpenBSD, and NetBSD? :)
As for the "from the beginning-of-an-era dept", give me a break. This is nothing more than Sun trying to ensure that Java stays relevant, with the greatest stability of other toolkits, Mono, Qt, GTK, wxWidgets, etc. I don't have to go through hell and back agreeing to page long license agreements trying to get Mono, or Qt installed/bundled with a Linux distro.
Sun, you're a bit late.
Error 407 - No creative sig found
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!)
i can install java without adding extra repositories/setup? can i expect this to happen anytime soon with the major distributions?
\.
phoneME? phone MicroEdition? Some kind of really small phone? Perhaps, a...micro phone?
Its not responding. Are there really enough slashdotters awake at 7:00 AM (EST) to bring down something from Sun?
Or is it just so large that the two people that are downloading it are now sucking up all the bandwidth?
In any case, anybody have a torrent?
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!
GNU, Sun, Debian, Fedora, etc will have a party (serious collaboration effort) at Fosdem this year. Looks like it will be an interesting event. And Sun is a sponsor this year and will have Simon Phipps from Sun speaking on GPL Java
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 !
PhoneME? This doesn't sound like an open sourcing of Java. It sounds like we get the code to what was Java, but it's now it's own project, and Sun is left free to take the real "Java" anywhere they want to. And since it's "Java" that powers phones, PDAs, applications, and so on, we've lost the advantage. Sun will still be free to keep modifying Java in a different way than the phoneME source, and we're still not gonna know what's powering our cell phone, et al.
The name is important too.
If aspiration is a virtue, achievement cannot be a vice.
I don't have time to look for myself, but what's the overall quality of the code? Is it something that the open source community will actually be able to contribute to?
I mean, when the Mozilla source code was first released, the quality was sub-par. It was outright shitty, actually. That's why they needed to take some time and rewrite large portions of it. I know that Netscape 5 was still under development, but that's no excuse for the poor quality of the code we saw. Java is an actively developed and widely used platform, so I would expect the code quality to be somewhat higher.
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 name is a trademark, and I suppose Sun want to keep it for compliant implementations, as has been the case since they started licensing Java to other companies for implementation. The problem is that a restriction that you cannot change the APIs to make them incompatible with other Java implementations would not be compatible with the GPL, so the only way around this for them is to change the name for what is released under the GPL.
Eh, I really hope there will be a linux/powerpc release for java now that's GPLed.
This seems good for the upcoming OpenMoko-based ARM smartphone; although the project emphasizes native app development, fact is, there's a lot of mobile Java apps floating around. So once this is ported to OpenEmbedded/Moko, it should boost the platform's usefulness for many users.
So thanks, Sun, for this Christmas present. (Now just waiting for the phone to actually come out... :)
GPL prohibits non OSS software to be bundled tightly with GPLed software
Apart from the fact that you're a troll, I'm replying to a troll, and you're wrong: what the fuck is "bundled tightly" supposed to mean? Redhat wrap the box in duct tape?
... is not a good sign for source code archives for Linux =)
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.
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
I always thought that "bundled tightly" was the condition in which your undergarments got lodged in your nether regions and was beyond any degree digital dexterity and grace to extract. The condition of "bundled tightly" requires that the offending garment be removed and completely reapplied to the body.
If you must!
but there are a few parts missing:
>> What's Not in This Release
>>
>> The following software components are not included in the phoneME Feature software release:
>>
>> * Mobile 3D Graphics API (JSR 184)
>> * Audio functionality in MIDP 2.0 (JSR 118), Mobile Media APIs (JSR 135), and Java Technology for the Wireless Industry (JSR 185) implementations
will they be provided in future releases?
everything compiled with it has to be GPLed as well (as in, binaries containing both portions).
I've seen Linux distros with the Intel 3945ABG drivers (binary blob stuff) and Linux distros with Java...
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
Does anyone link the Java VM right into a kernel, so it doesn't have to load like an app every time a Java app/let starts? Maybe just as a kernel module? Would that violate the sandbox security? How about a pool of VM daemons? Maybe listening to a network socket into which Java bytecode can be sent for execution, like a webserver that runs against code, not request data. But more tightly integrated to the OS than, say, Tomcat or another JAS.
If not, will the open source of Java help any existing projects do any of that?
--
make install -not war
Apples and oranges are (canonically) not comparable because they're different fruit, so they have different criteria to be fairly judged on.
Apples and oranges certainly are comparable, within a particular context, just as Mono and Java can be compared within a particular context. For example, if I am seeking a way to prevent scurvy on long ocean voyages, I can compare apples and oranges and reach a clear conclusion about which is best. Mono and Java are probably comparable in many contexts. I have no basis for declaring a winner since in the context where I use Java (mobile phones that come with J2ME), the two are not comparable.
This is smart but for a different reason than "gee, we get to play with the sources." What it means is that phone developers who are looking at putting Java on the phone now have a leg up. While having Java on the phone is pretty much a basic requirement for most cell phone manufacturers, it does mean that if you are a new entrant into the phone market you can get a basic Java environment up and running on your hardware with minimal costs over the development tools necessary to do hardware and software development.
Right now with the struggle between WinCE, Symbian and Linux/Qtopia, it gives developers the opportunity to work (under GPL) the possibility of creating a Linux/Java cell phone (one where Java, not Qt, is used to run the UI) and create a phone which runs jar files as the basic unit of deployment.
And by using the GPL, it means that Sun can negotiate a cut from each cell phone shipped--meaning that Sun doesn't hurt its revenue source.
Bet'cha that the first cell phone manufacturer which tries to pull what Linksys did with its wireless repeater (running Linux but not providing the sources or a means to reprogram the device in violation of the GPL) will get hammered by Sun's lawyers.
Matt Ingenthron of Sun will be speaking at SCALE about Sun's new open-source java implementations. SCALE 5x will be Feb 10-11, 2007 at the LAX Westin, in Los Angeles.
All you have to do is:
apt-get install sun-java5-jre sun-java5-plugin
It's been that way since at least Dapper (I switched from Fedora when Dapper was released).
apt-get install sun-java5-jre sun-java5-plugin
It's been that way for a while.
Qt isn't a GUI toolkit, either. GUI is but one library of the Qt platform, along with networking classes [TCP, UDP and classes direct application - HTTP and FTP]; XML support [in the face of DOM,SAX and SVG], SQL facade; powerful testing, benchmarking and debugging utilities, OpenGL library, etc. And if we count Qtopia as well, there's a load of telephony and other specialty classes there. Way beyond just a GUI toolkit IMO, perhaps it really deserves the name 'platform'...
Mono, java, apple and orange doesn't implement Comparable. So...
"Use cases are fairy tales..." I. S. 2005
So you have some bad apps.
There are good Java apps out there.
Look at Puzzle Pirates (www.puzzlepirates.com). They have a persistant world game in java that plays fast.
Ok, so you need at least 512 MB, preferably 1gig of memory. And yes, it works (Slowly) even with only 128 or 256.
But it works. It doesn't require a reconfigured kernel. It doesn't crash in the middle. It's not horribly slow.
Yes, there's loading lag when you go from A to B. Most games have that, sadly.
You want to blame Java. What for?
1. An app that wanted a reconfigured kernel? Yes, no good app should need that. This one did.
2. Horrible config file re-write? That's not a language issue.
3. Death from timeout with no ablity to fix up? That's not a language issue.
4. Writing config file changes in-place, without getting everything changed first? That's not a language issue.
You've used a bunch of bad apps, that happened to have been written in one language, Java. Shall I talk about the bad C++ apps I've used, and blame the language?
Ohh --- better. I'll complain about the bad Microsoft Windows brand graphical operating system programs I've used, and then blame MS Windows for it.
Oh, wait, I just ruined my own argument, didn't I?
I hear a number of complaints about Java's performance. Java tuning is an artform. If your app is interactive(web server / GUI), I would use the low pause garbage collector. This will eat up more CPU but be more responsive. Otherwise use the throughput GC which will have noticeable pauses if memory gets low but will be more CPU-efficient. The linux kernel manages this tradeoff for you by measuring how 'interactive' each process is and adjusting things, with java currently you must manage this yourself. Maybe now that it's opensource it will automatically choose the garbage collector at runtime and adjust itself.
Having programmed in C++, J2ee is a lifesaver. No more chasing down memory leaks. Life is good and recently java performance has been great. It's easy to whip out java code but few people know how to tune a java app. I'm learning things every day.
2 years and no mod points. Join reddit. Because openness is good.
I am having difficulities finding Java for PalmOS on my father's Palm Treo 680 PDA. He needs Java applets in his default Web browser. From what I read, there is none. Even Palm's technical support says the older versions are incompatible.
Will this source bring the updated versions to work?
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
The only problem being it ignores TTL and the whole thing has to be reloaded to refresh that cache.
p erties.html.
You're right that choosing infinite TTL for DNS lookups by default was moronic. However first Google hit for +DNS +TTL +Java gives you how to set TTL for DNS lookups in JVM startup script:
http://java.sun.com/j2se/1.5.0/docs/guide/net/pro
See, there was no need to restart JVM. Lazy developers, lazy admins.
JVM under GPL is still a great thing.
Cheers
Because of the public static void main (String[] ARRRRRRRRRGGGGS!)
(ducks)
Agreed. No argument here.
Really? And there was me thinking
Everything in moderation, including moderation itself