[Bug java/27280] New: gcj cannot import inner classes using a wildcard import

[michele at focuseek dot com]

Try the following code:

=== p/A.java ===
package p;

public class A {
public static interface AI {
public static final int n = 3;
}
}
=== p/B.java ===
package p;
import p.A.*;

public class B {
static int main(String[] args) {
System.out.println(AI.n);
return 0;
}
}
==

Building this with gcj fails with the error:
./p/B.java:3: error: Can't find default package 'p.A'. Check the CLASSPATH
environment variable and the access to the archives

JDK 1.5 javac can compile the example. Also changing the import in B.java to

import p.A.AI;

makes it work with gcj, too.


-- 
   Summary: gcj cannot import inner classes using a wildcard import
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: michele at focuseek dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27280

[Bug java/25040] New: gcjh generated .h files missing methods inherited from interfaces

[michele at focuseek dot com]

In the attached example the interface I declares I.blah(). The abstract class A
then implements I but doesn't define the method nor re-declares it as abstract.

Given these definitions both javac and gcj accept calling blah() using an A
reference. Obviously you need to derive a non-abstract class C from A and
create an object of this second class in order to get such a reference.

Instead gcjh doesn't put a declaration for A::blah() in the A.h file it
generates so there is no way to invoke A.blah() from C++.

If blah() is re-declared s abstract in A then gcjh outputs the declaration for
A::blah().


-- 
   Summary: gcjh generated .h files missing methods inherited from
interfaces
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michele at focuseek dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25040

[Bug java/25040] gcjh generated .h files missing methods inherited from interfaces

[michele at focuseek dot com]

--- Comment #1 from michele at focuseek dot com  2005-11-25 23:01 ---
Created an attachment (id=10341)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10341&action=view)
A test case


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25040

[Bug java/43302] New: [Regression] gcc creates "dummy" resources in object files

[michele at focuseek dot com]

gcj adds a java resource named ".dummy" to most (all?) the object file it
produces. That resource doesn't appear anywhere in the sources.

This is a problem when I try to link an application made from multiple .o
produced by separate gcj invocations: I get the link-time error:

 multiple definition of `java resource .dummy'

Also this is a regression as gcj 4.2.2 didn't add it and thus the linker didn't
complain.

gcc was built with the following options:

../gcc-4.4.3/configure --prefix="/opt/focuseek-build-fsk" \
--program-suffix=-fsk \
--enable-languages=c,c++,java \
--enable-shared --enable-threads \
--enable-__cxa_atexit \
--enable-libgcj-multifile

on a centos 5.4. The md5 for ecj.jar is d7cd6a27c8801e66cbaa964a039ecfdb which,
as of today, is what contrib/download_ecj retrieves.

I'm aware of bug 42143 but I'm not able to say whether this is the same bug or
another one.

I will attach a test case as soon as possible.


-- 
   Summary: [Regression] gcc creates "dummy" resources in object
files
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michele at focuseek dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43302

[Bug java/43302] [Regression] gcc creates "dummy" resources in object files

[michele at focuseek dot com]

--- Comment #1 from michele at focuseek dot com  2010-03-09 09:25 ---
Created an attachment (id=20053)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20053&action=view)
A simple test exhibiting the .dummy resources problem

As I said this works with gcc 4.2.2


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43302

[Bug java/42143] [4.3/4.4/4.5 Regression] gcj creates "dummy" variables

[michele at focuseek dot com]

--- Comment #4 from michele at focuseek dot com  2010-03-10 08:05 ---
Yesterday I filed the suspiciously similar bug 42143 with a really simple test
case that fails on gcc 4.4.3 and used to work with gcc 4.2.2. As I wrote in the
description for that bug I suspect it's actually a duplicate of this bug but I
can't confirm it easily as I don't have binutils sources at hand.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143

[Bug java/42143] [4.3/4.4/4.5 Regression] gcj creates "dummy" variables

[michele at focuseek dot com]

--- Comment #5 from michele at focuseek dot com  2010-03-10 08:09 ---
(In reply to comment #4)
> [...] suspiciously similar bug 42143 [...]

I meant bug 43302...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143

[Bug java/43302] [Regression] gcc creates "dummy" resources in object files

[michele at focuseek dot com]

--- Comment #2 from michele at focuseek dot com  2010-03-10 08:30 ---
Experimenting with -save-temps I noticed that the .dummy resource is in the
.jar generated by ecj which seems to point to it as the main suspect.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43302