The previous module ended with a promise: "You have written miniature versions of almost all of them with your own hands. Now you are going to use the real ones."

This lesson is the bridge. Before writing your first Spring annotation or your first Hibernate entity, you need to understand what exactly a framework is, how it differs from a library, what it gives you and what it takes away, and —above all— how it works on the inside, because you already know the answer to that last question: annotations, reflection, dynamic proxies and code generation. Exactly what you built in module 10.

This matters for a very practical reason. The difference between a developer who uses Spring and one who understands Spring is not how many annotations they know by heart: it is that when something breaks —and it will— the first one searches a forum and the second one reasons about what the container is doing. When you see that a call to a @Transactional method from another method of the same class opens no transaction, you will know why: because the dynamic proxy you wrote in 10-03 has exactly that same hole, and you saw it with your own eyes.

There is also a professional decision that nobody teaches you and that you will take dozens of times in your career: whether or not to add a dependency. It is a decision with security, maintenance and weight consequences. This lesson gives you real criteria for taking it.

By the end you will be able to tell a library from a framework and explain inversion of control with an example you wrote yourself, you will have a map of the Java ecosystem by category, you will know how a dependency is evaluated before it goes into your pom.xml, you will understand what Maven Central is and what the groupId:artifactId:version coordinates mean, and you will know about software supply chain risk through a real case that paralysed the industry for weeks.

1. The starting point: BiblioTech, hand-made
2. Library versus framework: who calls whom
3. Inversion of control, explained with your own SimpleContainer
4. What a framework gives you
5. What a framework costs you
6. How the magic holds up: the four mechanisms
7. The map: what you wrote by hand versus what the real framework does
8. A map of the Java ecosystem by category
9. How a dependency is chosen
10. The prior question: do I really need it?
11. Maven Central and the coordinates
12. Semantic versioning
13. The cost of supply chain security
14. Log4Shell: what actually happened
15. Auditing dependencies in practice
16. Which framework to learn first
17. Why this course chooses Spring Boot
18. The plan for module 11
19. Common Mistakes and Tips
20. Exercises

Before looking ahead, take one more look at what you have. BiblioTech, at the end of module 10, is a respectable project: a sealed domain, generic repositories, streams, java.time, virtual threads, a home-made dependency injection container and three dynamic proxies.

And it has six declared debts:

Every one of those rows is a lesson in this module. But notice something: none of those debts is business logic. None of them has anything to do with loans, fines, reservations or catalogues. They are all plumbing: things every application needs and no application wants to write.

That observation is, literally, the definition of the problem frameworks solve.

The distinction is usually explained badly. It is not a question of size or complexity. There are enormous libraries and tiny frameworks. The difference is the direction of the calls.

• A library is code that you call. You control the flow: you decide when, where and with which arguments. java.util.Collections, Jackson or Apache Commons are libraries: you call Collections.sort(list) whenever it suits you.
• A framework is code that calls you. The framework controls the flow: it defines the structure of the application, it starts up, and at certain points it invokes your code. You fill in the gaps.

This inversion has a classic name, the Hollywood Principle: "Don't call us, we'll call you."

A concrete example you already know, from 09-06. When you wrote MetadataClient with HttpClient:

You control everything. HttpClient is a library.

And now, a framework example you will see in 11-04:

Where is the main? Who calls fineForFiveDaysIsFiveEuros()? Not you. JUnit calls it. All you did was write a method and put a label on it. JUnit scans your classes, finds the methods annotated with @Test, creates one instance per method and invokes them. That is a framework.

Compare the two models:

An honest nuance: the boundary is not always sharp. Spring is a framework, but RestTemplate inside Spring is a library. Hibernate is a framework when it manages the lifecycle of your entities, and a library when you call entityManager.find(...). The useful thing is not to classify, but to ask at each point: who controls the flow here?

Inversion of control (IoC) is the general principle: handing control of the flow over to another component. Dependency injection (DI) is the concrete form of IoC you will use most: instead of an object creating its own dependencies, they are handed to it ready-made.

You wrote this yourself in 10-03. Before SimpleContainer, LoanManager did this:

The problems with that code, all of them real:

1. It cannot be tested. To test a fine calculation you need a CSV file on disk and an SMTP server.
2. You cannot change implementation. If tomorrow the store becomes a database, you have to edit LoanManager.
3. It cannot be configured per environment. The development SMTP host and the production one are different, and they are hard-coded.
4. The clock is the system's. That Clock.systemDefaultZone() makes it impossible to test a due date without waiting 15 days. Precisely what 10-05 set out to avoid.

After SimpleContainer:

LoanManager no longer knows where its collaborators come from. It only knows what it needs. Somebody on the outside —the container— resolves the dependency graph, builds everything in the right order and hands it the pieces.

Visually, the change is this:

Your SimpleContainer did this: it scanned the classes annotated with @Component, looked at their constructors through reflection, recursively resolved each parameter, detected cycles and cached the singletons. One hundred and fifty lines.

Spring's ApplicationContext does exactly the same. And a few things more:

None of those extra rows is business logic. They are all things you would need to write if your application grew. That is what you are buying.

Four concrete things, in order of real importance.

1. Non-differentiating code, already solved. There is a useful distinction between differentiating code (the code that solves the problem your company exists for: in BiblioTech, the rules for loans, fines and reservations) and plumbing code (what any application needs: starting up, configuring itself, talking to a database, serving HTTP, recording traces). Plumbing code adds value for nobody and yet it eats most of your time when you write it yourself. A framework gives you that time back.

2. Shared conventions. If you hire a Java developer with Spring experience, they understand your project structure in an afternoon. If BiblioTech used your home-made SimpleContainer, it would take them a week to understand a container that exists only in your company and for which there is no documentation, no courses and no forum answers. Conventions are an economic asset.

3. Ecosystem. When you choose Spring, you are not just choosing a container: you are choosing Spring Data (persistence), Spring Security (authentication), Spring Cloud (distributed systems), Actuator (observability) and hundreds of integrations that already work together. The integration is already done and tested, and that is worth more than any individual feature.

4. Maintained security. When a vulnerability appears in HTTP request handling, the Spring team publishes a patch and you bump a version. If that logic is yours, you discover the vulnerability when somebody exploits it. This point tends to be underrated and it is probably the most important one in production.

A framework is not free. Four costs, also real.

1. Learning curve. Spring has more than twenty years of accumulated surface. Becoming productive takes weeks; becoming competent, months. And a good part of that learning does not transfer: learning @Transactional teaches you nothing about databases, it teaches you about Spring.

2. Coupling. A framework permeates the architecture. Migrating an application from Spring to Quarkus is not swapping a dependency: it is rewriting the configuration layer, the start-up layer, the test layer and probably part of the domain. That is why it is worth keeping the domain free of framework annotations wherever possible — an idea developed in 12-02.

3. Magic that is hard to debug. When an @Autowired does not inject, or a transaction does not roll back, or an entity saves itself without you calling save, the cause is in code you did not write, invoked by reflection from a point that does not appear in your stack trace. This is exactly why module 10 came before this one: if you know how the magic works, you can debug it.

4. Weight. An executable Spring Boot jar with web and JPA weighs around 40-50 MB and starts in 1-3 seconds. For a long-lived service that is irrelevant. For a serverless function that starts on every request or a CLI that must respond in 50 ms, it is disqualifying — and that is where Quarkus, Micronaut or the GraalVM native compilation mentioned in 10-07 come in.

In summary:

The professional conclusion is neither "frameworks are good" nor "they are bad": it is that the decision depends on the context, and that anyone who does not understand what lies underneath cannot take it.

This is where module 10 pays off in full. Everything a Java framework does "by magic" rests on four mechanisms, and you know all four.

Annotations are metadata: labels that do nothing on their own. @Service starts nothing. @Entity creates no table. @Test runs nothing. They are inert marks that somebody has to read.

You learned that by building @CsvField and @Auditable. And you learned the indispensable condition:

Every framework annotation that is read at runtime carries @Retention(RUNTIME). Open the source of Spring's @Service or Jakarta Persistence's @Entity: it is there.

Somebody has to read the labels. That somebody uses reflection: Class.forName, getDeclaredFields, isAnnotationPresent, getDeclaredConstructor().newInstance(), invoke, setAccessible(true).

Your AnnotatedExporter walked the fields of any object looking for @CsvField. Hibernate walks the fields of any entity looking for @Column. It is the same loop.

When the framework needs to add behaviour around your method without touching your code —transactions, security, caching, retries, metrics— it does not modify your class: it wraps it. You wrote three:

When you see @Transactional in 11-02, you will see nothing new: you will see that same InvocationHandler with begin transaction before and commit or roll back after. And you will see the same hole too: if the target calls itself internally, the call does not go through the proxy and the aspect is not applied. That detail is the cause of a huge percentage of the world's "my @Transactional doesn't work" reports.

Technical note: the JDK proxies you wrote only work over interfaces. When the class implements none, Spring uses CGLIB, which generates a subclass of your class at runtime and overrides its methods. Hence a practical consequence: a final class or method cannot be proxied with CGLIB, and that is why sometimes your @Transactional on a final method does absolutely nothing.

There are two possible moments.

• At compile time, through an annotation processor (javax.annotation.processing, seen in 10-02). That is what Lombok does: there is no runtime magic, the .class already contains the getters. Also MapStruct and Micronaut.
• At runtime, generating bytecode on the fly with ASM, ByteBuddy or CGLIB. That is what Spring, Hibernate and Mockito do.

Each option has its consequences:

The current trend, precisely because of start-up cost and compatibility with GraalVM native compilation, is to move work from runtime to compile time. Quarkus and Micronaut were born with that idea, and Spring 6 has partly adopted it with AOT.

This table is module 10 summarised and read from module 11. It is probably the most important table in this lesson.

Read it in both directions. Left to right, it is your road map. Right to left, it is the answer to the question "what is Spring doing here?".

The Java ecosystem is enormous and a newcomer finds it overwhelming. In reality it sorts nicely into eight categories, and in each one there are two or three dominant options.

With this map in front of you, the ecosystem stops being an endless list of names and becomes eight decisions, each with a reasonable default.

Adding a line to the pom.xml takes five seconds and commits your team for years. These are the criteria that are actually used.

A practical checklist before you write the dependency:

If you hesitate on more than two boxes, do not add it yet.

Before all the criteria above there is a question far too many people skip.

The modern JDK is much richer than people remember. A great many historical dependencies are no longer needed:

And the counterweight: nor should you write yourself what is notoriously hard to get right. Cryptography, date parsing with time zones, JSON parsing, CSV parsing with embedded quotes and line breaks (remember your CsvReader from 07-07 and all the edge cases it did not cover), and anything to do with security. There, a mature dependency always beats your own implementation.

The practical rule: write yourself what is specific to your business; delegate what is generic and hard.

When you add a dependency, where does the jar come from?

Maven Central is the public repository of Java artefacts, maintained by Sonatype. It holds millions of versions of hundreds of thousands of libraries, and it is Maven's and Gradle's default target. When you write a dependency and run mvn package, Maven downloads it from Central and stores it in your local repository (~/.m2/repository) so it never has to download it again.

Every artefact is identified by three coordinates:

They are written in short form as groupId:artifactId:version, for example com.fasterxml.jackson.core:jackson-databind:2.17.1. You will see that notation in Maven's output, in security reports and throughout the documentation.

And the physical path is predictable: the groupId with its dots turned into folders, then the artifactId, then the version. The jar above lives at:

Knowing this genuinely helps the day Maven tells you it cannot find an artefact: you can go to that folder and see whether it is there, whether it is corrupt, or whether all you have is a .lastUpdated file (the classic symptom of a failed download, fixed by deleting the folder and running mvn -U).

All of this is developed in 11-05. Here you only need the vocabulary.

Most of the Java ecosystem follows semantic versioning (SemVer), with the format MAJOR.MINOR.PATCH:

The usual suffixes, from least to most stable:

Two practical consequences:

1. Bumping PATCH or MINOR should be safe, and it is what you do continuously to pick up security fixes.
2. Bumping MAJOR requires reading the migration notes. The canonical and very current example: Spring Boot 2.x → 3.x replaced every javax.* package with jakarta.* and requires Java 17. That is why everything about persistence in this course is jakarta.persistence and not javax.persistence. If you copy an example from the internet with javax.persistence, it is from Spring Boot 2 and it will not compile.

Here comes the uncomfortable part.

When you add a dependency, you do not add a jar: you add a tree. A single spring-boot-starter-web brings in around thirty transitive artefacts. A typical enterprise project has between 100 and 400 jars, of which you wrote zero.

Every one of those jars runs code with the same permissions as your application. It can read your files, open network connections and access your environment variables. And you have reviewed none of them.

This is called software supply chain risk, and it takes three forms:

In December 2021 CVE-2021-44228, nicknamed Log4Shell, was published against Apache Log4j 2, one of the most widely used logging libraries in the Java world.

The technical summary, without the drama: Log4j 2 supported variable substitution inside log messages, and one of the supported forms allowed a JNDI lookup against a remote server. Consequence: if an application logged text controlled by an attacker —an HTTP header, a user name, a User-Agent— the attacker could make the server download and run their code. Remote code execution from a single line of text.

Why it was so serious:

• Trivial to exploit: all it took was sending a string in any field that ended up in a log.
• Ubiquitous: Log4j 2 was in tens of thousands of products, very often as a transitive dependency the team did not even know it had.
• Hard to inventory: the question "do we have Log4j?" turned out not to be easy to answer in most organisations. And that was the real lesson.

What the industry learned, and what affects you directly:

1. You have to know what you have. Hence the rise of the SBOM (Software Bill of Materials), the inventory of an application's components.
2. You have to be able to update fast. If updating a dependency takes three weeks of manual testing because there are no automated tests, your exposure window is three weeks. This connects directly with the whole of module 11: without Maven you cannot change a version with one line, and without JUnit you cannot verify that the change broke nothing.
3. You have to watch continuously. A project that is secure today has vulnerabilities six months from now without a single line of code changing, because vulnerabilities are discovered in code that already existed.

Important notice. What is described here is what a developer needs to know in order not to take naive decisions. In a real project, the dependency policy, vulnerability analysis and incident response are the responsibility of the organisation's security team or officer, with their own tools and processes. Your role is to keep the dependency tree under control, update when you are told to and not introduce dependencies without judgement. Application security practices are covered in 12-07.

Three tools you will use from 11-05 onwards.

1. Seeing the whole tree. This is the first one and the one used most:

Output (trimmed) from a Spring Boot project with web:

There you see at a glance three things this module is going to explain: that Spring Boot already brings Logback and SLF4J (11-07), that it already brings Jackson (11-07) and that it already brings embedded Tomcat (12-04). And you see that a jar you never declared, logback-core, is in your application.

To find who drags in a specific artefact:

2. Looking for known vulnerabilities. The OWASP plugin checks your tree against the public vulnerability database:

It generates an HTML report in target/ with the CVEs found and their severity. In a real project this runs in continuous integration, not by hand.

3. Seeing what is out of date.

It lists, dependency by dependency, which version you use and which is the latest available. Running it every few weeks and applying the patch updates is one of the most profitable hygiene practices there is.

If you have got this far, the list of options may be paralysing. The criterion for choosing the first one is not technical, it is about learning:

1. Learn the one that is used most. Not because it is the best, but because when you get stuck —and you will— somebody has already got stuck the same way and written it down. Documentation, courses and answers are a real resource.
2. Learn one well rather than three halfway. The concepts —IoC, DI, ORM, AOP, persistence context— transfer. The syntax does not. Someone who masters Spring learns Quarkus in two weeks; someone who has skimmed all three masters none.
3. Learn with a real project, not with isolated examples. That is why this module is about BiblioTech, and why there is a whole module 12 to integrate it all.

Honestly, three reasons and one warning.

• It is what the market has. A very large majority of Java back-end job openings mention Spring or Spring Boot. It is the knowledge with the highest immediate value.
• It covers every category on the map. With Spring Boot you touch DI, web, persistence, testing, configuration, security and observability with one coherent model. You learn eight things inside one ecosystem instead of across eight.
• Its magic is exactly the magic you already understand. Annotations, reflection, dynamic proxies. You are in the best possible position to learn it without it being magic.

The warning: Spring is not the answer to everything. For a small CLI it is a sledgehammer to crack a nut, and up to 12-03 you will see that a well-structured console application does not need it. For serverless functions with cold starts, Quarkus or Micronaut are better. And for a service that only runs three SQL queries, jOOQ or JdbcTemplate may fit better than Hibernate. Choosing well is part of the craft; and to choose you have to know.

This module has a deliberate structure: each lesson settles one debt from module 10 and presents one tool completely and self-containedly. Integration into a real project is module 12.

By the end of the module, BiblioTech will be a Maven project with Spring, JPA persistence over H2, tests with JUnit and Mockito, JSON with Jackson and logging with SLF4J. It will not be a complete application yet —that is module 12— but all its pieces will be the real ones.

Mistake: believing a framework excuses you from understanding what lies underneath. It is exactly the other way round. The framework automates; when the automation fails, only someone who understands the mechanism can fix it. If @Transactional does not roll back, you need to know about proxies and about database transactions.

Mistake: adding dependencies without evaluating them. "I need to sort a list, I'll add Guava." No. Look first at the JDK, then at what you already have in the tree, and only then at Maven Central.

Mistake: copying examples from the internet without checking the version. The unmistakable symptom: javax.persistence instead of jakarta.persistence, or WebSecurityConfigurerAdapter, which was removed. Those are from Spring Boot 2 and do not compile on 3. Always check the date and version of the example.

Mistake: pinning versions of dependencies the BOM manages. When you use spring-boot-starter-parent, do not put <version> on the dependencies it manages: you are taking away its job of guaranteeing that the versions are compatible with each other. This is explained in 11-05.

Mistake: using version ranges or LATEST. It destroys reproducibility: the same git tag compiles differently depending on the day. Always pin concrete versions.

Mistake: never updating "because it works". An application left untouched for three years accumulates dozens of known vulnerabilities. And when you finally have to update, the jump is so big that it becomes a project.

Tip: tell the core apart from the plumbing. Keep your domain (entities, business rules) as free of framework annotations as possible. BiblioTech's fine logic must be testable without starting Spring. This principle is explored further in 12-02.

Tip: learn to read a dependency:tree. It is the tool that will get you out of trouble most often: version conflicts, duplicate jars, classes appearing twice, and the security question "do I have this library?".

Tip: when something in the framework looks like magic, look for the mechanism. Ask yourself: is it an annotation read by reflection? Is it a proxy? Is it code generated at compile time? It is almost always one of the three, and then it stops being magic.

Tip: look at a starter's dependencies before adding it. A spring-boot-starter-web brings Tomcat, Jackson, validation and logging. Knowing that stops you adding Jackson yourself at another version and causing a conflict.

For each item in the list, say whether it is a library or a framework, and justify your answer with the "who calls whom" criterion. In the ambiguous cases, explain why they are ambiguous.

1. java.util.Collections
2. JUnit 5
3. Jackson's ObjectMapper
4. Hibernate
5. SLF4J
6. Spring Boot
7. The SimpleContainer you wrote in 10-03
8. The AuditProxy you wrote in 10-03

Nexus Software needs to generate barcodes for the labels on BiblioTech's books. A colleague proposes adding a library they found. Write the analysis you would carry out before accepting it, using the lesson's checklist, and decide. Available data:

• groupId:artifactId — com.example:barcode-magic
• Latest version: 0.4.1, published 3 years ago
• Licence: not stated in the POM
• Usages in Maven Central: 7 projects
• Transitive dependencies: 14 jars, including a full graphics engine and an XML library
• Documentation: an 8-line README
• One medium-severity CVE open for 14 months

For each of these "magic" behaviours you will see in the coming lessons, say which of the four mechanisms from section 6 makes it possible and what you wrote in module 10 that resembles it.

1. You write @Service on LoanManager and Spring instantiates it on its own.
2. You write @Transactional and the database rolls back when an exception is thrown.
3. You write Lombok's @Getter and a getTitle() you never wrote appears.
4. You declare interface LoanRepository extends JpaRepository<Loan, Long> without implementing it and it works.
5. You write @Test and the method runs without a main.
6. You write @JsonProperty("isbn_13") and Jackson uses that name in the JSON.

Solution 1

The conclusion that matters: you wrote two miniature frameworks without calling them that.

Solution 2

Applying the checklist:

Decision: reject. Four critical boxes fail, and the licence alone would be enough. Counter-proposal: use ZXing, and do it behind an interface of our own (LabelGenerator), so that the specific library is isolated in a single class and the future cost of changing it is one implementation. And add dependency analysis to continuous integration so the next CVE is detected automatically.

A professional note: the licence point is not negotiated on technical grounds. In a company, a jar with no declared licence is a legal problem, and that conversation belongs to the appropriate person, not to the developer acting alone.

Solution 3

If you have been able to complete this table, the lesson's goal is met: there is no magic left, only four mechanisms you already know applied at industrial scale.

Frameworks stopped being a black box before you even used the first one.

You can tell a library from a framework by the only question that matters —who calls whom— and you recognise the Hollywood Principle when you see it: a @Test method with no main, a @Service that instantiates itself, an entity that saves without you calling save. And you understand inversion of control not as a textbook definition but as the concrete change you made in LoanManager: from creating its own dependencies with new to declaring them in the constructor and letting somebody else resolve them — with the four consequences that had (it can be tested, the implementation can be swapped, it can be configured per environment and the clock stops being the system's).

You know what you buy and what you pay. You buy non-differentiating code already solved, conventions any developer understands, an integrated ecosystem and —the most underestimated of all— security patches maintained by others. You pay a learning curve, architectural coupling, implicit behaviour that is hard to debug, and weight. And you know that the correct answer to "framework, yes or no?" always begins with "it depends on the context".

And above all, you know how the magic holds up: annotations with @Retention(RUNTIME) that are inert labels; reflection that reads them and acts; dynamic proxies that wrap your objects to add behaviour without touching your code —with the detail, which you will run into, that an internal call does not go through the proxy and that CGLIB cannot cope with anything final—; and code generation, at compile time with annotation processors or at runtime with bytecode. Four mechanisms. You have written or studied all four. And you have the complete map of what you did by hand → what the real framework does, which is both your road map for the module and your diagnostic manual when something breaks.

You have the map of the ecosystem sorted into eight categories with a default option in each, so that the endless list of names becomes eight decisions. And you have judgement for the decision you will take dozens of times: whether or not to add a dependency. With the prior question up front —doesn't the JDK already do it?, because java.time, HttpClient, Files.readString, String.isBlank and record have made many classic dependencies obsolete— and the real criteria behind it: maintenance, licence, adoption, transitivity, security and exit cost.

You know Maven Central, the groupId:artifactId:version coordinates, the predictable path inside ~/.m2 and semantic versioning with its most practical consequence today: the jump from Spring Boot 2 to 3 replaced javax.* with jakarta.*, and that is why an example copied from the internet with javax.persistence simply will not compile.

And you understand supply chain risk: that an average project has hundreds of jars nobody has reviewed running with your permissions, that Log4Shell proved the hard question was not patching but knowing what you have, and that the ability to update fast depends on exactly the two tools in this module —Maven to change a version with one line and JUnit to verify you broke nothing—. With the clear warning that, in a real project, dependency policy and vulnerability response belong to the security officer, and that application security practices arrive in 12-07.

The plan is set and every lesson settles a debt. The first one is the biggest: that hundred-and-fifty-line SimpleContainer you wrote so you would not have to call new, and which is missing absolutely everything else — scopes, lifecycle, profiles, externalised properties, ambiguity resolution and transactions.

In the next lesson, BiblioTech throws that container away and adopts the one ten thousand developers have spent twenty years polishing. You will see the ApplicationContext, the three forms of injection and why only one is advisable, the stereotypes, a bean's lifecycle, the scopes, the dev and prod profiles, the typed properties that replace your Configuration from 07-07, and Spring Boot's auto-configuration explained properly — not as magic, but as a set of conditions you can read and debug.

And when you get to @Transactional, you will not see a mysterious annotation: you will see your own AuditProxy, with twenty years of polish on top.

We start with Spring.