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'
unubscribe
Re: KJC and GNU Classpath
Brian Jones wrote: we tried by hand but we encoutered the following problems: command: cd classpath/lib; java -mx12800 at.dms.kjc.Main --verbose --nowrite @classes According to the documentation I think you'd want to do something like the above but changed to cd classpath/lib; java -mx12800 at.dms.kjc.Main --verbose --nowrite `cat classes`, since I did not see the "@classes" syntax documented on your web page, but if it works that's great. It works. Introspector: = ../java/beans/Introspector.java:23: Package gnu.java.beans not found in import. import gnu.java.beans.*; ComponentBeanInfo: == ../gnu/java/beans/info/ComponentBeanInfo.java:23: Package gnu.java.beans not found in import. import gnu.java.beans.*; This package exists in classpath/gnu/java/beans/ so something is probably wrong with how you're trying to compile. It was our fault. AWTEvent: = ../java/awt/AWTEvent.java is missing from lib/classes It appears that AWTEvent is not part of the compile, see classpath/lib/standard.omit. It has been added in lib/classes in the last CVS of CLASSPATH. ObjectInputStream: == problem with an expression (java/io/ObjectInputStream.java:1188: Variable "value" cannot be initialized by a value of type "int" [JLS 4.5.4]) Which compiler do you use ??? please rewrite: char value = default_initialize ? 0 : this.realInputStream.readChar (); as: char value = default_initialize ? (char)0 : this.realInputStream.readChar (); see also: java/io/ObjectInputStream.java:1223: Variable "value" cannot be initialized by a value of type "int" [JLS 4.5.4] Okay, I made these changes in CVS. It works fine. WeakHashMap: java/util/WeakHashMap.java:336: Cannot access field "queue" it is in an other package and not a class member [JLS 15.10] This is a problem with how WeakBucket is setup I believe. It doesn't make much sense to me why we would call the super constructor with a package private data member that isn't even initialized in java/lang/ref/Reference.java except in this same constructor. There is also the problem mentioned above of queue being in another package. I think Jochen Hoenicke should look at this. And we also have the following problem that is a bug in KJC: java/util/AbstractList.java:410: Invalid outer class for this operation [JLS 15.7.2] we will try to fix it today. Could you fix these problems and send us an email ([EMAIL PROTECTED]) when it's available on your CVS ? lyta:~$ cvs -d :pserver:[EMAIL PROTECTED]:/cvs/public co kjc-suite cvs server: cannot find module `kjc-suite' - ignored This bug is already fixed. We'll try to make a new release available on our CVS tomorrow. The line above should now work. Could you fix this problem and let the classpath list know when you have ([EMAIL PROTECTED])? I'd also like to know when you fix the AbstractList problem above. Thanks you for your prompt answer. I got GNU CLASSPATH to compile on my computer using SUN's JDK with: vgp% cd classpath/lib vgp% CLASSPATH=$CLASSPATH:/extra/kaffe/libraries/javalib/Klasses.jar java -mx128m at.dms.kjc.Main @classes Vincent for DMS. Brian -- Brian Jones [EMAIL PROTECTED]
Re: KJC and GNU Classpath
Vincent GAY-PARA [EMAIL PROTECTED] writes: Hi, At DMS we tried to compile GNU Classpath with KJC (http://www.dms.at/kjc) and we encoutered some problems. ObjectInputStream: == problem with an expression (java/io/ObjectInputStream.java:1188: Variable "value" cannot be initialized by a value of type "int" [JLS 4.5.4]) Which compiler do you use ??? please rewrite: char value = default_initialize ? 0 : this.realInputStream.readChar (); as: char value = default_initialize ? (char)0 : this.realInputStream.readChar (); see also: java/io/ObjectInputStream.java:1223: Variable "value" cannot be initialized by a value of type "int" [JLS 4.5.4] I believe this is a compiler error, not an error in the code. `value' is not being initialized with a value of type int, but with a value of type char. JLS 15.24: The type of a conditional expression is determined as follows: ... Otherwise, if the second and third operands have numeric type, then there are several cases: ... If one of the operands is of type T where T is byte, short, or char, and the other operand is a constant expression of type int whose value is representable in type T, then the type of the conditional expression is T. ... -- Geoff Berry
Re: Success Compiling Latest Classpath!
"Aaron M. Renn" [EMAIL PROTECTED] writes: Ok, I tried building the latest Classpath from scratch myself using the latest build system. It's amazingly easy and worked very well with only a couple hiccups along the way. Kudos to Brian Jones for his work recently to make all this happen. Here's a list of the things I had to do beyond syncing up with CVS to compile: -- Grabbed Jikes 1.10. My last version was at 0.43 so I doubt it would work. No, it would not work. And apologies in advance for the .u files. :) See the HACKING file on jikes 1.11 (which is not out). -- Had to get libart. Yes, finding the libart cvs stuff is a pain. -- Needed to mkdir vm/current and include, run autoheader without errors. -- Oops, as it turns out, we are supposed to symlink to vm/current during the build process. I deleted the dir and hand crancked the link. Okay, configure should have done the symlink for you, some sort of problem? -- I got messages about missing java.dep and headers.dep when I first ran make, but this didn't appear to cause any problems. Known about it, but haven't looked into this yet. It isn't a problem when using jikes of course. I'll probably add support for kjc next. -- Problems compiling. It turned out I had a couple unchecked in AWT files that need to be added to standard.omit. I did so. It happens. Just wanted to insert a comment that Jikes is unbelievably fast. -- The native stuff bombed on missing dependencies. I've seen this one enough. Hmm... let's add a rm -rf .deps to clean. -- Two compile errors in the GTK peers. These are bugs that need to be fixed. The error text is below: I compiled earlier today without the problems you mention. Could it be javah in 1.1.5 is messed up? I'm using 1.1.7B. I hacked around this by editing the generated header files to match the .c file method signatures. For the record, my configure command was: ./configure --with-japhar --with-java=/usr/local/jdk1.1.5/bin/java \ --with-javah=/usr/local/jdk1.1.5/bin/javah --with-jikes \ --enable-maintainer-mode --with-classlib=/usr/local/jdk1.1.5/lib/classes.zip Now I'm off to see what happens when I type "make install" :-) Been playing with that today. I don't know if you did your get after my last commit or not but you might want to try again just to see those changes to where we install which in your case might be something like /usr/local/japhar/lib/classpath, /usr/local/japhar/share/classpath/glibj.zip. I haven't tried yet so I may have made a mistake. Brian -- Brian Jones [EMAIL PROTECTED]
Ahhh....Success!
I synced up with CVS and now have Japhar working with the old Classpath 0.00 release. Looks like John's patch did the job. I did have a problem with core dumps that required me to add /usr/local/japhar/lib to LD_LIBRARY_PATH manually. Also, I still don't seem to have all of my libraries loaded correctly because I'm getting some runtime link errors. Are the library files still supposed to be called libjaphar_whatever.so? -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
Re: Ahhh....Success!
"Aaron M. Renn" wrote: I synced up with CVS and now have Japhar working with the old Classpath 0.00 release. Looks like John's patch did the job. I did have a problem with core dumps that required me to add /usr/local/japhar/lib to LD_LIBRARY_PATH manually. strange... what were the core dumps? /usr/local/japhar/lib is only checked after the directories in LD_LIBRARY_PATH are checked, so if you have older native libs your path that could be the problem. Also, I still don't seem to have all of my libraries loaded correctly because I'm getting some runtime link errors. Are the library files still supposed to be called libjaphar_whatever.so? they can be either libjaphar_%s.so or lib%s.so. japhar tries to load the libjaphar_%s.so library first, and if it can't find it it tries lib%s.so. Chris
Re: Ahhh....Success!
Chris Toshok [EMAIL PROTECTED] writes: "Aaron M. Renn" wrote: I synced up with CVS and now have Japhar working with the old Classpath 0.00 release. Looks like John's patch did the job. I did have a problem with core dumps that required me to add /usr/local/japhar/lib to LD_LIBRARY_PATH manually. strange... what were the core dumps? /usr/local/japhar/lib is only checked after the directories in LD_LIBRARY_PATH are checked, so if you have older native libs your path that could be the problem. Also, I still don't seem to have all of my libraries loaded correctly because I'm getting some runtime link errors. Are the library files still supposed to be called libjaphar_whatever.so? they can be either libjaphar_%s.so or lib%s.so. japhar tries to load the libjaphar_%s.so library first, and if it can't find it it tries lib%s.so. I may have changed a couple of lib names today without changing the load in the .java file to match. My mistake. I'll fix it tomorrow. Brian -- Brian Jones [EMAIL PROTECTED]
Re: Ahhh....Success!
"Aaron M. Renn" wrote:
Brian Jones ([EMAIL PROTECTED]) wrote:
I may have changed a couple of lib names today without changing the
load in the .java file to match. My mistake. I'll fix it tomorrow.
Our Java files should be loading names like "javanet". Now this maps
to a native library name. In Japhar, supposedly either libjavanet.so
or libjaphar_javanet.so work, but I've only ever gotten the latter to
do so. I wonder if we are hardcoding a library name someplace in our
native code.
oh, you know what this might be? Joechen fixed a bug in MapDLLName (or
whatever that method is) that gives you the name of the .so to load. that
can only return one name, and it returns libjaphar_%s.so. hmm.. i'll take
a look at this tomorrow.
Chris
--
saturn5 do { addMoreFeatures(); } until (engineers = 0);
