Classpath build process and VM-specific issues
Hi All. I would like to suggest 2 things. Build Process = 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, ...). It would be impractical (or even maybe impossible) to setup a *single* "classpath" installation on a user system, meant to be used by distinct VMs/compilers on this same system; one can simply think of the ever changing VM interface, VM-specific issues, etc. 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. So, what I see is a very minimal change. It would work as follows: $ ./configure *** configure error: *** You must supply a --with-vm=xxx command-line argument. *** Valid VMs are: unknown, gcj, jikes, sablevm,... To compile Classpath for gcj, one would type: $ ./configure --with-vm=gcj This would select CNI libraries, etc. To compile for SableVM, one would type: $ ./configure --with-vm=sablevm and so on. VM*.java Classes As far as I know, SableVM does not need any really "SableVM-specific" .java classes. It only need *minimal* changes in the "reference" implementation to work. I can easily imagine other VMs (such JamVM) being in the same situation. I would very much like all the VM-specific code moved to VM*.java package-private classes, but these classes should reside in the *normal* package tree, not in a vm/ subdirectory. [talking of normal package tree: would anybody object to moving the whole tree to an src/ subdirectory, as it should be done in such a big project?] Grzegorz Prokopski and I are working on a set of m4 macros (that would not require understanding "m4" to be used) to allow minimal customization of VM*.java classes for each VM, while retaining most of the code sharing across all VMs that can work with the default VM*.java setup. [Some VMs, like JikesRVM tend to completely replace some base classes by their own; SableVM does not]. The objective: Share as much code between "normal" VMs (that need nothing really special in base classes), and intuitive source file locations. What do you think? Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Quoting Etienne Gagnon ([EMAIL PROTECTED]): > It would be impractical (or even maybe impossible) to setup a *single* > "classpath" installation on a user system, meant to be used by distinct > VMs/compilers on this same system; one can simply think of the ever > changing VM interface, VM-specific issues, etc. While that is currently true, one would hope that the virtual machine interface will stabilize over time. At that point, Classpath developers should make sure not to introduce incompatible changes to virtual-machine related classes without making a new major release and announcing it properly anyway. Virtual machine targetting that stable classpath release could then share most of the core classes and Distributions like Debian could then ship the classpath zip-file, reusing it for all virtual machines included. The exception are, of course, the VM* classes, which virtual machine packages will include. The VM will put its own customized versions of these classes into its bootstrap classpath to override default versions (if any) included in the standard classpath installation. BTW, on the topic of VM* classes: Has there been agreement on java.lang.VMClass? The proposal was to make its methods static (and possibly add an "Object vmdata" field to java.lang.Class instead). David pgp0.pgp Description: PGP signature ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Tests (Was: Classpath post from zander@javalobby.org requires approval)
Hi, On Thu, 2004-03-25 at 16:29, [EMAIL PROTECTED] wrote: > As list administrator, your authorization is requested for the > following mailing list posting: Oops. I believe I hit the spam button. Sorry Thomas. Hope the rest of our cooperation goes a bit smoother. > From: Thomas <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Tests > Date: Thu, 25 Mar 2004 16:28:51 +0100 > > I'm a long time Java programmer (over 5 years now), with a _lot_ of experience > in quite obscure parts of the libraries. > As an effect I know of quite some annoying bugs in Suns implementation of the > various base classes (mostly Swing stuff). I am interrested in creating tests > to test for these bugs in the (coming) implementation of the same API in G.CP Very nice! Welcome, welcome! > With such long experience on Suns JVMs you can guess I looked into there > sources ones or twice. I'm assuming this means you can't accept > implementations of API stuff from me. > But does this mean I can't create tests? What about APIDocs, and what about > simple bugfixes? Writing tests and documentation is fine. And really appreciated! The reason we don't accept code from people who have studied other proprietary implementations is summarized at: http://www.gnu.org/software/classpath/docs/hacking.html#SEC2 "If it turns out that your code was not developed in a clean room environment, we could be very embarrassed someday in court. Please don't let that happen." As you probably know, creating a a compatible implementation means writing much code that will look similar. To proof that the similarity doesn't come from copying another implementation, but because we are follow the spec so precisely, we use the defense that the people who wrote it have not looked at any other implementation of those methods and classes. If you would like to help with testing then please check out the Mauve project which we use for much of our testing purposes. http://sources.redhat.com/mauve/ Also taking an existing free program written in the java language and trying to make it work with gcj, kaffe or another VM based on classpath is really appreciated. See the following email for some more explanation "GNU Classpath 0.08 - How to use it": http://mail.gnu.org/archive/html/classpath/2004-03/msg00093.html On the documentation front we are missing a good overview document. We do already have some nice API documentation (although it can certainly use more attention for some packages/classes): http://www.klomp.org/mark/classpath/doc/api/html/ A good overview document should tell you "this is what we have", "this is how it fits together" and "this is how you use it to create more free software". Most documentation tells about the proprietary implementations. And although we try to be as compatible as possible to make it easy for people to move from a proprietary platform to a free one, we are not there yet. So what we really need is a document that describes everything from the point of view of the free implementation that we have now. > Please cc answers as I'm not subscribed. Please subscribe to the list. It makes communication a but easier. I need to explicitly accept non-subscriber email (darn spam...) Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Sablevm-developer] Re: Starting to swing... [screenshots]
Hi all, On Wed, 2004-03-24 at 19:39, Etienne Gagnon wrote: > > http://people.redhat.com/~graydon/free-swing-mar-23-2004.png > > OK SableVM guys! I'd like to see this in SableVM's staging tree *now*! :) > To get get SableVM staging to work out-of-the-box with > a Classpath CVS, using: > > $ # [go to classpath working copy] > $ cd classpath > $ ./configure --with-vm=sablevm && make && make install > > $ # [go to sablevm working copy] > $ cd ../sablevm > $ ./configure && make && make install > > $ # [go to swing demo] > $ cd ../swing-demo > $ sablevm SwingDemo > > $ # [amazing GUI is now shown :-)] > > What's missing? Two things: - This code is now only in the development branch of libgcj. To keep the AWT/Swing hackers busy and to to distracted by all the other cool things going on this is only merged back to libgcj proper once a month (then it needs to me merged back to classpath again). Which means that you will have to wait till 0.09 probably to play with it out of the box. - Although we have a TestAWT application, we don't have a TestSwing application. It would be nice if Graydon could post the sources of the demos he used for the nice shots at http://people.redhat.com/~graydon/ Hint, hint, ... ;) Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
> "Etienne" == Etienne Gagnon <[EMAIL PROTECTED]> writes: Etienne> VM*.java Classes Etienne> Etienne> As far as I know, SableVM does not need any really "SableVM-specific" Etienne> .java classes. It only need *minimal* changes in the "reference" Etienne> implementation to work. I can easily imagine other VMs (such JamVM) Etienne> being in the same situation. BTW, another thing that came up on irc is that we could share some code inside the JNI implementation, for instance argument parsing for JNI_CreateJavaVM. Etienne> [talking of normal package tree: would anybody object to moving the Etienne> whole tree to an src/ subdirectory, as it should be done in such Etienne> a big project?] Personally I'd prefer no change, since moving stuff around is a pain with cvs, and since there doesn't seem to be a really big benefit from it. Etienne> I would very much like all the VM-specific code moved to VM*.java Etienne> package-private classes, but these classes should reside in the Etienne> *normal* package tree, not in a vm/ subdirectory. Etienne> Grzegorz Prokopski and I are working on a set of m4 macros Etienne> (that would not require understanding "m4" to be used) to Etienne> allow minimal customization of VM*.java classes for each VM, Etienne> while retaining most of the code sharing across all VMs that Etienne> can work with the default VM*.java setup. [Some VMs, like Etienne> JikesRVM tend to completely replace some base classes by Etienne> their own; SableVM does not]. Etienne> The objective: Share as much code between "normal" VMs (that Etienne> need nothing really special in base classes), and intuitive Etienne> source file locations. It does seem to me that most "ordinary" (C-based, Unix-y platform) VMs could share a lot of this code. Moving it out of the vm/ subdirectory, I don't know. It seems like that would prioritize these VMs over the weirder ones. Personally I don't see it as that big of a problem to have the VM* classes in a separate directory hierarchy. I talked with Grzegorz a bit about this on irc the other day. One question I have is, how are we going to test changes to the VM* code if the m4 processing step is in place? Right now, the reference code is just reference code, so we can make changes to it on a theoretical basis. This is both good (we can make it more correct) and bad (we can't test it). It does imply that changes to this code have to be tracked by VM implementors and then integrated into their versions of these classes. With the m4 scheme, it seems like we would have to test any change to these classes against all VMs using them. In other words, the maintenance burden gets pushed onto all of us, instead of the particular VM implementors. Of course the positive aspect here is that bug fixes can be more immediately shared, and we can actually test the VM* code. Which is a big plus. What do you propose for the testing part of this change? Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
On Thu, 2004-03-25 at 13:17, David Lichteblau wrote: > Quoting Etienne Gagnon ([EMAIL PROTECTED]): > > It would be impractical (or even maybe impossible) to setup a *single* > > "classpath" installation on a user system, meant to be used by distinct > > VMs/compilers on this same system; one can simply think of the ever > > changing VM interface, VM-specific issues, etc. > > While that is currently true, one would hope that the virtual machine > interface will stabilize over time. At that point, Classpath developers > should make sure not to introduce incompatible changes to > virtual-machine related classes without making a new major release and > announcing it properly anyway. > > Virtual machine targetting that stable classpath release could then > share most of the core classes and Distributions like Debian could then > ship the classpath zip-file, reusing it for all virtual machines > included. > > The exception are, of course, the VM* classes, which virtual machine > packages will include. The VM will put its own customized versions of > these classes into its bootstrap classpath to override default versions > (if any) included in the standard classpath installation. Yes, at some point it might be possible, though given the size of today's disks - it might not matter that much. But even such case does not imply that these VM-specific binaries (which each JVM would have in its bootclasspath) could not come from one source. Such single source would allow to share almost all of the code (that is all maintenance, bugfixes and improvements), surrounded by minimal, compile-time-conditional VM-specific tweaks. Grzegorz B. Prokopski ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Etienne Gagnon wrote: > Build Process > = > > 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, ...). > > It would be impractical (or even maybe impossible) to setup a *single* > "classpath" installation on a user system, meant to be used by distinct > VMs/compilers on this same system; one can simply think of the ever > changing VM interface, VM-specific issues, etc. Hmm, not sure I agree. For example, JC uses a completely stock Classpath installation. JC includes its own version of certain core classes and these classes are inserted in the boot classpath in front of glibj.zip. All Classpath's native libraries are used (or overridden) as-is. Also, I'm worried that requiring the code associated with VM X spread across two source trees (the VM's and Classpath) could make maintenance more difficult. However, I'm open to this change.. for JC it would just be a no-op. > The objective: Share as much code between "normal" VMs (that need nothing > really special in base classes), and intuitive source file locations. That's a worthy objective... sounds like an improvement. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Object serialization and final fields
Hi,
Some people has reported failures in kaffe with applications trying to
deserialize objects containing final fields. Apparently it is authorized
in the serialization spec but we cannot rely on
java.lang.reflect.Field to set them. So our only solution is to bypass
the protection in java.lang.reflect.Field by creating new native calls
in ObjectStreamField.
I am proposing the following changes for ObjectStreamField. I don't
whether it's possible to make a generic change to Field.java so we can
call private methods in it using native calls.
Regards,
Guilhem.
Index: java/io/ObjectStreamField.java
===
RCS file: /cvsroot/classpath/classpath/java/io/ObjectStreamField.java,v
retrieving revision 1.14
diff -u -b -B -r1.14 ObjectStreamField.java
--- java/io/ObjectStreamField.java 26 Feb 2004 07:53:15 - 1.14
+++ java/io/ObjectStreamField.java 25 Mar 2004 20:19:43 -
@@ -38,9 +38,10 @@
package java.io;
+import gnu.java.lang.reflect.TypeSignature;
+
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
-import gnu.java.lang.reflect.TypeSignature;
import java.security.AccessController;
import java.security.PrivilegedAction;
@@ -64,7 +65,7 @@
{
this (field.getName(), field.getType());
this.field = field;
-toset = !Modifier.isFinal(field.getModifiers());
+//toset = !Modifier.isFinal(field.getModifiers());
}
/**
@@ -353,11 +354,14 @@
return "ObjectStreamField< " + type + " " + name + " >";
}
+ final private native void setBooleanNative(Object obj, boolean val)
+throws IllegalAccessException;
+
final void setBooleanField(Object obj, boolean val)
{
try
{
- field.setBoolean(obj, val);
+ setBooleanNative(obj, val);
}
catch(IllegalAccessException x)
{
@@ -365,11 +369,14 @@
}
}
+ final private native void setByteNative(Object obj, byte val)
+throws IllegalAccessException;
+
final void setByteField(Object obj, byte val)
{
try
{
- field.setByte(obj, val);
+ setByteNative(obj, val);
}
catch(IllegalAccessException x)
{
@@ -377,11 +384,14 @@
}
}
+ final private native void setCharNative(Object obj, char val)
+throws IllegalAccessException;
+
final void setCharField(Object obj, char val)
{
try
{
- field.setChar(obj, val);
+ setCharNative(obj, val);
}
catch(IllegalAccessException x)
{
@@ -389,11 +399,14 @@
}
}
+ final private native void setShortNative(Object obj, short val)
+throws IllegalAccessException;
+
final void setShortField(Object obj, short val)
{
try
{
- field.setShort(obj, val);
+ setShortNative(obj, val);
}
catch(IllegalAccessException x)
{
@@ -401,11 +414,14 @@
}
}
+ final private native void setIntNative(Object obj, int val)
+throws IllegalAccessException;
+
final void setIntField(Object obj, int val)
{
try
{
- field.setInt(obj, val);
+ setIntNative(obj, val);
}
catch(IllegalAccessException x)
{
@@ -413,11 +429,14 @@
}
}
+ final private native void setLongNative(Object obj, long val)
+throws IllegalAccessException;
+
final void setLongField(Object obj, long val)
{
try
{
- field.setLong(obj, val);
+ setLongNative(obj, val);
}
catch(IllegalAccessException x)
{
@@ -425,11 +444,14 @@
}
}
+ final private native void setFloatNative(Object obj, float val)
+throws IllegalAccessException;
+
final void setFloatField(Object obj, float val)
{
try
{
- field.setFloat(obj, val);
+ setFloatNative(obj, val);
}
catch(IllegalAccessException x)
{
@@ -437,11 +459,14 @@
}
}
+ final private native void setDoubleNative(Object obj, double val)
+throws IllegalAccessException;
+
final void setDoubleField(Object obj, double val)
{
try
{
- field.setDouble(obj, val);
+ setDoubleNative(obj, val);
}
catch(IllegalAccessException x)
{
@@ -449,11 +474,14 @@
}
}
+ final private native void setObjectNative(Object obj, Object val)
+throws IllegalAccessException;
+
final void setObjectField(Object obj, Object val)
{
try
{
- field.set(obj, val);
+ setObjectNative(obj, val);
}
catch(IllegalAccessException x)
{
pgp0.pgp
Description: PGP signature
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Tests (Was: Classpath post from zander@javalobby.org requires approval)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 25 March 2004 19:44, Mark Wielaard wrote: > Writing tests and documentation is fine. And really appreciated! ... > If you would like to help with testing then please check out the Mauve > project which we use for much of our testing purposes. > http://sources.redhat.com/mauve/ I downloaded the snapshot and got it running; I'll try to find out how this works and see what I can add. Thanx. First impression was a bit strange; 70195 of 3581269 tests failed on Suns JDK 1.4.2_02... seems like lots of tests copy-pasted but not finished. > Also taking an existing free program written in the java language and > trying to make it work with gcj, kaffe or another VM based on classpath > is really appreciated. Hmm; my projects use lots of Swing code; so that seems like a no-go idea for some time to come.. Is the Apache licence considered Free for you guys (I'm really an open source programmer, not a free-software one..). When I have some time (yeah-right!) I'll try to get my pet-project http://uic.sf.net running. But this requires to setup something like kaffe; I'll see how well this is apt-gettable.. > On the documentation front we are missing a good overview document. Something like this?: You never heard of Suns Java; then here is the documentation that introduces you to Java! The Free libraries provided in Gnu Classpath can be used as an extensive library to allow any task to be programmed in Java. As the Gnu Classpath is just a library for the Java language, you will want to have a application which can run Java code (called a Runtime Environment), as well as a compiler to compile your code to be run by anyone that has a Runtime Environment installed as well. etc. > We do already have some nice API documentation (although it can > certainly use more attention for some packages/classes): > http://www.klomp.org/mark/classpath/doc/api/html/ Editing this is done by editing the sources? So checking out the sources and posting a diff will allow me to send you updates/fixes etc. What about images? I suggested to the Sun people at one time that things like the rotate(double rad) should have an image which displays the rotation. This is needed since the Graphics object has a coordinate system which is opposite to the one you learned in math school.. Classical programmers mistake (which IMO means bad docu) > > Please cc answers as I'm not subscribed. > > Please subscribe to the list. Just did. - -- Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAY0POCojCW6H2z/QRAlBRAJ9qBX/Fcye9g4a/mVR2lu4WZR/3YQCdGTVA O1nKy7ewk6P4h+YRZZrVBa8= =g0T0 -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Classpath build process and VM-specific issues
Etienne Gagnon wrote: > Grzegorz Prokopski and I are working on a set of m4 macros (that would > not require understanding "m4" to be used) to allow minimal > customization of VM*.java classes for each VM, while retaining most of > the code sharing across all VMs that can work with the default VM*.java > setup. My vote is firmly against introducing macros. Unless it is done in such a way that the resulting code is still valid Java code, so that Classpath can still be compiled without running m4 or any of the build scripts. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Classpath build process and VM-specific issues
David Lichteblau wrote: > BTW, on the topic of VM* classes: Has there been agreement on > java.lang.VMClass? The proposal was to make its methods static (and > possibly add an "Object vmdata" field to java.lang.Class instead). I don't think anybody objected to this proposal. I'd definitely would like the vmdata field though. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
On Thu, Mar 25, 2004 at 09:48:58PM +0100, Jeroen Frijters wrote: > Etienne Gagnon wrote: > My vote is firmly against introducing macros. Unless it is done in such > a way that the resulting code is still valid Java code, so that > Classpath can still be compiled without running m4 or any of the build > scripts. The m4 macros would only reside in the VM*.java classes, not in any other class. Firthermore, if we keep the vm/ tree around, the m4 stuff would only be in the vm/ tree, so any VM that does not want to use the m4 system (GNU m4 is highly portable and Free!!!) could get Classpath to work. We could also make sure that "make dist" builds a .tar.gz with "vanilla" VM.java files that do not need m4 to build. This is what "make dist" does in SableVM. Note that the objective is: 1- *minimal* macro stuff. 2- Maximal sharing across "ordinary" (C-based, Unix-y platform) VMs. Currently, cvs co of Classpath *DOES* require auto* tools and m4. Would that suit you? Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Classpath build process and VM-specific issues
Etienne Gagnon wrote: > The m4 macros would only reside in the VM*.java classes, not > in any other class. I understand, but I'd still rather not have the additional dependency. > Currently, cvs co of Classpath *DOES* require auto* tools and m4. No, if you somehow get a Configuration.java (e.g. manually create it), you can build Classpath by simply running jikes (or another Java compiler). > Would that suit you? It doesn't really matter to me. I don't mind maintaining my own copy of the VM classes. However, I do think it raises the barrier to entry yet again. And that is not good. We want to make the project more accessible, not less. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
As the Classpath Turns - Introducing Planet Classpath
Hi all, Some of us saw each other in Belgium last month, some of us meet on irc [*] from time to time and sometimes we have huge cross-mailinglist discussions. Now we also have a "Planet" to keep each other informed about interesting stuff! I have setup "Planet Classpath": http://classpath.wildebeest.org/planet/ It aggregates some of the diaries written by GNU Classpath, gcj, Kaffe, IKVM.NET, java-gnome, Debian java, Jikes RVM and SableVM hackers. Not always relevant, but always fun to read! I hope it will give a feeling of working together with people on a bigger project (there is so much non-Classpath work that is still very relevant to the Classpath community!) Hope you like it. If you work on something Classpath (or freevm) related and write about it from time to time please let me know and I'll add you to the planet. It doesn't have to be "100% pure" Classpath. It is also nice to see what other things people find interesting. But I believe writing a movie review from time to time is mandatory :) Cheers, Mark [*] #classpath on irc.gnu.org signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Classpath build process and VM-specific issues
On Thu, 2004-03-25 at 16:54, Jeroen Frijters wrote: > > Would that suit you? > > It doesn't really matter to me. I don't mind maintaining my own copy of > the VM classes. However, I do think it raises the barrier to entry yet > again. And that is not good. We want to make the project more > accessible, not less. To run autogen.sh you need m4 anyway. And we can make sure that once the resulting tarball is created - there's no need for m4 anymore (besides this one class you've mentioned). The important thing here is also what exactly we think of when we say "macro". This is very ambiguous and many (me including) have bad thoughts when reminded about macros/#defines etc. like in C preprocessor. (macro hell? ;-) The idea, as I see it, is not to scatter the code with macros. We have already done this. SableVM would be nightmare to maintain if we didn't have m4 macros. BUT. There's quite a big BUT here. *These* macros importantly improve readability of the source. In particular, they were designed so that they don't interfere with normal C syntax, most of their usages look just like any C code, and for the non-introduced people, the macros we have may just be nonexistant at all. If you tried to take a look at the parts of my FOSDEM presentation where I was also showing some examples of how we use macros: http://gadek.debian.net/FOSDEM/FOSDEM-Prokopski-SableVM.pdf Now - I don't think we want that advanced m4 usage in Classpath because it doesn't seem needed, but we'll try to make it as nice and userfriendly as possible. Surely it should be about just as easy to read as any other .java file. I hope to be able to show you a working implementation in not too distant future. Cheers, Grzegorz B. Prokopski ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Archie Cobb wrote: > Etienne Gagnon wrote: > > Build Process > > = > > > > 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, ...). > > > > It would be impractical (or even maybe impossible) to setup a *single* > > "classpath" installation on a user system, meant to be used by distinct > > VMs/compilers on this same system; one can simply think of the ever > > changing VM interface, VM-specific issues, etc. > > Hmm, not sure I agree. > > For example, JC uses a completely stock Classpath installation. JC > includes its own version of certain core classes and these classes > are inserted in the boot classpath in front of glibj.zip. All > Classpath's native libraries are used (or overridden) as-is. Same for Kissme. It currently uses a bog standard Classpath glibj.zip file, and overrides roughly a dozen Java classes with its own versions. IIRC, the overridden files are nearly all in the vm/reference tree.' As with JC, Kissme puts its override classes in a ZIP file on the boot classpath ahead of glibj.zip. > Also, I'm worried that requiring the code associated with VM X > spread across two source trees (the VM's and Classpath) could make > maintenance more difficult. I think I agree. The current setup is more convenient for me. The alternative would require me to maintain a complete vm-specific tree in the Kissme source base ... and manually merge in changes from the Classpath reference tree. > However, I'm open to this change.. for JC it would just be a no-op. Same for Kissme ... at least for the proposed change to the Classpath configure.ac file. > > The objective: Share as much code between "normal" VMs (that need nothing > > really special in base classes), and intuitive source file locations. > > That's a worthy objective... Agreed. However, for Kissme (and JC?) code sharing is pretty much complete as it is. And I don't see anything counter-intuitive about Classpath's current directory structure. The only criticism I'd make of the current Classpath file structure is that I don't think there should be ANY VM specific code in the tree ... or in the configure.ac file. (Obviously, I don't count the Classpath vm/reference classes or jni/cni native libraries as VM specific.) -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Tests (Was: Classpath post from zander@javalobby.org requires approval)
> First impression was a bit strange; 70195 of 3581269 tests failed on Suns > JDK 1.4.2_02... seems like lots of tests copy-pasted but not finished. IIRC, the bulk of the tests, (including the failing tests) are in a single file that tries to exercise Unicode support. I looked it once, and concluded that the problem was that it was targeting an old Unicode codeset. I've commented out the Unicode testcase file in the key file I use for Kissme regression testing. The result is roughly 150 failing tests out of roughly 11000. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Tests
Hi Thomas Thanks for your interest in writing test cases! Just in case you had absolutely no preference about where to start, I'd propose javax.swing.tree and javax.swing.table. IMHO, unit tests for these classes would be really helpful for making sure that a prospective implementation in Classpath actually works. And since they are model (instead of view) classes, tests can be written in the same way as for any other non-visual class. But this is just a suggestion, you're of course free to do anything that you want... Best regards, -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
