Re: Bug tracker link

[Patrik Reali]

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

[Patrik Reali]

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

[Patrik Reali]

--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

[Patrik Reali]

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

Re: cvsignore files

[Patrik Reali]

Cool! This is a great improvement.
Thank you very much.
-Patrik

___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath

cvsignore files

[Patrik Reali]

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

[Patrik Reali]

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

Re: Javadocs

[Patrik Reali]

Like for the daily builds, I'm willing to offer my machine to make a daily 
or weekly documentation build if somebody provides the script for this.

Because my uplink connection is weak (128 kbit/s), I would prefer to upload 
the results somewhere else (e.g. some gnu server) instead of serving them 
from the same machine.

Maybe we can talk with the sysadmins of www.gnu.org to be able to upload a 
tarred version of the doc and automagically unpack it on the server

-Patrik

Patrik Reali
http://www.reali.ch/~patrik/
--On Mittwoch, 16. Juni 2004 11:45 -0400 Bryce McKinlay 
<[EMAIL PROTECTED]> wrote:

David Gilbert wrote:
I'm familiarising myself with GNU Classpath at the moment, with the hope
that I can contribute something in the future (copyright paperwork is in
process).  A quick question - are there any Javadocs online anywhere?  I
couldn't find any, but maybe I missed somewhere obvious?  Anyway, I
generated them from source (using javadoc) and would be happy to upload
them somewhere if that would help.

As far as I know, the classpath javadocs are not yet officially online
anywhere. It would, however, be cool to have them on the web somewhere,
and automatically generated from CVS classpath sources.
Regards
Bryce

___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath


___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath

Q: How do you keep your sources in synch?

[Patrik Reali]

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?

[Patrik Reali]

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: Bad link for 0.08 download?

[Patrik Reali]

Hi Stephane,

you are right! The file was renamed. (Anyone know more?)

Have a look into  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: Classpath build process and VM-specific issues

[Patrik Reali]

--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

[Patrik Reali]

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++?

[Patrik Reali]

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

[Patrik Reali]

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

[Patrik Reali]

--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: 0.08 NEWS

[Patrik Reali]

--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

[Patrik Reali]

--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: Query on stacktrace management logic

[Patrik Reali]

--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

[Patrik Reali]

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/1532254&mode=thread>

27 Feb: Sun Agrees to Talk to IBM over Open Sourcing Java: 
<http://developers.slashdot.org/article.pl?sid=04/02/27/1610245&mode=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

[Patrik Reali]

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

[Patrik Reali]

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)

[Patrik Reali]

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 (GC Interface)

[Patrik Reali]

tc.).
> 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
--
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: JIT pluggability (ABI Issues)

[Patrik Reali]

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: Java Runtime Matrix for UserLinux

[Patrik Reali]

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

JNode project

[Patrik Reali]

Hi!

I just discovered the JNode project (http://jnode.sourceforge.net/), whose 
goal is to provide a complete OS written in Java. It is LGPLed and uses 
Classpath with some modifications (being native java, they do not use 
native methods).

Merry Christmas,
 Patrik

Patrik Reali
http://www.reali.ch/~patrik/


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Help and input needed

[Patrik Reali]

--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: Revolution Action (was: Re: [Little Off Topic] Revolution ison ; ))

[Patrik Reali]

> How many people want to attend (Brussels, Belgium, the weekend of 21-22
> February 2004)? If I followed the messages and irc discussions correctly
> then Arnaud, Chris, Tom, Dalibor, Stephane, Michael and myself will be
> there at least.

I really want, but cannot tell yet (depends on my army schedule for next
year). It should be fixed in the next weeks.

-Patrik



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Tests, Documentation

[Patrik Reali]

I could host the Classpath documentation on the Jaos site, but only as a
temporary solution.


-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: Tests, Documentation

[Patrik Reali]

Hi Sascha,

I completely agree and support your wishes! In fact, it would be nice if the
whole classpath and its documentation (javadoc) would be rebuilt on a
regular base and offered through the website.

I disagree on one point: testing doesn't slow down development. It may be
boring, but it is like a safety net that prevents developers from comitting
buggy code and allow to detect errors early (and thus much faster) when they
are inserted.

-Patrik

Patrik Reali
http://www.reali.ch/~patrik/
http://www.oberon.ethz.ch/jaos


> Dear co-hackers,
>
> having read quite a bit of Classpath code, I'd like to express two wishes.
>
> First, please write more test cases. I agree that it is boring, dumb, and
> taxing; testing slows down development. But it's also the most reliable
> way to make sure that code really works. If anyone needs to change our
> code in five years, they'll want to know whether their change has any
> serious impact. Without a large test suite, this is close to impossible.
>
> Second, please write understandable documentation for every single
> method. Developers should be able to create free programs without
> referring to external documents. These could disappear at any time.
>
> In other words, I think that we really need to improve the quality of our
> code. Building a sound foundation for others is not the same as some fun
> week-end hack.
>
> Thank you all,
>
> -- 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: VMInterface addition: Make native library names part ofVMInterface

[Patrik Reali]

- 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

[Patrik Reali]

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

[Patrik Reali]

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

[Patrik Reali]

ed token
`include/config.h'
./configure: line 1336: `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

[Patrik Reali]

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

[Patrik Reali]

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

[Patrik Reali]

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

[Patrik Reali]

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.()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.()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)
> ()V
> 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: Workshop Oct. 14

[Patrik Reali]

Hi Sascha,

thank you for taking the burden of organizing this! Here are my (small)
propositions.

I would like to hear the people / projects taking part to the BoF present
the goals of their projects and their roadmap, to know what is going on and
in which direction classpath will (or will have to) evolve, and identify
possible synergies.

I think that your idea of making an extended tasklist (including required
knowledge and estimated work) is great; the BoF should continue this, by
identifying other possible tasks. Maybe it is possible to find more
developers by launching this as "adopt a piece of classpath" or with some
other funny/fancy slogans

The VM integration is also an important point. We could work on improving
the VM Integration Guide by explaining the rationale of this design, in
particular when are VM classes used instead of native methods and vice versa
(and thereafter checking whether the code follows this rationale).

And maybe (but only as last topic) you could schedule the discussion about
the NotYedImplementedException, as I guess the list may not have reached an
agreement on this before the LinuxKongress.

-Patrik


- Original Message -
From: "Sascha Brawer" <[EMAIL PROTECTED]>
To: "GNU Classpath" <[EMAIL PROTECTED]>
Sent: Friday, September 26, 2003 5:23 PM
Subject: Workshop Oct. 14


> Hi all,
>
> as announced, there will be workshop for GNU Classpath developers on
> October 14 in Saarbrücken/Germany.
>
> Does anyone wish to discuss a specific topic, in addition to graphics?
> I'd like to prepare an agenda for the afternoon, so we can make most of
> the time.
>
> 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
>
>



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: file.encoding property

[Patrik Reali]

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

[Patrik Reali]

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?

[Patrik Reali]

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: Towards GNU Classpath 0.07 and 1.0

[Patrik Reali]

> 0.07. The best thing for the next snapshot is to just set a date when we
> want to release it. I propose to just set this at the last week of
> November (three months from now) since we are already making real
> progress. Look at the bug/patch database for a number of improvements to
> object streams, java.text, rmi and javax.naming that are just waiting to
> get checked in. Much thanks go to the Kaffe team that has been importing
> Classpath libraries like mad the last couple of weeks and simultaneously
> debugged them and provided patches! And apologies to anyone whose
> patches didn't make it for the 0.06 release.
> If that works out then we can just keep on doing snapshot releases every
> three months till...
>

I think that setting the dates is quite useful, at least it gives an
indication of
classpath's progress; it also helps (at least me) to plan the releases of
the Jaos
to keep in synch with classpath and be able to start the migration early to
contribute
with feedback and comments about the new code.

At the moment it is not clear [to me], whether the releases are time-driven
or
feature-driven (I guess rather time-driver), but in both cases it would be
nice
to have a paragraph on the release policy on the web-site and the list of
conditions which trigger a new release.

I admit that 0.06 took me by surprise and I currently do not have the
resources to
upgrade Jaos to the 0.06 in the next days.

-Patrik

--
Patrik Reali
http://www.oberon.ethz.ch/jaos/



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Preparing for 0.06 release

[Patrik Reali]

> > 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

[Patrik Reali]

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

[Patrik Reali]

> 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

[Patrik Reali]

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

Re: Problems with Character

[Patrik Reali]

From: "Eric Blake" <[EMAIL PROTECTED]>
> I think the latest version of both files in Classpath should work.
> Could it possibly be a VM error in adding two chars, and casting the
> result back to a char?  The data is encoded as signed offsets from the
> current character, but stored as unsigned chars in the String constants;
> so if your VM does the math wrong, you may be getting a weird index.
> Another possibility - is your VM correctly handling reading in the UTF
> string from the constant pool and converting it to char[]?
>
> Can you do some more detective work? What do you get for
> Character.readChar('a') and Character.readChar('A')? If I'm reading
> CharData correctly, readChar('a') should be 0x1b02, so that you then
> index UPPER[54] == '\uffe0' (in other words, 'a' + -30 => 'A').
> readChar('A') should be 0xd01, so that you index LOWER[26] == ' ' (or
> 'A' + 32 => 'a').
>

I'm sorry. I did cry for the wolf too early. The error must be in my JVM.

To confirm this I just moved the whole CharData and Char into an own
class and let the tests run on another JVM using this class instead of
Character.
There's no error there.

I hope I didn't cause too much panic with this

-Patrik



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Problems with Character

[Patrik Reali]

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: Locale initialization error

[Patrik Reali]

From: "Eric Blake" <[EMAIL PROTECTED]>
> Patrik Reali wrote:
> >
> > Hi!
> >
> > I've run into a initialization problem when class java/util/Locale is
> > initialized.
> >
> For these constructors, I tried adding a trusted constructor which does
> no capitalization.  I'm still running into a problem here:

Your solution with the trusted constructor works properly.
On my side, I tried a different approach:

  public Locale(String language, String country, String variant)
  {
if (defaulLocale == null) {
  this.language = language;
  this.country = country;
  this.variant = variant;
} else {
  this.language = convertLanguage(language);
  this.country = country.toUpperCase();
  this.variant = variant.toUpperCase();
}
this.hashcode = (this.language.hashCode() ^ this.country.hashCode()
 ^ this.variant.hashCode());
  }

This works too. It's up to  you to choose the solution you prefer.

> According to the Javadoc of java.lang.System, there is no guarantee that
> the properties user.language, user.region, or user.variant exist.  Does
> Sun document anywhere that these must exist, or who must supply them?
> Or is it just a VM integration requirement of Classpath?  If the latter,
> then is it documented in the Classpath/VM integration guide?
>
VMSystem.java doesn't list those properties.

Locale should maybe install some defaults, if no properties are available:
private static Locale defaultLocale =
new Locale(System.getProperty("user.language", "en"),
   System.getProperty("user.region", ""),
   System.getProperty("user.variant", ""));

The language is important, because it is used for the convertions.


> I just committed my hack shown above - did it do the trick for you?

It works, thanks.

> (How I wish that I could compile a working VM on cygwin, to answer that
> question for myself).
>
I first had the opposite problem: testing the VM without API. And as I'm
still
testing my JVM, I never now if the error is on my side or not. I would offer
you my
Jaos, but it runs only on the Aos system: nice but different!

Ciao,
  Patrik



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Locale initialization error

[Patrik Reali]

Hi!

I've run into a initialization problem when class java/util/Locale is
initialized.

The static initialization of Locale creates many instances of class Locale,
whose
constructor calls String.toUpperCase.

  public Locale(String language, String country, String variant)
  {
this.language = convertLanguage(language);
this.country = country.toUpperCase();
this.variant = variant.toUpperCase();
this.hashcode = (this.language.hashCode() ^ this.country.hashCode()
 ^ this.variant.hashCode());
  }


String.toUpperCase uses the default locale

  public String toUpperCase()
  {
return toUpperCase(Locale.getDefault());
  }

but since Locale is still initializing, it does not exist and causes a
NullPointerException in the String.toUpperCase(Locale loc)
fuction as soon as loc is used.

The problem happens also when String.toUpperCase and String.toLowerCase
are invoked directly, as they cause the initialization of Locale too.

I'm not sure if I should post this to the patch manager too, as I have no
patch
available. My approach would be to avoid calling toLowerCase during the
initialization
of the class, by setting using a flag or by using a different (private)
constructor for
the initialization (but this would require a dummy parameter).

Here's the stack dump (as generated by the Aos system) of the problem.
I removed the local variable informations; the numbers after the procedure
are used to distinguish the overloaded methods.

_jlString.String.toLowerCase5543 pc=7751
_jlString.String.toLowerCase1539 pc=7717
_juLocale.Locale.convertLanguage pc=1588
_juLocale.Locale.init7470 pc=1321
_juLocale.Locale.init2121 pc=1260
_juLocale.clinit pc=54
JVMSystem.Execute pc=2352
JVM.CheckInitialized pc=7983
_jlString.String.toUpperCase1539 pc=8251
_StringTest.main pc=1053
JVMSystem.InvokeMethod pc=2388
JVMBase.Method.invokeNative pc=3744
JVM.MainThread.run pc=1256
JVMThreads.RunBody pc=781


----
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 ?

[Patrik Reali]

> 
> 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