classpath-patches
[Top][All Lists]
Advanced

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

Re: [cp-patches] FYI: java-util adjustments for target/native


From: Mark Wielaard
Subject: Re: [cp-patches] FYI: java-util adjustments for target/native
Date: Sun, 22 Jan 2006 20:35:35 +0100

Hi Roman,

On Thu, 2006-01-19 at 12:35 +0100, Roman Kennke wrote:
> Am Donnerstag, den 19.01.2006, 02:02 +0100 schrieb Mark Wielaard:
> > I don't really like this change. Why was this necessary?
> 
> As with the other target stuff, this was intended to improve
> portability.

The problem I have with the improve bit. Adding indirection without
actually providing real multiple implementations doesn't look like an
improvement, but does increase complexity and maintainability.

>  However, I understand your point. Feel free to revert this
> change and we (aicas) will implement our own thing based on the VM
> interface. (The same goes for the remaining native code, if you don't
> like the target native code at all, which is understandable since you
> mostly deal with posix-like systems, then feel free to get rid of it, we
> can still implement our own thing on the VM interface level. However,
> this would mean that we could not exchange bugfixes for native code
> anymore...)

I think that when you are done with this cleanup we should take a long
and hard look at what we have. The real problem seems to be that for
posix like systems (GNU/Linux, Darwin, *BSD, Solaris, cygwin, etc) the
target-layer makes things more brittle. Autoconfiscation is much more
robust and well understood for these kind of systems and currently our
users mostly rely on these kind of systems. There will not be much love
for the target-layer till we have a clear and healthy user community for
it. The most promising way to get that is probably to get the MinGW
target working well since that is where we can find most users imho.

In the long run I think it would be best to split the native part in
two. One for the major posix like systems that just uses a clean
autoconfiscated JNI implementation and one for all the other systems
that are hard/impossible to autoconfiscate using the target layer. This
is a bit like libgcj has done it.

Cheers,

Mark

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


reply via email to

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