Simon Phipps on the Process of Opening Java 152
twofish writes "Simon Phipps, the chief open-source officer
at Sun Microsystems, has reaffirmed Sun's
commitment to Open Source in an interview
with computerworld.
The focus of the interview is Simon's efforts to fully open source Java.
He points out that many problems need to be resolved before
Java can be open sourced — ownership, legal, access, encumbrances and relationships
with Java licensees. It took Sun a full five years to solve these issues with
Solaris. However Simon predicts that it won't take anything near this amount
of time to complete the task with Java.
Of course, one of the other concerns for OS Java is the resulting incompatible
versions and breaking of the Java WORA
model (Gosling himself has always been particularly concerned about incompatible
forks resulting in the introduction of an open source version of Java) and this opens
up additional problems for the open source Java model."
Quit the talking (Score:4, Interesting)
Re:Java already breaks the WORA model (Score:3, Interesting)
Re:Java already breaks the WORA model (Score:3, Interesting)
The majority of "interesting" Java applications I've seen were restricted to a single platform for various reasons, mostly because they apparently (somehow) were making platform-specific system calls. (I don't know the exact details of this, all I DO know is that there are plenty of Java applications out there that are restricted to a single platform for whatever reason. I may be wrong about the reasons, but the fact is that WORA failed on the desktop)
What about WORA for J2ME (i.e. on mobile devices)? The situation seems even worse. If you go to the download site for nearly any Java game designed for mobile phones, they will list different downloads for every model of phone they support, with varying filesizes. Not a single Java application designed for other phones has worked with the JVM available for PalmOS 5 devices such as my Treo 650.
If WORA had ever actually worked, I'd accept Java's unwillingness to break it. Unfortunately for that excuse, it's hard to break something that is already broken.
Chief Open Source Officer? (Score:3, Interesting)
Please.... someone, tell me why there needs to be an "officer"--much less a "cheif"--within a corporate environment. Aside from convention, what practical use would such a high paying position render? Management? Bah, the realities of management... is a given with shuttles exploding on international television and multi-billion dollar corporations such as Enron, to the everyday corporate life of meaningless and unproductive meetings setting deadlines, project goals and planning... it's all crap, and never useful.
But, even if it's "management"... it's interesting that a corporation would feel the need for such heirarchy to "manage" any aspect of a system which itself, has no such structure.
Re:Java already breaks the WORA model (Score:1, Interesting)
When you can't get applications to run on the same version of the Sun JRE *on the same computer* it's fairly safe to say that WORA has never been achieved.
Another good hint is when developers have to "port" their application from their own desktop to work properly on the test server. "WORA" was at best a dream of how code should work rather than a reality.
(Although I've never had a problem getting Perl, Python, or PHP scripts working on different OSes. In fact, the only environment I've ever had massive problems getting to run on different systems, even when running the same OS, was Java.)
Re:Java already breaks the WORA model (Score:5, Interesting)
A good example of a portable J2ME app is opera mini which exists in only two variants the both of which work across pretty much all java capable phones except maybe for the really crappy ones, such as your Palm based one (blame Palm, not Sun). J2ME is a modular specification which unfortunately leads to the interesting situation that the more of the modules your app uses the less portable it becomes. Pretty much all of the modules are optional and with MIDP 1.0 many vendors added loads of vendor specific APIs as well. Many applications written for that mixed bag of standard and non standard extensions are not portable.
MIDP 2.0 mostly removes the need for vendor specific APIs (though many vendors still ship them). Upcoming MIDP 3.0 is even better apparently. of course many games need to make assumptions about device specifics (e.g. screen size, number of colours, keyboard layout) which unfortunately leads to many portability issues. These problems are hard to solve and currently J2ME seems the best solution the market has come up with. Most device specific binaries of J2ME apps merely include some minor modifications, optimizations and packaging. I agree that testing for all that is a major PITA for developers. If you have a better solution that works for non trivial applications across the thousands of different brands and types of mobile phones, get some venture capital and get rich!
Re:Incompatible Java forks (Score:2, Interesting)
If J++ were created with an GPL-like opensouced java, it would be easy to port J++ to run in linux and firefox, which was the whole point of making J++ incompatible.
It's not Microsoft trying to kill java like with J++. They want their java to continue being theirs. They dont want to give it away.
Re:Java is a toy (Score:1, Interesting)
No, it's not. It's a horrible language to teach to beginning students, and there are plenty of scripting languages to use for people who can't use low-level languages.
The problem with Java is that there's too much crap you have to teach people before they can learn to use it. A good beginning language allows people to learn simple logical structures before moving on to data types and structures. When it comes to learning a language, the number of lines Hello World takes is a good metric to how much "glue code" you have to teach before a new learner can start to learn even the very basics.
Java's Hello World:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World.");
}
}
Five lines, only one of which has to do with the task at hand (displaying the text "Hello world."). You have to show access modifiers, explain classes, potentially explain packages, and explain methods, all to get to Hello World.
Python, on the other hand, takes just one:
print "Hello World."
Python allows you to slowly introduce concepts and build up to an understanding of data structures and other more complicated things. Python is a good language to start learning. (Some people disagree due to the indentation requirements for Python, but my feeling is forcing people to use proper indentation while learning probably helps in the long run and makes the code easier to read and understand.)
Anyway, Java's a horrible language to teach new CS students, although unfortunately most colleges do anyway. But they shouldn't. Start with a scripting language to teach fundamentals, then move to C to teach more complicated tasks. Move to Java only when getting ready to prepare students for common "real world" tasks.
Re: Someone has to say it (Score:3, Interesting)
I do find Java a good fit for a certain class of programming tasks -- namely those which require the software to run on a diversity of platforms. In that regard, I don't think anything can beat Java. If only Windows shipped with a good JRE...
However, I do disagree with some of your points. For example, no matter how good Swing is for programming, it will always suck since it renders widgets itself. Even though it has pluggable look-and-feel, it isn't possible to always make it look like a native application (try to write a look-and-feel for "the currently selected GTK2 theme", for example...). Also, even though Java's library support may be good, it quite much sucks that it is impossible to do OS-specific calls. I realize that that is because of the WORA principle, but it quite much sucks that it is impossible to, for instance, write Unix programs that use setuid in Java. I cannot imagine that it would hurt to add OS-specific calls for programs that just don't care about being OS-independent (especially not if they were added in seperate packages, like os.posix or os.win32, so that they won't be confused with OS-independent classes), right? By the way -- yes, I know about JNI and, no, I don't think it counts.
Basically, I think that the JVM and the class library are pretty nice (not perfect by a long shot, however), but the Java language itself just sucks. I have often considered making an alternative language that compiles to Java class files.
Re: Someone has to say it (Score:4, Interesting)
Java 1.5 made the language a LOT nicer and more expressive.
Re:Who will fund future development? (Score:2, Interesting)
The corporate world can deal with it, or it can fund development. As a multi-year volunteer on Perl 6 design and implementation, I can proudly say that the corporate world's opinion doesn't matter unless it's willing to do something about it.
Re:Incompatible Java forks (Score:3, Interesting)
sure, which is only slightly different from the current truth: "write once, debug everywhere"
It's not that I disbelieve you, but could you give me examples where you've needed to do something platform specific with code written for J2SE or J2EE? I have written several very large Java apps (both standalone and web applications) but never had issues with running the resulting code on different platforms. Heck, the last system I worked on ran out of the box on Solaris, Windows, Linux and NetBSD. The only time I've run into platform specific issues is with handheld devices running a third party JVM. I do keep on seeing these complaints about "write once, debug anywhere", but never had an opportunity to find out why.