FULL PRODUCT VERSION :
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014; root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64

A DESCRIPTION OF THE PROBLEM :
In a small test and manual byte code manipulation I created a situation where:

... // long value on stack
lstore_1
...
... // ref value on stack
astore_1
return

To my surprise this bytecode was runnable.

According to JVM specification sections

http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.10.1.4

and

http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.10.1.2

this should not verify.

The current implementation seems to be more lenient than the JVM specification. This bug affects me as follows:

I am working on a bytecode generator / compiler whose implementation would be greatly simplified if I could assume the current lenient verification to remain, namely I can reuse local variable slots for different types if they are ultimately overridden.

However, considering that the specification does not seem to allow this I must assume this to break in the future and will need to opt for a different, more involved implementation scheme (i.e. using new variables for different types).

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create class file with bytecode of the form:

... // long value on stack
lstore_1
...
... // ref value on stack
astore_1
return

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expected the bytecode verification to fail because the code assigns a reference value to a long-typed local variable.
ACTUAL -
Bytecode verification passed.

REPRODUCIBILITY :
This bug can be reproduced always.