Slashdot Log In
Will Sun Open Source Java?
Posted by
samzenpus
on Mon May 01, 2006 10:10 PM
from the free-coffee dept.
from the free-coffee dept.
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?"
Related Stories
[+]
Java to be Open Sourced in October 267 comments
thePowerOfGrayskull writes "Sun is now stating that the Hotspot JVM and javac will be open-sourced in October of this year, with the rest to follow by the end of 2007. There is still no word as to which license it will be released under. For those who haven't seen it yet, Sun has previously opened a public developer community site for soliciting feedback and providing updates about the process."
[+]
Java To Be Opened For Christmas? 243 comments
MBCook writes "At the Oracle OpenWorld conference, Sun's CEO Jonathan Schwartz announced on Wednesday morning that Java would be opened within 30-60 days, which would would mean about Christmas Day at the latest. Sun first announced they would do this back in May at JavaOne but didn't give a date. We've seen rumblings before on this topic. Schwartz also commented on the companies Sun Fire servers, Sun's relationship with Oracle, and general trends."
This discussion has been archived.
No new comments can be posted.
Will Sun Open Source Java?
|
Log In/Create an Account
| Top
| 700 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
If they do, it will all depend upon the license. (Score:5, Insightful)
What changes and how would depend upon which license was chosen.
Re:If they do, it will all depend upon the license (Score:5, Informative)
Mustang changes this (Score:5, Informative)
(http://slashdot.org/ | Last Journal: Friday March 26 2004, @09:01AM)
http://www.internetnews.com/dev-news/article.php/
Re:If they do, it will all depend upon the license (Score:5, Funny)
(Last Journal: Sunday June 17, @02:35AM)
Re:If they do, it will all depend upon the license (Score:5, Insightful)
(http://play.pixelblaster.ro/)
Re:If they do, it will all depend upon the license (Score:4, Informative)
(http://matthewtrumbell.com/)
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:4, Interesting)
I really don't understand this. Having a rich and versatile range of libraries is a problem?
Personally I use Ruby (on Rails) these days for web development: convention over configuration is, imo, a much more important advance in the art than object-orientation was.
And Java has had this for years. I use JDO to persist my Java objects (it is a far more powerful and versatile system than Rails - much faster, and can persist to non-relational stores as well). How much configuration do I need in principle to describe my schema? Nothing but a list of classes. By default, the schema is created and mappings are automatically set up based on the field names of my classes. By default, no configuration needed.
How long has JDO had this? Since 2000!
Convention over configuration is nothing new.
Re:If they do, it will all depend upon the license (Score:5, Interesting)
(http://www.houghi.org/)
That way SUSE lies the choice with the user, not with the distribution. If the user still decides to use it (and many will) they still have all the advantages as they have with the different other packages that are included with SUSE, including security updates.
Re:If they do, it will all depend upon the license (Score:4, Insightful)
Re:If they do, it will all depend upon the license (Score:5, Informative)
(http://www.haeleth.net/)
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:This would help (Score:5, Informative)
(http://www.webmink.net/)
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.
Re:This would help (Score:5, Interesting)
(http://slashdot.org/)
on a more philosophical level, there is already an excellent VM that *can* use all the 8G and then some. it's called linux. using java to build apps because it's easy to program in is like using tonka trucks because those trucks are so much easier to handle than the real thing. after all, why pay commercial driver rates to drive a multi ton truck when you can get you own kids (for free) to 'drive' the tonka trucks.
i learned java back around '95, '96 and was really excited about it then. but after having used it on some really large projects, i have been really really disappointed and came to the conclusion that the only real contribution of the JVM was a serious neutering to most modern advances in the OS.
forget portable programming languages - use a portable OS - linux. and forget the V, use the M (tm).
anyhow, Guy Steel was right. i am looking at lisp right now (mostly for emacs tho).
Re:This would help (Score:5, Interesting)
(http://www.pandora.be/jurgen.defurne/ | Last Journal: Wednesday September 08 2004, @11:52AM)
I have the impression that the last couple of months I see more people on Slashdot mentioning Common Lisp as a replacement for Java.
rank amateurs (Score:4, Insightful)
Because you are rank amateurs who are unable to read documents or use profiling tools such as jconsole or YourKit [yourkit.com]?
Re:This would help (Score:5, Insightful)
(http://xaxxon.slackworks.com/)
uTorrent is NOT self-contained. It requires the Windows API to run. This part of its footprint is not shown when you look at its memory usage, but that first 256MB of RAM that windows uses is the reason uTorrent looks so small.
Re:This would help (Score:5, Insightful)
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:This would help (Score:5, Insightful)
Programmer time is much more expensive than processor time these days. Therefore, many current programming languages are optimised to save programmer time first. C and C++ were designed in a time when processor cycles were extremely expensive, and therefore are optimised to save time at runtime instead.
As you have seen, java typically gets you results more quickly than C. In this case, since you simply took less time to get to your basic functionality, you could take more time to think about how to code more efficiently, and ended up actually writing faster code in the end.
However, java is not the only modern programming language out there. People have designed several new languages in the past decade. It seems reasonable to assume that some of those people deliberately set out to improve on java. Compared to such languages, java might appear to be very inefficient.
I'll leave it up to you to compare and decide. For instance, here's a comparison for web applications, done at JPL. (YMMV):
http://oodt.jpl.nasa.gov/better-web-app.mov [nasa.gov]Re:This would help (Score:5, Interesting)
(http://www.evilspock.net/)
Re:This would help (Score:4, Informative)
(http://www.ki.se/ | Last Journal: Tuesday August 28, @07:06AM)
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:This would help (Score:4, Insightful)
I know. This is a real weakness in Java. It would have been great if it was a far more memory efficient languages, because then it could have been used in a wide range of low-memory situations like embedded devices, PDAs or mobile phones....
Er - something wrong with this argument, perhaps?
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: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:Third-Party JVM (Score:5, Insightful)
(http://www.ki.se/ | Last Journal: Tuesday August 28, @07:06AM)
No, not EVERY method. Just methods that that can reasonably fail (for instance I/O related operations), and that doesn't "know" how to handle the problem themselves. This helps you create well defined APIs, which in my opinion is one major reason there are so many frameworks and open source projects for Java.
Although relatively useless (if not harmful), these checked exceptions lead to a minimum of 122 extra CPU cycles per method invocation.
Evidence of this? Besides, it has been said so many times, but appearently it has to be said again. Processing cycles keep getting cheaper. Programmer hours keep getting more expensive. Trading a few cycles for a feature that helps you create more stable and transparent code is sensible.
catch (Exception e) {}
That is just about the worst thing you can write. Ok, maybe catch(Throwable t) {} is worse. That the first editions of Bruce Eckels Thinking in Java books were littered with those is evidence he just doesn't get checked exceptions.
No (Score:5, Insightful)
(http://aliquis.homeunix.net:8080/blog/)
No, haven't they already said that? Like hundreds of times? And does it really matter?
"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."
"No", who would run PHP on Java anyway? Why? Why would open-sourcing it help?
"Would this move Java up the desirability scale in your eyes?"
No, Java is already desirable in my eyes.
"Could this be a way to help improve what's lacking in Java?"
No, what is lacking?
People who complain that Java is slow, should be open-sourced, and so on have never seemed to had a clue.
Re:No (Score:5, Insightful)
(http://www.glpwd.com/)
Will people stop trying to move Java towards a culture that won't keep Java up to the same standards Sun has? There's a reason why the top two server side platform these days are
The only place I ever see Java going is perhaps to be bought by another bigger company who has a similar path. My only hope is that it's IBM because their Java apps are of a higher quality than Sun's, and they've done such good work with the Eclipse platform.
Re:No (Score:5, Funny)
Of course, any equivalent app in Java would have more lines of opaque XML configuration than the "POS LAMP application" has code. It will also be slower, eat several times as much memory, and depend on specific versions of two dozen frameworks.
The Rails version, OTOH, would be about 4 lines long and deployed before the Java guys managed to fire up their Eclipse bloatware. It would, however, be about the same speed as the Java app.
The Lisp version would never fail, would have source code in the form of a haiku, could tell the future and control the weather. It will never be written because all those parentheses look funny.
Re:No (Score:5, Insightful)
(http://janneinosaka.blogspot.com/)
Irrespective of any ideological issues, there are a few reasons the current situation hurts Java a bit.
Foremost for quite a few readers of slashdot is that free Linux distributions can't include Java in their default install. That means Java-based apps are not going to be included either. And since users need to jump through quite a few hoops to get Java installed (don't say "it's easy" - for most people anything beyond using their package manager is too high a hurdle), you can't assume it will be available on desktops in general.
The second issue is that Java does not really play well with the desktop. I have set up my desktop to run fine using three languages - English, Swedish and Japanese - and made sure everything from localization to character input works smoothly. But Java does not cooperate; it has its own way of dealing with CJK characters and needs its own fonts and separate setup to work. I have fiddled a little with it, but have never gotten it to work properly (especially being able to run an app in Swedish while still being able to input Japanese). And since it uses its own input method, it does not share the local dictionary so typing becomes frustratingly different from any other application I use. And since the code is not open, distributions can't fix these interoperability issues.
Both of these issues serve as disincentives from using Java apps and from writing them in the first place.
Re:No (Score:5, Interesting)
(http://ptth.net/squish/ | Last Journal: Monday October 01, @11:26AM)
No, haven't they already said that? Like hundreds of times? And does it really matter?
Sure it matters. A lot of people have issues with it because of the license. It would clearly expand the number of potential adopters to go open source. More adopters will mean better tools.
"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."
"No", who would run PHP on Java anyway? Why? Why would open-sourcing it help?
Well, I agree with the first part. But presumably integration will get better/faster in open source.
"Would this move Java up the desirability scale in your eyes?"
No, Java is already desirable in my eyes.
But a lot of people would find it more desireable. You can trust that java won't go away in open source, whereas you can't really say the same as long as SUN is at the helm.
"Could this be a way to help improve what's lacking in Java?"
No, what is lacking?
Mostly modernizing. The pace of java development is glacial, compared to say what is going on in C# or Ruby. People with specific integration issues that can't get sun to address compatibility problems are stuck.
People who complain that Java is slow, should be open-sourced, and so on have never seemed to had a clue.
There's no doubt java is still slow in a number of contexts. There are also obvious opportunities for performance enhancement that could be addressed in an open source process. I recently benchmarked ten of my applications in c++ and java, java is about 2x slower for most of the cases I tried, and never faster. To me, that's perfectly acceptable, but java could make more inroads into other areas of computing if it was more competitive in performance. More inroads means more developers, and that means better tools, which is what I yearn for.
Re:No (Score:5, Interesting)
(http://iabervon.org/~barkalow/ | Last Journal: Saturday May 31 2003, @02:01AM)
On the other hand, Sun's Java compiler has always had broken dependancy tracking (at least since I started using it heavily in 1999). (If a build has an error, the set of output class files may be such that the next run of the compiler skips a source file which needs to be compiled; this is mainly that it can generate the public class without generating other classes in the same file.) I think it's likely that, if Sun does open source the JDK, they'll get fixes for a number of annoying flaws of that sort pretty quickly, and things that are clearly wrong but aren't considered worth working on will be improved substantially.
Of course, there's essentially no chance that they'll relax their grip on the language standard, and they probably shouldn't, unless they turn it over to a standards body due to no longer being able to employ good language designers.