Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Susan Calvin Newsgroups: comp.lang.java.programmer Subject: Re: Java generics and type erasure Date: Thu, 26 May 2011 01:12:28 +0000 (UTC) Organization: A noiseless patient Spider Lines: 52 Message-ID: References: <9d4c2b16-beb5-40b1-87a2-f03e971efeed@k17g2000vbn.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Thu, 26 May 2011 01:12:28 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="8GQpfR98UwRtBuI+o3WctQ"; logging-data="19641"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/HjaHznnSy2pe2XOuqBNCPio6p0BbiHWA=" User-Agent: slrn/3.1 (USERIX 1.7) Cancel-Lock: sha1:cuyWEJlK29g0Y47Bz9UVFRpnG8I= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4587 On Thu, 26 May 2011 10:18:20 +1200, Lawrence D'Oliveiro wrote: > In message , Susan Calvin wrote: > >> The only reason I can think of for not doing this (the logic seems >> simple enough to implement) is that it turned out doing so would break >> legacy code that used util collections' raw types. Was that why? > > Yup. Much of the complexity attendant on introducing generics into Java > was precisely because of that need for backward compatibility. > >> Perhaps there should be a compile flag that turns on the >> legacy-compatible behavior for use when compiling 1.4 and older >> sources, but which is off by default? > > What happens when you mix code compiled with that flag, with code that > was compiled without? Why, nothing, of course, since generics don't exist at run-time. Both Integer x = aFoo.m1.get("quux"); (in the file compiled with the flag) and Integer x = (Integer)(aFoo.m1.get("quux")); (in the file compiled without it) would compile to the same bytecode, including a checkcast for Integer. This is only an issue for source compatibility, not binary compatibility. And there are far worse problems with generics and especially with autoboxing. For example: int x = aFoo.m1.get("quux"); Guess what happens if "quux" is not found? There should probably be a shorthand way to check for this -- maybe a variation on the ?: operator that tests its left hand side for null, evaluates to it if it's not, and evaluates to its right hand side otherwise, e.g. int x = aFoo.m1.get("quux")?:-1 perhaps would make x -1 as a sentinel for "not found" in this instance. Actually, the Java 5 features have several rough spots that aren't easy to smooth over. Java really should have been designed with generics and better integration of primitive types into the type system from the beginning. Now we have these ad hoc bandaid solutions that show visible seams here and there and we're probably going to have to live with them for the next forty years, just as we're living now with 40-year-old COBOL code.