> On Mar 23, 2018, at 7:51 AM, Stephen Colebourne wrote:
>
> Without being able to insist that a library is on
> the module-path it is also clear that the benefits of strong
> encapsulation and reliable configuration don't apply to library
> consumers.
Why would a framework author ever want to
> On Jul 28, 2016, at 8:09 AM, Stephen Colebourne wrote:
>
> As I have shown, in most libraries,
> 90%+ of the packages need to be exposed - hiding packages is the
> minority/specialist use case (the JDK is unusual in the packages it
> wants to hide).
FWIW with jboss modules we ended up with a
> On Jul 27, 2016, at 10:15 PM, David Holmes wrote:
>
> On 28/07/2016 1:52 AM, Stephen Colebourne wrote:
>> On 27 July 2016 at 16:26, Remi Forax wrote:
>>> to get back to our issue,
>>> there are 4 possibilities when exporting a package, for a public type,
>>> (1) don't see it at compile time,
> On Jul 28, 2016, at 1:11 PM, Alan Bateman wrote:
>
> On 28/07/2016 19:04, Jason T. Greene wrote:
>
>> :
>> Wow! That's very unfortunate. If there's no way to correlate a source
>> snapshot to an OpenJDK binary; that's going to be a very strong motivator
>> for using a thirdparty build.
>>
> On Jul 26, 2016, at 4:50 PM, Paul Benedict wrote:
>
> Okay, I accept your scenario for what it is. You created a very nice
> example to illustrate your point where everything must be one, but you know
> not every project is like this. The whole discussion with Joda Time was
> based on having a
> On Jul 21, 2016, at 3:45 PM, Alan Bateman wrote:
>
> Just a few comments on the examples posed in the last mail.
Thanks!
>
>
> On 21/07/2016 18:01, Jason Greene wrote:
>> :
>> That would help, but there is also class visibility issues that would ne
> On Jul 21, 2016, at 12:01 PM, Jason Greene wrote:
>
>
>> On Jul 18, 2016, at 4:30 PM, mark.reinh...@oracle.com wrote:
>>
>
> Hi Mark, Thanks for the reply. I have snipped out portions to make it easier
> to follow the thread.
>
>>>
>>>
> On Jul 18, 2016, at 4:30 PM, mark.reinh...@oracle.com wrote:
>
Hi Mark, Thanks for the reply. I have snipped out portions to make it easier to
follow the thread.
>>
>> I agree they are certainly intermixed elements of a system, but I’d also
>> argue IoC is pervasive in SE applications as we
> On Jul 14, 2016, at 5:07 PM, John Rose wrote:
>
> On Jul 14, 2016, at 4:51 AM, Andrew Haley wrote:
>>
>> Forgive me if I've missed something, but
>> #ReflectiveAccessToNonExportedTypes does not deal with the need to
>> make fields or methods accessible to the framework. That's what
>> setAc
> On Jul 14, 2016, at 4:56 AM, Stephane Epardaud wrote:
>
> So how about a Java Language annotation (say, @RequiresExport) that we could
> place on IoC framework annotation definitions (say, @Entity, from JPA) that
> would tell the compiler that any type annotated with @Entity must be exported
> On Jul 13, 2016, at 4:47 PM, mark.reinh...@oracle.com wrote:
>
> Jason -- thanks for your feedback on this topic.
Hi Mark,
Thanks for you reply! My thoughts are inline. I apologize in advance for the
length/verbosity. Also, as a general disclaimer, I realize that you are all
experts; in man
> On Jul 7, 2016, at 5:31 PM, Paul Benedict wrote:
>
> If this restriction stays (and I am really hoping it doesn't), my next best
> hope is for Containers like WildFly, Tomcat, SpringBoot etc. to enable me to
> do this. If the Layer has a hook into amending the Module Descriptor, then I
> am
> On Jul 7, 2016, at 5:10 PM, Alex Buckley wrote:
>
> Hi Jason,
Hi Alex,
Thank you for the thoughtful reply, I have included some debate below.
>
> On 7/7/2016 1:17 PM, Jason Greene wrote:
>> I wanted to second Paul’s comments on jams-spec-comments[1], but with
>&g
I wanted to second Paul’s comments on jams-spec-comments[1], but with some
additional thoughts.
The proposal takes a step in the right direction by allowing a runtime path to
bypass access control. However, the fundamental issue at play is that class
visibility is being used as an access contro
14 matches
Mail list logo
