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]

Re: GCJ and generics


Mohan Embar wrote:
> For grins, you can try passing:
> 
> -Wl,--noinhibit-exec
> 
> ...to the gcj command you use to link and
> see what happens....

   I wasn't aware of this option but I tried it (both with one hyphen
and two; I saw it documented both ways.)  Unfortunately, it didn't work.
   It appears to be more to un-inhibit linking if symbols are *un*defined.

   It looks like several of our messages crossed over in the air.
Thanks to Cedric for helping clear up my ignorance.  I've read the
relevant part of the JVM spec and understand that this is indeed valid
bytecode.

   As far as I know, and have just verified, this is the way that the
bytecode will be in Java 1.5, and no changes have been made to the idea
of type erasure and creation of bridge methods.  Perhaps someone who
knows the right questions to ask could clarify the bytecode issue with
Neal Gafter who comprises all of Sun's compiler team.  If so, his e-mail
address is available at:

http://www.gafter.com/~neal/

   I'd use the e-mail address in the scanned business card at top, as
I've been able to communicate with him at this address.  I don't want to
post it directly to prevent spamming him unintentionally.

   I've just verified what I can glean of Sun's intent from Neal's
postings to the Java developer forums (as late as October 13) that the
current type erasure technique is what will be used.  He states:

   "Its an unfortunate consequence of backward runtime compatiblity with
existing code that erasure is the only technique available to us."
http://forum.java.sun.com/thread.jsp?thread=452549&forum=316&message=2065929

   Another interesting point is that what was once a viable option, the
-s option to the generic compiler, which would compile generic Java to
plain Java source (which could theoretically then be compiled with gcj)
is no longer an option, because it won't be supported.

   "I don't think it is possible to translate your program into legal
Java, which is why I don't plan to support the -s option in the product."
http://forum.java.sun.com/thread.jsp?thread=453678&forum=316&message=2065877

   Questions could also be posted to the "Adding Generics" section of
the Java Developers Forum, which is now read by Neal:

http://forum.java.sun.com/forum.jsp?forum=316

   It appears that bytecode methods which differ only in return type
will be common sooner or later, and this case will have to be handled.

   Again, thanks for all the information!

-- 
  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]