Christmas is coming soon, and you’ll soon be at the family dinner again, even if this year it will be a Teams meeting as we’re doing everything virtually.
As every year, it will be time for you to impress the other Java developers in your family with your mastery of cool new frameworks and tools.
So here are 3 hot tricks coming from JHipster, that you can apply on any Java project (JHipster simply generates files, you can totally copy/paste them on any Java project).
Tip 1: Prettier for Java
Prettier is a code formatter that has taken the world by storm. Every modern JavaScript or TypeScript project uses it, and it’s now available for Java developers!
This means you will have perfectly formatted Java projects, automatically. And that’s definitely impressive.
Prettier for Java is the official Java version of Prettier, and it has been developed by the JHipster organization, as part of our mission to improve all Java projects in the world.
This isn’t an ordinary code formatter that senior Java people will already know about:
- Prettier for Java contains in fact 2 projects: one to generate a Concrete Syntax Tree (CST) of your code, and another one to print everything perfectly. So Prettier “understands” your code, a bit like your IDE does, in order to produce the most perfect output: this is far more advanced and powerful than traditional code formatters, and this is the main reason of its success.
- Following a long JHipster tradition, Prettier for Java is a JavaScript that tools that writes Java code. It sounds a bit crazy (and it is!), but it has the added value of not starting a JVM each time it runs.
- As Prettier is widely-used in the front-end world, all major IDEs already support it.
For installation instructions, head over to https://github.com/jhipster/prettier-java, and our recommended trick in the JHipster team is to install Prettier as a Git hook, so it runs in the background when you commit your code.
As a result just doing “git push” will send perfect Java code to your repository, even if you didn’t write it properly.
Tip 2 : Testcontainers
All projects generated with JHipster come with a number of pre-configured Docker Compose files. Here are the ones from our sample projects: https://github.com/jhipster/jhipster-sample-app/tree/main/src/main/docker.
Most of those files can’t be used in production: for example, we wouldn’t recommend using the MySQL file to run a database in production, as you’ll have trouble to maintain it. For example, you need good backup and update policies, which are not provided here.
But those files allow you to easily run a production-like infrastructure on your laptop or on your CI/CD pipelines. We have found them to be hugely helpful to test our code and to automate it.
So recently we decided to go even further thanks to the magic of Testcontainers: https://www.testcontainers.org/
Testcontainers provide a very easy way to run Docker containers within your JUnit tests: usually, those containers will run a data store like PostgreSQL, MongoDB or Elasticsearch. Those provide some incredible benefits:
- You can run integration tests within your IDE, even without knowing anything about Docker or the data store you are using. For example, a developer who doesn’t know how to install MongoDB can still very easily test code that uses MongoDB, and correct issues.
- You can run complex integration tests within your CI/CD toolchain, including tests with different data stores. For example, the JHipster build is probably one of the most complex GitHub Action available: here is the configuration we use to test our default builds (using the Angular frontend) against several databases, https://github.com/jhipster/generator-jhipster/blob/main/.github/workflows/angular.yml
On JHipster, as we don’t want to mix unit tests and integration tests, and also as we don’t want new users to have an error message when they run their tests on the first time, we have created a specific “testcontainers” profile to run Testcontainers.
As a result, you need to start up your Docker daemon and run “mvn verify -Dspring.profiles.active=testcontainers” to use that cool feature.
Tip 3: “git push” to deploy to the cloud
As a developer, no one wants to know the specific commands needed to deploy a Java project to a cloud provider, or to spend time deploying a Jar file manually.
In the JHipster community we have different alternatives, but usually our favorite solution is to have something similar to this:
- Use the cloud provider’s CLI to generate the necessary infrastructure.
- Generate a GitHub Action that is able to build the project.
- Set up the GitHub Action so that each time a developer pushes some code, the final artefact is deployed to the cloud infrastructure.
For instance, this is what we do in our Azure sub-generator, documented here: https://www.jhipster.tech/azure/.
If you don’t use JHipster, you can copy/paste our templates from https://github.com/jhipster/generator-jhipster/blob/main/generators/azure-app-service/templates/github/workflows/azure-app-service.yml.ejs (we promise, they are easy to read!). And don’t miss that line where we add a cache for Maven archetypes, or your builds will last forever!
Once this is done, you’ll be able to modify the Git trigger so that each time a developer pushes some code to a specific branch, the application will be built and deployed.
steinhauer.software