Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 12, 2013 21:12 UTC (Thu) by juhah (subscriber, #32930)
In reply to: Security of Java takes a dangerous turn for the worse, experts say (ars technica) by smurf
Parent article: Security of Java takes a dangerous turn for the worse, experts say (ars technica)

I'd like to point out that Java 8 will improve syntax little in some cases:
Arrays.asList(1,2,3,4,5,6).stream().map(n -> n * n);

That said, Java syntax will still be far from python elegance, in general.

What is perhaps more interesting is JVM, not Java. Go checkout Clojure and Scala if you haven't heard of them yet. And how they all compare:
http://benchmarksgame.alioth.debian.org/

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 13, 2013 18:25 UTC (Fri) by jonabbey (guest, #2736) [Link] (7 responses)

I hear a lot of great things about Scala, including from some of my co-workers who are developing with it.

For myself, I'd preferentially choose to work with Clojure, but most of my Java work is in Ganymede, an open source network directory management framework, and I don't want to scare away the few people that seem inclined to adopt it by making them grok Lisp.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 16, 2013 23:25 UTC (Mon) by HelloWorld (guest, #56129) [Link] (6 responses)

The problem with Scala and Clojure is that they are hampered by the inadequacies of the JVM.

Structural types in Scala are slow (use introspection because the JVM doesn't allow for a class to retroactively implement an interface (Sun's "fix" for that is java.lang.reflect.Proxy, which is really just an ugly hack))
generics on the JVM suck
- introspection is broken, something like foo instanceof Bar<Baz> doesn't work)
- crazy inefficiencies due to boxing (an ArrayList<Byte> requires around 4 machine words per byte of payload) leading to hacks like GNU Trove or Scala's
no support for value types, so crazy inefficient if your objects are small (and let's not talk about the fact that every object carries around a lock, even if it's never accessed concurrently)
the type system is fucked up (covariant mutable arrays, wtf? And they have covariant return types, but no contravariant argument types (except if the argument happens to be this, yeah, that makes sense. Not.))
No tail call optimization, so compiler authors need to work around that, which is basically impossible except for simple cases

And that list isn't even exhaustive.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 17, 2013 5:15 UTC (Tue) by peter-b (guest, #66996) [Link] (5 responses)

> No tail call optimization, so compiler authors need to work around that, which is basically impossible except for simple cases

Makes it literally impossible to implement a Scheme on top of the JVM, for example (the Scheme spec *requires* tail call optimization).

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 17, 2013 10:34 UTC (Tue) by eru (subscriber, #2753) [Link] (3 responses)

Makes it literally impossible to implement a Scheme on top of the JVM, for example (the Scheme spec *requires* tail call optimization).

Now I'm curious: How can the JVM prevent tail call optimization? After all, it is just a matter of updating the variables that correspond to the parameters of the function, and then executing a goto to its start. And the JVM (being a low level language) has a goto.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 17, 2013 11:50 UTC (Tue) by peter-b (guest, #66996) [Link]

There's an interesting question on Stack Overflow that covers this:

http://stackoverflow.com/questions/105834/does-the-jvm-pr...

Don't forget that "true" tail call optimization implies that *any* tail call can be optimized, not just the self-recursion<->loop case.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 17, 2013 12:04 UTC (Tue) by HelloWorld (guest, #56129) [Link]

That's the kind of workaround I was referring to, it breaks for non-trivial cases, for example when it's not known at compile time which function implementation a call will end up in.

scala> import scala.annotation.tailrec
import scala.annotation.tailrec

scala> class Test {
     |   @tailrec def apply { apply }
     | }
<console>:9: warning: method apply in class Test does nothing other than call itself recursively
         @tailrec def apply { apply }
                              ^
<console>:9: error: could not optimize @tailrec annotated method apply: it is neither private nor final so can be overridden
         @tailrec def apply { apply }
                      ^

It fails even for simple mutually recursive definitions:

scala> @tailrec def even(x: Int): Boolean = x == 0 || odd(x - 1); @tailrec def odd(x: Int): Boolean = x != 0 && even(x - 1)
<console>:10: error: @tailrec annotated method contains no recursive calls
       @tailrec def even(x: Int): Boolean = x == 0 || odd(x - 1); @tailrec def odd(x: Int): Boolean = x != 0 && even(x - 1)
                    ^
<console>:10: error: @tailrec annotated method contains no recursive calls
       @tailrec def even(x: Int): Boolean = x == 0 || odd(x - 1); @tailrec def odd(x: Int): Boolean = x != 0 && even(x - 1)

It's not just about tail *recursion* optimization, it's about general tail *call* optimization. JVM modifications are needed to make this kind of thing work.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 17, 2013 18:56 UTC (Tue) by jonabbey (guest, #2736) [Link]

The StackOverflow link does a good job talking about the problem. Clojure gets around this by having explicit loop and recur statements that the Clojure compiler uses to set up trampolines as needed for recursion.

Without having JVM-level support, though, you do lose some tooling support and flexibility. It would make a very nice addition to the JVM, albeit more work to do than the invokedynamic feature that was added in Java 7 to support dynamic languages on the JVM.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 21, 2013 7:27 UTC (Sat) by Per_Bothner (subscriber, #7375) [Link]

Of course it's not literally impossible to implement full tail-call optimization on the JVM - it's just harder. Kawa has long done so. It uses a special calling convention, using a thread-specific CallContext object. This calling convention is optional, because it is slower, and doesn't interoperate with "native" Java as directly - you enable it using an optional --full-tailcalls flag. (Note you can mix code compiled with --full-tailcalls and --no-full-tailcalls.) (Also note that Kawa even with full tailcalls enabled is still generally faster than Clojure.)