> I want to port GNU Classpath to Neko to make the > porting of Java applications to the Neko platform > easier. I suppose that this will be done as an 80% > automated source code conversion from Java to haXe.
Hello, Yes, this is possible to do with a good code generator, since in terms of programming language, most of Java is included in haXe already. However, GNU ClassPath is not only composed of pure Java sources. It also requires some C code using JNI to access the operating system. Replacing that by accessing to the Neko libraries might be a big work already, and is not automatizable. > Getters and Setters, etc will be done the haXe way as > much as possible. This will require modification of > Java ports that use Neko GNU Classpath, but the same > source code conversion tool that I develop should take > car of getters, setters, iteration, etc. > automatically. Yes, it's easy to detect some get/set patterns in the Java classes and turn them into full-fledged properties. > However, is there any reason to not use GNU Classpath > and use Apache Harmony instead? I haven't followed Harmony recently. But what would be the difference with haXe ? > Comments, objections, advice? A project page will be > created after a little discussion. This looks like a huge project. GNU Classpath is pretty big since it includes AWT/SWING. I'm not sure what are your goals. If you want to use haXe, maybe adding a haXe-2-Java generator and running haXe on the JVM might be a simpler approach. If you want to help people and yourself porting Java apps to haXe/Neko, then maybe you should focus on only a small subparts of GNU Classpath that don't require "native" code, and add some "native" classes (FileSystem, Network, ...) by rewrapping by-hand the neko libraries. Best, Nicolas -- Neko : One VM to run them all (http://nekovm.org)
