- 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.
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.
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
Quite a few. It's a solid choice for a startup for a variety of reasons:
- The Java (and more generally, the JVM) ecosystem is huge and includes stable, performant libraries and frameworks for just about every use case you can have. No need to re-invent the wheel.
- Java as a language is mature and performant, but is still actively being improved.
- No vendor lock-in. There are multiple implementations of everything including the JVM itself (unlike C# for example).
- There are very good tools for developing, debugging and profiling JVM applications.
- Some of the most popular big-data related tools are all based on the JVM. Just to name a few - Kafka (Scala), Hadoop (Java), Cassandra (Java), Spark (Scala), Ignite (Java), Elasticsearch (Java), Storm (Clojure), Neo4j (Java) and many more. So even if you're not using Java, you're probably using Java.
- Android apps are JVM-based. So every startup with a native android app is writing Java (or Kotlin).
- Hiring Java developers is easy(er). Everyone knows Java. Want to hire a junior developer? No problem. Want a veteran with 20 years of Jave experience? You can find those too.
- Java is well supported - due to its popularity, vendors usually offer first class SDKs and support for Java developers.
- There are many JVM-based languages. Don't like Java? No problem - you can use Clojure, Kotlin, Groovy, Scala, JRuby or even Jython. Some of them are even directly compatible with Java (and/or each other) so you can mix and match in some cases.
In fact, I recently had to create a cross-platform desktop app, and I'm still not aware of a better option then the JVM. I would have preferred to write it in Scala, but opted for Java to make it easier for the rest of the team to maintain.
Java isn't an awesome language, but it's fine. There's a lot of awful legacy Java code out in the wild, and I wouldn't want to work on it. But Java as a language is boring, inoffensive, and it works. As a result, it's probably going to be around for a long time.
What GUI library(ies) did you use? Just Swing? Java-FX as well?
I'm curious about this - I've developed the macOS part of a desktop app, where the Windows part used WPF, and we shared C# code (.net core, so it would run in both platforms).
The advantages were that each app looked 'native' to its OS. But in my opinion, the disadvantages outweighed them: a) No linux support. b) Double the work on the UI parts.
The Java alternative would reverse this: no native-looking UI elements, but they would be done once and run everywhere, including Linux. Another alternative would be Electron, but I feel (though I'm not sure) Java would be more performant.
Can anyone chime in on this? I know there's no definitive winner on this space...
I've written almost no Java before this project, and I had never used JavaFX before. It took about 2 weeks to go from beginning to end on the project, which I was happy with.
We're also moving ahead with our plan to replace node with the jvm for our backend.
2 (main reason). Our codebase has turned into a disaster, and we realized that none of our node developers are senior despite what their resume says; our interview process was more geared towards hiring anyone than hiring well. We tried finding a more senior node engineer, but we couldn't given our time constraints, so I'm taking some of our actual senior engineers from our mobile team, and the consensus was that we wanted to work with Kotlin.
Recently we have started a migration of our pipeline to Kubernetes, so these improvements are a real benefit to our use case.
Java is absolutely huge in the corporate world, where they build new projects with it all the time.
edit: sorry I mean other than startups you'll find plenty.