Tiny typos in Date Time articles ( https://dev.java/learn/date-time/ ) and Reflection articles ( https://dev.java/learn/reflection )

[willy-b]

Thanks for the excellent content!

Just sharing a few small typos I found in case the team wants to clean them up in the next version.

---

• https://dev.java/learn/date-time/zoneid-zone-offset/ (archived at https://web.archive.org/web/20260208003013/https://dev.java/learn/date-time/zoneid-zone-offset/ ) has at least one typo:

The following code, **efines** the departure time for a flight from San Francisco to Tokyo as a [ZonedDateTime](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/time/ZonedDateTime.html) in the America/Los Angeles time zone.

efines should be defines .

---

• https://dev.java/learn/date-time/temporal/ (archived: https://web.archive.org/web/20260208020314/https://dev.java/learn/date-time/temporal/ ) has at least one typo:
  The nest example is the PaydayAdjuster custom adjuster
  nest should be next .

---

• https://dev.java/learn/reflection/names/#array (archived: https://web.archive.org/web/20260208021909/https://dev.java/learn/reflection/names/#array )

has a typo, "refence" instead of "reference."

---

• For https://dev.java/learn/reflection/fields/ (archived https://web.archive.org/web/20260206042334/https://dev.java/learn/reflection/fields/ )

there are a few issues.

First, a small typo in:

Note that there are restrictions on the members you can make accessible, if there are in other modules. You can check the page [Reflective Access with Open Modules and Open Packages](https://dev.java/learn/modules/opening-for-reflection/) for more information.

That is, "if there are in other modules", "there" should be "they." (see screenshot below, shared with one more example).

Then for: "This codes makes the field nameField accessible, despite being private."
It seems it should be "This code makes" instead of "This codes makes" (with an extra "s" on "codes") (see screenshot above).

Finally, in two code snippets, the "toString()" method for the User class is overridden, and both of them have a typo in the String returned.
That is, in two places:

    public String toString() {
        return "User[name='" + name + "]"; // missing single quote before square bracket on right side of name
    }

should be:

    public String toString() {
        return "User[name='" + name + "']"; // single quote added before square bracket on right side of name
    }

A side note, in the example, it is not mentioned that,
for

Field nameField = userClass.getDeclaredField("name");

NoSuchFieldException must be caught or declared to be thrown,
and

nameField.set(maria, "Mary");

IllegalAccessException must be caught or declared to be thrown, which might also be worth mentioning.

---

• For https://dev.java/learn/reflection/methods/ (archived: https://web.archive.org/web/20260206041438/https://dev.java/learn/reflection/methods/ )

In

You can still get access to such a method and invoke it, by first calling [method.setAccessible(true)](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/reflect/Method.html#setAccessible(boolean)) on it. 
This call may fail in case you are trying to invoke a method from a class in another module, 
due to the restrictions on the class members a module. You can check the page [Reflective Access with Open Modules and Open Packages](https://dev.java/learn/modules/opening-for-reflection/) for more information.

Not sure what wording exactly was intended to be written for "due to the restrictions on the class members a module," which is not grammatically correct. It may be missing a preposition before "a module" or might be a leftover fragment that should simply be removed. Perhaps the rest of the sentence prior is fine by itself, e.g. "This call may fail in case you are trying to invoke a method from a class in another module," because the package containing the class of interest may not be opened or exported by the other module, which is already explained by the link given in the next sentence.

Also "But by doing so you loose the type safety of calling the method directly."
"loose" should be "lose" in this case.

Thanks so much for the all the content!

Bit hesitant to bother you with the reports of the typos and other little issues, but if I were hosting this I would want these reported (and they are very easy to clean up), so letting you know.

[JosePaumard]

Hello, and thank you for taking the time to report all this! I just pushed the fixes.
is "This call may fail in case you are trying to invoke a method from a class in another module, due to the access restrictions on class members that a module may declare." correct, and is it clear enough?
Again, thank you!

[willy-b]

Thanks for the updates!

All typos I had reported in the Date Time articles have been resolved.

(As of https://web.archive.org/web/20260208223138/https://dev.java/learn/date-time/zoneid-zone-offset/ and https://web.archive.org/web/20260208223211/https://dev.java/learn/date-time/temporal/ .)

For the Reflection article on Fields ( https://dev.java/learn/reflection , section https://dev.java/learn/reflection/fields/ ; archived at https://web.archive.org/web/20260208223622/https://dev.java/learn/reflection/fields/ ) , there are a couple of items remaining:

• The print output for instances of User in the examples for https://dev.java/learn/reflection/fields/ now needs to be updated to match the fixed toString .
  • The original toString already did not match the shown output (0 single quotes around the name are shown, whereas the code in the original, archived at https://web.archive.org/web/20260206042334/https://dev.java/learn/reflection/fields/ , would have printed 1 imbalanced single quote and now should print 2 balanced single quotes around the name).
• Nit: On https://dev.java/learn/reflection/fields/ , the sentence "You can read more on access flags in this section" , is missing a period at the end. (archived: https://web.archive.org/web/20260208223622/https://dev.java/learn/reflection/fields/ ).
• Instead of the new "Note that this method throws an IllegalAccessException" after the example including nameField.set(maria, "Mary");, you might consider to write something like "Note that Field.set(Object, Object) declares that it can throw the checked Exception IllegalAccessException, so the method call must be wrapped in an appropriate try-catch block or the calling method must also declare that it throws IllegalAccessException for the code to compile successfully. Such exception handling has been omitted from these code snippets for brevity but must be included by those following along at home."
• Instead of the new "Note that the getDeclaredField() throws a NoSuchFieldException" after the example including Field nameField = userClass.getDeclaredField("name");, you might instead consider to write something like "Note that getDeclaredField() declares that it can throw the checked Exception NoSuchFieldException, so exception handling, not shown here, will be required for this example to compile." (The explanation could also be more verbose like what I suggested for IllegalAccessException above.)

---

Re: your question on how you should finish the sentence

You can still get access to such a method and invoke it, by first calling method.setAccessible(true) on it.
This call may fail in case you are trying to invoke a method from a class in another module,

on https://dev.java/learn/reflection/methods/ (current version with your proposed edit archived at https://web.archive.org/web/20260208223938/https://dev.java/learn/reflection/methods/ ):

is "This call may fail in case you are trying to invoke a method from a class in another module, due to the access restrictions on class members that a module may declare." correct, and is it clear enough?

I think "due to the access restrictions of class members that a module may declare"
is a little confusing to be honest because, as I understand it (see the spec quote below):

1. the reflective access is restricted at the package, not class level
2. from outside a module, reflective access to packages is restricted by default (so a module does not need to declare access restrictions to block reflective access); unless packages are exported or opened, the classes within are not accessible to reflection.

Per JLS 25:
https://docs.oracle.com/javase/specs/jls/se25/jls25.pdf

A normal module
grants reflective access to types in only those packages which are explicitly
exported or explicitly opened (or both). An open module grants reflective access
to types in all its packages, as if all packages had been opened.

For code outside a normal module, the reflective access granted to types in the
module's exported (and not opened) packages is specifically to the public and
protected types in those packages, and the public and protected members of
those types. The reflective access granted to types in the module's opened packages
(whether exported or not) is to all types in those packages, and all members of those
types. No reflective access is granted to types, or their members, in packages which
are not exported or opened

Or e.g. also per https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/reflect/AccessibleObject.html

Whether the checks for Java language access control can be suppressed (and thus, whether access can be enabled) depends on whether the reflected object corresponds to a member in an exported or open package (see setAccessible(boolean)).

Thanks very much!