Enterprise applications are usually not very innovative. They stand out against the background of other developments in many ways:
- Functionality is quite broad but similar in most applications.
- They take a long time to develop and even longer to use because they are hard to replace.
- Generally, the number of users varies.
- Have medium hardware and code optimization requirements.
- Have high requirements for reliability, data integrity, and protection, auditing, and access rights verification.
- Must integrate with existing (sometimes outdated) systems and be easy to expand.
To implement the planned extensive functionality in a reasonable time (from six months to two years), and in general to meet these requirements, custom enterprise software development is conducted by a large team – ten or more specialists.
Maven or Gradle
Maven described the structure of the project and its folders, and the entire lifecycle, and provided a library repository. Instead of manually downloading the right libraries, all you had to do was specify what to get and what version. Maven downloaded not only the specified dependency, but also everything it needed to run it. It could also run plugins as regular dependencies and build them into the project lifecycle.
Maven has become the de-facto standard and is used in almost every Java project. And it’s very convenient – you always know what parts it consists of and how it’s built.
Gradle came about because Maven limits programmers. It uses a similar folder structure, the same dependency mechanisms, and many of the same ideas, adding the ability to write complete code. Many people put shorter constructs on the plus side of Gradle. The problem with Gradle is that it’s not declarative scripts in a special language, but real code that has access to the entire project structure and build elements through the Gradle API.
But you can use Maven. If you need something custom, you can always write a plugin that’s nicely connected and configured via explicit parameters, hiding complicated magic behind its façade and not cluttering the core scripts with it.
Despite its verbose nature, Maven is easier to learn, understand, use, and maintain. For enterprise applications that take a long time to develop and even longer to maintain by a large team with varying levels of expertise, this is more important than Gradle’s ability to do anything (which isn’t necessary at all).
Java or something else?
Java hasn’t evolved for long enough. There was an understandable desire for more user-friendly constructs, especially for those familiar with other languages. But the period of stagnation is in the past. A lot of interesting things have emerged in Java. Libraries like Lombok, MapStruct, and Spring AOP have made enterprise application development more convenient. And if you also use ERP https://nolt-technologies.com/services/erp, you can take your business to the next level.
Kotlin has been in development for 5 years and it came out a year after Java 8. It has certain advantages. But for enterprise applications these don’t make much difference.
Kotlin is a good option for Android. But for modern enterprise applications, there is no need to use Kotlin. One of the perks of Kotlin is the ability to create DSLs. So in an application where you can choose a different technology stack for each service, there’s nothing stopping you from implementing a piece of business logic with Kotlin-based DSL.
Spring (and Spring Boot) is a very functional, mature, and really handy framework, which really speeds up enterprise application development and makes their architecture better. Together with Spring, it is convenient to use other libraries – Liquibase, Lombok, MapStruct, etc.
The important thing is that the solutions must be practical. Striving too hard for perfection leads to worse results than a not-so-pretty but more practical solution.
