20
"Having more obstacles removed is great and I hope Java will go on that track heavier", — Alexander Levin
Hello jLovers!
Our next speaker, Alexander Levin, has shared his thoughts about what is going on in the Java community!
Alex is a senior software engineer specializing in full-stack development and Kotlin. He is passionate about knowledge sharing and brings his expertise to idiomatic Kotlin. He is an active member of a community for Kotlin starters.
What new countries have you “visited” thanks to the online format?
I think... none? :D
Yeah, it happened to be mostly either Russian or German conferences, so no new countries for me.
How has your programming style with Java evolved over the past couple of years? What are some of the things that led to the significant improvements?
It's... hard to say. Partially because I am writing in different styles on different languages. Like code on Kotlin, on Scala or on Java will be 3 different types of code.
You can think that with Java evolving quickly my style can change with Java but reality is different. Like even stuff that is coming from Java 8 is sometimes hard to use. Example of that - you cannot switch fully from imperative code to functional one even with Stream API due to incompatibility with checked exceptions.
So in Kotlin you will have:
val result = input.map { service.callWithPossibleException(it, someOtherParam) }
And in Java you will have:
var result = new ArrayList<>(input.size());
for (var it: input) {
result.add(service.callWithPossibleException(it, someOtherParam));
}
While it's not that bad in this example, it creates weird inconsistency.
What is planned for Java after Java 17? How will it change the everyday life of a Java developer?
Define "Java developer" I guess :D
While I hope it will be better soon, it's hard to say anything about changes when a lot of devs are still using Java 8.
Definitely not all of them and even for them there are ways to improve the situation (like Jabel) but the situation is still a bit sad.
But if we try to look more optimistically then the situation is interesting as we have a great balance of adding all types of stuff: security-related things, new features, performance improvements etc. I hope that this balance will stay even after Java 17 :)
There are Groovy, Scala, Kotlin, and many others in the family of JVM languages. What features do we miss in Java in comparison with other JVM languages? Elaborate.
Main thing from Kotlin and Scala 3 - extensibility and ease of use. It's great to have as few obstacles as possible when you want to quickly write something.
More concrete examples of that:
** Easy main function. Like in Java you have class, weird method notation etc, and in Kotlin you have:
fun main() = println("Hello World")
And it's pretty easy in Scala 3 as well:
@main def helloWorld() = println("Hello World")
That thing is easier to explain, easier to read and possible to quickly write even on a smartphone :)
** Extension functions
While it's debatable whether extension functions are the best approach (or something like pipe operators), having any of them is a great way to create a more fluent API and decouple unnecessary stuff from the class itself.
Unfortunately not that much progress on that from Java (except using experimental Lombok stuff or Manifold)
** Standard library functions
While you can argue that Kotlin sometimes going too far with them (example: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/first-not-null-of-or-null.html) the idea of having a lot of easy to use utilities is great.
Less need for libraries like Guava/Apache Commons, more or that - it's even possible to do some short scripts without bothering with adding any libraries for convenience.
So... Yeah, having more obstacles removed is great and I hope Java will go on that track heavier :)
In the beginning, Make was the only build automation tool available beyond homegrown solutions. Make has been around since 1976, and as such, it was used for building Java applications in the early Java years.
However, many conventions from C programs didn't fit in the Java ecosystem, so in time Ant took over as a better alternative. Maven continues to use XML files just like Ant but in a much more manageable way. And then, Gradle was built upon the concepts of Ant and Maven. Fancy Gradle or old school Maven? Or Ant?!
It's an interesting question. On one hand, I love the idea that Maven is pretty simple (at least when you don't use Ant plugins inside) and 99% of the time it just works fine with that simplicity. Also I love how it's supported in IDE.
On the other hand, I don't really like how verbose Maven is. It can be solved to some extent with Maven Polyglot project but it will kill all IDE compatibility immediately. Also when you started to be this 1% of users when not everything works great out-of-the-box Maven started to feel pretty unpleasant.
With Gradle it's kinda the opposite: sometimes it's hard to see any structure and there are a lot of ways to do the same thing. Even for the simplest stuff like adding dependency!
But if you have a "unique" problem (or at least you feel like it's unique) you can just quickly script some stuff and that's it.
On a personal level I would prefer working with Gradle right now but I wouldn't say that this choice is set in stone :)
Note: touched Ant only once so no opinion on this tool. Used Make just as "great place to put some scripts" so also hard to discuss about it as build tool :D
Alex will run his session Custom IDE inspections for effective testing on the 26th of June at 13.30 CEST! Join him!
20