First off, something fishy is going on ... I'm not getting this message on
the Japhar list, just Classpath. Am I still on that list, after the recent
list changes?
> From: Petter Reinholdtsen [mailto:[EMAIL PROTECTED]]
>
>
>
> > OK, I got around to testing the new patch and realized that the
> > classpath.zip I put up on classpath.org wasn't quite right--some
> > sort of version problem. I just put one up that *does* work--I
> > tested it tonight with *gasp* Hello World!
>
> :-)
>
Actually, I've gone through and ran some of the Japhar tests. We're running
OK, not quite beta quality, but OK. Most problems are with the class
library itself, and some missing classes.
> I had a look at the patch today. I have some questions and some
> change request before I add it to Japhar CVS.
>
> Why was DLL loading order changed on arch/dynamic_loading.c?
>
I wanted one ifdef instead of two :) Plus, I didn't think order mattered in
this function. Threads haven't started yet, and there is no crosstalk
between libs. Changing it back raises no issues.
> I would like Classpath to change it's DLL names from javaio and
> javalang, to classpath_io and classpath_lang. That way I can localize
> the required Classpath change to DLL_findAlongPath().
>
Remember, though: we have to load *both* your "lang" and ours, and both your
"reflect" and ours. We have the VM-independent portion of lang sitting up
in Classpath, and also VM-independent reflect. Then there are the
cp.java.lang and cp.java.lang.reflect dirs. Only with the union of the
Japhar+Classpath lang do we have all the lang and reflect functions. Thus,
even if we change javaio to classpath_io (which is just fine), there still
need to be two separate loads for lang in DLL_loadSystemLibraries(). One
yours, one ours.
Not that I mind a name change to classpath_*. That would probably be a good
thing. It should probably just be classpath_javalang, not classpath_lang.
> Could Classpath change name on the following variables, to keep them
> the same as JDK?
>
> java.lang.Class declaringClass -> clazz
> java.lang.String len -> count
> str -> value
> java.lang.Throwable message -> detailMessage
> java.lang.Thread privateInfo -> PrivateInfo
>
I am wary of making any changes deliberately to give compatibility with
private and package-protected members and/or classes from Sun. It is an
explicit step away from cleanroom. I am not a lawyer, though. I think we
should defer to Paul and his FSF buddies on this one, or anyone who really
knows the law on this.
The ifdefs for field names really do not get in the way of maintenance at
all, they aren't as disruptive as the changes to objects.c and interp.c.
Just use the defined variable names and your source is identical to what it
was before, and just as easy to change. Fixes only need be made once, and
they are propagated to Classpath and JDK automatically. It's the other
ifdefs that introduce code forking within the code itself.
> java.lang.String.offset seem to be missing in Classpath. Why?
>
Because the docs said it wasn't used, and I wasn't sure if it was ever set
to 0. offset is kind of optional anyway; it's only there to be able to make
substrings use the same character array as their parents. (And maybe some
sharing with StringBuffers, too.) Paul can enlighten us here. Perhaps it
*is* used.
> BTW: One checks for NULL pointers _before_, not after it is used.
> Have a look at objects.c:cache_fields() and try again. :-)
>
static void cache_fields(JNIEnv * env) {
int i;
class_clazzfile = find_class(env, "java/lang/Class");
for(i=0;i<class_clazzfile->num_fields;i++) {
if(!strcmp(class_clazzfile->fields[i]->name, "private_data"))
private_data_field = (jfieldID)class_clazzfile->fields[i];
else if(!strcmp(class_clazzfile->fields[i]->name, "superclass"))
superclass_field = (jfieldID)class_clazzfile->fields[i];
else if(!strcmp(class_clazzfile->fields[i]->name, "name"))
name_field = (jfieldID)class_clazzfile->fields[i];
else if(!strcmp(class_clazzfile->fields[i]->name, "signers"))
signers_field = (jfieldID)class_clazzfile->fields[i];
}
assert(class_clazzfile != 0);
assert(private_data_field != 0);
assert(superclass_field != 0);
assert(name_field != 0);
assert(signers_field != 0);
}
If you look in the caller: "if(private_data_field == NULL)
{ cache_fields(); }". The check happens in the caller, not the callee.
It's a silly optimization to avoid the method call. I spent too much time
with my head in assembly code a few years back. If you think it's better to
put it into the method, be my guest :)
> Why do you do the caching in objects.c, and are you sure it is save to
> cache this info?
>
Well, it'd be best to cache it wherever you guys are caching the ClazzFile *
for Class, String and Object. I just don't know where that is. All field
and methodIDs that are used by the core should be cached somewhere.
I do the caching because searching for these fields is very slow (a total of
10 string compares) and I want speed in the JVM. I don't mind if you want
to use find_class every time, I just think it's a waste of taxpayer CPU
cycles :) It would also involve monitors, another thing I like to minimize,
for the same performance reasons. Caching it with class, string and object
would be best.
> That is it for today. Need some sleep. I've commited some of the
> changes to configure.in and friends. I want to use FOR_CLASSPATH as
> the define to be consistent with FOR_MOZILLA. I moved the define from
> many Makefile.am's to config.h. Have a look in CVS.
>
Wow, didn't know what config.h was. This was my first time messing with
automake :)
> More later. :-)
Thanks much!
--John Keiser
