In our new Java Monthly edition, we’d like to introduce you to Deepu K Sasidharan. He was kind enough to share his experience on 12 more Java-related questions.
Deepu K Sasidharan is a Software Engineer by passion and profession. He is a Java Champion working as a Senior Developer Advocate at Okta. He is the co-lead of JHipster and the creator of KDash and JDL Studio. He is a polyglot programmer working with Java, Rust, JavaScript, Go, and so on. He is also a cloud technology advocate and an open-source software aficionado. He has authored books on Full-stack development and frequently writes about Java, Rust, Go, JavaScript, DevOps, Kubernetes, Linux, and so on, on his blog.
Dreamix: As one of the leaders of the widely used JHipster project, can you tell us a little bit about the future of JHipster? What are the upcoming developments that you are most excited about?
Deepu K Sasidharan: JHipster has been a project close to my heart for many years now. The project has grown dramatically in popularity, contributors, community, and codebase. While most of it is good news, the growth in the codebase and the increased number of supported options have made maintenance a challenging task for the core team. So the next phase of JHipster (version 8) will focus on shedding some weight and making the codebase easier to maintain and customize. For this effort, there are two directions we are taking with core team members contributing to the approach they think is more valuable in the long run. One direction is refactoring the JHipster generator’s core codebase, led by Marcelo Shima, to make it easy to maintain and build blueprints (JHipster’s extension mechanism). The second direction is JHipster Lite, led by Pascal Grimaud, which focuses on building a new Java-based scaffolder. This will be hosted as a web app and work similarly to start.spring.io in providing minimal and incremental pieces of code that you can use to build applications.
Dreamix: It is clear that the direction for the JHipster is mainly guided by the community but if it was up to you, should JHipster evolve to cover more and more different use cases (different technologies, different functionality) or should it have more focus and value simplicity and minimalism. Should it be optimized for covering all the needs of bigger and more complex projects (where it can save more time) or should it be optimized as the best tool to quickly start a smaller and simpler project (where it will be used more often).
Deepu K Sasidharan: This is an excellent question, and your observation is on the point that today it is driven by community and contributor consent. If it was up to just me, I’ll focus on a few generic use cases and do it very well with everything driven by JDL (JHipster Domain Language) configurations with a solid blueprint system for extensions.
Dreamix: When starting a new project a team of developers is faced with the decision if they should use a code generator like JHipster or assemble everything manually. In the first case they will quickly have a lot of things generated and everything working really well together but with the risk of not fully understanding everything that is happening in the code. On the other hand, with manually doing everything it will be slower initially, may lack some of the “nice to have” aspects, and may even not be as well executed, but everyone will understand every part of the project. When is one better than the other and can something be done to make this decision easier?
Deepu K Sasidharan: This differentiation needs another aspect to be more relevant, IMO. There are two major types of projects from my experience. One is greenfield projects built for custom use cases, typical in traditional enterprises and consulting companies. They don’t evolve a lot and are driven solely by a group of users from a company or a domain. These projects typically enter a maintenance phase after initial development, and the teams might keep changing constantly. The second kind of project are products built and evolved over the years by the same team with some members rotating and having a large user base. So IMO, for the first kind of project, choosing something like JHipster would be a no-brainer as the advantages will heavily outweigh the disadvantages since the churn in teams generally makes a custom-built or JHipster scaffolded project look the same to a new team member. In the second case, of course, the team will have a better grasp of things if everything is built from scratch, but I would argue that it is a smarter choice to use a scaffolding tool to save a lot of time so that you can use some of that time to learn and understand what is scaffolded.
Dreamix: With time projects evolve and move away from the initial code generated with JHipster but at the same time new versions of JHipster are constantly released, containing important improvements and library updates. At what point do you advise people to stop using the automated upgrade process (JHipster upgrade sub-generator ) and update libraries and code manually instead?
Deepu K Sasidharan: It will depend on the development practices followed by the team. If the generated project didn’t undergo heavy customizations, it might be possible to keep using the upgrade sub-generator and use Git to solve conflicts. When I used to work for a consultancy, I built and maintained some projects using JHipster; these apps had many customizations, so my favorite approach for upgrading was as follows. I had a second workspace with the same JHipster configuration of the app. I just regenerated this project with the new JHipster version when I wanted to upgrade. I then used a tool like Beyond Compare to compare this workspace with the project workspace and carefully cherry-pick the changes that made sense. Of course, this was manual and time-consuming but still way faster than trying and doing all those upgrades manually in the project. Usually, this process took anywhere between an hour to a day, depending on the number of changes and conflicts, whereas doing it fully manual would have taken a few days to weeks.
Dreamix: As author of the “blueprints” functionality in JHipster, what is your advice about when companies should use it? Should it be mainly used by technology vendors to allow people to incorporate their technologies in the JHipster ecosystem or is it also appropriate for software companies to develop blueprints just for internal use so they can tweak the generated code to fit better with their preferences.
Deepu K Sasidharan: When I created the blueprint mechanism, my goal was to support both use cases as they are technically the same and can be achieved using blueprints. I had the second use case at the company I worked at that time, which prompted me to build the system. But I also saw blueprints as a way for the JHipster community to grow, which it did by successfully having spin-off blueprints for Kotlin, .NET, Node.js, and so on (https://www.jhipster.tech/modules/official-blueprints/) which expanded the JHipster community beyond Java. Today blueprints are the ideal way to extend JHipster to add something new for the community or to customize some parts of the templates for an internal use case.
Dreamix: As a polyglot developer you are constantly exposed to many different programming languages and can assess their strengths and weaknesses. Aside from the obvious case with Javascript/Typescript for web applications, what are some other cases where different languages can be successfully combined with Java to achieve synergies and get better results than just using the languages separately?
Deepu K Sasidharan: I’m a huge proponent of using the right tools for the right job, and I believe everyone should be open to picking the best language for the task at hand without considering their biases. For example, I would use Rust or Go any day to build CLIs, system tools, or Kubernetes tooling because they have a better ecosystem, and the results are more efficient. But if I have to create a reliable API server, I will build that in Java since the ecosystem is far better and is battle-tested. Similarly, if there is a use case in the API server I built with Java, where absolute performance matters but not the response time, I would offload that process to a job written in Rust. So yes, I firmly believe that inter usage of languages can be great for Java. Given the maturity and reliability of the Java ecosystem, and not to mention the long-term optimizations provided by JVM, adding more languages to the mix can make the argument for Java stronger, IMO. With great leaps being made by GraalVM in its polyglot capabilities and with project Panama becoming closer and closer to GA, it is a great time to normalize foreign functions (FFI). This will make Java viable in machine learning, advanced arithmetics, and CPU/GPU offloading use cases.
Dreamix: What is the upcoming java feature that you are most excited about and why?
Deepu K Sasidharan: Definitely project Loom and project Panama. I have been a fan of goroutines in Go and getting something similar in Java in the form of Virtual Threads is exciting. I wrote about this in detail here (https://developer.okta.com/blog/2022/08/26/state-of-java-project-loom). Next would be the Foreign Function & Memory API since it will open a lot of doors for Java and will expand the possibilities in Java. As a polyglot developer, that is quite exciting for me. I have written in detail about this (https://developer.okta.com/blog/2022/04/08/state-of-ffi-java)
Dreamix: Can you name a feature from another language that you think will be a good fit for Java in the future but is not currently planned for inclusion.
Deepu K Sasidharan: There are many such features TBH. But if I have to pick, then zero-cost abstractions would be the feature I miss the most. (https://deepu.tech/my-second-impression-of-rust/#zero-cost-abstractions)
Dreamix: In the modern versions of Java we already have most of the needed features to allow functional style programming in many cases. Do you think this style should be enforced (or strongly preferred) in new projects or should we sometimes stick to a more traditional Java way of doing things, and if so – when? Do you think these features and the tooling around them are mature enough and the benefits are significant enough to justify enforcing full transition?
Deepu K Sasidharan: This ties into my previous answer. While Java has enough pieces in place for functional programming, it won’t be appropriate for all use cases. Without zero-cost abstractions, you would still have to rely on imperative code whenever you need to squeeze out maximum performance. So I recommend using functional style where appropriate and imperative/OOP when necessary.
Dreamix: In one of your blog posts you talked about “developer experience” (as analogous to a “user experience” but from the point of view of a developer using a piece of technology). Can you give some examples of technologies that have done this really well?
Deepu K Sasidharan: As I mentioned in that post (https://deepu.tech/what-is-developer-experience-and-why-care/) as a Developer, I expect a good experience from the tools I use, which include languages, frameworks, libraries, IDEs, and so on. And like user experience, Developer experience (DX) will be different for different developers. The following technologies have the best DX in each category based on my personal preference.
1. Language & Tooling: Rust + CargĐľ
2. Library ecosystem: Java and Rust
3. Framework: Spring framework
4. IDE/Editor: VSCode
5. Development environment: Linux and specifically Fedora
6. Cloud platform: Google Cloud Platform
7. Tools: Docker, Terraform
Dreamix: How do you update yourself about the latest trends in Java?
Deepu K Sasidharan: As a polyglot developer, there are many languages and frameworks I follow and keep tabs on. I use Twitter and newsletters to keep up to date with news, and whenever I see a feature that looks interesting, I learn and then write about it as I believe public writing is one of the best ways to learn. The same is true for Java, and Dreamix is one of the sources for sure.
Dreamix: Can you recommend a favorite book about programming? What about a favorite book in general?
Deepu K Sasidharan: This might come as a surprise from someone who has authored programming books. Still, I’m not a fan of reading technical books as I’m more of a hands-on learner and prefer short tutorials to learn than full-blown books, but that probably is because I’m also a generalist. So I don’t think I have read enough technical books to recommend one. For books in general, I like most of the books written by Richard Dawkins and will recommend “The Greatest Show on Earth” if I have to recommend just one.
Is there anything else you would like to ask Deepu K Sasidharan? What is your opinion on the questions asked? Who would you like to see featured next? Let’s give back to the Java community together!
