Hi Roger,
It wasn't entirely clear to me from the docs if extending the time would
impact the expected running time of the text on an otherwise unloaded
system.
The current version looks fine.
Thanks,
-Joe
On 3/29/2016 8:24 AM, Roger Riggs wrote:
Hi Joe,
ok, my thought was that extending
Hi Peter, Mandy,
On 2016-03-26 12:47, Peter Levart wrote:
Comparing this with proposed code from webrev:
493 try {
494 return (ClassBoundMethodHandle>)
495 Class.forName("java.lang.invoke.BoundMethodHandle$Species_" +
LambdaForm.shortenSi
FYI for denizens of core-libs-dev:
I've posted a set of proposed changes to the @Deprecated annotation to jdk9-dev.
Please see the following review thread:
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-March/003917.html
Thanks,
s'makrs
+1
> On Mar 29, 2016, at 3:35 PM, Mandy Chung wrote:
>
> This test should be excluded until JDK-8150975 is resolved. It’s currently
> commented out in ProblemList which was unintentional.
>
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/Pro
This test should be excluded until JDK-8150975 is resolved. It’s currently
commented out in ProblemList which was unintentional.
diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -443,7 +443,7 @@
# core_tools
# 8150975
-# tools/
> On Mar 29, 2016, at 12:15 PM, joe darcy wrote:
>
> Hi Mandy,
>
> On 3/28/2016 8:48 PM, Mandy Chung wrote:
>>> On Mar 28, 2016, at 5:03 PM, Joseph D. Darcy wrote:
>>>
>>> Hello,
>>>
>>> New iteration of the webrev updated after the Jigsaw integration and
>>> incorporating the earlier feedb
Hi Mandy,
On 3/28/2016 8:48 PM, Mandy Chung wrote:
On Mar 28, 2016, at 5:03 PM, Joseph D. Darcy wrote:
Hello,
New iteration of the webrev updated after the Jigsaw integration and
incorporating the earlier feedback.
http://cr.openjdk.java.net/~darcy/8151763.1
# tools/jimage/JImageTest.
On 29/03/2016 16:38, Sundararajan Athijegannathan wrote:
Hi,
Please review http://cr.openjdk.java.net/~sundar/8148491/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8148491
This looks to me. A minor nit in TaskHelper.getPluginsConfig where
removing genbom leaves a ) in mid air.
-A
Hello!
After the fix for JDK-8148748 went in, I needed to rebase the fix.
Comparing to the previous webrev, the changes are local to
ArrayList.spliterator().
http://cr.openjdk.java.net/~igerasim/8079136/09/webrev/
The builds/tests are green.
With kind regards,
Ivan
On 03.02.2016 22:16, Iv
On 3/29/2016 12:21 AM, Alan Bateman wrote:
On 28/03/2016 23:46, huizhe wang wrote:
Thanks David. So I understand the dynamic nature of the server
configuration. There maybe two options to solve it:
1) Add a system property to point to a Layer in order to find an
alternative-system-default.
Actually I think most use the AE1 (2003) and AE2 (2004) of „recent“ ZIP
Archivers, not the legazy PKZip Version.
It would be an Option to only Support those (however given the unclear
Standardisation in this area i Can understand it does not Show up in sdk Code,
there are quite good alternativ
Thanks Vladimir!
/Claes
On 2016-03-29 18:27, Vladimir Ivanov wrote:
Reviewed.
Best regards,
Vladimir Ivanov
On 3/29/16 2:47 PM, Claes Redestad wrote:
Hi,
the reverse of Recipe.elements is calculated eagerly but only used once
and only by
some strategies. Removing this might also help a bit
Reviewed.
Best regards,
Vladimir Ivanov
On 3/29/16 2:47 PM, Claes Redestad wrote:
Hi,
the reverse of Recipe.elements is calculated eagerly but only used once
and only by
some strategies. Removing this might also help a bit with footprint if
run with caching
enabled.
Bug: https://bugs.openjdk.
+1
> On Mar 29, 2016, at 12:38 PM, Sundararajan Athijegannathan
> wrote:
>
> Hi,
>
> Please review http://cr.openjdk.java.net/~sundar/8148491/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8148491
>
> Thanks,
> -Sundar
Hi,
Please review http://cr.openjdk.java.net/~sundar/8148491/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8148491
Thanks,
-Sundar
Hi Joe,
ok, my thought was that extending the time out didn't affect the running
time of the test
and since the signal is handled by a separate thread a busy system might
be the cause.
I removed the re-raise of the signal so the test will fail if the signal
is not received
even after the long
Hi Per,
On 03/29/2016 04:03 PM, Per Liden wrote:
Hi Peter,
On 2016-03-28 19:18, Peter Levart wrote:
[...]
And now a few words about ReferenceHandler thread and synchronization
with it (for Kim and Per mostly). I think it should not be a problem to
move the following two java.lang.ref.Reference
Hi Nadeesh,
Looks good
Thanks, Roger
On 3/29/2016 8:12 AM, nadeesh tv wrote:
Hi Roger,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8030864/webrev.08/
Regards,
Nadeesh
On 3/11/2016 9:19 PM, Roger Riggs wrote:
Hi Nadeesh,
Thanks for filling in the missing DateTimeException
Hi Peter,
On 2016-03-28 19:18, Peter Levart wrote:
[...]
And now a few words about ReferenceHandler thread and synchronization
with it (for Kim and Per mostly). I think it should not be a problem to
move the following two java.lang.ref.Reference methods to native code if
desired:
static Re
On 2016-03-29 13:52, Aleksey Shipilev wrote:
On 03/29/2016 02:47 PM, Claes Redestad wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8152951
Webrev: http://cr.openjdk.java.net/~redestad/8152951/webrev.01/
Still good.
-Aleksey
Thanks!
/Claes
Looks good,
Thanks, Roger
On 3/29/2016 8:15 AM, nadeesh tv wrote:
Hi all,
Please see the doc changes
http://cr.openjdk.java.net/~ntv/8148950/webrev.00/
Bug ID https://bugs.openjdk.java.net/browse/JDK-8148950
On 25/03/2016 18:46, Chris Hegarty wrote:
Take 2.
InvalidJarIndexException is thrown when an index is corrupt. It is a useful
piece of
information that the deployment of the jar files, on the class path, with
indices, are
"bad". It is really an Error. It indicates a serious problem with the
d
We're almost there, but looking at the tests, it looks like the
behaviour is wrong:
The intended behaviour is that
-20.5mins (minus 20 minutes 30 secs) should truncate to -20mins
-2.1secs truncate to -2secs
Note that the truncation is different to Instant here.
An Instant truncates towards the fa
+1
Stephen
On 29 March 2016 at 13:15, nadeesh tv wrote:
> Hi all,
>
> Please see the doc changes
> http://cr.openjdk.java.net/~ntv/8148950/webrev.00/
> Bug ID https://bugs.openjdk.java.net/browse/JDK-8148950
>
> --
> Thanks and Regards,
> Nadeesh TV
>
Hi all,
Bug Id : https://bugs.openjdk.java.net/browse/JDK-8148849
Enhanced Duration by adding public Duration truncatedTo(TemporalUnit unit)
Please http://cr.openjdk.java.net/~ntv/8148849/webrev.00/
--
Thanks and Regards,
Nadeesh TV
Hi all,
Please see the doc changes
http://cr.openjdk.java.net/~ntv/8148950/webrev.00/
Bug ID https://bugs.openjdk.java.net/browse/JDK-8148950
--
Thanks and Regards,
Nadeesh TV
Hi Roger,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8030864/webrev.08/
Regards,
Nadeesh
On 3/11/2016 9:19 PM, Roger Riggs wrote:
Hi Nadeesh,
Thanks for filling in the missing DateTimeException cases.
- src/java.base/share/classes/java/time/chrono/IsoChronology.java:
" * @
This could also be fine, assuming that using the exception doesn't incur
any kind of major performance degradation (e.g. I could make a subclass
that suppresses fillInStackTrace(), and hopefully that will suffice to
avoid any major costs). It falls under the class of fixes that requires
that o
On 03/29/2016 02:47 PM, Claes Redestad wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8152951
> Webrev: http://cr.openjdk.java.net/~redestad/8152951/webrev.01/
Still good.
-Aleksey
Hi,
the reverse of Recipe.elements is calculated eagerly but only used once
and only by
some strategies. Removing this might also help a bit with footprint if
run with caching
enabled.
Bug: https://bugs.openjdk.java.net/browse/JDK-8152951
Webrev: http://cr.openjdk.java.net/~redestad/8152951/w
On 29/03/2016 10:55, Andrew Haley wrote:
:
I'm sure that's right. However, we are also running the risk of
breaking important use cases when JDK9 is released. We're going to
have to do a lot of work with developers to make sure that they can
still work with JDK9. The problem is that many devel
On 28 March 2016 at 22:41, Xueming Shen wrote:
> It's a tricky call. To be honest, as I said at the very beginning, I'm not
> sure whether
> or not it's a good idea and worth the efffort to push this into the j.u.zip
> package to
> support the "traditional PKWare encryption", which is known to be
On 29/03/16 08:21, Alan Bateman wrote:
> The devil is in the detail of course. You haven't said if the
> FinderDelegate implementation has to be visible via the system class loader.
>
> I think the main thing is to tread carefully and it would be very easy
> to introduce a troublesome mis-featur
Hi Xueming,
I'm Tomoyuki from NTT Data.
I was invited by Yasumasa because
we strongly want this feature even though it is weak encryption.
The reason is that there are absolutely both requirements
to prevent easy unpacking of zip files from innocents's mis-operation
and to keep the existing usabi
Hi,
An easy way to make ServiceLoader loaded services decide at runtime for
themselves if they want to be enabled or disabled is a little addition
to their behavior. Suppose that a new exception type is defined:
IgnoreServiceException. When this exception is thrown from the
constructor of the
Dear Sherman,
I got this error when I run some test code on Java 9-ea+111 (can't use Java 8,
since java/lang/invoke/StringConcatFactory is used in the code).
> Exception in thread "main" java.lang.IllegalAccessError: class
> jdk.java.util.regex.Pattern (in unnamed module @0xeec5a4a) cannot acce
On 28/03/2016 23:46, huizhe wang wrote:
Thanks David. So I understand the dynamic nature of the server
configuration. There maybe two options to solve it:
1) Add a system property to point to a Layer in order to find an
alternative-system-default. This will add a new step to the JAXP
proces
37 matches
Mail list logo
