I presume you mean native opcodes, not java-bytecode-opcodes. There is no reason to add new bytecodes if all these API methods are known to be intrinsic, besides, there’s very little room to add new bytecodes anyway. The same strategy will be used when they (finally) add methods like Integer.add(a, b) [all primitives] to the API, so that other languages that run on the JVM can simply make method calls, instead of relying on the limited provided functionality by the java-classfile specification.
Yes indeed I meant native opcodes.
I seriously doubt they’re removing primitive types from the language given how incredibly incompatible that would be. I suspect they just plan to make boxed types actually fast by way of specialization (what every decent compiler since the 80’s has done) instead of the half-assed hack they are now.
There’s a lot of things that just aren’t going to get fixed about Java though, so it’s good to see they’re keeping emphasis on making the VM a suitable target for other languages that do fix Java’s shortcomings
More info (Lang.NEXT presentation from John Rose) on Java 8. Interesting how invokedynamic will be tied with lambdas.
Also, a great proposal on how value types could be introduced to the language/JVM.
“permgen removal”. “retire the classpath”. Those kind of things make me giddy with excitement.
What really gets me excited is seeing the creative use of invokedynamic as a sort of lazy meta-object protocol for lambdas. That to me is actually more interesting than the lambdas themselves.
I’m all for abandoning the JVM, but what IS an embeddable library? Apparently my Google-fu is off today.
Why would you want to abandon the JVM?!?
You can easily bundle the JVM with your application so that you can run on your JVM, guaranteed. You would no longer need to depend or expect a user to be capable of installing a system-wide JVM (that could be a different version, etc).
It does not mean abandoning the JVM as a concept, just giving you more control over how you invoke the JVM to run your application.
This
With ‘abandon the JVM’ he means ‘abandon the public JRE’.
Ohhh 
That seems to be the direction that they are headed in. Alot of the slides show “classpath” crossed out. Breaking up packages into separate & versioned bundles. So I’d assume that a JRE just becomes a collection of all the various versions.
Yes! And support iPhone runtime and Google NaCl.
I love the JVM alt-language space, the libraries, the IDEs, the build tools, and the fast runtime performance (faster than almost everything except C/C++). Those pieces are what keep me excited about JVM. I don’t think I’d build another serious project in plain Java; I’d rather use Scala or maybe Kotlin.
Java 8 Jigsaw has some awesome potential.
It seems to me that Oracle is making some very good decisions about Java’s direction. And I’m also getting the impression that things are moving a little faster now than in the recent past.
Yes, we might be getting back to the glory days of early 2k.
Cas 
If by “the recent past” you mean the last 5 years that won’t be too difficult
Even crawling along at a snail’s pace is better than a complete standstill (except for some bug fix / security hole fix AKA applet break releases)
Still I see the platform diversify even more. More languages than you can shake a stick at, and more are coming. I used to like diversity and freedom, but in today’s world it is actually a big hindrance IMO; people don’t seem to think like that anymore.
State of the Lambda: Libraries Edition; Stream vs Iterable, lazy vs eager seeking, pipelined operations.
Also, technical details on how lambdas will be translated to bytecode: Translation of Lambda Expressions