On 13 September 2016 at 21:04, wrote:
> 2016/9/12 15:08:41 -0700, Stephen Colebourne :
>> My preference of these three options is option 2.
>
> Sorry if I wasn't clear, but this isn't meant to be a "choose one"
> proposal. It's a set of check boxes, not radio buttons. The proposal
> is to imple
2016/9/12 15:08:41 -0700, Stephen Colebourne :
> My preference of these three options is option 2.
Sorry if I wasn't clear, but this isn't meant to be a "choose one"
proposal. It's a set of check boxes, not radio buttons. The proposal
is to implement suggestions (2) and (3) of your original comm
Anyone who cares about grammar would know "requires optional" is awkward
(and horrible) English. It's an oxymoron. It's non-nonsensical.
Since this is all about dependencies, why not be straightforward like this:
dependency requires foo.bar1;
dependency optional foo.bar2;
NB: I did once submit a
+1 for "requires optional"
On Tue, Sep 13, 2016 at 2:29 AM, Stephen Colebourne
wrote:
> On 11 September 2016 at 22:24, wrote:
> > Proposals for the following issues have been available for evaluation
> > and experimentation for quite a while now. Most responses have been
> > positive and ther
On 13/09/16 15:40, Alan Bateman wrote:
> On 13/09/2016 15:28, Andrew Dinn wrote:
> We have a number of patches coming that will align the implementation
> with the current proposals and expect to have EA builds shortly too.
Excellent! Thanks for the very quick response.
regards,
Andrew Dinn
---
On 13 September 2016 at 07:33, Sander Mak wrote:
>> Here is my counter proposal, hopefully a
>> relatively small conceptual change:
>
> Not sure whether introducing a new top-level keyword (exposes) is better than
> adding a modifier keyword to exports. As was the case with `exports dynamic`,
>
On 13/09/2016 15:28, Andrew Dinn wrote:
:
The immediate question is
1) Will the agent be able add an export relationship
M exports private P to M'
Yes.
The bonus question is essentially the same as the first but in a
slightly different circumstance. Let us instead assume that module M
c
Looks good.
Mandy
> On Sep 13, 2016, at 2:41 AM, Sundararajan Athijegannathan
> wrote:
>
> Modified existing test to check quotes around properties added by jlink:
>
> Updated webrevs:
>
> jdk:
>
> http://cr.openjdk.java.net/~sundar/8163320/jdk/webrev.02/
>
> Top:
>
> http://cr.openjdk.ja
I understand the motivation for this change from the point of view of
normal application operation. It looks to me to be in many ways an
improvement on the previous proposal (dynamic exports). However, I don't
really know whether it is adequate to the needs of middleware. So, I
will leave it up to
Hello,
I've updated the patch to the current situation. The top-level
repository patch is here:
http://cr.openjdk.java.net/~jlahoda/8153362/top-level.03/
Langtools repository patch is here:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.04-phase2/
Does this look OK?
Thanks,
Jan
O
Modified existing test to check quotes around properties added by jlink:
Updated webrevs:
jdk:
http://cr.openjdk.java.net/~sundar/8163320/jdk/webrev.02/
Top:
http://cr.openjdk.java.net/~sundar/8163320/top/webrev.02/
Thanks
-Sundar
On 9/9/2016 9:07 PM, Mandy Chung wrote:
> Looks good.
>
> I
Another +1 for the return of dynamic exports. Frameworks using reflection
are such a common case that if dynamic exports are not available, users
will either create weak modules for all their code, or they have to export
packages that they would rather not export. While "dynamic export" is still
no
12 matches
Mail list logo
