Per Bothner writes:
> > Is a modification of gcjh a good way to simplify the task for
> > the parser/converter? I.e. marking Java-turned-C++ classes,
> > enforcing naming schemes/prefixes etc.?
>
> I don't see how it helps. The problem is analyzing the user's C++
> native code.
If you can safely separate the user written C++ (e.g. classes
which are not the native equivalent of Java classes) from the
C++ statements that are actual Java access by CNI, maybe the
problem gets closer to textual replacement then. So, if
gcjh enforces a certain mind of annotation, namespace, the
analysis of the user's code might be simnplified? Especially
if done before CPP expands CNI statements for gcj's G++?
b.
p.s.:
> > Having parts of the toolchain being pure Java (along with the
> > ability to compile them to native code for bootstrap) is the
> > foundation for much more portability.
>
> But why is this an inportant goal for GNU Classpath?
I do not know whether portability is a goal for GNU Classpath.
I personally consider it important. Free Software written in Java,
with minimal native dependencies both at built time and runtime,
that can be compiled to native code or bytecode, could IMO
make large inroads into new user groups - Joe Windows will
always shy away from libtool/Perl/G++/Cygwin.
