

Bytecode features not available in the Java language - henk53
http://stackoverflow.com/a/23218472/472792

======
malft
Didn't see my favorite on the list: creating the bool 2. I believe there are a
couple of methods in the JDK that do

    
    
        if (dangerousFlag == true) doCheck();
        ...
        foo(dangerousFlag ? bar : baz);

~~~
peeters
Wait, I love learning new things about Java, but I feel in the dark here. What
is your example demonstrating?

~~~
onedognight
If true is book(1) then the check

    
    
        bool(2) == true
    

will fail but

    
    
        bool(2) ? a : b
    

will act as if bool(2) were true and this inconsistency could lead to
unintended execution paths.

~~~
peeters
Ah, I'm with you. Thanks.

------
peeters
As far as not catching checked exceptions goes, this is actually possible in
the Java language as well since the language allows throwing a generic type
parameter. It's pretty difficult to do by accident though, and does at least
give a compile warning.

    
    
        public class Dangerous {
        
            public static void main (String ... args) {
                Dangerous.<RuntimeException>throwUnchecked(new IOException("Forgot to catch me!"));
            }
        
            static <T extends Exception> void throwUnchecked(Exception e) throws T{
                throw (T) e;
            }
        }

------
jodah
I knew the SO answer must have been written by Raf before I even got to the
author section. Check out his great library, ByteBuddy, if you want to try
mucking with some of this stuff:

[http://bytebuddy.net](http://bytebuddy.net)

------
whitten
If the Java Virtual Machines don't always execute certain Java Byte Codes, how
does a compiler to JVB for another language know that the generated code is
run ?

~~~
krilnon
There's an official specification for what and how a program that claims to be
a JVM implementation should operate given Java bytecode. So someone writing a
language that compiles to Java bytecode would typically either target the
specification (and test on as many implementations as they felt necessary), or
target a specific implementation like HotSpot and ignore the rest.

------
quotemstr
You can define two methods that differ only by return type. That's how
covariant returns work. Check the javap output and recoil in horror.

~~~
peeters
True. One of them is a bridge method.

Here's an example:

    
    
        class CovariantReturn extends CovariantReturnBase {
            public Integer produce() {
                return 5;
            }
        }
        
        class CovariantReturnBase {
            public Number produce() {
                return 4.5;
            }
        }
    

And the relevant javap output for CovariantReturn:

    
    
    	  public java.lang.Integer produce();
    	    flags: ACC_PUBLIC
    	    Code:
    	      ...
    
    	  public java.lang.Number produce();
    	    flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC
    	    Code:
    	      ...

