4 ms·

That doesn't sound like an improvement.

pmelendez 11y ago
It is actually... It is going straight to native and built in on the browser instead of a call to a plugin and then a VM and finally to native.
- niccaluim 11y ago
  Java runtimes generate machine code just like V8 does, and there's no functional difference between "built-in" code and a plugin. A plugin is just a shared library.
  - RyanZAG 11y ago
    At the time Java was being used in browsers, it had a lot of problems with that machine code generation. It took a long time for the JIT to kick in. The JITed x86 code it produced was poor. The startup time to load in the various libraries required by the applet tech was incredibly slow. It only started downloading the actual java code to run after the applet itself had finished loading everything. And more issues. There problems were never truly about the idea being bad: it was the implementation that was terrible and was hindered even further by the Sun-Microsoft lawsuits, etc. If everyone is on board with a technology and work to make it usable instead of 'feature complete', then it is very easy to make this work where Java applets failed. It's actually easy to make Java applets work where Java applets failed if you were to re-implement the idea with the correct focus and buy-in. It's not technology - it is politics.
coldtea 11y ago
Well, considering it was: - isolated (outside of DOM) - non standard (not everywhere) - third party (proprietary) - alien (uncanny value of different UI style) - bloated (even compared to the web stack, Spring was an over-engineered badly designed mess of a GUI API) - insecure (full of exploits to this very day, tons of them closed just last year) it does sound as a great improvement. Except in case you weren't there and can't remember.
- niccaluim 11y ago
  I was very much there, and I'd sooner eat my cat than go back to that era of Java. But C++? Is that really the best we can do? Everyone's so afraid of breaking backwards compatibility but I don't see any other way out of the never-ending accretion of hacks Eich left us with.
  - jacobolus 11y ago
    Not C++ per se, but anything that can compile to WebAssembly, which should right away include anything with an LLVM toolchain, and should down the line include any compiled language for which someone puts the work in to add WebAssembly as a compile target. I’m also hoping it winds up being friendly enough to hand write WebAssembly for small chunks of numerical code. With asm.js, that’s currently kind of a pain.
  - dikaiosune 11y ago
    Rust in the browser?

It is actually... It is going straight to native and built in on the browser instead of a call to a plugin and then a VM and finally to native.

niccaluim 11y ago
Java runtimes generate machine code just like V8 does, and there's no functional difference between "built-in" code and a plugin. A plugin is just a shared library.
- RyanZAG 11y ago
  At the time Java was being used in browsers, it had a lot of problems with that machine code generation. It took a long time for the JIT to kick in. The JITed x86 code it produced was poor. The startup time to load in the various libraries required by the applet tech was incredibly slow. It only started downloading the actual java code to run after the applet itself had finished loading everything. And more issues. There problems were never truly about the idea being bad: it was the implementation that was terrible and was hindered even further by the Sun-Microsoft lawsuits, etc. If everyone is on board with a technology and work to make it usable instead of 'feature complete', then it is very easy to make this work where Java applets failed. It's actually easy to make Java applets work where Java applets failed if you were to re-implement the idea with the correct focus and buy-in. It's not technology - it is politics.

coldtea 11y ago

Well, considering it was: - isolated (outside of DOM) - non standard (not everywhere) - third party (proprietary) - alien (uncanny value of different UI style) - bloated (even compared to the web stack, Spring was an over-engineered badly designed mess of a GUI API) - insecure (full of exploits to this very day, tons of them closed just last year) it does sound as a great improvement. Except in case you weren't there and can't remember.

niccaluim 11y ago
I was very much there, and I'd sooner eat my cat than go back to that era of Java. But C++? Is that really the best we can do? Everyone's so afraid of breaking backwards compatibility but I don't see any other way out of the never-ending accretion of hacks Eich left us with.
- jacobolus 11y ago
  Not C++ per se, but anything that can compile to WebAssembly, which should right away include anything with an LLVM toolchain, and should down the line include any compiled language for which someone puts the work in to add WebAssembly as a compile target. I’m also hoping it winds up being friendly enough to hand write WebAssembly for small chunks of numerical code. With asm.js, that’s currently kind of a pain.
- dikaiosune 11y ago
  Rust in the browser?