Slashdot Mirror
Sun Withdraws Java from Standards Process
An anonymous reader pointed us to a story over at ZD Net about Sun withdrawing Java from the ECMA Standards body. They say they want to protect the "Integrity" of the company's investment in Java.
← Back to Stories (view on slashdot.org)
There are differences between what Sun is doing and what Microsoft has done. (And this analogy is getting really tired of being trotted out for any company Redhat's size or larger.)
:)
First, Microsoft does not license their Windows technology to anyone. (Wince doesn't count.)
Sun licenses their technology to anyone that wants to pay the fees. In fact, Sun would be happy if they never had to do their own JVM implementations. They would be content to provide a reference implementation and compatability testing.
Microsoft charges for everything.
Sun gives JDK, JRE, etc. away for free... and has even made the JDK more free.
Microsoft does not provide a source for input to the evolution of their products.
Sun provides a Community Process to which anyone can become a member for a fee. Sure, not any old Joe can give his input, but would we really want a language developed by popular vote? I sure wouldn't.
Microsoft creates products to push their own defacto standards for API's and such.
Sun regularly publishes draft standards for Java extensions. Many of which are designed around third party implementations to be plugged in.
In conclusion, Sun controls the Java platform but not with the same stranglehold that Microsoft has on anything Microsoft. And this difference is significant.
If Sun suddenly decided to take Java in strange directions that the majority of the Java development community didn't agree with, Java would live on as another language. If that happens then I'll be the first one joining in on the Myva(?) project.
However, right now I think Sun is doing a fantastic job and I'm willing to give them some leeway.
Edu. sig-line: Choose rhymes with lose. Chose rhymes with goes. Loose rhymes with goose.
Comparing? THEN use THAN.
That's one way give a good uppercut to developers who are trusting you. So now Sun completely controls Java. They're reneged on their promises now that developers have put alot of time and effort into Java, because they believed in it, and they believed Sun was making their best effort to move it to a standardized base, and do things for the good of Java, which, in the end, is for the good of then.
Suddenly, *WHAM*. We need to protect our investment.
Goodbye good 'ole Sun, HELLO Microsoft II.
-- I'm the root of all that's evil, but you can call me cookie..
Is ECMA a legitimate standards body?
Are they producing standards that help to advance the state of the art?
The reason I ask this is because my only previous knowledge of ECMA is the certification that JavaScript (aka ECMAscript) went through. If memory serves, the ECMA group was chosen over other more well known standards organizations because it was thought to be easier to influence, thereby orchestrating the outcome. Ever since then, I have wondered about this organization.
Now, ECMA is in the news again. But, this time, a Slashdot community member posts a link to the ECMA Web Site. So I have the opportunity to check out the roster of member companies. If you look at them, you will note that practically every one is a multinational that is not based in Europe.
I guess that this point, in itself, doesn't say much. Except that there must have been a much bigger number of true European companies in ECMA back when it was founded in 1961. But, then I notice that at least one European computer manufacturer that I know of, Bull isn't a member. Neither is Nokia, although Ericsson is.
There is an organizing body in the sport of boxing known as the IBF. It was created as an alternative to the WBA and WBC, and seems to exist for the sole purpose of having an alternate slate of champions who can challenge one of the more established sanctioning bodies' champions.
So, my ultimate question is, does ECMA serve the same role in the technology world that the IBF appears to serve in the boxing world?
--
Dave Aiello
-- Dave Aiello
A web applet language [snip...]
That opening line destroyed whatever credibility you could have established as someone who knows what he/she is talking about. Java is not, has not or ever will be a web applet language in fact what the fsck is a web applet language?
IIRC, Java was originally designed for embedded systems and workstations/servers. That's why the VM and portability was the main push behind the language. With the advent of the World Wide Web, Sun added a few tricks to Java and enabled people to write web applets. The funny thing though, is that now Java is primarily seen not as a GUI development language (better use C++ or VB if your a pseudo-programmer) but as a quick and powerful server side development language.
Bad Command Or File Name
I set up a mailing list, got a group going, and we started to go into our design phase. We looked at the new features that were going to go into 1.2 and decided to wait for 1.2 to come out and the spec to settle down. We shelved the effort until that point.
We never started up again. The java spec went all over the place and I decided that I didn't like Java for one of the same reasons I don't like Microsoft -- I don't want to be a member of the API of the week club. I have better things to do with my time.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
According to the article Sun thinks Java can stand on its own. In other words, Sun is saying "We don't need you anymore; we write our own ticket from now on" to ECMA.
They seem to be saying "we don't need you-you need us" to developers too (SCSL?). They might have been better off not portraying themselves as the knight in shining armor, then abandoning that role once it had any disadvantages (at least short-term). At least with Microsoft, developers have no illusions about motive; you know what you get there.
There may be a lot of scorned developers out there who react like they have been betrayed by Sun. If that happens, we will find out if Sun "doesn't need you anymore."
This will hurt Java in the short-term since it will be more difficult to develope code that will be portable to [the now non-existent] Java 2 standardized platform. However, I don't think that this will negatively affect the Java language itself in the long run. Java as a language will live or die on its own merits, of which I believe that it has many. It is a type-safe language built from the ground up to support OOP. For thirty years, C has withstood the test of time despite not _ever_ having a standard platform; the same assessment applies to C++ as well. A careful programmer can exploit the benefits of the language while mantaining portability and efficiency using the same methods that he/she have always used. Sun's decision will probably help Java in the end because of this.
--
Flames? Think I'm a karma whore?
It looks to me like Sun is looking for a standards body who will put their name behind Java, while letting Sun handle the actual "standardization" process. Unsuprisingly, they're not finding a body to do this.
So, who's left? I seem to recall they've already tried ISO, they've tried ECMA, and they're sure to get the same reception with the IETF.
This article (in german) tells us that "the head of technical commitee 41, Michael Wheatley (IBM), possibly wants to continue with the standardization of Java even without Sun's support.
I guess they own the trademark, and a bunch of the code that's out there... but do they own other intellectual property involved, or is everyone simply worried about fragmentation?
Why doesn't ECMA simply go ahead and standardize the same thing under another name... perhaps the contracts that the current players in the Java industry have disallow them from going it "together" against Sun alone?
See, I'm speculating. It would be nice if someone who knew the answers could chime in.
So far, Sun's Java specs are explicitly open: you can use them to build your own compatible implementation (you just can't call it "Java"). And Sun's Java specs are detailed and quite complete. This is in stark contrast to the Win32 API specs, which are so poorly documented that for practical purposes, it's not possible to make a complete independent implementation.
However, dropping the standardization effort also is bad PR because it gives the impression that Sun is renegging on their commitments.
One point of concern is that Sun every now and then seems to make some fuzzy claims about intellectual property related to the Java APIs. No matter who drives the evolution of the Java platform (Sun or a standards body), those parts of the Java specs would clearly not be acceptable to most users of Java, and that is something users need clarity on up-front.
If Sun does make IP claims related to parts of the APIs (rather than their implementation), that would be a serious matter and would have to be identified up front. That is a point, I think, Sun needs to be pressed on so that we don't end up in a situation analogous to GIF/Unisys. Those APIs would likely be only a small part of the Java platform and easily replaced by alternative de-facto standards developed outside Sun.
I've been to many JavaOne conferences, and a few of the other presentations when this topic comes up. All kinds of people have their own little pet additions to Java. Multiple inheritence is one. Do people miss it? Sure. Do they need it? NO. I've been programming in Java professionally for four and half years now (since the day it went public). I've never ONCE run into a situation where I've been stopped by this. And you know what? The code is cleaner because of it. Say what you want, but multiple inheritence is just a huge mess for the next poor slob that has to maintain the code.
What's the point of that rant? Without Sun (and mainly Gosling and Guy Steel) holding the reigns on the Java up until this point, all kinds of confusing crapola would have been added to the language (just look at what Microsmurf tried to add), and it would have gone from a simple, elegant language to a huge mess.
I think Sun (specifically the team of people that keep an eye on what to add) has been doing a pretty darn good job so far. Without the people who knew from the beginning what the original intent of the language was, Java would have degenerated into a mismash of crap.
Java promised us a compile once, run anywhere solution, and for a few years, it looked like we would get it.
Well, we didn't; and we aren't going to out of java, not for a long time.
I think its time that we consider abandoning java, and starting up a new program. The real wonder of Java is, and should have remained, its virtual machine, and if Sun had developed a robust VM, and kept it seperate from the language, then developing for the VM would be just like developing for any other computer archetecture, and we could have used our languages of choice and cross-compiled to the VM.
In addition, an independant VM would have less security issues than a merged language/VM, and it would become easier to maintain the sandbox.
In conclusion, we need an OS VM, and you can write C, I will write C++, and my buddy will write Fortran and Assembler, and they will all run on it.
-Crutcher
-- Crutcher --
#include <disclaimer.h>
I see IBM (and HP also) as entirely different than MS here and can not see them developing their own versions of Java. It makes sense for MS to bastardize Java because they are enitrely for the proprietization of the language to the Windows platform. They have nothing else but Windows and do not desire their "enhancements" be available on anything else. IBM and HP on the other hand have a much larger set of platforms which they support in various ways. In the case of IBM, polluting Java would require polluting it for OS/390, OS400, AIX, as well as Windows, Linux and many other operating systems that they often make their products available for. IBM is very concerned about portability as many of their software applications run on several (or more) platforms. Just check pretty much any product at www.software.ibm.com and you will likely see that the product you look at is available on several platforms (MQSeries is available for well over 20 different platforms and is not alone). IBM is making a big push in the Java arena already specifically for its platform independence and development speed, polluting Java would not make sense for them. This is an investment which they have already made and very likely will continue to do so and not by bastardizing the language.
Indeed, standardization only slows things down. Java is evolving rapidly, any standard would be obsolete before it has gone through the acceptation procedure. I.e. a standard has little other than marketing value.
If you look at standardization of Java, there's three things that can be standardized:
- the language
- the bytecode
- the API
Standardizing the language at this point would not be a good thing since interesting language extensions are being developed at the moment (classes with parameters). As long as the extended languages are backwards compatible that's ok with me.
Standardizing the bytecode would probably be not very harmful but I don't see any immediate advantages either. The bytecode and the VM have been pretty well described already and anybody can make a cleanroom implementation of it. As far as I know the specs have been very stable. It should be possible to compile old jdk 1.02 programs with the latest JDK and run the resulting bytecode on an old java VM (provided the new API doesn't clash with the old one).
Standardizing the API is rediculous. The java API is a moving target, functionality is being added continuously and the existing API is also perfected from time to time. Fixing the API is not a good thing since I want new functionality and I want those errors fixed in the existing API. In any case a standard API would be lagging behind the current version of the API making it pretty much useless.
Jilles
Now that they own StarOffice, is this move an indication of things to come. IE. will future versions of StarOffice only run on SUN's Java VM?
ABIWord is looking better and better.
Finkployd
Since Sun obviously can't be trusted to do the right thing as far as opening this platform up I don't install any Java VM on my Linux boxen. Support an open object API for Linux, support GNUstep.
Java is over. The future belongs to Objective-C.
Night
A web applet language should be well integrated with HTML, not segregated into little square windows. Does anyone remember Curl? Not the web grabber, but the lispish thing with curly brackets at MIT. It was a brilliant idea. It replaced HTML, Java, Javascript, Flash, etc. with one quite adequate language. Unfortunately, nobody seems interested in replacing HTML.
A run-anywhere platform should not be tied to specially designed languages. You should be able to compile your C into bytecode that will run on any system. It wouldn't be a big deal to implement, many game emulators do a bigger job. You'd have to provide a low-level window library, but that's really no big deal (the insanity begins when you try to make a high-level window library, and anticipate everything the programmer might want to use).
Let's face it, Java went as far as it did on a huge marketing campaign, not on its technical merits. It didn't deliver on its promises, and those not caught up in the trendiness saw that it never could. Let's not waste any more time with it.
I agree. Sun has a process for contributing to Java's evolution. Sure, they have final say, but they've done a good job so far at weeding out the bad ideas. In that sense, Sun has set themselves up as their own standards body with a vested interest in the success of the language they guide. And the process is working.
I think the language is still too young for a totally committee based evolution. It would be 5 years before we saw a new version.
Rather than convincing Sun to do something as drastic as giving over their baby to a third-party, maybe we should be working on having them slowly open up the Java Community Process a little more.
I personally have no problem considering them to be their own standards body. At least for the forseeable future.
Edu. sig-line: Choose rhymes with lose. Chose rhymes with goes. Loose rhymes with goose.
Comparing? THEN use THAN.