Hi folks, I hope this announcement might be of interest to some of you as
being related to and in some respects complementary to Kaffe.
I've just released the first (very experimental) version of VX32, a new
x86-based application-level virtual environment. Unlike most x86-based virtual
machin
Hi,
After checking a few things here and there it appears that we are too
strict. The VM must only rely on access flags of the class to check the
accessibility. The inner class flags are used by the other compiler and
the reflections. So we may remove everything related to inner/nested
classe
PatchSet 7032
Date: 2005/12/22 17:51:17
Author: guilhem
Branch: HEAD
Tag: (none)
Log:
More (and hopefully final) fixes for access.
* kaffe/kaffevm/access.c
(checkAccess): Simplified to the maximum according to Sun's VM
spec we must not check for specific inner classes fla
Hi Tom,
On Thu, 2005-12-22 at 09:23 -0700, Tom Tromey wrote:
> This was PR 19870. We thought it was fixed but perhaps this is a new
> instance of it.
Indeed it is. I added a slight variant of the original example to the
bug report and reopened it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=198
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
Mark> In this case it really does seem a bug in gcj -C byte code generation.
Mark> Since this is a static inner class it should create an (package private)
Mark> accessor method for the private ByteArrayOutputStream buffer field.
Mark> (jik
Hi Hanno,
On Thu, 2005-12-22 at 16:48 +0100, Mark Wielaard wrote:
> > The source compiles but executing gij with the class files breaks.
> > I narrowed down the error to a testcase I would say.
> > Java file is attached.
> >
> > # gcj -C DemuxOutputStream.java
> > # gij -cp . DemuxOutputStream
>
Hi Hanno,
On Thu, 2005-12-22 at 13:45 +0100, Hanno Meyer-Thurow wrote:
> Hi list!
> First time I send to this list so please be kind! ;)
Welcome. This message can almost not be an coincidence. So I am sharing
it with "that other" free runtime initiative "kaffe". (See CC.)
> I try to build apache
Hi Guilhem,
> Here is a better example. The previous could not be compiled directly if
> you try to compile indepedently then you'll see the runtime accepts it.
> Here I have an example which compiles and should run on a VM. However
> kaffe throws an IllegalAccessError.
In this case, my patch d
Ito Kazumitsu wrote:
Hi Guilhem,
I have met a new IllegalAccessError in eclipse. I have attached two
files which reproduce the problem.
legal2.java did not compile.
Found 1 semantic error compiling "legal2.java":
7. legal1.A a = legal1.getA();
Hi Guilhem,
> I have met a new IllegalAccessError in eclipse. I have attached two
> files which reproduce the problem.
legal2.java did not compile.
Found 1 semantic error compiling "legal2.java":
7. legal1.A a = legal1.getA();
^
*** Semantic
Hi Ito,
Here is a better example. The previous could not be compiled directly if
you try to compile indepedently then you'll see the runtime accepts it.
Here I have an example which compiles and should run on a VM. However
kaffe throws an IllegalAccessError.
Regards,
Guilhem.
Ito Kazumitsu
PatchSet 7031
Date: 2005/12/22 13:55:16
Author: kaz
Branch: HEAD
Tag: (none)
Log:
2005-12-22 Ito Kazumitsu <[EMAIL PROTECTED]>
* kaffe/kaffevm/access.c
(outerof): Removed,
(checkAccess): Simplified according to Sun's VM spec.
Members:
ChangeLog:1.4550->1.4551
Hi Ito,
I have met a new IllegalAccessError in eclipse. I have attached two
files which reproduce the problem.
The protected bit is difficult to handle apparently. I have talked with
Tom Tromey and it says that normally we should completely ignore the
accessibility flag in inner classes.
R
Ito Kazumitsu wrote:
From: Ito Kazumitsu <[EMAIL PROTECTED]>
Date: Thu, 22 Dec 2005 11:08:15 +0900 (JST)
The runtime access control is much simpler than the compile-time
access control. And we may be able to omit the checking of nested
relations of classes at runtime.
Simply omittin
14 matches
Mail list logo
