Am 2015-10-20 um 20:28 schrieb Attila Szegedi:
so, is that a +1? :-)
Yes :) I thought about adding a +1 at the end but thought it would be
redundant.
Hannes
On Oct 20, 2015, at 7:11 PM, Hannes Wallnoefer <hannes.wallnoe...@oracle.com>
wrote:
Fair enough. You know the library best and I trust your judgement. Also, it's
not a library built for the casual user, so clean structure may be more
important than simplicity.
Hannes
Am 2015-10-20 um 16:47 schrieb Attila Szegedi:
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.
