Hi, On Sat, 2006-01-28 at 17:02 -0800, Casey Marshall wrote: > On Jan 28, 2006, at 7:21 AM, Guilhem Lavaux wrote: > > I thought to have been already clear about that in the past (and > > with no answers !). > > Sorry, I meant to reply about what you were proposing, but forgot :-)
Yeah, sorry. We all need little reminders from time to time. But showing up with real code does help getting replies :) > What you're working on seems a bit better than the target layer > stuff, in that you have real functions that the compiler/debugger can > tell you about, if there's an error. Agreed, it is definitely better then what we have now with the macros. > I don't, however, entirely see > the point of another funcall to wrap the syscalls in. It seems to me > as though efforts like this are trying to re-use the bits of JNI code > that wrap syscalls in the native parts of VM* classes, and not much > else. I do see some value because it makes it clear where the JNI part ends and where the platform specific part starts. But I am not sure putting all platform specific parts in separate files is always an improvement since most of it is actually pretty small and most of it seems not to be that different between platforms. Adding separate functions for things that might be different or that need VM specific hooks/callbacks is good though. I would just hate to see it overdone for small things that could just as well be in the same file or even function. > In my opinion, time would be better spent: > > - Writing utility functions that make JNI easier to deal with. That is what JCL and NSA were for (native/jni/classpath). They were supposed to be "safe wrappers" for some common things like throwing exceptions, conversion of jstrings and cstrings and generic RawData support that hides whether the platform is 32 or 64 bits. But those functions were never really worked out much, nor are they used very consistently in all our JNI code at the moment. > - Writing concise, portable (in the realm of POSIXy systems, at > least) native implementations of VM* classes that require native > support. Through autoconf and replacement functions where needed. That is how libgcj (and kaffe) do it. > > * if we want something which is quite portable (but maybe not as > > portable as aicas portability layer) we must ensure some level of > > abstraction to hide how syscalls are really used. That way if we > > have to call different things in the OS (e.g. for more exotic > > platforms like windows) or to use the syscalls differently we will > > not be completely stuck by tons of autoconf code in the common VM > > layer. > > It seems like a lot of the argument for this kind of native layer is > "we can port to Windows/some exotic platform," but frankly, I don't > see it. Windows (in my uninformed opinion ;-) is probably wildly > different enough such that writing a win32 `cpio_read' isn't much > less work than writing a win32 > `Java_gnu_java_nio_channels_FileChannelImpl_read__.' And since any > port like this is (AFAIK) merely hypothetical, I don't see the value. libgcj has a somewhat separate Windows implementation of some platform native code (see the nat*Win32.cc files in gnu/java/nio, gnu/java/net, java/lang and java/net in gcc/libjava). And they also support cygwin and mingw to a point (although I don't know whether the Posix or Win32 native implementation is used by either the cygwin or mingw target). All this can/should of course be wrapped behind our VMClass interface layer since that also helps making our library JNI/CNI/.NET/Oberon/etc agnostic. > I don't mind this proposal, and I think you should go ahead with it. > I still have my own opinions about how to write Classpath's native > library, so I may try my own experiment in another branch (unless, of > course, no-one really agrees with me, in which case I will just stop > critiquing other people's code). I think I agree with Casey. Please go ahead with your work Guilhem. We will try to be constructive in our criticism. Actually doing the work and providing patches is a very good way to proof your point that this is needed and makes things cleaner. Thanks for working on this. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
