[RFC] Fix PosixProcess by porting VMProcess from Classpath...

Wed Jul 14 02:08:00 GMT 2004

David Daney wrote:
>>Yes. If the general opinion is that Classpath's VMProcess is better than 
>>ours, then I am in favour of switching to/merging with the classpath 
>>version. However, the native part will need to be converted from JNI to 
>>CNI, because to use JNI we'd have to have a separate shared libary for 
>>it. Translating the native code should be relatively straight forward 
>>(CNI is easy) and I'm happy to help out here if needed.
>>>>>>>>My general idea would be to:
>>a) Replace PosixProcess.java with the contents of VMProcess.java, but
>keep the PosixProcess.java filename and ConcreteProcess class name.
>>b) Port the native code to CNI and put it in natPosixProcess.cc
>>>Q: Would it be better to keep VMProcess.java as is (as much as possible)
>and change natRuntime.cc to use VMProcess instead of ConcreteProcess?
>>I think either way is ok. It would be nice to have the .java part truely 
merged, with no diffs between the claspath & libgcj version. If that is 
going to be possible to do in a clean way (given the JNI->CNI 
conversion) then its probably best. The ConcreteProcess thing is 
slightly awkward so it would be nice to get rid of it too.
I wonder if it would be possible to share VMProcess.java between the 
Posix and Win32 ports, and just have different native code? That way 
it'd certainly make sense to just have VMProcess.
>Q: Can we just take Classpath code and change the license to
>LIBGCJ_LICENSE license (i.e. GPL + exception)
>>Yes. Classpath & libgcj share the same license, and anything from either 
project can be freely shared between them without additional paperwork, etc.
Regards
Bryce