Will Sun Open Source Java? 700
capt turnpike writes "According to eWEEK.com, there's an internal debate going on at Sun whether to open-source Java. (Insert typical response: "It's about time!") Company spokespersons have no official comment, as might be expected, but perhaps we could hear confirmation or denial as early as May 16, at the JavaOne conference. One commentator said, "Sun should endorse PHP and go one step forward and make sure the 'P' languages run great on the JVM [Java virtual machine] by open-sourcing Java." Would this move Java up the desirability scale in your eyes? Could this be a way to help improve what's lacking in Java?"
too little too late (Score:2, Informative)
Re:This would help (Score:1, Informative)
2) Says who? It is a virtual machine afterall, and if you run more Java apps all of them won't use as much memory as the first one did. Also memory are cheap and who cares. It's a good and safe language and you probably ends up with less bugs.
It is very reasonable to run Java in Linux. It's harder/more painful/whatever in the BSDs but it works.
Re:If they do, it will all depend upon the license (Score:5, Informative)
Re:This would help (Score:2, Informative)
FreeBSD now includes Sun Java [freebsd.org] as part of the distro, so it should be easy. Any Linux/BSD/etc distro can do this, it just requires spending the money to get it certified.
Re:Third-Party JVM (Score:5, Informative)
The main reason Java has a terrible reputation (IMO) is/was it's tendancy to hang/lockup/freeze your browser when an applet loads, and general clunkyness with Swing.
Re:Alternate VMs (Score:3, Informative)
Sun, on the other hand, does not allow anything of the sort with their own Java stack and has held off on open-sourcing because it sees its Java runtime environment as a beachhead through which it can colonize your system (especially on Windows, where it comes bundled with all sorts of seemingly-unrelated stuff, like browser toolbars). Allowing third parties to ship stand-alone executables would undermine this.
This is probably to the long-term detriment of the Java platform because the runtime environment is now large and unwieldy enough to really complicate app deployment.
I believe Sun intentionally obfuscates the issue by pointing out that native code is not portable, is somewhat more fragile (because it is not insulated from system dependencies by a VM) and does not necessarily perform better than bytecode in a VM with an aggressive JIT. All these are true, but is besides the point.
Re:Yes (Score:1, Informative)
Java already has the best "Write Once, Run Anywhere" technology on the market today. Programs that fail to be portable are usually due to:
1. Idiot programmers who can't figure out that "c:\\My Files\\data.txt" is not portable across Operating Systems.
2. Hardware inconsistencies that screw up many more programs than just Java. Hyperthreading is the worst offender, but general SMP can wreak all kinds of havoc on unsuspecting code.
Re:This would help (Score:5, Informative)
Actually, FreeBSD were given a license at no cost by Sun, and any not-for-profit organisation with a need for access to a Sun-maintained compliance test kit can get it at no charge [sun.com]. So it's really just a matter of having the motivation to ask.
Who cares? (Score:3, Informative)
Why do I say that? Because it is the one all non-Sun/Microsoft server environments (meaning Linux & *BSD) will be shipping. RedHat is already there. If you want a different Java you have to deal with the implications of having it co-exist with GCJ. Although they do use alternatives to make that managable, they ship the IBM JDK on their extras CD, not Sun's and the Sun packages almost certainly (haven't bothered to check a recent vintage) don't deal with that, their 'rpms' are brain damaged tarballs wrapped in a thin rpm wrapper.
So it no longer matters what Sun does. Five years ago they could have turned around the fortunes of Java when it was under serious threats. Ten years ago OPening Java would have meant we wouldn't be dealing with
Re:Open Java (Score:5, Informative)
Kaffe and GNU/Classpath are excellent, active projects with dedicated developers. Notably, GNU/Classpath has recently passed the 99% code coverage mark measured against the Java SE specification. Apache Harmony was started because Apache won't use code licensed under the GPL, not because of any technical defect in the work of the Kaffe and GNU/Classpath developers. Harmony is also making excellent progress and has a skilled and active community. Both are committed to making compatible implementations of Java, but licensed under the licenses their communities need.
Mustang changes this (Score:5, Informative)
http://www.internetnews.com/dev-news/article.php/
Amazon is not LAMP (Score:5, Informative)
Amazon is not LAMP.
Re:Overlords (Score:4, Informative)
As the two ACs who have been modded out of view said, that particular drug already exists - Jython [jython.org] - and is already supported in Java IDEs like NetBeans (via Coyote [java.net]) and Eclipse. It's been interesting to see all the old urban myths about the Java platform being slow, bloated, single language and so on doing the rounds again though, I'd almost forgotten about them...
Re:Make sure 'P' Languages run on JVM.....huh? (Score:2, Informative)
Re:Open Java (Score:4, Informative)
As an embedded systems developer who has recently been dealing with Windows CE, let me tell you that Microsoft is pushing
The Java market is fragmenting. All these groups are taking it in different directions. The Apache people are re-implementing it, the GNU people won't deal with Sun Java, distribution is a mess. Microsoft offers a consistant product, a consistant platform, and a hard sell. Java is losing ground on the server side. On the embedded side, Microsoft is determined to "fucking kill [java]", and they're not resting. It's not all doom and gloom, Java will be around for a while. But it wouldn't hurt if Sun got off their asses and removed the obstacles in the way of their allies in the war against dotnet.
Re:No (Score:1, Informative)
There's no reason the license for Java needs to change if all you want to do is fix specific flaws in the current implementation. The only reason Java would need a more open license is to allow people to copy, modify, and redistribute the JVM (or the SDK tools).
Re:Why Should Sun Do This? (Score:3, Informative)
http://shootout.alioth.debian.org/gp4/ml.php [debian.org]
http://shootout.alioth.debian.org/gp4/ocaml.php [debian.org]
Two SML implementations are SML/NJ, MoscowML.
Re:Third-Party JVM (Score:5, Informative)
Other problems with your post: Eclipse is an application; Swing is a language feature. A Smalltalk derivative (Squeak) is not a suitable replacement for Java. I'd go so far as to say Ruby and Python aren't either, though both are very powerful and are better suited to some tasks than Java.
Nice try at a troll...subtly nonsensical.
Re:This would help (Score:5, Informative)
Pretty meaningless comment, unless you can supply some examples. I've done consulting and development for a number of large, lawyer heavy organizations, and none of them had a problem deploying Java solutions on linux. None.
"2. JVM is fat fat fat, it uses way more RAM than is reasonable."
Sadly uninformed, probably due to severe lack of experience with large applications. Per example, a couple of years ago I worked in a team that bid on and developed an application that, in a nutshell, receives up to 20Megs per sec of market data, breaks it up into itty-bitty messages, and then makes it available to any number of subscribing clients. Call it a proxy, if you will. We developed the app in pure Java, using the new NIO functionality. We competed with another team who started out in C, moved to C++ midway through, and were barely in a position to go alplha when we were ready to deploy. The client, since they were paying and had a lot of anti-Java staff, insisted on waiting, even though the delivery date had long since passed. When they finally had something to show, the apps were launched on identical hardware, and allowed to run 24/7. Our app ran smoothly, uninterrupted (except for a blown network interface) for the duration of the test. The other team had to restart their app several times a day, resulting in unnacceptable outages. Their restart time was, likewise, poor. Their app required 2Gigs to run. Ours ran happily under a Gig.
The client paid both teams for their efforts, then licensed our solution.
So, my quesion then is, where's the fat?
Re:PHP and Java is oil and water (Score:4, Informative)
Re:No (Score:3, Informative)
The problem is worse with medium scale apps because Java offers something most frameworks don't: choice. Do you use Spring, Hibernate, JSF/EJB3, JSP/EJB2, Struts or a mixture of all of the above (shudder). Thats one man month gone already and you haven't even written a prototype. This makes finding your team hard too, as even if you are Sun Certified, each framework is a language in itself with its own quirks and thats before you get inhouse arguments over which patterns you are going to use and where. Thats before we even start to talk about writing the same code three times (interface(s), bean, XML)
I think Java has lost the small to medium enterprise battle, but then it never really wanted to win those battles. XDoclet and hibernate take some of the hardwork out of Java programming, but the battle isn't with the frameworks so much as the language itself. Compared to C/C++ Java might look light, but compared to Ruby/Python/PHP its nightmare of repitition and bordom. Arguments about speed of execution are as relevent with Java/Ruby(et al) as they were with Java/C and C/Assembler. Thats not to say that Java isn't faster than modern scripting languages (although just as in Java vs. C that is debateable), its just that the time to support and build a scripting language is so much less that the additional hardware is cheap in comparision.
If you find yourself writting a Java webapp for a project whose volumetrics don't mean that you need to be running on at least 3 Sun Servers (or equivalent), then you're almost certainly using the wrong tool, and even if you are the chances are that Ruby on Rails is still probably worth a look.
MySpace runs on ASP.NET 2.0 and IIS 6 now (Score:3, Informative)
Here is a blog by a Microsoft ASP.NET dev describing the details (it's an interesting read):
http://weblogs.asp.net/scottgu/archive/2006/03/25
Note that some parts of MySpace still use
And just to add more proof (since I know that most here will be skeptical
What ? Eclipse has no issues with languages at all (Score:2, Informative)
I call bullshit - just because you don't know how to set up your machine properly doesn't mean java has language problems.
Re:This would help (Score:3, Informative)
Quoting Deb Goodkin of FreeBSD Foundation (from here [ittoolbox.com]):
We spent close to $35,000 for this release. It is hard to estimate the future costs of maintaining the Java releases since we expect to build updated distributions in response to all security advisories released by Sun.
So, while the license itself might have been given gratis, this clearly shows that the process of obtaining it was cumbersome and costly, and the result is still a limited, version-dependent, binary-only distribution.
Yes, Java is still evil. Changing license for something more liberal would certainly help much with adoption here.
Re:Why Should Sun Do This? (Score:1, Informative)
The problem, exactly, is that SUN only implements its JDK on the platforms it judges as "interesting enough". Running a non-mainstream OS on some non-i386 hardware will always end up with you unable to run any SUN JDK -> simply doesn't exist. Well, Blackdown can help and hacking and going all sort of self-punishment you might end up in getting it to work, but well, compare the number of platforms GCC or Perl [perl.com] run on, and compare the number of platforms supported by SUN JAVA, and well, you'll see that SUN JAVA's portability is purely theorical. Now the usual answer "but nobody does this!". Some vendors, and SUN is no exception, are very smart at knowing what people want, without even asking them. Should you want to do something they didn't plan, you cease to exist.
Now it's perfectly true people have the specs, people are free to implement. Look at the efforts made by GCJ [gnu.org] and Classpath [gnu.org] and you'll see that even with many talented developpers involved, it's hard to catch up with SUN.
What could SUN benefit? Obviously, get many free software developpers to get interested in Java at all. Many software developped in C++ could have gone the Java way, if there had been a way to run Java programs freely, using the *latest* JDK. For now, people have to beg SUN (and possibly IBM) to port the JDK to this or that platform to get a chance to run their Java 1.5 program on *any* platform. Not to mention the fact that some people care about freedom and the right to know what they are running on their computers...
IMHO, SUN will publish Java under a Free (as in freedom) and/or Open Source licence the day the concurrent implementations (GCJ,Kaffe,Classpath...) will catch up. On that day SUN's JVM will have absolutely no added value but the stamp "this is SUN software" (which is what counts more for many). Think of Motif, it got free the day GTK and Qt/KDE where ahead of it. Same for OpenSolaris [opensolaris.org] which comes at a time the Linux kernel is pretty advanced in term of features and is obviously (even if not technically fully equivalent) taking significant market shares so that, well, Solaris is dead.
Sun will "Open Source" Java the day it's dead, because another "Open Source" project took the lead. So if SUN ever publishes a free software JDK, you could interpret this as a signal that means something like "GCJ+Classpath is ready for production use".
Re:Amazon is not LAMP (Score:2, Informative)
Re:This would help (Score:4, Informative)
1) You do know that tools such as top and ps report a lot more memory than is really used? This has been adressed in the upcoming Java 6, which will more accurately report the memory used, you will likely see a decrease of 25-55% [java.net] reported memory use on Linux/Unix, and at least 11% of real memory used.
2) You can use jvm startup parameters to limit memory usage and still get acceptable performance [rifers.org].
Re:This would help (Score:4, Informative)
Now, before I take a moment to rag on your ridiculous RAM comment, let me assure you that I hate Java from that ground up. I find it to be little more than a virus.
JVM is thin thin thin. The fact is that most non-Sun implementations of the JVM are tight and small. In fact, from a performance perspective, Java is typically superior to compiled languages because of how it handles RAM. Before you blow me off, let me justify my comment. Thanks to the Java license and NDA agreements, I in fact can not say where I learned this information, but I have extensive experience in this topic since I was forced for extended periods to suffer the Java VM on embedded devices.
Java is a relatively simplistic (though strangley complete to the point of OVER KILL!!!) architecture/language/etc... It provides a language matched to a virtual machine matched to a set of somewhat poorly written libraries.
What makes Java superior to compiled languages is that it compensates for several key factors. First I'll refine my definition of a compiled language to clearly specify C/C++/Pascal/other non-garbage collected languages.
1) Application Developers are not System Developers
Using C++ as an example, most application developers use the standard implementation of new and delete. This is fine, but the first thing to keep in mind is that memory allocation for a C++ application that makes use of a lot of small objects tend to pay a huge performance price. C developers regularly shoot down the performance of C++ without realizing that it's the limitation in the C allocation routines.
Object oriented programming is typically very heap intensive. In many cases, developers insist on iterating through strings and lists far too much. Students are even taught in the university that data structures should be used absolutely everywhere. Of course they are taught Big-O and Little-O, but unless you're actually implementing the data structure classes and types, very little importance is placed on performance of these classes.
Strings are abused regularly since even though the allocation unit size of the heap allocator is limited to blocks of 16 bytes (for example), programmers will actually reallocate the buffer for a string to resize it from 8 to 9 bytes in length. By reallocating, I mean they will in fact allocate a new 9 byte string, then copy the original to the new buffer and delete the original buffer.
Application developers pay very little attention to the actual internal mechanics of the classes and functions which they use. To a certain extent, I can forgive them since an application developer is expected to think differently than a system developer. When we depend on system developers to write applications, they're often extremely fast, but relatively unusable.
So here's where Java shines, because of the garbage collection system and because of the relocatable memory architecture, memory is managed in such a way which decreases the cycles spent in allocation and deallocation of buffers. A well written JVM actually will actually either when necessary or when time is available compress the heap to maximize performance and minimize heap consumption.
So although Java seems like a memory hog, it's actually not that bad given the number of allocations and deallocations being performed by the developers. Sadly, the extreme memory use you're talking about is related to the poor system level development skills of application developers stacked on the additional layer which abstracts even more from the developer therefore making it less practical for the developer to understand the internals of the system.
2) System Developers make Terrible Applications
A system developer is typically biased towards raw high level languages such as C (not C++) because their used to making use of the stack whereever po
Re:Open Java (Score:2, Informative)
http://www.object-refinery.com/classpath/statcvs/ [object-refinery.com]
Progress, over the last two years in particular, has been astonishing.
Re:Will it make the competion less desirable? (Score:3, Informative)
That's sad really, I wonder on what standards [mono-project.com] those "wonderful Mono efforts" are based on ? Yeah. There'll never be a open standard [ecma-international.org] for .NET, never bother about open source [dotgnu.org] implementations [mono-project.com].
Re:Alternate VMs (Score:3, Informative)
Re:Bad idea (Score:4, Informative)
Microsoft already forked java and called it C#. Now C# is evolving faster then Java and is making serious inroads into the java development market. Furthermore there are at least two open source implementations of java. So there are three forks right there.
Being closed source has not prevented anybody from forking java. Whats more being open sourced has not caused python, ruby, php, perl, ocaml, or haskell to fork.
I don't know where people get this meme from really. It makes no sense at all.
Re:If they do, it will all depend upon the license (Score:4, Informative)
Seriously, though, there are other problem domains out there. A lot of them, in fact. And even in web development, depending on the complexity and context of the solution, might require vast amounts of code that never interact with a GUI of any kind. When you evaluate these languages and platforms in context's outside of web development, Java starts to look far more robust and flexible.
As another poster pointed out, where are the buffered readers for ruby/php? Sure File.open("name") might LOOK nice, but Java's addition of a buffer solves a common problem many programmers in the past needed to solve by hand. There are about a thousand of these examples where Java's framework is more complex than its ruby/php counterpart, but for good reason: it adds much needed functionality for the enterprise developer.
Taft
Re:If they do, it will all depend upon the license (Score:5, Informative)
Did you even read the pages you were linking to? The Open Source Initiative's own certification page, that you linked to, has this to say, right in the first paragraph: "the term 'open source' itself [...] can't be protected as a trademark".
I can call anything I like Open Source, and nobody can do a thing to stop me. The new Evil Proprietary License (a viral license that infects any software in the same room with a deadly curse that can only be lifted by the sacrifice of your firstborn) could be called Open Source. What it couldn't legally be called is OSI Certified(tm).
Re:PHP and Java is oil and water (Score:3, Informative)
Of these languages, only Perl has working multithreading support. Python and Ruby both have hugely granular global interpreter locking, which makes multithreading impractical.
What works well for a hobbyist doesn't necessary work well when professional adult programmers need to accomplish something reliably day in and day out.
Re:No (Score:2, Informative)
bufferedFile = open("foo.txt", buffering=True) # or specify an integer if you want to manually set the buffer size
sock = socket.socket() # then set it up
objectReader = pickle.Unpickler(gzip.GzipFile(fileobj=sock))
obj1 = objectReader.load()
obj2 = objectReader.load()
I will admit that setting up the socket in Python follows a painful, C-like method (bind(), connect(), etc.); however, for any real networking application, you'd probably be using the Twisted library anyways, which does a whole lot more.
PHP in the Java VM (Score:3, Informative)
Re:No (Score:3, Informative)
As an example, the GzipFile object's constructor doc says:
And the socket object's makefile() method documentation says this:
So we should be able to create a socket and do
GzipFile(fileobj=s.makefile('r')).read()
However, the python GzipFile implementation seems to want to be able to seek within the file object, but the object returned by socket.makefile() does not have a tell() method. The easy solution is to fix GzipFile so that it doesn't need to seek, the real solution probably won't happen till Python3000 brings the interface magic to everything... (coming RSN)
That said, in case someone wants to know a way to stream zlib data (the compression method used by zip and gzip):then run recv() until it runs out of data
You could actually do the same with gzip data, you'd just have to know the magic number of gzip header bits to skip before you start decompressing. The nice thing with the Java code you list above, of course, is that it's already implemented for you.
-Mark
Does anyone really care? (Score:0, Informative)