I structured it this way as I think it adds to the clarity of the API; .linker has classes essential for implementing linkers, and .linker.support contains conveniences. Similarly, .support contains conveniences for using the base package.
Other approaches I could think of: 1. merge .linker.support into .support: I dislike it as I can imagine some languages not needing .linker or .linker.support (e.g. a scripting shell or a language that doesn’t have its own object model but uses JVM object model straight). I don’t want .support to be a multipurpose “util” package. 2. merge .linker.support into .linker: then .linker would look more complicated than it is; right now it only contains the specification essentials 3. instead of .linker.support use .support.linker: same depth of package names, not sure what’s the benefit. I’d be for keeping the current structure (obviously :-) ) Attila. > On Oct 20, 2015, at 3:22 PM, Hannes Wallnoefer <hannes.wallnoe...@oracle.com> > wrote: > > Adding the linker.support package is probably the correct thing to do. But it > creates two similiarly named packages and a deeper and bigger package > structure. My approach would have been to keep the package structure simple, > but if most people agree it's better this way I won't stand in the way. > > Hannes > > Am 2015-10-16 um 16:04 schrieb Attila Szegedi: >> Please review JDK-8139761 "Improve Dynalink class nomenclature and package >> organization" at <http://cr.openjdk.java.net/~attila/8139761/webrev.jdk9> >> for <https://bugs.openjdk.java.net/browse/JDK-8139761> >> >> Thanks, >> Attila. >
