port or develop?

Submitted by Trickkiste on Mon, 04/05/2004 - 05:43.

hi,
every now and then anybody asks to implement a certain feature or program and many times another one claims that there is a Java version of this or that already available.
At that point the term "port" or "porting" is used often.

I see the long term goal of JNode (Any java application should run on it, fast & secure!) and the need of porting at a lower level, but i think its better to develop the JNode system to the ability of running nearly any Java application than porting the application to the need of JNode.

Maybe JNode is not that far, but if a certain application does not run, we will need to search the responsibility and or fault inside JNode and not inside the application...

Andreas

‹ log4j config under eclipse 3 problems with boot process ›

develop where possible

Submitted by admin on Mon, 04/05/2004 - 16:52.

I prefer to fix jnode is an app does not work on it.

However some parting may be needed on low level stuff. This is the area which implements the java api's.
Ewout

Separation

Submitted by mattzerah on Tue, 04/06/2004 - 06:18.

Is there any way to separate the low level modifications, especially in the classpath distribution?

Perhaps by subclassing, or intercepting calls, or anything. This way we can simply keep the current CVS of classpath in JNode, and hopefully keep any JNode specific modifications outside of classpath. I haven't looked into the JNode mod's within classpath so I dont know how easy/hard/possible it is to do this, but I think it would be nice to simply take out classpath and drop in the sun's api, or 's api, instead of relying on classpath.

Just a thought.

Matt.

Java API layers native API

Submitted by markhale on Tue, 04/06/2004 - 16:10.

It is not possible to isolate classpath completely from jnode. The Java API has to hook into the underlying native/jnode API if it is to provide non-trivial services. Consider the obvious case of the AWT. This has to be completely dependent on jnode's graphic subsystem. There is no way round this. Ofcourse, one can try to minimize the number of system hooks, but you cant eliminate them. And there is definitely no way you can swap in/out Classpath for Sun's API. You can't even swap Windows Sun Java API with Solaris Sun Java API, precisely because Windows system hooks are different from Solaris system hooks are different from jnode system hooks. I think the best one can do is to document the hooks well, and try to keep them all in one place.

I prefer develop (less maintenance)

Submitted by Fabien D on Mon, 04/05/2004 - 07:03.

I agree with you.
As far as I know, charva and classpath are the only things that have been ported to JNode.

For classpath, I was surprised that it has been ported to JNode. But, after some reflections, I realized that at the lower level it can (must?) become too specific to avoid porting. I prefer avoid this because it involves more job (someone is dedicated to this task).

I think it's better that someone from classpath or JNode design/develop some generic interfaces that can be implemented for specific VM (the JNode VM in our case) ... this allow other VM to use classpath more easily.

For charva, it's a different situation because I have searched on the web and haven't found applications for it. But is there anybody motivated by developping a new application (that may already exist with swing) for charva.
Maybe, it will be specific to JNode. But, later, what about a swing version of this application ? and a version for JNode GUI components ? This involve more job.