[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Policy change proposal - JVMs Provides: requirements



Hi Grzegorz,

--- "Grzegorz B. Prokopski" <gadek@debian.org> wrote:

> > ;) Check the japitools JDK API compatibility pages
> at
> > http://rainbow.netreach.net/~sballard/japi/
> Thanks for the link. However in this case the APIs
> are compared,
> not if they really work. There's a lot of stubs in
> GNU Classpath,
> so I doubt if this comparison method is sutiable for
> our purpose.
> Every JVM that uses GNU Classpath would get same
> results. It's
> comparison of classpaths not JVMs.

I'd say there are three states an implementation of
functionality from an API goes through:
1) not there
2) there and defect
3) there and perfect

The stubs in classpath count for me as 2). They let
you compile programs against the stubs, after all, and
thus  are definitely more useable than 1). I think
this was one of the reasons the OpenOffice guys went
ahead with Classpath and not kaffe's class library for
their debian build work. Classpath has at least free
software stubs for swing, while kaffe has none, but
works well with sun's implementation. Using kaffe +
sun's non-free swing would have kicked OpenOffice out
of 'debian-free', if I understand the debian policies
right.

In my opinion, stubs that haven't been filled yet,
should be treated as bugs, and incite people to
provide their own implementations.

Actually, you need to take into account that semantics
of some methods have changed between different
versions of the API. So you may get runtime
incompatibilities no matter what you decide on
java*-provides.

I think the matter is no different than when deciding
whether gcc is a good enough C/C++ compiler. It may
not support all of C99, it may still lack some C++
features, it may even have some bugs, but in a lot of
situations, it's a very useful tool. But there must
have once been a time when gcc was not very useful for
compiling most C & C++ programs ;)

Talking of whether things really work should be done
within the context of the mauve test suite, in my
opinion. 

It would be a great service to the free java community
if someone could set up a site similar to the
Japitools page, that would pull the latest CVS source
for gcj, kaffe, sablevm, wonka, kissme, etc., build
them, and run them against the latest mauve from CVS,
and publish the results. Give people some graphs, to
track progress, too ;) There is a perl script in the
japhar CVS that can convert the output from mauve into
html.

Unfortunately, I can't do it. Most importantly because
I'm a regular kaffe developer. I'd prefer to see
someone more "vendor-independant" than me do it to
avoid any bias. Plus the usual lack of time; I'm busy
enough fixing bugs in kaffe ;)

best regards,
dalibor topic

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



Reply to: