Bytecode features not available in the Java language

[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);

[TheLoneWolfling]

That's in the list:

> Overflow and implicitly assign byte, short, char and boolean values

[peeters]

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

[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

[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.

[pests]

Which bytecodes do you mean? If you're talking about the jsr/ret thing they still have functionality but the compiler just doesn't generate those.

[kragen]

What is the sound of one hand clapping?

[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:
	      ...