Hi Grzegorz, --- "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
