No if you take care to switch to 23 when it is there to be always inside of the support time. But you can use multiple jdk, In the project options you can choose
Whatās great about the JVM is all the cool JVM languages that in many cases reduces the verbosity of Java itself - Clojure, Kotlin, Ceylon, Scala, Groovy, Gosu and my current favorite JVM language, Fantom. 
This stupid speaking about verbosity. Where is the problem with it? I canāt believe that there is any problem.
Itās just a personal preference. I personally donāt like to write getters/setters or fancy OOP. To me types and type bound procedures is enough.
2 Likes
IMO electron is optional (and i donāt like it) but javascript/html/css runs on pretty much everything.
Electron isnāt a real option. Threading, performance and a few other things are a real problem.
I mean, many large companies such as Discord, Microsoft, Spotify, and Valve have decided Electron is a real option. There are also many open source projects that choose Electron.
It may be a performance hog and battery drain, but I wouldnāt say that it is not a real option.
2 Likes
āThereās a fine line between clever and stupidā - SpinalTap
Java is often considered verbose because it requires more boilerplate code to accomplish tasks compared to other languages. This can make the code more tedious to write and read. Hereās a comparison between Java and Kotlin (a more concise JVM language) to illustrate this.
Example 1: Data Classes
Java
public class Person {
private String name;
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Person person = (Person) o;
return age == person.age && name.equals(person.name);
}
@Override
public int hashCode() {
return Objects.hash(name, age);
}
@Override
public String toString() {
return "Person{" +
"name='" + name + '\'' +
", age=" + age +
'}';
}
}
Kotlin
data class Person(val name: String, val age: Int)
Example 2: Singleton
Java
public class Singleton {
private static Singleton instance;
private Singleton() { }
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
Kotlin
object Singleton
Example 3: Null Safety
Java
public class User {
private String name;
public User(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
// Usage
User user = new User("John");
if (user != null && user.getName() != null) {
System.out.println(user.getName());
}
Kotlin
class User(val name: String)
// Usage
val user = User("John")
println(user?.name)
Example 4: Functional Programming
Java
List<String> names = Arrays.asList("John", "Jane", "Smith");
List<String> upperNames = names.stream()
.map(String::toUpperCase)
.collect(Collectors.toList());
Kotlin
val names = listOf("John", "Jane", "Smith")
val upperNames = names.map { it.toUpperCase() }
These examples demonstrate how Kotlin reduces verbosity compared to Java by offering built-in support for common patterns, more succinct syntax, and advanced features like null safety and inherent functional programming paradigms. This can lead to more readable and maintainable code. 
4 Likes
Nice but wrong. There is no need to build getters and setters all time. And: you can generate them automatically with the IDE (Netbeans, IntelliJ and also Eclipse doing that, I donāt know if VSCode is doing that also and I even donāt want to know).
Also: you check if the class is null in Java what is not needed. Initialize the variable with null when writing your class. In an instance of this Object you can use it. With or without getters and setters.
Also in Kotlin you should use getters and setters. But in your eyes Java is sooo verbose. Like in c++ you donāt need getters and setters in Java when the class is public. Even in Kotlin it is needed if you donāt want to expose the field. There are in Java, c++, kotlin and many more getters and setters from exactly this reason. Holding the control.
So what you wrote has no connection with the reality. NO connection.
1 Like
It is known that Java is rather verbose. This is not MY opinion per se, but the opinion of the industry. If there were no issues with Javaās verbosity, then Java could have remained as it was pre-Java_8 and there would be no attempt in the industry to address said verbosity with newer and more āmodernā JVM languages.
Itās great that you pointed out the ability to auto-generate getters and setters with an IDE. However, the need for such auto-generation itself underscores Javaās verbosity. It is known that code is read and maintained far more often than it is initially written. The cognitive load of reading succinct syntax is much lower than reading verbose syntax when maintaining an existing code base.
In any case, I find quite a few of your comments to be rather unclear and potentially misleading. For example, it may be true that in both C++ and Java, you can make class fields public and access them directly, thus bypassing the need for getters and setters. However, this practice is discouraged in OOP because it breaks encapsulation, which is a core principle aiming to protect data integrity by providing controlled access to class properties.
You also suggest initializing the variable with null when writing the class. This is confusing because initializing a variable to null doesnāt solve the problem of null pointer exceptions - it just sets the variable to null. 
It solves the problem of not initialized variables. True. And verboseā¦people like you are speaking about it. Your example had nothing to do with reality. It is known that it is verboseā¦hmmā¦I donāt think that you have knowledge how to work with java today.
Your answer shows me that you really believe that Java is not real oop. It is one of the best oop systems worldwide. And your Ideas having again nothing to do with the reality. Millions of java programmers using oop every day with java since decades. What do you think? All of them are wrong? Sorry. May be I am too much Java and C++ user to accept your Ideas. But wrng ideas are wrong ideas.
The verbosity problem was sinking under the level of verbosity of c++ with java 8. But I guess you have not enough knowledge with java. It is a fast to learn and to use language. Programmers coming from c++ can learn it really fast. I know many c++ programmers which are using both, c++ and java. But. None of them said Java is more verbose than c++. The other way around.
So stop this form of hatespeaking against java without any real knowledge about the language. And serve an alternative where everybody can say: okay, that is my cross platform language with the same broad ecosystem and the same platform support and the same functionality or even more. Good luck when searching. And, small tip: it is definitely not GO.
It is just a fanboy rant, not an objective review. Dont waste time there. 
Sorry but no. But this misleading verbosity discussion for exampleā¦is not objective at all.
Java 8 WAS verbose
Modern Java isnt
Not like it used to be
Thereās an entire Reddit thread about this
https://www.reddit.com/r/java/comments/19745i3/is_java_really_that_verbose/
We dont ned to rehash that here
3 Likes
yeah. Please no.
I thought I was being rather objective, but it appears Iām āhatespeakingā? But it is good manners to categorically call someoneās comments āwrongā, āstupidā? Thatās not hateful at all. 
It is while I am confronted with wrong arguments which had nothing to do with reality. And that argumentation you tried to drive forward. Sorry for that. But I was ttacked too many times exactly with this arguments and I tried to discuss that over long time now. Since java has lost itās verbosity compared to other languages I would say: sorry for selecting wrong words.
Theyāre OPINIONS
Something where there is no right & wrong
NOW I will accept that there ARE language usage differences
Iāve found that Germans are VERY absolutist in how they speak & write
When they say āYOU MUSTā it often really means āYou shouldā
And when they write āyouāre WRONGā they really mean āI disagreeā ESP when it comes to things involving opinions
So each side take a breath
Calm down
Write a response
Let it sit for 20 minutes to reread and rethink whether you are stating FACTS
Or if it should be said as āIn my opinionāā¦
And edit as needed
EDIT : typos corrected
2 Likes
Norman, it is not an opinion when somebody writes like in this case that getters and setters are needed but not in other languages. That is not true at all. And yes, there is no way to behave like that. You canāt say you must do it otherwise it does not work. While it is not so. That kind of argument would not even work with java 7. Beside that it is even with Kotlin like that. Or with Objective-C. And with C# with the same āshitā. That said you may also recognize that there is no verbosity description inside. So I was using to rude words. That because I am rid of the endless discussions of verbosity of java. Rid in that case: speaking about verbosity when like in this case all languages having the same construct behind. Then why it is not verbose in C#, Kotlin, C++, ObjectiveC, Python, GO and many more. And then declare that it is not real OOP. Wow. Java, the most OOP language is not OOP and destroys OOP. Exactly that way you canāt go without getting corrected. Why? While it is simply not true. The author may believe it. But it becomes not true from believing. And it is not only Java using this construct like I described.
And on the other Side it helps also to use the getter and setter for additional functionality. While setting a variable with a setter you can control the given data for fitting the variable conventions. Or format a given string that it fits the conventions. Or filter it. Makes sense to do it on a central point. While then you have the control and you will need to write it only one time. Doing the same in other classes will be in the result the need to implement it more often when using the same variable from another class to set it where it is not implemented yet. If implemented in getter: no problem.
So there is a good chance to have even less boilerplate code and save much time when programming.
Getting back to the subject matter at hand ā¦
Speaking of another rich ecosystem. dotNet appears to be moving in the right direction with much of it being open-sourced and cross-platform development being paramount. 3rd party tools like Avalonia and Uno look very promising. And there are some cool CLI-languages, besides the big three (C#, F#, VB_Net). REMObjects Oxygene is one of my personal favorite with its Pascal-flavored syntax.
1 Like