Re: SPECjvm98
On Tue, 19 Mar 2002, Dalibor Topic wrote: Speaking of benchmarking suites, there is Ashes from the SableVM people. http://www.sable.mcgill.ca/ashes/ I think it's open source, so I'd prefer that. :) Okay, thanks, I'll take a look at that. There are also some open source conformance test-suites, I believe. I like the idea, but that only gives us a rough estimate about performance, not conformance. I think that running a performance benchmark on a web/cvs/ftp/build server under load will produce rough results most of the time. Good catch; no, obiviously you can't run the benchmark on a machine being used for something else at the time and expect to get reasonable results. However, since you'll have to run the benchmark on different architectures anyway, you might as well run them on separate machines that are idle overnight or the like. Also, it does give you a rough idea on conformance if the benchmarks break too badly :) I was thinking more in the terms of breaking some optimization. The problem with optimizations is that they're quite platform specific and sometimes longer to run than simple conformance/ regression tests, so they're difficult for a single developer to run. In addition Kaffe has pretty good conformance, but it would appear performance could use some work. -Jukka Santala
Re: Interesting results...
On Thursday 21 March 2002 07:28, Mason Loring Bliss wrote:
On Thu, Mar 21, 2002 at 04:42:13AM +0100, Dalibor Topic wrote:
Try to rebuild Klasses.jar using jikes 1.13
I've built Jikes 1.13 and set JIKES = jikes in rebuildLib and Makefile,
and this is what I see:
Issued 1 semantic warning compiling java/awt/Toolkit.java:
504. native static synchronized void imgProduceImage(
ImageNativeProducer prod, Ptr imgData); - *** Warning:
The type ImageNativeProducer is defined in the file Image.java but
referenced in the file java/awt/Toolkit.java. It is recommended that it
be redefined in ImageNativeProducer.java.
That's just jikes complaining about a hack in AWT library code. The code
should work nevertheless.
I haven't tried the latest jikes from CVS yet, I'll do it today.
Compilers that work for me:
* jikes 1.14
* kjc 1.5b (has other serious bugs, though).
* javac 1.3.1
Compilers that don't work for me:
* javac 1.4.0 : make check fails almost all tests since the warning about
changed class file format version is not expected by the tests :) May work,
but will generate lot of assert is a keyword now warnings during
compilation.
* kjc 2.1A : miscompiles CatchDeath (and a few other tests), so that it fails
to verify on JDK. since kaffe's verifier doesn't recognize the error, kaffe
proceeds and does weird things.
* gcj 3.0.4 : fails to compile Klasses.jar due to a bug in gcj.
* javac 1.1.8 : fails to compile Klasses.jar due to bugs in javac.
C-Compilers:
I use gcc 2.95.3. My experience with gcc 3.0.4 was mixed : kaffe compiles, but
I get more failed tests. I didn't have time to investigate.
Failing tests:
Some tests have really tight watchdog timer settings. They will fail if you
are using a six year old computer, running KDE 3 alongside, and running kaffe in
interpreter mode, like I do right now :). I've attached a patch that extends the
timer on watchdogs that used to fail for me.
Finally, each failing test has a testclass.out and testclass.fail file with
the expected output and the output of the failed attempt. Inspecting those
files might provide more insight at what exactly is failing.
hope this helps
dalibor topic
* test/regression/CLTestJLock.java,
test/regression/ProcessClassInst.java,
test/regression/TestUnlock.java: increased watchdog time
limits. Old, slow processors under load had a hard time passing
these tests.
diff -u kaffe/test/regression/CLTestJLock.java patched-kaffe/test/regression/CLTestJLock.java
--- kaffe/test/regression/CLTestJLock.java Fri Oct 15 05:55:53 1999
+++ patched-kaffe/test/regression/CLTestJLock.java Wed Mar 20 16:17:50 2002
-64,7 +64,7
new Thread() {
public void run() {
try {
- Thread.sleep(2000);
+ Thread.sleep(9000);
} catch (InterruptedException e) { }
System.out.println(Time Out. Failure.);
System.exit(-1);
diff -u kaffe/test/regression/ProcessClassInst.java patched-kaffe/test/regression/ProcessClassInst.java
--- kaffe/test/regression/ProcessClassInst.java Fri Feb 12 14:51:09 1999
+++ patched-kaffe/test/regression/ProcessClassInst.java Wed Mar 20 15:31:41 2002
-27,11 +27,11
static Vector v = new Vector();
public static void main(String av[]) throws Exception {
- // a watchdog thread that kills us off after 3 sec
+ // a watchdog thread that kills us off after 9 sec
new Thread() {
public void run() {
try {
- Thread.sleep(3000);
+ Thread.sleep(9000);
System.out.println(sorry, you timed out);
System.exit(-1);
} catch (Exception e) {
diff -u kaffe/test/regression/TestUnlock.java patched-kaffe/test/regression/TestUnlock.java
--- kaffe/test/regression/TestUnlock.java Fri Feb 12 14:51:11 1999
+++ patched-kaffe/test/regression/TestUnlock.java Wed Mar 20 16:54:07 2002
-20,7 +20,7
new Thread() {
public void run() {
try {
- Thread.sleep(2000);
+ Thread.sleep(9000);
} catch (Exception _) { }
System.out.println(Time out. Failure.);
System.exit(-1);
Re: Interesting results...
On Thu, Mar 21, 2002 at 05:17:13PM +1100, Andrew Dalgleish wrote: On Thu, Mar 21, 2002 at 04:42:13AM +0100, Dalibor Topic wrote: Try to rebuild Klasses.jar using jikes 1.13 jikes == 1.13 or jikes = 1.13? With jikes == 1.15 on OpenBSD-current I get: FAIL: DoubleCvt.java FAIL: TestSerializable2.java FAIL: Alias.java These three all have this error: /usr/libexec/ld.so: Undefined symbol _floor called from lt-Kaffe:/.../kaffe/kaffevm/.libs/libkaffevm.so.0.0 at 0x4006ea7c If I add libm to LD_PRELOAD they pass. I'm guessing this bit from configure may be related: checking whether deplibs are loaded by dlopen... unknown FAIL: wc.java This still gives the same error: java.lang.VerifyError: at pc 5 sp 7 not in range [4, 6]
Re: Interesting results...
On Thu, 21 Mar 2002, Dalibor Topic wrote: Compilers that don't work for me: * javac 1.4.0 : make check fails almost all tests since the warning about changed class file format version is not expected by the tests :) May work, but will generate lot of assert is a keyword now warnings during compilation. How about -target 1.1 ? -Jukka Santala
Re: Interesting results...
On Thu, Mar 21, 2002 at 05:17:13PM +1100, Andrew Dalgleish wrote: On Thu, Mar 21, 2002 at 04:42:13AM +0100, Dalibor Topic wrote: Try to rebuild Klasses.jar using jikes 1.13 jikes == 1.13 or jikes = 1.13? jikes == 1.13. -- EC
Re: Interesting results...
On Thu, Mar 21, 2002 at 08:02:11AM +0100, Erik Corry wrote: *** Warning: The type ImageNativeProducer is defined in the file Image.java but referenced in the file java/awt/Toolkit.java. It is recommended that it be redefined in ImageNativeProducer.java. It's only a warning. Ah. I hadn't dug into the build infrastructure yet, and I blindly assumed that make in kaffe/libraries/javalib would give me Klasses.jar, and I assumed that since it went as quick as it did, it had stopped after the first warning. Indeed, using Jikes 1.13 to build Klasses.jar, however it's being done, I'm able to then say javac foo.java and produce a quite functional foo.class. If Klasses.jar is toasty for everyone, would it perhaps make sense for a corrected version to be committed? I'm still dead new to Java and class library layout, so I'm not quite sure where javac fits into things - it seems to be doing the same thing Jikes does, and it's certainly working, which makes me wonder if it could actually produce itself now that I've bootstrapped it with Jikes... I guess I need to hit the FAQs some more and give some more time to my book. (I'm using Just Java^2, FWIW.) On Thu, Mar 21, 2002 at 12:52:08PM +0100, Dalibor Topic wrote: That's just jikes complaining about a hack in AWT library code. The code should work nevertheless. And it does. Thanks. Compilers that work for me: * jikes 1.14 * kjc 1.5b (has other serious bugs, though). * javac 1.3.1 Is kjc a separate project? And, by javac, do you mean Sun's javac? On Thu, Mar 21, 2002 at 12:52:18PM +0900, Ito Kazumitsu wrote: kjc.jar attached to current Kaffe, that is KJC 1.5B, has serious bugs. I suggest you should upgrade KJC to 2.1A or downgrade to 1.5A. Do we build kjc.jar as part of Kaffe? I'm not seeing how to build it from the source tree I've got here. Thanks in advance, all, for further clues. As noted, I'm up and running now, but I'd love to understand more. -- Mason Loring Bliss awake ? sleep : random() 2 ? dream : sleep; [EMAIL PROTECTED] https://acheron.ne.client2.attbi.com/
Re: Planning for next release (1.0.7)
On Thu, 21 Mar 2002, Jim Pick wrote: It doesn't have to work on everything, but if it doesn't work on a particular platform - it would be nice to identify that in the release notes. What about IA-64 ? I had a patch against some 1.0.6 cvs snapshot 2001/08/19. However, it requires gcc3.0 and there is no JIT support. I heard Debian people would be interested too. Bye, Gwenole.
Re: Planning for next release (1.0.7)
On Thu, 2002-03-21 at 08:44, Mason Loring Bliss wrote: On Thu, Mar 21, 2002 at 07:04:32AM -0800, Jim Pick wrote: For future releases, I'd like to propose a version numbering scheme similar to what's used for the Linux kernel. Out of curiosity, what is gained by that? It seems somewhat arbitrary, as the Linux kernel does it. I'm mostly in favour of the way NetBSD does things, FWIW. Release periodically, branching at each release, and simply dump new features into the trunk. I've done some NetBSD stuff too. It's very CVS-centric though - personally, I like being able to stick a version number on a development-only release and make a tarball. With tarballs, we'll get more testers if people don't feel like they have to continually check out HEAD from cvs all the time. I'm probably just biased because I'm more from a Linux background (Debian, Kernel.org) than a *BSD background. :-) I'm also in favour of frequent releases, however, so that folks wanting the stability of running a release branch never get too horribly far behind. This is not an area where NetBSD shines, but there's no reason why Kaffe can't do it. When we're in full swing development mode, I'd like to see releases made every few weeks or so. Is development active enough to warrant this? Unless there's a crazy amount of development going on, I'd think that doing nothing more frequent than one release per two months would be a sane minimum span of time. The goal, I expect, is to get folks to use Kaffe and start integrating it into their work, and having to update more than a few times per year will become per- nicious, I expect, when what people most want is a stable platform on which to base their Java projects. With sufficient change, and with a tradition of quality and stability, of course, updates can come more frequently without making the user base too nervous. It would of course be cool to see Kaffe rapidly catch up with Java 1.4, for instance. The frequency of the unstable releases would probably depend on whether there is enough changing to warrant it. I've got a lot of ideas, and I'm going to have time to work on it (partly on Transvirtual time), plus I want to suck in quite a bit more 3rd-party stuff, plus other people will be contributing, and the project will be more open - so I suspect that there will be a lot more changes. The stable releases will probably be a lot less frequent - just a major new stable release after each development cycle, plus occasional bug fixes. Fortunately, we're just reimplementing somebody's else's API (Sun), so we don't have to worry so much about release-to-release compatibility of APIs (except for the ones we define). Anyway, take all this with a grain of salt. I'm new to Java, and I don't have commit access to the repository, so I can be safely ignored. :P Thanks for the feedback! Cheers, - Jim
Re: Most popular applications?
Thanks for the good suggestions for apps. By the way, have you given any thought to improving cooperation with the GNU Classpath project? I realize that currently the licensing is probably an insurmountable goal to actually merging Kaffe's class library with Classpath, but it would be nice to be able to configure Kaffe to run --with-classpath, if such a thing were possible. Duplication of effort on such a large problem as the Java libraries seems so tragically wasteful. Yeah, the licensing debate has always been a pain. Lots of splitting hairs. :-) I definitely want to see Classpath running on Kaffe, as an option. The primary obstacle I see is just getting the integration work done. The licensing issue is primarily that Classpath is GPL + exception, while Kaffe is strictly GPL. Transvirtual obviously can't relicense Classpath as part of our KaffePro proprietary VM, so I see two parallel sets of class libraries going forward. That said, I don't see why we can't redistribute Classpath with Kaffe. I'm still pretty good friends with Paul Fisher of the Classpath project (he used to work with me at Transvirtual, he now works for the FSF), and he discussed some of the legal issues with me. Legally, I think that's doable, as long as we clarify that Kaffe's GPL overrides the exception in Classpath. That shouldn't have any affect on people using Kaffe for GPL sort of things. If people want to do non-GPL types of things, they are already affected by the fact by Kaffe's GPLness. The fact that they use Classpath instead of the Kaffe class libraries shouldn't add any additional legal burden on them. Kaffe+Classpath will have more of a legal burden (eg. pure GPL) than something like gcj+Classpath (GPL + exception). I think the old issue used to be whether or not Classpath should be GPL, or GPL+Exception. If I understand the long, sad tale correctly, Tim Wilkinson had convinced RMS not to use GPL+Exception for Classpath, since Transvirtual was developing and had released the class libraries for Kaffe under the GPL, and theoretically having a competitive library under a competing, freer free software license would have been detrimental to the business. Red Hat and Paul Fisher wanted it to be GPL+Exception to make it easier to license to companies. So even though Classpath was GPL, they did not want to incorporate the GPL code from Transvirtual. Transvirtual has a business of relicensing their implementation to proprietary customers, so was unwilling to release the code under anything more liberal than the GPL, fearing it would make it impossible to sell the proprietary version. Hence the reason there are two sets of libraries now. The IP business is icky. :-) But that's history, and now Classpath is GPL+Exception. People who have need to worry about the legal burden (eg. they have serious commercial needs) should probably be looking at licensing a commercial version anyways (eg. KaffePro, Red Hat's stuff, Sun's version, Insignia, etc.) for other reasons, like protected their own proprietary intellectual property, patent issues, support needs, etc. Maybe Classpath might even become the default class library for Kaffe, if that's what people want to use. But I don't see any good reason to completely scrap Kaffe's current class libs either. Maybe I should go into law... Cheers, - Jim
Re: Most popular applications?
Jim Pick wrote: Maybe Classpath might even become the default class library for Kaffe, if that's what people want to use. But I don't see any good reason to completely scrap Kaffe's current class libs either. But you don't see any hope of getting Kaffe's libraries relicensed under GPL+Exception so that code from them can be merged into Classpath? Of course, that's not your decision, and I assume there are multiple copyright holders involved. But if Transvirtual is still unwilling to make the exception, then it doesn't matter what any other potential copyright holders might or might not think anyway... I don't seriously expect a positive answer to this :) But you can't deny it would be nice... Stuart. -- Stuart Ballard, Programmer NetReach - Internet Solutions (215) 283-2300, ext. 126 http://www.netreach.com/
Re: Most popular applications?
On Thu, 2002-03-21 at 13:18, Stuart Ballard wrote: Jim Pick wrote: Maybe Classpath might even become the default class library for Kaffe, if that's what people want to use. But I don't see any good reason to completely scrap Kaffe's current class libs either. But you don't see any hope of getting Kaffe's libraries relicensed under GPL+Exception so that code from them can be merged into Classpath? Of course, that's not your decision, and I assume there are multiple copyright holders involved. But if Transvirtual is still unwilling to make the exception, then it doesn't matter what any other potential copyright holders might or might not think anyway... I don't seriously expect a positive answer to t his :) But you can't deny it would be nice... I doubt that's going to happen, as I said before. Transvirtual licenses the same libraries for proprietary use, so it's pretty unlikely that they'll be released under a looser license than the GPL (especially the AWT). It's probably a moot point at this time anyways, as I think Classpath is pretty complete (although I haven't ever really looked at it closely). The damage (if you can call it that) has already been done, and now the free software community has 2 class library implementations which basically do the same thing. It's duplication, but I guess it's better to have two implementations rather than zero implementations. :-) I'd love to see both Classpath and Kaffe's class libraries made to be interoperable, compatible and switchable. Cheers, - Jim
Re: Most popular applications?
Hi, On Thu, 2002-03-21 at 22:18, Stuart Ballard wrote: But you don't see any hope of getting Kaffe's libraries relicensed under GPL+Exception so that code from them can be merged into Classpath? Of course, that's not your decision, and I assume there are multiple copyright holders involved. But if Transvirtual is still unwilling to make the exception, then it doesn't matter what any other potential copyright holders might or might not think anyway... I don't seriously expect a positive answer to this :) But you can't deny it would be nice... It would be very nice and it has already happened in the past. Transvirtual donated their RMI packages to the FSF and they are now integrated into GNU Classpath. Interestingly enough the Intel Orp developers have made the packages able to run JBoss on Orp+Classpath and have submitted patches. Brian Jones added those patches to CVS yesterday. GNU Classpath is already used by a couple of VMs and adding Kaffe to that list would be very nice. Cheers, Mark
Re: Planning for next release (1.0.7)
Hi Jim, On Thursday, 21. March 2002 16:04, Jim Pick wrote: 1) Solicit feedback on what should be in the release * A recompiled Klasses.jar that works. * An updated kaffe/kaffevm/inflate.c if it suffers from the zlib security bug. * Small obvious patches from distribution vendors. * i64 platform patch from mandrake. Has cool new feature written all over it and the developer announced it on the mailing list a couple of months ago. - what not: * java.security implementation from JanosVM. It is a major enhancement that should not just be rushed in. Leave something for 1.0.8 in 2-3 months :) * s390 platform patch from debian. It is apparently broken. For future releases, I'd like to propose a version numbering scheme similar to what's used for the Linux kernel. eg. Even minor version numbers = I thought if you're downloading straight from CVS you were on the bleeding edge anyway :) Version numbers are just multisets with semantics for me. That being said, we could use the Linux version numbering scheme, if there is a) interest in maintaining an actively developing stable branch, or b) a lot of experimental development ahead. I am not sure if the number of developers is big enough to support parallel development on two trees. But if/when we fold in changes from JanosVM pocketlinix etc. there will be a lot of experimental development. Currently many users (i.e. people who are not developing for/with kaffe) seem to use the CVS version, since 1.0.6 is way behind what's in CVS now. If we release early, often remain stable, then those users will probably switch back to using releases, without being intimidated by the varying degree of stability in the CVS version. In that case, there would be no real need for a specific development branch. But then, it's a big IF, so having a specific bleeding edge development branch might be useful anyway. Count this answer as undecided, but supportive :) dalibor topic P.S. Dedicating a release to Edouard is a very good idea. _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: SPECjvm98
On Thursday 21 March 2002 10:24, Jukka Santala wrote: On Tue, 19 Mar 2002, Dalibor Topic wrote: Speaking of benchmarking suites, there is Ashes from the SableVM people. http://www.sable.mcgill.ca/ashes/ I think it's open source, so I'd prefer that. :) Okay, thanks, I'll take a look at that. There are also some open source conformance test-suites, I believe. There is mauve. There is jacks (compiler conformance). Then there are the regression test suites of various implementations, like libgcj's. I have run kaffe with mauve. I haven't looked into other conformance test-suites. Also, it does give you a rough idea on conformance if the benchmarks break too badly :) I was thinking more in the terms of breaking some optimization. The problem with optimizations is that they're quite platform specific and sometimes longer to run than simple conformance/ regression tests, so they're difficult for a single developer to run. In addition Kaffe has pretty good conformance, but it would appear performance could use some work. Optimizations in core library code should be beneficial to all platforms. But I guess you are not talking about those, since they are not platform specific. I don't think I understood the term breaking some optimization properly. Do you mean breaking some benchmark ? If so, yes, meaningful benchmarks will take longer to run than conformance tests in general. You have to run a benchmark for some time to avoid measuring side effects like disk I/O, VM startup etc. Unless of course that's exactly what you want to measure :) Conformance tests usually run for a couple of seconds each. In general, if people run kaffe on benchmarks put the results on the web, I assume that Jim will link to them. If people volunteer to do so regularly, like the nightly builds done by the flex people, someone could write a couple of scripts to collect present the information in a nice way. All it takes is to pick the benchmarks, find volunteers and agree on the procedure :) I could submit results on x86-linux, interpreter/jit/jit3. But that's a rather common platform, and not that interesting, I guess. Unless there is a massive amount of interest in seeing how kaffe performs on old, slow computers :) dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Interesting results...
On Thursday, 21. March 2002 13:24, Andrew Dalgleish wrote: On Thu, Mar 21, 2002 at 05:17:13PM +1100, Andrew Dalgleish wrote: On Thu, Mar 21, 2002 at 04:42:13AM +0100, Dalibor Topic wrote: Try to rebuild Klasses.jar using jikes 1.13 jikes == 1.13 or jikes = 1.13? With jikes == 1.15 on OpenBSD-current I get: FAIL: wc.java This still gives the same error: java.lang.VerifyError: at pc 5 sp 7 not in range [4, 6] could you post the offending class file? thanks, dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Most popular applications?
hi Jim, On Thursday, 21. March 2002 17:41, Jim Pick wrote: 1) Tomcat: http://jakarta.apache.org/tomcat/ - for running servlets 2) Jython: http://www.jython.org/ - see the note saying it doesn't work with Kaffe at http://www.jython.org/platform.html 3) I'm not going to list too many myself - I want to see what other people are running, or want to run wanting to run (haven't tried yet): * ant. it is crucial to build many java packages from apache. * hypersonicsql. pure java database. * jtidy. html cleanup program. * junit. popular unit testing framework. * soot. bytecode optimizer. long term: * banking applets. * mindterm. ssh application/applet. coolness factor: * net beans IDE. needs swing, though. * dynamic java. java source interpreter. * jikes research virtual machine. * weirdx. x server. well, you asked :) I expect the stuff in the first section to run on kaffe, since it doesn't need swing or awt. In the long term better browser integration would be nice, thus applets. The rest is just pure showing off. dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Planning for next release (1.0.7)
Hello all From: Jim Pick [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Planning for next release (1.0.7) Date: Thu, 21 Mar 2002 07:04:32 -0800 ...snip... Here's how I'm thinking of doing it: 1) Solicit feedback on what should be in the release 2) If there isn't anything major that needs to be done, we'll tag a release candidate for testing in CVS, next week 3) The people on the mailing list will test it for a week (from out of CVS) What would the testing involve? I'd be happy to help if I can. Finally, when we decide to do this release, I think we should dedicate it to the memory of Edouard Parmelan. For those that don't know, he was one of the most active Kaffe developers, a member of the core team, and one of the driving forces behind the project. He died tragically in a motorcycle accident last year, leaving behind a wife and kids. This sounds like a fine idea. I'm all for it. I think the releasing versioning proposals are good. More importantly, I'd like to see the versioning method documented on the website and descriptions of the releases placed in CVS. Mark _ Send and receive Hotmail on your mobile device: http://mobile.msn.com
Re: Planning for next release (1.0.7)
Hi Gwenole, On Thursday, 21. March 2002 18:15, Gwenole Beauchesne wrote: What about IA-64 ? I had a patch against some 1.0.6 cvs snapshot 2001/08/19. However, it requires gcc3.0 and there is no JIT support. I heard Debian people would be interested too. I checked out your patch from mandrake's kaffe-1.0.6-11mdk source distribution. It seems to apply cleanly against the current version from CVS. Could you give that a try, and tell us if it still works? thanks in advance from someone still stuck with ia32 :) dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Most popular applications?
On Thursday, 21. March 2002 18:13, Stuart Ballard wrote: Apache JServ and GNUJSP (sorry, my site was developed before Tomcat was credibly stable). http://java.apache.org/ and http://www.klomp.org/gnujsp/ And while we're going for server-side stuff, we should try to make sure as many JDBC bindings work as possible (Oracle and PostgreSQL are the ones that matter to me personally). Do JServ GNUJSP work with kaffe.org's version? If not, what's missing? JBoss seems to have some momentum these days and I might be using it in the future. Also, the other Jakarta projects: Ant seems very widely used, Struts is something I've been looking into for future use, etc. Agreed. By the way, have you given any thought to improving cooperation with the GNU Classpath project? I realize that currently the licensing is probably an insurmountable goal to actually merging Kaffe's class library with Classpath, but it would be nice to be able to configure Kaffe to run --with-classpath, if such a thing were possible. Duplication of effort on such a large problem as the Java libraries seems so tragically wasteful. That would be a nice feature, and another plaform for classpath to run on. I don't think it's a tragical waste, since both projects have diametrical goals: here a virtual machine running on an awful lot of platforms, there a class library running on many virtual machines. Different goals allow different decisions to be made, thus different ideas prosper in design development. As long as people don't get too excited about the duplication of effort, and start religious wars everything will be fine. In my opinion choice is beneficial to everyone. It might take longer to get a free software version of java 1.x with multiple class libraries being developed in parallel, but I don't think time really is such a big problem here. If you feel that development on kaffe should proceed faster, you are more than welcome to contribute :) dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Interesting results...
On Thursday, 21. March 2002 17:30, Mason Loring Bliss wrote: On Thu, Mar 21, 2002 at 08:02:11AM +0100, Erik Corry wrote: Ah. I hadn't dug into the build infrastructure yet, and I blindly assumed that make in kaffe/libraries/javalib would give me Klasses.jar, and I assumed that since it went as quick as it did, it had stopped after the first warning. Building Klasses.jar is explained in FAQ/FAQ.classlibrary-compile. Jikes is written in C++ and is very fast compared to javac or kjc. Unfortunately, the latest version has a couple of showstopper bugs that you got to experience first hand. Sorry about that. If Klasses.jar is toasty for everyone, would it perhaps make sense for a corrected version to be committed? Yes. :) Short answer: as soon as someone with CVS write access does it, it will be done. Long answer: we had some problems with the CVS server, and trouble picking the right version of jikes that generated a Klasses.jar file that just worked for everyone. Now that you've verified that everything works again with good old lucky number release of jikes (1.13), it's just a matter of one of the core developers getting that version, installing it and recompiling the class library. I'm still dead new to Java and class library layout, so I'm not quite sure where javac fits into things - it seems to be doing the same thing Jikes does, and it's certainly working, which makes me wonder if it could actually produce itself now that I've bootstrapped it with Jikes... I Here's a short introduction to java compilers: * jikes: C++ based, fast, open source. * javac: java based, part of sun's java development kit, proprietary (i guess the source is available under one of the pseudo-open source licenses from sun). * kjc: part of the kopi project, java based, free software (GPL). * gcj: part of gcc 3.0, c/c++ based, free software (GPL). * kopisusu: fork of kopi 1.4F. seems to have fallen asleep. there are a few other compilers around, but those are the major ones out there. kaffe provides additional tools beyound the virtual machine, just like the proprietary java development kits do. There are scripts in a kaffe installation that allow it and the tools to be used under those popular names. Kaffe ships with kjc as the java compiler, which can be conveniently called via the javac script. Finally, kjc should be able to compile itself under kaffe. You need to get the sources from www.dms.at/kopi first. have fun :) On Thu, Mar 21, 2002 at 12:52:08PM +0100, Dalibor Topic wrote: Is kjc a separate project? And, by javac, do you mean Sun's javac? Yes, in that case I meant sun's javac. Do we build kjc.jar as part of Kaffe? I'm not seeing how to build it from the source tree I've got here. We don't build kjc as part of kaffe. We just use a precompiled jar file. hope this helps. dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Interesting results...
Short answer: as soon as someone with CVS write access does it, it will be done. Long answer: we had some problems with the CVS server, and trouble picking the right version of jikes that generated a Klasses.jar file that just worked for everyone. Now that you've verified that everything works again with good old lucky number release of jikes (1.13), it's just a matter of one of the core developers getting that version, installing it and recompiling the class library. Archie check in a version of Klasses.jar compiled with 1.13 (sorry, cvs commits aren't being posted to the mailing list at the moment because I need to fix the script). It seems to work for me with Linux. I tried cygwin too, but had some compile probs I'll have to investigate later. Cheers, - Jim
Re: Planning for next release (1.0.7)
Hi Friends, I am bit new to open source development. Can somebody take time to highlight how things work in Open Source World and I would be grateful if some details on the process used to compile and test the VM before release. some questions that come up in mind is - Using jikes for getting Kaffee.jar... Why?? - How do we test the VM for conformance?? I guess let me hold to my questions and see if they get resolved as we move along. Regards, Partha - Attitude Matters Parthasarathy G Technology Development Center - HomeNet Wipro Technologies, EI 53/1 , Hosur Road, Madiwala Phone: 91-80-5502001-008 x3130 Fax No: 5502160 Bangalore - 560 068. Visit Home Networks Website * Intranet: http://gruha.wipro.com * Internet: http://www.wipro.com/homenet/ - Original Message - From: Jim Pick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 21, 2002 8:34 PM Subject: Planning for next release (1.0.7) Hi, Sorry I've been a bit quiet the last few days - things are a bit hectic at Transvirtual as I try to get stuff prepared for JavaOne next week (plus I'm going skiing in Tahoe this weekend). I'd really like to get a new release of kaffe out sometime soon, since it's been too long since the last release (July 24, 2000). I'm not as familiar with the codebase yet as I'd like to be - so I'm asking for opinions on what absolutely should be in the next release. I think the emphasis on this release should be just getting something out that works. It doesn't have to work on everything, but if it doesn't work on a particular platform - it would be nice to identify that in the release notes. Here's how I'm thinking of doing it: 1) Solicit feedback on what should be in the release 2) If there isn't anything major that needs to be done, we'll tag a release candidate for testing in CVS, next week 3) The people on the mailing list will test it for a week (from out of CVS) 4) Two weeks from now, we'll release it as 1.0.7 Does this sound OK? I'm a big believer in release early, release often. For future releases, I'd like to propose a version numbering scheme similar to what's used for the Linux kernel. eg. Even minor version numbers = stable, Odd minor version numbers = unstable. So, future releases in the 1.0.x series would be considered stable, ready for production. We'd open up development on a new 1.1.x series, which ultimately would become 1.2.x when it's deemed ready for a stable release. With this arrangement, as developers, we'll have the freedom to do some radical stuff to the 1.1.x tree, as people downloading it will understand that it's a development series of releases. When we're in full swing development mode, I'd like to see releases made every few weeks or so. What do people think of that idea for versioning and making releases? Finally, when we decide to do this release, I think we should dedicate it to the memory of Edouard Parmelan. For those that don't know, he was one of the most active Kaffe developers, a member of the core team, and one of the driving forces behind the project. He died tragically in a motorcycle accident last year, leaving behind a wife and kids. I'm going to be very busy this coming week with JavaOne next week, but I'll try to stay as involved as possible in trying to make this release happen. Cheers, - Jim **Disclaimer Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited.
Re: Interesting results...
On Thu, Mar 21, 2002 at 05:33:21PM +0100, Dalibor Topic wrote: On Thursday, 21. March 2002 13:24, Andrew Dalgleish wrote: On Thu, Mar 21, 2002 at 05:17:13PM +1100, Andrew Dalgleish wrote: On Thu, Mar 21, 2002 at 04:42:13AM +0100, Dalibor Topic wrote: Try to rebuild Klasses.jar using jikes 1.13 jikes == 1.13 or jikes = 1.13? With jikes == 1.15 on OpenBSD-current I get: FAIL: wc.java This still gives the same error: java.lang.VerifyError: at pc 5 sp 7 not in range [4, 6] could you post the offending class file? Works ok with jikes 1.13. With jikes == 1.15 built from their tarball, the file test/regression/wc.java in CVS gives this error in wc.fail java.lang.VerifyError: at pc 5 sp 7 not in range [4, 6] at java.io.PushbackReader.init(PushbackReader.java:32) at java.io.StreamTokenizer.init(StreamTokenizer.java:50) at wc.init(wc.java:72) at wc.main(wc.java:104) wc.class.gz attached, but I'm happy to use 1.13 wc.class.gz Description: application/gunzip
CVS update: kaffe/libraries/javalib
Date: Thursday March 21, 19102 22:40 Author: jim Update of /cvs/kaffe/kaffe/libraries/javalib In directory loco:/tmp/cvs-serv30377/libraries/javalib Modified Files: Klasses.jar Log Message: Applied patch from Dalibor, incorporating DatagramPacket/Socket API updated from Timothy Stack (from JanOS VM)
CVS update: kaffe
Date: Thursday March 21, 19102 22:40 Author: jim Update of /cvs/kaffe/kaffe In directory loco:/tmp/cvs-serv30377 Modified Files: ChangeLog Log Message: Applied patch from Dalibor, incorporating DatagramPacket/Socket API updated from Timothy Stack (from JanOS VM)
Re: Interesting results...
Stuart Ballard writes: As far as I can see Jikes 1.13 is the one that works. The alternative is to actually find the bug, probably somewhere in the verifier. I tried running with ElectriFence and it made no difference, so I don't think it's a malloc bug. No, the bug is in jikes. Jikes 1.15 is completely broken, jikes 1.15b fixes some of the errors but leaves in at least one major one: VerifyErrors on any constructor of a non-static inner class that is either non-public or calls this(). I've also heard bad things about jikes 1.14, but didn't hit any of those personally. I recommend requiring specifically jikes 1.13 until 1.16 comes out. FYI, I just checked in a rebuild Klasses.jar built with jikes v.1.13. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com
