Why are there a lot of non-public low-level Java methods ending in 0?

I like to poke around the Java source with IntelliJ. However, I have noticed something strange. Some non-public methods, particularly those in low-level classes, end in 0. This is most often the case with native methods, however I have observed some non-native methods with this name too. For example, java.lang.reflect.Executable#getAnnotatedReturnType0(Type), and java.lang.reflect.AccessibleObject#setAccessible0(boolean). The former simply sets two boolean flags! What is the reasoning behind this strange convention?

It's a somewhat common convention for helper methods.

Java does not allow methods-in-methods (though there is some traffic about adding them). Sometimes you have a repetitive task that nevertheless doesn't fit properly in a looping structure (such as a while or for loop) and doesn't easily fit in a lambda (because its parameter + checked exception requirements don't line up to a convenient type, or the code predates JDK8).

The JDK itself, and some other projects, use the convention of: helper methods get the same name it is a helper for, with a single digit suffix, generally 0 (if there are more helpers, they'd be 1, 2, etc).

This is particularly common with overloading. Let's say you have the following method signature:

/**
 * Detaches a disk from a virtual computer.
 * The disk must have been unmounted already on the virtual PC, unless
 * the {@code force} parmater is true, but note that (long story
 * about the perils of force disconnecting here).
 *
 * @param computerId computer to detach the disk from.
 * @param diskId ID of disk to detach
 * @param force Force the issue even if the disk is in use.
 * @throws DiskInUseException If the disk is in use. Never thrown if
 * {@code force} is {@code true}.
 */
public void detachDisk(
   String computerId, String diskId, boolean force) throws DiskInUseException { ... }

That's a bad API. It's got all sorts of ugly warts on it:

• The docs specify a lot of caveats that literally do not apply whatsoever if I set force to false.
• It throws a checked exception that may never occur, which is always bad (don't force calling code to catch impossible exceptions, obviously!) - if force is true, the DiskInUseException cannot occur.
• If I call it: detachDisk(computer, disk, true) and I see that in code, I can guess that computer is a variable referring to a virtualPC, same for disk but whatever might true be about? I might guess that it's about forcing things, but maybe in my head that third parameter is safely (the reverse of force).

We can solve a few issues by using an enum instead of a boolean, but that leaves the rest. This is vastly superior API design:

/**
 * Same text, but leave out all the stuff about the dangers of forcing.
 * @see #forceDetachDisk(String, String)
 */
public void detachDisk(String computerId, String diskId)
   throws DiskInUseException {..}

/**
 * Same, but now highlight the dangers of forcing.
 * @see #detachDisk(String, String)
 */
void forceDetachDisk(String computerId, String diskId) { .. }

Muuuch better, but most likely these 2 methods share most of the implementation. That naturally leads to making this thing:

private void detachDisk0(String computerId, String diskId,
   boolean force) throws DiskInUseException { .. }

which is private so the confusion and warts it has don't matter, and the public detachDisk methods will simply call the private one. However, some auto-complete dialogs, and certainly most java compilers including javac itself, do recognize calls to private methods and will 'helpfully' alert you about the fact that it does exist, and would you perhaps like to change its accessor keyword (if it's a source file and not a class dep)? - That's not so nice. Toss that 0 in there to lessen the effect, and to make more clear that the private method is meant solely to be invoked by the 0-less methods and no other method; you wrote it with only its usage from the detachDisk method, and not any other method, not even in the same source file.

That's an API design more projects should be using.

This "convention" has been used not only for Java. I remember seeing the same in C#. Usually you will see a public method with the same name (without the zero at the end) calling the private method ending in zero.

But anyway, this naming convention for a private method is not a good example or something you should copy.