How does GNU classpath implement char?
Hi guys, I was wondering - how does gnu classpath implement char (the primitive value). The Sun Java documentation sasy that char is a 16 bit positive value that has the representation of a character in UTF-16 encoding. http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Character.html (This is about the wrapper class, but it has some info on char as well). The info for char is here: http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.1 http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#88061 http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#95413 So it seems to me that only BMP characters are representable in char. What should be done (in programming) in order to use characters outside BMP? Best regards: al_shopov ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: rmi vs cajo
Mark Wielaard writes: > > While playing a bit with Cajo > (http://wiki.java.net/bin/view/Communications/ProxyUsage) I got the > following error: > > java.lang.NullPointerException >at gnu.cajo.invoke.Remote.hashCode (Remote.java:510) >at java.util.Hashtable.hash (Hashtable.java:822) >at java.util.Hashtable.put (Hashtable.java:432) >at gnu.java.rmi.server.UnicastServer.exportObject (UnicastServer.java:66= > ) >at gnu.java.rmi.server.UnicastServerRef.exportObject (UnicastServerRef.j= > ava:110) >at java.rmi.server.UnicastRemoteObject.exportObject (UnicastRemoteObject= > .java:83) >at java.rmi.server.UnicastRemoteObject. (UnicastRemoteObject.java:= > 69) >at gnu.cajo.invoke.Remote. (Remote.java:486) >at gnu.cajo.utils.ItemServer.bind (ItemServer.java:206) >at ProxyTest.main (ProxyTest.java:38) > > It seems we are to eager to export the Remote object immediately (from > the constructor). We want to put it in a Hashtable and call hasCode(), > but for the cajo Remote object the item field used to calculate the > hashCode() hasn't been set yet so that gives a NullPointerException. Isn't this a simple failure by gnu.cajo.invoke.Remote to satisfy the contract for hashCode()? As I understand it, hashCode() should not throw any exception. Andrew. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How does GNU classpath implement char?
> "Alexander" == Alexander Shopov <[EMAIL PROTECTED]> writes: Alexander> I was wondering - how does gnu classpath implement char Alexander> (the primitive value). In a technical sense, Classpath doesn't -- it just leaves the low-level representation of char to the VM. Alexander> So it seems to me that only BMP characters are Alexander> representable in char. What should be done (in programming) Alexander> in order to use characters outside BMP? AIUI, 1.5 has a lot of library updates to allow for 'int' codepoints that lie outside the 16 bit range of a java 'char'. For the most part we have not implemented these APIs yet. They don't look intrinsically hard, just voluminous... Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[Bug classpath/23860] New: Exception in JComboBox.removeAllItems()
The following program works in Sun's JDK but fails in libgcj6: cat > crash.java << EOF import javax.swing.JComboBox; class crash { public static final void main (String args[]) { JComboBox c = new JComboBox (); c.addItem ("foo"); c.removeAllItems (); } } EOF gcj-4.0 --main=crash crash.java ./a.out Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1 at java.util.Vector.elementAt(int) (/usr/lib/libgcj.so.6.0.0) at javax.swing.DefaultComboBoxModel.getElementAt(int) (/usr/lib/libgcj.so.6.0.0) at javax.swing.plaf.basic.BasicComboBoxUI$ListDataHandler.intervalAdded(javax.swing.event.ListDataEvent) (/usr/lib/libgcj.so.6.0.0) at javax.swing.AbstractListModel.fireIntervalAdded(java.lang.Object, int, int) (/usr/lib/libgcj.so.6.0.0) at javax.swing.DefaultComboBoxModel.removeAllElements() (/usr/lib/libgcj.so.6.0.0) at javax.swing.JComboBox.removeAllItems() (/usr/lib/libgcj.so.6.0.0) at crash.main(java.lang.String[]) (Unknown Source) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) -- Summary: Exception in JComboBox.removeAllItems() Product: classpath Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: classpath AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: konqueror at gmx dot de CC: bug-classpath at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23860 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug classpath/23859] New: Assertion failure when calling JTabbedPane.addTab(null, ...)
Thanks to gcj's ability to compile native code that can be debugged with gdb, I finally could narrow down and report this bug that I first noticed with libgcj4 or libgcj5. The program runs fine under Sun's JVM, but libgcj aborts because of an assertion failure. I keep getting an assertion failure and SIGABRT when my program calls JTabbedPane.addTab() with null first argument. If I replace the first argument with a string (even an empty one) or if I run the code under Sun's JVM, there is no assertion failure. Here is a minimal test case: cat > crash.java << EOF import javax.swing.JTabbedPane; import javax.swing.JTable; class crash { public static final void main (String args[]) { JTabbedPane t = new JTabbedPane (); JTable jt = new JTable (); t.addTab (null, null, jt); } } EOF gcj-4.0 --main=crash crash.java ./a.out ** ERROR **: file ../../../src/libjava/jni/gtk-peer/gnu_java_awt_peer_gtk_GdkFontPeer.c: line 290 (Java_gnu_java_awt_peer_gtk_GdkFontPeer_getTextMetrics): assertion failed: (cstr != NULL) aborting... Replace the first argument of t.addTab() with "", and the assertion won't fail. Note that the program works under Sun's JVM. Marko -- Summary: Assertion failure when calling JTabbedPane.addTab(null, ...) Product: classpath Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: classpath AssignedTo: roman at kennke dot org ReportedBy: konqueror at gmx dot de CC: bug-classpath at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23859 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: How does GNU classpath implement char?
Hi. > AIUI, 1.5 has a lot of library updates to allow for 'int' codepoints > that lie outside the 16 bit range of a java 'char'. For the most part > we have not implemented these APIs yet. They don't look intrinsically > hard, just voluminous... Sven has implemented a lot of 1.5 functionality in Character already. Still the file says it it updated to 1.5 but JAPI scores for Classpath vs. 1.5 show no missing methods (only some unicode code points). Sven can you comment on this a bit? cu Robert ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How does GNU classpath implement char?
Hi, again. I obviously overlooked something in the JAPI comparison. There are indeed missing all the methods that deal with and 'int' as a character. cu Robert ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How does GNU classpath implement char?
> "Robert" == Robert Schuster <[EMAIL PROTECTED]> writes: Robert> I obviously overlooked something in the JAPI comparison. There Robert> are indeed missing all the methods that deal with and 'int' as Robert> a character. There are also some in places like String, StringBuffer, etc. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Bug swing/23850] New: ProgressMonitor unimplemented
I just want to announce that I want to implement this (But my bugzilla account is not properly set up yet.) cu Robert roman at kennke dot org wrote: > The class javax.swing.ProgressMonitor and related classes are complete stubs > and > should be properly implemented. > ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: RFC: Generics branch VM interface
On Thu, Jun 16, 2005 at 12:08:18PM +0200, Jeroen Frijters wrote: > Hi, > > I'd like to propose a fundamental change to the VM interface on the > generics branch. In particular, I'd like the VM interface (and in this > case I mean strictly the interface between the Foo and VMFoo classes) on > the generics branch to be compatible with the main branch. That way a VM > can use the same VM interface code for both branches. > > This means, for example, that in VMClass, we use Class instead of > Class. In some cases this requires additional casts in the > corresponding class, but these casts are removed by the compiler so they > don't affect performance or code size. > > Another example is that VMSystem.environ() would return a String[][] > instead of a List (as an aside, IMO, it's always better to use > built-in types across the VM interface, e.g. manipulating an array in > JNI is easier and more efficient than manipulating a List). > > Another, possibly more contentious, case is VMClass.getTypeParameters(), > this currently returns a TypeVariable>[], but I wonder if it > wouldn't be better to simply return a string and do the signature > decoding (which presumably is common to all VMs) in > java/lang/Class.java. > > Any thoughts? > > Regards, > Jeroen > Has there been any movement on this? I haven't seen any of it being applied to the branch. Cheers, -- Andrew :-) Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments. See http://www.fsf.org/philosophy/no-word-attachments.html No software patents in Europe -- http://nosoftwarepatents.com "Value your freedom, or you will lose it, teaches history. `Don't bother us with politics' respond those who don't want to learn." -- Richard Stallman Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html public class gcj extends Freedom implements Java { ... } signature.asc Description: Digital signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Loader in ObjectStreamClass.readClassDescriptor
Hi Mark, Mark Wielaard wrote: Hi Nicolas, On Tue, 2005-08-02 at 14:08 +0200, Nicolas Geoffray wrote: Hi everyone, sorry for the typo, it was ObjectInputStream.readClassDescriptor that misbehaves. Shortly, when a reading a given class descriptor CL, it loads the class of a field from CL with the currentClassLoader on the stack. But in RMI, the currentClassLoader is null, so loading the fields' classes won't work for classes that are not in the bootclasspath (glibj.zip). The algorithm with RMI will however succeed to load the class CL itself because it uses the method resolveClass from gnu.java.rmi.server.RMIObjectInputStream. The patch given fixes the problem by loading the fields' class of CL with CL's classloader. I agree it looks like we are doing something dodgy here. Using the class loader of the class itself to resolve the field classes seems better then using the current class loader if resolveClass() is overridden. Do you happen to have a little testcase for this? Either using rmi or some other class that overrides ObjectInputStream.resolveClass(). Then we can put that in Mauve. Three files for testing are attached. It's more an RMI related issue, since the thread class for rmi is gnu.java.rmi.server.UnicastConnection, which is loaded by the vm classloader. Consequence is that the current classloader in stack is null. ReceiveObjectImpl is the RMI object. Just rmic and launch it. Then launch Main. While we're at it, there might also be something to change in, this time, ObjectStreamClass.setClass. In the method it tries to compare the serial uids bewteen the local class and the stream class. It does it for all classes, even for array classes, which is wrong because array classes do not have serial uids. An array class does have a serial uid. But it is calculated slightly differently because we have to pretend an array class does not implement any interfaces. I thought arrays do not have uids because their implementation is native. How can you calculate an uid for a native type? I'm also interested to know how compatible are the algorithms between java and gnu classpath for computing the serial version uid? When I tried to communicate a sun vm with mine, it says that my HelloWorld class isn't compatible between the vms. Is that normal or are the algorithms compatibles and I did something wrong? The algorithms should be compatible. But since compilers can generate different class members (like synthetic methods or inner class names) a class compiled with different (versions of) compilers might not have the same serial version uid. See also: http://www.gnu.org/software/classpath/docs/hacking.html#SEC18 OK, thanks Cheers, Mark Cheers, Nicolas import java.rmi.Naming; public class Main{ class Foo implements java.io.Serializable{} class Bar implements java.io.Serializable{ Foo f = new Foo(); } public static void main(String[]args){ try{ Bar b = new Bar(); ReceiveObject ref = (ReceiveObject) Naming.lookup("rmi://localhost/ReceiveObject"); ref.receiveObject(b); }catch(Exception e){ System.out.println("Error : " + e ); } } } import java.rmi.Remote; import java.rmi.RemoteException; public interface ReceiveObject extends Remote{ public Object receiveObject(Object unknown) throws RemoteException; } import java.rmi.*; import java.rmi.server.*; public class ReceiveObjectImpl extends UnicastRemoteObject implements ReceiveObject{ public ReceiveObjectImpl() throws RemoteException{ } public Object receiveObject(Object unknown) throws RemoteException{ System.out.println(unknown); return null; } public static void main(String[] args){ try{ ReceiveObject ref = new ReceiveObjectImpl(); Naming.rebind("ReceiveObject", ref); }catch(Exception e){ e.printStackTrace(); } } } ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
JamVM 1.3.3 released
Hi, I'm pleased to announce the release of JamVM 1.3.3 (http://jamvm.sourceforge.net). This release adds ports to AMD64 and PowerPC64 and a couple of other minor features/bug-fixes. The full list of changes are here: http://sourceforge.net/project/shownotes.php?release_id=356099 Thanks, Rob. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: How does GNU classpath implement char?
> The Sun Java documentation sasy that char is a 16 bit positive value > that has the representation of a character in UTF-16 encoding. As of Java 5.0 that is correct. Previously Java only supported the 16-bit Unicode standards. > So it seems to me that only BMP characters are representable in char. > What should be done (in programming) in order to use characters > outside BMP? UTF-16 allows for the encoding of all Unicode characters within 16-bit values. The values \u to \u are encoded directly. The values above 0x00 are encoded as "surrogate pairs" using two char values. There are methods within the Character class for working with surrogate pairs, and also methods that deal with Unicode code points (any 21-bit Unicode value) directly, by taking/returning int values. Classpath is not yet Java 5.0 compatible, but people are working on that. Cheers, David Holmes ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath