On 17/10/2016 22:18, Claes Redestad wrote:
>
>> On 2016-10-17 21:35, Alan Bateman wrote:
>>>
>>> JavaNetHttpCookieAccess, JavaNetInetAddressAccess and
>>> JavaNetSocketAccess are the other 3 that are used to get at non-public
>>> types in java.net so I don't think JavaNetUriAccess would be out of
On 17/10/2016 22:18, Claes Redestad wrote:
On 2016-10-17 21:35, Alan Bateman wrote:
JavaNetHttpCookieAccess, JavaNetInetAddressAccess and
JavaNetSocketAccess are the other 3 that are used to get at non-public
types in java.net so I don't think JavaNetUriAccess would be out of
place.
TIL!
> On Oct 17, 2016, at 2:18 PM, Claes Redestad wrote:
>
> http://cr.openjdk.java.net/~redestad/8168073/webrev.02/
+1
Mandy
> On 17 Oct 2016, at 14:18, Claes Redestad wrote:
>
>
>
> On 2016-10-17 21:35, Alan Bateman wrote:
>>
>>
>> On 17/10/2016 19:45, Claes Redestad wrote:
>>>
>>> Most other SharedSecrets classes seems to be per-package, so not sure
>>> if this case is special enough to start making them per-cl
On 2016-10-17 21:35, Alan Bateman wrote:
On 17/10/2016 19:45, Claes Redestad wrote:
Most other SharedSecrets classes seems to be per-package, so not sure
if this case is special enough to start making them per-class, other
than the slightly more natural naming.
JavaNetHttpCookieAccess, Jav
> On 17 Oct 2016, at 10:53, Claes Redestad wrote:
>
> Hi Paul,
>
> On 2016-10-17 19:39, Paul Sandoz wrote:
>> Hi Claes,
>>
>> This looks good.
>
> Thanks!
>
>>
>> Did you consider adding asserts to the package private constructor?
>
> No, might be reasonable. Do you insist? :-)
>
A gentl
> On Oct 17, 2016, at 11:07 AM, Alan Bateman wrote:
>
>
>
> On 17/10/2016 12:17, Claes Redestad wrote:
>> Hi,
>>
>> one partial cause for startup regressions due to jigsaw is related to
>> creating
>> URIs for the location of each module.
>>
>> By providing a package-private constructor we
On 17/10/2016 19:45, Claes Redestad wrote:
Most other SharedSecrets classes seems to be per-package, so not sure
if this case is special enough to start making them per-class, other
than the slightly more natural naming.
JavaNetHttpCookieAccess, JavaNetInetAddressAccess and
JavaNetSocketAcce
On 2016-10-17 20:07, Alan Bateman wrote:
On 17/10/2016 12:17, Claes Redestad wrote:
Hi,
one partial cause for startup regressions due to jigsaw is related to
creating
URIs for the location of each module.
By providing a package-private constructor we can avoid the time to
scan and
validate
On 17/10/2016 12:17, Claes Redestad wrote:
Hi,
one partial cause for startup regressions due to jigsaw is related to
creating
URIs for the location of each module.
By providing a package-private constructor we can avoid the time to
scan and
validate the URI, which takes a little time (exec
Hi Paul,
On 2016-10-17 19:39, Paul Sandoz wrote:
Hi Claes,
This looks good.
Thanks!
Did you consider adding asserts to the package private constructor?
No, might be reasonable. Do you insist? :-)
/Claes
Paul.
On 17 Oct 2016, at 04:17, Claes Redestad wrote:
Hi,
one partial cause
Hi Paul,
On 2016-10-17 19:39, Paul Sandoz wrote:
Hi Claes,
This looks good.
Thanks!
Did you consider adding asserts to the package private constructor?
No, might be reasonable. Do you insist? :-)
/Claes
Paul.
On 17 Oct 2016, at 04:17, Claes Redestad wrote:
Hi,
one partial cause
Hi Claes,
This looks good.
Did you consider adding asserts to the package private constructor?
Paul.
> On 17 Oct 2016, at 04:17, Claes Redestad wrote:
>
> Hi,
>
> one partial cause for startup regressions due to jigsaw is related to creating
> URIs for the location of each module.
>
> By pr
Hi,
one partial cause for startup regressions due to jigsaw is related to
creating
URIs for the location of each module.
By providing a package-private constructor we can avoid the time to scan
and
validate the URI, which takes a little time (executes ~80K bytecodes)
but also
pushes various
14 matches
Mail list logo