[fpc-devel] Pascal to Java compiler

[Marco van de Voort]

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 )