The JCP is dead. Like a headless chicken, it doesn't realise it yet and it's still running around, but it's already dead. I don't think many people will be sad to see it go.

Don't get me wrong; it's been useful to some extent as Java has grown. But over the last five years, the JCP has been synonymous with bulking up the junk of the JVM (and its many patches. In fact, despite deprecating APIs, very little has actually disappeared over the years (and the only one that was really deprecated came back again a few releases later).

And in its older years, Java is starting to go grey and putting on weight, with Java 6 clocking in at a sprightly 13.9Mb. By comparison, Java 1.1 was 2.6Mb; although Java wasn't really usable until Java 1.2; but even that was 5.2Mb. Let's not forget that each one of these is compressed, and so the rt.jar (or for the really old-skool, classes.zip is likely to be somewhat bigger on disk).

What has all that extra baggage bought us? Sure, the VM's been improving over the years; but even though there's interest on running other languages on the JVM (including of course, Sun's own sponsored JRuby) you still can't download/use the VM without the runtime baggage. I mean, when was the last time you used javax.sound.midi? And who uses java.util.logging when there's a better log4j implementation? And let's not forget the fact that the XML parser is almost always worth ripping out and replacing with a more up-to-date version of xerces. (And the less said about java.util.Date, the better.)

At the centre of all this is the JCP, which is to Java what a Belgian chocolatier is to an overweight group of dieters. The home of the Java bloat brings us ever more junk in the form of Java libraries that get downloaded along with the central runtime, all in the name of progress. Unfortunately, although the C might stand for Community, what it really means is Control; everything that passes through those hallowed doors is really a licence to bloat. There's even a mechanism to cut back the classes loaded – although what that really does is just change the download from a big über-jar of everything into a set of smaller jars, whilst downloading the rest of the crap in the background.

What Java desperately needs is a decent modular system that can allow parts to be dynamically brought on-line as needed. In fact, it should be possible to download a minimal VM/JIT/Object/String that you can use as a basis for other languages (like the aforementioned JRuby). If you need I/O, bring that down separately. If you need networking, bring that on-line too. It should be possible to mix-and-match those at run-time, and applications should say what they need. It has the potential to be a lot better than (say) CPAN because this could be made dynamic and self describing, instead of modules that have to be downloaded manually.

Alas, we're as far away from that as ever. Despite working modular systems sitting on top of the existing Java mechanism, others are in development and have been a priori decided to be in Java 7, rather than being based on technical merits of the same. That Java needs a modular system is without doubt; what's needed is a realisation that a one-classpath-fits-all solution is really not going to work. And yet the proposals so far all exhibit the same kind of Not Invented Here weakness (along with its cousin, We Can Do Better Without Really Understanding The Problem) meaning that we're going to end up with more bloat that no-one uses and replaces with a more capable system in any case.

But modular systems aside; JCP is not about community; it's about Control. Read through any of the JSRs and there's a section on "Why isn't this addressed by existing systems". Reading through them is an exercise in marketing; there's invariably no real reasons there, but rather 'We can do it better/different/smaller/faster'. What really happens in these situations is that the spec leads have zero interest in building upon what's already there; they want to get in their own version of a codebase (whether real or proposed) and the arguments are essentially 'Because we didn't write it'. The so-called 'expert groups' are nothing more than a peer review process of the developers (normally the submitters of the JSR), and have zero impact on the code that actually gets developed. (Normally, the submitters of the JSR will supply the sole developers of the code rather than enlisting the help of the expert group, so that they can own all the IP of the process.) In other words, it's the sanctioned blessing of doing whatever you want to do; and the failure rate of the JSR is pretty low (often only because the spec leads give up and move on to something else).

Worse for Java overall is there's very little stewardship of the language actually evolving. Evolution doesn't just mean unconstrained growth; it means evolving. Bits that are useless (hello again, Date) should be cut off. Better still, a decent modular system should be able to supply the missing bits in a 'compatibility' module that others could use for handovers, but with the assumption that going forward they wouldn't have the support. OK, so there's a warm fuzzy feeling that you get when you can run an Applet compiled under Java 1.0 on today's Java 6 systems; but from a practical purpose, it's about as useful as that scientific calculator that you've got stashed at the back of the drawer because that's what you had in class and never wanted to let go.

And as for Java the language; Microsoft are winning this battle, and have been for some time. Generics in Java (a separate joke, but never mind that here) were a knee-jerk reaction to the C# code base; and before that, very little interesting happened in the language. Microsoft on the other hand understands the need for developers (as the chair-bashing CEO has been known to chant) and so the .Net framework supports plenty of languages out of the box. No, I don't mean random toy languages that you can find with a Google search; I mean real languages that are being used for day-to-day use. On the other hand, the JVM's only really got Java as a prime language; everything else are also-rans. (Scala is neat, and JRuby has a bunch of weight behind it, but they're still small fry in comparison to the Java ecosystem as a whole.) Why aren't some of these features coming into the Java language? Functions as values, ability to map over nested collections, continuations; Java has none of these. Heck, it's only just graduated from the everything-is-a-for-loop.

All this has been clear for some time. What's also clear is that there's nothing happening about it (that will make a difference). The Java Kernel, or Java Browser Edition, or Consumer JRE, or whatever the marketing droids are calling it now (and you can bet that V2 will have a new name) is really just a more optimised way of downloading the JRE at application start-up. It's not modular, it doesn't permit a cut-down VM, and it downloads everything whether you need it or not, just at different times:

The basic workings of the Java Kernel are as follows:

• Download base functionality that every application needs: VM, garbage collector, security, classloader, and enough networking functionality to be able to download the rest of the bits.
• Download additional dependencies that this application specifies.
• Download any Class not found exception culprits as needed.
• Download the rest of the JRE in parallel until the entire release exists on the user's system.

Compare that with (say) Flex and there's a clear winner in terms of usability and download speed/start-up time. Importantly, Flex doesn't have ten years of baggage with it, which means it can concentrate on the things that really matter instead of those that don't. Unfortunately, the Consumer Kernel Browser JRE doesn't focus on the big picture; it's just a shuffling of the bits. There's also very little thought given to updating the CKBJRE; whereas a decent modular system will independently version modules (and thus only update the ones that need changing), the CKBJRE freezes a particular version of the JRE at the time it was downloaded without ever having plans to update them. All it does is solve the initial start-up problem, and even then, it still downloads everything whether you need it or not.

So, with Java heading down the expand-and-conquer of the available drive space, what's a budding new language to do? Well, Scala has the ability to run on a .Net platform or a JVM platform, and I think a VM agnostic language may well be the way for new languages in the future to be adopted, though possibly a niche area. What I think is more likely to happen is approaches like Google has taken with GWT and more recently with Android which is essentially to reuse the benefits of the powerful Java IDEs to allow code to be written against a subset of the language that they've given up Sun ever providing, and then use the resultant compiled code to generate an executable. This is really the same form of transparency that (say) Scala gives; the language doesn't constrain what the underlying runtime should be (although in Google's case, the language is similar enough to take advantage of tools that others have developed to help write it).

Not only that, but (in my mind) the important part is that there's no JCP involved. Much like other open-source projects evolve and have incremental releases, so too can Android. With Java, the JCP is extra baggage that both slows down the development cycle, and then (for good measure) prevents you from running that on an older version of Java. Compare this with your favourite open-source library; they're all pretty Java-version agnostic, and you can mix-and-match your library levels with the VM level. At this point, the advances in Java are more about performance of the VM than any real change in the underlying supporting cast of libraries.

Of course, a mobile phone platform is an interesting beast. What will really make it happen is the fact that you can update the software remotely; something that hasn't ever really happened in the traditional mobile phone market before. And let's face it; Java on the mobile phone has been a complete disaster. What has J2ME ever done for you? Granted, there's the occasional game; but really, a technology just for that? Where's the bluetoooth support? The USB connectivity? Being able to make a call, or help index your contacts?

In fact, J2ME died when manufacturers started saying 'Java compatible' on the handsets. Is that MIDP 1.0 or MIDP 2.0? Is it based on CDC or CLDC? Does it support JSR 82? JSR 232? Frankly, no-one knows and (more importantly) no-one cares. The mobile phone market is way too fragmented in terms of types of user-base, and the fact that there's a single marketing slogan 'Java inside' doesn't help distinguish any of the features. It's a bit like selling cars with 'Uses gas!' as the marketing statement, instead of the size of the engine, number of cylinders, whether it's fuel-injected or not etc.

Anyway, the point of the matter is that JSR is deadweight, just further adding to the bloat of an increasingly dated and bloated technology. Instead of setting the VM free and having a modular system built on top (like Harmony), Java is doomed to suffer under its own weight with the JCP speeding up the demise. It now appears to be too late to fix these problems; and hence we're seeing innovation happening outside the hallowed JCP grounds and into the realms of moving the technology forward using other, more nimble, means.