Typos and potential small errors in the Modules tutorials ( https://dev.java/learn/modules )

[willy-b]

Hello dev.java team!

Thanks so much for the tutorial on the Java Platform Module System!
I wanted to share some items I found so far while reviewing it that may be of interest to the team to fix (typos, potential small mistakes, etc).

---

In the latest version of https://dev.java/learn/modules/services/ (archived as is at https://web.archive.org/web/20260706001005/https://dev.java/learn/modules/services/ )

• In the sentence

  The module providing the service has to express its offer with a provides $SERVICE with $PROVIDER directive, where $SERVICE is the same type as in the uses directive and $PROVIDER the fully qualified name of another class, which is...

  • either a concrete class that extends or implements $SERVICE and has a public, parameterless constructor (called a provider constructor)
  • or an arbitrary type with a public, static, parameterless method provide that returns a type that extends or implements $SERVICE (called a provider method)

  in "with a public, static, parameterless method provide " the name of the method should be "provider" instead of "provide" (see Java 26 JLS 7.7.4 at https://docs.oracle.com/javase/specs/jls/se26/html/jls-7.html#jls-7.7.4 , archived as is at https://web.archive.org/web/20260706000738/https://docs.oracle.com/javase/specs/jls/se26/html/jls-7.html#jls-7.7.4 ).

---

In the latest version of https://dev.java/learn/modules/ (archived as is at https://web.archive.org/web/20260705193540/https://dev.java/learn/modules/ )

• In the section description sentence

  Use requires transitive to imply readability, where a module passes its dependency on another module on, allowing a other modules to read it without explicitly depending on it.

  "allowing a other modules to read it" should be "allowing other modules to read it".

---

In the latest version of https://dev.java/learn/modules/intro/ (archived as is at https://web.archive.org/web/20260705221201/https://dev.java/learn/modules/intro/ )

• In the sentence

  It turns all artifacts on the module path into modules, even plain JARs, which get turned into automatic modules, which is enables incremental modularization.

  "which is enables incremental modularization" should be "which enables incremental modularization".

---

In the latest version of https://dev.java/learn/modules/optional-dependencies/ (archived as is at https://web.archive.org/web/20260705223812/https://dev.java/learn/modules/optional-dependencies/ )

• In the sentence

  If module A requires static module B, the module system behaves different at compile and run time

  "behaves different" should probably be "behaves differently"

• In the sentence

  But as we explored when discussing module resolution, this means tha the module system will throw an error at run time if com.sample.solver is absent - clearly the dependency is not optional.

"this means tha the" should be "this means that the"

• In the sentence

  It may not always be ne necessary to explicitly check a module's presence, though.

  "not always be ne necessary to" should be "not always be necessary to"

---

In the latest version of https://dev.java/learn/modules/implied-readability/ (archived as is at https://web.archive.org/web/20260509144618/https://dev.java/learn/modules/implied-readability/ )

• In the sentence

  It also uses java.xml but unlike java.prefs not just internally - the public class java.sql.SQLXML maps the SQL XML type and as such uses types from java.xml its own API.

  "from java.xml its own API" should be "from java.xml in its own API".

---

In the latest version of https://dev.java/learn/modules/automatic-module/ (archived as is at https://web.archive.org/web/20260706150054/https://dev.java/learn/modules/automatic-module/ )

• In the sentences

  An example is the bytecode manipulation tool ByteBuddy:
  It is published in Maven Central as byte-buddy-$VERSION.jar, which lead to the automatic module name byte.buddy (before it defined a proper name).
  Unfortunately, this is illegal, because byte is of course a Java keyword.

  The verbs are inconsistent ("An example is" , "It is published", "which lead to" , "before it defined", "this is illegal").
  This could be fixed in many ways. One example of a grammatical rewrite would be
  "An example was an earlier version of the bytecode manipulation tool ByteBuddy: It was published in Maven Central as byte-buddy-$VERSION.jar, which led to the automatic module name byte.buddy (before it defined a proper name). Unfortunately, this was illegal, because byte is of course a Java keyword."

• In the sentence

  Furthermore, most projects use a Maven-backed local repository, where the JAR files are named ${artifactID}-$VERSION, from which the module system will likely infer ${artifactID} as the automatic module's name.

  the second occurrence of "${artifactID}" is not styled consistently with the first (as code).

• In the sentence

  No, mistake is to publish modules with such dependencies to a public repository.

  "No, mistake is" should be "No, the mistake is".

---

In the latest version of https://dev.java/learn/modules/strong-encapsulation/ (archived as is at https://web.archive.org/web/20260706184408/https://dev.java/learn/modules/strong-encapsulation/ )

• In the sentence

  Less visible classes and members are internal and strongly encapsulates by the module system.

  "are internal and strongly encapsulates by" should be "are internal and strongly encapsulated by" ("encapsulates" should be "encapsulated" in this case).

---

Feel free to leave this open after pushing a fix as I would be happy to review any such changes to help you confirm that the items reported have been addressed.

Thanks!

[JosePaumard]

Thank you again for your report! A fix is on its way.