Red Hat Joins Open Source Java Project 121
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."
FYI (Score:5, Informative)
because i can't find references on the sun & openjdk site.
I truly hope for the end of gcj/gij (Score:5, Informative)
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.
Re:I truly hope for the end of gcj/gij (Score:2, Informative)
'closed source' is an inane term. I don't think anyone from gcj or gij was describing Sun's Java as 'closed source'. It's non-free, which is what matters. Merely being able to look at the source code doesn't mean you have freedom to use, share and change the software.
Re:parallel universe (Score:5, Informative)
And there are plenty of nice Java apps and environments on Linux -- Eclipse is one of the big ones, obviously. The bottom line is that gcj/gij gave Java on Linux a bad name because standard Java apps and programming examples never have worked on it right. Install Sun's JRE/JDK or Blackdown, and you'll find that Java works great on Linux.
Re:Other Linux Java Options? (Score:3, Informative)
and this https://jdk6.dev.java.net/6uNea.html/ [java.net]
Re:parallel universe (Score:5, Informative)
If Swing developers remember to move intensive operations off the Event thread and into a background thread, then Swing app's are really nice and responsive. It's not that difficult, but for some reason most developers are either unable to, or unwilling to do this simple task.
Believe me, I've seen the source of plenty of Swing app's that have been written with everything in the Event thread and the developer (one of whom I had employed at that time) refused to do this because they couldn't be bothered.
As for the look and feel, it's getting better but it still has a long way to go.
Re:I truly hope for the end of gcj/gij (Score:5, Informative)
Re:Other Linux Java Options? (Score:5, Informative)
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".
Re:Other Linux Java Options? (Score:5, Informative)
you don't. a simple stroll over to java.sun.com will show you that the JRE [sun.com] 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.
That's how flash won the web (Score:3, Informative)
Re:Will anything change for end users? (Score:3, Informative)
Re:Will anything change for end users? (Score:4, Informative)
Re:parallel universe (Score:3, Informative)
I wasn't blaming swing users, but from past experience most don't follow the Swing event model, even when it's documented well. Virtually all are creating swing objects outside of the Event thread (EDT).
> I can understand that for very large operations but if I have to create a thread for every event driven operation, I am done for.
No is did not say for every operation, I said for the expensive ones like file or network IO. When swing appears slow 99% of the time its because of something in the background holding up the Event thread.
> Multi-threaded programming is just hard.
Sure it can hard if you have to handle concurrency, but what I was trying to say here isn't that hard.
Making the Action (running inside the EDT) invoke some code within a thread Executor or thread pool is only a couple of extra lines. Making state changes to a swing component to display the result is a couple of extra lines (using SwingUtilities.invokeLater()). That's not hard at all...
> Perhaps he felt that he wasn't paid enough for that?
As for if he wasn't paid enough, that didn't come into the equation. Yes he was a junior developer, but he refused point blank to learn which the other junior developers (not just the Java ones) were eager to do.
Re:Getting harder to choose: Java or Python? (Score:4, Informative)
Re:Will anything change for end users? (Score:3, Informative)
Re:Other Linux Java Options? (Score:4, Informative)
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.