diff --git a/documentation/src/main/asciidoc/introduction/Tuning.adoc b/documentation/src/main/asciidoc/introduction/Tuning.adoc
index 73de3e8585..eb2b375995 100644
--- a/documentation/src/main/asciidoc/introduction/Tuning.adoc
+++ b/documentation/src/main/asciidoc/introduction/Tuning.adoc
@@ -239,7 +239,7 @@ session.setSubselectFetchingEnabled(true);
 [%unbreakable]
 [TIP]
 ====
-We may request subselect fetching more selectively by annotating a collection or many-valued association with the `@Fetch` annotation.
+We may request subselect fetching more selectively by annotating a collection or many-valued association with the link:{doc-javadoc-url}/org/hibernate/annotations/Fetch.html[`@Fetch`] annotation.
 [source,java]
 ----
 @ManyToMany @Fetch(SUBSELECT)
@@ -362,7 +362,7 @@ So a second-level cache is often by far the easiest way to improve the performan
 And so the cache is a potential source of bugs which are difficult to isolate and reproduce.
 
 Therefore, by default, an entity is not eligible for storage in the second-level cache.
-We must explicitly mark each entity that will  be stored in the second-level cache with the `@Cache` annotation from `org.hibernate.annotations`.
+We must explicitly mark each entity that will  be stored in the second-level cache with the link:{doc-javadoc-url}/org/hibernate/annotations/Cache.html[`@Cache`] annotation from `org.hibernate.annotations`.
 
 But that's still not enough.
 Hibernate does not itself contain an implementation of a second-level cache, so it's necessary to configure an external _cache provider_.
@@ -529,7 +529,7 @@ There's no need for this association to be lazily fetched, since we're expecting
 But on the other hand, if we leave it marked for eager fetching then, by default, Hibernate will often fetch it using a join.
 This places completely unnecessary load on the database.
 
-The solution is the `@Fetch` annotation:
+The solution is the link:{doc-javadoc-url}/org/hibernate/annotations/Fetch.html[`@Fetch`] annotation:
 
 [source,java]
 ----
@@ -694,7 +694,7 @@ As is generally the case with any second-level cache, the query cache can break
 For the most part, the second-level cache is transparent.
 Program logic which interacts with the Hibernate session is unaware of the cache, and is not impacted by changes to caching policies.
 
-At worst, interaction with the cache may be controlled by specifying of an explicit `CacheMode`:
+At worst, interaction with the cache may be controlled by specifying of an explicit link:{doc-javadoc-url}/org/hibernate/CacheMode.html[`CacheMode`]:
 
 [source,java]
 ----
@@ -918,7 +918,7 @@ Indeed, the usual practice is to avoid having transactions that span user intera
 That said, there _is_ also a place for pessimistic locks, which can sometimes reduce the probability of transaction rollbacks.
 
 Therefore, the `find()`, `lock()`, and `refresh()` methods of the reactive session accept an optional `LockMode`.
-We can also specify a `LockMode` for a query.
+We can also specify a link:{doc-javadoc-url}/org/hibernate/LockMode.html[`LockMode`] for a query.
 The lock mode can be used to request a pessimistic lock, or to customize the behavior of optimistic locking:
 
 .Optimistic and pessimistic lock modes