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.
What new countries have you “visited” thanks to the online format?
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!
If there are Java Champions, perhaps we should add Java Princesses and Java Dragons, too?
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!!!
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?
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!
Do you have any personal habits around development or self-care that you would like to share with our audience?
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).
Obviously, projects Valhalla, Loom and Amber have received a lot of buzzes, but there is a healthy level of skepticism about the projects. Do you have any thoughts you’d like to share?
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!
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.
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 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?
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.
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?!
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.
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?
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.
As a Google Developer Advocate, if you were forced to talk about only one Java thing, what would it be?
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.
With all the recent changes in Java, do you think Groovy should remain “better Java” or continue to evolve on its own?
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!
Register to attend
Our Website
Take care and have a lovely day!
Top comments (0)