Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`

[Nicolai Parlog]

 Hi Sven,

yes, I was not very precise. The "problem" (in scare quotes because it
is only a problem to the JPMS) with Hibernate is exactly that it is
"only" an implementation, which we should be able to replace with any
other at link time.

So modules should of course not have to "export to Hibernate". This
was the original problem with qualified exports.

The current proposal will fix this by allowing me to export to anybody
but at run time only, which will keep people from depending on it at
compile time.

 so long ... Nicolai



On 01.07.2016 11:34, Sven Reimers wrote:
> The point was if you want to limit reflective access to special
> modules you would need some kind of alias or token as the target of
> your export, e.g. jpa and not hibernate.
> 
> If dynamic export is not limited, all is fine - agreed.
> 
> Sven Am 01.07.2016 10:49 schrieb "Sander Mak"
> <sander.mak at luminis.eu>:
> 
>> 
>>> On 01 Jul 2016, at 10:41, Sven Reimers <sven.reimers at gmail.com>
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> regarding exporting DTO to hibernate..
>>> 
>>> I think the whole point of having JPA is to not have explicit
>>> dependency
>> to
>>> hibernate..
>> 
>> Hence the proposal for `exports dynamic`, where you don't have to
>> qualify the export to a certain module. The relation between the
>> DTO module and JPA would be expressed by having a `requires jpa`
>> (or whatever module the spec annotations will live in). The
>> `dynamic` part makes sure no other modules take an accidental
>> dependency on your DTOs (if that's what you want) at 
>> compile-time. All sounds good to me.
>> 
>> 
>> Sander
>> 
>> 
> 

-- 

PGP Key:
    http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509

Web:
    http://codefx.org
        a blog about software development
    http://do-foss.de
        Free and Open Source Software for the City of Dortmund

Twitter:
    https://twitter.com/nipafx