The POSIX definition for JVM_MAXPATHLEN is (MAXPATHLEN + 1). There is a comment explaining that the +1 is to account for slightly different values on different versions of Linux (4095 vs 4096), and to account for the JVM and the rest of the JDK being built on different Linux versions. But that usage model (HotSpot Express) was killed a long time ago.

Shared JVM code uses JVM_MAXPATHLEN, which it gets from jvm_md.h (either the POSIX version or the Windows version). Having lots of JVM code (implicitly) including jvm.h is something we should be moving away from.

Code specific to POSIX (and variants) instead uses MAXPATHLEN consistently, and seem to not use JVM_MAXPATHLEN. Similarly, Windows-specific code uses neither, instead using MAX_PATH.

So it seems JVM_MAXPATHLEN exists to provide a definition for shared HotSpot code. As such, a better location for it would be os_{posix,windows}.hpp.

That we have potential differences between shared and unshared code (using JVM_MAXPATHLEN in shared code, while using MAXPATHLEN (posix) or MAX_PATH (windows)) is kind of disturbing, though I've not found any place that seems like an actual problem.

That JVM_MAXPATHLEN is consistently greater than MAXPATHLEN on POSIX systems, and might be greater than MAX_PATH on Windows, also seems potentially problematic.

I _think_ what ought to happen is

1. Remove the +1 from the POSIX definition of JVM_MAXPATHLEN, instead just making it expand to MAXPATHLEN.

2. Move the definitions for JVM_MAXPATHLEN from jvm_md.h files to os_{posix,windows}.hpp files.

3. Investigate whether the Windows definition should remain a hard-coded 1024 or should instead be MAX_PATH. (Or something else. MAX_PATH seems to be relatively small. The alternative seems to involve using APIs and configuration for long paths. Maybe we're already doing that?)