In our previous episode, Felipe Monteiro de Carvalho said: > My initial experience was that this is no problem. The Java libraries > are just an API just like any other. Just call the appropriate > routines and you can build your implementation for anything in the FPC > library. > > I managed to write a simple ReadLn using base Java routines. It turns > out they don't have one ready (horrible!), so I just got a routine > that reads byte per byte and read until a new line comes. Parsed the > ASCII into a number, processed the signal, etc.
It's like with the bytecode. If you start cutting pieces off, a workaround here. (insert "hammer" analogy here) The point is if people will accept it, and if the synergy is enough for both sides of the projects (native and bytecode). And if code practically can't be shared, you don't even get to first base. IMHO if it can't compile something like fpdoc (when cleaned a bit for pointer use), there is no point.... And then there is second base, keeping the interests of both platforms aligned long term and resist bringing heaps of .NETisms/Javaisms into the melt. Multiple versions of the framework (ME/SE/EE, compact framework etc), and the other way around, implementing new native features that are hard to add to the bytecode targets. That's the lesson of Delphi.NET. _Sure_ it can be done. But only halfway practical (all existing code must be at least partially reengineered), and after an initial migration period hardly anybody is interested anymore in sharing the source, since it is simply not easy for large, non trivial codebases, and limiting to both sides. In summary, it is about making the cooperation worthwhile in practice, and keep it that way beyond the catchy phrase "but you can target all these platforms ...", and avoid the situation most progress are compromises neither side are happy about long term (like VCL.NET when the honeymoon was over). So, I would narrow the project really down, like limiting yourself to (a subset of) J2ME, and really keep the focus on mobile devices, and avoid the generalization of "all of Java". Maybe that the fork can also be partially (e.g. only a native compiler generating bytecode to not complicate the compiler, and a totally separate RTL tree ) _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
