Re: Removing the TARGET_* layer or not ?

[Mark Wielaard]

Hi,

 BTW for people who have no idea what this is actually about please read
 about the TARGET layer in native/target/readme.txt (GNU Classpath CVS).
 Autoconfiscating is explained in "The Goat Book":
 http://sources.redhat.com/autobook/autobook/autobook_237.html

On Fri, 2004-08-06 at 07:47, Steven Augart wrote:
> If we are going to be using this stuff, we need a clear justification 
> for it.  I would suggest that we create subdirectories for a couple of 
> these embedded platforms that Classpath is running on, and populate 
> them, so that we can see what these extreme cases actually look like.  
> As I understand matters, if AICAS is distributing software that uses 
> Classpath on such platforms, then they also must be distributing the 
> source code for the portability layer that Classpath requires in order 
> to work on those platforms.  If so, then we should have that all in the 
> source tree, so that we can see why this is needed.  Does this make 
> sense?  (It's almost two in the morning here in New York, so it may not :))

I think this makes sense and explains why people see the TARGET layer as
just an extra (obfuscated) layer of indirection. We don't have any
evidence that it actually works since we don't use it ourselves. And
people are looking at libgcj and kaffe and notice they do have many
ports to different platforms, are mostly similar to GNU Classpath, and
do use autoconf to select the implementation they need for each
platform. So clearly people want to mimic that. And it is what the GNU C
coding standards recommend: http://www.gnu.org/prep/standards_27.html

Tom Tromey said that for libgcj they use a hybrid approach. For Posix
like systems they use just one source file that uses autoconf checks to
see what/how things work. For completely different systems they just
compile/link against a completely different implementation source file.

I think this is the way forward if we want to both keep the TARGET layer
for some systems and autoconf for those systems were it works. The trick
would be to come up with an good design/interface to make this work. My
suggestion would be to better split the JNI functions from the actual
implementation. In each native package directory we already have a
java[pacakge].c file that defines common pacakge functions
(native/jni/java-io/javaio.c, native/jni/java-nio/java_nio.c,
 native/jni/java-net/javanet.c, etc).
I propose we put all real functionality in these files and make the
java_[package]_[class].c JNI source files do only the JNI wrapping of
these real implementation methods. So all TARGET layer or
autoconfiscated stuff would be moved inside the common package functions
C source files.

I haven't actually tried doing this, so it might not work, but it might
be a way to support both autoconfiscation and a target layer for those
platforms that aren't autoconfiscatable.

One additional benefit might be that if the common package functions C
source files don't contain any JNI constructs that we might be able to
more easily share native implementations between JNI and CNI based
systems like libgcj. (This is just speculation though, I haven't
investigated if we can actually do this.)

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part