Re: Bug tracker link
Looks like I missed a post. What shall the correct link be? Thanks, Patrik --On Mittwoch, 23. März 2005 21:26 +0100 Mark Wielaard [EMAIL PROTECTED] wrote: Hi, On Wed, 2005-03-23 at 20:20 +0100, Dalibor Topic wrote: I just noticed that the bug tracker link on the classpath page points to the Savannah one, and directed someone to put a bug report in there, istead of directing them to the gcc bug tracker. Mea culpas aside, should the link on www.classpath.org be changed to point to the new bug tracker? We haven't moved the bugs yet. I hope it can be done end of next week. I will contact the gcc bugmasters again. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath 0.14 released
Sorry, I'll try to update this tonight. -Patrik --On Freitag, 18. März 2005 10:02 +0100 Thomas Zander [EMAIL PROTECTED] wrote: Ehm.. 0.14 again? [1] Perhaps you should update the download page more often? http://www.gnu.org/software/classpath/downloads/downloads.html Cheers! 1) http://lists.gnu.org/archive/html/classpath/2005-02/msg00109.html -- Thomas Zander ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Documentation generated with gjdoc
--On Dienstag, 11. Januar 2005 23:34 +0100 Mark Wielaard [EMAIL PROTECTED] wrote: Hi, On Tue, 2005-01-11 at 04:16 -0500, David Gilbert wrote: Mark Wielaard wrote: Will this be available from a link on the GNU Classpath homepage? The idea is to have the documentation of the latest released versions actually on http://www.gnu.org/software/classpath/ en keep the version on developer.classpath.org as our moving target (daily build when we switch to a new server). Putting stuff on www.gnu.org is a bit difficult since the last compromise of the gnu.org servers. Anything not going through savannah CVS has to go through an admin. But I hope that when 0.14 is released we can give them the finalized doc.tar.gz to upload. Well, for the time being and temporarily, I've added a link from the http://www.classpath.org/docs/docs.html to the doc on developer.classpath.org Once the release doc is uploded, I will switch or even better, keep two links (last release and current code). -Patrik ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Sleeping at FOSDEM
Hi! just to say that this year I won't attend FOSDEM; I really would like to, but I'm in California till the end of march. -Patrik --On Freitag, 14. Januar 2005 17:53 + Robert Lougher [EMAIL PROTECTED] wrote: Hi, Are many people from the runtimes going? I really enjoyed it last year, and I'd like to go again this year. Rob. On Fri, 14 Jan 2005 18:19:47 +0100, Arnaud Vandyck [EMAIL PROTECTED] wrote: Thu, 13 Jan 2005 10:32:41 +0100, Sascha Brawer [EMAIL PROTECTED] wrote: Sounds pretty cool. Actually, who is going to FOSDEM? May ex-classpath-hackers-gone-lurking come, too? Good to hear you Sascha! Of course you are welcome! ;-) -- Arnaud Vandyck ,= ,-_-. =. ((_/)o o(\_)) `-'(. .)`-' \_/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
cvsignore files
Hi! I just noticed that most of the cvsignore files where removed. Now, when checking for changed files (e.g. cvs -n -q upd) all the Makefile and Makefile.in show up though they are not meant to be in the cvs. What was the reason for removing them? -Patrik ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: classpath 0.10 and GCJ Version 3.3.3 20040215
Michael Koch programmed a nightly build executed every night, which is compiled with jikes 1.16. on a Suse 8.1 machine (with a few patches) Maybe this could be extended to use more compilers and versions thereof? -Patrik --On Mittwoch, 21. Juli 2004 09:10 +0200 Mark Wielaard [EMAIL PROTECTED] wrote: Hi Steve, On Tue, 2004-07-20 at 23:27, Steven Augart wrote: I just accidentally tried to build Classpath 0.10 using GCJ (I was using an AIX machine, and I'd left Jikes out of my path). The GCJ version is: gcj (GCC) 3.3.3 20040215 (release) This gave the error: /usr/gnu/bin/gcj --bootclasspath '' --classpath ../../classpath-0.10:../../classpath-0.10/external/jaxp/source:../v m/current:.: -C -d . @classes ../../classpath-0.10/java/security/cert/X509Certificate.java:143: error: Class `java.security.cert.X509Certificate' can't subclass interface `java.security.Certificate'. public abstract class X509Certificate extends Certificate implements X509Extension The configure script currently tests whether GCJ, if used, has at least version 3.3. This doesn't seem to be adequate to get around the error. Does anybody know what version of gcj we need to avoid this complaint? We should update the configure script appropriately. The release was tested against gcj (GCC) 3.3.4 (Debian 1:3.3.4-3) and gcj CVS. Hopefully 3.3.4 is enough. But I see that Debian actually includes a couple of patches for the compiler... One of which looks like it was for the above issue. Darn. So you might actually need the 3.4 FSF release. The official policy is to make sure that the java source files can be compiled against the latest official releases of gcj and jikes. (So if gcj 3.4 and/or jikes 2.21 don't work, we have a bit of a problem.) But in practice (in my case) this often means the last releases of gcj and jikes in Debian. We do have a problem in any case since at least the INSTALL/hacking-guide document doesn't explicitly say that (and the configure script version check could indeed be updated). Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Q: How do you keep your sources in synch?
Hi, I'd like to add this topic to the FAQ, thus I'm looking for hard evidence on this topic. I was wondering, how the various VM deal with changes in the classpath code (I assume you have a customized version of classpath). Are you importing them by hand or rely on some automated tool? Before being able to use classpath out of the box, I relied on cvs (cvs import and cvs checkout -jOLDVERSION -jNEWVERSION), which worked well as long as the differences were not to big. What is your experience? -Patrik ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Bad link for 0.08 download?
Hi Stephane, you are right! The file was renamed. (Anyone know more?) Have a look into ftp://alpha.gnu.org/gnu/classpath/ for the released files. Classpath is released on the alpha server, because is still heavily under development. -Patrik --On Montag, 5. April 2004 09:47 +0100 S. Meslin-Weber [EMAIL PROTECTED] wrote: Hi guys, I tried downloading classpath-0.08.tgz from the downloads page last night and it looks like the URL is pointing to the alpha gnu ftp site. Shouldn't that be poiting to the regular gnu ftp site? Thanks, Stephane ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Bad link for 0.08 download?
ok, I'm sorry for the confusion. I'll update the download page accordingly. -Patrik --On Dienstag, 6. April 2004 00:07 +0200 Mark Wielaard [EMAIL PROTECTED] wrote: Hi, On Mon, 2004-04-05 at 23:46, Patrik Reali wrote: you are right! The file was renamed. (Anyone know more?) Have a look into ftp://alpha.gnu.org/gnu/classpath/ for the released files. Classpath is released on the alpha server, because is still heavily under development. No sorry. I thought I had announced it clearly. But obviously I didn't. Since 0.08 the snapshot releases are only hosted on ftp.gnu.org. We now only put test releases on alpha.gnu.org. alpha.gnu.org doesn't keep backups and although we see the GNU Classpath snapshots as works in progress it seems people do rely on them. So from now on we put them on ftp://ftp.gnu.org/gnu/classpath/ to make sure they are mirrored and backed up. The 0.08-test1 release found on alpha is indeed just a test release made a few days before the real 0.08 release. Cheers, Mark P.S. This is also the reason we don't have any official pre 0.06 releases anymore. They were never backed up and nobody had the official old release files anymore. We could regenerate them from CVS of course, but nobody bothered to do that. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
--On Samstag, 27. März 2004 21:00 -0500 Etienne Gagnon [EMAIL PROTECTED] wrote: Note to Patrik: I thought you would have noticed, by now, that I was only trying to tell about a subset of the VMs that use Classpath without using 10 words. (See other messages for a better description). I used normal as in normally built. I did not intend to say better or worse. Hi Etienne, I want to apologize to you if my comment offended you; it was not meant that way. -Patrik ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Classpath is not meant to live on its own; it is either meant to be used as a class library for a compiler (e.g. jikes), or as a class library for a virtual machine (gcj, JikesRVM, SableVM, Kaffe, ...). So, I suggest to change the configure.ac to force ./configure to require a --with-vm=xxx option. In other words, there would not be a default Classpath configuration. The motivation is that when a user builds a Classpath version, he intends to use it in some context. There is no default set of options that would work for all possible uses of Classpath. In fact, each possible default configuration would favor one VM or one compiler over the others. This doesn't apply to Jaos: it uses Classpath out of the box; some methods are overridden by an Oberon implementation, but it still requires the java class in the beginning. There seems to be at least 4 VM whose configuration corresponds to the current default configuration I think this defeats the purpose of being a library for all VM and compilers around, and raises the entry barrier for new ones. The objective: Share as much code between normal VMs (that need nothing really special in base classes), and intuitive source file locations. Sharing is possible only when this code written in java, because this is the only common denominator all VM use! And how do you define normal anyway? Only technology that is at least 20 years old? -Patrik Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
[Article] The Future of OSS Desktop Development: Java, Mono, or C++?
Sorry for keeping you from your productive work, but one recent article Java, Mono, or C++ referenced in OSNews is quite interesting and detailed. It mentions GNU Classpath, GCJ, and IKVM. The article Java, Mono, or C++: http://ometer.com/desktop-language.html The OSNews news item and discussion around it: http://www.osnews.com/story.php?news_id=6379 Cheers, Patrik Patrik Reali http://www.reali.ch/~patrik/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Java Security classes available
Hi, I'll take care of this. -Patrik Patrik Reali http://www.reali.ch/~patrik/ --On Sonntag, 14. März 2004 11:15 +0100 Ewout Prangsma [EMAIL PROTECTED] wrote: Hi all, In JNode (a Java OS using a derived classpath version) we've implemented the Java Security architecture. During the implementation several bugs in classpath have been fixed. If you need them, feel free to get them from our CVS server (http://cvs.sourceforge.net/viewcvs.py/jnode after a SF delay) or contact me. The following classes have been fixed / created gnu.java.security.PolicyFile gnu.java.security.actions.GetBooleanAction gnu.java.security.actions.GetIntegerAction gnu.java.security.actions.GetPropertiesAction gnu.java.security.actions.GetPropertyAction gnu.java.security.actions.GetPolicyAction gnu.java.security.actions.InvokeAction gnu.java.security.actions.SetPropertyAction java.awt.Toolkit java.io.FilePermission java.net.SocketPermission java.security.CodeSource java.util.TimeZone java.util.Locale java.util.PropertyPermission The implementation of the access control itself can be found in: org.jnode.vm.VmAccessController org.jnode.vm.VmAccessControlContext Regards Ewout ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Query on stacktrace management logic
--On Sonntag, 7. März 2004 16:02 +0100 Chris Gray [EMAIL PROTECTED] wrote: On Thursday 04 March 2004 09:01, Jeroen Frijters wrote: David Holmes wrote: class Class is the first class that must be initialized [...] Given the wide variety of VMs that use Classpath, I'd be careful with statements like these. For almost every such assumption there will be a VM for which it isn't true. Amen. Wonka [doesn't use Classbath [yet], but] currently loads five other classes before java.lang.Class; java.lang.Object, java.lang.Cloneable, java.lang.Serializable, java.lang.Throwable, and the mysterious array class. You don't need java.lang.String from the beginning? Jaos is more exigent: * java.lang.Object * java.lang.String (also initialized) * java.lang.RuntimeException * java.lang.NullPointerException * java.lang.ClassCastException * java.lang.ArrayOutOfBoundariesException * java.lang.OutOfMemoryException * java.io.IOException * java.lang.AbstractMethodException * java.lang.Throwable (also initialized) * java.lang.StackTraceElement (also initialized) * java.lang.VMThrowable (also initialized) * java.lang.Thread (also initialized) * java.lang.ThreadGroup (also initialized) * java.lang.System (also initialized) And obviously, many other follow implicitly when a class is initialized. You may ask why so many classes? Well, there are mainly two reasons. First, I try to use as much java code as possible (I'm lazy), thus parts of the JVM rely on the code in the libraries. A beautiful example are threads, which rely on the Runnable interface: during the first implementation of Jaos, the Oberon language didn't have interfaces, thus the threads where started by invoking the Java code in java.lang.Thread; only later I did integrate Jaos interface support in the Oberon Kernel and added them to the language :-) . Of course, some functions must be duplicated for bootstrap purposes, because they are needed before they become available. Second, the exceptions are handled by Oberon's exception handler, which is not able to load classes. All Exceptions that are generated by the compiler or the CPU as interrupts must be already available in Throwable. And obviously Throwable, StackTraceElement, and VMThrowable. -Patrik ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: 0.08 NEWS
--On Montag, 8. März 2004 08:52 +0100 Mark Wielaard [EMAIL PROTECTED] wrote: By the way, how come everyone else isn't complaining about #6938? Why am I the only one who notices it? Does everybody else have a bootstrap class path that contains the java class path as a subset? As far as I have seen most VMs have their own System/Application classloader. The SableVM developers were also rewriting it (to make sure ProtectionDomains were set correctly). So I guess everybody works around it instead of collaborating on the version in CVS. Probably only the Orp developers used this class as is for their VM. For Jaos, I can confirm Mark assertion. The classloader is one of the few classes that must be available at bootstrap. In fact, I assume that only a JVM written in Java is able to use this class for the bootstrap of the VM. (Correct me if wrong) -Patrik ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Query on stacktrace management logic
--On Samstag, 13. März 2004 01:57 +0100 Jeroen Frijters [EMAIL PROTECTED] wrote: David Holmes wrote: Since I seem to be the only one that actually wants a VMClass instance, maybe we can agree on a slightly different interface. How about keep a reference to a VMClass instance in Class, but not calling any instance methods on VMClass, but using static methods instead (always passing the Class reference along). I don't understand the purpose of holding a reference to an instance of a class that only has static methods invoked on it. The reference implementation of VMClass will not have any instance members, but VMs might choose to add instance state. However, after thinking about it some more, I think it would be better to just add an instance member to Class, called vmState (or whatever) of type Object. That is more flexible (at the cost of additional downcasts). The only overhead for you is the unused vmState reference field in each Class instance. This seems a sound idea to me. I think the downcasts are not a big problem, as those calls are mostly used by the reflection, thus not time-critical. -Patrik ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Query on stacktrace management logic
--On Freitag, 5. März 2004 08:13 +1000 David Holmes [EMAIL PROTECTED] wrote: As previously mentioned I think VMClass would be better defined as a helper with static methods rather than a shadow object attached to each Class instance. From my own experience, I can only agree with this... (not much to say, but I really wanted to say it) -Patrik ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Free Java, the sequel
Although I'm pretty sure that everybody already read the articles, here's the sequel of the free java story from slashdot: 26 Feb: IBM Offers to Help Sun Open Up Java: http://slashdot.org/article.pl?sid=04/02/26/1532254mode=thread 27 Feb: Sun Agrees to Talk to IBM over Open Sourcing Java: http://developers.slashdot.org/article.pl?sid=04/02/27/1610245mode=thread Open letters seems to be quite trendy nowadays... -Patrik Patrik Reali http://www.reali.ch/~patrik/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: security
Hi Johan, thanks a lot for this report. It is obviously important to get those things right. Not every JVM uses those C routines (some like JNode and Jaos don't even have C available), but since the code is released, it should also be secure. -Patrik Patrik Reali http://www.reali.ch/~patrik/ --On Montag, 1. März 2004 08:45 +0100 Johan Peeters [EMAIL PROTECTED] wrote: at FOSDEM, we discussed how I might help to improve free Java's security. It seems to me that, for the edifice to be secure, the native layer's security is absolutely essential. I scanned the native directory with RATS (Rough Auditing Tool for Security - http://securesoftware.com) and found a few potential vulnerabilities, e.g. regarding the use of strcpy, fprintf, getenv and sprintf. Is this worth investigating further, or has it been covered? kr, Yo -- Johan Peeters bvba software architecture services tel:+32 16 64900 http://www.johanpeeters.com ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
[Article] Sun Fires Back over Open Source Java Accusations
OSNews has some discussion on Sun's answer to ESR request to make Java open source. http://www.osnews.com/comment.php?news_id=6053 -Patrik Patrik Reali http://www.reali.ch/~patrik/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: JIT pluggability (ABI Issues)
Hi! What I meant was the order parameters are pushed on the stack. Please excuse my previous underspecified statement. As a side node, pushing parameters right-to-left makes the implementation of open parameter lists much simpler (maybe this is another reason C tends to use it?). -Patrik --On Montag, 12. Januar 2004 12:59 -0800 Per Bothner [EMAIL PROTECTED] wrote: Patrik Reali wrote: Calling Convention * left-to-right (as in java) or right-to-left (as in C) Huh? Argument evaluation order is not really part of the ABI. C has *unspecified* evaluation order, so many implementations have evaluated them right-to-left because that's the way the stack grows (on most C implementations). But this is less relevant with optimizing compilers and register-based calling conventions. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: JIT pluggability (ABI Issues)
ABI Issues. I would divide this in three parts: allocation, calling convention, code patterns. Allocation deals with the addresses of the data structures and is fairly easy to deal with. The information needed is: * size for each basic type * padding/alignment of each type (in an object, in an array) * class layout (do we really need this? I guess the fields are allocated in the row as they are declared) * class hidden fields (type descriptor, locks, ...) * array layout (this may get complicated) * method number / offset in the vtable or itable * class numbering / interface numbering (for the systems that use this information) * Strings (some systems may have some special implementations here) Calling Convention * left-to-right (as in java) or right-to-left (as in C) * self (first or last?) * size and alignment issues * return values (on register? on stack?) * which params are passed on stack / in a register * register saving policies Code Patterns (using a system call or some inlined code) * method invocation (i.e. type descriptor layout) * class allocation * array allocation * class initialization * locking / unlocking * switch-tables (Jaos has a table with the absolute address of each switch destination, this must be patched by the linker) [... I'm sure I'm missing some here...] I think allocation is fairly simple to deal with. In fact, each backend could provide an implementation class which computes the allocation values. Calling convention and code pattern configuration may make even the simplest compiler become too complex to implement please correct me if wrong (this is just an assumption). -Patrik Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos/ http://iiop-net.sourceforge.net/ --On Freitag, 9. Januar 2004 09:45 +0100 Sascha Brawer [EMAIL PROTECTED] wrote: Tom Tromey [EMAIL PROTECTED] wrote on Thu, 8 Jan 2004 17:48:59 -0700: [standard pluggable JIT interface] This would indeed be quite nice, IMHO. Language choice for API. The obvious choices being: C lowest common denominator C++ next-to-lowest common denominator :-) provides some abstraction benefit, maybe Java using our own tools... There are some users of Classpath who cannot execute any C code, such as Jaos and JNodeOS. If the pluggable JIT interface was in Java, these systems would be able to use it (assuming that someone writes a JITter in Java, like IBM did with their Jalapeño/Jikes RVM). Also, I'd assume that the interface would be rather narrow in the sense that it wouldn't get invoked very often in the direction VM -- JIT; probably once for each class or method to be compiled. But the JIT would presumably have to call a lot into the VM (for retrieving field offsets etc.). ABI Issues According to IBM's publications and web pages, Jikes RVM seems to nicely cope with different ABIs (such as the slightly different calling conventions for AIX and MacOS X). Maybe, their code could serve as an example for how to structure the JIT interface so it can cope with different ABIs. Jaos works on top of an abstraction called object kernel, which basically is an API to garbage collection, synchronization, etc. Patrik Reali might be able to tell the list more about this. General API - Verifier interface? Does the verifier do all checking or does it impose some requirements on the JIT/interpreter? (Some verifiers choose to delay some checking until interpretation.) Does the JIT want/need information already computed by the verifier? For instance basic blocks or the type map at a given statement. I think it would be very wasteful to compute this information twice, but it might be very difficult to define common data structures that are suitable for everyone. Might it be sufficient if a verifier could store some opaque reference for later use by the JIT? AegisVM writes that they have developed a modular bytecode verification architecture, but I didn't look at this yet. Another thing that might be interesting to share is parts of a compiler backend, such as assemblers. -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: JIT pluggability (GC Interface)
(such as the slightly different calling conventions for AIX and MacOS X). Maybe, their code could serve as an example for how to structure the JIT interface so it can cope with different ABIs. Jaos works on top of an abstraction called object kernel, which basically is an API to garbage collection, synchronization, etc. Patrik Reali might be able to tell the list more about this. General API - Verifier interface? Does the verifier do all checking or does it impose some requirements on the JIT/interpreter? (Some verifiers choose to delay some checking until interpretation.) Does the JIT want/need information already computed by the verifier? For instance basic blocks or the type map at a given statement. I think it would be very wasteful to compute this information twice, but it might be very difficult to define common data structures that are suitable for everyone. Might it be sufficient if a verifier could store some opaque reference for later use by the JIT? AegisVM writes that they have developed a modular bytecode verification architecture, but I didn't look at this yet. Another thing that might be interesting to share is parts of a compiler backend, such as assemblers. -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath -- Chris Gray /k/ Embedded Java Solutions Embedded Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos/ http://www.classpath.org/ http://iiop-net.sourceforge.net/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Java Runtime Matrix for UserLinux
Hi Robert, if you can submit me a small paragraph describing JamVM, I'll add it to the link list on the Classpath site. -Patrik --On Montag, 5. Januar 2004 05:30 + Robert Lougher [EMAIL PROTECTED] wrote: Hi, Sorry for the empty post - first day back into work tomorrow :) What I meant to say: Any reasons for missing out JamVM (http::/jamvm.sourceforge.net)? It's been using Classpath since 1.0.0 (12-Mar-2003). Quite a few people are using it successfully, and I think a number of people on this list have given it a test. Thanks, Rob. Original Message Follows From: Dalibor Topic [EMAIL PROTECTED] To: GNU Classpath [EMAIL PROTECTED] Subject: Java Runtime Matrix for UserLinux Date: Sun, 04 Jan 2004 20:40:28 +0100 Hi all, I've started a java runtime matrix in the UserLinux wiki, that will serve as the foundation for their decision which runtime to pick. So if you feel like having your runtime as the default java runtime in UserLinux, please consider filling in the blanks for your project. If you don't please remove it from the matrix. You can find the matrix here: http://cgi.userlinux.com/cgi-bin/wiki.pl?Java_Runtime_Matrix cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath _ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath Patrik Reali http://www.reali.ch/~patrik/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Help and input needed
--On Sonntag, 14. Dezember 2003 19:05 +0100 Mark Wielaard [EMAIL PROTECTED] wrote: - GNU Classpath task list. Sascha has already made a start with one and Patrik has already turned them into a nice web page (but since savannah is down, we cannot publish it...) If Patrik can post the current tasks to the mailinglist then other can comment on it and/or add tasks. The current draft of the task list is here: http://www.reali.ch/~reali/classpath/tasks.html Please be patient and kind to my site, the downlink is only 64 kbit/s. Some entries a still quite raw (or just a placeholder). I'm still not sure how to handle the contact person (because of the current spam levels, I'm reluctant to post emails on a webpage) Feedback, new entries, and time or skill estimations for the existing entries are welcome! I'll update the list regularly on my site, waiting for savannah's great comeback. -Patrik ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
- Original Message - Tom Tromey writes: David I don't think there is an easy solution to this as it is unlikely David that a single VMInterface will fit the needs of all VMs perfectly. David In some cases (java.lang.ref.* for example), I don't think that it David is reasonable for classpath to try to provide an implementation David that will actually work unchanged on all VMs. Andrew Exactly. Classpath should provide a reference implementation, Andrew we but shouldn't expect every core class to be used unchanged. I agree. I think it is reasonable to expect libgcj to diverge from classpath in some places -- there are areas where libgcj's needs aren't the same as the needs of other VMs. But at the same time, I'd expect VMs that are unusual in other ways (e.g., IKVM or JikesRVM, both different in one way or another) to also occasionally have their own divergence. Or, to put it another way, let's distribute some of the divergence; it can't all rest on libgcj. (Which I doubt anyone is proposing anyway.) I agree with you. My approach is rather pragmatic: first, classpath should allow to quickly develop a VM, by providing a clean design and as many features as possible in Java. Then, once the VM is running, everybody can choose the optimizations that match the problem that the VM is trying to address. In practice, as soon as one VM leaves the state of pet project or proof of concept, optimizations are unavoidable. I'm not sure that compiler optimizations (in particular inlining and pointer escape analysis) can handle every problem (and as I remember, they ofter require static compilation and limit dynamic loading, a core java feature), thus some code modification may be required to optimize the API for the VM. Anyway, coming myself from the compiler world, you can imagine how painful it is for me to say that native methods should forward the call to the VM* classes (thus adding an indirection). This has for me the following advantages: * clear separation between the API and the VM * regrouping the native methods into a few classes (it is simpler to find out which methods must be implemented, and the number of stubs to create is much smaller, which is less code to manage) On the other hand, the VM* approach causes additional costs: * often requires to duplicate structures to keep track of one information. * additional indirection in each invocation As often the case, good design and optimizations don't mix well! In case of doubt, I always choose the good design (it fits every case) over the optimization (it usually fits only a specific use-case). But this is just my own opinion. -Patrik Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Q: Classpath and Eclipse
Hi! Has anybody already tried to import classpath under Eclipse? I tried to create a project and import the files, but then Eclipse is far too intelligent: * gnu/java/lang classes are imported into package java.lang * vm/reference/java/lang classes are imported into package vm.java.lang Probably I'm just doing something wrong (I'm using Eclipse 3.0M4) Thanks, Patrik --- Patrik Reali http://www.reali.ch/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
Jeroen wrote: Bryce McKinlay wrote: Sorry, I think I misunderstood your message. I thought you were suggesting moving all the native methods (eg for IO classes) to separate VM* classes. I think that is in fact what Mark was suggesting and I think this is definitely a good idea. There are a lot of VMs that don't (want to) use JNI for their native methods. Having all native methods in the VM* classes makes this much easier. I agree with this. Moving all the native methods in the VM* classes would be easier for the VM implementors, because it is easier to document or find out which methods must be provided (a grep native *.java doesn't help much!). Right. I think there is a distinction, however, between what the VM must implement to operate with classpath - ie core VM classes like Class, Object, Throwable, Thread; and portable classes which happen to have native methods, such as java.io.File and java.net.PlainSocketImpl. The later are just normal classes with native methods, the implementations of which are typically be portable across different VMs. This assumption is not true for some VMs. My VM (IKVM) has no native methods and I'm pretty sure this is also true for JAOS and maybe others. How I'm going to explain this...? Well Jaos uses the Oberon language to provide the native methods (native == written in a language other than java), but doesn't go through JNI: both languages have the same object model with garbage collection, so no object pinning and similar stuff is needed, and the jitter compiles the byte-code using the same data layout and calling convention, such that the generated code is identical for both languages. It is the task of the linker to patch the native implementation entry points into the method tables, and from that point java can call oberon and oberon can call java. Moving all the native methods to a separate class would make my job simpler: I would replace the complete class with an oberon class instead of having to merge them. And because the interface is stable, I would be able to get rid of a lot of bootstrap code, which checks every time whether the methods and fields have changed. So, they a system/platform interface rather than the VM interface. To put it another way, just because a method is native doesn't mean it interfaces with the VM. The VM* classes don't mean interfaces with the VM, but are a way for VM implementers to easily replace their implementation. (The idea being that the interface between the non-VM and VM classes is fairly stable). Well, the VM classes are part of the VM interface, which is much broader. I agree that they will be fairly stable, thus making the port simpler to maintain. -Patrik Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: CVS configure.in is broken
: `AM_CONFIG_HEADER(include/config.h)' - Original Message - From: Stephen Crawley [EMAIL PROTECTED] To: Patrik Reali [EMAIL PROTECTED] Cc: Mark Wielaard [EMAIL PROTECTED]; Stephen Crawley [EMAIL PROTECTED]; [EMAIL PROTECTED]; GNU Classpath [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, October 27, 2003 1:03 AM Subject: Re: CVS configure.in is broken Patrik, The problem with --disable-gtk-peer is that it works for the compilation, but GTK must be installed anyway, otherwise aclocal fails. I can't recall exactly, but I think I found it was OK to just ignore the aclocal error messages. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: CVS configure.in is broken
The problem with --disable-gtk-peer is that it works for the compilation, but GTK must be installed anyway, otherwise aclocal fails. In practice, I would have to install GTK-2 just to be able to configure the package _not_ to use GTK-2. To avoid this, I used to remove the GTK, GLIB, and LIBART stuff in the configure.in file (from line 121 to line 148) before aclocal and eventually configured classpath with --disable-gtk.peer. It's a hack , but it works for me. -Patrik Stephen Crawley wrote: Mark Wielaard [EMAIL PROTECTED] wrote: On Thu, 2003-10-23 at 19:52, Dalibor Topic wrote: apparently the configure.in in CVs is broken. I tried the aclocal; autoheader; automake; autoconf routine as recommended in the HACKING document, but it doesn't work:=20 aclocal complains about =20 aclocal: configure.in: 134: macro `AM_PATH_GTK_2_0' not found in library aclocal: configure.in: 137: macro `AM_PATH_GLIB_2_0' not found in library aclocal: configure.in: 140: macro `AM_PATH_LIBART' not found in library =20 and it's all down from there ;) Also from the HACKING document: the following are required. =20 - GTK+ 2.x.x - libart_lgpl 2.1.0 Those packages should provide the missing AM_ macros. There is an alternative workaround to this. There is an ugly hack in the configure.ac file that allows you configure to Classpath with --disable-gtk-peer on a platform that does not have GTK+ 2.x.x. This workaround allows you to build / use Classpath for non-GUI apps if you are stuck with an older Linux distro that only has GTK+ 1.x.x. (Retrofitting GTK+ 2.x.x can be really hard because of the number of libraries and applications that need to be upgraded. At least, that was what I found with RedHat 7.2.) -- Steve P.S. This should be documented in the HACKING file, since the question seems to come up every few months. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath initialization
In Jaos, the ClassLoader is loaded but not really used (I'm still stuck with classpath 0.5) because I have my own native implementation which overrides the calls to Java's classloader in Class.fromName(). I'm currently upgrading my implementation to work with 0.6 by moving all the native stuff into the VM classes, but haven't got that far yet (it's a lot of work!) -Patrik For comparison, Wonka's explicit class initialisation looks something like this: ** 1) load class java/lang/Object. ** 2) load java/lang/Cloneable, java/lang/Serializable, java/lang/Throwable. ** 3) create clazz_Array. clazz_Array acts like clazzObject but has ** a modified method table and a modified interfaces table. ** It overrides the clone method of java/lang/Object and adds two ** new interfaces: Cloneable and Serializable. ** (We need to do this before any subclasses of Throwable are loaded, ** in order to ensure that they are marked CLAZZ_IS_THROWABLE). ** 4) load java/lang/Class, java/lang/ClassLoader, java/lang/Thread, ** java/lang/ThreadGroup, and java/lang/ref/Reference. ** 5) load all the classes mentioned in core-classes.in. ** 6) For each primitive class xxx, create: ** -An instance Class_xxx of class java/lang/Class, linked to **a w_Clazz structure (clazz_xxx). **The name associated with the Class instance is xxx.class. ** -Entries in the array atype2clazz[], which is indexed by P_xxx. Step 5) is needed because we need to create explicit relationships between C and Java constructs for quite a large number of classes, which Patrik doesn't need to do because he's using Oberon. I guess that's also why he doesn't need to explicitly load ClassLoader; we need to do that because of all the behind-the-scenes stuff needed to implement class loading according to the JVM spec. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
The LGPL has a rather interesting point in paragraph 6a. where they state that it is obviously possible to change the code, but It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions. I think this bit is not in the GPL (as every piece of code is released under the GLP). This is obviously common sense. The same holds for any implementation of a protocol (even the GPLed ones) that everything can be changed, but nobody would seriously expect them to work afterwards. Would you consider the implementation of a standard or a protocol (which cannot change freely) to violate the GPL? I do not know what the OMG licences doens't allow to do (I couldn't find the implementatio either). -Patrik Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos - Original Message - From: Stuart Ballard [EMAIL PROTECTED] To: Brian Jones [EMAIL PROTECTED] Cc: GNU Classpath [EMAIL PROTECTED] Sent: Tuesday, October 21, 2003 3:40 PM Subject: Re: org.omg link on Classpath homepage Brian Jones wrote: Basically they will never be free to modify because the entire point of the OMG standard is these interfaces DO NOT CHANGE or change only as the standard evolves at the whim of the standards body. The GPL doesn't allow compatibility with licenses that do not permit modification. Then isn't Classpath violating GNU project policy by advertising non-free software on its homepage? Stuart. -- Stuart Ballard, Senior Web Developer FASTNET - Web Solutions (215) 283-2300, ext. 126 www.fast.net ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath initialization
Hi! Initializing a JVM is quite a complicated thing. Many problems depend on which class you first initialize, because this could cause unexpected dependecies to pop up. Jaos doesn't suffer from the problem you descrive, because it doesn't use the external libraries or JNI: Oberon is rather close to Java, and the objects can be directly accessed from both languages without fear of breaking the type system or confusing the garbage collector. I also had my share of problems with the system properties, because they are hard-coded in the libraries and I didn't realize it at once. Furthermore, the properties and java.io assume an unix-like filesystem, which Oberon doesn't have: we don't have directories, only mounts. In Jaos, I explicitely initialize a few classes during bootstrap (this are only the explicit calls, other classes may be automatically initialized as side effect, and in fact about 80 are!). This code relies on classpath 0.5 (I'm not through updating yet). 1. String 2. Throwable 3. StackTraceElement 4. VMThrowable 5. Thread 6. ThreadGroup 7. System This may look strange, but 1. String is implicitely used everywhere, because the string constants are instances of this class; according to the spec, allocating an instance of a class causes the class to be initialized. (I could avoid this, but then I would have to protect every access to the string methods with a check to launch initialization; Strings are already slow enough in Jaos). 2. Throwable / StackTraceElement / VMThrowable: I must allocate them when the VM is launched: loading them on-demand (at the first exception) is already too late, because the VM is already processing an exception (in Oberon this is done with a software interrupt) and loading reads from the disc (causing more interrupts), but the kernel doesn't allow to interrupt handler to cause other interrupts. 3. Thread / ThreadGroup must be initialized, because every java program is executed in a java thread; Jaos creates such a thread for the execution of a java program. This remarks (in particular 2 and 3) are quite Jaos specific. This won't probably solve your problem, but may give you some insight about the various problems encountered during the initialization phase. -Patrik Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos - Original Message - From: Joseph Wenninger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 9:33 PM Subject: classpath initialization Hi I'm trying to use an unmodified classpath (0.06). I already have something working with a modified one. My problem is that the call stack during initialization of the System class I looks something like LOG: called: java/lang/System.clinit()V() LOG: called: java/lang/System.loadLibrary(Ljava/lang/String;)V(405c8488) LOG: called: java/lang/Runtime.getRuntime()Ljava/lang/Runtime;() LOG: finished: java/lang/Runtime.getRuntime()Ljava/lang/Runtime;-0x8420fd8 LOG: called: java/lang/Runtime.loadLibrary(Ljava/lang/String;)V(8420fd8, 405c8488) LOG: called: java/lang/VMSecurityManager.currentClassLoader()Ljava/lang/ClassLoader;() LOG: called: java/lang/ClassLoader.clinit()V() LOG: compiler_addinitclass: java/lang/VMClassLoader LOG: called: java/lang/VMClassLoader.getSystemClassLoader()Ljava/lang/ClassLoader;() LOG: called: java/lang/System.getProperty(Ljava/lang/String;Ljava/lang/String;)Ljava/lang /String;(405cb500, 405cb578) ()Vi The last line causes an exception, since the static member properties isn't initialized yet. Did anybody else encounter such a problem ? I'm not sure if that it is a vm bug or a compiler problem or something that I miss Kind regards Joseph Wenninger ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
I think this makes sense (as long a java implementation is available).
I can see only one limitation at the moment: if someone wants to construct a
free J2ME (CLDC) API from Classpath.
The CLDC API contains only java.io; there, PrintStream writes to the
underlying stream according to the locale and VM configuration. There is no
explicit encoder (as far as I can see), but I guess it would rely on
something like the current encoders (maybe just hardcoded, because a generic
implementation it just too expensive on a small device).
-Patrik
Patrik Reali
http://www.oberon.ethz.ch/jaos
Brian Jones [EMAIL PROTECTED] wrote on Tue, 23 Sep 2003 07:17:07 -0400:
Is there a reason to keep gnu.java.io.{encode,decode}.* around when it
looks like the nio versions could be used?
It probably would make sense to switch to java.nio.charset.
Some of us (Dalibor Topic; Mark Wielaard; Andy Walter; James Hunt; Ingo
Proetel; Sascha Brawer) had discussed this during our meeting at LinuxTag
in Germany.
Quoting from Mark's meeting minutes (http://mail.gnu.org/archive/html/
classpath/2003-07/msg00040.html):
The plan for character encodings is to move to the java.nio.charset
interface. We already have required encodings for this. But GNU
Classpath and gcj both still also have their old implementations
(which are actually used in most places). gcj also has a libiconv
provider (but not as java.nio.charset provider). A java.nio.charset
libiconv provider would be nice to have for those systems that
have that library.
-- Sascha
Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Workshop/BoF: Graphics in GNU Classpath
I will be in Saarbrücken. -Patrik -- Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos/ http://iiop-net.sourceforge.net/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: HTML-Rendering engine written in Java?
Hi Clemens, XBrowser (http://xbrowser.sourceforge.net/) ist a Web Browser completely written in Java, so I guess it must contain a rendering engine. It is released under the SISSL licence. -Patrik - Original Message - From: Clemens Eisserer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 13, 2003 9:55 PM Subject: HTML-Rendering engine written in Java? Hi there! Does anybody know a useable html-rendering engine completly written using Java and 100% free Software (e.g. GPL, LGPL)... I want to port such a library from AWT/SWING to SWT. All libraries I found were proprietary, so they arent useful at all for me :-( lg Clemens ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Preparing for 0.06 release
A side question (that's important for deciding whether to include it in the 0.06 release), do any VMs use the unmodified reference Thread class? I believe the kissme VM just uses the vm/reference version of Thread. Jaos uses vm/reference/java/lang/Thread as is. But this shouldn't stop you from improving the design by moving the native stuff into a VMThread class. If a native method is just rewritten to call a VM* method, then Jaos implementation will still work, because the linker patches the native method implementation directly into the method table and thus ignores the call to the VM* class. -Patrik ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Jaos JVM
Hi! After a pause of more than one year, caused by some other higher-priority projects, I'm working again on the Jaos VM [0]. Since I left ETH, I can only work during my spare time on the project. The Jaos VM is a JVM using GNU Classpath implemented on top of the Aos/Bluebottle kernel [1]. This kernel offers many useful features like garbage collected memory management, dynamic module loading, and object-oriented model. This makes the implementation of a JVM particularly attractive and simple. Jaos uses GNU Classpath out-of -the-box. Currently, it works with GNU Classpath release 0.5. No changes at all are required. Jaos has some charateristics which make it peculiar. First, the jitter generates code that follows the kernel conventions for data layout, thus the java modules are fully integrated in the system (interoperability with oberon requires no glue code). Second, the java reflection classes are implemented to work directly with the system's symbol tables (the same used by the oberon compiler) so that both compilers rely on the same metadata (this sounds .NETish, and in fact also is). Jaos is a jit-based JVM; the jitter is based on [3], which is an ideal compromise as it fastly generates good code for the i386 processors. The language used for the native methods and low-level implementation is Active Oberon, an extension of the Oberon language (an evolution of Modula-2 and Pascal). Thus, Jaos is only able to run code written either in Active Oberon or Java: third party code in C is excluded. This is no big problem (for the moment), as the core classes of classpath are quite complete; it may pose a problem with the java/awt package, because apparently most of the implementation are optimized (and thus in C). Another advantage of the kernel modularity and dynamic loading features is that it allows decide which modules are loaded. As an example, I can deploy only the Aos kernel, Jaos, and a stripped down version of classpath (and forget about Oberon itself) on a single bootable floppy disk. My plans for the future include supporting java/net, java/awt, simplify Jaos installation and handling, and fine-tuning the VM. I want to rely as much as possible on Java code, in particular for the graphical support (I'm thankful to Sascha Brawer, who is writing the font stuff in Java). As a JVM developer, I think it is important for Classpath to provide as much code as possible in Java itself: this provides a reference implementation, it is fully portable, and allows to quickly have a fully-featured running JVM; each JVM can then choose whether to rely on the default implementation or provide an own optimized one. I will shortly begin with the implementation of java/awt/* for Jaos, but I will try to work as much as possible with Java (ideal would be to have only one base class with graphical primitives like Graphics2D natively implemented, and the rest in Java). Obviously, I will contribute any Java code I need to add to classpath to make Jaos work. Jaos itself is also freely available. Thank you very much to the whole classpath developer team for the great work done! -Patrik Reali [0] Jaos: http://www.oberon.ethz.ch/jaos/ [1] Aos/Bluebottle: http://bluebottle.ethz.ch/ [2] Active Oberon: http://bluebottle.ethz.ch/languagereport/ [3] Cierniak et al.; Fast, Effective Code Generation in a Just-In-Time Java Compiler; PLDI-98 Patrik Reali http://www.inf.ethz.ch/personal/reali http://www.oberon.ethz.ch/jaos ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: 0.05
of months. I'd like to make a new Classpath release, perhaps in the next few weeks, depending on how long it takes to get most of the Good to hear. I was going to prepare a new version of the Jaos VM to release my latest changes (an new improved jit-compiler, a few slides from a lecture I'm currently giving, and some documentation as part of my thesis). I will wait for the 0.05 release to integrate the new libraries in Jaos: the timing is almost perfect, as I should have more time from february on. The good news for the moment are: * Jaos is not dead * I did run the Spec JVM 98 on Jaos with Classpath: 201_compress, 202_jess, 209_db, and 228_jack are working fine (though I did my last checkout in march). The other benchmarks fail because of some errors in Jaos. The results on my website are those with the old compiler; with the new one the code should be about twice as fast. Patrik Reali http://www.inf.ethz.ch/personal/reali http://www.oberon.ethz.ch/jaos ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: getting started with classpath
From: Brian Jones [EMAIL PROTECTED] Some good ideas here, but let's not exclude other JVMs such as SableVM or kissme. A side question of mine at the moment is whether any of these support working with the AWT and native peer code other than GCJ. Jaos has currently no support for the AWT. Whenever this happens, I will have to provide my own native implementation, because I'm not running on a *nix system. -Patrik ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Problems with Character
Hi! I'm experiencing some problems with java.lang.Character. The methods toUpperCase and toLowerCase return wrong results (most of the calls leave the values unchanged, a few return strange values). I went through the code, but there's not much they're just taking the result from some tables. I'm currently using the latest version of Character and CharData. Can anybody confirm (or dismiss) the problem? Thanks, Patrik Patrik Reali http://www.inf.ethz.ch/personal/reali http://www.oberon.ethz.ch/jaos ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath which jvm ?
Which jvm does the --current-- classpath run with ? orp doesn't seem to work. R. Jaos (http://www.oberon.ethz.ch/jaos/) works with classpath 0.03 and an own implementation of java/lang/Character. Jaos is currently in an advanced alpha phase. Textual IO and file support are implemented; Net and AWT are not supported. -Patrik ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
