On Jun 24, 2005, at 5:47 PM, Rodrigo Kumpera wrote:
If the API is meant to be language agnostic, it's just a bunch of
constants and a function vector. This should provide enouth to build a
better layer for each language.
The API between a Java JITer and a C JVM should be coarse grained
since cross-language calls are slow. ORP defines a very nice C++ only
interface, but I doubt it would work well for the C++ <-> Java
scenario.
This might be too 80's, but a good interface can be well defined in
terms of functions, structs and constants. It will work just fine for
C/C++ and would not be that painfull or slow to use from Java (or
whatever comes into our mind).
Or we can use IDL and let it be object oriented.
How would that work?
geir
Rodrigo
On 6/24/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Jun 24, 2005, at 5:17 PM, Weldon Washburn wrote:
On 6/23/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Where is code we can start examining? What do the the java-on-java
implementations do?
geir
Geir,
I can't talk about code just yet.
I know, but I'm going to taunt you anyway! Taunt!
Seriously, how about referring us to code in ORP at sourceforge?
But I think we can at least get
started on the basic, low controversy APIs. For example, the access
and property flags defined in the class file format are straight
forward boolean values. While the access/property flags may be
extended, it is unlikely that basic notions such as public/private
access would ever be removed. Below is a first stab at the API to
retrieve the values contained in internal classloader data
structures.
Its understood that the JIT won't use all of the below APIs. For
example, some of the access properties issues are dealt with during
resolution and not by the jit. I used the java 1.5 version of
Chapter
3 of the Java Virtual Machine Spec.
Comment/questions are appreciated.
Thanks
Weldon
Class access and property modifiers (table 4.1)
bool Class::is_public(); // ACC_PUBLIC
bool Class::is_final(); // ACC_FINAL
bool Class::is_super(); // ACC_SUPER
bool Class::is_interface(); // ACC_INTERFACE
bool Class::is_abstract(); // ACC_ABSTRACT
bool Class::is_synthetic(); // ACC_SYNTHETIC
bool Class::is_annotation(); // ACC_ANNOTATION
bool Class::is_enum(); // ACC_ENUM
Field access and property flags (table 4.4)
bool Field::is_public(); // ACC_PUBLIC
bool Field::is_private(); // ACC_PRIVATE
bool Field::is_protected(); // ACC_PROTECTED
bool Field::is_static(); // ACC_STATIC
bool Field::is_final(); // ACC_FINAL
bool Field::is_volatile(); // ACC_VOLATILE
bool Field::is_transient(); // ACC_TRANSIENT
bool Field::is_synthetic(); // ACC_SYNTHETIC
bool Field::is_enum(); // ACC_ENUM
Method access and property flags (table 4.5)
bool Method::is_public(); // ACC_PUBLIC
bool Method::is_private(); // ACC_PRIVATE
bool Method::is_protected(); // ACC_PROTECTED
bool Method::is_static(); // ACC_STATIC
bool Method::is_final(); // ACC_FINAL
bool Method::is_synchronized(); // ACC_SYNCHRONIZED
bool Method::is_bridge(); // ACC_BRIDGE
bool Method::is_varargs(); // ACC_VARARGS
bool Method::is_native(); // ACC_NATIVE
bool Method::is_abstract(); // ACC_ABSTRACT
bool Method::is_strict(); // ACC_STRICT
boot Method::is_synthetic(); // ACC_SYNTHETIC
That's pretty non-controversial :)
So this API is really for the classes Method, Field and Class, rather
than a bigger C API. Does this make it harder for other languages to
use or implement? (I have to admit it's going to take a few to start
thinking in C again...)
geir
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
