Slashdot Mirror

You're wrong about this. For all of its flaws, the Java Community Process allows anyone from a large corporation to a single unaffiliated individual to help chart the course of Java evolution. This is a far cry from MS's focus-group oriented evolution of the VB platform.

Why can't I 'Object i = 5;'? There should be a 'void*' type.

You don't want a "void*" type; you just want int and the other primitives to be fully privileged objects (subtly different). This is probably the most common criticism of Java, and it's reasonable. There are also reasonable arguments for having primitives apart from objects, however. They didn't do this without some thought. Still, I lean toward your opinion on this one.

Why can't I 'Method m = Object.toString;'?

Reasonable -- it's a little shorter than Method m = Object.class.getMethod("toString", new Class[0]). But it's not a big issue -- in most cases where you'd use that, an interface paired with an anonymous inner class is more appropriate (and typesafe).

Why can't I [stuff] and get the right method called!?

Because that's a pretty wacky idea. Think for a moment about the implications of what you're proposing here -- x ? y : z is an expression...what is its type?

You could make this work, but would it be worth the hideous mess it would make of the spec to save you from having to type the words if and else?

Why can't I 'import java.util.*String*;' or 'import java.*.*;' ?

Because it poses tremendous potential namespace conflict problems with little clear benefit.

Why do we have 'new' instead of alloc and init?

Separating instantiation from initialization is reasonable; static factory methods do this just fine, but require foreknowledge of the problem. Such a facility, however, would still need to provide the guarantee that you can't actually obtain a reference to an object until it's fully initialized, which is where a naive implementation looking like like MyClass.class.alloc().init() would fail.

Why aren't static methods inherited?

Because that's an absolutely hideous idea. Static methods aren't part of the signature matching that underlies the type system, and don't participate in polymorphism; they are semantically equivalent to methods on the class, not the object (which is how Smalltalk does it).

I'd add to your list the lack of generics (which they're working on) and some of the unpleasant aspects of the memory model on multiprocessor machines.

And I guess if you're on the 'other side of the fence', you want to check out the WebDAV protocol.

For god's sake, DON'T go try and invent your own! We'll all end up with another KDE/Gnome/.

Multi-process JVMs are coming. Its called "Application Isolatation".

JSR-121: http://www.jcp.org/jsr/detail/121.jsp

The Expert Group is hoping to release its draft API to community review in a month or so. The draft API on the above web page is 1 year out of date, but is useful to get a handle on the scope of what's being done (if not how the API will accomplish it).

If you can't wait, check out the JanosVM:

http://www.cs.utah.edu/flux/janos/janosvm.html

Take your pick:

• jsr-121
• KaffeOS
• JX
• Alta
• JanosVM
• MVM

Generics will will be included in Tiger (1.5)

They don't break either source or binary compatibility (at least not the way Sun is going to do them).

You can even download the beta compiler and give it a whirl if you're eager. Java Generics

Jon

Many of these types of games and more where being demonstrated on JavaONE this year on J2ME devices so I would get too hung up on BREW. In fact I wouldn't even bother with that technology.

BREW is currently a CDMA only technology. The majority of the world uses GSM thought. (Americans sometimes forget this since CDMA has a larger, but weakening, footprint in the US.) The majority of carriers and handset manufacturers are committed to J2ME in someway. Motorola has gone so far as to pledge that all of its phones will ship with J2ME by the end of this year. Even CDMA carrier Sprint PCS have decided to forego BREW for J2ME when they launch thier new service this August.

If your a developers, where would you put your efort first?

J2ME has its limtiations though. Then again so do these devices -- With a screen not much larger then an airmail stamp we're not even talking game boy here. The limitations of J2ME are currently being addressed with initatives such as Project Monty (a new high performance virtual machine), Mobile Game API and the Mobile Media API.

<tim/>
---
http://tima.mplode.com/

Many of these types of games and more where being demonstrated on JavaONE this year on J2ME devices so I would get too hung up on BREW. In fact I wouldn't even bother with that technology.

BREW is currently a CDMA only technology. The majority of the world uses GSM thought. (Americans sometimes forget this since CDMA has a larger, but weakening, footprint in the US.) The majority of carriers and handset manufacturers are committed to J2ME in someway. Motorola has gone so far as to pledge that all of its phones will ship with J2ME by the end of this year. Even CDMA carrier Sprint PCS have decided to forego BREW for J2ME when they launch thier new service this August.

If your a developers, where would you put your efort first?

J2ME has its limtiations though. Then again so do these devices -- With a screen not much larger then an airmail stamp we're not even talking game boy here. The limitations of J2ME are currently being addressed with initatives such as Project Monty (a new high performance virtual machine), Mobile Game API and the Mobile Media API.

<tim/>
---
http://tima.mplode.com/

IIRC, the Java Authentication and Authorization APIs also deal with SASL quite well.

yep

Well, membership in the JCP is limited to people who pay Sun $2000 per year for education, gov't or NPO entities or $5000 per year for corporations. Otherwise you can apply and hope to be an "expert" and comment on one specific JSR. That's awfully convenient, having a "independent standards committee" run by Sun, requiring payment by Sun and requiring you sign an agreement with Sun. JCP is a joke.

JCP - Java Community Process
To take right from their website:

The JCP 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. 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.

Come on people, do your research before you blab this stuff.

Unfortunately, STL's use of templates and inlines can inflate the size of your code in exchange for raw speed.

At times it's not even "in exchange", considering degraded locality of code for instruction caches.

I read a few days back about generics, a proposed extension for Java that resembles C++ templates, but only to an extent. I'd say the extension is very elegant, if one accepts the idea of the single-rooted object hierarchy.

1) As has been pointed out countless times before, the CLR isn't really multilanguage - it just supports languages than are semantically equivalent to C# with a common set of types.

2) Performance of Java 1.4 is far better than the current C# SDK, believe me on numerically-intensive stuff they're not even close - this is what one would expect from a mature VM. However, there is no fundamental limitation in either Java or Dotnet - they can both be JIT compilers - though Java is currently more intelligent since it can factor in dynamic statistics, such which branches are commonly taken, whereas Dotnet is a static-only compiler.

3) a) An unsigned datatype? Are you serious? This is utterly trivial. Anybody pointing to this sort of language feature as a significant differentiator is clearly unfamiliar with genuinely alternative programming paradigms - functional, logic-based etc. Don't they teach LISP in college these days?
b) Directory structures? Well, I have never anyone complain about this in 4 years of programming Java - if you can point to an actual problem I'd be fascinated to see it.

4) Java is controlled by the JCP. You can read about it here: http://jcp.org/home/index.en.jsp. If you think MS is about to give up control of the Dotnet platform to other vendors you must be under the influence of something more pernicious than mere naivety.

In fact, JDOM is a part of the Java Community Process as Java Specification Request 102.

Sun comment about JDOM:

In general we tend to prefer to avoid adding new APIs to the Java platform which replicate the functionality of existing APIs. However JDOM does appear to be significantly easier to use than the earlier APIs, so we believe it will be a useful addition to the platform.

In fact, JDOM is a part of the Java Community Process as Java Specification Request 102.

Sun comment about JDOM:

In general we tend to prefer to avoid adding new APIs to the Java platform which replicate the functionality of existing APIs. However JDOM does appear to be significantly easier to use than the earlier APIs, so we believe it will be a useful addition to the platform.

JSR80 started in Sep 2000. Look at its web page, that is what I meant by check your facts. In fact, it was being developed internally since 1999. Just because it wasn't public doesn't mean it didn't exist.

there's an argument to be made that the essence of "Open Source" has a lot more to do with open development process

I agree. So why are you bashing JSR80? The expert group had no choice (read the JSPA and/or IEPA) on when to make the docs/code public.

"we can easily accept other peoples' bugfixes, and yet maintain total control".

I don't know where you got the idea that either the CPL or javax.usb itself somehow "maintains total control". Like any other OSS/FS project, we control our copy of the code and anyone else is welcome to use, contribute, and even fork it if they want. How exactly could a corporation "maintain total control" over code under an OSS or FS licese anyway?

Free Software is still basically precluded by the JCP rules.

Only the API "belongs to Sun". Yeah, that sucks. But the RI and TCK, and any other implementation, can have any license they want (if I read Sun's announcement correctly). And the API should be difficult to change, since by definition APIs shouldn't bounce around. However it's quite changable, the expert group just has to have a mainentence review and update it.

You should really read up on how the JCP works and things may be clearer to you.

JSR80 started in Sep 2000. Look at its web page, that is what I meant by check your facts. In fact, it was being developed internally since 1999. Just because it wasn't public doesn't mean it didn't exist.

there's an argument to be made that the essence of "Open Source" has a lot more to do with open development process

I agree. So why are you bashing JSR80? The expert group had no choice (read the JSPA and/or IEPA) on when to make the docs/code public.

"we can easily accept other peoples' bugfixes, and yet maintain total control".

I don't know where you got the idea that either the CPL or javax.usb itself somehow "maintains total control". Like any other OSS/FS project, we control our copy of the code and anyone else is welcome to use, contribute, and even fork it if they want. How exactly could a corporation "maintain total control" over code under an OSS or FS licese anyway?

Free Software is still basically precluded by the JCP rules.

Only the API "belongs to Sun". Yeah, that sucks. But the RI and TCK, and any other implementation, can have any license they want (if I read Sun's announcement correctly). And the API should be difficult to change, since by definition APIs shouldn't bounce around. However it's quite changable, the expert group just has to have a mainentence review and update it.

You should really read up on how the JCP works and things may be clearer to you.

JSR80 started in Sep 2000. Look at its web page, that is what I meant by check your facts. In fact, it was being developed internally since 1999. Just because it wasn't public doesn't mean it didn't exist.

there's an argument to be made that the essence of "Open Source" has a lot more to do with open development process

I agree. So why are you bashing JSR80? The expert group had no choice (read the JSPA and/or IEPA) on when to make the docs/code public.

"we can easily accept other peoples' bugfixes, and yet maintain total control".

I don't know where you got the idea that either the CPL or javax.usb itself somehow "maintains total control". Like any other OSS/FS project, we control our copy of the code and anyone else is welcome to use, contribute, and even fork it if they want. How exactly could a corporation "maintain total control" over code under an OSS or FS licese anyway?

Free Software is still basically precluded by the JCP rules.

Only the API "belongs to Sun". Yeah, that sucks. But the RI and TCK, and any other implementation, can have any license they want (if I read Sun's announcement correctly). And the API should be difficult to change, since by definition APIs shouldn't bounce around. However it's quite changable, the expert group just has to have a mainentence review and update it.

You should really read up on how the JCP works and things may be clearer to you.

JSR80 started in Sep 2000. Look at its web page, that is what I meant by check your facts. In fact, it was being developed internally since 1999. Just because it wasn't public doesn't mean it didn't exist.

there's an argument to be made that the essence of "Open Source" has a lot more to do with open development process

I agree. So why are you bashing JSR80? The expert group had no choice (read the JSPA and/or IEPA) on when to make the docs/code public.

"we can easily accept other peoples' bugfixes, and yet maintain total control".

I don't know where you got the idea that either the CPL or javax.usb itself somehow "maintains total control". Like any other OSS/FS project, we control our copy of the code and anyone else is welcome to use, contribute, and even fork it if they want. How exactly could a corporation "maintain total control" over code under an OSS or FS licese anyway?

Free Software is still basically precluded by the JCP rules.

Only the API "belongs to Sun". Yeah, that sucks. But the RI and TCK, and any other implementation, can have any license they want (if I read Sun's announcement correctly). And the API should be difficult to change, since by definition APIs shouldn't bounce around. However it's quite changable, the expert group just has to have a mainentence review and update it.

You should really read up on how the JCP works and things may be clearer to you.

Do you wonder why GameSpy's article described the technology in such glowing terms? They're a member of the Java Game Profile JSR's Expert Group. Hardly an impartial observer; they should've at least mentioned their involvement in the article.

That's news to me, when we moved into the public review period for JSR80 (javax.usb), the JCP PMO suggested that we host the RI, licensed under the Common Public License, on our own server.

We have written and circulated a change to the draft JSPA that would permit the RI to be so licensed.

Well that's good news. I thought it was already ok! Guess that's why IANAL.

That's news to me, when we moved into the public review period for JSR80 (javax.usb), the JCP PMO suggested that we host the RI, licensed under the Common Public License, on our own server.

We have written and circulated a change to the draft JSPA that would permit the RI to be so licensed.

Well that's good news. I thought it was already ok! Guess that's why IANAL.

before starting the boycott read the comments here: http://jcp.org/jsr/results/99-7-1.jsp

Many agree with the concerns of Apache although they voted yes.

I've read the mono FAQ and rationale and... I still don't understand why I should care about this. Some of it is the lack of details - like they mention garbage collection but don't mention if memory can still be manually freed (something akin to Obj-C on Darwin seems best). Some of is that it isn't scheduled to run on my system (OS X). This really doesn't seem like much more of a solution to any issue than is already available via Java, Corba and other means. Oh well, I guess this is the constant question for this project and I should look through the archives, though I suppose if it was answered to my satisfaction I would remember it. And as is tradition, I must mention the "hope Sun learns a lesson and makes Java a public standard" sentiment (and please don't mention their fucking joke called the "Java Community Process" - only $5000 and I can have input on more than one API, yay!)

OK.. I am a Java fan... (recently this has been changing though.)

I have mixed feelings with JDK 1.4.

The JPDA (debugging) support in 1.4 is vastly improved. You can now redefine classes in a running virtual machine. This is really cool and I have written an Ant 'Redefine task to take advantage of this.

The assert facility is OK.... i don't like the fact that they added an Assert keyword but I don't get to make the decisions.

There is also some controversy.

The JSPA agreement that one has to sign to participate in the JCP is WAY too restrictive for Open Source developers. The Apache Software Foundation has a good document where they drawn the line in the sand on their participation.

The Log4J people are upset because there is now a 'stanard' Java package for logging. IMO the 'standard' package is inferior to Log4J in many situations.

The regexp package is not all it is cracked up to be either. I would recommend Jakarta ORO or Jakarta Regexp.

As far as that... it runs GREAT on Linux. Probably the most SOLID VM I have ever run.

They did break some stuff with legacy code. If you ever named a class 'URI' your code will now fail to compile because they put this class in the java.net package which everyone imports anyway.

As far as C# vs .Java. I am really impressed with the CLR/CLI stuff. Right now, as it stands, Java is a proprietary language. Unless we see SUN Open Source Java (or push it through a standards committee), we *may* see a JDK 1.5... but no one will use it.

Also.. check out my Reptile project. It is Java based, only requires JDK 1.2 and incorporates some really cool Java/XML stuff. :)

Oh, goody! The chance to duke it out in front of an audience! ;-)

You'll excuse me if I have my doubts based on the previous track record.

First things first. There is no file system hierarchy imposed by Java. The usual package naming convention you see is just that, a convention, and doesn't signify that the packages are in a parent-child relationship. As for the folders, I guess it was just a convenient way of representing the existing convention in a file system. A repository/database based system like Visual Age for Java is free to use whatever it wants. You can just as easily put your classes in a flat list of directories corresponding to packages as long as you have a compiler that understands it (easy to do in a day by driving JDK compiler). The point is, you don't violate the language or API specification by doing so.

I wouldn't say inner classes and operator overloading are at the same level of utility. One is (useful) syntactic sugar, the other is a way to create fine grained objects not easily represented otherwise. See this for an example of their use. This is not to say that operator overloading isn't useful, it's a great way to write seamless data structures. In fact, I wish I had them in Java, but with names and interfaces and without the C++ syntax.

It's not fine grained. AppDomain's and Assembly's are okay when all you want is to isolate unrelated components from each other (like web apps in a servlet engine), but they fail when those components need to interact with each other. In effect, this precludes a whole class of software that use aggressively component based architectures, like JBoss, HP's Core Services Framework, Apache Jakarta Avalon or the Eclipse IDE Framework, for that matter. The basic problem is that isolation and resolution are lumped together in .NET, and you won't be able to isolate components and resolve references from one component to another at the same time. See the Developer's Guide on MSDN for details. I'd love to be proved wrong on this because I like some of AppDomain's details and similar stuff with more advanced functionality is in JSR 121 for application isolation, so let me know if this line of reasoning is not correct.

Because it's a big mechanism with lots of artifacts hard coded into the language itself. Funny, because you pointed out the difficulty of using operator overloading correctly when I see the cryptic application of operators for managing event listeners in C#. See this article on why delegates are not a good idea, it covers the basics even though it's not about C#'s version of them (I like Objective-C's delegates though, but they are different).

Reflection works just as well, thankyouverymuch. I find it fundamentally wrong to stuff code with metadata when you can have it separate. I like the descriptor stuff in J2EE, I wouldn't want bits of it in my source code. Yes, sometimes it's more work, but it gives you the flexibility to change mappings (it's always a mapping to something else, be it EJB's, WebMethods in .NET, or whatever) on the fly. Of course there are exceptions, it becomes tedious when there is a 1-to-1 mapping from the code to target domain with no properties on the mapping itself. A canonical example is the @deprecated Javadoc tag in Java. In the end, I think it makes a big difference to have discipline to not abuse such a system, and all previous experience says that MS doesn't have that.

But that's just me, and objects in the mirror may seem further than they really are to you...

Looks like you picked the right door! Not only do you win a platform supported by a whole industry, but the only truly open standard around! Now THAT bears repeating.

Of course, I'm talking about the Java language. Where else do you get something where the language and VM are controlled by a standards body composed of many companies across many industries, that have to approve all changes made (Sun only controls licencing of the Java trademark)? How about a standard where real everyday people like you and I can propose changes and make comments on proposed standards?

Wait, you were thinking you might get .NET? Odd, I thought they didn't have the full standard submitted to the standards body. And I'm not clear on how I can comment on progressing ECMA standards.

Lastly, what's stopping you from writing everything on top of a raw turning machine? After all, everything you want to do is technically supported...

Check out calling conventions from Eiffel# to C# and then perhaps you'll rethink the usability of cross-language prgramming.

.

Have a nice day.

Isn't the STL, and the generic programming it introduces, one of the main features lacking in Java? Or will Java catch up in that area?

Yes and yes. However, some caution is in order here.

It is a common misconception that the STL, templates and generic programming are synonymous, that one is only good with the others. This is not true. Generic programming is the concept, the programming style. C++ supports generic programming through its template facilities, but other languages (e.g., functional languages) manage perfectly well without a formal template mechanism. The STL is a very clever library based on generic programming principles, and the C++ standard library contains a large amount of material based on it, and unfortunately also commonly known as the "STL", though it is not entirely Stepanov's original idea. Also unfortunately, C++'s language facilities aren't quite up to making the most of it yet -- templates are a good start, but a couple of major omissions are still crippling for now. Hopefully the next revision of the C++ standard will incorporate things like in-place definition of anonymous functions, to fulfil the currently wasted potential of the standard algorithms.

Sadly, Sun's Java team seem to be amongst the uninformed here. The Java Generics proposal, which you can download via this link if you're interested, basically describes a heavily cut-down version of C++ templates. The usual Java approach has been adopted: take what is commonly used, quietly ignore anything else, add a little here and there but not much of substance. If memory serves, the more glaring omissions include numeric template parameters. Useful techniques from the C++ world such as traits and template metaprogramming appear to be hard or impossible to implement with the current Java generics proposals. As a result, Java's "generics" will probably be good for writing template containers -- itself a great improvement over the status quo -- but not very useful for much else.

It's a step in the right direction, certainly, but in spite of the hype, Java is still way behind the field on this one. The major functional programming languages are probably in the lead, and C++ is still the next most serious contender I know of by quite some distance.

Java is a marketing buzzword that covers a variety of technologies. Quoting http://java.sun.com/java2/whatis/:

The JavaTM platform is based on the power of networks and the idea that the same software should run on many different kinds of computers, consumer gadgets, and other devices. Since its initial commercial release in 1995, Java technology has grown in popularity and usage because of its true portability. The Java platform allows you to run the same Java application on lots of different kinds of computers.

[...]The idea is simple: Java technology-based software can work just about everywhere. Java technology components don't care what kind of computer, phone, TV, or operating system they run on. They just work, on any kind of compatible device that supports the Java platform.

In the Java 1.0 days there were essentially three things referred to as Java: the JVM, the language, and the standard library. Oh, and maybe something about delivery of applets through sandboxed bytecode. Four things Sun wanted you to think of for the term "Java". Now there are a zillion. Soon, there will be a zillion and fifty.

OK, OK, those aren't at the same architectural level as the big three components. But "Java" has become increasingly vague, and don't think Sun isn't encouraging this. They want non-directed feelings of goodness associated with whatever's in their (proprietary) platform this week.

If what people wanted from Java was just a language, in the traditional view of what a language is, gcj would have taken over the world by now.

Java is a marketing buzzword that covers a variety of technologies. Quoting http://java.sun.com/java2/whatis/:

The JavaTM platform is based on the power of networks and the idea that the same software should run on many different kinds of computers, consumer gadgets, and other devices. Since its initial commercial release in 1995, Java technology has grown in popularity and usage because of its true portability. The Java platform allows you to run the same Java application on lots of different kinds of computers.

[...]The idea is simple: Java technology-based software can work just about everywhere. Java technology components don't care what kind of computer, phone, TV, or operating system they run on. They just work, on any kind of compatible device that supports the Java platform.

In the Java 1.0 days there were essentially three things referred to as Java: the JVM, the language, and the standard library. Oh, and maybe something about delivery of applets through sandboxed bytecode. Four things Sun wanted you to think of for the term "Java". Now there are a zillion. Soon, there will be a zillion and fifty.

OK, OK, those aren't at the same architectural level as the big three components. But "Java" has become increasingly vague, and don't think Sun isn't encouraging this. They want non-directed feelings of goodness associated with whatever's in their (proprietary) platform this week.

If what people wanted from Java was just a language, in the traditional view of what a language is, gcj would have taken over the world by now.

GNU Classpath and its related projects, while trying to fulfill the noble goal of creating an open source implementation of the Java Runtime Environment, has nothing to do with Litris' "predicament". Sun's JRE (and a number of others, notably the IBM's JRE) can be used freely to execute any kind of software, and is fully compatible with open source.

As the article and many people here have pointed out before, it is easily demonstratable that the whole issue is a smoke screen -- equivalent open source projects (e.g. JBoss) have never had problems with Sun.

Sun's policy in respect to Java (including the JRE) has been to provide a mechanism for the definition of standard specifications via the Java Community Process, and let players in the market provide different implementations of those specifications. The JCP is also obliged to provide a reference implementation and a compatibility testing suite to ensure that different implementations work well with each other. The whole idea is precisely to avoid vendor lock-in and to promote excellence via competition between different implementations (compare this with .NET). This policy plays very well with open source, since it allows the open source community to create competitive and highly compatible implementations of those standards. JBoss (an open source implementation of the J2EE specification) is excellent example of that.

That the 2.3 Servlet specification and 1.2 JSP Specification have been released as final.

You can get the full details here.

The Zip file you'll find there contains a bunch of examples, along with the (proposed) spec in PDF.

As I said, I really liked the proposed changes, just not the timeframe they'd be in place (still years off, JDK 1.5). I think a basic problem that some people have with the spec is that it follows in the same path as Java itself of only allowing object types as parameters - thus no primitive types. I think some people wanted an exact copy of the C++ template mechanism, but like other areas of the language it borrows features from other languages where appropriate.

Other standards bodies don't have registration fees? Just anyone can jump in? Sun in this case acts more of an administrator, and like other standards bodies the fee basically means sponsored membership of some sort that makes sure only people with some degree of interest in the work under discussion are members.

You forgot to mention the "Individual Expert" option where individuals can, for free, become standard reviewers. Sure they can't submit JSR's but they can review them so if you feel REALLY STRONGLY about an upcoming standard you can get involved at the lowest level. The public at large always gets to review and comment on public drafts of a proposed JSR.

As for Sun having "The last word" on JCP's, I'd like you to give an example. As far as I can tell the orgianization has an executive committee of 16 members, one of which is always from Sun but the rest are other elected members from other companies - and a company may only have one member in this committee, including Sun. This panel decides what JSR's to work on, as well as finished JSR's to accept.

Read the JCP 2 Process document, then come back and re-state your argument.

If you really want to know, the elected members of this committee are listed here

Other standards bodies don't have registration fees? Just anyone can jump in? Sun in this case acts more of an administrator, and like other standards bodies the fee basically means sponsored membership of some sort that makes sure only people with some degree of interest in the work under discussion are members.

You forgot to mention the "Individual Expert" option where individuals can, for free, become standard reviewers. Sure they can't submit JSR's but they can review them so if you feel REALLY STRONGLY about an upcoming standard you can get involved at the lowest level. The public at large always gets to review and comment on public drafts of a proposed JSR.

As for Sun having "The last word" on JCP's, I'd like you to give an example. As far as I can tell the orgianization has an executive committee of 16 members, one of which is always from Sun but the rest are other elected members from other companies - and a company may only have one member in this committee, including Sun. This panel decides what JSR's to work on, as well as finished JSR's to accept.

Read the JCP 2 Process document, then come back and re-state your argument.

If you really want to know, the elected members of this committee are listed here

No it isn't. It's Sun's. They refuse to let it go, refuse to let it be an open standard, and they never will allow it.

I'm afraid it is you who are wrong about a great many things...

In particular, it's finally time to lay to rest the false notion that Sun controlls Java. It is controlled by a standards body called the Java Community Process, plain and simple. IBM has a major VM as do other companies, and they are not letting Sun alone hold the reigns on Java. There are far too many corperations from all sides that have gone with Java to let Sun alone control things.

Furthermore, I would argue that not only is Java controlled by other groups besides Sun but in fact Java is the most open and interactive standard to ever come down the pike, and THAT is what has really made it popular with developers. All new aspects of Java (like generics support or new API's) come through the JCP, and along the way ANYONE can help shape the direction of things - I know as I've been on the KVM mailing list as well as the Java 2D mailing list before they were finished standards, and ideas from individuals were incorperated into final standards. That means everyone who wants to has a say in how the API works along with the giant corperations, who send reps to the ISO bodies you seem to think Java needs to be controlled by. I don't know about you but I like enhancements done out in the open with vigorous discussion from everyone rather than by some smoky-back-room process.

If Java really is closed, how can projects like Kaffe exists? (GNU JVM).

Ugh, this is getting so tired. XP CAN run Java. In fact, in can run the MS JVM if you download and install it. It can run any JVM you want that you download and install.

Well, that's great! So support then is on the same level as Perl, in that you can download and install that. What percentage of users do that again? I think right now I'd say that XP comes with better support for Code Red than Java.

I agreee though with the concept that XP really has shot itself in the foot by not including Java. This leaves the door open to say "well, they're going to have to download a VM anyway so we might as well use the Java plugin". Microsoft could have kept Applets mired in the old Java 1.1 world for quite some time, but now that the plugin is more of an ooption it can help further the use of Java. I know that discussion is happening right now at my own company, we're pretty sure to move on to using the Java Plugin for external applets to help provide a more standard applet environment.

Why do people insist on writing long comments trying to look smart, without actually bothering to know what they are talking about?

Why do most posters here insist on furthering group-think that's patently wrong? Who knows.

For those mistaken enough to think that Java the language and VM are not open, take a look at the Java Community Process.

Are you saying there can only be one standards body? Personally I think the important aspects of a standard are that a consortium of many different companies and people from all over (including individuals) be involved, true of the JCP. The Java bytecode is a standard, and other VM's have been written by many people. The Java langauge is a standard, anyone could write a compiler and feel safe knowing what to expect.

What is the difference to you between the JCP and ECMA? Why do you consder changes through one body open and the other not?

At JavaOne, a speaker was moaning about an aspect of the language not going in until later than Sun wanted (Generics - not out until 1.5) - but he was also happy that the JCP was working in that it was going against Sun's wishes on the matter and the community process was in control.

Those of you siding with MS and imagining it will be more "Open" than Java are in for quite a rude shock!

Assumption 1: Mono will have good performance

I am labeling this as an "assumption", because for some strange reason Mono's expected performance is not discussed here, even though there are multitudes of people consistently bashing Java for being slow.

Since the CLR is essentially identical to a Java VM in terms of high-level design, the execution of CLI code would be performed by using much the same approaches that are used for executing Java bytecode. If you look at Ximian's CLR implementation roadmap, you will see that it follows exactly the same path that the Java implementations took, except that it stops short before the last step -- runtime optimization. (Just to note that this last step is the most difficult one, but it is exactly what allowed Java to get close to C/C++ in terms of performance. JIT helps, but it simply does not cut it -- it is not enough).

Now, it took more than 5 years of intensive work for the JVMs to reach their current level of performance. How long will it take for Ximian's CLR impelementation to become fast enough and not be branded by the people on /. as slow? Obviously they can benefit from some of the Java work, but personally I feel that it would be very unlikely if that happens within less than 3 years. (although it would be nice if it did)

Assumption 2: .NET is standardized, so we can do multi-platform development

By now we all know that C# and the CLR have been submitted for ECMA standartization. What is important to realize is that while the C# language may be standardized, most of its libraries would not be. if you look at the list of libraries that are submitted for standartization, you can count 257 entities (classes, interfaces, delegates, etc.) defined in there. On the other hand, if you count the entities provided by the libraries in .NET beta1, and exclude the server-specific stuff, the OS-specific stuff, and even WinForms, you will get a number that is very close to 2000. So in effect Microsoft is standardizing at most 13% of the libraries it provides to Windows developers (the figure would be even lower if we include WinForms and other libs that might also be of interest).

What are the implications of this fact? The standardized libraries might allow OSS developers to build more extensive libraries base on pure CLI (w/o native code) and thus create an environment for multi-platform development. The suggestion to use the .NET libraries for this purpose, however, would fly in the face of everything that we have learned about Microsoft in the past -- as long as they have a monopoly, they will play games with the API, and will turn the whole endevour into a perpetual tail chasing.

It seems to me that Ximian do recognize this fact, but I am not very clear how they plan to counter the problem. In the article Nat said "I hope it doesn't happen" in reference to Microsoft changing the API, and that an open source version would "reduce the chance that Microsoft will be able to do that". If that is their strategy, well... good luck.

Assumption 3: You need .NET (Mono) to implement or use Web services

This is one of the reasons given in the article as to why Mono is necessary, and I am sorry to say this, but it is complete bull. The Web services that MS is advocating are based almost entirely on SOAP and XML, which are completely platform-agnostic and language-agnostic -- that's what MS has been touting as an advantage all along. You can communicate to a Web service using C and a set of SOAP libraries if you want to. If Ximian wanted to have a safe development environment to implement and use Web services, there is already a very mature one in existence that provides superb SOAP and XML support -- Java.

There is only one objective reason that I see for selecting .NET over Java, and it is not mentioned in the article at all: the CLR is designed to support multiple languages, unlike the JVM. The catch here is that the JVM already supports a hell of a lot of languages other than Java and that languages have to be bastardized to be used on the CLR, but still, I guess it does hold some marginal advantage.

Finally, as you can see above, the whole supposed licensing advantage of .NET vs. Java is a complete red herring. In fact, Java holds some practical advantages in that respect: In Java concrete specifications are provided not only the main libraries, but also for many optional ones. Changes in the Java API must be approved via a fairly democratic process as part of the Java Community Process, of which OSS groups such as the Apache foundation are also members, and is open to entry by others as well. All this has allowed a lot of implementations of the various Java libraries by a lot of independent vendors. Will this happen with .NET? Anyone willing to bet money on that one?

Java on the client side will hopefully (have grammar nazis given up on this one?) start to blossom with Java Web Start (example game, specs).

Take a look at the JSR 134 for this: http://jcp.org/jsr/detail/134.jsp In combination with this, there is a bunch of work in the JCP wings for dealing with USB devices (based on a pre-existing OSS Java USB API for Linux no less!)