Data classes may come to Java.
http://cr.openjdk.java.net/~briangoetz/amber/datum.html
http://mail.openjdk.java.net/pipermail/amber-spec-experts/20...
Fibers, continuations, string literals, pattern matching and value types are in the works.
http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.htm...
http://openjdk.java.net/jeps/326
I’m more concerned with the copyright status of Java APIs. Can you really be sure that you will be safe from Oracle’s clutches?
Building something using OpenJDK using Java APIs shouldn't get you in any trouble.
What got Google in trouble with Oracle was that they copied and re-implemented all of Java's APIs. Are you planning on doing something similar?
... was a big wallet.
Only both projects are pretty pointless to sue since they aren't making any money.
We're looking for engineers in London incidentally, if anyone is interested. See my post in this month's who's hiring.
- Many engineers know Java to at least an intermediate level, so they can be productive quicker (and hiring is easier)
- We had some existing libraries written in Java, so integrating them with the web platform was much easier if we went down the JVM route
- Java is the language most familiar to members of the startup (including me, although I also have experience in RoR, Kotlin, ObjectiveC and JavaScript)
Technical:
- Java is generally very performant and running on the JVM means we don't generally have to worry about platform specific issues (there are well known exceptions of course e.g. file path issues)
- The language itself is at a reasonable level of abstraction. It is strongly typed and IMO, writing a non-trivial backend in a dynamically typed language is a sub-optimal choice. It has a huge ecosystem of robust, battle tested libraries that are indispensable to us (e.g. JGraphT). There is a huge community - you are unlikely to run into 'uncharted' territory
- It is popular to hate on Java but it really isn't that bad a language, especially if you aim to follow guidelines like those in Effective Java (probably my favourite programming book) e.g. avoiding mutable state and side-effects. It will never be as good as a modern language like Kotlin (data classes are my favourite feature there), but it is good enough
- The server frameworks available are seriously robust and 'just work'
- There is always the option of using alternative JVM languages (we use Kotlin for a large part of the backend)
In summary, we are 6 months into developing the web platform, progress is rapid, and we have no regrets (yet) about the technology choices. IMO, sometimes boring is best.