Re: JNI vs. CNI (was Re: Announcement: libgcj and GNU Classpath merge
Aaron M. Renn wrote: > Jochen Hoenicke ([EMAIL PROTECTED]) wrote: > > I have invented an ad hoc abstract language and have transformed the > > natInflate.cc from libgcj (java.util.zip.Inflate). I have used the > > prefix JCL_ for the pseudo methods. I haven't implemented everything, > > yet, only what I needed for Inflater. See: > > Did anyone else take a look at this? Personally, I don't like this > approach. But the alternatives aren't great. Here's what we've got: > > 1. Metalanguage/macro approach. See Jochen's code at: > http://www.Informatik.Uni-Oldenburg.DE/~delwi/classpath/JCL/Inflater.jcl > > 2. #ifdef's > > 3. Separate implementations of JNI and CNI. > > 4. Write a JNI <-> CNI adapter layer > > 5. Make gjc support JNI and stick with that approach. Way I see it, the JNI v. CNI represents two different approaches to the same problem (allowing Java classes to interact with native code). The first approach (JNI) stresses cross-platform compatibility (here I am referring not only to different operating systems and architectures, but also different VM's on the same arch/OS) at the expense of performance. The second approach (CNI) stresses performance (as well as ease of maintenance) at the expense of cross-platform compatibility. How difficult would it be to implement both approaches (perhaps as #ifdef macros or pluggable header files), and then provide a build-time option to use one or the other? Perhaps something like: ./configure --with-cni Ian -- "And it ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things." -- Nicollo Machiavelli, 'The Prince'
Re: Announcement: libgcj and GNU Classpath merge
Bernd Kreimeier ([EMAIL PROTECTED]) wrote: > One of the implications of Java for free software is that it could > eventually make large inroads into Win32/other non-UNIX. Vice versa, > Java applications might minimize the migration pains for GUI intensive > apps, from non-UNIX to Linux. Is GNU/Linux the limit of what Classpath > is aiming at? Certainly not. GNU/Linux is simply the limit of what most of the developers have installed at home. I was to support at least all Unix flavors, plus Win, plus anything else anyone wants to help port it to. (Which since it is mostly Java shouldn't be too big a deal, except for perhaps some Win AWT peers). But of course you must run before you can walk, which is why we are first focusing on Japhar+GNU/Linux. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
Re: Announcement: libgcj and GNU Classpath merge
Tom Tromey ([EMAIL PROTECTED]) wrote: > libgcj is very portable (though perhaps not widely ported). It can > run on systems without a filesystem, for instance. I can't speak for > Classpath, but I can say that libgcj's goal is and will continue to be > portability to a wide variety of systems (including Windows, should > someone do the port). Portability is one of our goals, hence we write as much in Java as possible. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
Re: Announcement: libgcj and GNU Classpath merge
Brian Jones ([EMAIL PROTECTED]) wrote: > If the volume is more than a trickle of messages on compiling java > code with gcc then having a separate list is probably a good thing. > The classpath list is more of a developer list than a user list. > Traffic has not mandated we go to a classpath-devel or similar yet. I would like to see some improvements to our project infrastructure, particularly in the area of bug tracking. Right now bug reports and patches come to the list, and I'm sure many of them just get dropped. Maybe this is something Cygnus can help with. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
JNI vs. CNI (was Re: Announcement: libgcj and GNU Classpath merge
Jochen Hoenicke ([EMAIL PROTECTED]) wrote: > I have invented an ad hoc abstract language and have transformed the > natInflate.cc from libgcj (java.util.zip.Inflate). I have used the > prefix JCL_ for the pseudo methods. I haven't implemented everything, > yet, only what I needed for Inflater. See: Did anyone else take a look at this? Personally, I don't like this approach. But the alternatives aren't great. Here's what we've got: 1. Metalanguage/macro approach. See Jochen's code at: http://www.Informatik.Uni-Oldenburg.DE/~delwi/classpath/JCL/Inflater.jcl 2. #ifdef's 3. Separate implementations of JNI and CNI. 4. Write a JNI <-> CNI adapter layer 5. Make gjc support JNI and stick with that approach. Personally, I prefer option 5 for the core library stuff. If performance proved to be an issue for some reason, we could look at other options, such as #ifdef-ing down to CNI at isolated spots as needed. It looks like there are a few people out there who want to use Classpath, and porting to various JVM's is going to require some sort of massive #ifdef/alternate implementation approach for some parts of the library. It could get ugly. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
Re: Announcement: libgcj and GNU Classpath merge
On Dec 21, Stuart Ballard wrote: > Jochen Hoenicke wrote: > > > > I would volunteer to port that package. There are only two native > > files, so porting it to JNI should be simple. > > > > For CNI vs. JNI: One could invent an intermediate language, that could > > be translated to CNI code or JNI code via a perl script. Using the > > preprocessor alone (as Stuart suggested) seem impossible (CNI uses C++ > > namespaces and classes like java::util::zip::Deflater::deflate, while > > JNI uses plain C identifier Java_java_util_zip_Deflater_deflate). > > I like the perl approach. Although it might seem hacky, it means we can > design the meta-language as we want to, rather than using clunky > preprocessor directives. Even if it were possible to do it with the > preprocessor, but I know that I for one wouldn't enjoy programming in > the language that resulted! > > I say go for it, and keep us updated on your progress:) I have invented an ad hoc abstract language and have transformed the natInflate.cc from libgcj (java.util.zip.Inflate). I have used the prefix JCL_ for the pseudo methods. I haven't implemented everything, yet, only what I needed for Inflater. See: http://www.informatik.uni-oldenburg.de/~delwi/classpath/JCL convertJCL.pl is the perl script, that does the transformations to JNI and CNI Inflater.java the java code. Inflater.jcl the source code that gets transformed to: Inflater.c the JNI code. natInflater.cc the CNI code. There are some changes against the original natInflater.cc: The zstream is now stored in an array of bytes instead of using a special object as native pointer (which may disturb some garbage collectors). Arrays are accessed via JCL_GetArrayElements and must be released afterwards. And one has to be much more careful with exceptions and synchronized blocks, since there is no native exception handling nor automatic destructor (for calling monitorexit) in C or JNI. Jochen
Re: Announcement: libgcj and GNU Classpath merge
Tom Tromey <[EMAIL PROTECTED]> writes: > > "Bradley" == Bradley M Kuhn <[EMAIL PROTECTED]> writes: > > There are a few libgcj-related mailing lists. > See http://sourceware.cygnus.com/java for a full list. > > I'm ambivalent about merging the lists. There are two issues, as I > see it: > > 1. How will people here react to a lot of questions about gcj, > building libgcj, etc, etc. (See the java-discuss archives for an idea > of the volume). If the volume is more than a trickle of messages on compiling java code with gcc then having a separate list is probably a good thing. The classpath list is more of a developer list than a user list. Traffic has not mandated we go to a classpath-devel or similar yet. > 2. Do we lose any features, eg archiving (I've heard that the > classpath mailing list archiver is sometimes flaky? Is this true? Or > maybe I have my wires crossed). The classpath archive is hosted at http://www.mail-archive.com/classpath%40gnu.org/ which is hosted by VA Linux. There shouldn't be any flakiness in the future. > There are many other technical details to be worked out in terms of > merging the projects. I haven't really given it much thought, though > I could come up with a list if somebody wants one. Feel free, Paul and I as well as others want to work on this asap. This happened at a good time you see because I imagine most of us have some vacation coming up soon and I was already planning on spending a good deal of mine getting Classpath ready for a new release. The PTB demand it. Brian -- Brian Jones <[EMAIL PROTECTED]>
Re: Announcement: libgcj and GNU Classpath merge
>> This sounds like a good plan... I never heard of a GNU/Linux system >> that didn't include Perl, but certainly some other unixes don't. Bernd> One of the implications of Java for free software is that it Bernd> could eventually make large inroads into Win32/other Bernd> non-UNIX. Vice versa, Java applications might minimize the Bernd> migration pains for GUI intensive apps, from non-UNIX to Bernd> Linux. Is GNU/Linux the limit of what Classpath is aiming at? I'm not sure how I feel about JNI/CNI compatibility using a language we make up. It does seem attractive, but I wonder how many lurking pitfalls there are. Another approach would be to modify gcjh to generate stub classes that look like CNI on one side but make JNI calls on the other side. This also has pitfalls (as in, it might not even be possible to do, given direct field references in CNI code -- there's no good way to introduce accessors. I'm not entirely certain this is the case, since my knowledge of C++ hasn't kept up with the language). Either way we should definitely investigate these (and other) options instead of just writing all the code twice. That way lies agony. I'd like to point out that using Perl as part of the build process is not a portability killer. It all depends on how you do it. For instance, in libgcj we use Perl to generate tables in some situations (eg, the tables used by Character are generated by a Perl script). In this case we check in the generated tables since they change infrequently; most developers never run the scripts. libgcj is very portable (though perhaps not widely ported). It can run on systems without a filesystem, for instance. I can't speak for Classpath, but I can say that libgcj's goal is and will continue to be portability to a wide variety of systems (including Windows, should someone do the port). Tom
Re: Announcement: libgcj and GNU Classpath merge
Stuart Ballard wrote: > This sounds like a good plan... I never heard of a GNU/Linux system that > didn't include Perl, but certainly some other unixes don't. One of the implications of Java for free software is that it could eventually make large inroads into Win32/other non-UNIX. Vice versa, Java applications might minimize the migration pains for GUI intensive apps, from non-UNIX to Linux. Is GNU/Linux the limit of what Classpath is aiming at? b. -- "Problem solving is hunting. It is savage pleasure, and we are born to it." Thomas Harris, Silence of the Lambs
Re: Announcement: libgcj and GNU Classpath merge
> "Bradley" == Bradley M Kuhn <[EMAIL PROTECTED]> writes: Bradley> (BTW, is there a mailing lists for libgcj, and will it be Bradley> merged with the Classpath mailing list now?) There are a few libgcj-related mailing lists. See http://sourceware.cygnus.com/java for a full list. I'm ambivalent about merging the lists. There are two issues, as I see it: 1. How will people here react to a lot of questions about gcj, building libgcj, etc, etc. (See the java-discuss archives for an idea of the volume). 2. Do we lose any features, eg archiving (I've heard that the classpath mailing list archiver is sometimes flaky? Is this true? Or maybe I have my wires crossed). There are many other technical details to be worked out in terms of merging the projects. I haven't really given it much thought, though I could come up with a list if somebody wants one. T
Re: Announcement: libgcj and GNU Classpath merge
> "Artur" == Artur Biesiadowski <[EMAIL PROTECTED]> writes: Artur> A number of libgcj classes are heavily instrumented with CNI Artur> native methods (for sake of speed/space etc - most notably Artur> String and Character classes). Will gcj switch to classpath Artur> ones, or there would be differences in implementations for some Artur> classes ? (not talking about obvious ones required by porting, Artur> like Class or WeakReference) I'm unwilling to give up the speed advantages offered by our use of CNI (which is nowhere near as prevalent as people here seem to think). However, I think these decisions must really be made on a class-by-class basis, and we don't have enough information yet to make them. So the answer is, "it depends". Tom
Re: Announcement: libgcj and GNU Classpath merge
Paul Fisher wrote: > As an initial integration solution, we'd like for Classpath to act as > an upstream source provider for libgcj. We'd add a make target to > Classpath which would build a tar-ball of source suitable for > importing into libgcj. All source changes would go into the Classpath > CVS tree, and the libgcj tree would be periodically updated. A number of libgcj classes are heavily instrumented with CNI native methods (for sake of speed/space etc - most notably String and Character classes). Will gcj switch to classpath ones, or there would be differences in implementations for some classes ? (not talking about obvious ones required by porting, like Class or WeakReference) Artur
Re: Announcement: libgcj and GNU Classpath merge
Jochen Hoenicke wrote: > > > libgcj has java.util.zip [...] > > I would volunteer to port that package. There are only two native > files, so porting it to JNI should be simple. > > For CNI vs. JNI: One could invent an intermediate language, that could > be translated to CNI code or JNI code via a perl script. Using the > preprocessor alone (as Stuart suggested) seem impossible (CNI uses C++ > namespaces and classes like java::util::zip::Deflater::deflate, while > JNI uses plain C identifier Java_java_util_zip_Deflater_deflate). I like the perl approach. Although it might seem hacky, it means we can design the meta-language as we want to, rather than using clunky preprocessor directives. Even if it were possible to do it with the preprocessor, but I know that I for one wouldn't enjoy programming in the language that resulted! I say go for it, and keep us updated on your progress:) > Porting this package is probably a nice test for this technique. What > do you think about it? If you don't want to rely on perl for > compiling it would be simple to include the transformed classes in the > distribution. This sounds like a good plan... I never heard of a GNU/Linux system that didn't include Perl, but certainly some other unixes don't. Stuart.
Re: Announcement: libgcj and GNU Classpath merge
Paul Fisher wrote: > > The FSF and Cygnus have agreed, in principle, to merge the libgcj and > Classpath projects together. This is great news! This should really speed up development of both projects :) > 1. libgcj and Classpath will both change licensing terms to the GPL >with the following exception: > > /* As a special exception, if you link this library with other files > to produce an executable, this library does not by itself cause > the resulting executable to be covered by the GNU General Public > License. This exception does not however invalidate any other > reasons why the executable file might be covered by the GNU > General Public License. */ A couple of points I made before but I didn't see a definite answer to - I just want to make sure that they are dealt with: Mozilla - according to Chris, Japhar runs *in-process* in mozilla, so it's important that this new license isn't incompatible with the NPL. I don't see why it would be, but I'm just checking... Japhar - the use of the term "executable" in the above license seems to exclude linking Classpath with Japhar to produce a *library* for adding java support to a program. Since this is what Japhar does and it is licensed under the LGPL for that reason (all Japhar *executables* are licensed under the GPL already), I'd be interested to know how this would work. (one solution that occurs to me is dual-licensing like Perl, under the modified-GPL and the LGPL... both licenses seem to exclude some uses, but between the two of them all cases are probably covered) Stuart.
Re: Announcement: libgcj and GNU Classpath merge
On Dec 21, Mark Benvenuto wrote: > Paul Fisher wrote: > > Help merging our projects together will be greatly appreciated. We > > need to address overlapping classes and make sure that only the best > > portions of our class libraries exist in the merged distribution. > > > > We will need to go through the differences. Probably, go package by > package and hand off the tasks to maintainers and volunteers. The classes > will have to be evaluated on many levels such as cleaness, effciency, and > speed. Also, the differences in native implementation language and CNI vs > JNI may make a difference. They generally have a lot less in terms of > clases then we do but can fill in some holes for us. > > libgcj has java.util.zip [...] I would volunteer to port that package. There are only two native files, so porting it to JNI should be simple. For CNI vs. JNI: One could invent an intermediate language, that could be translated to CNI code or JNI code via a perl script. Using the preprocessor alone (as Stuart suggested) seem impossible (CNI uses C++ namespaces and classes like java::util::zip::Deflater::deflate, while JNI uses plain C identifier Java_java_util_zip_Deflater_deflate). Porting this package is probably a nice test for this technique. What do you think about it? If you don't want to rely on perl for compiling it would be simple to include the transformed classes in the distribution. Jochen
Re: Announcement: libgcj and GNU Classpath merge
Paul Fisher wrote: > /* As a special exception, if you link this library with other files > to produce an executable, this library does not by itself cause > the resulting executable to be covered by the GNU General Public > License. This exception does not however invalidate any other > reasons why the executable file might be covered by the GNU > General Public License. */ Just to satisfy my curiosity: how does this differ from the LGPL, and why was this solution preferred to using LGPL? b. -- "Problem solving is hunting. It is savage pleasure, and we are born to it." Thomas Harris, Silence of the Lambs
Re: Announcement: libgcj and GNU Classpath merge
Paul Fisher wrote: > The FSF and Cygnus have agreed, in principle, to merge the libgcj and > Classpath projects together. > > The general framework: > > 1. libgcj and Classpath will both change licensing terms to the GPL >with the following exception: > > /* As a special exception, if you link this library with other files > to produce an executable, this library does not by itself cause > the resulting executable to be covered by the GNU General Public > License. This exception does not however invalidate any other > reasons why the executable file might be covered by the GNU > General Public License. */ > Fine. > > 2. Cygnus will assign all of the libgcj code it owns to the Free >Software Foundation. All future contributions will be assigned to >the Free Software Foundation. > Great. > > 3. libgcj, which includes an execution environment for programs >written in the Java programming language, will likely be merged >into GCC proper. > I am getting goosebumps. I am look forward to getting really great java performance. > > > Help merging our projects together will be greatly appreciated. We > need to address overlapping classes and make sure that only the best > portions of our class libraries exist in the merged distribution. > We will need to go through the differences. Probably, go package by package and hand off the tasks to maintainers and volunteers. The classes will have to be evaluated on many levels such as cleaness, effciency, and speed. Also, the differences in native implementation language and CNI vs JNI may make a difference. They generally have a lot less in terms of clases then we do but can fill in some holes for us. libgcj has java.util.zip and java.util.zip along with DecimalFormat, and Event that we need at the momemt. java.io, java.lang , and java.net is there for the most part as far as I can tell. Some java.text and java.util is there also. java.security is almost non existent along with java.sql, java.rmi, java.applet, and java.beans. libgcj's java.awt is in a partially implemented state. Finally, a lot of their native code is written in C++ and I think CNI ( I do not care but others may). Also, if to get started on merging the projects some guidelines should be setup. Where to get libgcj, what compiler to get if you want to test integration of things, etc. I am also curious can their compiler compile Classpath? BTW: libgcj http://sourceware.cygnus.com/java/ CVS: for libgcj cvs -d:pserver:[EMAIL PROTECTED]:/cvs/java login (password is ``anoncvs'') cvs -z9 -d:pserver:[EMAIL PROTECTED]:/cvs/java co libgcj (Note: their CVS server is a lot faster then ours ) Mark Benvenuto
