 |
Why have a JCP
It is important to keep in mind why there is such a thing as the JCP. This question can be answered in many different ways depending on who you ask.
Here is an overview;
There is a one liner that best illustrates the need for the JCP: The problem with standards is that there are so many of them
When you look at where Java is headed it is save to compare hardware interfaces with the software interfaces the JCP is creating standards for. If you take memory cards for things like cameras you will see what I mean. Every vendor has its own standard and none work with the others; over time one will be more standard to the rest. But big guys like Sony will always have a memory stick that only they can talk to.
There is no need to say that this is bad for the consumer since it leads to less choice and vendor lock in. It is also bad for the vendor since consumers will upgrade less, the vendor has to put a lot of effort into creating the spec and mostly has to support specs that only cost money to support.
The JCP means to bring together these vendors to create that new spec for memory cards together and to be able to build on top of that technology seperately for optimal provits and user benefit (the latter since it stimulates the former).
Are those Standards?
Well, standards is nothing but a set of agreements, you don't have to keep to them if you don't want to. But there are verious reasons why you should (which are out of scope for this page).
The real question thus is Is the standard giving me the functionality I need ?. There are several points you have to consider when you ask this question.
- If the spec represents some hardware interface, the hardware has to be capable of doing what you want.
- Making the spec too broad could mean the vendor can't build that feature you want in the spec on top of the spec. It might be his competative edge.
- If the spec is talking about an extension (next version) of an existing spec, in what gradiation should it be kept backwards compatible. Some vendors might feel strongly about that; but can't discuss it due to some company secrets.
- An open source programmer mostly just wants to get things done; in a clean manner. This can be contrairy to what the former points suggest.
Industry Standards
Not all standards come from specifications. Not all specifications pre-date the standard. A problem with the JCP is its "design by committee". It also is a reflection of a pre-opensource/internet world. Some of the most ubiquitous standards predate the formal specification. HTML, SMTP, SAX, etc. These are standards based on what people actually use. Standards adoption is fastest and most complete when it is bottom up. It is slower and less complete when it is top-down (SOAP, JCP).
Why does the JCP need reform?
The majority of this page is vendor-centric. The majority of the Java world is not. One problem with the JCP is that it is also vendor centric. One objective is to incorporate and enfranchise the small players, the developers and the open source community into the process. These are the people who REALLY set the "standards". The JCP can produce specs that are not standards. They're only standards if people use them. Given the current apathy of the Java community towards EJB, J2EE? and other JCP standards, there may be a day coming when the very legitimacy of the JCP and its ability to dictate standards is held in question. The problem is that this may be very bad for Java.
The JCP is driven by a couple of large vendors who hold all of the power. They set the rules. They decide who can see the standard, have input in the standard, etc. Often this results in a standard that is no different than had IBM or Sun simply put the work into their product and declared themselves the standard. By incorporating the interests of the Java community as a whole, more legitmacy and better standards can be created. By making the standards process more implementation driven, standards based on what people need/use can be created.
Discussion:
To use it or not to use it.
My personal stand is simple; this process will probably give me better specs then I have seen in the past from individual vendors since its a lot more public and they also learn. (WAP comes to mind here).
If this proves to give us APIs that are powerful enough to use, I will use it. And this is something the vendors will eventually learn as well, to leverage the individual progremmer means to wield power. -- ThomasZander - 13 Jul 2003
|