
What are the Differences Between Java Platforms from Desktops to Wearables? - pjmlp
http://electronicdesign.com/embedded/what-are-differences-between-java-platforms-desktops-wearables
======
MaggieL
Well, you could always wear one of these...And use standard Java, or even
Scala: [https://goo.gl/2t5hBX](https://goo.gl/2t5hBX)

------
vegabook
Nothing irritates me more than having an unnecessary virtual machine slow down
my code by a factor of 2 or more, hogging memory, and putting a huge headwind
on startup times. It all just grates against my engineering soul. It's like
riding a bicycle wearing platform shoes. And it's the #1 reason that I will
never target Android for my code (also being forced to OOP).

It's not like there are thousands of architectures out there. There's x86 and
ARM. Which language doesn't already do both, natively? We don't need this JVM
anymore, especially in the era of LLVM, though I acknowledge that corporate
intertia means it will never die. However please, corporate drones, do not try
to push Java into IoT. Give us a break.

~~~
brashrat
it grates against my engineering soul when so many of my fellow engineers
forget that the x86's themselves are virtual machines, microcoded
architectures that implement x86's. And that any OS's job upon booting is to
present a new virtual machine to the user--which is why the same box can be
booted as a Windows machine, a unix machine, or a Macintosh--and so to add
some additional code to simultaneously present additional virtual machine
abstractions is not bad engineering, it's the very stuff of engineering.

Abstractions are an efficient way to reduce the complexity of complex
problems, and a virtual machine that allows the same code to run on top of
different architectures can't be said to be "unnecessary".

~~~
vegabook
There is no need for the JVM abstraction anymore, since the multiple
architectures of the 90s such as Sun SPARC, SGI, Mips, PowerPC, X86, DEC
Alpha, AS/400, have been pared back basically to two. Moreover, the more
modern abstraction is the LLVM, which is targeted at the right level -
compiler writers - without saddling the programmers and users with a bloated
code translation layer that they must cart around everywhere they go. The JVM
does nothing for a programmer, abstraction wise, that makes Java easier than,
for example, Golang.

~~~
tadfisher
Well, Android also supports MIPS, so there's three.

Then there are the 64-bit variants, making six.

Then there are the various levels of ARM compatibility and extension
instruction sets, like Thumb-1 and Thumb-2. Android supports two broad sets of
32-bit ARM platforms, so in total you have seven target ABIs [1].

All of which I'm sure LLVM makes completely transparent to the developer and
ekes out the same level of performance as an on-device JIT. Note that the
preceding sentence was sarcasm.

In reality, the VM mostly does not exist on Android beyond what's needed for a
compatible runtime. The ART compiler emits machine code [2], or with the
latest iteration, mostly machine code with stubs for JIT targets. Said code is
in ELF binary format.

[1]
[http://developer.android.com/ndk/guides/abis.html](http://developer.android.com/ndk/guides/abis.html)

[2]
[https://source.android.com/devices/tech/dalvik/#features](https://source.android.com/devices/tech/dalvik/#features)

~~~
vegabook
"ekes out", that's rich. After taxing your native performance at least 50%,
it's now eeking out performance. Haha.

~~~
tadfisher
50% over... C? That's quite respectable for a fully-managed OO language. Go
can't even get close to that for the non-assembly-implemented parts of the
standard lib.

The synthetic benchmarks on ART agree with you, BTW.

At that level of performance, your primary hits are I/O and UI, and that's not
something a faster language target is going to improve. If you are writing
tight loops for, say, scientific number-crunching, you should be writing
assembly or doing GPGPU anyway. In the real world, with real applications,
Java is not the bottleneck on Android; bad programmers and bad APIs are.

Swift is pretty cool though.

~~~
vegabook
I meant to be somewhat flippant. "Sarcastic..." You have made some good
points, tadfisher, especially with respect to the ARM architectures being
fragmented, and the ART compiler. I take those points, and indeed, I do
respect the JVM because it is an awesome piece of engineering to be giving up
very little for the consistent target it provides. And let's be fair, Java and
Scala are not slow languages. I have more of a philosophical problem with the
JVM on the desktop and server ecosystems as these don't really need it anymore
- arguably - and also, you have to admit that JVM languages still force you
down an OO route which is not always very elegant. Even Clojure (apparently)
needs to breathe in some ugly OO syntax if you want to touch the (admittedly
huge) Java ecosystem. Look I use JVM tech: Cassandra in particular, am very
impressed with it (I also code in Java to the Bloomberg API - less impressed
with that). I don't love the JVM as you've gathered, for purist reasons and
the fact that it takes me into a slightly dull corporate sort of culture, but
I know that it has advantages. Anyway fun sparring with you. good points.

------
mchahn
Quite an advertisement here. I love how many languages are the most popular.
This says Java is. Many say Javascript is. Obviously C and C++ can claim this.
Who cares?

