I agree with you, you are doing great

Cheers,

Sacha

If Jonathan wants to bring the software face of Sun in the forefront, then he may as well redirect his sales staff, service engineers from a Hardware persona to a Software one. This in my honest opinion is the toughest job to do.

I will not be surprised if they change the name of “Sun Microsystems” to “Java Microsystems” with a motto of “We do Java Virtualization”.

It may be better to motivate the employees and bring out the innovation in them that has been lying hidden due to market fears. SUN is a brand, a synonym with a great technological company (Sutherland, Joy, Gosling, etc). Now this attempt to re-image yourself as Java is a bad one, IMHO.

The issues the vendors are squabbling about today are issues they should have fought about 2004, when we first started working on scaling JCP’s steep walls and certifying Kaffe as a 1.5 implementation. The EC comfortably slept through the whole open source Java phenomenon for five years, and never bothered to figure out why those odd Kaffe, gcj and Classpath people are deliberately staying outside the JCP, and what their problems with the system are.

Today, that ‘omg, making an open source Java 1.5 implementation is not as easy as advertised by the JCP, shock, horror’ battle is no longer relevant. We’ve been there, we’ve done that, and we found a better way to win it over the past three years.

The relevant battle today is to turn the JCP into something where no longer a single vendor, or a cartel of vendors & their friends can have the ultimate advantage over others. The only way to get everyone to disarm at the same time, is to make clear, simple rules that grant everyone equal rights, rather than exclusive rights to those running the system. That leads naturally to open source RIs, TCKs, no NDAs, etc. That’s what the EC should get on, but from discussions with Sacha & Geir, I know that’s illusionary with the current EC.

So, alternatively, we should just gradually vote ourselves an EC that will do it, and put the interests of the community back into the JCP. We shouldn’t wait until the vendors run Java and the JCP into the ground, and we shouldn’t pay to watch another round of Unix vendor wars.

The current JSR system discriminates against people who don’t sign NDAs, for example. Yet the JCP EC never saw it fit to stand up against that discrimination and abolish it in the past five(5) years I’ve been following it, and to establish equal access to all of the Java community to JSRs under development (i.e. as long as commenting on them makes any sense at all).

That’s been something the GNU Classpath community has demanded at least since 2002, btw., but the JCP EC didn’t find time yet to fix that particular equal-treatment issue. I mean, the JCP EC never found the time in the past five years to invite the Classpath community to a JCP meeting and listen to their list of issues with the JSPA either. I assume they must be really busy doing whatever the JCP EC is doing behind closed doors.

Thanks for your kind words. As you might not have understood, JBoss/Red Hat is not directly concerned by the field of use restriction of Java SE as we are using (and participating in) the OpenJDK project with SUNW, we are not using Harmony. However, we do think that the Harmony project should be properly treated, as a principle of equal-treatment.

Cheers,

Sacha

No, sorry, I cannot, per JCP-EC rules.

Cheers,

Sacha

>>
They have had no success whatsoever with any of the (numerous!) Application Servers they released into the market up to now in spite of the fact that they’ve made significant investments in the software field (including the acquisition of SeeBeyond). Is it paying off? My bet is that it is not
>>

From what I can see, GlassFish is doing _very_ well, and others, like Forrester (see http://blogs.sun.com/theaquarium/entry/what_a_difference_18_months) ) seem to agree. – eduard/o

So I’m not buying the argument that the spec lead is worse off with an open source RI, as I haven’t seen any spec lead with an open source RI come out and complain about it. So it doesn’t seem to be that limiting, as afaik Sun and IBM are happily licensing their code to whoever cares about licensing it under non-free terms. I don’t think they are all switching over to open source RIs for their JSRs out of the pure kindness of their hearts alone.

I don’t see how. The RI has to be *fully functional* (it is not just a set of API). For most specs, that represents quite a bit of work!

Cheers,

sacha

I’d optimistically assume that current JSR spec leads have learned their lessons of API design over the past years. They’ve had a lot of practice, if nothing else …

Voting the current EC out would not be a revolution, it would be just a simple reform for the JCP to start serving the C in that acronym, rather then only the proprietary vendor subset at the expense of the rest of us. When the time comes, the vendors will jump on that bandwagon, like that did with open source Java, and we’ll all be winners, as usual.

I agree with you, the Java phenomenon is impressive. While we can certainly criticize many things and could improve many others, the list of languages/platforms that have generated so much value for an entire ecosystem, and this during more than 10 years must be pretty short and Java must be sitting right at the top of that list.

If Java had not been in the hands of SUNW (but instead in the hands of any of the big software guys out there), I am not sure I would be here to write the same thing today. That’s why I am currently concerned that SUNW might be have decided to go in the wrong direction with Java.

We are spoiled…

Cheers,

Sacha

In fact, I am referring to none of the cases you’ve outlined above – but almost.

Mandating FOSS RIs and TCKs would limit the opportunity of the spec leads to keep a competitive advantage for their own implementation – usually a super-set of the RI. More specifically, if my business model is to sell proprietary software then I might be fine to lead a spec but might not want to make all of the IP of my RI available to any competitor out there, which is fair enough. The JCP is about standards, not implementations. If you want an implementation, go and code it yourself. In FOSS Again, that is because most of the time, the product of the spec leads is an extension of their RI.

Companies that are NOT JSR leads but want to implement a JSR are not mandated to do it in FOSS, obviously. Providing the same possibility/option to the Spec Leads seems fair to me.

Also, if, as you hinted, the Java Developer community really thought it was suffering that much, it would be trivial for “it” to do what you are suggesting and to get rid of the current ECs (all it takes is to become JCP member and vote – all of this is free).

I cannot feel that wind of revolution yet

For the handful, at most, specifications that have gone the route of making both the RI and the TCK open source, I don’t recall anyone complaining about that choice limiting their business model. Quite to the contrary, Doug Lea’s concurrency JSR was hailed as the supermodel JSR everywhere, afaik, and it was the first JSR I’ve seen to have both an open source TCK and an open source RI.

At best, an argument could be made that mandating FOSS RIs and TCKs limits the opportunity of the spec leads to make a business out of discriminatory access to specifications, RIs or TCKs, which is a business model that’s currently encouraged by the JCP EC by default for most JSRs.

All the regular schoolyard theater that happens in the JCP around discriminatory access to one thing or another (and there something fishy going on every year, year after year) is a direct consequence from allowing the creation and maintenance of supposedly community driven and maintained specifications to be perverted into a profitable line of business for a couple of members of the JCP establishment at the expense of the Java developer community, that gets to deal with the consequences, and pay for them, directly or indirectly.

Putting an end to that sort of business practice would actually be a great thing for Java developers everywhere. But I don’t expect vendors on the JCP EC to empower their consumers by giving them non-discriminatory access to RIs, TCKs, and specifications without being dragged kicking and screaming to do it. And I certainly don’t expect the current EC to do the dragging part.

I am not sure I agree with you on the proprietary TCK & RI. If the JCP releases good standards and good TCK&RI so I can i) prove that the standard can actually be implemented (RI) and ii) test my own implementation (TCK), then I am fine.

Most FOSS JSR implementations (if not all of the FOSS ones) actually never license the RI, just the TCK. And while it would sometimes be easier to be able to look at the TCK code (mostly to debug the TCK itself before raising a challenge before the spec lead), that is more by comfort than really a must-have.

I don’t think FOSS should become a mandatory constraint for the RI&TCK. This industry contemplates many different business models: the JCP should respect this and allow for these various business models to co-exist.

Imposing the TCK&RI to be FOSS software goes against that respect for multiple business models IMO.

Cheers,

Sacha