Re: Proposal for CNI/JNI problems
Per Bothner writes: > You need to analyze CNI (i.e. C++) source code. You need to recognize > CNI field and method references, which are just C++ field/method > references. That implies a semantic analysis of the C++ code. Yep. > The logical tool is a compiler. The only C++ compiler we have > available is G++. ANTLR? Bootstrapping issues aside. > It does not emit C source. Adding an option to emit C is a major > project. It is even worse if you want human-readable C. Granted. I wasn't focused on G++. > What you can do is convert annotated-CNI to JNI C. What do you mean by annotated-CNI? > That loses some of the simplicity of CNI 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.? > However, that is a quite different idea. 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. I'd prefer e.g. an ANTLR solution for that reason alone, given that the feasibility of either approach still seems equally dubious to me :-\. b.
Re: Proposal for CNI/JNI problems
Bernd Kreimeier <[EMAIL PROTECTED]> writes: > ANTLR? ANRLR is not a compiler; it is parser-generator. It does not handle C++ name resolution, for example, as far as I know. > What do you mean by annotated-CNI? CNI with macros that are no-ops when using CNI, but that help whatever tools is used to convert to JNI. > 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. > 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? -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/~per/
Re: Proposal for CNI/JNI problems
On Jan 16, 2000, Per Bothner <[EMAIL PROTECTED]> wrote:
> Bernd Kreimeier <[EMAIL PROTECTED]> writes:
>> What do you mean by annotated-CNI?
> CNI with macros that are no-ops when using CNI, but that help whatever
> tools is used to convert to JNI.
And, preferrably, no-ops that would be warned about when missing, so
as to arrange that ``porting'' to JNI isn't a pain just because CNI
doesn't require certain stuff.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them
Re: Proposal for CNI/JNI problems
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.
