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
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
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.
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
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
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
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
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
-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.
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
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
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
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,
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
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
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
16 matches
Mail list logo
