In a few weeks, we are going to celebrate the true festival of the Java language - jLove!
jLoveis an online conference around JVM technologies. The conference started in 2020 and had 2 days, 3 tracks, 60+ speakers including top Java stars (Trisha Gee, James Ward, Venkat Subramaniam, Josh Long, Jessica Kerr, to name a few), 5000+ attendees from around the globe, and from companies like IBM, Microsoft, Oracle, Red Hat, etc. at its first edition.
This year, we decided to continue our lovely tradition and interviewed our jLove speakers about their thoughts, plans, dreams, and projects!
Let’s dive into a boundless ocean of jLove and explore what our speakers want to share with us.
Please, welcome fabulous Piotr Przybył, Software Gardener!
What new countries have you “visited” thanks to the online format?
It's not that easy to answer, because some events have migrated to online format and keep their origin identity, whereas some others were and still are online, gathering attendees from all over the world. For example, can you tell me where jLove is from? ;-) So for sure that would be Romania, Russia, Spain, Turkey (apart from Poland, of course), but I also received questions and feedback from e.g. Vietnam, India, Canada or Brazil.
If there are Java Champions, perhaps we should add Java Princesses and Java Dragons, too?
I'm not sure naming is that important. I mean, in my understanding it's all about recognising someone's efforts and achievements to make the language, the platform and the community better places for everyone, not their background or origin.
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?
Oh yes, thanks to changes we see in Java over last years and expecting to see quite soon, Java developers can push towards more functional and declarative style, favouring immutability and lack of side effects as the primary choice. Record types or lambda-style switch expressions are great examples of that. If wish modules were more frequent, as they allow much cleaner architecture without any tools apart from javac.
One thing that still didn't quite happen in our community is the mental shift to these new ideas. I mean: we're aware of the new APIs, but we still use them in the way we used to think in the past, with the prominent example of if(optional.isPresent()).
When I'm about to start a training on new Java features, I open it by asking people what version of Java do they use. Most of the time the answers say it's Java 8 or above. However, when we come to the details, it's actually the runtime version, because the habits are still Java 7, like "streams perform poorly, so we never use them" and so on. Please don't get me wrong, it was never my intention to suggest "rewrite all your loops for streams", but when we write a new piece of code in a fresh micro-service, maybe we should try this new paradigm too. Or at least be aware of it, it's pros and cons.
Do you have any personal habits around development or self-care that you would like to share with our audience?
Have a garden and at least a bit of flexibility. When the code doesn't flow through your fingers, just leave it for a while and start doing something else. Like remove some real bugs from your vegetables ;-)
Obviously, projects Valhalla, Loom and Amber have received a lot of buzzes, but there is a healthy level of scepticism about the projects. Do you have any thoughts you’d like to share?
In general I like the direction the language and the platform are heading, nevertheless I can't say I welcome every change with full smile. Sometimes it seems as if the platform could be more oriented toward solving more like everyday needs. Let me give you an example: Yoda time was a great success and it was somewhat incorporated into Java 8 as java.time. It was somewhat similar with JPA, so business- and community-driven inventions made their way into the platform. Back in time we had nice XML support, yet somehow I don't see the same happening to JSON, which became de-facto standard of inter-system communication. Sure, we have HTTP/2 client, but it's not trivial to use it for consuming REST endpoints. Text blocks are also nice, but will .formatted work as well as String interpolation in other languages? I'm not so sure about that.
It might be, that even more than two preview feature releases could be nice, something we witness now with project Panama for example.
What is planned for Java after Java 17? How will it change the everyday life of a Java developer?
I can't tell that for sure, I'm nowhere near to decide that ;-)
I think the way we create and even think about the code will keep changing... While e.g. I don't expect reactive programming to go away anytime soon, Loom may change the currents in our waters.
What I hope will happen is that eventually projects Panama and Valhalla will seal the gap that still forces many systems and developers to stay with Java 8. They should enable much more efficient data processing without relying on the sun.misc.Unsafe hacks. And excuse me for not being able to resist from saying that, I'm somewhat happy that JEP-403 will force the OOP fraudsters to craft their --add-opens, because maybe it will make us, developers, more following the standards and conventions, and less hacking.
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.
There are at least a few ;-) I miss val, I miss immutable collection types, I wish we had more null safety... On the other hand, we've already seen a vast number of ideas coming to Java in the past and near future, like REPL, sealing inheritance hierarchies, data containers (records), pattern matching with extractors... Java has its own way many times, but we can't say it's always better or worse. It's different. And please note that keeping a language and platform with more than a quarter of century in good shape is not a trivial task, provided decent backward compatibility should be maintained.
There are plenty of reasons why Java, being one of the older software programming languages, is still widely used. For one, the immense power one wields when using Java is enough to make it their staple—coupled with the possibility of using good Java frameworks that can reduce the turnaround time for big projects. Your favorite framework? What advantages and disadvantages it has?
My favourite framework is the one that does the job which has to be done with sacrificing as little as possible. That's why I have a habit of starting with libraries first, if possible.
In the beginning, Make was the only build automation tool available beyond home-grown 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?!
I'm not using Ant a lot these days, and as for the other two (and friends, like e.g. Scala's build tools) I have no other choice but to be a professional IT consultant and reply: 'it depends'. Both tools made a long way, both are very nice, provided they're used in the proper context and not abused. I tend to suggest Maven when the build is super standard and Gradle, where super flexibility or some wiring is needed. I've been doing wonderful things with all of them, including SBT, so the best tool shall be used and "the best" really depends on the needs. IMHO Java developer should be proficient with both of them and still understand how javac and jar work under their hoods.
Are we going to use modules ever? When we create a module, we organize the code internally in packages, just like we previously did with any other project. So why are packages not enough?
Of course! I think there's a lot of misunderstanding when it comes to modules in Java. I mean, in my reading they're blamed for not solving issues which they were never supposed to solve in the first place. A healthy criticism should always be welcome, but we should rather expect a rabbit to run fast, not dive with sharks.
Up to Java 8 limiting the code use and re-use was rather limited. With only four visibility options (compare that with Scala, for example!) and a all-in-or-all-out final modifier, we had to invent and use some replacements, like static analysers run by CI.
Modules in my reading elevate the clean movement to a whole new level, the level of clean architecture to be precise. Now it's "only" a matter of crafting module descriptors, so the compiler will take care of that for us. This gets especially useful with less experienced team members, so despite being tempted to use a public class from that ...impl package in another module, they can't do that because we're always pair programming with the compiler in Java.
Many people argued that the microsevices are good, because they make avoiding monoliths (and going for modular code)easier, despite TCP overhead. What we saw last years is a hell lot of "micromonolyths", which, despite being theoretically separate modules, have to be deployed all at once, when the time selected by some druids come.
Building modular solutions isn't trivial, many developers complain about that and yet they deny JPMS its chance.
Another thing that's going to happen really soon is adding another dimension to this puzzle, I mean sealed classes here. Whereas modules are for visibility, sealed classes are for extensibility of pieces of our code, so we'll be able to replace the nuke option of final with fine-grained control. I guess various library maintainers (even inside organizations) will enjoy this change, provided that they'll give it a chance.
Sebastian Daschner gave a talk in Russian this year. I know that you’re learning Russian as well - for the same purpose? ;)
Not really. We have exercises for our muscles, why not to try develop different areas of our brains?
I learn not only Russian, learning is fun and understanding other people helps a lot in direct communication. Maybe one day I'll give a talk in Russian, who knows? ;-) For sure I won't be able to compete with Sebastian, as he practices his Russian every day with a great passion.
As a PC member yourself, do you feel that COVID changed the process of selecting talks?
It allowed one thing for sure: giving a virtual talk can be easier for some people, especially less known speakers from developing countries for example. They don't need to worry about an expensive travel.
Of the negative aspects, giving remote talks is much more difficult, I think. We're quite lucky in IT industry, because we master the technology better than an average person, still the lack of human factor is very challenging and some speakers, fully understandably, don't want to do that. I promised myself not to go for pre-recorded talks, because I see not much value compared to just watching YT videos.
Therefore program committees have one more challenge this days: how to help speakers not to feel alone, when talking to a webcam in their room.
Some of your talks are about Java’s new features. What upcoming feature makes you excited to the extent of wanting to give a talk about it once released?
Even if I'm not excited about some new Java features, I'll try to cover them all, depending on their general usefulness for JVM developers. And please don't make me to pick my favourite one, there are way too many.
Register to attend
Check out our Website
Join us!
*original spelling retained
Top comments (0)