This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

GCJ and generics


   Hi,

   I've tried to use the gcj compiler to compile my project "Frink," a
calculating tool/programming language (
http://futureboy.homeip.net/frinkdocs/ ) to an executable.   gcj is
getting closer; some of the earlier problems (crashes, hangs on certain
class files, odd errors) I've had were improved by installing the
pre-3.4 20031006 build of gcj found here:

http://www.thisiscool.com/gcc_mingw.htm

  But I'm still having problems.  I'm not compiling from source, but
rather from a .jar file.  This is because I'm using a prototype
"generic" compiler from Sun to compile to bytecode.  You may know of
this; it's a compiler developed under the JSR-014 Java Community Process
that adds C++-template-like "generics" support to Java, like:

   Vector<String> vec = new Vector<String>();

   Which is nice because the compiler ensures that vec contains Strings,
and not just any old object, eliminating lots of casts and giving both
compile-time safety and code reuse.

   As far as I know, this bytecode is fully Java 1.1-compliant (I'm
using an older version of the compiler, not the newer ones that broke
forward compatibility) and the bytecode runs on all Java 1.1 and later
platforms I've tested, including SonyEriccson p800 smartphones, and runs
with all Java validity checks like -Xfuture turned on.

   I've removed any AWT or Swing code from the jar file too.  The jar
file contains everything needed to run Frink.

   Unfortunately, the compiler gets partway through (with lots of
warnings) and then gives the following errors like:

c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s: Assembler messages:
c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:4439: Error: symbol
`__ZN5frink5units22BasicObjectEnumeration11nextElementEv' is already defined
c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:7014: Error: symbol
`__ZN5frink5units24ConformalUnitEnumeration11nextElementEv' is already
defined
c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:41771: Error: symbol
`__ZN5frink4expr29DimensionListConstraintSource3getEPN4java4lang6StringE'
is already defined
c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:49063: Error: symbol
`__ZN5frink4expr24FunctionConstraintSource3getEPN4java4lang6StringE' is
already defined
c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:152982: Error: symbol
`__ZN5frink6source14CurrencySource3getEPN4java4lang6StringE' is already
defined
c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:164228: Error: symbol
`__ZN5frink6source9CPISource3getEPN4java4lang6StringE' is already defined
c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:167175: Error: symbol
`__ZN5frink6source11PoundSource3getEPN4java4lang6StringE' is already defined
c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:248935: Error: symbol
`__ZN5frink8security21MagicCollectionSource3getEPN4java4lang6StringE' is
already defined
c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:249314: Error: symbol
`__ZN5frink8security16MagicGroupSource3getEPN4java4lang6StringE' is
already defined
c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:255278: Error: symbol
`__ZN5frink8security20PermissionTypeFilter11nextElementEv' is already
defined
c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:338725: Error: symbol
`__ZN5frink8security30BasicManager$ObjectEnumeration11nextElementEv' is
already defined
c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:339586: Error: symbol
`__ZN5frink8security36PermissionTable$PrincipalEnumeration11nextElementEv'
is already defined

c:\DOCUME~1\eliasen\LOCALS~1\Temp/ccusaaaa.s:416251: Error: symbol
`__GLOBAL__I__ZN3org6apache3oro4util17GenericCacheEntry6class$E' is
already defined

   (Even running this manually through c++filt didn't help, by the way.)

   It's not like C++ templates, really.  You can't put primitives in
template arguments.  The compiler doesn't create multiple template
instantiations or extra classfiles for different template signatures,
but "erases" the types at compile time and provides only a single
classfile as before.  Calls to templated types are "wrapped" in
appropriate casts.  The distributed code runs with a standard JVM and
standard Java runtime libraries.  You don't, say, ship a new version of
Vector or Enumeration with your jarfile.

  The methods that produced the errors above shouldn't have multiple
instantiations in code, but they're common in that the files producing
errors have a signature like:

public class MagicGroupSource implements Source<Group>

or

public class BasicObjectEnumeration<T>
	implements java.util.Enumeration<String>

   Where the classes implement a templated interface.  The methods
complained about are things like (the first error above in
BasicObjectEnumeration is):

 public String nextElement()

   Where the method in question is specified by the implemented interface.

   Nonetheless, I believe this is valid bytecode and that the methods
being complained about are really not instantiated multiple times.

   Is there anything I can do to improve this situation and try to force
the compile to proceed?  Is someone interested enough in this rather odd
case (which may become quite prevalent when generics are released in
Java 1.5) to have a look?  Again, I have reason to believe that this
bytecode is valid as it runs on any 1.1 JVM and passes all verification
tests that I can throw at it.  I've used this prototype generic compiler
for over 2 years and never had any other problems with compatibility.

   If so, the jar file is available at:
http://futureboy.homeip.net:8000/frinkjar/frinkgcj.jar

   (It's a calculator and programming language.  If you manage to get it
to compile, try something like entering "2 feet + 3 meters" when you get
it running, or see the docs referenced above for more calculations you
can try.)

   Please let me know if there's anything I can do to provide more
information or debug.  GCJ has great promise and I hope that it'll be
able to work for me too!

-- 
  Alan Eliasen                 | "You cannot reason a person out of a
  eliasen@mindspring.com       |  position he did not reason himself
  http://futureboy.homeip.net/ |  into in the first place."
                               |     --Jonathan Swift



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]