Stuart Ballard wrote:
"Edouard G. Parmelan" wrote:
Could you add value of serialVersionUID in Japize ?
Hey, great idea :) I'll try to get this done by tomorrow (my hacking
gets done on the train to and from work).
Well, it took a little longer than I thought due to Real World work
Stuart Ballard wrote:
To my knowledge, even though static final constants are part of the
public API, their values are not given by Sun and so they have to be
determined experimentally.
Exactly why I want to report them as part of Japize... to make it
possible to automate testing that
"Edouard G. Parmelan" wrote:
Could you add value of serialVersionUID in Japize ?
The following code will retreive/compute this value:
ObjectStreamClass stream = ObjectStreamClass.lookup(clz);
if (stream != null) {
// this class is Serializable, register
Godmar Back wrote:
Have you tried calling 1.2's Class.forName(,false,) and then
using getField().getValue() on a final static field?
Does doing this invoke clinit?
I need to be able to run on 1.1...
In 1.1 w/ reflection, you're obviously out of luck since
Class.forName will
Okay, try it again now.
We now also search superinterfaces if you invoke Class.getMethod() on
an interface class.
However, since there's no notion of superinterfaces at the bytecode level,
there's also no ordering - this means that I believe that the result of
such a getMethod call is not
Godmar Back wrote:
Okay, try it again now.
We now also search superinterfaces if you invoke Class.getMethod() on
an interface class.
Excellent. Kaffe now gives exactly 0 "M" (the NoSuchMethodException) and
only about 7 or 8 "!" (the non-equality) on the whole of its class
libraries. As
Godmar Back wrote:
In 1.1 w/ reflection, you're obviously out of luck since
Class.forName will call clinit
Blah. I guess I should explore options that look at the bytecode, rather
than reflection, then... (the most important reason I need to run on 1.1
is to get reliable docs *for* 1.1)
methods twice. It is safe to assume that two calls to getMethod() with
the same arguments *in the same run of Kaffe* (and without the
possibility of any classes being gc'd) will always return the same
method, right?
Right.
- Godmar
Godmar Back wrote:
Can anyone confirm that this is or is not a bug? Blackdown JDK 1.1.8
does not display this behavior, and I can't think of an easy workaround
in my code to get the results I expect.
Well, yes that's probably a bug.
I worked around this by testing whether
Stuart Ballard wrote:
Well, I've made some changes to the class since I "announced" it here a
while back and put up a homepage at http://stuart.wuffies.net/japi/ .
The reason I mention this is (1) I'd like feedback, and (2) I have the
results of running japicompat between jdk11 and kaffe,
"Edouard G. Parmelan" wrote:
Stuart Ballard wrote:
Well, I've made some changes to the class since I "announced" it here a
while back and put up a homepage at http://stuart.wuffies.net/japi/ .
The reason I mention this is (1) I'd like feedback, and (2) I have the
results of running
Stuart Ballard wrote:
Raw idea: Did you think it's possible to use a ClassLoader to load
jdk1.1 classes and an other to load Kaffe (or GNU Classpath) classes ?
Yes, but URLClassLoader is 1.2 only and I'm using 1.1 primarily. I could
write a ClassLoader from scratch, but that sounds
"Edouard G. Parmelan" wrote:
For now, Japize does not extrate final values (or I missing something)
so with method Class.forName(String name, boolean initialize, ClassLoader
loader) [yes it's 1.2] clinit is never called, so no native code :-)
Actually, Japize does extract all field values
Stuart Ballard wrote:
However, I think that asking for the value of a field, even a public
static final one, is enough to cause clinit to get called... right? :(
It depends if it is compile time constant. If yes, then clinit will not
be called. From JLS 12.4.1
[when initialization occurs]
Artur Biesiadowski wrote:
Stuart Ballard wrote:
However, I think that asking for the value of a field, even a public
static final one, is enough to cause clinit to get called... right? :(
It depends if it is compile time constant. If yes, then clinit will not
be called. From JLS
I worked around this by testing whether
mth.equals(cls.getMethod(mth.getName(), mth.getParameterTypes())). This
seems to expose another bug because on numerous occasions I get a
NoSuchMethodException from this check, which shouldn't ever be
possible... the imaginary conversation between
Have you tried calling 1.2's Class.forName(,false,) and then
using getField().getValue() on a final static field?
Does doing this invoke clinit?
If not, we should be able to fix Kaffe accordingly; I bet 10:1
it will call clinit.
But, actually, I don't really understand what that should be
17 matches
Mail list logo
