Berin Loritsch wrote:
> >
> > > public class java.sql.SavePoint {}
> > >
> > > Sun guards the java.* classes jealously, and I need to know if this
> > > is really a solution.
> >
> > What Sun generally tries to do is to stop people from extending or
> > subsetting the full API. What you are describing certainly looks like a
> > subset to me.
>
> Are you sure it is not a superset? In a Jdbc 2.0 environment, this class
> is not even available. All the other classes are not touched, superceded,
> or anything. I can make the SavePoint interface match Sun's definition,
> which would avoid the "subsetting" issue. The question is, is this enough?
IANAL. I do not speak for Sun. But Java is a Registered Trademark, and
there are specific conditions on its permissable use. My experience has
been that this use would not qualify.
If you try to avoid the subsetting, the next hurdle is that the
implementation you make must pass the compliance test suites.
The options this leaves are not pleasant. I tried to head this off by
raising this issue this past summer, with specific compilation failures
that would arise carefully documented. All I was asking for was a set of
jars that JDK 1.3 users could compile against, much as has been done for
quite a number of other JSRs. Unfortunately, I could not generate much
excitement on this issue here, nor within the necessary places within Sun.
For now, I *watch* jdk 1.4 builds at:
http://nagoya.apache.org/~rubys/gump/java14/
But personally, I expect to be on JDK 1.3 for a while.
Sigh.
- Sam Ruby
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
