Slashdot Mirror

Take a look at JSR 121 over at the JCP, which is slated for the upcoming Tiger release (Java 1.5).

It's actually interesting to see the development of the JVM, separately from the rest of the platform. Essentially it is parallelling the development of hardware-based computers, moving from being a unitask environment to finally being a multitasking environment under a managing OS.

I know this is just feeding the trolls, but I couldnt resist:

"Trying to run java applications over X at long distances makes me want to commit suicide."

There used to be a problem with running Java on a remote X server with JDK 1.2 and 1.3, but it is fixed now in 1.4.

"Then there is the damn JVM's that each app needs..."

The new Isolation API slated for 1.5 should hopefully sort out the JVM-per-app isssue (I agree it's crap).

"For some reason the screen flickers every time you run a java app"

Again, fixed in 1.4 AFAIK.

"Humm, and cut/paste sucks, yes you can use key combos, but sometimes in windows, its nice to select all, and copy."

No quite sure what you mean here. If you mean in "Windows" (not windows) then you can select all and copy (CTRL+A & CTRL+C) in any Java text widget).

"If you cant have command line, and you must have a GUI, for gods sake use a HTML."

What??? I assume you are talking about web-based applications here? I agree, that for web applications, HTML is *usually* the way to go. However, there are some very nice standalone Java applications out there. For example (and this is not a plug, just an example), one of the best GUI CVS clients I have found is a Java application (SmartCVS).

Just my 0.02c. I've been developing Java applications for the last 7 years (since 1.1), so I think I'm entitled to an opinion....

James Bray

I think java resource sharing is slated for 1.5 (aka Tiger) as part of a system named the Isolation API.

The idea being that multiple applications can be executed in a single VM whilst being "isolated" from each other.

For more details, check out the relevant JCP page.

James Bray

Absolutely no information? What do you call this then? http://www.jcp.org/en/jsr/detail?id=166

Collection c; ... for (String s : c)

What if I have a data structure that is logically iterable yet not a Collection nor an array? How would I use for in say, a Vector or Matrix class of my own design? What if I wanted that for loop to iterate over the elements of a Matrix in some nonstandard denumerable manner?

It would seem more logical to me for Java to simply apply allow blocks as used in Smalltalk.

URL : Enhanced for discussion on JCP site

URL : About Smalltalk Blocks

Thanks a lot Sun for posting absolutely no information about the progress of this JSR. At least Doug Lea has posted a little information.

FUD. The specification was released only one year ago.

FUD. See JDOCentral.com and TheServerSide for real-world discussions.

Now my plans for taking over the world using hordes of CLDC/MIDP MIDlets, all communicating via Bluetooth, can be realised! Soon, your phone will become your worst enemy...

But seriously, I've heard this release includes an implementation of JSR-82, the standard Java API for Bluetooth. This will be very cool, you'll be able to write java apps for the P800 which can do Bluetooth!

w00t!

/mike

The two main standards currently under development are OpenGL ES by the Khronos group and the JSR-184 headed by Nokia. If you read through the list of participating companies, you'll notice a good bit of overlap; we can expect the two APIs to play quite nicely together.

Mobile 3D hardware will also be coming probably sooner than what most people think. Some Ericsson researchers will be giving a SIGGRAPH talk on the subject ("Graphics for the Masses: A Hardware Rasterization Architecture for Mobile Phones") even if nothing more than the title is known at this time.

While all mobile devices will have to make their own compromises on functionality, battery life, weight and cost, almost all of them are capable of running 3D graphics when the software is carefully constructed. Many modern software rendering techniques are based on dynamically generated/compiled code, and the processes are very similar to what happens inside 3D hardware. As these libraries will also be fairly small, they will not add cost or weight to the devices themselves. 3D chips will be reserved to those more keen on playing games on the road.

The technology is definitely coming, now all we need to do is invent the killer application. Ideas anyone?

Jouni

By "impedance mismatch" I mean efficiently calling C functions and passing parameters / return values,and sharing data structures like arrays and structs.

JSR 166 and JSR 133 address some of the thread issues.

Larry

By "impedance mismatch" I mean efficiently calling C functions and passing parameters / return values,and sharing data structures like arrays and structs.

JSR 166 and JSR 133 address some of the thread issues.

Larry

Actually, Sun works with a wide range of developers and companies
to improve Java using the Java Community Process

The JCP has hundreds of members listed here

I personally believe the JCP does an admirable job.
Does it have room for improvement? Of course.
Is it working? For me the answer is yes--
Java gets steadily faster and more useful.

What do you think is a better model
for extending and improving a language?

Cheers, Joel

From the JCP homepage:
the Java Community Process is the way the Java platform evolves.
It's an open organization of international Java developers and licensees
whose charter is to develop and revise Java technology specifications,
reference implementations, and technology compatibility kits.

Actually, Sun works with a wide range of developers and companies
to improve Java using the Java Community Process

The JCP has hundreds of members listed here

I personally believe the JCP does an admirable job.
Does it have room for improvement? Of course.
Is it working? For me the answer is yes--
Java gets steadily faster and more useful.

What do you think is a better model
for extending and improving a language?

Cheers, Joel

From the JCP homepage:
the Java Community Process is the way the Java platform evolves.
It's an open organization of international Java developers and licensees
whose charter is to develop and revise Java technology specifications,
reference implementations, and technology compatibility kits.

I do, however, understand people's concerns about java being overbloated and big. It's ridiculous to have a 10MB jvm started anytime you want a small application to run. JDK 1.5 has included in it JSR-121, called Application Isolation. This will essentially bind multiple JVM processes onto one main parent process, which will give a much faster startup time. This will also serve as an excellent conduit to smaller java applications going mainstream (i.e., small utility programs, not large applications).

Hey, have a look over at JCP.org.

There's 922 JSR's there, all public standards underway that anyone (that includes YOU and ME) can comment on. Where can I go to comment on the C# standards underway?

So, which is the more open standard?

What a maroon. (Yes, I did spell that right).

After having read the article twice I realize that the author actually does not talk about Web-Services.

Instead, he's talking about Windows CE - client-programming, perhaps with some communication with the rest of the universe...

It was strange because C++ doesn't have too much to do with Web Service. I have to say that the article was a complete waste of time as I didn't learn anything!!

Apart from that I have to say that Web-Services in C++ could be great fun, but as so often there is a lacking of standards. Java adresses this issue very effectively via Java Community Process, thus providing standards for the greatest technologies very fast... (While C++ doesn't even provide standardized UI,XML or DB programming - but actually some very good opensource APIs)

Please don't get me wrong - Actually I used to love C++, but recently I always had the feeling being on the wrong lane. This comes from the many decisions and concepts you have to live with:

• UI: QT / more or less native (Win32, Cocoa, Motif) / GTK (gtkmm??)
• XML: xerces
• DB: ODBC (and I hate this plain C-API, it's kinda "do it yourself")
• General Library: STL?? (doesn't work very well together with all the other stuff)
• other things: sockets, corba, http (and some other high-level protocols, I'm not yet talking of SOAP

Finally you realize that it's not C++ missing the elegance, it's the different approaches and many standard-C APIs that make your life to hell... With some accepted "organ" to propose standards C++ would be unbeatable...

That's not exactly what Enhanced 911 is all about. Dialing 911 from your cell phone has always patched you to the correct 911 center (unless the cell tower happens to be close to a border). The major goal of E911 is the tell the emergency operaror where you are located. You can read more about E911 on the FCC website.

There are many cell phones currently on the market which have what is called Assisted GPS. As another posted mentioned, Assisted GPS cell phones merely take measurments of the signal strength coming from various GPS satellites. These measurements are forwarded to the cell tower which calculates the mobile phones location. This is mainly implemented to support E911 in the cheapest way possible. However, I have seen numerous postings on the SprintPCS developer website forums that there are plans to put together a Java library which will permit application developers to write J2ME apps which can query the lat/long of the phone. Those postings are from Sprint employees, but they currently seem to be suggesting that we will see this as part of the Location API included with the Java MIDP 2.0 to be released 4th Quarter 2003.

If I did not state it clearly above, once the cell tower calculates your position, it currently has no reason to pass that info back to your phone. The Location API will work by asking the cell tower for your location, not by reading some registers in your phone. Without the Location API (and the supporting software on the towers), there would be no way for you to write a mapping application that ran on your phone, regardless of how much memory you have. For obvious reasons, such a library would have to query the phone user before permitting the application to obtain location information. I also imagine that Sprint would have to come up with a scheme to prevent folks from reverse engineering the Sprint library and then implementing their own libraries which would not bother asking for permission. That is probably at least part of the reason why it is taking so long to get support for polling your phones location.

XPP which has evolved into Common API for XML Pull Parsing . I don't believe there is a standard pull-based API for XML parsing in the Java world yet although there is JSR 173.

Actually, there is a Java Specification Request to add generics to Java, which is essentially adding template capability. The proposal is JSR014.

With a Java Developer Connection account, you can try a prototype compiler with this capability. It claims to generate code that can run on a standard 1.3 JVM.

well, because they really want to perhaps? you're not the only java developer and taste differs.
See this:
http://jcp.org/en/jsr/detail?id=014

One of the major strengths of templates is to avoid exactly the situation that Java everything-from-Object inheritance causes in collections.

In other words, this code:

MyObject m = (MyObject)iterator.next();

In fact, it's so useful, it's appearing in Java in JDK1.5, courtesy of JSR 14.

But far beyond convenience when typing, the important point is that using templates or generics in collections turns the typesafety of collections into a compile-time check rather than a runtime exception. Which is a Good Thing.

That's just plain wrong. Enter Java Community Processand check for yourself the list of participants. Like IBM, BEA, Apache, Apple, etc. That is if you like to know what you are talking before posting.

From the home page: "Java Community Process is the way the Java platform evolves. Its an open organization of international Java developers and licensees whose charter is to develop and revise Java technology specifications, reference implementations, and technology compatibility kits. Both Java technology and the JCP were originally created by Sun Microsystems, however, the JCP has evolved from the informal process that Sun used beginning in 1995, to a formalized process overseen by representatives from many organizations across the Java community."

JSR 121 -- The Isolation API

JSR 121 -- The Isolation API

Microsoft's CEOs have made it "patently" clear that they intend to restrict competing .Net implementations by cultivating Microsoft's patents, such as United States Patent Application #20020059425 "Distributed computing services platform" which covers the design and inter-operation of .NET based implementations.
Although there is prior art examples of individual technologies such as the JVM etc, Microsoft patents such as the one mentioned, define and claim the interoperation of the components, in such a way that any re-implementations will be sure to be covered by the patents. This remains true even for the Microsoft specs submited to standard

In comparison, Sun has granted the Apache and all open source developers FULL access to the specs, test kits and granted the full rights to develop competing products under the JSPA . Sun has also fully pened up the Java development standards process under the new Java Community Process (JCP) . Even to the point of granting full open source re-implentations of J2EE such as JBoss ...

JBoss received the green light last week, after Sun told ComputerWire that it would allow all of the APIs contained in J2EE 1.4 to be open sourced. Fleury had expressed concern that certain critical APIs, including Enterprise Java Beans (EJB) 2.1, would be not be made available to open source organizations.

However, Java Community Process director Onno Kluyt said: "Sun's plan with 1.4 is that although it started before JCP 2.5, by the time it ships it will allow the creation of independent implementations. I don't think the APIs are that interesting, because the license that sits on top of J2EE will allow that [independent implementations]".

There those that claim that .NET is open to re-implementation, but until Microsoft make a simliar public legal declaration to Sun's JSPA, any .NET reimplementation represents a pending legal mindfield.

it's in the works: http://www.jcp.org/en/jsr/detail?id=175

also, i don't think java is really "copying" C# features. you could say the same thing about most of C#'s features. in reality, both environments borrow heavily from years of computer science precedent.

There are some other interesting changes coming to provide a more coherent memory model, vastly improved concurrency support, and intra-JVM application isolation. Java is getting much better at providing access to the capabilities of the underlying OS, and the JVM working more like a little multi-process OS itself...

Larry

There are some other interesting changes coming to provide a more coherent memory model, vastly improved concurrency support, and intra-JVM application isolation. Java is getting much better at providing access to the capabilities of the underlying OS, and the JVM working more like a little multi-process OS itself...

Larry

There are some other interesting changes coming to provide a more coherent memory model, vastly improved concurrency support, and intra-JVM application isolation. Java is getting much better at providing access to the capabilities of the underlying OS, and the JVM working more like a little multi-process OS itself...

Larry

Possibly the "most different" feature that will probably come in. Here.

I'm not too sure I like them, as they do add a completely new and different and more cryptic syntax to Java, but I can definitely see the use for them. No more clumsy casting when you retrieve something from a List.

Daniel

Funny, I thought the Java Community Process and the Bug Parade were step 2! As a result of feedback, Java has added nested classes, strictfp, generics, enums, foreach, reference objects, tons of library classes, as well as fixed thousands of bugs.

What you don't see is that MS basically started off with a clean slate: what's good about Java; take that; what's bad abot Java; fix that.

Sun has been holding onto the Java reigns for so long, including under the charade of open-ness they call the Java Community Process, that they simply can't fix what's broken now. Check out JSR 201. Late in December 2002, they decide it's time to start playing catch up with C## in terms of language features. It'll take a year for this to be finalized, and then another year for it to be released. And it's happening so slowly that you basically can't use any new features until you're sure that everyone along the way has them, which is way too late in the game.

Java is Dead!

The only way Java can recover is to declare the current language frozen, and start a new one based on the old one. Basically, all the good stuff from C##; take it; all the bad stuff from C##; fix it; beat MS at their own game. I don't believe Sun has the balls to do this, but they also don't have the balls to let anyone else do this either (they would sue anyone who tried).

The ruling about MS putting Java into Windows is actually just going to kill Java off a little quicker than it would otherwise. Java will get a little more attention for a while, which will make people realize how much it blows when compared to C##. Bring 'em on!! I'm ready to dump Java and move to a more useful language ...

With apologies to Miguel "Everything else that was easy didn't get standardized, but the important parts did." de Icaza, Microsoft has already demonstrated that they will add and extend API's in the .NET platform that are not part of the public specification. As with Wine the Mono project will _always_ be playing catch up to MSFT. This gives MSFT first mover advantage and should invalidate the claim of .NET's cross platform capabilities.

In contrast the Java Community Process (jcp.org) publicly discloses the API specifications for Java Standard Edition, Java 2 Enterprise Edition and Java Micro Edition. Anyone can join the JCP. Any vendor who ships a product branded with any of these names has access to these open specifications. Any developer who programs to these specifications can deploy to any of these vendors. Thus Java is not only multiplatform it is also multi-vendor and open in a way that the .NET platform will never be.

With apologies to Miguel "Everything else that was easy didn't get standardized, but the important parts did." de Icaza, Microsoft has already demonstrated that they will add and extend API's in the .NET platform that are not part of the public specification. As with Wine the Mono project will _always_ be playing catch up to MSFT. This gives MSFT first mover advantage and should invalidate the claim of .NET's cross platform capabilities.

In contrast the Java Community Process (jcp.org) publicly discloses the API specifications for Java Standard Edition, Java 2 Enterprise Edition and Java Micro Edition. Anyone can join the JCP. Any vendor who ships a product branded with any of these names has access to these open specifications. Any developer who programs to these specifications can deploy to any of these vendors. Thus Java is not only multiplatform it is also multi-vendor and open in a way that the .NET platform will never be.

See JSR-121 http://jcp.org/en/jsr/detail?id=121. (Note this JSR is in public review -- please provide feedback.)

Operating systems that virtualize hardware and allow different binaries to run will always exist. However, that doesn't preclude programming langugages from providing some of the same OS-like features to their programs.

Isolation is a powerful concept, and one that hasn't really been taken advantage of in the past. (Pilot/Mesa and Oberon, and a few others have done it, but no one seems to have noticed). Putting it in Java will make a few more waves...

You have raised some interesting points regarding the legal issues surrounding the case, some of which I was not aware of. I thought this case was a direct extension of the contractual violations made by Microsoft in their Java implementation. Thanks for the correction.

However:

Java is dead regardless of the outcome of the case. Sun is merely showing that Java is a completely closed language that only Sun is allowed to change. Sun is only getting a free ride on this in the Linux-media like slashdot.

This I do know enough about to disagree with. Java is far, far from being dead, nor is it in fact a closed language. Java is hugely popular in server-side applications, and that popularity has not significantly abated with the introduction of .NET. Further, the mechanism used to introduce new features into the language, Java Community Process, is largely outside of the control of Sun and is driven instead by a large and active user base. Read both the FAQ and the Procedural Overview for more info.

You have raised some interesting points regarding the legal issues surrounding the case, some of which I was not aware of. I thought this case was a direct extension of the contractual violations made by Microsoft in their Java implementation. Thanks for the correction.

However:

Java is dead regardless of the outcome of the case. Sun is merely showing that Java is a completely closed language that only Sun is allowed to change. Sun is only getting a free ride on this in the Linux-media like slashdot.

This I do know enough about to disagree with. Java is far, far from being dead, nor is it in fact a closed language. Java is hugely popular in server-side applications, and that popularity has not significantly abated with the introduction of .NET. Further, the mechanism used to introduce new features into the language, Java Community Process, is largely outside of the control of Sun and is driven instead by a large and active user base. Read both the FAQ and the Procedural Overview for more info.

You have raised some interesting points regarding the legal issues surrounding the case, some of which I was not aware of. I thought this case was a direct extension of the contractual violations made by Microsoft in their Java implementation. Thanks for the correction.

However:

Java is dead regardless of the outcome of the case. Sun is merely showing that Java is a completely closed language that only Sun is allowed to change. Sun is only getting a free ride on this in the Linux-media like slashdot.

This I do know enough about to disagree with. Java is far, far from being dead, nor is it in fact a closed language. Java is hugely popular in server-side applications, and that popularity has not significantly abated with the introduction of .NET. Further, the mechanism used to introduce new features into the language, Java Community Process, is largely outside of the control of Sun and is driven instead by a large and active user base. Read both the FAQ and the Procedural Overview for more info.

Standards processes involve an independent body that controls and supervises the standardization process. Standards bodies have well-defined and proven rules that many people established and agreed on before any individual standard is being considered.

And the JCP does not fit in what way...?

There is an independant (from Sun, which is only one member among many) panel that controls what goes in Java and what does not, with members from many companies. On a smaller level, anyone is free to comment on public drafts or even propose additions as an individual, a practice I find very nice. How many other "standards bodies" would let an individual have any say at all?


The standardization process often involves a whole host of legal agreements and guarantees that don't exist with the JCP. For example, many standards bodies, not only is the submitter bound to disclosure of related patents and RAND licensing terms of their patents, but so are the other members of the standards body.


Would such an agreement read something like:

4. Intellectual property: In-Bound
A. Contributions to the Spec Lead. You hereby grant to each Spec Lead (and, if different, Maintenience Lead) for each Expert Group for which You are not the Spec Lead, with respect to teh Output of the JSR led by the Spec Lead, a perpetual, non-exclusive, worldwide, roayalty-free, fully paid-up and, subject to section 4.D irrevocable, licence, with the right to sublicence...


Each company and individual praticipating in the JCP has to sign something like that, and all of the other text located here

I'm not sure why you would want any sort of RAND style licensing in your standards body at all.


Another problem with the JCP is that it isn't producing a standard for Java, it's producing a large set of pieces that define specific bits of functionality. Think of it this way: do you know what APIs were part of the Java platform in March 2000? What about today?

Yes, you mostly see individual pieces being worked over as it's a more rigorous process to add a core API or feature. But that still does happen (like with generics) through the JCP.

Telling you what the API looked like in March 2000 is really quite meaningless - instead at any point you can easily see what API's are in what version of the JVM, which is much more important to know (as I'm using 1.3.1 at work now, even though 1.4 has been out for some time). You can find a list of various API's here, which tell you EXACTLY what you can expect to exist from any 1.3.1 J2SE implementation, and optional API's that you can make use of as well if you need to. You can find the bytecode spec if you like as well, and build the whole thing from scratch which to me is the CORE definition of having a real standard.

To me, a standards body really does two things: (1) Keep any one organization from controlling the standard (which implies that it keeps the technologies used patent free), and (2) make sure that ANYONE can build an implementation of the standard which would work with other implementations, using only the documentation produced by the standards body. The JCP meets both those requirements and has other nice features as well like individual participation, which means to me you are going to see more varied discourse on a standard and not a puppet body echoing the will of one member.

If the JCP were not a real body, things would be different in the Java world as Sun does not always get its own way. Generics would have been in 1.4 if it were up to Sun alone.

Anyone who wants to know more about the process of the JCP shoudl read over the process overview here, or the full detail here.

Standards processes involve an independent body that controls and supervises the standardization process. Standards bodies have well-defined and proven rules that many people established and agreed on before any individual standard is being considered.

And the JCP does not fit in what way...?

There is an independant (from Sun, which is only one member among many) panel that controls what goes in Java and what does not, with members from many companies. On a smaller level, anyone is free to comment on public drafts or even propose additions as an individual, a practice I find very nice. How many other "standards bodies" would let an individual have any say at all?


The standardization process often involves a whole host of legal agreements and guarantees that don't exist with the JCP. For example, many standards bodies, not only is the submitter bound to disclosure of related patents and RAND licensing terms of their patents, but so are the other members of the standards body.


Would such an agreement read something like:

4. Intellectual property: In-Bound
A. Contributions to the Spec Lead. You hereby grant to each Spec Lead (and, if different, Maintenience Lead) for each Expert Group for which You are not the Spec Lead, with respect to teh Output of the JSR led by the Spec Lead, a perpetual, non-exclusive, worldwide, roayalty-free, fully paid-up and, subject to section 4.D irrevocable, licence, with the right to sublicence...


Each company and individual praticipating in the JCP has to sign something like that, and all of the other text located here

I'm not sure why you would want any sort of RAND style licensing in your standards body at all.


Another problem with the JCP is that it isn't producing a standard for Java, it's producing a large set of pieces that define specific bits of functionality. Think of it this way: do you know what APIs were part of the Java platform in March 2000? What about today?

Yes, you mostly see individual pieces being worked over as it's a more rigorous process to add a core API or feature. But that still does happen (like with generics) through the JCP.

Telling you what the API looked like in March 2000 is really quite meaningless - instead at any point you can easily see what API's are in what version of the JVM, which is much more important to know (as I'm using 1.3.1 at work now, even though 1.4 has been out for some time). You can find a list of various API's here, which tell you EXACTLY what you can expect to exist from any 1.3.1 J2SE implementation, and optional API's that you can make use of as well if you need to. You can find the bytecode spec if you like as well, and build the whole thing from scratch which to me is the CORE definition of having a real standard.

To me, a standards body really does two things: (1) Keep any one organization from controlling the standard (which implies that it keeps the technologies used patent free), and (2) make sure that ANYONE can build an implementation of the standard which would work with other implementations, using only the documentation produced by the standards body. The JCP meets both those requirements and has other nice features as well like individual participation, which means to me you are going to see more varied discourse on a standard and not a puppet body echoing the will of one member.

If the JCP were not a real body, things would be different in the Java world as Sun does not always get its own way. Generics would have been in 1.4 if it were up to Sun alone.

Anyone who wants to know more about the process of the JCP shoudl read over the process overview here, or the full detail here.

Standards processes involve an independent body that controls and supervises the standardization process. Standards bodies have well-defined and proven rules that many people established and agreed on before any individual standard is being considered.

And the JCP does not fit in what way...?

There is an independant (from Sun, which is only one member among many) panel that controls what goes in Java and what does not, with members from many companies. On a smaller level, anyone is free to comment on public drafts or even propose additions as an individual, a practice I find very nice. How many other "standards bodies" would let an individual have any say at all?


The standardization process often involves a whole host of legal agreements and guarantees that don't exist with the JCP. For example, many standards bodies, not only is the submitter bound to disclosure of related patents and RAND licensing terms of their patents, but so are the other members of the standards body.


Would such an agreement read something like:

4. Intellectual property: In-Bound
A. Contributions to the Spec Lead. You hereby grant to each Spec Lead (and, if different, Maintenience Lead) for each Expert Group for which You are not the Spec Lead, with respect to teh Output of the JSR led by the Spec Lead, a perpetual, non-exclusive, worldwide, roayalty-free, fully paid-up and, subject to section 4.D irrevocable, licence, with the right to sublicence...


Each company and individual praticipating in the JCP has to sign something like that, and all of the other text located here

I'm not sure why you would want any sort of RAND style licensing in your standards body at all.


Another problem with the JCP is that it isn't producing a standard for Java, it's producing a large set of pieces that define specific bits of functionality. Think of it this way: do you know what APIs were part of the Java platform in March 2000? What about today?

Yes, you mostly see individual pieces being worked over as it's a more rigorous process to add a core API or feature. But that still does happen (like with generics) through the JCP.

Telling you what the API looked like in March 2000 is really quite meaningless - instead at any point you can easily see what API's are in what version of the JVM, which is much more important to know (as I'm using 1.3.1 at work now, even though 1.4 has been out for some time). You can find a list of various API's here, which tell you EXACTLY what you can expect to exist from any 1.3.1 J2SE implementation, and optional API's that you can make use of as well if you need to. You can find the bytecode spec if you like as well, and build the whole thing from scratch which to me is the CORE definition of having a real standard.

To me, a standards body really does two things: (1) Keep any one organization from controlling the standard (which implies that it keeps the technologies used patent free), and (2) make sure that ANYONE can build an implementation of the standard which would work with other implementations, using only the documentation produced by the standards body. The JCP meets both those requirements and has other nice features as well like individual participation, which means to me you are going to see more varied discourse on a standard and not a puppet body echoing the will of one member.

If the JCP were not a real body, things would be different in the Java world as Sun does not always get its own way. Generics would have been in 1.4 if it were up to Sun alone.

Anyone who wants to know more about the process of the JCP shoudl read over the process overview here, or the full detail here.

In comparison, Sun has granted the Apache and all open source developers FULL access to the specs, test kits and granted the full rights to develop competing products under the JSPA . Sun has also fully pened up the Java development standards process under the new Java Community Process (JCP). Even to the point of granting full open source re-implentations of J2EE such as JBoss...

JBoss received the green light last week, after Sun told ComputerWire that it would allow all of the APIs contained in J2EE 1.4 to be open sourced. Fleury had expressed concern that certain critical APIs, including Enterprise Java Beans (EJB) 2.1, would be not be made available to open source organizations.

However, Java Community Process director Onno Kluyt said: "Sun's plan with 1.4 is that although it started before JCP 2.5, by the time it ships it will allow the creation of independent implementations. I don't think the APIs are that interesting, because the license that sits on top of J2EE will allow that [independent implementations]".

There those that claim that .NET is open to re-implementation, but until Microsoft make a simliar public legal declaration to Sun's JSPA, any .NET reimplementation represents a pending legal mindfield.

For the impatient:

The preliminary spec for generic types in Java is here.
The Sun prototype compiler can be downloaded here.
And a forum for discussion of Java generics is also available.

You might also want to check out CodeGuide. This is AFAIK the only IDE which already supports Java generics as described in the spec (and is an awesome IDE for traditional Java as well).

Enjoy!

-- kryps

interface Iterable<T> {
Iterator<T> iterator();
}
interface List<T> implements Iterable<T> {...}
interface Set<T> implements Iterable<T> {...}
class Test {
void <T,S implements Iterable<T>> printList(S s) {
Iterator<T> it = s.iterator();
while (it.hasNext())
System.out.println(it.next());
}
}

Check JSR-201 "Extending the JavaTM Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import"

You are reaching if you think that combining Sun's statement on the JCP together with some minor revisions of Java2 mean that Sun makes available all their patents for free Java implementations.

Your ignoring the last paragraph quoted from Effort on the edge, Part 1

Gingell notes that, "When J2SE is available under the terms of JCP 2.5, if someone wanted to implement it from specifications, they could do so without also licensing the reference implementation. They would have to license the TCKs to verify that they'd made a compatible implementation. They would thus have to be a TCK licensee, which would be available for free to qualified nonprofits."

g4dget wrote:"Sun has made no legally binding commitments on keeping Java open.".
At least Sun's Robert A. Gingell Sun Fellow & Vice President has published a Letter of Intent which includes the declration

Again in the interests of meeting the spirit of the requirements, Sun will modify the specification licenses of all the JSRs currently in progress to reflect Apache's requirements as met in the new draft JSPA. And we reaffirm a previous statement that we would work over time to change the licenses of previously completed JSRs to comply with the new JSPA draft. We specifically commit to doing such changes at a minimum for:

JSR 31 (JAXB), JSRs 52, 53, 152, 154 (JSPs/Servlets), JSR 63 (JAXP), JSR 67 (JAXM), JSR 93 (JAXR), JSR 101 (JAXRPC), JSR 127 (Java Server Faces), JSR 172 (J2ME Web Services)

As noted in the introductory summary, we believe these changes constitute a full meeting of Apache's requirements both in letter and in spirit.

It's a start, and it's value should not be dismissed lightly. Once again, Where are the equivalent public declarations from Microsoft?

Why will not Sun pull out of this accord? - Because, increasingly, it is not in Sun's self interest to do so.

Sun has adopted the LGPL/GPL licensed GNOME Desktop for both it's Solaris and Linux systems. In fact so much more open sourced software is being deployed on their systems, adding value to the platforms, that it is not in Sun's interest to limit free lisenced code interoperation with the Java frameworks.
For similar reasons IBM and other Java licensese are pressuring Sun to further open up the Java enviroment.

In it's comments of the voting for the new JCP IBM even commented:

IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.

Forces are moving into place which is going to make it very difficult for Sun to backslide to a close model again.

As for FUD, it seem to me that over time, Microsoft is becoming the sole dominant player in lies based on untruths.

By the way g4dget, are you any relation to John Carroll?

Q: Whats a JSR?
A: A JSR is a Java Specification Request. This is the document submitted to the PMO by one or more members to propose the development of a new specification or significant revision to an existing specification. There are currently more than 90 Java technology specifications in development in the JCP program, including the next versions of Java(TM) 2, Micro Edition (J2ME(TM)), Java(TM) 2 Platform Enterprise Edition (J2EE(TM)), and Java(TM) 2 Standard Edition (J2SE(TM)).

From Effort on the edge, Part 1

But how can you, as a JSR lead, grant that right, where those patents are owned by the companies that make up your expert group? The JCP 2.5 JSPA addresses both in-bound and out-bound intellectual property. In-bound intellectual property is the set of patents, licenses, or other rights that you and your expert group members bring to the table. Out-bound intellectual property signifies the rights of your specification's users, reference implementation, and compatibility test kit.

In essence, when your experts join your expert group, they grant the spec lead the right to sublicense the existing intellectual property they bring to developing the JSR. That not only includes patents, but copyrights, trademarks, and trade secrets as well. You and your experts can, in turn, choose whatever license form you desire for your output. If you choose the new Open Source License, you steer your technology's users clear of possible infringement on patents, trademarks, or other intellectual property they might not initially be aware of.

Sun is playing by those new rules. "Prior to the use of JCP 2.0, [Sun's Java licensees] were the only ones to gain access to the technologies needed to implement the things that comprise the Java technology from Sun," explains Gingell. "And licensees typically got all of the specifications, implementations, and conformance tests along with service and support programs as a bundle.

"One way to look at JCP and its evolution is that it's a process of unbundling all of these things. As of JCP 2.5...the specifications, reference implementations, conformance tests are all separately available," adds Gingle. "J2SE is not today available under the terms of JCP 2.5. Sun did commit to making available some of the JSRs it has led under 2.5 terms prior to the adoption of 2.5 by the JCP, and we have committed that all prior JSRs would be available under those terms but on an indefinite schedule. The expectation is that those changes will occur as maintenance on the technology occurs, roughly over the course of a year or so we'd expect."

To facilitate open source J2SE implementations, in August 2002, Sun announced a scholarship program for qualified nonprofit organizations that require access to Sun's compatibility tests to verify their adherence to JSR standards. Nonprofit groups that qualify can obtain Sun's compatibility test kits free of charge.

Gingell notes that, "When J2SE is available under the terms of JCP 2.5, if someone wanted to implement it from specifications, they could do so without also licensing the reference implementation. They would have to license the TCKs to verify that they'd made a compatible implementation. They would thus have to be a TCK licensee, which would be available for free to qualified nonprofits."

At least Sun is making concrete steps towards being more open.
Where are the equivalent public declarations from Microsoft?

In comparison, Sun has granted the Apache and all open source developers FULL access to the specs, test kits and granted the full rights to develop competing products under the JSPA. Sun mhas also fully opened up the Java development standards process under the new Java Community Process (JCP).

There those that claim that .NET is open to re-implementation, but until Microsoft make a simliar public legal declaration to Sun's JSPA, any .NET reimplementation represents a pending legal mindfield.

Not sure I understood your post. But just so you know, this is under serious consideration - take a look at JSR 121. Also note that the #2 request for enhancement (4466510) on the java developer connection is related to memory usage.

You're wrong about this. Anyone is free to join Java Community Process