Red Hat Plans Open Source Java 422
sthiyaga writes "According to a ComputerWire article, Red Hat is in discussions with Sun about launching an open source version of the Java platform. 'There's always been an interest in an open source implementation of Java developed in a clean room that adheres to the Java standards,' Szulik told ComputerWire. 'We're in discussions with Sun. We'd like to do this with their support.'"
Much needed (Score:5, Insightful)
Sun's Support (Score:4, Insightful)
It'd be hard to do it without Sun's support since they have been known on occasion to get very mad about people making versions of Java without their support. Of course that was mainly about a non-standard version, so maybe it wouldn't matter as long as it followed the standard.
How far is RedHat into this? Planning, Writing, Compiling, Marketing? If they're only planning it, java may finally be dead before it gets done; of course java may outlive me, of course I may die this evening, we just don't know.
Blackdown? (Score:4, Insightful)
be careful (Score:5, Insightful)
If this gets dragged into the JCP process or stays under Sun's "community source" umbrella, it will not be open source in the way that we know it. If people aren't free to "corrupt" the open source Java in any way they like, it will not be open source; for example, one project of key importance for Java on Linux would be native bindings to Gnome.
A closely related question to be answered is what the patent situation around any such "open source" version of Java will be; Sun currently holds several patents that effectively block fully compatible open source implementations. Will Sun dedicate those patents to the public domain? Or will the "open source Java" adopt a license that makes the code open source but lets Sun retain control over who gets to use it through patents?
To Sun, Linux is as much as a threat as Microsoft, and their strategy is the same: make the OS irrelevant by replacing it with a Sun-controlled platform that runs on top of the OS. The Linux community should be as paranoid about that occurring as Microsoft management is. Sun is, ultimately, not a friend of Linux.
Maybe Sun is serious about creating an "open source" version of Java in the sense we all use the term. But I will reserve my judgement until there is something concrete on the table. So far, every promise of opening up Java by Sun has turned out to be a smokescreen and a distraction.
About time.... (Score:1, Insightful)
Re:Native Java (Score:4, Insightful)
Re:Cool (Score:3, Insightful)
OT: THANK YOU! (Score:5, Insightful)
This might be the final kick in the ass that gives Linux the momentum to move on top.
Hey troll/Tool Of The Man (tm) (Score:3, Insightful)
And, it's not a puppet body like some other bodies you might be able to think of.
They added some nice features in
That's the point of copyleft (Score:5, Insightful)
If Java were open-source, Microsoft could take it, deliver it as they saw fit and drive a definition of Java that was divergent from the one that the community wanted to be compatible.
Assume that Microsoft would have called this divergent platform "J++".
If the Java platform were open-source and under a license similar to that of X11, what you quoted would be the case. On the other hand, if the Java platform were open-source and copylefted, Microsoft would have to publish the source code of its J++ platform.
Re:Much needed (Score:4, Insightful)
Isn't blackdown OpenSource? (Score:5, Insightful)
Re:Wasted effort ? (Score:5, Insightful)
Don't blame your bias on the language design, especially when you don't name anything to back it up.
What's the "much more modern approach to networked programming than Java?"
And don't say
Re:Gosling favors Open-Source Java (Score:4, Insightful)
I wouldn't. I like the pressure it puts on companies to Open Source their stuff. Non-Open Source software is inherently untrustworthy because you can't get an independent review of exactly what it's doing.
I don't want to end up with a security nightmare like you have on Windows desktops where it seems like every other program has some kind of call home feature that essentially turns the program into a trojan.
Re:be careful (Score:2, Insightful)
To Sun, Linux is as much as a threat as Microsoft, and their strategy is the same: make the OS irrelevant by replacing it with a Sun-controlled platform that runs on top of the OS. The Linux community should be as paranoid about that occurring as Microsoft management is. Sun is, ultimately, not a friend of Linux
Now I get to ask my other favorite tech-biz question:
What exactly is Sun's business model?
Sun does not make money from Java, it's an expense. They support it because it provides an alternative to Windows in terms of availability, and .Net as a comprehensive framework. But for this to work to Sun's advantage, the message has to be "Java is everywhere, but for best results, you really should run it on a Sun platform. All those other platforms are just there so you can have a common codebase." How will opening the source benefit Sun? Seems that will allow others to make optimized versions for non-Sun hardware or OSes. Sun has to pretend "We're all in this together against big bad M$", while at the same time wondering how to undermine Linux - a nightmare for them.
So far, every promise of opening up Java by Sun has turned out to be a smokescreen and a distraction.
For what seems to be a clear reason.
Re:Much needed (Score:3, Insightful)
And that means ALL the api's, not just the end-user ones, but the internal communications ones as well.
If MS does that, then
Re:Gosling favors Open-Source Java (Score:5, Insightful)
1. C Sharp the language is a standard, but this counts for little since the platform (corresponding to J2SE or J2EE) is really the Dotnet framework, which is not standardized and remains proprietary and patented.
2. Shared source is not open source, in fact, I doubt if many people here would be willing to accept the terms for looking at Rotor, let alone using it.
3. "Not stood in the way of" (yet) other implementations is a little different from actually supporting them. With the Java Platform, not only are there already multiple vendors and dozens of separate implementations, but the legal permission for their development has been set forth in the JSPA [apache.org]. No equivalent exists for Dotnet whatsoever.
(Yawn. Hope I'm not missing anything good on TV...)
Re:Sun's Support (Score:4, Insightful)
Yes, they don't like having their platform polluted. This helps my applications stay portable.
I sincerely hope they continue to keep implementors in line. Don't you?
Re:Much needed (Score:3, Insightful)
I can tell you what it is not [oracle.com].
too little, too late (Score:5, Insightful)
don't get me wrong. i love java, its the only thing on my resume, sole bread-n-butter for past 6 years, etc.
but the C# designers really know the market.
when i first read "C# = java done right" in a PR article, i said, "yeah right, what absolute BS".
but then, i attended my first c# training seminar last month, & having just completed a major java-to-c# porting project, i can say this much - C# has definitely won the windows-only-client-side battle. if you are developing an app that front-ends on a windows client ( that's pretty much ALL of wall street, given the heavy use of MS-Excel ), C# is simply the way to go.
6 years ago, i recall graduating from school & deciding to go into a Java-job. classmates were like - "what's java ? unproven stuff. use MFC. that's were the $$ is".
how wrong they were! C# is now in the same position - poised to skyrocket.
every single java concept has made it into C#.
furthermore C# has several useful notions ( delegates, boxed types, attribute annotations,assemblies etc ) not in Java.
finally, cross-language interop is a dead reality - i can write a C# class, my VB class can inherit from it, and my C++ class can inherit from my VB class, and call functions in Perl - the CLS & the common type system makes it easy for even a casual novice pgmmer.
once's the mono project attains fruition, c# on linux will be the defacto pgmming style - need i say more ?
from a reluctant C# convert
do not download that source code (Score:3, Insightful)
Any open source version of Java must be either a clean-room implementation, or it must wait for Sun to release the JDK sources under the LGPL, GPL, or BSD licenses. And even then, you may still have to worry about Sun's patents in some cases.
Re:Much needed (Score:5, Insightful)
2)
3)
- It has a much faster graphics interface, while maintaining a robust graphics toolkit.
- It has a better messaging mechanism (Events/Delegates are a GODSEND and are the single most useful thing in the framework)
- It interoperates quickly and pretty thoroughly with current COM APIs, and wraps up nicely for use in non-.NET apps
- The Studio environment is faster to work with and has a more mature debugger than any Java IDE I've seen, including Netbeans
- ADO.NET is pretty nicely done, and things like DataAdapters parellel structures I always end up writing in Java anyway.
Anyway, the runtime filesize argument is just crap. The java guys need to get that GUI speed up to par or
Re:Wasted effort ? (Score:4, Insightful)
It's free enough for the uses of almost all users and that should be enough for everyone.
RH has already made the commitment to include only Open Source software in their distribution. Backing down from this would potentially damage some business relationships and alienate some of their users. Until now, they have included only partially complete OS versions of a Java VM. If you wanted the full Java VM, you had to get it from Blackdown, SUN, or some other vendor. RH probably feels they will be more competitive if they can include a full version of Java with their distribution. Open Source is the only way they can do this, and they are probably tired of waiting for the various other "clean room" efforts to meet their needs.
They should take into account the effects of potentially success of SCO attacks on IBM and Linux.
No, they should be wary of any contracts they enter into with SUN.
Especially creating a clean room implementation won't help anymore, it will always be SUN's IP.
Not true. IBM's trouble with SCO was not over a clean room implementation, but over the suspicion that a contract to view "proprietary" material was violated, and the fruits of that contract were implemented in other competing operating systems (IE, Linux). Also, SCO is trying to consider all components of AIX as a derivative work of Unix, and thus under their control. Provided that RH doesn't ask for any development help from SUN, the same situation shouldn't arise. Of more concern would be patents that SUN holds.
Why spend any effort on Java at all ?
Because it's still alive and well on the server side. Having an open source version of java would enable Red Hat to ship "ready to run" web application servers to enterprise customers.
Re:too little, too late (Score:4, Insightful)
Most people will appreciate JDBC drivers for their local database, flexible security, true cross-platform working etc. Conversely,, we can probably get by without "attribute annotations" for a while.
Java out of the web browser? (Score:1, Insightful)
Re:This is not that complicated (Score:1, Insightful)
Java may win either way, but Sun won't.
These people aren't looking to save the world. They just want to make money
They will take the path that has the least risk and the highest potential profit.
Re:OT: THANK YOU! (Score:1, Insightful)
Think about it.
Re:too little, too late (Score:2, Insightful)
RedHat should make better use of their time (Score:2, Insightful)
It would be a much better use of time and talent to make Java work better on Linux wrt:
1. FUTEX support
2. NPTL threads
3. full screen and 2D graphics are horribly slow under Linux because for some reason Sun doesn't seem to use MIT-SHM, or their pixmap caching code is doing the wrong thing...
4. Why not even spend time helping with Sun's ALSA port for Java 1.4.2.
Heck, I'm sure the Blackdown team would have dozens of ideas on how to improve the existing code base.
Rewriting from scratch? Is working together so hard? It would be such a shame to have great Linux coders work to build something that didn't work perfectly and was never used.
interest in Java (Score:2, Insightful)
Re:Gosling favors Open-Source Java (Score:3, Insightful)
There is nothing open or standard about Microsoft's
The entire platform wasn't even created to solve a business problem, it was simply created to kill Java.
Well, that and because of
Java was created to solve an industry wide, 30 year problem. How do you turn software from an expense, into an asset?
You do that by making the software independant of hardware, and making it a part of your IP property of your business process.
Which should be perpetual, respond only to a business need, and not a vendors whim.
The reason why Java was invented was to free companies from buying a PeopleSoft implementation for 10 million and then having your investment totally invalidated by someone who buys the company and destroys your investment.
Like Oracle plans to do.
Open Sourcing Java would simply free licensed implementations from being engaged by the certification process.
I am not so sure, that is great for Java. Sun has been extremely magnanimous in managing Java.
Having a bunch of Open Source implementations running around with no means of making sure they all work the same way is not what I would call a positive thing for Java...GPL'ed or otherwise.
Remember, Java write once run everywhere is critical. Perhaps not in the US, but too all my European and Chinese and Japenese customers, who are quickly moving away from anything Microsoft, and everything Linux, it is very very important.
Some sort of release mechnism will have to be developed to insure that Java GPL'ed implementations are not allowed to fork with non standard runtime libs.
-Hack
Re:Much needed (Score:4, Insightful)
It has a better messaging mechanism (Events/Delegates are a GODSEND and are the single most useful thing in the framework)
The event mechanism is good but delegates suck ass. Here's why:
1) Delegates are slower than interfaces (they're really just classes with an Invoke method and object+function pointers which requires two levels of indirection).
2) Delegates break OO. Suddenly you have something that works differently from other clases for no real benefit.
3) Anonymous inner classes allow you to define the function close to where its used. With delegates you can have a method body pages away from where it is registered with the event. And the method often has very little to do with the class that contains it. Anonymous methods in V2 are a good start but you still need anonymous innner classes (implementing IComparer for example -- which is an interface and not a delegate!).
Now, events are good. Having the "event" keyword and automatic wiring is useful. But there is no reason why the "event" keyword couldn't work with interface types instead of delegate types. Having worked extensively with delegates I've gotta say that they simply complicate the type system.
Re:If you don't like swing... (Score:3, Insightful)
1) In contrast to the rest of Java, you have to remember to explicitly free everything you create.
2) Cross platform stuff goes out the window, unless you can make sure a SWT lib is installed everywhere you want it
At the very least, with an open source Swing, you could ship say, a linux binary, but also ship the class files for other clients.
Re:OT: THANK YOU! (Score:1, Insightful)
Fuck you Bible Thumper. If you're going to pray, don't waste the effort on bullshit like java when kids are starving at this very moment. Some XIAN you are!
Re:Much needed (Score:3, Insightful)
Ever try a Factory method? I thought at first that's what you were describing, but maybe you don't know. Generally a static method, you pass it parameters which it uses to decide which class in the hierarchy to instantiate and return.
Check out Design Patterns by Gamma, Helm, Johnson, and Vlissides. It covers the Factory pattern and much more.
Re:Much needed (Score:2, Insightful)
Ah, the usual slashdot "modded up because it sounds like he knows what he's talking about" problem.
1.Delegates are slower than interfaces.
And interfaces are slower than function pointers. Storing a pointer to an "interface" is actually storing a pointer to an object, which is in turn just an empty object with one data member which is a pointer to a vtable. So it takes two levels of indirection. You cant complain that delegates arent the most efficient way forward when interfaces arent either.
Surely what you mean to say is that interfaces are slow, and we should all just use function pointers? Ah, but function pointers dont carry a this pointer, which means we dont know who called us. But not call-backs are for objects. Some are for global or static objects, so the this pointer is a waste.
Alternatively, perhaps you could create a functor that would create at run time a class that calls your object specifically. Ah, wait, thats delegates!
At the end of day, the extra machine instructions for implementing interfaces and delegates is neglibible compared to the kind of code that gets executed as a result. For example I use delegates a lot for windows messages, which usually result in several thousand to a million pixels being redrawn. Five extra assembly instructions and memory cache miss dont seem like a terrible price to pay for better OO design now does it? And so we come to point 2.
2. Delegates break OO. Suddenly you have something that works differently from other classes for no real benefit.
No programmers break OO. If you think that the class/instance method is the be all and end all of object oriented programming then you need to take a look at Smalltalk or OpenCyc. Using classes does not make you an OO programmer.
Can you write horrible, non-oo code using delegates? Yes. Can you write horrible non-oo code using classes and interfaces? Yes. Is all code using delegates non-OO? No. Is all code using classes non-OO? No.
3. Anonymous inner classes allow you to define the function close to where it is used. With delegates you can have a method body pages away from where it is registered with an event.
So with delegates they are bad because a programmer could write unclear code by putting the delegated function definition well away from where the delegate is initalised? This is as compared to the horrible unreadable code you'll find if you put "anonymous inner class java" into google. If you had to create 10 such inner classes would you advocate putting this code all in one initialisation function (such that it is very big), or would you create 10 seperate initialiser functions that the first calls (such that the code that calls the initialisers is possible pages away from the actual code of the initialiser)?
And the method very often has little do to with the class that contains it?
And anonymous inner classes prevent this how? Oh. They dont.
Give it up mate. Java is an old, hacked, bungled, proprietary language from a monopolistic company. If there's going to be an open source language, get behind Mono, and make open source .NET.
Re:Not as a whole but (Score:3, Insightful)
There is only one implementation of Java, together with its derivatives by licensees. As long as that is all there is, its license matters, because nobody has demonstrated so far that they are capable of producing an independent implementation.
Why not? I see you dropped my point about keeping old libraries around for old releases of Java if they work better.
You can't just mix and match libraries. If you run a version of Java linked against old libraries, it won't be able to load code linked against new libraries, it will have security holes associated with the old libraries, etc.
I see no, zero, nada, zilch difference between a distro release and something like a solaris release. There is none. The distro maintainers keep stable versions of Java around the same way Sun does.
Sun doesn't "keep stable versions of Java around", Sun has the option of recompiling Java and fixing bugs and incompatibilities in Java when they make a new operating system release. Because Sun owns the copyright, Sun gets to make those choices. Linux distributors, on the other hand, face the possibility that Sun stops making Java available or breaks the Java distribution whenever it suits Sun.
The ability to fix bugs and recompile packages from source is at the core of open source systems. It is what has made Linux such a success. It makes no sense for open source developers to say that open source is a good idea, but, hey, for Java we don't really need it.
None of them caught on because they offered poor coompatibility, because Windows is not a published spec - unlike Java which is.
The Windows and Java APIs are documented in pretty much the same way: as a huge collection of vendor-supplied documents aimed primarily at programmers. Neither set of documentation rises to the level of a "specification", and both have significant gaps. That's why making a third party Windows implementation was very difficult, and the same appears to be true for Java. Sun Java really is like Microsoft Windows in that regard.
If you're at all a fan of Linux, then you need to think about what a world where Java (the most commonly used enterprise programming language by far) is owned by MS and runs best on Windows servers. By-By Linux! Seriously, that is how it would be.
You say that it is perfectly fine if there exists only a single, proprietary implementation of Java as long as it is owned by Sun, but if that implementation were owned by Microsoft, it would be bad? Where is the logic in that?
I don't see any difference between Java being proprietary to Sun and Java being proprietary to Microsoft. Both Sun and Microsoft are companies that would like to see Linux go away because it eats into their business, and both have a strong incentive to make sure that Java runs best on their own servers and performs less well on Linux. That is exactly the problem.
Fortunately, it hasn't gotten to that point yet at all, since Java is not very important on Linux yet. As soon as there exists a full open source implementation of the Java platform on Linux, an implementation that neither Sun nor Microsoft can mess with, I'm all for widespread use of Java on Linux. Until then, Linux users should stay away from Java.