Slashdot Mirror

NetKernelTM Microkernel is a REST microkernel. It provides a clean, robust and scalable foundation for the development and delivery of robust, scalable and adaptable systems.

Java bindings to Open GL ES

There is an existing 3D API for J2ME devices, JSR 184. It provides effectively the same functionality as this JSR will. However, it is object-oriented and thus the interface to the underlying functionality is completely different from OpenGL. This JSR will cater especially to the needs of those developers who are already familiar with OpenGL, and furthermore do not require any of the high level functionality provided by JSR 184. Further, with the abundance of OpenGL applications on the market, having an API based on the OpenGL specification will ease the efforts of porting these applications to the J2ME platform. Providing Java bindings to OpenGL ES will ease the effort of moving applications from the ME space to the SE space and vice versa

No, this doesn't exist in any devices - yet.

The "J2EE 5" link in TFA links to OpenSolaris, not to http://java.sun.com/j2ee/5.0/index.jsp or http://www.jcp.org/en/jsr/detail?id=244 .

If you'll look at harmony's website, you'll see that they aren't just implementing the Java Virtual Machine as you put it. They are implementing J2SE. J2SE is not just a language. It is a platform.

Platform fragmentation is as, or more important than, language fragmentation*. A language cannot stand alone. You need libraries. Platform fragmentation is what Sun is worried about right now, not language fragmentation. The JVM is not even part of the "open source java" debate, since open source JVMs already exist and Sun is more or less encouraging them!

Please see my other comment here.

* Language fragmentation can still happen if Harmony chooses to implement different JSRs than Sun does for some reason. However it is incredibly unlikely that this would be a bad thing. As long as Harmony stays within the accepted protocols for extending the Java language, and keeps any experimental/unapproved-JSR features cleanly quarantined within the -XX "pragma" flags (both of which things, Microsoft did NOT), this will be fine.

You missed gcj, which eliminates both the VM and runtime compiliation overhead.

Might as well screw deterministic memory- something more than necessary with realtime embedded systems.

This problem is eliminated with gcj, as long as you know what you're doing regarding GC. There is also a real-time specification for Java, which was apparently used to program a sophisiticated Boeing drone. This was announced at JavaOne earlier this week. Finally, the Javolution library is a useful tool in this area as well.

Maybe JIT moved Java from being fully interpreted, but it's still interpreted and "compiled" at runtime making it theoretically (a.k.a Javaly) and realistically on average always slower and more of a memory hog than unnamed alternatives, that's all. But, sometimes that's ok right?

Apparently, in the case of VB, Perl, Python, Ruby etc. etc. etc. Besides, as I pointed out above, there are ahead-of-time Java compilers. (JET is a commercial alternative for Windows.)

Look at how Java has taken over the desktop application market where that least matters. How many Java desktop applications do you run?

Several.

Can you tell it's Java?

No, not in the case of Eclipse, Azureus or RSSOwl. Can you? (BTW Azureus is one of the top applications on Sourceforge.) Others are minimally identifiable, but their interfaces are no stranger than Winamp or many other current applications.

If programming will always be hard, one might wonder what skeletons in the closets Java fanatics have at the price of conformity to an interface. Java version incompatibilities, buggy VMs, oh my.

As opposed to (just to pick my favorite whipping boy) C++ compiler incompatibilities, memory issues, third-party library incompatibilities, and fragility?

Java isn't perfect. I'm personally interested in seeing a truly open language developed which is more suitable for HPC, numerics and realtime, and leverages the best features of Java and C#. Until then, however, I think Java is a very good alternative for many projects, large and small.

Anyone who writes in Groovy, Python, ObjectScript, JavaScript, NetRexx, and many others. There's a scripting JSR as well. I don't think the original poster had this specifically in mind though.

Another approach to the problem: JSR 170: Content Repository for JavaTM technology API
Standardizing the interfaces to various data resources (filesystem, database, cache, ...).

The expert group reads like a who's who in data management. And it seems to be very near to the final draft.

the OpenOffice developers are using proprietary classes from Sun's Java runtime library.

You mean the ones that are fully and openly documented, and have source code available in both the JDK binary download and the full SCSL source downloads?

This has everything to do with runtime libraries -- not the same thing as compilers, Bonzo.

That's "Bozo", bozo. ;-)

Java Hate comes three main forms:
Free! It ain't. Some people argue it is "less free" than .net, others say it is more so (anyone can join the JCP for free (beer), is joining the ECMA as easy?) Nor is it, or Sun as OSS friendly as "they should be". With the source code for Java is aviable to download, it does not have a pro-distribution lience.

Slow! Most modern benchmarks (1.4) show Java to be comparitive to native and .NET in most cases (trig being the big downfall at the moment). However many people used it in its 1.0/1.1 days, when it was slow, and refuse to update.
Its not the fastest at starting.

Swing Some people love it, other loth it. Guess which group are more vocial ;)

> Will open sourcing Java source code mean that the language will get submitted to a standards organization like ECMA or ISO or something?

It's already under control of a standards organisation - the JCP.

Whilst it's lead by Sun, there are members from all through the Java community, making it arguably a more relevant standards body than ECMA or ISO as far as Java is concerned.

Submitting Java to ECMA or ISO would not achieve anything that cannot be achieved via the JCP, and would possibly even be detrimental to its development.

Is the gist of this news item that IBM is abandoning Java for PHP?

No, it sounds like they just want to support a scripting language for use in the application server and the Groovy standardization process (of which they're a part) is probably going too slowly for their liking.

The difference between Java and Mono is not a technical one in the first place. Both are modern platforms with a JIT compiler and a prefered OO language. Both run on multiple platforms and for bioth are multiple languages available.

The problem is more a political one. On Mono, future language extensions are dictated by Microsoft. The Mono developers could of course extend their VM in any way they want. But they would loose compatibility with Windows.

On Java everyone can join the Java Community Process (JCP). Membership is free and every member is entitled to vote and can even run for election.

Datails can be found at Javalobby.org.

"Power arises when groups of people act in concert." (Hannah Arendt)

C# is an ECMA standard (which of course with generics et al Microsoft is breaking). This is NOT open, and certainly not in comparison to Java.

The Java Community Process go to the site and have a look at the "closed" and unchangable monstor that Sun has created. I mean its just scary to think that Java 6.0 is ASKING FOR JOINERS, to input into the next standard.

How would you become an ECMA member and propose changes to C# ?

C# is an ECMA standard (which of course with generics et al Microsoft is breaking). This is NOT open, and certainly not in comparison to Java.

The Java Community Process go to the site and have a look at the "closed" and unchangable monstor that Sun has created. I mean its just scary to think that Java 6.0 is ASKING FOR JOINERS, to input into the next standard.

How would you become an ECMA member and propose changes to C# ?

There is already a JSR for that would define a standard for Jail-like compartments in a single JVM process:
JSR 121: Application Isolation API Specification

Problem is, this JSR is going nowhere. There are some big corps onboard, but no one seem's interested in defining a common API. Sun's management is clearly not interested (more precisely, "Sun's managment has decided not to commit any resources to this project in the short term.") So there are lots of research papers, prototypes and Master's thesis, which are all very interesting, but no working implementation that everyone can use.

That's really sucks because with an implementation of this JSR, the JVM could get a lot more OS-like. Too bad.

The TCK will be available to Qualified
Not-for-Profits and Qualified Individuals for no
charge as per Section F.III of the JSPA 2.

SUN IS WILLING TO LICENSE THIS SPECIFICATION TO YOU ONLY UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS LICENSE AGREEMENT ("AGREEMENT").

The util.concurrent package has been very popular among open-source projects, and is known for its strong performance. In many cases, migrating from util.concurrent should be as simple as importing java.util.concurrent.class instead of EDU.oswego.cs.dl.util.concurrent.class .

Of course, one of the improvements made by JSR166 is to genericize all the interfaces and classes, so what uses to be a BlockingQueue is now a type-safe, parameterizable class BlockingQueue<E>.

Not all of the toolkit made it into the 5.0 release in time, and the missing stuff, referred to as jsr166x, which comprises "concurrent sorted maps and sets, as well as concurrent double-ended queues (deques)", is available for use.

Doug also offers a JSR166 maintenance update that fixed a bug in one of the classes.

You can also obtain and modify Java's code as you wish (see http://java.sun.com/j2se/1.5.0/download.jsp) but you can only *distribute* your modifications for the purpose of "research" (so not as part of a commercial product for example).

Java is "bazaar"-like because the JCP provides a mechanism for groups and individuals to create proposals to evolve or extend Java which are ratified by a committe (again of groups and individuals, essentially chosen in a meritocratic manner). This could be compared with Mozilla's team of super-reviewers.

Jonathan's point is that Linux (the kernel) is cathedral-like because decisions about changes to the kernel are made exclusively by Linus Torvalds.

Java has open processes for becoming a member of the change committee (see http://www.jcp.org/en/participation/membership) and for submitting proposals (see http://www.jcp.org/en/procedures/jcp2#1).

"Linux" in the broadest sense (see http://blogs.sun.com/roller/page/ColmSmyth/2004111 6#linux_is_an_open_source) has aspects of both the cathedral and the bazaar.

I really find Eric Raymond's seminal CATB article (see http://www.catb.org/~esr/writings/cathedral-bazaar /cathedral-bazaar/index.html) to be an essential read, but it's terminology is IMHO too obscure to be used effectively in discussions like this; I find well-known terms like "dictatorship" (Linux kernel), "meritocracy" (Mozilla.org, "Individual Expert"s on the Java JCP Committee) and "feudal" (GNOME.org) are clearer.

http://blogs.sun.com/ColmSmyth/

You can also obtain and modify Java's code as you wish (see http://java.sun.com/j2se/1.5.0/download.jsp) but you can only *distribute* your modifications for the purpose of "research" (so not as part of a commercial product for example).

Java is "bazaar"-like because the JCP provides a mechanism for groups and individuals to create proposals to evolve or extend Java which are ratified by a committe (again of groups and individuals, essentially chosen in a meritocratic manner). This could be compared with Mozilla's team of super-reviewers.

Jonathan's point is that Linux (the kernel) is cathedral-like because decisions about changes to the kernel are made exclusively by Linus Torvalds.

Java has open processes for becoming a member of the change committee (see http://www.jcp.org/en/participation/membership) and for submitting proposals (see http://www.jcp.org/en/procedures/jcp2#1).

"Linux" in the broadest sense (see http://blogs.sun.com/roller/page/ColmSmyth/2004111 6#linux_is_an_open_source) has aspects of both the cathedral and the bazaar.

I really find Eric Raymond's seminal CATB article (see http://www.catb.org/~esr/writings/cathedral-bazaar /cathedral-bazaar/index.html) to be an essential read, but it's terminology is IMHO too obscure to be used effectively in discussions like this; I find well-known terms like "dictatorship" (Linux kernel), "meritocracy" (Mozilla.org, "Individual Expert"s on the Java JCP Committee) and "feudal" (GNOME.org) are clearer.

http://blogs.sun.com/ColmSmyth/

Tomcat is many things:

• an open-source servlet container developed by the Apache Foundation
• the reference implementation for the Java servlet specification
• a container for JavaServer Pages
• a standalone web server
• an add-on for Apache and other web servers

The key is understanding what a servlet is. A servlet is an instance of a Java class that is invoked in response to an HTTP request. In other words, it's custom Java code for handling and responding to HTTP request by web browsers and other clients. Think the Java equivalent of CGI applications. If you like Java, servlets (and the JSP technology that is built on top of them -- JSP pages compile into servlets) are a nice way to build dynamic websites.

You can use Tomcat in standalone mode or by hooking it up to a web server like Apache -- it ships with a module for the latter that directs servlet requests from Apache to Tomcat and back.

It's getting easier to find hosting services that offer servlet support, and they usually run Tomcat to do it. Personally, I use KGB Internet, but check the list of servlet ISPs for other alternatives.

While neither Java nor C# is truly free of being controlled by an Evil Corporation(tm), Java at least has multiple vendors, runs on a wide variety of platforms, and has an open standardization process.

Ubiquity and Dynamicsoft have SIP Servlet containers implementing the spec; there's also a reference implementation here to play with.

though even there Java had Javadoc tags long before C# showed up.

Personally, I found that to be an abuse of the javadoc feature, but to each there own.

But pretty much all the other features you listed have been in the works a long time.

Most of the features aside from generics did not even start the process until late 2002. C# already was already in production, let alone be considered under development.

Java did have a leg up with generics in that they started back in '99 and there were research implementations preceeding that I think as far back as '97.

I believe the generics support in C# was under research at the time of the release of .NET 1.0, but that was easily years after any of the similar Java generics projects.

As it goes I think Java has one of the most amazing communities in the industry: JCP

It includes vendor heavyweights like IBM, Oracle, BEA, Sybase, Borland et al, specialist players such a Plumtree, and many major players in the Java open source world like Craig McClanahan(Strus and JSF), Linda DeMichiel and Craig Russell. Sun developed Java and continues to manage the process and have responsibility for its various implementations. Oh and it does pretty much rule enterprise computing at the moment. I can't remember the last time I walked into a company that wasn't running at least one major system on Java/J2EE.

Most of the posts regarding this licensing have been from the developers' perspective, but perhaps we should look at this from the users' perspective.

Something like 90% of the public recognizes the Java name (way more than recognize Sun). It's therefore extremely valuable. People recognize Java as meaning either "works on the Web", or more enlightened "app runs on all kinds of computers and maybe my cell phone".

If I make a vitual machine call FooCoffeeBar, I am going to be taking advantage of the years of powerful Java branding (i.e. "public recognition") to tell non-developers that this code runs in lots of places by calling it "Java Compatible". If I didn't care about end-users, I'd used a phrase like "I can't believe it's not J*v*", since developers are smart enough to figure it out. ;-)

Running the canonical test suite is the only way to make sure this brand doesn't get diluted. A naive user who buys a Java-enabled cell-phone (or a Mac desktop, whatever) that can't run Java apps properly will likely be put off all Java (including products from other vendors and brands using the "Java compatible" branding).

Remember, it was the Open Source Community that has been clamouring for Java to be opened up mostly because of redistribution issues. Does this licensing scheme, which protects the end-user base, not accomplish anything developers need (since you can redistribute under any license you want if it passed the test suite)?

With regards to Sun randomly changing the API or VM, creating havoc developers down the road, please see the Java Community Process.

So what would happen if an Open Source, non-Java(tm) fork were to make a desireable but incompatible improvement? Simply include it in the next revision of the official Java(tm) spec!

This is the entire point of the JSR process and it is how all changes to the Java spec-- including those that initiate within Sun itself-- make it into new versions of the spec. I'm not sure how easy it is to become a JCP member, but I'm sure Sun can be convinced there's room for the open source community on it if the open source community is willing to not just blow the JCP off.

Meanwhile I cannot fathom that Sun would not allow open source Java derivatives to implement incompatible extensions as long as those extensions do not activate without a -X flag (the -X flag is kind of java's equivalent of #pragma). One of the requirements for a JSR to be finalized is to create a reference implementation which implements the proposed extension. One of the biggest advantages of an open source sort of license for the JVM would be that it would make reference implementations for language extensions much easier; choosing a license which would prevent making experimental extensions entirely impossible would sabotage this, and be silly. I doubt Sun would do that.

So no, I don't think Sun wants "complete control over the spec" exactly, or they wouldn't have set up this standards body thing to, um, allow other people to partially control the spec. It would certainly be nice of Sun if all that happened upon violating the spec in an open source Java derivative was that your VM extension loses Java certification. However I don't think it would be the most unreasonable thing in the world if Sun demanded if you use their code (rather than, say, Kaffe's) your experimental functionality extensions don't activate unless specifically switched on by the user. It's all very well to say that such "experimental project" would "not gain widespread acceptance" but this is simply not the case-- after all, previously one such JVM with incompatible experimental extensions that were on by default shipped with a major operating system.

SMB to Java is hardly fair. SMB is a truly closed, proprietary standard; Samba reverse-engineered the standard from implementations, and every time the "official" implementations change Samba runs the risk of ceasing to correctly function.

Java is a proprietary but relatively open standard whose specification is open and available to everyone, and whose specification is guided by a number of third parties, but which no one may be certified as being an implementation of unless they are 100% complaint with the specifications.

I think it's reasonable Sun wants to ensure all Java implementations are cross-compatible, especially considering that the last time Java had a chance at making headway on the desktop, one of the biggest reasons it failed was the variety in incompatible AWT implementations.

Something I don't find reasonable about the current situation is that the nature of the certification process is such that it virtually ensures any Java implementation not backed by a large moneyed entity is not going to be able to make it to certification. Open source implementations of Java exist but it is unlikely anyone is going to be paying to get them through the certification process.. well, ever.

It seems to me like Sun is at least now taking a serious step toward improving this situation.

Sun's problem is that they know that people want to produce non-conformant implementations. They feel they have to stop them doing that. This goal is, by its very nature, incompatible with an open source license. No amount of clever wording is going to change that.

Perhaps this is exactly why Sun has been so reluctant to even approach open source licenses with Java up until now?

The web service descriptions will probably be sufficient to reimplement protocols by just running stub generators.

Why is the poster doing this as a JSR? They are requests for Java specifications. Things that go into the core of the Java platform.

The problem domain for this proposed JSR is primarily in the business world, not the technical one. I can't see any one proposal getting sufficient backing from a wide enough user group. Certainly not enough for everyone to agree on a useful technical implementation of this.

There are better ways to handle this...

I suggest that the poster goes and sets up his own web service to do this (banks and investment firms offer such services already). And work out an open API.

It's good you've found a problem that interests you. But please don't feel you need to go and clutter up my platform of choice to go solving it.

--
Java Hosting on Linux VPSs

• IBM (DB2 Content Manager - runs on Linux)
• Documentum (now EMC)
• FileNet
• OpenText

Java is being worked on to deliver stable guaranteed time to interrupt?

Exactly. It was the first JSR created as part of the Java Community Process. The final API can be viewed on the JCP website. The "reference implementation" being used for testing can be found here.

Keep in mind that the API is most likely to show up on hard real time systems and probably won't be available on your standard desktop OSes. (Windows? Hard realtime? *rolls eyes*)

class Complex {
float re,im;
Complex(float re,float im) {
this.re = re; this.im = im;
}
Complex plus(Complex other) {
return new Complex(this.re+other.re,this.im+other.im)
}
}

...
Complex data[] = new Complex[1000*1000];
for(int i=0;i<data.length;i++) data[i] = new Complex(rand(),rand());
Complex total = new Complex(0.0F,0.0F);
for(int i=0;i<data.length;i++)
total = total.plus(data[i]);

It's interesting that you suggest a VM that starts at boot time. One of the things in the somewhat near future of Java (currently being prototyped) is a sharable VM, which will run as a daemon. Each new java program will connect to the daemon and run within a single VM, rather than starting a new VM for each app. This would be done through the Isolation API (JSR 121 )

It will be interesting to see how this changes the usage patterns of Java. The claim at JavaOne this year is that jumping into an already running
VM reduces startup time by 96% for non-GUI apps, and 66% for GUI apps.

JSR 223: Scripting Pages in JavaTM Web Applications
The specification will describe mechanisms allowing scripting language programs to access information developed in the Java Platform and allowing scripting language pages to be used in Java Server-side Applications. JSR 223

For those interested in developing 3D games for embedded systems (not just cellphones). You may want to look at OpenGL ES by the Khronos Group.

As a preferred programming environment for embedded systems Java will provide access to 3D graphics through JSR184 a Mobile 3D graphics API for J2ME and more excitingly JSR239 direct Java bindings for OpenGL ES!

For those interested in developing 3D games for embedded systems (not just cellphones). You may want to look at OpenGL ES by the Khronos Group.

As a preferred programming environment for embedded systems Java will provide access to 3D graphics through JSR184 a Mobile 3D graphics API for J2ME and more excitingly JSR239 direct Java bindings for OpenGL ES!

It is called OpenGL ES (Embedded Systems) by the Khronos group. The article started of with quotes from some guy from the Khronos group.

There are several initiatives to bring 3D to the Jave platform as well. JSR184 is a Mobile Graphics API for J2ME. Even more exciting is the upcoming JSR239 which will provided Java with direct bindings to OpenGL ES!

It is called OpenGL ES (Embedded Systems) by the Khronos group. The article started of with quotes from some guy from the Khronos group.

There are several initiatives to bring 3D to the Jave platform as well. JSR184 is a Mobile Graphics API for J2ME. Even more exciting is the upcoming JSR239 which will provided Java with direct bindings to OpenGL ES!

You should check out JSR 184: Mobile 3D Graphics API for J2ME. This appears to be a "J2ME-ized" subset of Java3D. Nokia has a reference implementation. AFAIK the first commercial implmentation of JSR 184 is Swerve from Superscape.

*Sigh*, yes, it's true. At least Sun finally seems to be warming up to client-side Java with the partial startup optimizations coming in 1.5 and the recent JDIC project opening.

There is a much more agressive plan, though, that could lead to a Java shell to allow a much faster starting of client-side apps.

You are once again spouting the tired old line that Sun is the master of Java. Not at all true, Java's fate is controlled by a whole host of companies - including IBM. Take a look at the reality of Java platform evolution at the Java Community Process web site.

It's a standards body just like any other, just more open.

P.S. - Aside from that gripe being wrong, I agree with the other poster that you should look into Objective-C to address other issues. Look for "GnuSTEP" for cross-platform objective C GUI work. It's just nicer to use on a Mac as they have very good tools (though in fairness I have never looked at what GnuSTEP tools might be around, I just can't imagine them being quite as good as the tools Apple has sunk so much effort into!).

WHy compare with Java when there is Groovy, the JVM scripting language?

Here's a simple sample script:

#!/usr/bin/env groovy
println("Hello world")
for (a in this.args) {
println("Argument: " + a)
}

Note that you can run this from a command line, no compiling required.

Groovy is not just some random basement project either, it's actually a JSR and so will probably become a standard before too long.

If you want a C3 equivilent, I'm sure some well-meaning but mistaken soul will copy this project as they have tried to do with every other Java project. "C# - only a year behind Java since 2003!".

...but Groovy isn't.

Groovy is a Python/Ruby style scripting language that runs anywhere Java runs, and it works and plays well with existing Java libraries, including the JDK. There's even a JSR for it.

3-In fact, there is actually LESS chance of fragmentation when Java lies in the hands of the public, first because it means that no one will start up a competing "openjava", a venture that would almost certainly lead to incompatibilities, and second because, as the example of the death of xfree86 shows, too much central and absolute control over software by a small group will inevitably anger developers and users alike, leading them to search for an alternative.

Say, isn't "OpenJava" called .Net? Same difference to me, extremely similar platforms with huge amount of duplicated code (Ant and NAnt, JUnit and NUnit, etc.). What you said about the issues with forks is true until someone big enough does it, and we are seeing the result in front of our very eyes.

As for control by the public - Java is already controlled by the public at large through the JCP. I do think opening the source could get some people more fired up about some things though, as the JCP can be rather slow.

Java is managed by a standards organization. It's call the Java Community Process. Any individual can join for free and contribute to the Java standards. Companies can join for a reasonable cost. Everything that goes into Java is standardized by the JCP and every JCP standard is freely implementable.

Explain to me why we need ANSI or ISO?

A colleague of mine insists that .NET is better because it's an ECMA standard. He's too dense to understand that not all of .NET is part of the ECMA standard and it's not truly an open standard because although I can freely implement what the ECMA standard says, I can't do jack crap to change what's in the ECMA standard. The standard is controlled wholly by Microsoft.

Explain to me how this is better than the JCP?

The JCP is already slow enough. The last thing Java needs is some bloated organization like ANSI or ISO to get involved.

1. Java is not open-sourced and falls out of use like most closed standards eventually do.

Wha..? Java is not a closed standard. See the Java Community Process. Sun's implementation is closed. I disagree that "most" closed standards fall out of use. Many survive.

2. Java is released as open-source and they lose control of it.

Well, the Linux kernal is open-source and yet Linus maintains quite a lot of control over it. No doubt Sun's people would still have a lot of control because they're the most familiar with it, and it is/was their baby. This happens with a lot of open source projects.

3. Java is released under a pussyfoot-shared-source-with-lots-of-restrictions- but-we'll-call-it-open-source license which alienates the OSS crowd and causes open rebellion. Same outcome as #1, only quicker.

Unfortunately I think that we'll see something like this. Rebellion? Well, no, people are using it now under its closed paradigm. Many people will use it regardless of its closed or openess (or varying levels in between).

A few things that can be done to improve on java. Make the standard a standard housed with an officially recognized standards body which does not allow patented features to be accepted into standards.
So I guess you're unaware of the ECMA saga, when Sun made a good-faith attempt to do exactly this. And when they asked ECMA, "so what happens if someone breaks the rules, by say shipping a JDK with a non-conforming java.* class?", there was an embarrassed silence, and Sun decided that this would be incompatible with the lawsuit against MS.
Work out the consensus first, then figure out the standards structure.
Right now java is in sun's hands and nobody has a say in the standard but sun.
Hmmm.. you don't spend too much time reading the proceedings at jcp.org, do you?

Sun has had almost a decade to follow through on their initial promise of submitting Java to a recognized, existing standards body and they haven't done it. Instead, they have set up a process in which their customers and users do enormous amounts of work for them and Sun reaps the benefits and have the final say.

Most disturbingly, Sun still has complete ownership of JCPs (read the license agreement, say, for JCP 32).

Sun has had their chance. Java has been a positive influence on the industry, but it is time to move on to something else, both for legal reasons and for technical reasons.

JavaTM API for XML Parsing Specification ("Specifica-tion")
Version: 1.0
Status: FCS
Release: March 2, 2000
Copyright 1999-2000 Sun Microsystems, Inc.
901 San Antonio Road, Palo Alto, California 94303, U.S.A.
All rights reserved.

NOTICE
The Specification is protected by copyright and the information described therein may be protected by one or more U.S. patents, foreign
patents, or pending applications. Except as provided under the following license, no part of the Specification may be reproduced in any form
by any means without the prior written authorization of Sun Microsystems, Inc. ("Sun") and its licensors, if any. Any use of the Specification
and the information described therein will be governed by the terms and conditions of this license and the Export Control and General Terms
as set forth in Sun's website Legal Terms. By viewing, downloading or otherwise copying the Specification, you agree that you have read,
understood, and will comply with all of the terms and conditions set forth herein.
Sun hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under Sun's
intellectual property rights that are essential to practice the Specification, to internally practice the Specification solely for the purpose of
creating a clean room implementation of the Specification that: (i) includes a complete implementation of the current version of the
Specification, without subsetting or supersetting; (ii) implements all of the interfaces and functionality of the Specification, as defined by Sun,
without subsetting or supersetting; (iii) includes a complete implementation of any optional components (as defined by Sun in the
Specification) which you choose to implement, without subsetting or supersetting; (iv) implements all of the interfaces and functionality of
such optional components, without subsetting or supersetting; (v) does not add any additional packages, classes or interfaces to the "java.*" or
"javax.*" packages or subpackages (or other packages defined by Sun); (vi) satisfies all testing requirements available from Sun relating to the
most recently published version of the Specification six (6) months prior to any release of the clean room implementation or upgrade thereto;
(vii) does not derive from any Sun source code or binary code materials; and (viii) does not include any Sun source code or binary code
materials without an appropriate and separate license from Sun. The Specification contains the proprietary information of Sun and may only
be used in accordance with the license terms set forth herein. This license will terminate immediately without notice from Sun if you fail to
comply with any provision of this license. Upon termination or expiration of this license, you must cease use of or destroy the Specification.

Apart from the fact that the document is covered by copyrights, patents, and that you can do almost nothing with it, note that it is Sun, not the JCP members or some other organization, that owns all the rights.

It also tells you who has the final word over compliance: Sun.

And it spells out conditions that are almost impossi