Re: Building Kaffe with GTK AWT
On Monday 15 April 2002 03:10, Jim Pick wrote: I know the Trolltech guys are also selling a Qt AWT - I'm not sure if it is available under the GPL or not. Does anybody know? Someday, I'm going to phone them up and ask. :-) Proprietary, as far as I know. There are also Qt based AWT projects within QtJava and somewhere on sourceforge. I don't think that any of them is ready for the prime time. Once we get into full blown development mode, I'd like to collect as many of the AWT implementations together as I can, and make them selectable at configuration or run time. I'm sure some of them are going to be essentially dead (eg. BISS AWT), but there's no harm in making them available. The main one I'm going to support (for kaffe.org) is going to be the X11 one, and maybe the Win32 one. sounds great. dalibor topic
Re: PATCH: truncated class handling
Hi Patrick, On Tuesday 16 April 2002 00:49, Patrick Tullmann wrote: I've attached the ChangeLog entry here. I can check this in, but want to know if I should check it in now, or if we should wait for after the 1.0.7 release. Other feedback or issues are welcomed, too. depends on how experimental it is. On which platforms did you test it? In general, it sounds great. I haven't merged the relevant kaffevm changes from JanosVM yet, so I'd say you go first :) dalibor topic
Re: Building Kaffe with GTK AWT
On Monday 15 April 2002 17:05, Marc Haisenko wrote: On Monday 15 April 2002 03:10, Jim Pick wrote: On Fri, Apr 12, 2002 at 05:15:10PM +0200, Marc Haisenko wrote: Hi folks, I'm developing a STB using Linux on which we run a Java AWT app. Cool. I wouldn't mind talking to you about KaffePro then, since that's looking like it's going to be our target market, primarily. We're just in the initial stages of defining what we're going to do to the product, and I wouldn't mind some feedback. Uhm, sorry, I'm not a native english speaker, do you mean you want or don't want to talk about KaffePro ? :-) And what is KaffePro ? Ja, er will ;-) Transvirtual released a lightweight AWT called no-native-wm (plus a framebuffer graphics library called fgl) with the PocketLinux stuff. You can dig it out of the tarball here: http://www.kaffe.org/ftp/pub/packages/pocketlinux/ Of course, it's already somewhat dated and completely unsupported, and don't expect Transvirtual to be updating or bugfixing it in the future (although other people are free to build on top of the GPL'd code). I've looked into it, and I don't like it ;-) Especially the no-longer-supported character of it. It would nice to fold it in into kaffe.org's version and support it, if we can find someone who would like to do it :) Also, I know the Microwindows people got kaffe working with their framebuffer library (I'm not sure if they used the Win32 widgets or the X11 widgets as their base). Does anybody know of any other free framebuffer AWT implementations? There are some pretty cool base graphics libraries out there that look nice (DirectFB, PicoGUI). Some of those could be bound to no-native-wm, I guess, but somebody would have to do the work. and SDL for the gaming community :) My problem is, I can't find any instructions on how to actually compile Kaffe to use GTK instead of X. I've downloaded and untarred Kaffe 1.0.6 and gtkawt.tar.gz, copied the content into the Kaffe source tree and am now puzzled with how to go on. There seems to be no switch in the configure script and there seems to be not a single document about this, not in the source, not on the Kaffe web site and according to Google not on the net at all. So, can somebody give me the needed hints ? Or is the GTK AWT dead ? If so, does someone know of an alternative to get an AWT for the Linux framebuffer ? I don't think anybody is using it. I notice that there is also a GTK AWT in the PocketLinux kaffe sources that were released. It might be same one... OK, so this means the GTK AWT is not really supported by the Kaffe team ? that's right. It's out there for the adventureous to play with, but it's not part of the official distribution, - unsupported. You might still get some questions answered if the author is one the mailing list. You might get some support for the pocketlinux version on the pocketlinux mailing lists. You could complain, or you could fix it and submit it for inclusion. :) Maybe you could do something like Wonka's AWT ? They essentially seem to have implemented an AWT which uses the framebuffer and then wrote a small simulator to run in X. I think the most portable solution would be a generic AWT and then to write a kind of frontend which maps the primitive graphic operations. But I guess this wouldn't be as easy as it sounds, especially when it comes to performance. I thought the AWT peers had that purpose anyway? Shouldn't writing a frambuffer peer be enough? dalibor topic
Re: Answer
On Monday, 1. April 2002 14:11, David Jones wrote: On March 31, 2002 04:06 pm, Carlos Andres Cañaveral Usuga wrote: I need work with jdbc for access to a database made on postgresql. It is posible with kaffe and how? thanks This is possible. I got it working once on an HP425 workstation (how's that for a Kaffe port?) did you have to patch anything? I thought that m68k should just work :) dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Benchmarking kaffe (Was: Re: SPECjvm98)
On Tuesday 26 March 2002 14:07, Jukka Santala wrote: On Mon, 25 Mar 2002, Dalibor Topic wrote: Sticking to a standard environment would just limit the number of people able to contribute results. That's one of the things I'm afraid of. The last thing we want is people upgrading their compiler/libraries on the run, and forgetting to mention it in the benchmarks, leading to everybody think they've broken something terribly, or found a new optimization. O.K. Writing a script or a java program that compiles --version information for tools and libraries used should be possible. I'm in favor of automating the process as much as possible: 'make benchmark' and you get a bench.txt file at the end with all relevant configuration information and the results. Put a benchmark toolchain definition for that release somewhere where it gets parsed by the benchmark script. Let the script flag non-standard entries. What kind of contribution process would be suitable for such an effort? Emails to a specific mailing list? Web forms? Well, I was most initially thinking of having both a gnuplot graph of the development of the benchmark performance over time, as well as a textual log of the specific results. In the most simplest case, this would only require an e-mail notification of the location of the graphs to this list, and the URL could then be added to the official web-page if deemed useful/reliable enough. If enough data is provided, it might be worth it just to write a script on the web-site machine, that would gather the benchmark logs and collate combined graphs from them. sounds right. But, as implied, if we're aiming for just any benchmark, for posterity and some pretend-comparisions between system perfomances, then all bets are off, and we should probably have some sort of web-form for users to input in that Herez the rezultz I gotz from running my own number-calculation benchmark, calculating how many numbers there are from 1 to 1000 while playing Doom in another Window. This is OBIVIOUSLY what everybody else will be doing with the VM's, so I think this counts. I'm not sure I even have a compiler. ;) Uh, no, thanks :) But that raises an interesting question: which benchmarks would matter? For example, I assume that benchmarking kaffe's as a platform for apache.org's java projects might be interesting, since a couple of responses to the most popular applications thread had those mentioned. What could Ashes cover? dalibore topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Benchmarking kaffe (Was: Re: SPECjvm98)
On Monday 25 March 2002 10:32, Jukka Santala wrote: On Sat, 23 Mar 2002, Dalibor Topic wrote: Do you have any specific benchmarks in mind? Not particularily, but despite the subject-line on this thread, I agree with the view we should probably stay with open-source benchmarks. Ashes looks like a good alternative, and even has Kaffe regression tests section, oddly enough. I assume that's because the people that put together ashes are also developing a byte code optimization tool called soot. They use ashes to evaluate its performance. Wild speculation: they managed to successfully crash different VMs with the resulting bytecodes, thus the regression tests. I was also thinking about the java grande benchmarks, scimark 2.0 and jMocha (I have not checked their licensing status yet). While they are application specific, they are a smaller download than ashes, allowing more people to participate. I think more interesting question is if we should try to agree on a standard runtime environment; the compiler and libraries can have much bigger effect on performance than the JVM/KaffeVM in question. Primarily, this doesn't matter as long as the environment stays the same from test to test, or changes are explictly noted, but to improve comparability of optimizations between platforms etc. there might still be use for agreeing on such. It seems like GCC 2.96 would be the preference, as this is common standard, altough moving to 3.x series should be considered. How about libraries, though? This is a tougher nut to crack, altough admittedly a proper VM benchmark shouldn't depend so much on library performance. I agree that environments don't matter as long one is comparing the results to one's earlier runs. I doubt that comparing one's results with those of others will lead to anything beyond wild speculation. If I recall it correctly, the original motivation was to notice avoid performance regressions on platforms unavailable to the patch developer. Different Linux distributions, for example, ship different version of gcc with their latest offerings. Requiring that everyone compiles kaffe with the version x just puts an additional roadblock before people can evaluate performance. I would rather like to see if there are any regressions on environments that people use, than on a synthetic one. As you point out, there are a lot of external influences to VM performance. I don't feel that we should specify a standard runtime environment, since the standard environment is a moving target on any platform. In my opinion benchmark results tend to become irrelevant after some time anyway. Sticking to a standard environment would just limit the number of people able to contribute results. What kind of contribution process would be suitable for such an effort? Emails to a specific mailing list? Web forms? dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Merging PocketLinux-kaffe and kaffe.org-kaffe (Was: Re: Most popular applications)
On Monday 25 March 2002 10:14, Jukka Santala wrote: I'm not entirely sure of microwindows etc. either; but provided these modules are functional (or at least semi-so) in the code made available before clsoing the development tree, I guess it shouldn't be too much of a trouble to transfer them over. It's the core and classlib changes (sometimes supporting said modules) that would be troublesome, I think... My thinko about microwindows. I've read about it on the web somewhere, and thought it was part of pocketlinux kaffe open vm custom edition. There seems to be a port available here: http://web.media.mit.edu/~lifton/proj/E-book/technical/ I hope that even semi-functional stuff in the development tree can be motivational to someone to go ahead and add what's missing, thus I'd like to see the new platforms being merged in. After 1.0.7 is released, of course. Porting over classlibrary bugfixes from custom edition should also be reasonably easy, for those parts of the kaffe.org class libraries that don't seem to be actively hacked upon, like java.applet (last functional change on 2000-07-21, my more recent changes were just cleanup). dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: SPECjvm98
On Friday 22 March 2002 11:27, Jukka Santala wrote: On Thu, 21 Mar 2002, Dalibor Topic wrote: Now you're confusing me, as well. As noted above, modifying code on one platform can affect the performance of other platforms (or other code paths) negatively, and I doubt most developers bother to benchmark even on their own system after every little change that could've slowed things down. Hence it would be good idea to provide performance history graphs on different platforms so that people can see that Aha, so something committed on April the 1st turned the Gibbering test 50% slower on both platforms X and Y, must have been the new gibber-collector I submitted... I agree. I test the stuff I (re)implement for performance, but usually don't bother testing the performance of small spec conformance fixes. I would, for example, like to introduce a kaffe.util.param package in a not too distant future. There is a lot of parameter checking code in the io libraries, and I'd like to factor that out into the param package. The package would contain just final classes with static methods. So your typical method call to BufferedReader.read(buf, off, len) would call kaffe.util.param.Buffer.check(buf, off, len) before it goes on with your read request. Since BufferedReader.read(char [], int, int) already checks its parameters, this would in effect de-inline that code out of the read method. The resulting performance penalty would be eliminated by a JIT compiler that can inline final methods. But it would remain on platforms stuck with an interpreter. The interesting question to ask is: Is the adverse effect on performance on those platforms big enough to kill this idea? I could only know if people submitted benchmark results for those platforms, once the patch is out. 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, That is somewhat what I had in mind. I'm bit reluctant to volunteer, as I don't know how long I can contribute, but I should be able to put up performance-tracking for AMD Duron and StrongARM at least. Intel platforms should be relatively easy to come by. Sounds great. I could offer results on a Cyrix Psomething+. Do you have any specific benchmarks in mind? dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Interesting results...
On Saturday 23 March 2002 00:26, Andrew Dalgleish wrote: Should Kaffe's make check include a full test suit for all compilers? No. There is a project called jacks for that. I think it would be better if we had an application that loads links all classes from Klasses.jar. That would in turn automatically have them verified by the VM. Running that application before checking in a new version of Klasses.jar, and as a regression would be a better way to ensure Klasses.jar is in a useable state. Hint: it should be rather easy to code, so if someone feels like devoting a couple of minutes to it, go for it. dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Most popular applications?
On Friday 22 March 2002 11:16, Jukka Santala wrote: look into improving the PocketLinux Kaffe implementation. Speaking purely personally, I wouldn't mind seeing framebuffer GUI added to the desktop edition, or the GPL released versions merged, and that's something we're looking at. speaking purely personally: Merging things from pocketlinux' kaffe to kaffe.org sounds interesting to me. I've seen that pocketlinux features a lot of new stuff (new mem mgmt, gcs, jit, platforms, frambuffer, microwindows, gtk peers, ...) and would like to see some of that finding its way into the desktop edition. dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Jikes 1.15 vs. Verifier
On Sunday 24 March 2002 04:54, Dalibor Topic wrote:
I've attached the patch for class-analyse.c that improves the error
message generated when the verification fails. I hope this will make
finding that kind of issues with compilers easier.
I have now ...
* kaffe/kaffevm/code-analyse.c:
(verifyBasicBlock) improved error message.
--- kaffe/kaffe/kaffevm/code-analyse.c Fri Jun 1 21:30:05 2001
+++ patched-kaffe/kaffe/kaffevm/code-analyse.c Sun Mar 24 04:42:39 2002
-406,7 +406,8
if (sp meth-localsz || sp meth-localsz + meth-stacksz) {
failed = true;
postExceptionMessage(einfo, JAVA_LANG(VerifyError),
-at pc %d sp %d not in range [%d, %d],
+In class %s in method %s with signature %s at pc %d: sp %d not in range [%d, %d],
+meth-class-name-data, meth-name-data, METHOD_SIGD(meth),
pc, sp, meth-localsz,
meth-localsz + meth-stacksz);
break;
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: 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)
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...
On Thursday 21 March 2002 01:21, Andrew Dalgleish wrote: On Wed, Mar 20, 2002 at 06:54:48PM -0500, Mason Loring Bliss wrote: Hello, all. I saw the note about Klasses.jar on the list, rebuilt, and reinstalled. That was evidently part of the problem I was seeing, as now javac comes back with an error, as opposed to being utterly silent. Here's what I'm Hmm. I'm just trying to get Kaffe up on cygwin for the first time. make check fails 109 tests with exactly that error. A quick double check on OpenBSD-current gets the same 109 failures. Try to rebuild Klasses.jar using jikes 1.13 dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: SPECjvm98
On Tuesday 19 March 2002 10:30, Jukka Santala wrote: On Mon, 18 Mar 2002, Jim Pick wrote: Maybe we can order a copy for kaffe.org and put it on the server? I'm sure TVT will spot the $50 or $100 bucks. Interested in that? 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. :) I think it would be a good idea to have it run on daily autobuild from the CVS, with reports plotted archived on the site, so that problems (As well as improvements) in the codebase could be spotted as early as possible. (Altough, due to the variety of platforms supported, this would always be potentially bit misleading) 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. speaking of conformance: the japhar web site features a mauve results page, which would be nice to have in a similar fashion for kaffe. finally, have fun, dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Zlib in kaffe?
Hi, I have come accross this page http://www.gzip.org/zlib/apps.html that claims kaffe uses zlib and thus might be vulnerable to the recently uncovered zlib security bug: http://www.cert.org/advisories/CA-2002-07.html Is kaffe using a statically linked version (i.e. is the heavily hacked inflate.[ch] code it)? Or doues it just link to the DLL? cheers, dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
[PATCH] javac kjc 2.1A compilation fix was: Re: VerifyError in PushbackReader
On Sunday 17 March 2002 18:01, Ito Kazumitsu wrote:
Now KJC 2.1A has been released. But when I tried to rebuild
Klasses.jar with KJC 2.1A, I got the following message:
/bin/sh ./rebuildLib
Compiling classes ...
java/util/Hashtable.java:169: error:Class Entry is not accessible [JLS
6.6.1] java/util/Hashtable.java:201: error:Class Entry is not accessible
[JLS 6.6.1] make: *** [lib/stamp] Error 1
the attached patch solves that problem javac compilation problems for me.
could you give it a try?
cheers,
dalibor topic
* libraries/javalib/java/util/HashMap.java :
(getTableLength) new method.
* libraries/javalib/java/util/Hashtable.java :
(writeDefaultObject) Use getTableLength instead of accesing
table directly.
(writeObject) same.
--- kaffe/libraries/javalib/java/util/Hashtable.java Fri Nov 23 00:38:12 2001
+++ patched-kaffe/libraries/javalib/java/util/Hashtable.java Mon Mar 18 19:33:57 2002
-166,7 +166,7
private void writeDefaultObject() {
loadFactor = map.loadFactor;
- threshold = (int)(map.table.length * loadFactor);
+ threshold = (int)(map.getTableLength() * loadFactor);
}
}
-198,7 +198,7
stream.defaultWriteObject();
// remember how many buckets there were
- stream.writeInt(map.table.length);
+ stream.writeInt(map.getTableLength());
stream.writeInt(map.size());
Iterator i = map.entrySet().iterator();
--- kaffe/libraries/javalib/java/util/HashMap.java Mon Dec 3 13:11:41 2001
+++ patched-kaffe/libraries/javalib/java/util/HashMap.java Mon Mar 18 19:33:18 2002
-101,6 +101,10
return e == null ? null : e.value;
}
+ int getTableLength() {
+ return table.length;
+ }
+
public Object put(Object key, Object val) {
// See if key already exists
Re: Klasses.jar needs to be rebuilt
On Monday 18 March 2002 22:34, Carlos Valiente wrote: I have grabbed a fresh checkout from CVS a couple of hours ago and have built Kaffe on linux-ppc. Everything compiled OK, but the resulting version of kaffe didn't seem to work. I have invoked kaffe with '-vmdebug NATIVELIB' enabled; the problem was a missing native (??) implementation of java.Class.newInstance(). That method is implemented in Java, not as a native method. I rebuilt Klasses.jar and everything was fine. My bad. I changed the native implementation of java.Class.newInstance to a pure java one, and deleted the now unnecessary native implementation without telling Archie to regenerate klasses.jar. will be fixed soon, I hope dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Lock problem
On Sunday, 17. March 2002 11:40, Parthasarathy G wrote: Hi, I have encountered VM abends because of lock problems. When I went thru the code was getting the impression that this problem happens when we have a lock timeout. Any fixes for this. I'd really like to try to help you, but to be able to do so, I need more information from you. First I'd need the output of kaffe --fullversion to see which version of kaffe you're running, and os/platform details. Then it would be really nice if you could post some code that demonstrates the bug: 5-10 lines would be just fine, but in general the rule ist: the smaller the code is that exposes the bug, the better the chance that someone reads it and fixes the bug. Finally, it would be really great if you could give us more information on which code you went through, and why you think the bug happens at a lock timeout. Follow the above, and I bet you'll get more useful responses from kaffe developers :) have fun, dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: New website
On Sunday, 17. March 2002 06:14, Jim Pick wrote: I finally got the website up that I've been working on for the last few days. thanks a lot, Jim. It looks really nice, clear actually feels quite fast over my slow 56k connection. Good work! Some of the pages aren't done yet, but I felt like it would be good to get it up sooner rather than later, since the old site had lots of dead links (eg. how to sign up for the mailing list). What's not done should be easy enough to fill out. Could you post the anonymous cvs access information for the web site HTML code to the mailing list? There might be web hackers able to assist you with those tasks. cheers, Dalibor Topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: ClassFormatError when running RMI between kaffe1.0.6 and jdk1.2.2
On Friday, 15. March 2002 16:21, Yun Zhang wrote: I have compiled a simple Java RMI program using Kaffe kjc and rmic. I ran the server under Kaffe on node A and ran the client under Sun jdk1.2.2 on node B. Both of machines are RedHat linux. The client side generated the following error: Exception in thread main java.lang.ClassFormatError: SimonImpl_Stub (Bad index into constant pool) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:477) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:109) at java.net.URLClassLoader.defineClass(URLClassLoader.java:248) at java.net.URLClassLoader.access$1(URLClassLoader.java:216) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:191) at java.lang.ClassLoader.loadClass(ClassLoader.java:298) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:285) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:314) at java.io.ObjectInputStream.loadClass0(Native Method) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:630) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:126) at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:766) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:353) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:232) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:978) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:232) at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source) at java.rmi.Naming.lookup(Naming.java:89) at hiSimon.main(hiSimon.java:12) Does anyone has the similar experience or an explanation for this? I would assume that you are being bitten by a bug in the kjc compiler :( Could you give the latest version from CVS a try and tell us if that works? good luck, Dalibor Topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
[PATCH] java.awt.EventQueue : getNextEvent
Hi,
this small patch changes the behavior of getNextEvent in
java.awt.EventQueue. Instead of silently swallowing all
InterruptedExceptions, it now lets them propagate up.
Reasoning: The API specification says that getNextEvent throws an
InterruptedException.
Dalibor Topic
* libraries/javalib/java/awt/EventQueue.java:
(getNextEvent) Now throws InterruptedException. Try/catch
statements for InterruptedException removed.
diff -urB kaffe/libraries/javalib/java/awt/EventQueue.java patched-kaffe/libraries/javalib/java/awt/EventQueue.java
--- kaffe/libraries/javalib/java/awt/EventQueue.java Tue Oct 12 04:29:39 1999
+++ patched-kaffe/libraries/javalib/java/awt/EventQueue.java Tue Mar 12 12:29:04 2002
-127,7 +127,7
}
}
-public AWTEvent getNextEvent () {
+public AWTEvent getNextEvent () throws InterruptedException {
AWTEvent e;
if ( (Toolkit.flags Toolkit.NATIVE_DISPATCHER_LOOP) != 0 ) {
-137,9 +137,7
synchronized ( this) {
// block until we get something in
while ( localQueue == null ) {
-try {
- wait();
-} catch ( InterruptedException xx ) {}
+wait();
}
e = localQueue;
-181,9 +179,7
// this point only in case it is not blocked, or evtGetNextEvent()
// returned 'null'
if ( !AWTEvent.accelHint ) {
-try {
- Thread.sleep( Defaults.EventPollingRate);
-} catch ( InterruptedException xx ) {}
+Thread.sleep( Defaults.EventPollingRate);
}
}
}
[PATCH] java.awt.AWTEvent: toString
Hi,
this patch makes AWTEvent's toString method follow the description
from Java Class Libraries, 2nd Edition. It improves its comparability
with JDK's output.
It also removes some unnecessary static methods from AWTEvent, and
adapts EventQueue accordingly.
Dalibor Topic
* libraries/javalib/java/awt/AWTEvent.java:
(getID) removed unnecessary method.
(getSource) removed unnecessary method.
(toString) Improved compatibility with JDK.
* libraries/javalib/java/awt/EventQueue.java:
(dropAll) don't use static AWTEvent.getSource().
diff -urB kaffe/libraries/javalib/java/awt/AWTEvent.java patched-kaffe/libraries/javalib/java/awt/AWTEvent.java
--- kaffe/libraries/javalib/java/awt/AWTEvent.java Mon Dec 17 11:54:51 2001
+++ patched-kaffe/libraries/javalib/java/awt/AWTEvent.java Tue Mar 12 15:35:31 2002
-75,14 +75,6
return id;
}
-static int getID ( AWTEvent evt ) {
- return evt.id;
-}
-
-static Object getSource ( AWTEvent evt ) {
- return evt.source;
-}
-
protected static Component getToplevel ( Component c ) {
// Note that this will fail in case 'c' is already removeNotified (has no parent,
// anymore). But returning 'null' would just shift the problem into the caller -
-146,7 +138,22
}
public String toString () {
- return getClass().getName() + ':' + paramString() + , source: + source;
+ StringBuffer result = new StringBuffer(getClass().getName());
+
+ result.append('[').append(paramString()).append(] on );
+
+ Object src = getSource();
+ if (src instanceof Component) {
+ result.append(((Component) src).getName());
+ }
+ else if (src instanceof MenuComponent) {
+ result.append(((MenuComponent) src).getName());
+ }
+ else {
+ result.append(src);
+ }
+
+ return result.toString();
}
static void unregisterSource ( Component c, Ptr nativeData ) {
diff -urB kaffe/libraries/javalib/java/awt/EventQueue.java patched-kaffe/libraries/javalib/java/awt/EventQueue.java
--- kaffe/libraries/javalib/java/awt/EventQueue.java Tue Mar 12 12:57:47 2002
+++ patched-kaffe/libraries/javalib/java/awt/EventQueue.java Tue Mar 12 15:58:12 2002
-31,7 +31,7
AWTEvent del, last = null;
while ( e != null ) {
- if ( AWTEvent.getSource( e) == source ) {
+ if ( e.getSource() == source ) {
if ( localEnd == e )
localEnd = last;
[PATCH] misc. toString fixes
Hi,
here's yet another small fix for toString, in order to improve
comparability of output with JDK. This one adds a toString method in
java.awt.image.DirectColorModel, and adapts the existing ones in
java.awt.BorderLayout, java.awt.Event and java.util.EventObject.
Dalibor Topic
* libraries/javalib/java/awt/BorderLayout.java:
(toString) Improved comparability with JDK.
* libraries/javalib/java/awt/awt/Event.java:
(toString) Improved comparability with JDK.
* libraries/javalib/java/awt/awt/image/DirectColorModel.java:
(toString) New method.
* libraries/javalib/java/awt/util/EventObject.java:
(toString) Improved comparability with JDK.
diff -urB kaffe/libraries/javalib/java/awt/BorderLayout.java patched-kaffe/libraries/javalib/java/awt/BorderLayout.java
--- kaffe/libraries/javalib/java/awt/BorderLayout.java Wed Mar 24 08:56:18 1999
+++ patched-kaffe/libraries/javalib/java/awt/BorderLayout.java Tue Mar 12 12:57:27 2002
-318,6 +318,6
* Returns the String representation of this BorderLayout's values.
*/
public String toString() {
- return getClass().getName() + [ + hGap + ',' + vGap + ']';
+ return getClass().getName() + [hgap= + hGap + ,vgap= + vGap + ']';
}
}
diff -urB kaffe/libraries/javalib/java/awt/Event.java patched-kaffe/libraries/javalib/java/awt/Event.java
--- kaffe/libraries/javalib/java/awt/Event.java Thu Feb 28 22:54:10 2002
+++ patched-kaffe/libraries/javalib/java/awt/Event.java Tue Mar 12 12:59:52 2002
-156,7 +156,7
}
protected String paramString() {
- return (id= + id + ,x= + x + ,y= + y + ,key= + key
+ return (id= + id + ,x= + x + ,y= + y
+ ,target= + target + ,arg= + arg);
}
diff -urB kaffe/libraries/javalib/java/awt/image/DirectColorModel.java patched-kaffe/libraries/javalib/java/awt/image/DirectColorModel.java
--- kaffe/libraries/javalib/java/awt/image/DirectColorModel.java Sat Jul 24 02:56:16 1999
+++ patched-kaffe/libraries/javalib/java/awt/image/DirectColorModel.java Tue Mar 12 13:36:34 2002
-126,4 +126,11
return (i + (j - 8));
}
+
+public String toString() {
+ return DirectColorModel: rmask= + Integer.toHexString(getRedMask())
+ + gmask= + Integer.toHexString(getGreenMask())
+ + bmask= + Integer.toHexString(getBlueMask())
+ + amask= + Integer.toHexString(getAlphaMask());
+}
}
diff -urB kaffe/libraries/javalib/java/util/EventObject.java patched-kaffe/libraries/javalib/java/util/EventObject.java
--- kaffe/libraries/javalib/java/util/EventObject.java Fri Nov 23 00:38:12 2001
+++ patched-kaffe/libraries/javalib/java/util/EventObject.java Tue Mar 12 13:29:09 2002
-26,6 +26,6
}
public String toString() {
- return (source.toString());
+ return (getClass().getName() + [source= + source.toString() + ']');
}
}
[PATCH] Bug fix for java.util.Vector
hi,
this patch fixes some problems with kaffe's javautilVector
implementation I found them while playing around with the Vector
examples from Java Class Libraries Second Edition Vol1 Supplement book
One javautilVector example from the book is still broken, subList I don't
have a fix for that, since I don't understand the AbstractList implementation
well enough to come up with a solution
Patch and change log entry are attached
cheers,
Dali
diff -ur kaffe/libraries/javalib/java/util/Vectorjava patched-kaffe/libraries/javalib/java/util/Vectorjava
--- kaffe/libraries/javalib/java/util/Vectorjava Mon Dec 3 13:11:41 2001
+++ patched-kaffe/libraries/javalib/java/util/Vectorjava Thu Feb 28 03:05:43 2002
-107,8 +107,9
// required because we might have a large enough, pre-allocated, empty element
// array that doesn't give us (physical) access errors
if ( index = elementCount )
-throw new ArrayIndexOutOfBoundsException(IntegertoString(index)
- + = + elementCount);
+ throw new ArrayIndexOutOfBoundsException(Array index out of range:
+ + IntegertoString(index));
+
return elementData[index];
}
-168,7 +169,7
public synchronized int indexOf(Object elem, int index) {
for (int pos = index; pos elementCount; pos++) {
Object obj = elementData[pos];
- if (elem == obj || elemequals(obj)) {
+ if (elem == obj || (elem != null elemequals(obj))) {
return (pos);
}
}
-287,7 +288,13
if (pos 0) {
resultappend(, );
}
- resultappend(elementData[pos]toString());
+
+ Object data = elementData[pos];
+ /* if data is null, it is represented as null
+ * otherwise its toString() method is called
+ */
+ String data_as_string = (data == null) ? null : datatoString();
+ resultappend(data_as_string);
}
resultappend(]);
return (resulttoString());
* libraries/javalib/java/util/Vectorjava:
(elementAt) Updated exception message
(indexOf) Fixed NullPointerException
(toString) Fixed string conversion of nulls
[PATCH] Awt fixes
hi,
I am playing around with the examples from the Java Class Libraries
book for Java 10 :) I ran the Main example for javaawtComponent
and fixed the few issues I noticed in kaffe's libraries
It fixes some debugging output, some AWTEvent to Event conversion, and
adds a few simple new methods from Java 12 to Component
With the attached fixes, kaffe JDK 131 on i386 linux give almost
exactly the same debugging output The only difference is the width
height of the InputCanvas JDK 131 picks a different font - the
canvas has different dimensions
cheers,
Dalibor Topic
* libraries/javalib/java/awt/Canvasjava:
(counter) new variable Used to give canvases distinct default
names
(Canvas) set default canvas name in constructor
* libraries/javalib/java/awt/Componentjava:
(getX) new method
(getY) new method
(paramString) removed unnecessary Removed flags output in
parameter string Now uses 'x' to separate width from height
(postEvent) commented out event x and y coordinate increase since
it resulted in wrong x and y on example code
(toString) tweaked to JDK output format
* libraries/javalib/java/awt/Eventjava:
(paramString) now returns just the parameter string The output
has been tweaked to JDK's format
(toString) reimplemented according to spec
* libraries/javalib/java/awt/event/KeyEventjava:
(initOldEvent) set x and y coordinates of the converted event
diff -ur kaffe/libraries/javalib/java/awt/Canvasjava patched-kaffe/libraries/javalib/java/awt/Canvasjava
--- kaffe/libraries/javalib/java/awt/Canvasjava Tue Oct 12 04:29:38 1999
+++ patched-kaffe/libraries/javalib/java/awt/Canvasjava Thu Feb 28 21:03:50 2002
-16,11 +16,14
extends Component
{
final private static long serialVersionUID = -2284879212465893870L;
-
+ private static int counter;
+
public Canvas() {
// Canvases usually get their own update events, not being updated
// sync within their parents
flags |= IS_ASYNC_UPDATED;
+
+ setName(canvas + counter++);
}
ClassProperties getClassProperties () {
diff -ur kaffe/libraries/javalib/java/awt/Componentjava patched-kaffe/libraries/javalib/java/awt/Componentjava
--- kaffe/libraries/javalib/java/awt/Componentjava Wed Dec 19 23:21:34 2001
+++ patched-kaffe/libraries/javalib/java/awt/Componentjava Thu Feb 28 22:12:06 2002
-543,6 +543,14
return treeLock;
}
+public int getX() {
+ return x;
+}
+
+public int getY() {
+ return y;
+}
+
/**
* deprecated
*/
-903,10 +911,8
}
protected String paramString () {
- String s = + name + ',' + ' ' + x + ',' + y + ',' + width + ',' + height;
+ String s = name + ',' + x + ',' + y + ',' + width + 'x' + height;
- s += flags: + IntegertoHexString( flags);
-
if ( !isValid() ) s += invalid;
if ( !isVisible() ) s += hidden;
if ( !isEnabled() ) s += disabled;
-925,9 +931,12
evtrecycle();
return (true);
}
-
- evtx += cx;
- evty += cy;
+
+// Commented out since it doubles an event's x
+// and y coordinates with the Main example for javaawtComponent
+// from the Java Class Libraries book
+// evtx += cx;
+// evty += cy;
}
evtrecycle();
-1675,7 +1684,7
}
public String toString () {
- return (getClass()getName() + [ + paramString() + ']');
+ return (getClass()getName() + '[' + paramString() + ']');
}
/**
diff -ur kaffe/libraries/javalib/java/awt/Eventjava patched-kaffe/libraries/javalib/java/awt/Eventjava
--- kaffe/libraries/javalib/java/awt/Eventjava Sun Nov 25 21:52:00 2001
+++ patched-kaffe/libraries/javalib/java/awt/Eventjava Thu Feb 28 22:37:44 2002
-156,8 +156,8
}
protected String paramString() {
- return (javaawtEvent [ + target + , + id + , + arg +
- , + x + , + y);
+ return (id= + id + ,x= + x + ,y= + y + ,key= + key
+ + ,target= + target + ,arg= + arg);
}
public void recycle() {
-180,7 +180,7
}
public String toString() {
- return (paramString());
+ return getClass()getName() + '[' + paramString() + ']';
}
public void translate(int x, int y) {
diff -ur kaffe/libraries/javalib/java/awt/event/KeyEventjava patched-kaffe/libraries/javalib/java/awt/event/KeyEventjava
--- kaffe/libraries/javalib/java/awt/event/KeyEventjava Wed Jun 14 16:13:54 2000
+++ patched-kaffe/libraries/javalib/java/awt/event/KeyEventjava Thu Feb 28 22:35:20 2002
-270,7 +270,12
ewhen = when;
emodifiers = modifiers;
ekey = keyChar;
-
+
+ // we need to set x y coordinates too,
+ // since some events may be cached
+ ex = ((Component) getSource())getX();
+ ey = ((Component) getSource())getY();
+
return e;
}
Re: does kaffe support Java 3D?
#O#n!!#F#r#i#d#a#y#,!!#2#2#.!!#F#e#b#r#u#a#r#y!!#2#0#0#2!!#1#4#:#3#8#,!!#Z#h#u!!#W#e#n#z#h#a#n#g!!#w#r#o#t#e#:!v!v#N#o#t!!#a#s!!#f#a#r!!#a#s!!#I!!#k#n#o#w#.!!#T#o!!#e#f#f#i#c#i#e#n#t#l#y!!#i#m#p#l#e#m#e#n#t!!#J#a#v#a!!#3#D#,!v#y#o#u!!#n#e#e#d!!#t#o!!#a#t!!#s#o#m#e!!#p#o#i#n#t!!#i#m#p#l#e#m#e#n#t!!#t#h#e!!#3#D!!#r#e#n#d#e#r#i#n#g!v#u#s#i#n#g!!#a!!#3#D!!#t#o#o#l#k#i#t#.!!#I#'#m!!#n#o#t!!#a#w#a#r#e!!#o#f!!#a#n#y!!#i#m#p#l#e#m#e#n#t#a#t#i#o#n#s!!#t#h#a#t!v#w#o#r#k!!#w#i#t#h!!#k#a#f#f#e#,!!#e#s#p#e#c#i#a#l#l#y!!#n#o#t!!#o#f!!#a#n#y!!#f#r#e#e!!#i#m#p#l#e#m#e#n#t#a#t#i#o#n#s#.!v#B#u#t!!#t#h#a#n#,!!#I!!#h#a#v#e#n#'#t!!#l#o#o#k#e#d!!#r#e#a#l#l#y!!#h#a#r#d#,!!#s#o!!#y#o#u#r!!#s#e#a#r#c#h!!#m#i#g#h#t!v#l#e#a#d!!#y#o#u!!#t#o!!#b#e#t#t#e#r!!#r#e#s#u#l#t#s#.!v!v#Y#o#u!!#m#i#g#h#t!!#b#e!!#l#u#c#k#y#,!!#t#h#o#u#g#h#,!!#i#f!!#y#o#u!!#c#a#n!!#f#i#n#d!!#s#o#m#e#t#h#i#n#g!!#t#h#a#t!v#r#e#n#d#e#r#s!!#t#h#e!!#3#D!!#s#t#u#f#f!!#j#u#s#t!!#u#s#i#n#g!!#A#W#T#.!!#B#u#t!!#t#h#a#t!!#w#o#u#l#d!!#p#r#o#b#! a#b#l#y!v#b#e!!#w#a#y!!#t#o#o!!#s#l#o#w!!#f#o#r!!#p#r#a#c#t#i#c#a#l!!#u#s#e#,!!#e#v#e#n!!#w#i#t#h!!#k#a#f#f#e#.!v!v#Y#o#u!!#m#i#g#h#t!!#b#e!!#l#u#c#k#y!!#i#f!!#u#s#i#n#g!!#t#h#e!!#J#a#v#a!!#3#D!!#p#a#c#k#a#g#e!!#i#n!!#k#a#f#f#e!!#w#o#r#k#s!v#f#o#r!!#y#o#u#r!!#r#e#s#p#e#c#t#i#v#e!!#p#l#a#t#f#o#r#m#,!!#a#f#t#e#r!!#f#i#d#d#l#i#n#g!!#w#i#t#h!!#c#l#a#s#s#p#a#t#h#,!v#l#i#b#r#a#r#y!!#p#a#t#h#s!!#e#t#c#.!v!v#Y#o#u!!#m#i#g#h#t!!#b#e!!#l#u#c#k#y!!#a#n#d!!#f#i#n#d!!#s#o#m#e#t#h#i#n#g!!#t#h#a#t!!#w#o#r#k#s#.!!#I#f!!#s#o#,!!#p#l#e#a#s#e!v#t#e#l#l!!#u#s!!#:#)!v!v#G#o#o#d!!#l#u#c#k#!!v!v#D#a#l#i _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: how can i get kaffe through WWW?
Hi, --- ²ÜÓ¿ [EMAIL PROTECTED] wrote: i want to get kaffe through WWW,which site can i get it? You can get the source through www.kaffe.org. If you click on the AnonCVS link, you'll get to a page with detailed descriptions on how to get the latest bleeding edge source code from the CVS repository. If you need binaries, you should check your distribution's ftp servers or the mailing list archives for such announcements. Good luck :-) Dali = Success means never having to wear a suit __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
Re: [kaffe] Slow byte to char conversion
Am Die, 29 Aug 2000 schrieb Dalibor Topic: Is it not fair to assume that converting n bytes will result in less than or equal to n characters? For most of encodings that I've seen, it is a safe assumption. Unfortunately, I haven't seen 'em all :) I'm suspicious that it's possible to have a byte encode several characters. I digged around Unicode.org today, to see if I can find some interesting mappings from native character sets to Unicode which violate that assumption. I've found the Devagari and Farsi encodings from Apple. Here is an example from MacFarsi, the character set used to encode Persian. It's online at: http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/FARSI.TXT # For example, the mapping of 0x2B is given as LR+0x002B; the # mapping of 0xAB is given as RL+0x002B. If we map an isolated # instance of 0x2B to Unicode, it should be mapped as follows (LRO # indicates LEFT-RIGHT OVERRIDE, PDF indicates POP DIRECTION # FORMATTING): # # 0x2B - 0x202D (LRO) + 0x002B (PLUS SIGN) + 0x202C (PDF) So, in this case, a single Mac OS Farsi code point results in three Unicode characters. It can actually get even worse: # In the TrueType variant of Mac OS Farsi, 0xA4 is a ligature for the # currency unit "rial". This is mapped using the grouping hint followed # by the Arabic characters for "rial" # # (TrueType variant) 0xA4 - 0xF86B+0x0631+0x064A+0x0627+0x0644 Here you have a single code point encoded by five (5) Unicode characters. The grouping hint seems to be a vendor specific extension from Apple, though. That's still 4:1. Sun doesn't seem to have included any Farsi or Devangari conversion mechanisms, so kaffe doesn't really have to support such exotic encodings. But ... it may one day. So I'd recommend staying on the safe side. Dali _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [kaffe] Slow byte to char conversion
Hi Godmar,
Am Die, 29 Aug 2000 schrieb Godmar Back:
I was looking at this function in String.java:
private static StringBuffer decodeBytes(byte[] bytes, int offset,
int len, ByteToCharConverter encoding) {
StringBuffer sbuf = new StringBuffer(len);
char[] out = new char[512];
int outlen = encoding.convert(bytes, offset, len, out, 0, out.length);
while (outlen 0) {
sbuf.append(out, 0, outlen);
outlen = encoding.flush(out, 0, out.length);
}
return sbuf;
}
Why can't this function be rewritten to read:
private static StringBuffer decodeBytes(byte[] bytes, int offset,
int len, ByteToCharConverter encoding) {
char[] out = new char[len];
int outlen = encoding.convert(bytes, offset, len, out, 0, out.length);
return new StringBuffer(outlen).append(out, 0, outlen);
}
Is it not fair to assume that converting n bytes will result in less than
or equal to n characters?
For most of encodings that I've seen, it is a safe assumption.
Unfortunately, I haven't seen 'em all :)
I'm suspicious that it's
possible to have a byte encode several characters. And here is why:
Unicode supports "combining" characters. These characters are used to
modify other characters. For example, you can add accents to
normal characters. Since Unicode is designed to allow easy conversion
to/from existing character sets, it includes many precomposed
characters, like the german umlauts ä,ö,ü. You'd still need combining
characters to fully represent some scripts, like Thai. Markus
Kuhn says in his "UTF-8 and Unicode FAQ for Unix/Linux" [1] : "with
the Thai script, up to two combining characters are needed on a single
base character. "
In his article on "Forms of Unicode" [2], Mark Davis shows some of the
myths about characters vs code points vs code units. It features a
table with some unexpected things. There is an encoding for the fi
ligature, for example [3]. Some arabian characters' Unicode
representation depends on the context. Some characters require
several Unicode characters to be represented properly: "The Devangari
syllable ksha is represented by three code points."
I haven't seen an encoding for Devangari, so I don't know whether the
encoding for "ksha" would be less than three bytes. I've seen other
encodings (doing research for this post today), collected by Mark
Leisher as a supplement to the official Unicode conversion tables. And
some of them, like I3342, encode a single byte into several characters
[4]. I don't think any of these encodings is supported by Sun's JDK 1.3,
though.
To sum it up: I'm not convinced. I guess taking a look at GNU
libc iconv functionality should provide some more insight, but I don't
have the sources around right now. The GNU libc folks have done a
massive job supporting a variety of encodings, so this might be another
direction to look for advice..
Read ya,
Dali
[1] http://www.cl.cam.ac.uk/~mgk25/unicode.html
[2] ftp://www6.software.ibm.com/software/developer/library/utfencodingforms.pdf
[3] \uFB01 according to Unicode-Data-3.0.txt
[4] 0xA4 - 0x0631 0x064A 0x0627 0x0644 for PERSIAN RIAL SIGN
__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Re: [kaffe] Slow byte to char conversion
Hi Godmar,
sorry for the delay, but I was on holidays last week, and away from my
mail.
Am Sam, 19 Aug 2000 schrieben Sie:
From what I understand, and someone correct me if I'm wrong,
there shouldn't be any reason not to include the change you suggest -
if someone implements it, of course.
Done. I have a patched version of Encode.java. I 'll
clean it up when a definite solution has stabilized.
If I understand your proposal right, you'd use an array for
the first 256 values and a hashtable or something like that
for the rest. I don't think there would be a problem with changing
it so that it would both serialize an array and a hashtable.
One or two objects in *.ser shouldn't make a difference.
Yes. It should work nicely for ISO-8859 based encodings, and
then for some.
Actually, for byte to char conversion you don't even
need a hash table, since all ISO-8859-X assign unicode chars
(simply speaking) to byte values in the range 0-255.
For the reverse way (char to byte conversion) I'd need to do some
experiments to figure out a better way. In most character to byte
encodings, there is no single range from character x to character y
where all characters are mapped from. So the array based approach is
space-inefficient. A combination of arrays and hasmaps might be
interesting. But for the time being, I'm playing around with
java.io.InputStreamReader, so I'm trying to fix byte to char conversion
first.
You could even stick a flag at the beginning if the array shouldn't
pay off for some encodings.
I'd prefer a more class hierarchy based approach. We already have
kaffe.io.ByteToCharHashBased. We could have ByteToCharArrayBased, too.
Something like this (warning: untested code ahead):
abstract public class ByteToCharArrayBased extends ByteToCharConverter {
// map is used to map characters from bytes to chars. A byte
// code b is mapped to character map[b 0xFF].
private final char [] map;
public ByteToCharArrayBased ( char [] chars) {
map = chars;
}
public final int convert (byte[] from, int fpos, int flen,
char[] to, int tpos, int tlen) {
// Since it's a one to one encoding assume that
// flen == tlen.
for (int i = flen; i 0; i --) {
to[ tpos++] = convert( from [ fpos++ ]);
}
return flen;
}
public final char convert (byte b) {
return map[b 0xFF ];
}
public final int getNumberOfChars(byte [] from, int fpos, int
flen) {
return flen;
}
}
Now a (byte to char) conversion class has three choices:
a) it uses all byte values from 0-255 - it extends
ByteToCharArrayBased, and makes the constructor use the
appropriate char array.
b) the encoded byte values are sparsely distributed through the range
of all legal byte values - it extends ByteToCharHashBased due to
its space efficiency.
c) there is a huge block of bytes used in the encoding, but there are
also many bytes outside that block's range used in the encoding - it
extends ByteToCharConverter and uses fields for ArrayBased as well
HashBased conversion. The convert method checks whether a byte is
within the block and uses the array, or uses the hash table otherwise.
From my experience (converting ISO-8859-X encodings from being hash
based to being array based), for byte to char conversion option (a)
takes little memory (256 chars for the table) and is very fast. As I
explained in my previous post, it beats option (b) in time-efficiency.
I suppose it beats it in space-efficiency as well, as long as most
bytes are convertable into characters.
When there are only a few lagal byte values, which can be encoded into
characters, the hash based conversion could be more space-efficient. On
the other hand, the array based implementation doesn't waste much
memory in that case. Even in the worst case, a fictive encoding that
solely uses a specific single byte to encode some character, there are
255 * 2 = 510 bytes wasted. That's not much, and can be improved upon,
by introducing range checks and similar techniques.
The choices really start to matter when you're going the other way
round, from chars to bytes. Take a look at ISO-8859-8 (a.k.a. hebrew).
It encodes 220 characters. Of these 220, only 32 are *not*
mapping a byte value to itself. They are either mappings into the
range between \u05D0 and \u05EA, mappings within the first 256
characters, or mappings to a few special characters like LEFT-TO-RIGHT
MARK.
One would have to see what the actual sizes of the
.ser files would be; keeping those small is certainly desirable. From
what I understand, they're more compact than any Java code
representation. Edouard would know more since he wrote that code, I
think. On a related note, this whole conversion thing stinks.
Why can't people stick to 7-bit ASCII? For instance, the JVM98 jack
benchmark
Re: [kaffe] Slow byte to char conversion
Am Mon, 28 Aug 2000 schrieb Artur Biesiadowski: And why exactly default converter could not be cached and same instance used for all conversions ? I think it is stateless class, so it should be safe to enter same object method from various threads with all state on stack. It depends on the encoding. Let's say you have a multibyte encoding, where several bytes encode a single character, like UTF-8 [1]. You can't guarantee that all the byte arrays that you want to encode into char arrays terminate on character boundaries. So you need to be able to save the state of your converter and pick up at the position where you left next time your converter is called. Imagine that you're reading in a UTF-8 encoded file, and get an IOException while you're reading it. You convert as much as you've read, but you can't decide on the last character, since your stream has been interrupted. The UTF-8 converter saves its state, and waits for bytes to convert to characters. Now, imagine another thread tries to do some UTF-8 input conversion, too. If it used the first converter, it would get a corrupted result, since the first converter is still waiting for bytes to continue converting. So you have to use a fresh UTF-8 converter for that. You could say: "So? Kaffe uses ISO-Latin-1 as default encoding. That's stateless.". But unfortunately the default encoding comes from the file.encoding system property, which can be changed by the user [2]. Don't rely on the default encoding being ISO-Latin-1. Kaffe does some sort of caching already, but it instantiates a new converter every time one is needed, which is not necessary for stateless converters, as you've pointed out. [1] If you have a Linux installation around, take a look at /usr/share/i18n/charmaps/UTF8. It might have a slightly different name on your installation, though, since character encodings usually have several aliases. [2] Well, sort of. While Java 2 allows system properties to be set, kaffe has not caught up with that yet, as far as I know. So the only way I know of to change the default encoding is to modify it in libraries/clib/native/System.c and recompile kaffe. __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
[kaffe] Slow byte to char conversion
Hi, I wrote a simple program to show a Java charmap ( something like Encode.java in developers directory). It essentially creates a byte array with size 1, and creates a string with the appropriate Unicode char using the encoding in question for every value a byte can take. When displaying a serialized converter like 8859_2, the performance is very bad. Comparing current kaffe from CVS running on SuSE Linux 6.4 with jit3 and IBM's JRE 1.3 running in interpreted mode, kaffe is about 10 times slower. While I consider the idea to use serialized encoders based on hashtables a great one, it is very inefficient for ISO-8859-X and similar byte to char encodings. These encodings use most of the 256 possible values a byte can take to encode characters, so I tried using an array instead. I achieved comparable running times to JRE 1.3. Why was the hashtable based conversion chosen over alternatives (switch based lookup, array based lookup)? Dali = "Success means never having to wear a suit" __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/
Re: missing files, while compile Kaffe
Am Die, 15 Aug 2000 schrieb Alexandre Oliva: On Aug 14, 2000, Mansuroglu Seki [EMAIL PROTECTED] wrote: - cd to 'd:\cygwin\kaffe\kaffe\kaffe' Wrong. Run make in the same directory in which you run configure. Or you could always try using the latest CVS sources. I think there was a glitch in the Klasses.jar for 1.06 that prevented me from succesfully building kaffe. hope this helps, Dalibor Topic __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
[kaffe] Klasses.jar compilation problems
Hi, I think I've found the reason why latest kaffe from CVS won't let me recompile my classes anymore. Although all regression tests work just fine, when I try to make Klasses with kjc 1.4F-egp1, I get: Could not initialize Kaffe. Your Klasses.jar version is 1.06, but this VM was compiled with version 1.05 The current effective classpath is `.:/home/javauser/Projects/Workbench/kaffe/libraries/javalib/Klasses.jar:/home/javauser/Projects/Workbench/kaffe/libraries/javalib/kjc.jar' make[1]: *** [lib/stamp] Error 255 make: *** [Klasses] Error 2 That's irritating, since kaffe/libraries/java/lang/Cloneable.java sets KAFFE_VERSION to 106. Unfortunately, when generating the includes, kaffeh sets KAFFE_VERSION to 105. Since Cloneable.java is younger than Klasses.jar, I assume that recompiling Klasses.jar should do the trick. Bye, Dalibor Topic __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Kaffe's java compiler needs an update
Hi,
I've spent some time chasing a bug around which in the end turned out
to be a kjc 1.4D bug. It doesn't appear with kjc 1.4F, so I'd recommend
upgrading Kaffe's kjc.jar to 1.4F.
The bug in question shows up when you compile Klasses.jar with Kaffe's
kjc and try to read() a file until EOF. It won't work, because
java.io.Reader read() method returns 65535 instead of -1 on EOF. kjc
1.4D gets confused about the type of -1 (int/char) at line 43 in
java/io/Reader.java:
return read(single, 0, 1) 0 ? -1 : single[0];
Here's a small test program that exposes the bug:
public class Main {
private static int cnt = 0;
private static char [] c = new char[1];
public static void main(String [] args) {
System.out.println(test());
}
public static int test() {
c[0] = 'X';
return cnt % 2 == 0 ? -1 : c[0];
}
}
Running JDK 1.1.8 javap on the kjc 1.4D generated class file results in following
output for method test():
Method int test()
0 getstatic #30 Field char c[]
3 iconst_0
4 bipush 88
6 castore
7 getstatic #32 Field int cnt
10 iconst_2
11 irem
12 ifne 18
15 ldc #33 Integer 65535
17 ireturn
18 getstatic #30 Field char c[]
21 iconst_0
22 caload
23 ireturn
which is clearly wrong (byte 15 should be iconst_m1).
kjc 1.4F generates the iconst_m1 instead.
Although you could give a hint to kjc 1.4D how to compile the above
example properly, by casting c[0] to int, I propose to update the
compiler. Unless, of course, there are other issues that prevent us
from doing so.
Bye,
Dalibor Topic
__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Another Thread.stop() issue
Hi,
I've got a bit of follow-up on Jason's Thread.stop() message. I've found a
bug in Kaffe's Thread.stop(Thowable object) method. The following code, legal
under Java 1.1, 1.2 and 1.3 exposes it:
---ThreadStop.java---
class Runner extends Thread {
public void run() {
try{
//Sleep for a while
sleep(1);
}
catch (InterruptedException _) {}
}
}
class ThreadStop {
static public void main(String[] argv) {
Runner u = new Runner();
// start runner thread
u.start();
try {
Thread.currentThread().sleep(1000);
}
catch (InterruptedException e) {
e.printStackTrace();
}
u.stop(new Exception("Success."));
try {
Thread.currentThread().sleep(1000);
}
catch (InterruptedException e) {
e.printStackTrace();
}
System.exit(0);
}
}
---cut!---
r
unning it with JDK 1.1.7 on Linux gives me:
$ java ThreadStop
java.lang.Exception: Success.
running it with lates kaffe from CVS gives me:
$ kaffe ThreadStop
java.lang.ClassCastException: can't cast `java/lang/Exception' to `java/lang/Error'
at java.lang.Thread.waitOn(Thread.java:473)
at java.lang.Thread.sleep(Thread.java:364)
at Runner.run(ThreadStop.java:7)
If you take a look at the code, you'll see death being cast to an Error
object, which can be thrown without requiring special declaration. On the other
hand, the stop(Throwable) method can receive any kind of throwable object, so
it seems to be a bug to cast it to an Error.
I tried to fix the this with some obvoiues fixes (remove death altogether,
allways use stop0) but unfortunately I couldn't get it to work. I kept getting
this:
java.lang.IllegalMonitorStateException
at java.lang.Thread.sleep(Thread.java:364)
at Runner.run(ThreadStop.java:23)
So I decided to leave it up to the great threading hackers to fix the things :)
Have some fun,
Dali
__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Re: Thread.stop()
On Mon, 22 May 2000, Jason Baker wrote:
Mo DeJong [EMAIL PROTECTED] writes:
I was under the impression that methods like Thread.stop() were
removed from the JDK or replaced with no-ops. I seem to remember
that they were never implemented in Netscape's JVM. The whole
concept of stoping a thread seems like a bad idea, a thread
should expire due to natural causes.
There is (or was, I have the docs for a JDK 1.3 beta) a nice document
explaining the various issues on thread stopping linked from the
method summary of java.lang.Thread. It is called "Why Are Thread.stop,
Thread.suspend, Thread.resume and Runtime.runFinalizersOnExit Deprecated?", and
should be the file jdk1.3/docs/guide/misc/threadPrimitiveDeprecation.html in
the JDK 1.3 documentation. Essentially, it makes the point, that unless you
really, really know what you're doing, Thread.stop() leaves your objects in a
damaged state, and leads to unleasant surprises.
Thread.stop(Throwable) is even worse: in addition anyone can pass any exception
to your thread, even exceptions it's not prepared to catch ...
There is an implementation of Thread.stop and other deprecated Thread methods
in the JDKs, it's just marked deprecated since JDK 1.2.
In Peter Haggar's "Practical Java" he talks about thread stopping in praxes 57
58, and essentially recommends the same things Sun does: don't use
Thread.stop(). If you have to do stop threads, use polling on a volatile
variable (since threads can copy local variables), or use synchronized methods
to access it. If the stop variable is true, then clean up your resources, put
the object in a safe state, and exit via the Thread.run method(). The
disadvantage is: the thread does not stop immediately, it has to read the stop
variable first.
If that's an issue, like for threads that wait for a long period, than you
should additionally use interrupts. There are examples of all that in Sun's
document described above.
Thread.stop is dangerous, but without a process model there is really
no alternative. I'm using it to halt infinite loops, which is why I
need the stack trace.
I'd say, try to use polling. Something like this should do it:
class InfiniteLoopThread extends Thread {
private volatile boolean quit;
public void stop() {
quit = true;
}
public void safeStop(Throwable t) {
quit = true;
// if you need the stack trace
// to see who stopped the thread
t.printStackTrace();
}
public void run() {
while (!quit) {
// your infinitely looping code
}
// oops! turned out to be finitely looping!
// do the clean up.
// dump the stack trace
// if you still need it
this.dumpStack();
}
}
Both Godmar and Pat use Thread.stop to implement safe termination, so
given that it is part of Kaffe, what should the call do?
According to the JDK 1.3 API documentation the Thread.stop() method should look
something like this:
public void stop() {
SecurityManager sm;
sm = System.getSecurityManager())
if(sm) {
sm.checkAccess(this);
if(this != currentThread()) {
sm.checkPermission(new RuntimePermission("stopThread"));
}
}
throw (new ThreadDeath());
}
Thread.stop(Throwable) should be very similar.
There is one thing that the JDK 1.3 documentation says about printing stack
traces:
The top-level error handler that reacts to otherwise uncaught exceptions does
not print out a message or otherwise notify the application if the uncaught
exception is an instance of ThreadDeath.
I think your 'Die' code shows a bug or two in the JDK 1.2.2 and JDK 1.1.7. It
should generate stack traces since you're throwing Errors around, not
ThreadDeaths. Unless of course, Sun's JVM generally doesn't print stack traces
on Errors or Throwables, but I haven't found anything supporting that in the
documentation for java.lang.Error or java.lang.Throwable.
Last time I looked at Kaffe's threads, it didn't do
the SecurityManager checks, so Kaffe is not 'fully compliant' with JDK 1.3
specification (or 1.2, for that matter) either.
hope this helps,
Dali
__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Re: Regression Test failures in current CVS
--- Alexandre Oliva [EMAIL PROTECTED] wrote: On Jan 14, 2000, Dalibor Topic [EMAIL PROTECTED] wrote: Try to unset it, or to set it to C. I think en_US disregards case. We should probably arrange to set LANG=C in TestScript, if it is set to something else, if this solves the problem. Actually it was LC_ALL ... after setting it to C everything worked fine. Thanks for your help, Alexandre. Adding a LC_ALL=C in the TestScript would be nice, it is not set there at all. read ya, dali = "Success means never having to wear a suit" __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: A small java.io bugfix
--- Dalibor Topic [EMAIL PROTECTED] wrote: Hi, attached you'll find a patch for current CVS version of Kaffe. [SNIP] Appropriate regression tests are in the works. Done. Attached to this e-mail is a unified diff to the current cvs version of Kaffe of the file Makefile.in in the directory kaffe/test/regression/ to include the attached 6 test files. They demonstrate the bugs. The tests pass under JDK 1.2 happy checking in, dali = "Success means never having to wear a suit" __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com diff tests.tar.gz
Re: Bytecode verifier
--- Tim Wilkinson [EMAIL PROTECTED] wrote: but before I go off and write a real one I'd like to know whether I'm simply reinventing the wheel - is there an Open Source Java bytecode verifier anywhere in the world? NPL'd : Electrical Fire's Byte Code Verifier http://lxr.mozilla.org/ef/source/ef/Compiler/FrontEnd/ Cheers, dali = "Success means never having to wear a suit" __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
A small java.io bugfix
Hi, attached you'll find a patch for current CVS version of Kaffe. This one fixes: * kaffe/libraries/javalib/java/io/BufferedReader.java The default size of the buffered reader did not match Sun's. The JDK 1.2 documentation doesn't say anything about it besides "The buffer size may be specified, or the default size may be used. The default is large enough for most purposes." On the other hand I found a reference in "The Java Class Libraries, Second Edition, Vol 1", at p 193, saying: "There are two forms of the constructor for *BufferedReader*. The first form constructs for the reader *in* a buffered reader that has the default buffer size of 8K characters." So I fixed that ... * kaffe/libraries/javalib/java/io/Reader.java method mark(int readAheadLimit): According to The Java Class Libraries, Second Edition, Vol. 1, the method mark(int readAheadLimit) in the class Reader should throw an IOError in the default implementation. Our version doesn't do anything, so of course it doesn't throw the required IOException. I also made it throw the IOException with the same message as Sun's JDK 1.2 does. method read(): There is a possible race condition when two threads use the same Reader and both try to read() at the same time. Imagine the following situation: A class PseudoReader inherits form Reader and implements the abstract methods close() and read(char [], int, int) In its read implementation, it uses locking based on the inherited class variable lock, while it writes character into the buffer, so that's alright. Thread A calls read(), which in turn calls read(single, 0, 1), and gets character 'a' stored into inherited class variable single, but gets interrupted after it has released the lock and before it could return from the function read(char [], int, int) Thread B goes into action and calls read() on the same PseudoReader, and gets character 'b' stored into single. It returns 'b' happyly. The inherited class variable single[0] == 'b' now. Thread A continues and returns from the read function as well. Unfortunately, its call to read() returns 'b', which is wrong. (According to JDK 1.2 behaviour, and "The Java Class Libraries, Second Edition, Vol 1" documentation for Reader.lock) method ready(): It should return false by default and not true, according to JDK 1.2 behaviour, and "The Java Class Libraries, Second Edition, Vol 1". method reset(): I've made it throw the same message the JDK does. method skip(long n): skip did not block until some characters are available. * kaffe/libraries/javalib/java/lang/Thread.java method toString(): fixed it to produce the string in the same format the JDK does. Appropriate regression tests are in the works. happy checking in, dali = "Success means never having to wear a suit" __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com diff
Another Bugfix patch for java.io.StreamTokenizer
Hi,
here is a new patch for java.io.StreamTokenizer fixing a bunch of bugs and
glitches.
Bugs that are fixed with this patch:
* when parsing numbers, a '-' alone without following numbers should be an
ordinary character, not a string. Reference: Java Language Specification.
* when parsing numbers, a single '.' should evaluate to 0.0
. Reference: Sun JDK 1.1.x/1.2.x behaviour.
* when parsing numbers, a single "-." should evaluate to -0.0
. Reference: Sun JDK 1.1.x/1.2.x behaviour.
* it was possible to set characters 255 or characters 0 to whitespace
chars, or to word chars, resulting in a corrupted TableEntry ordinary,
which is used for non ASCII characters. Setting it white space led to the
character -1 (EOF) being interpreted as white space, thus Kaffe would hang
on input forever. Reference: The Java Class Libraries Second Edition
Vol. 1, StreamTokenizer wordChars etc. method descriptions
* there was a bug when parsing numbers in streams that were something like
.4.4.4, Kaffe wouldn't stop before the second '.' Reference: Java Language
Specification
* when parsing quoted strings, kaffe wasn't able to handle octal escape
sequances. Reference: Java Language Specification
* when EOL was pushed back, the line number wasn't decreased so the last
token before the EOL had the wrong line number (too high).
* when parsing C or C++ comments and when / is not a comment character,
kaffe would drop the / in /4
* line numbers used to be wrong if the parsed quoted string contained
escaped EOL characters like in "\\\n"
* skipLine would be stuck in an infinite loop if the line ended
with an EOF instead of an EOL
* when parsing quoted strings, Kaffe would drop the newline if the string
ended prematurely
* when parsing numbers, Kaffe would try to parse 1.2- as a number instead
of parsing 1.2 as a number and - as an ordinary character.
Other things fixed:
* private class variable pushBack has the value false by default, so I
modified its declaration accordingly
* besides the three cases described ("-", "." and "-."), there should be
no other exceptions in number generation [1], thus I have removed the code
that would set ttype to TT_WORD and return a string with the number that
could not be parsed.
* I removed some code to handle EOL that was redundant in nextTokenType.
* with all the necessary modifications to make StreamTokenizer more
standard Java like, nextTokenType grew to big and I've split it into
several small functions. The semantics of the function should be clearer
now.
* I also changed the return type from nextTokenType to void, that allowed
to simplify nextToken, as well as to eliminate all the labourous token
type passing between nextToken, nextTokenType and token-type-specific
parsing functions.
Things to fix:
* The LineNumberReader eats \r ... so we don't see "\\\r" in a string as
"\\\r" but as "\\\n" .
* The numbers parsed are sometimes just a little different from what they
should be. For example, .4 comes out as n=0.40002, instead of
n=0.4 .
Attached is an example test program for your Kaffe breaking pleasure :),
and the diffs to the current CVS. If you run the test program with Kaffe
and with Sun's JDK 1.1.x/1.2.x you'll see that we are getting closer :))
Functions that were modified are:
java.lang.StreamTokenizer.chrRead
java.lang.StreamTokenizer.unRead
java.lang.StreamTokenizer.nextToken
java.lang.StreamTokenizer.nextTokenType
java.lang.StreamTokenizer.ordinaryChars
java.lang.StreamTokenizer.skipLine
java.lang.StreamTokenizer.whitespaceChars
java.lang.StreamTokenizer.wordChars
Functions that were added are:
java.lang.StreamTokenizer.parseWhitespaceChars
java.lang.StreamTokenizer.parseNumericChars
java.lang.StreamTokenizer.parseAlphabeticChars
java.lang.StreamTokenizer.parseCommentChars
java.lang.StreamTokenizer.parseStringQuoteChars
java.lang.StreamTokenizer.parseCPlusPlusCommentChars
java.lang.StreamTokenizer.parseCCommentChars
java.lang.StreamTokenizer.parseOctalEscape
Cheers,
dali
[1] Really huge numbers that can not be entirely represented in a double
are represented as infinity, according to Sun JDK 1.1.x behaviour.
import java.io.*;
class StreamTokenizerTest {
public static void main (String argv[]) {
//check the values of constants
// StreamTokenizer st = new StreamTokenizer(System.in);
StringBuffer testBuffer = new StringBuffer();
int i = 0;
// Create octal strings galore.
// The highest octal number converted to string is
// \377 which is equal to 255 decimal.
// Generate some more to test for correct behaviour
// with higher octals as well.
testBuffer.append('"');
for (i = 0; i = 300; i++) {
testBuffer.append('\\');
testBuffer.append(Integer.toOctalString(i));
}
// Insert a newline escape sequence to be parsed.
// makes the output look better
