Is java still popular? Though I'm not a big fan of it I wouldn't mind using, but I'm after somewhat recent changes in licensing I'm not even sure I can. I don't fully understand the changes and I'm afraid of oracle coming after me :).
Can anyone explain current caveats and/or limitations with current licensing?
>Can anyone explain current caveats and/or limitations with current licensing?
You can pretty much ignore the FUD posts about Java licensing. There are long winded replies to why it is FUD, but the short answer is it is trivially not a problem. It only applies if you use the Oracle JDK and want a certain type of support. Most of the world doesn't, instead using one of the other free JDKs.
Java is *not* popular in the reddit, HN, etc memesphere. In the real world it remains incredibly popular and a huge number of organisations continue to pick it as their language of choice for back-end development.
Java is more open than ever. Those random “scary” bullshit posts appear here and there but — OpenJDK is the standard reference implementation, and it has the same license as the Linux kernel. Different vendors give you builds of this same source, with some patches here and there, and they might provide support for their versions. One of these vendors is Oracle, who gives away the freemium OracleJDK. The latest LTS release is free to use with support, until the next one comes along, plus one year. But you would read more about different support services if you would need that - the same stuff is available for linux. In general, you can use any of these builds interchangeably, it doesn’t really matter. Like, intellij will offer you to download basically any of them.
So yeah, Java is insanely popular (top 3 language, among JS and Python, only their orders change depending on sane metrics (not you tiobe)), and is completely free with multiple vendors. Also, it’s pretty bullshit to consider Oracle any worse than other companies - they are the ones who completely opensourced OpenJDK and are responsible for 95+% of all the commits.
Java has a huge legacy code bases that depend on it but for new stuff Kotlin is probably the better choice. It is fully compatible with Java, which means you can add Java libraries and import them in your Kotlin code and use, inherit, overwrite functions and classes but also gives all the features of a nice modern language. I haven't used it for a serious project but it felt great from what I saw so far.
Kotlin has a lot of really nice language features and it's Java interop is a big sell, but after digging into the details I'm pretty pessimistic about it's long term success for a few reasons.
They seem to be attempting to move away from the JVM, preferring it's own multiplatform native compilation which is significantly less battle tested and, last I checked, still suffers from serious performance issues. This is a shame too because Oracle has put a lot into the development of GraalVM, which is a great solution for native compilation of JVM languages, but Kotlin still wants to tread it's own path for some reason. It creates a weird fracture in the ecosystem where some libraries only support either multiplatform or the JVM, and I'm pretty sure Java can't even be used in multiplatform projects.
Another big issue is that idiomatic Java code can often feel clumsy to use from Kotlin: for instance Kotlin function types don't map nicely to functional interfaces and the syntax for AutoClosable/try-with-resource statements is awkward. I can only see this getting worse in the future, as Java continues to develop new features and standard library APIs that are designed FOR JAVA. An example of this already happening is Java's in preview structured concurrency API. It makes heavy use of try-with-resource and offers duplicate but not necessarily compatible functionality to Kotlin's own coroutine API.
Also build times... They have gotten better but they are still much worse that any plain Java project and Java build times are already not great.
Java is superior to Kotlin from Java 21 onwards, esp with virtual threads and no function coloring and far shorter compile times. Kotlin has the advantage of lower verbosity of-course, but that is not an advantage when code browsing at 3am.
Kotlin styles also differ considerably unlike Java which is far more uniform in comparison.
munksbeer|1 year ago
You can pretty much ignore the FUD posts about Java licensing. There are long winded replies to why it is FUD, but the short answer is it is trivially not a problem. It only applies if you use the Oracle JDK and want a certain type of support. Most of the world doesn't, instead using one of the other free JDKs.
Java is *not* popular in the reddit, HN, etc memesphere. In the real world it remains incredibly popular and a huge number of organisations continue to pick it as their language of choice for back-end development.
kaba0|1 year ago
So yeah, Java is insanely popular (top 3 language, among JS and Python, only their orders change depending on sane metrics (not you tiobe)), and is completely free with multiple vendors. Also, it’s pretty bullshit to consider Oracle any worse than other companies - they are the ones who completely opensourced OpenJDK and are responsible for 95+% of all the commits.
BlindEyeHalo|1 year ago
Android switched to it as the default as well.
mightyham|1 year ago
They seem to be attempting to move away from the JVM, preferring it's own multiplatform native compilation which is significantly less battle tested and, last I checked, still suffers from serious performance issues. This is a shame too because Oracle has put a lot into the development of GraalVM, which is a great solution for native compilation of JVM languages, but Kotlin still wants to tread it's own path for some reason. It creates a weird fracture in the ecosystem where some libraries only support either multiplatform or the JVM, and I'm pretty sure Java can't even be used in multiplatform projects.
Another big issue is that idiomatic Java code can often feel clumsy to use from Kotlin: for instance Kotlin function types don't map nicely to functional interfaces and the syntax for AutoClosable/try-with-resource statements is awkward. I can only see this getting worse in the future, as Java continues to develop new features and standard library APIs that are designed FOR JAVA. An example of this already happening is Java's in preview structured concurrency API. It makes heavy use of try-with-resource and offers duplicate but not necessarily compatible functionality to Kotlin's own coroutine API.
Also build times... They have gotten better but they are still much worse that any plain Java project and Java build times are already not great.
lenkite|1 year ago
Kotlin styles also differ considerably unlike Java which is far more uniform in comparison.
anta40|1 year ago