| I have a few observations that might help inform what we do here. 1. There is often what you might call "implementation" in the javax.<spec> domain. There are bootstrap classes in the JSR 220 and JSRs 12 and 243 that must be implemented by the javax code. And Exceptions and Errors have to be classes. But 99% of the time, the javax material comprises interfaces that an implementation is supposed to implement. 2. There is no reason that I know of to restrict commit privileges on the javax code to expert group members. The TCKs typically include signature tests that verify that the interfaces and classes contain exactly what they are supposed to. 3. There is ongoing maintenance on the javax code in a JSR. Clarifications in the specification often lead to slight changes in the implementation of classes. Less frequently, an API can be added to a specified interface (doesn't change backward compatibility but adds functionality). 4. Apache JDO (which notwithstanding information on the incubator web site has graduated;-) is a project that is implementing both the API and the TCK. It's not clear to me what the advantage is to putting the API part in another project. Other projects that want to access the API jar can simply reference it via maven or download the jar files. 5. The JDO spec development is done in the open via cross-posting to the official JDO expert group alias and the apache-jdo dev alias. But this practice is not very common; many JSRs are developed in secret. 6. The roadmap for the Apache JDO project includes an implementation of the JDO 2 specification for relational and other databases. There is synergy with Tomcat, Geronimo, and the DB TLPs to integrate this future implementation into web and application servers and tools. Craig On Dec 30, 2005, at 9:32 AM, Geir Magnusson Jr wrote:
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! |
smime.p7s
Description: S/MIME cryptographic signature
