Re: Aicas again

[Casey Marshall]

On Jan 23, 2006, at 7:02 PM, Dalibor Topic wrote:

> If the new native layer code turns out to be something that does  
> more harm then good, then it should be either autoconfiscated, to  
> save what makes sense saving, or reverted and presumably gradually  
> rewritten to remove the macros for good. I am not sure if it's too  
> early to tell, I have not looked at the rewrite in past week myself.

One salient point, I think, is that this goes against the standard  
way GNU packages are written, which seems to me to basically be to  
target GNU, but try to be as portable as possible, and use autoconf  
to sort out the messy bits.

And, a lot of the code I've looked at breaks GNU's style rules  
(besides using macros absolutely everywhere), which I don't like.

It does make debugging much harder, so that right there is a negative.

> I doubt that will change much for Darwin, either way, since Darwin  
> is different enough from Linux to trigger portability issues. The  
> same would be the case if GNU Classpath had more developers using  
> Cygwin, which also gets regularly broken, in my experience, and  
> will get regularly broken in the future no matter what approach to  
> portability layers we take.

I do also think there is value in just writing UNIX-portable code; it  
seems, to me, to encourage better thinking about what one is writing,  
without relying on some obscure OS-specific crutch. It is like when I  
hear C# or Java programmers say they can't write anything lower  
level, because they depend too much on features (which are often  
overly generic and inefficient) tied to that environment.

> Runtimes that care about niche platforms like Darwin, Cygwin,  
> Solaris, or eCos are at any time able to write and maintain their  
> own code for the native layer anyway thanks to the VM interface  
> layer, and several runtimes seem to be working fine that way.

And that's what Aicas should do! This target-native stuff seems to  
work really great for them, since they push it so hard. But in the  
end it isn't terribly portable or usable by the community, and for  
the life of me I don't see what value they get out of the JNI code  
that wraps all of these macros. It seems to me like writing a POSIX  
layer for whatever they are targeting would be easier -- why is  
`TARGET_NATIVE_ERROR_TRY_AGAIN' better than just writing your own  
`#define EAGAIN?' Why can't you just call `TARGET_NATIVE_LAST_ERROR'  
`errno' for platforms that don't have a real errno?

By the way, I don't want to sound like I'm just picking on Aicas  
here; I should have introduced this as a discussion on just the  
native layer, not this company in particular. If they had a good  
suggestion on how to write the native interface, then I'd be fine  
with it. I just think this one is extraordinarily bad.

> I think the interesting question is where to draw the line what  
> needs to be included in GNU Classpath (and at what cost) and what  
> doesn't.

I think a nice, simple, almost reference-implementation style native  
library makes sense for Classpath (for the things that make sense to  
write as straight JNI code; truly VM-specific stuff needn't be  
included). As far as targets go, popular platforms that free software  
users use is best -- and that may not include Darwin, but GNU/Linux  
and the sane BSD's should be supported.

> I believe we'll be able to draw a clearer line once the last native  
> layer experiment is over, but I haven't been following the  
> discussion closely enough to be able to tell if it is over by now,  
> or if the current state of afairs is some transition state to  
> something else.

Is this really mostly an experimental thing? If it is, then it has  
even less business being the only way of compiling native code right  
now. It should have been done on a branch, especially since it is  
continuously breaking things.