Technology Advisory Board Meeting Minutes - March 25, 2022

Board Members In Attendance

• Jason Schindler – Object Computing Inc., Partner and Groovy, Grails, and Micronaut Team Manager
• Graeme Rocher – Micronaut Foundation, co-founder and Director; Oracle, Architect
• James Kleeh – Object Computing,Inc., Micronaut Development Lead
• Neal Ford – ThoughtWorks, Director, Cloud Architect
• Venkat Subramaniam – Agile Developer Inc., Founder
• Yuriy Artamonov – JetBrains, Microservices Fellow
• Mark Sailes – Amazon, Specialist Solution Architect for Serverless at AWS Cloud

Board Members Not In Attendance

• Zhamak Dehghani – ThoughtWorks, Principal Consultant
• Ken Sipe – Edward Jones, Department Leader – Application and Technology Architecture
• Guillaume LaForge – Google, Developer Advocate for Google Cloud Platform
• Bruno Borges – Microsoft, Principal Product Manager for Java

Others In Attendance

• Jen Wiese – Community Engagement Manager

Meeting led by

• Jen Wiese

Agenda

• Welcome
• Community Update
• Sponsorship Update
• Product Strategy
• Micronaut Framework Update
• Tech Talk
• Open Discussion
• Close Meeting

Community Update

• Goals for 2022
  • Training events
  • Webinars
  • Collaborative publications or events
  • Meetups
  • Microcasts
  • Podcasts
  • Micronaut Live Events
• Progress in Q1
  • Micronaut Podcasts
    • Micronaut Security
    • Agorapulse Micronaut Libraries*
    • Micronaut Serialization
    • Micronaut Features from a Grails Application*
    • Micronaut Email
    • Caribou*
  • Training Events
    • Building Secure Applications with the Micronaut Framework
    • Micronaut Testing Tips & Tricks
    • Micronaut Essentials
    • Jumpstart Your Micronaut Applications with AWS Lambda
  • Q1 Webinars
    • Micronaut for (P)IoT Projects
  • Q1 Meetups
    • Manchester Java Community Meetup: Micronaut Presentation
  • Q1 Conference Presentations
    • Oracle Developer Live
    • JavaDay Lviv

Sponsorship Update

• Tools and Infrastructure Partners
  • Gradle
  • JetBrains
• Ideas for others
  • 1Password
  • Sonar
  • YourKit
• Corporate Sponsorships
  • OCI
  • Safari.Net
  • Vizor Games
  • Ideas for others …
• Community Sponsorships
  • Ongoing

Product Strategy (Performant and Collaborative)

• Continued focus on Framework performance
• Performance test suite
• Focus on collaborations with other organizations>
• OSS partnerships
• Community-driven integrations
• Community-authored guides
• Technology & Infrastructure Partners

Micronaut Framework Update

• Micronaut 3.4.0
  • Micronaut Data MongoDB
  • Micronaut Serialization
  • Micronaut AOT

Tech Talk (March 2022)

• Release Cadence
  • 6 weeks currently
  • Suggesting a move to a more flexible release schedule
  • Release when ready (need more time to test)
  • Development cycle separate from release cycle
  • Offset development cycle and extend QA cycle
  • Reduce scope and release more often
  • Develop for a feature not a release (mindset)
• Micronaut 4
  • Baseline at JDK11 or JDK17

Open Discussion

• Release Cadence Discussion
  • Graeme: There is a 6-week cadence that I believe is causing some amount of rushing, and that rushing is commonly leading to regressions.
  • Graeme: There has been a proposal to switch to a less stringent release cycle that would be more about releasing when we are ready.
  • Graeme: Sergio feels we should keep the 6-week cadence because it allows users to get features into their applications sooner.
  • Venkat: I want to make an observation about what Oracle did for the Java release. The way I see it, they separated the development cycle from the release cycle. What they did was say you develop at the speed you want to develop, but there is a release going every so often, and the things that are ready are going to be released. I think it has been really effective.
  • Graeme: I think it works well for the 6 months because they have time. With 6 weeks, what we can get to is that there hasn’t been enough time for a good new feature, and it ends up looking like a patch release. I’m not saying that we should release on a schedule; I’m saying that the schedule is too short.
  • Neal: I concur with what Venkat said, but part of the reason they did that approach is that their testing is very complicated. The problem you run into with a long release cycle like that is there is tension around getting something in for the next release cycle. One suggestion is to offset your QA and release cycle by a few weeks. I’m in favor of reducing scope and releasing more frequently.
  • Venkat: I think it has an impact on the way we think as well. If I’m a developer on a team, I should be focused on developing a feature instead of developing a release. The key should be to develop a good product instead of developing a good release. If what we value is the release, I’m going to put effort towards releasing it. I don’t think developers are standing on the line and asking for a release when it is the opposite and they are usually behind.
  • Jason: Venkat I think you have hit on something critical here. We do tend to emphasize the release and even have a requirement that the blog post for a release needs to be ready to publish before a release can be made. Not to say that we shouldn’t continue that, but an emphasis on the features and decoupling that from the release process clarifies this for me.

• JDK version for Micronaut 4 Discussion
  • Graeme: We are at a point where we need to decide if Micronaut 4 should be based on JDK 11 or 17. My feeling is that people that are struggling to update to JDK 17 are also struggling to update to JDK 11. It seems that either way, we will have users that stay on Micronaut 3 for a time due to compatibility with JDK 8. Either way, we will need to support Micronaut 3 for a long time.
  • Graeme: My gut feeling is that we should move to JDK 17 because it provides value to the API of Micronaut with things like sealed classes, where JDK 11 doesn’t provide a lot of utility to the framework itself.
  • Graeme: Going to JDK 11 is also an option, and maybe not as many people have moved to 17 that have moved to 11.
  • Graeme: The other thing is the competition. Spring 6 is moving to JDK 17. Quarkus seems to be supporting JDK 11 for the foreseeable future.
  • Graeme: Another thing is third-party libraries that may choose to baseline to JDK 17. I think when Spring does it, a lot of other libraries will also do it.
  • Venkat: Is there a compelling reason that we should be using some of the features of JDK 17 in the implementation of Micronaut itself?
  • Graeme: Records are definitely something that are interesting because we can model certain parts of Micronaut Data on common things. I think sealed classes have more potential, in that you can finally define how your interfaces are extended.
  • Graeme: There are a lot of bugs that are fixed in JDK 17 that we have hacks in place for in our processing.
  • Graeme: Then of course there is our CI pipelines, where we will have to continue to maintain branches for each release of Micronaut the re-baselines.
  • Venkat: It might be useful to do a poll of users to see who is going to be on JDK 17. I think many of my clients don’t know when they will be on JDK 17.
  • James: The users don’t really care about removing cruft from the framework. I also think that 8 should be an option, just to see what the response is.
  • Graeme: It may be that we delay this conversation for another year.
  • James: It is definitely a problem to support 8 with GraalVM not supporting 8, but it could be the case that if a whole bunch of people say to stay on Java 8 in that poll, it will illustrate the cost of moving away from 8 as well.
  • Jen: We can put together a survey and send it out in an email for subscribers as well as Twitter and LinkedIn, and that just might be great feedback as well. We’ve seen just from getting responses from things that we don’t get as much of that from social media. I can do a real form that people can fill out.