From my experience, enterprise apps are generally complex because they are a combination of:
- environment: integration of a large amount of services - and a good amount of them are legacy and idiosyncratic
- use case: enterprise app are at the intersection of real life and the virtual world: the rules are messy, illogical and have a baggage of 20/30+ years. Thus they cannot be changed at all. This is IMO the main difference between a "pure" greenfield startup kind of project and the enterprise one.
- add another layer of burocracy and complex environment to navigate
And with that you got the enterprise app world :).
In the end whatever framework is chosen, the most important property is the availability of common language/patterns.
You may notice that in the linked article, only the artifact id has been spoofed. In maven you need to declare both groupId and artifactId for your dependency (and a fixed version, a range is generally considered a bad practice).
To be noted, it makes this kind of attack more difficult, but not impossibile.
Especially the mix public/private artifacts. I guess it will force a lot of companies to at least lock their groupId on maven central, if they never bothered to do so.
Hi, one of the devs here. I would like to clarify that this project has been developed as a side-project, it's not (at least, during that timeframe) our main work.
So don't take the time to develop a feature as a 100% full time work :)
That's why it's called a modular jar. There is also this "jmod" file described as:
"For the purpose of modularizing the Java SE Platform’s reference implementation, the JDK, we will introduce a new artifact format that goes beyond JAR files to accommodate native code, configuration files, and other kinds of data that do not fit naturally, if at all, into JAR files. This format leverages another advantage of expressing module declarations in source files and compiling them into class files, namely that class files are independent of any particular artifact format. Whether this new format, provisionally named “JMOD,” should be standardized is an open question."
"The internal files rt.jar, tools.jar, and dt.jar have been removed. The content of these files is now stored in a more efficient format in implementation-private files in the lib directory."
>Except they don't mention at all how a module system should lead to faster boot times.
They will switch from the basic jar (zip) format to a more optimized one. Additionally, with a modularized jre, it will load less modules (who use corba?). I'm quite sure there are additional reasons, but it's the 2 that I remember.