Slashdot Mirror
Red Hat Joins Open Source Java Project
narramissic writes "Red Hat has signed on to Sun's OpenJDK project and agreed to coordinate its own Java development efforts for Linux with the project. Red Hat will align the work it has done on IcedTea (its own implementation of some parts of the Java SE JDK) with OpenJDK. As part of its participation in OpenJDK, Red Hat will eventually create a compatible OpenJDK implementation for its Enterprise Linux distribution and will also use OpenJDK to create a runtime for its JBoss Enterprise Middleware that is optimized for a Linux environment."
what about mono?
Before adopting WHATWG, read the moonlight.NET EULA [http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx]
With all the "openness" going on with Java these days will things get even more complicated? I have 3 important commercial apps that run on java, all three have their own run time environments that are incompatible with each other. I have no end of trouble with jre and firefox. I can't count how many times I've had problems with classpaths trying to run java stuff.
Will the OpenJDK mean another runtime? As in Blackdown, Sun, Open?
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
I must have slipped into a parallel universe or something because it's starting to look like Java might finally make it's way onto the Linux platform in a useable way. Fair enough we have been deploying Java apps on Linux boxes for a while but it's been much harder than deploying a PHP, C, C++, etc etc application. That always struck me as strange because I would have thought that Java was the perfect language for open source projects. Fairly quick, simple to develop in, stacks of libraries, popular.
I used to have a better sig but it broke.
Open Sourced Solaris, SPARC, now Java... Halleluiah cries the OSS choir.
But seriously, this business move by Sun has made it far more attractive to my company, enabling us to test out Solaris on our existing server before we perform a rollout. In addition, having the source code for the UltraSPARC T1 has enabled us to do research into how the chip functions on a lower level, with an eye to further optimizing our software to perform even faster on it. Sun, you might win over my heart just yet.
Karma Whoring for Fun and Profit.
The official news on the red hat site:http://www.redhat.com/about/news/prarchive/2007/sun_java.html/
because i can't find references on the sun & openjdk site.
Slashdot ya no es que lo era!
Why? Sure, it was a novell idea to try and create an open sourced java but the whole arguments which backed it up were false. Many people seriously believed that Sun was not opening up the Java source code period, while in fact that was a mere lie. The Java source code was available but simply licensed in such a way which didn't really go well with some. And so they simply declared it "closed source" and fooled many people into thinking that the Java sourcecode wasn't available period.
Why I mention this? Because it was perfectly legal to adopt certain pieces and sniplets of code, check the way things were build an adapting those ideas. All of that might have made a difference for the gcj/gij projects. Personally I condemn those 2 projects, but having said that I will have to admit that they did make a good effort.
But the main reason I hate this stuff with a passion is because its not compatible with Java, and it is my belief that all the nonsense (gcj/gij + the bs about the closed source java) has left Java with a bad name / reputation on the Linux platform. Which I think is unfair and an utter shame. Would this have not been the case I think Java could have lifted some interoperable development movements to higher levels. Sure; it has already done this to some extend and Linux is still a big market for Sun, but when the bs was still spreading you could already easily download binary installers (self extractors) to install Java on Linux. But I have met simply way too many people who had problems to "do java on linux" and when you started disecting the problems it all boiled down to Linux distributions shipping gcj/gij thus resulting in non-working Java software. And as well all know; a good user doesn't blame his tools but the product he's trying.
I once spend 45 minutes on the Sun Java tutorial and couldn't get some examples to work. Eventually I tried on another platform, that did work, and so I knew where to look. Eventually I ended up dumping gcj/gij and replacing it, unfortunately I think many others ended up dumping Java.
Thats the reason because sun is working in what they call "the consumer jre", please check this pages: http://weblogs.java.net/blog/chet/archive/2007/05/consumer_jre_le.html/
and this https://jdk6.dev.java.net/6uNea.html/
Slashdot ya no es que lo era!
That number is a bit exaggerated, my install of the latest Java 6 JRE is about 80MB (and the download is only 14MB).
One of the reasons it's so big is because it has a LOT of functionality. But you're right of course when you say that you don't need all of that to run a simple Java application. So Sun decided to do something about that: in the upcoming Java 6 Update N (what was previously called the "Consumer JRE") only a relatively small "kernel" will be installed which has only the most essential components. The rest will be downloaded "when needed".
My problem with the Sun JRE is that it is HUGE. Why do I need 100MB+ to run a simple Java application?
you don't. a simple stroll over to java.sun.com will show you that the JRE is 14M for windows and 18M for linux.
the "100M+" is if you're also downloading all their development tools and documentation (and possibly netbeans, depending on the link). not atypical in the least.
http://kered.org
It's probably too late for java to overtake flash in that market segment, but if Sun had originally done this, they would have probably won the web war. The two biggest complaints about java are, the JRE is too big to download, and the programs take too long to start. This is 99% of people's impression of java. They don't care that it's perhaps one of the best general purpose languages out there right now. They care it takes 10 seconds longer than flash to run a simple program. Sun should have never half-assed that aspect. Either do it right or don't do it at all.
If an officer ever threatens to taze you, say you have a pacemaker.
If you need Real Time efficiency use specialized hardware, OS, and not Java. If you're making a little app that you want to be able to run on virtually any cell phone on the planet... use Java. Use the right tool for the job. How difficult is that?
Check out my lame java blog at www.javachopshop.com
They each have their advantages and disadvantages. According to the great computer language shootout, Java is faster by an order of magnitude, but is more verbose and usually consumes about twice as much memory. The ultimate decision depends (at least) on your application's needs and the capabilities of the environments you're targeting.
What does the uncompressed local copy have to do with download times? 14MB compressed takes just as long as 14MB uncompressed. If you think that your CPU can't handle fast decompression, just think of all of the web sites that gzip their content for network efficiency.
As for the complaint about docs, are you serious? Are you seriously complaining that there is too much documentation available in HTML format? And optional documentation at that? Think about what you're saying for a second: that you consider it a drawback that every class, method, and member of the JRE is consistently documented in detail.
GUI: AWT versus Swing are native widget peers versus internally rendered widgets.
RPC: RMI, CORBA, and XML-RPC/SOAP are for the following in order: RPC in a 100% Java environment, cross-platform binary RPC, and XML text-based RPC. There is a place for each of those.
XML parsers: are you referring to the SAX, DOM, and StAX parser APIs -- which would make three? Or do you mean two parsers like Crimson and Xerces. I think the former is self-evidently a good thing. The latter is due to compatibility and consistency through multiple releases as the older parser behavior may be necessary for an older app even if it's a little slower or more memory inefficient.
I can see your argument against including a scripting language, but Sun wanted to include a reference implementation of their pluggable scripting interface.
I/O: Blocking vs. non-blocking. What's the problem? Both have their uses.
What you call bloat, some would call completeness. Let's compare against some other popular languages.
Common Lisp: 10MB
Latest Python download for OS X: 17.9MB
Latest Perl download for OS X: 33.5MB (Linux version is between 18.9 and 24.8MB)
Latest Ruby (without Rails) download for OS X: 13.71MB
But don't take my word for it. Download for yourself. The only reason these other languages seem smaller to you is because they are bundled seamlessly with your Linux distribution.
Want database access, RPC, non-blocking I/O, XML parsing, etc. from those languages? Too bad, that's another download. Sure there are resources like CPAN, but why are their cores so bloated? Somehow Java is able to provide all of those "bloated" APIs at about the same download size as those languages that lack them.
And don't get me started on C and C++. They don't even have a standard database layer, XML library, or the like for you to download separately. Learned one non-blocking I/O library? Too bad, your new company uses a different one. Do you think ODBC is a good solution? Obviously you've never programmed for it.
I'm sure I could go on, but you get the picture.
- I don't need to go outside, my CRT tan'll do me just fine.