Alternative way to count the vowels in Kotlin:
val numVowels = countVowels(getDTO()?.string ?: "")Revisiting Java in 2021 – Part II
71–80 of 146 posts
Re: Revisiting Java in 2021 – Part II
#72Earlier quoted context omitted.
Do you know what the legal relationship is between Red Hat and Oracle is? I think Oracle v Google has sent shivers of fear through anyone wanting to rely on Java, including through an intermediate, because the strength of the relationship is only as strong as the weakest link in the chain. In other words, what is the risk that Red Hat will be sued by Oracle someday over their use and support of Java?
Let’s say Oracle sues Red Hat (now IBM), so what? Are android devs all totally screwed because Oracle sued Google? I’m not going to defend Oracle’s business practices but this seems like FUD. You can use Red Hat, Amazon, or Azul’s jvm. If it’s too “scary” to do so for your company than you need better executives and/or lawyers.
> If it’s too “scary” to do so for your company than you need better executives and/or lawyers.
That is the point though. It's sort of obvious if you read through the terms. But if you're at a company that is already afraid of words like GPL, the JDK is "now" also scary.
At the same time, even if your legal department are scared of Oracle (and really just stories of "I heard Oracle sued Google"), I claim that the Corretto docs (and similar) are quite clear.
Re: Revisiting Java in 2021 – Part II
#73I use Java every day, but we're stuck with Java 8 because of the confusing and frankly scary licensing around later JDKs. I would love to move to 17 but I need something to show to the C-levels that gives them warm and fuzzies around the license. Does such a thing exist? EDIT: I find it quite depressing that so many want to attack people for being confused around Java licensing. I submit that it is confusing on its f…
The licensing around post-8 JVMs is neither confusing nor scary. If you're confused or scared by it, that is entirely on you, i'm afraid.
Great, then explain it.
Re: Revisiting Java in 2021 – Part II
#74One point that the author fails to mention regarding Jetbrains is that they developed Kotlin and that Intellij at this point is largely implemented in it. Their whole strategy features a lot of Kotlin at this point. So, the best IDE for Java is built by the company that develops a drop in replacement for it. Not a minor point to make. The IDE that Oracle acquired along with Sun (Netbeans) is still there of course but…
Kotlin's dependency and relationship with IntelliJ is one of the largest reasons why I don't use it. I really dislike IntelliJ and Kotlin is mostly unusable without it. I don't see why I should force my company into vendor lock-in (IntelliJ/Kotlin) on what is otherwise an open platform (Java/OpenJDK).
This is unfortunate indeed. I'm hoping the Kotlin language server for VS Code will get some love, it doesn't seem to be working at this point.
Re: Revisiting Java in 2021 – Part II
#75> Build tools such as Maven and Gradle are fast, stable and effective
Exactly the opposite of what comes to mind when I think of these.
Re: Revisiting Java in 2021 – Part II
#76Earlier quoted context omitted.
Let’s say Oracle sues Red Hat (now IBM), so what? Are android devs all totally screwed because Oracle sued Google? I’m not going to defend Oracle’s business practices but this seems like FUD. You can use Red Hat, Amazon, or Azul’s jvm. If it’s too “scary” to do so for your company than you need better executives and/or lawyers.
> If it’s too “scary” to do so for your company than you need better executives and/or lawyers. That is the point though. It's sort of obvious if you read through the terms. But if you're at a company that is already afraid of words like GPL, the JDK is "now" also scary. At the same time, even if your legal department are scared of Oracle (and really just stories of "I heard Oracle sued Google"), I claim that the Cor…
But if you're at a company that is already afraid of words like GPL, the JDK is "now" also scary.
These companies either only develop software peripherally to their business, in which case sticking with java 8 is probably going to be fine, if silly, or they are the walking dead.
Re: Revisiting Java in 2021 – Part II
#77One point that the author fails to mention regarding Jetbrains is that they developed Kotlin and that Intellij at this point is largely implemented in it. Their whole strategy features a lot of Kotlin at this point. So, the best IDE for Java is built by the company that develops a drop in replacement for it. Not a minor point to make. The IDE that Oracle acquired along with Sun (Netbeans) is still there of course but…
IDEA is 56% Java and 15% Kotlin.
Re: Revisiting Java in 2021 – Part II
#78I'm not a huge fan of Java, but a lot of the improvements being worked on here are promising. I'm 90% certain I would only really start working on a project if we could use Kotlin just because the ergonomics are vastly superior. If that requires the trial-by-error mentioned ITA to figure out the best practices of various approaches available I think I'd take that trade off.
Have the ergonomics of Scala improved with version 3? I‘m planning on revisiting Scala at some point
Yes, a large part of Scala 3 was explicitly about improving ergonomics and making language features clearer to use. Some examples of this are:
- Greatly improved error messages [1]
- Revamped implicit syntax that makes it more straightforward to declare type classes and extension methods. [2]
- Simplified support for macros [3]
[1] - https://www.scala-lang.org/blog/2020/05/05/scala-3-import-su...
[2] - https://dotty.epfl.ch/docs/reference/contextual/type-classes...
[3] - https://docs.scala-lang.org/scala3/guides/macros/index.html
Re: Revisiting Java in 2021 – Part II
#79Earlier quoted context omitted.
> A superficial reading might be that Oracle's JDK does not come with the GPL encumbrance. This is the whole point of the "classpath exception". You can run, build and distribute Java programs under any license you choose. > But this also raises the question: what differs between the various JDK builds? Very little typically. Some like RedHat or Amazon enable extra options, like the Shenandoah GC. The big difference…
How about this: what is "OpenJDK"? It used to be an independent open-source clone of the Sun-then-Oracle implementation of the JVM/JLS/JSR specs under a liberal license. Now it seems to mean something different - like a working group that manages the specs, but no longer has a build of it's own. By convention, it seems that Oracle's "OpenJDK build" is the "default" OpenJDK build, but Oracle also provides a "commercia…
OpenJDK was never an independent clone. OpenJDK was started by Sun and was all of the JVM code they could relicense. Contributions to it were done either by Sun themselves, or by companies and individuals that signed a contributor agreement. This has continued under Oracle. Notably this includes Redhat, IBM, Microsoft, Azul, Apple and SAP. Originally the code didn't have enough components to produce a useful JVM, and Redhat put a lot of effort into producing builds that integrated with IcedTea to produce a fully Free Software JVM. Now though the OpenJDK has all of the components needed to produce a JVM.
OpenJDK is Oracle's reference implementation of Java, and provides a GPL+Classpath exception licensed build on their website. Additionally, Oracle provides a build a commercially supported build from their website. The commercial builds from Oracle have included other additions, but over the years the amount of closed sourced add-ons has decreased.
Other vendors provide builds of the OpenJDK, most include additional code, although for the most part the changes are minimal. All of these builds are based on the OpenJDK, and adhere to the GPL+Classpath exception.
There is also Azul Platform Prime/Zing. Which is there own JVM with an LLVM-based JIT, I'm not sure if they're using any OpenJDK code, but if so I assume they have a commercial agreement with Oracle.
Re: Revisiting Java in 2021 – Part II
#80I'm not a huge fan of Java, but a lot of the improvements being worked on here are promising. I'm 90% certain I would only really start working on a project if we could use Kotlin just because the ergonomics are vastly superior. If that requires the trial-by-error mentioned ITA to figure out the best practices of various approaches available I think I'd take that trade off.
I've been using Kotlin since 1.0 but I have to say the ergonomics of it are not vastly superior to Java.
As others have mentioned, with Kotlin you're pretty much limited to Jetbrains' IDE, you have a new runtime dependency, not just a compiler, which is rapidly changing and requires updates on the code base frequenly (one of my projects used Kotlin for testing with KotlinTest - which recently changed names to KTest I think - and it was horrible to have to re-write most of my hundreds of tests to be able to upgrade when they went from JUnit 4 to 5 and in the process re-wrote all of it, basically), the compiler is slower and it starts to feel very much once you have thousands of lines of code... not to mention that there's a fairly big overhead of not only having to have javac installed, but also the Kotlin compiler and standard library... also, you probably want to use Gradle with the Kotlin DSL which in my view is really, really slow and unpleasant to work with - though they've finally been improving this recently - in the last couple of years.
So, yeah, I like to write Kotlin code better than Java, but due to all of these factors and the fact that Java is now fairly close to Kotlin in functionality, if I had to start a big project today, I would pick Java for sure.