3 ms·

It looks like the patents that Oracle is claiming are being infringed upon focus on the actual JVM itself, not on the code run on it. Google making their own JV

It looks like the patents that Oracle is claiming are being infringed upon focus on the actual JVM itself, not on the code run on it. Google making their own JVM is what's brought them into the crosshairs.

hga 16y ago
Which could be rather bad if you need a JVM tuned in a non-standard way. Anyway you look at it, Oracle has enabled a lot of FUD to be thrown at Java, and if your observation is correct, andyone who's working on any sort of non-Oracle derived JVM (and there are a bunch) had just been handed a lot of legal uncertainty. Side note: I don't need hearing this shortly after learning about the RightHaven atrocity factory.
- bad_user 16y ago
  > andyone who's working on any sort of non-Oracle derived JVM Except Dalvik is not derived from the JVM. Sure they use the language, but what, are you going to tell me that I can't make a compiler that translates JVM bytecode to something else? Should projects like http://ikvm.net http://ikvm.net be illegal? Oracle is destroying the biggest advantage Java has.
  - hga 16y ago
    Very good point! Dalvik very much isn't a JVM. While both are bytecode interpreters you need to translate Java bytecodes into Dalvik ones to use the former. I'll need to read more (just woke up) to see just what Oracle is objecting to. Bytecode based systems are an old old old concept due to the severe lack of memory available in the bad old days, e.g. I personally know that as of the mid-late '70s the Lisp Machine's compiler went to a bytecode that the microcode would then interpret. As I recall Smalltalk did this and I know it wasn't a new concept. Heck, what about UCSD's Pascal system? Don't know the history of JIT compilation, let alone various tricks that have recently been developed; Java is the second wildly successful bytecode system, I think, after UCSD's, which was done back when memory was a lot more precious. And Dalvik optimized for among other things low memory demand, e.g. it is register based and Java bytecode is stack based. Thanks for pointing this out.

hga 16y ago

Which could be rather bad if you need a JVM tuned in a non-standard way. Anyway you look at it, Oracle has enabled a lot of FUD to be thrown at Java, and if your observation is correct, andyone who's working on any sort of non-Oracle derived JVM (and there are a bunch) had just been handed a lot of legal uncertainty. Side note: I don't need hearing this shortly after learning about the RightHaven atrocity factory.

bad_user 16y ago
> andyone who's working on any sort of non-Oracle derived JVM Except Dalvik is not derived from the JVM. Sure they use the language, but what, are you going to tell me that I can't make a compiler that translates JVM bytecode to something else? Should projects like http://ikvm.net http://ikvm.net be illegal? Oracle is destroying the biggest advantage Java has.
- hga 16y ago
  Very good point! Dalvik very much isn't a JVM. While both are bytecode interpreters you need to translate Java bytecodes into Dalvik ones to use the former. I'll need to read more (just woke up) to see just what Oracle is objecting to. Bytecode based systems are an old old old concept due to the severe lack of memory available in the bad old days, e.g. I personally know that as of the mid-late '70s the Lisp Machine's compiler went to a bytecode that the microcode would then interpret. As I recall Smalltalk did this and I know it wasn't a new concept. Heck, what about UCSD's Pascal system? Don't know the history of JIT compilation, let alone various tricks that have recently been developed; Java is the second wildly successful bytecode system, I think, after UCSD's, which was done back when memory was a lot more precious. And Dalvik optimized for among other things low memory demand, e.g. it is register based and Java bytecode is stack based. Thanks for pointing this out.