On Mon, 7 Dec 2020 14:20:07 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> @erikj79 Good point, that makes much more sense.
>
> I'm not sure about the formal process for suggesting changes to a delivered
> JEP, but this is the text I suggest should replace the current definition of
> the new scheme:
>
> src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
> native/include/*.{h,hpp}
> $LIBRARY/*.{c,cpp}
> conf/*
> legal/*
> data/*
> man/*
> lib/*
>
> where:
>
> - $MODULE is a module name (_e.g._, `java.base`);
>
> - The `share` directory contains shared, cross-platform code, as
> before;
>
> - The `$OS` directory contains operating-system-specific code, as
> before, where `$OS` is one of `unix`, `windows`, _etc._;
>
> - The `classes` directory contains Java source files and resource files
> organized into a directory tree reflecting their API `$PACKAGE`
> hierarchy, as before;
>
> - The `native` directory contains C or C++ source files, as before but
> organized differently:
>
> - The `include` directory contains C or C++ header files intended to
> be exported for external use (_e.g._, `jni.h`);
>
> - C or C++ source files are placed in a `$LIBRARY` directory, whose
> name is that of the shared library or DLL into which the compiled
> code will be linked (_e.g._, `libjava` or `libawt`); and, finally,
>
> - The `conf` directory contains configuration files meant to be edited
> by end users (_e.g._, `net.properties`).
>
> - The `legal` directory contains legal notices.
>
> - The `data` directory contains data files needed for building the module.
>
> - The `man` directory contains man pages in nroff or markdown format.
>
> - The `lib` directory contains configuration files not meant to be edited
> by end users.
>
> Rendered as markdown, it would look somewhat like this:
>
> src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
> native/include/*.{h,hpp}
> $LIBRARY/*.{c,cpp}
> conf/*
> legal/*
> data/*
> man/*
> lib/*
>
> where:
>
> - $MODULE is a module name (_e.g._, `java.base`);
>
> - The `share` directory contains shared, cross-platform code, as
> before;
>
> - The `$OS` directory contains operating-system-specific code, as
> before, where `$OS` is one of `unix`, `windows`, _etc._;
>
> - The `classes` directory contains Java source files and resource files
> organized into a directory tree reflecting their API `$PACKAGE`
> hierarchy, as before;
>
> - The `native` directory contains C or C++ source files, as before but
> organized differently:
>
> - The `include` directory contains C or C++ header files intended to
> be exported for external use (_e.g._, `jni.h`);
>
> - C or C++ source files are placed in a `$LIBRARY` directory, whose
> name is that of the shared library or DLL into which the compiled
> code will be linked (_e.g._, `libjava` or `libawt`); and, finally,
>
> - The `conf` directory contains configuration files meant to be edited
> by end users (_e.g._, `net.properties`).
>
> - The `legal` directory contains legal notices.
>
> - The `data` directory contains data files needed for building the module.
>
> - The `man` directory contains man pages in nroff or markdown format.
>
> - The `lib` directory contains configuration files not meant to be edited
> by end users.
I hope I understood the purpose of the `lib` directory correctly. Our only
instance of this is for `java.base/*/lib/security/default.policy`.
I also noted that jdk.hotspot.agent violates this scheme by having a top-level
`test` and `doc` directories, apart from `share` and the OS directories. The
purposes of these two directories are not clear to me. The tests in `test` are
definitely never executed. I don't know if this is an omission, or if they
should be removed. The documentation in `doc` is not exported to the end
product, nor is it references in any developer documentation. That too should
either be removed, or moved to a more suitable home.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1611
