I was thinking about another way of pushing Jakarta, partly in the context of the issue with Sun. If there was an open process for standard setting, it could make Sun's closed process less important.
The IETF does well at being open, but I don't think they would get involved in something like this. Things like the RFC Editor function are already overstretched just doing network standardisation. However, something along similar organisational lines could work. The other thing I would like to push is gcj. It doesn't seem to be very well known. For people who haven't come across it, it is part of gcc and it is an ahead-of-time compiler for Java. It also includes a bytecode interpreter so it can deal with dynamically generated code, and a free implementation of the Java class libraries. To some extent a project like this is always trying to keep up with Sun, but it isn't doing badly. There is already some code (in CVS) to bring it into compliance with some aspects of JDK 1.4, for example. It will also compile many of the Jakarta products. There is a list of some current ports at: http://sources.redhat.com/rhug/ A community-based standards process, together with gcj would provide independence from Sun. It is tempting at the moment to embrace .NET, but that would just tempt Microsoft to pull the same tricks in a few years' time. Microsoft is not in this out of altruism any more than Sun is. The other point is that Sun will only change if they are given a reason to. They are a profit-making company and so of course they will act in their own interests; that is how business works. The Java Apache projects have been one of the major reasons for Java's acceptance. Apache distancing itself from Sun would be a major reason for them to be more accommodating. (Admittedly Apache doing things with .NET would be an incentive for Sun too, but my first point still holds.) Right now, Java has a major threat from .NET, and Sun really shouldn't be fighting with its allies... -- Pete -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
