Re: VMInterface addition: Make native library names part ofVMInterface
Jeroen wrote: > Bryce McKinlay wrote: > > Sorry, I think I misunderstood your message. I thought you were > > suggesting moving all the native methods (eg for IO classes) to > > separate VM* classes. > > I think that is in fact what Mark was suggesting and I think this is > definitely a good idea. There are a lot of VMs that don't (want to) use > JNI for their "native" methods. Having all native methods in the VM* > classes makes this much easier. > I agree with this. Moving all the native methods in the VM* classes would be easier for the VM implementors, because it is easier to document or find out which methods must be provided (a grep native *.java doesn't help much!). > > Right. I think there is a distinction, however, between what the VM > > must implement to operate with classpath - ie core VM classes like > > Class, Object, Throwable, Thread; and portable classes which > > happen to have native methods, such as java.io.File and > > java.net.PlainSocketImpl. > > The later are just normal classes with native methods, the > > implementations of which are typically be portable across different > > VMs. > > This assumption is not true for some VMs. My VM (IKVM) has no native > methods and I'm pretty sure this is also true for JAOS and maybe others. > How I'm going to explain this...? Well Jaos uses the Oberon language to provide the native methods (native == written in a language other than java), but doesn't go through JNI: both languages have the same object model with garbage collection, so no object pinning and similar stuff is needed, and the jitter compiles the byte-code using the same data layout and calling convention, such that the generated code is identical for both languages. It is the task of the linker to patch the native implementation entry points into the method tables, and from that point java can call oberon and oberon can call java. Moving all the native methods to a separate class would make my job simpler: I would replace the complete class with an oberon class instead of having to merge them. And because the interface is stable, I would be able to get rid of a lot of bootstrap code, which checks every time whether the methods and fields have changed. > > So, they a system/platform interface rather than the VM > > interface. > > To put it another way, just because a method is native > > doesn't mean it interfaces with the VM. > > The VM* classes don't mean "interfaces with the VM", but are a way for > VM implementers to easily replace their implementation. (The idea being > that the interface between the non-VM and VM classes is fairly stable). > Well, the VM classes are part of the VM interface, which is much broader. I agree that they will be fairly stable, thus making the port simpler to maintain. -Patrik Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: VMInterface addition: Make native library names part ofVMInterface
Bryce McKinlay wrote: > Sorry, I think I misunderstood your message. I thought you were > suggesting moving all the native methods (eg for IO classes) to > separate VM* classes. I think that is in fact what Mark was suggesting and I think this is definitely a good idea. There are a lot of VMs that don't (want to) use JNI for their "native" methods. Having all native methods in the VM* classes makes this much easier. > Right. I think there is a distinction, however, between what the VM > must implement to operate with classpath - ie core VM classes like > Class, Object, Throwable, Thread; and portable classes which > happen to have native methods, such as java.io.File and > java.net.PlainSocketImpl. > The later are just normal classes with native methods, the > implementations of which are typically be portable across different > VMs. This assumption is not true for some VMs. My VM (IKVM) has no native methods and I'm pretty sure this is also true for JAOS and maybe others. > So, they a system/platform interface rather than the VM > interface. > To put it another way, just because a method is native > doesn't mean it interfaces with the VM. The VM* classes don't mean "interfaces with the VM", but are a way for VM implementers to easily replace their implementation. (The idea being that the interface between the non-VM and VM classes is fairly stable). Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: characters set's problem
Sascha Brawer wrote: What exactly do you mean when you say "Unicode"? It seems that you think that Java uses only U+ .. U+ (the "basic multilingual plane", also known as UCS-2). As far as I know, this was true in the past, but this restriction has changed in the meantime. Nowadays, Java uses the full Unicode character set. But rather awkwardly and incompletely. Is there a replacement for java.lang.Character, which only handles 16-bit 'char' values? -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: characters set's problem
jsona laio <[EMAIL PROTECTED]> wrote on Thu, 30 Oct 2003 07:55:17 +: >however, lately i want to participate a porject, in >which involves developing encoding like CCCII (CJK >based characters set for asian characters, which >defines more characters than unicode supports in the >parts of CJK). however, as i know, java vm is based >upon unicode. What exactly do you mean when you say "Unicode"? It seems that you think that Java uses only U+ .. U+ (the "basic multilingual plane", also known as UCS-2). As far as I know, this was true in the past, but this restriction has changed in the meantime. Nowadays, Java uses the full Unicode character set. The following is quoted from [1]: >The native coded character set of the Java programming language is that >of the first seventeen planes of the Unicode version 3.0 character set; >that is, it consists in the basic multilingual plane (BMP) of Unicode >version 1 plus the next sixteen planes of Unicode version 3. This is >because the language's internal representation of characters uses the >UTF-16 encoding, which encodes the BMP directly and uses surrogate pairs, >a simple escape mechanism, to encode the other planes. Hence a charset in >the Java platform defines a mapping between sequences of sixteen-bit >values in UTF-16 and sequences of bytes. Basically, you are free to use any Unicode code point that can be mapped to and from UTF-16. You also might want to have a look at Unicode 4.0, which has added many additional code points for CJK ideographs. (By the way, CCCII is listed among the "Source Standards and Specifications" of Unicode 4.0, chapter R.1, page 1385; also available online from the Unicode site). But if you really need ideographs that are not covered in Unicode, there are the "private usage areas". These are large ranges of Unicode code points that are reserved for private purposes. If you want to write a converter between some character encoding and Unicode (possibly using code points from a private usage area, if Unicode does not provide a code point for a specific ideograph), please have a look that the java.nio.charset package. I think that GNU Classpath would be glad to accept converters. The distinction between character sets and character encodings can cause a lot of confusion. A helpful introduction is [2]. [1] http://java.sun.com/j2se/1.4.2/docs/api/java/nio/charset/Charset.html [2] http://www.unicode.org/standard/principles.html Best regards, -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: gnu.java.awt.image.GdkPixbufDecoder
On Tue, Nov 04, 2003 at 01:45:54AM +0100, Richard Stahl wrote: > hello, > > i have just started using the classpath so maybe a stupid problem: > > i would like to run some code on JikesRVM (which uses classpath). the > code requires gnu.java.awt.peer.gtk.GtkToolkit. if invoking method > getImage() of this class i get an error: > > > java.lang.UnsatisfiedLinkError: Cannot find library cpgdkpixbuf > at > com.ibm.JikesRVM.classloader.VM_ClassLoader.loadLibrary(VM_ClassLoader.java:113) > at java.lang.Runtime.loadLibrary(Runtime.java:191) > at java.lang.System.loadLibrary(System.java:665) > at > gnu.java.awt.image.GdkPixbufDecoder.(GdkPixbufDecoder.java:59) > at > com.ibm.JikesRVM.classloader.VM_Class.initialize(VM_Class.java:1374) > at > com.ibm.JikesRVM.VM_Runtime.initializeClassForDynamicLink(VM_Runtime.java:514) > at > com.ibm.JikesRVM.VM_Runtime.unresolvedNewScalar(VM_Runtime.java:276) > at gnu.java.awt.peer.gtk.GtkToolkit.getImage(GtkToolkit.java:140) > > > so, there is no library "cpgdkpixbuf" required by classloader loading > gnu.java.awt.image.GdkPixbufDecoder while the code really includes > static code for loading native library "cpgdkpixbuf". > > can you, please, let me know how to solve this problem? The problem is simply to tell: the native library is not build during building classpath. Thats a bug in classpath. I made it compile and install this helper library. Can you send me a little testcase for testing before I commit this thingie ? I want to test if GdkPixbufDecoder really works. The version in libgcj has a comment about problems but doesnt tell which problems. Michael ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
gnu.java.awt.image.GdkPixbufDecoder
hello, i have just started using the classpath so maybe a stupid problem: i would like to run some code on JikesRVM (which uses classpath). the code requires gnu.java.awt.peer.gtk.GtkToolkit. if invoking method getImage() of this class i get an error: java.lang.UnsatisfiedLinkError: Cannot find library cpgdkpixbuf at com.ibm.JikesRVM.classloader.VM_ClassLoader.loadLibrary(VM_ClassLoader.java:113) at java.lang.Runtime.loadLibrary(Runtime.java:191) at java.lang.System.loadLibrary(System.java:665) at gnu.java.awt.image.GdkPixbufDecoder.(GdkPixbufDecoder.java:59) at com.ibm.JikesRVM.classloader.VM_Class.initialize(VM_Class.java:1374) at com.ibm.JikesRVM.VM_Runtime.initializeClassForDynamicLink(VM_Runtime.java:514) at com.ibm.JikesRVM.VM_Runtime.unresolvedNewScalar(VM_Runtime.java:276) at gnu.java.awt.peer.gtk.GtkToolkit.getImage(GtkToolkit.java:140) so, there is no library "cpgdkpixbuf" required by classloader loading gnu.java.awt.image.GdkPixbufDecoder while the code really includes static code for loading native library "cpgdkpixbuf". can you, please, let me know how to solve this problem? thank you very much in advance. best regards, richard ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
