[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removing the TARGET_* layer or not ?

From: Steven Augart
Subject: Re: Removing the TARGET_* layer or not ?
Date: Sat, 07 Aug 2004 00:29:59 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

Andy Walter wrote:

I'm sorry for the trouble which was caused by the target layer. Actually, I'm quite surprised about the massive critique now. When we asked to check it in more than one year ago, there was very little feedback and the feedback we got was mainly quite positive.

Thank you for the kind note. I think some of the difference may be that several of us (I'm thinking of Michael Koch in particular) now have been doing considerable work in C on JNI.

We are currently preparing the native layers of

- Solaris
- embOS

for check in into the Classpath repository next week. Especially the embOS layer for file I/O illustrates some bigger differences of embedded operated systems. Since embOS is unfree, I expect the RTEMS port will be more interesting to most people in this list. (I have to admit that the differences are not as big there).

I appreciate you preparing the native layers for inclusion into the classpath repository. Is any one of those platforms a platform which has a compiler that lacks a 64-bit type?

General Questions:

1) Is any classpath user other than AICAS on systems where there are only C '89 compilers available?

2) Anyone other than AICAS on systems where there is no 64-bit type available?

3) Anyone other than AICAS on systems where there is no support for "inline"? And, if you are, is avoiding the overhead of two or three function calls when performing a C call file handling functions very very important to you?

4) Anyone, other than AICAS, on a system that doesn't support POSIX?

If only AICAS has some of those four constraints (I suspect this is so), then I think the Classpath project (that's us, folks!) will have to look at this from a software project management point of view, and make a direction decision about whether it is appropriate for the project's native code to meet those constraints, given the negative consequences that follow:

The consequence of constraint (1) is that we are restricting ourselves to C '89. (For example, I define a variable in gthread-jni.c that I do not use until about a hundred lines later. This is complicated.) The consequence of constraint (2) is that all operations on a "jlong", except for passing them as parameters (this includes comparison for equality and assignment to anything other than another jlong) have to be wrapped with macros whose names take up half of a screen line. The consequence of the two parts of constraint (3) is that we apparently have to define use macros for operations that on every other multi-platform system I've worked on are handled via a uniform function interface (such as Mozilla's "nspr" portable runtime). The consequence of (4) is that we have to worry about multi-platform support for what would otherwise be simple calls to open(2), seek(2), and fstat(2).

The megative consequences of all of these put together is to hide bugs that would otherwise be obvious to experienced C programmers, and to discourage some programmers from working on the native code. This is the case because the JNI code in Classpath is not really written in C. It's written in a stack of macros on top of macros on top of macros, which eventually turn into C.

I am looking forward to learning more about the portability needs of the many projects that use Classpath.

Steven Augart

Jikes RVM, a free, open source, Virtual Machine:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]