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
