"Java Champions are inclusive, and gather people of various backgrounds and origins",— Guillaume Laforge

Would you mind if we share our secret with you? Ready?

We are so passionate about what we are doing! You can't even imagine how much!
Our philosophy is: always make something that really matters, goes from the heart to every involved soul! We love the community, we admire people!
And we expect people will share our visions and help us make jLove brighter, more innovative, exciting, and challenging. Because jLove is about people first!

So, Guillaume Laforge is our next amazing speaker!

Guillaume is a Developer Advocate for Google Cloud, focusing on serverless technologies. He's also the co-founder of the Apache Groovy programming language project and a member of the technical advisory board for Micronaut. Additionally, Guillaume is also a Java Champion.

I’ve been mostly in Europe (Belgium, Germany, France, UK) and in the US, virtually. But the one country addition was in Europe, with Portugal! That’s my first time there, and hopefully one day, it’ll be in-real-life!

Java Champions are inclusive, and gather people of various backgrounds and origins. There are also programs like JDuchess for the women of Java, which would be your Java Princesses! But I don’t think there’s anything close to a Java Dragons group yet! Now I’m wondering who would be part of it!!!

That’s a great question! Although there are plenty of new APIs, new syntax constructs throughout the various Java releases, I haven’t adopted them that much, and keep writing “simple” non-cryptic Java, with idioms and syntax developers are not necessarily yet very familiar with. Instead, the one thing that I’ve tried to work on, especially since being a Developer Advocate, was really the readability of my code, with clear variable names, explicit method names, to avoid any confusion when others read the code. We often underestimate the fact that code is more read than written!

With the pandemic situation, working from home, often over lockdown periods, the one thing that helped be go through this period was exercising. You’re mentally stressed, you’re not managing to write that code that you’re thinking is supposed to be easy to write, for this new project or demo… Well, take a break, go have a walk, do some physical activity, or why not a nap. And then, when you get back on the drawing board… err… keyboard, you’ll have a fresher view on the problem at hand. I like running, so when I know I won’t be productive, sometimes I take an hour off, and go outside for a run (or treadmill or elliptical bike when in lockdown).

There are always pros and cons to anything. Looking at Valhalla, Loom, Amber and Panama, those projects are really important for the long term viability of the platform. Those are key undergoing evolutions of the language that will bring several benefits. Lightweight threads with Loom is similar to what some other languages supported like Go’s goroutines, for example, and this will open up interesting evolutions of networking libraries, for example. Valhalla and its value objects will be great for reducing that dichotomy of primitive and object types. I’m also particularly interested in Amber for the new syntax constructs. In particular, I’m a fan of pattern matching and the new switch expression. Coming from my Apache Groovy background, I’ve enjoyed a more powerful switch expression, and had been considering ways to add pattern matching in the language, but I think it’s worth waiting for the outcome of Amber and see how it can be adapted and/or adopted into Groovy. Anyhow, it’ll make the Java language more powerful and expressive!

Java is catching up! And it’s releasing at a much faster pace! It’s nice to see the language evolve in various directions, and also take some inspiration from the alternative JVM languages. Java is still a bit verbose, even if for good reasons and a strong legacy, it sometimes a bit cumbersome to write some complex Java code without the simplicity or malleable syntax of those alternative languages. For example, I’d rather write business-rules or Domain-Specific Language like Groovy than Java.

There’s an interesting crop of new frameworks out there that take advantage of things like native image, to create lightweight and fast-starting Java apps. My favorite new framework is clearly Micronaut (I’m biased, I’m part of its technology advisory board). What makes it apart from the competition is its great polyglot support, but even more important, it’s how it takes advantage of ahead of time compilation techniques to do lots of clever tricks that used to be done slowly at runtime via reflection, like bean wiring, or other aspect oriented programming aspects. It’s very innovative in this area, and brings down memory consumption and greatly reduces startup time.

There are ways to use a polyglot approach with Maven, and thus avoid XML, but Gradle comes with a nice Groovy DSL for defining its builds, I favor Gradle over Maven. Gradle is a very advanced build tool, not necessarily easy to master, but it shines both for simple and complex builds.

Even with clear package separations, without modules we can’t really enforce users to not use classes that are part of packages they’re not supposed to use. You could go with things like OSGi, or similar frameworks, but it adds a layer of complexity. So at some point, modules might perhaps be unavoidable for such clean separation. However, I must confess that I still haven’t used modules myself, and try to stay away from them. But the next green-field big project or framework I might be working on, I think I’ll try to dive deeper and get started from the get go with modules to avoid the headaches later down the road.

I don’t even need to be forced, I’d gladly speak about running Micronaut-based applications on Google Cloud Platform! In particular on serverless solutions like Cloud Run, App Engine or Cloud Functions.

Groovy never really tried to be a “better Java”, but more of a more agile companion. That said, Groovy continued its effort to be as compatible (syntax-wise) with the Java language, as well as continued innovating with its syntax or features. But there’s a balance to keep, and we shouldn’t duplicate efforts: for example, Java is adding pattern matching, Groovy should just wait and not implement its own variation, but implement one that is compatible with Java’s. But it can certainly add a Groovy twist to such integration, by continuing to take advantage of things like the “Groovy truth”, like its great closure syntax, etc.

Join Guillaume's session on the 25th of June at 10.00 a.m. CEST!

Take care and have a lovely day!