[Bug libgcj/28977] UTF-16 endianness differs between gcj and Sun JDK
--- Comment #2 from marcus at better dot se 2006-09-07 18:37 --- (In reply to comment #1) > Does this really matter as UTF-16 BOM is correct? Well, I have a library for XML processing that comes with a test suite, and it expects the Sun behaviour. Besides it's documented in Sun's API, so it can potentially matter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28977
[Bug libgcj/28977] New: UTF-16 endianness differs between gcj and Sun JDK
This program gives different results with Sun's JDK (Debian sun-java5-jdk
1.5.0-08-1) and gcj:
Test.java
import java.io.*;
public class Test
{
public static void main(String[] args) throws java.io.IOException
{
OutputStreamWriter o = new OutputStreamWriter(System.out, "UTF-16");
o.write("Hello!");
o.flush();
}
}
===
According to Sun's API docs
http://java.sun.com/j2se/1.5.0/docs/api/java/nio/charset/Charset.html
the UTF-16 encoding is supposed to default to big-endian. This is also
what I get when running with Sun's JVM:
: feff 0048 0065 006c 006c 006f 0021 ...H.e.l.l.o.!
But when I run the same program with gij, I get little-endian output:
: fffe 4800 6500 6c00 6c00 6f00 2100 ..H.e.l.l.o.!.
In both cases I executed the same .class file, compiled with the Sun
JDK.
The system is Debian i386 testing/unstable.
$ gij --version
java version "1.4.2"
gij (GNU libgcj) version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)
This bug was also reported in the Debian bug-tracking system:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386443
--
Summary: UTF-16 endianness differs between gcj and Sun JDK
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at better dot se
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28977
[Bug libgcj/29178] New: CharsetEncoder.canEncode() gives different results than Sun version
The following test program gives different results with gcj and Sun JDK:
// A.java
import java.nio.charset.Charset;
import java.nio.charset.CharsetEncoder;
public class A {
public static void main(String[] args) throws java.io.IOException
{
CharsetEncoder enc = Charset.forName("US-ASCII").newEncoder();
System.out.println(enc.canEncode('\u00e4'));
}
}
// end
$ javac A.java
$ /usr/lib/jvm/java-1.5.0-sun/bin/java A
false
$ /usr/lib/jvm/java-gcj/bin/java A
true
The Sun version seems to return something like (c > 31 && c < 127),
which makes sense, whereas gcj apparently always returns true.
This breaks lots of code, such as Apache JaxMe 2 version 0.51
(specifically the MarshallerTest in the test suite, which generated
invalid XML with gcj).
This was tested on Debian (testing, i386).
~$ gcj --version
gcj (GCC) 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)
The bug was also reported to Debian's bug tracking system:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388596
--
Summary: CharsetEncoder.canEncode() gives different results than
Sun version
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at better dot se
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29178
[Bug libgcj/29869] LogManager class loading failure with Tomcat
--- Comment #5 from marcus at better dot se 2007-03-29 18:11 ---
(In reply to comment #4)
> Third, what's up with the class name "1catalina.org.apache.juli.FileHandler,"?
> Perhaps we are not parsing something correctly?
It comes from a configuration file for the logging mechanism,
/var/lib/tomcat5.5/conf/logging.properties:
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler, 3
manager.org.apache.juli.FileHandler, 4admin.org.apache.juli.FileHandler,
5host-manager.org.
apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
# Handler specific properties.
# Describes specific configuration info for Handlers.
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.
2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.
3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.
4admin.org.apache.juli.FileHandler.level = FINE
4admin.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
4admin.org.apache.juli.FileHandler.prefix = admin.
5host-manager.org.apache.juli.FileHandler.level = FINE
5host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29869
[Bug libgcj/31700] New: [JNI] -X options not recognised by JNI_CreateJavaVM
JNI_CreateJavaVM fails to recognise -X options such as -Xmx and friends. It
says:
libgcj: unknown option: -Xmx128M
I tracked it to this code in libjava/prims.cc:
else if (vm_args->ignoreUnrecognized)
{
if (option_string[0] == '_')
parse_x_arg (option_string + 1);
else if (! strncmp (option_string, "-X", 2))
parse_x_arg (option_string + 2);
else
{
unknown_option:
fprintf (stderr, "libgcj: unknown option: %s\n", option_string);
return -1;
}
}
else
goto unknown_option;
Notice how the -X options are only accepted if vm_args->ignoreUnrecognized is
true. This is contrary to the specification [1] which seems to say that
supported -X options should be recognized in all cases, whereas unknown -X
options should be ignored iff vm_args->ignoreUnrecognized.
[1] http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-12.html
--
Summary: [JNI] -X options not recognised by JNI_CreateJavaVM
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at better dot se
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31700
[Bug libgcj/28977] UTF-16 endianness differs between gcj and Sun JDK
--- Comment #4 from marcus at better dot se 2008-02-03 20:43 --- The bug is still in gcj 4.3. The Sun API docs are quite clear about how this should behave: "When decoding, the UTF-16 charset interprets a byte-order mark to indicate the byte order of the stream but defaults to big-endian if there is no byte-order mark; when encoding, it uses big-endian byte order and writes a big-endian byte-order mark." [1] ~$ gij-4.3 --version java version "1.5.0" gij (GNU libgcj) version 4.3.0 20080116 (experimental) [trunk revision 131577] [1] http://java.sun.com/javase/6/docs/api/java/nio/charset/Charset.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28977
[Bug java/35206] New: Class.getModifiers() returns wrong value for static inner class
Calling getModifiers() for an inner class that is public static returns 33 (public synchronized) instead of the correct value 9. -- Summary: Class.getModifiers() returns wrong value for static inner class Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at better dot se GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35206
[Bug java/35206] Class.getModifiers() returns wrong value for static inner class
--- Comment #1 from marcus at better dot se 2008-02-15 04:50 --- Created an attachment (id=15155) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15155&action=view) Test case Result with gij: ~$ gij InnerTest 33 = public synchronized static: false ~$ gij --version java version "1.5.0" gij (GNU libgcj) version 4.3.0 20080202 (experimental) [trunk revision 132072] Expected result (Sun JRE 6): ~$ java InnerTest 9 = public static static: true -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35206
[Bug libgcj/35253] reflection on annotation objects throws IllegalAccessException
--- Comment #1 from marcus at better dot se 2008-02-19 14:41 --- $ gij -version java version "1.5.0" gij (GNU libgcj) version 4.3.0 20080202 (experimental) [trunk revision 132072] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35253
[Bug libgcj/35253] New: reflection on annotation objects throws IllegalAccessException
The following test program throws an IllegalAccessException with gij,
but works with Sun Java.
~$ gij InvokeAnnotationMethod
Exception in thread "main" java.lang.IllegalAccessException
at java.lang.reflect.Method.invoke(libgcj.so.90)
at test.Helper.invoke(Helper.java:11)
at InvokeAnnotationMethod.main(InvokeAnnotationMethod.java:11)
~$ java InvokeAnnotationMethod
~$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-b105, mixed mode)
The odd thing is that if the test.Helper class below is moved up to
the default package, the program works. So there seems to be some
reflection bug.
Report forwarded from Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466538
- file InvokeAnnotationMethod.java
import java.lang.annotation.*;
import test.Helper;
public class InvokeAnnotationMethod
{
public static void main(String[] args)
throws Exception
{
Annotation ann = Inner.class.getAnnotation(Ann.class);
new Helper().invoke(ann);
}
@Retention(RetentionPolicy.RUNTIME)
public @interface Ann {
public int param() default 0;
}
@Ann
public class Inner
{
}
}
---
- file test/Helper.java
package test;
import java.lang.reflect.Method;
public class Helper
{
public void invoke(Object a)
throws Exception
{
Method m = a.getClass().getMethod("param", new Class[0]);
m.invoke(a, new Object[0]);
}
}
--
Summary: reflection on annotation objects throws
IllegalAccessException
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at better dot se
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35253
[Bug libgcj/35253] reflection on annotation objects throws IllegalAccessException
--- Comment #2 from marcus at better dot se 2008-03-09 14:46 --- BTW this bug makes TestNG fail horribly with gcj, it relies heavily on reflection with annotations of this kind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35253
[Bug libgcj/31700] [JNI] -X options not recognised by JNI_CreateJavaVM
--- Comment #3 from marcus at better dot se 2007-05-14 15:24 --- Subject: Re: [JNI] -X options not recognised by JNI_CreateJavaVM > Could you try this patch? I'm trying, but my brand new Thinkpad insists on rebooting every time I build gcc. Will have to investigate... Marcus -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31700
[Bug libgcj/32198] New: rmic fails if remote method throws superclass of RemoteException
ss c = (Class) iter.next();
Method[] m = c.getMethods();
// Check if throws RemoteException.
for (int i = 0; i < m.length; i++)
{
Class[] exc = m[i].getExceptionTypes();
boolean remEx = false;
for (int j = 0; j < exc.length; j++)
{
if (RemoteException.class.isAssignableFrom(exc[j]))
{
remEx = true;
break;
}
}
if (! remEx && !force)
throw new CompilationError(m[i].getName() + ", defined in "
+ c.getName()
+ ", does not throw "
+ RemoteException.class.getName());
AbstractMethodGenerator mm = createMethodGenerator(m[i]);
methods.add(mm);
}
This code checks that the declared exception exc[j] is a _subclass_ of
RemoteException, when it seems that it should do exactly the opposite!
[1] http://mx4j.sourceforge.net/
[2] http://java.sun.com/j2se/1.5.0/docs/guide/rmi/hello/hello-world.html
[3]
http://gcc.gnu.org/viewcvs/trunk/libjava/classpath/tools/gnu/classpath/tools/rmic/SourceGiopRmicCompiler.java?revision=120621&view=markup
--
Summary: rmic fails if remote method throws superclass of
RemoteException
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at better dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32198
[Bug libgcj/29869] New: LogManager class loading failure with Tomcat
I'm trying to run Tomcat 5.5 with gij. It tries to load a log manager through the java.util.logging.manager property. Apparently the class loading code in java.util.logging.LogManager fails to load the correct class, even though it is on the classpath. The exact same invocation with Sun JDK works correctly. $ /usr/lib/jvm/java-gcj/bin/java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/home/marcus/apache-tomcat-5.5.20/conf/logging.properties -Djava.endorsed.dirs=/home/marcus/apache-tomcat-5.5.20/common/endorsed -classpath :/home/marcus/apache-tomcat-5.5.20/bin/bootstrap.jar:/home/marcus/apache-tomcat-5.5.20/bin/commons-logging-api.jar:/home/marcus/apache-tomcat-5.5.20/bin/tomcat-juli.jar -Dcatalina.base=/home/marcus/apache-tomcat-5.5.20 -Dcatalina.home=/home/marcus/apache-tomcat-5.5.20 -Djava.io.tmpdir=/home/marcus/apache-tomcat-5.5.20/temp org.apache.catalina.startup.Bootstrap start WARNING: error instantiating 'org.apache.juli.ClassLoaderLogManager' referenced by java.util.logging.manager, class not found java.lang.ClassNotFoundException: org.apache.juli.ClassLoaderLogManager not found <> WARNING: error instantiating '1catalina.org.apache.juli.FileHandler,' referenced by handlers, class not found java.lang.ClassNotFoundException: 1catalina.org.apache.juli.FileHandler, <> Exception during runtime initialization java.lang.ExceptionInInitializerError <> Caused by: java.lang.NullPointerException <> This is with a Tomcat 5.5.20 binary distribution from http://tomcat.apache.org, and gij on Debian i386: A workaround is to disable the java.util.logging.manager property. Tomcat appears to run correctly then. $ gij --version java version "1.4.2" gij (GNU libgcj) version 4.1.2 20061020 (prerelease) (Debian 4.1.1-17) -- Summary: LogManager class loading failure with Tomcat Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at better dot se GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29869
