so, is that a +1? :-)
> 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.
>