Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Casting without Generics Date: Mon, 9 Jul 2018 17:59:41 -0400 Organization: A noiseless patient Spider Lines: 44 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 9 Jul 2018 21:59:44 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="f4774f41d776d8a1f45f2a9326b95747"; logging-data="22164"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/qlYDRfh9fWbBZIq9zdGA7" User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Cancel-Lock: sha1:w54hQgxDTfVFbIU9hZO9JoNdVaY= In-Reply-To: Content-Language: en-US Xref: csiph.com comp.lang.java.programmer:38479 On 7/9/2018 3:54 PM, Stefan Ram wrote: > The following programm yields no compile-time error > using the JDK 10: > > Main.java > > public final class Main > { public static void main( final java.lang.String[] args ) > { final java.lang.CharSequence cs = "abc"; > java.lang.System.out.println( ( java.io.PrintStream )cs ); }} > > transcript > > Exception in thread "main" java.lang.ClassCastException: java.base/java.lang.String cannot be cast to java.base/java.io.PrintStream > at Main.main(Main.java:4) > > Why? It surprised me, too -- at first. But consider: class Perverse extends PrintStream implements CharSequence {...} ... is certainly not forbidden, and if you were to write such a thing it would then be possible to have a CharSequence instance that would survive the cast-check with no trouble at all. The mere fact that some reference is to a CharSequence does not imply that it cannot also be to a PrintStream. > I used to believe that the compiler would complain that > »java.io.PrintStream« is neither a super- nor a subtype > of »java.lang.CharSequence«. > > Did I miss something? The rules are spelled out in JLS 5.1.6, with special reference to 5.1.6.1-3. Roughly speaking, the compiler need not object to a conversion that is *possibly* valid if there exists a foolproof way to check the validity at run-time. (If there's no foolproof run-time check the compiler must object unless the conversion is *assuredly* valid.) -- esosman@comcast-dot-net.invalid Nine hundred twenty-six days to go.