On 9/12/14 1:55 PM, Peter Levart wrote:
On 09/12/2014 12:45 PM, Daniel Fuchs wrote:
However the listeners are to be invoked in the same order they have been
added.
I am still unconvinced this is worth the additional
complexity it would bring to the implementation.
The deprecated methods were
On 9/12/14 2:37 PM, Alan Bateman wrote:
On 12/09/2014 11:45, Daniel Fuchs wrote:
I am still unconvinced this is worth the additional
complexity it would bring to the implementation.
The deprecated methods were using HashMap to store listeners,
and therefore the order in which listeners were
Thanks Alan!
I have updated the webrev with your suggestions:
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
-- daniel
On 9/12/14 3:54 PM, Alan Bateman wrote:
On 12/09/2014 14:38, Daniel Fuchs wrote:
Would modifying the specification of addConfigurationListener()
as follows
On 9/12/14 4:42 PM, Alan Bateman wrote:
On 12/09/2014 15:16, Daniel Fuchs wrote:
Thanks Alan!
I have updated the webrev with your suggestions:
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
-- daniel
A minor suggestion for readConfiguration is that "Any register
configur
configuration changes
CC: core-libs-dev@openjdk.java.net
On 9/12/14 4:42 PM, Alan Bateman wrote:
On 12/09/2014 15:16, Daniel Fuchs wrote:
Thanks Alan!
I have updated the webrev with your suggestions:
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
-- daniel
A minor suggestion for
ment for the API that allowed to
listen for LogManager configuration changes
CC: core-libs-dev@openjdk.java.net
On 9/12/14 4:42 PM, Alan Bateman wrote:
On 12/09/2014 15:16, Daniel Fuchs wrote:
Thanks Alan!
I have updated the webrev with your suggestions:
http://cr.openjdk.java.net/~dfuchs/webrev
On 9/16/14 1:12 PM, Pavel Rappo wrote:
Hi everyone,
Could you please review my change for JDK-8044627?
http://cr.openjdk.java.net/~prappo/8044627/webrev.00/
-Pavel
Hi Pavel,
Given that helper.loadClass uses the context class loader,
Should you also simply use
ServiceLoader loader =
Done.
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.06
On 9/16/14 3:56 PM, Alan Bateman wrote:
On 15/09/2014 17:03, Daniel Fuchs wrote:
:
Here is a new webrev - with updated test case:
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.05/
I think this quite good now
On 9/16/14 4:14 PM, Pavel Rappo wrote:
Daniel,
Given that helper.loadClass uses the context class loader,
Should you also simply use
ServiceLoader loader =
ServiceLoader.load(InitialContextFactory.class);
at lines 680-681 ?
It needs to be the system class loader to allo
#addSuppressed(java.lang.Throwable)
* suppressed exceptions}.
best regards,
-- daniel
On 16/09/14 17:31, Daniel Fuchs wrote:
Done.
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.06
On 9/16/14 3:56 PM, Alan Bateman wrote:
On 15/09/2014 17:03, Daniel Fuchs wrote:
:
Here is a new
Hi,
Please find below a patch for [1]
8059269: FileHandler may throw NPE if pattern is a simple name and
the lock file already exists
[1] https://bugs.openjdk.java.net/browse/JDK-8059269
The webrev is here:
http://cr.openjdk.java.net/~dfuchs/webrev_8059269/webrev.00
This is a regres
On 29/09/14 05:01, Alan Bateman wrote:
On 26/09/2014 19:33, Daniel Fuchs wrote:
Hi,
Please find below a patch for [1]
8059269: FileHandler may throw NPE if pattern is a simple name and
the lock file already exists
[1] https://bugs.openjdk.java.net/browse/JDK-8059269
The webrev is
On 29/09/14 13:42, Alan Bateman wrote:
On 29/09/2014 09:51, Daniel Fuchs wrote:
The files created by the test (both log files and lock files) will be
removed by the finally block at lines 150 - 174 - so the test shouldn't
leave any files open (which I verified by running the test on a JDK
On 29/09/14 15:12, Alan Bateman wrote:
On 29/09/2014 13:53, Daniel Fuchs wrote:
- 233 FileChannel.open(Paths.get(file + ".lck"), CREATE_NEW, WRITE);
- 234 FileChannel.open(Paths.get(file + ".1.lck"), CREATE_NEW, WRITE);
+ 233 FileChannel.open(Paths.get(file + "
Hi,
Please find below a fix for
8025690: Default FileHandler constructor doesn't
throw NullPointerException if pattern is empty and count > 1
https://bugs.openjdk.java.net/browse/JDK-8025690
The default constructor of FileHandler is specified to throw
a NullPointerException if the patt
rds,
-- daniel
Best,
Lance
On Sep 30, 2014, at 10:04 AM, Daniel Fuchs <mailto:daniel.fu...@oracle.com>> wrote:
Hi,
Please find below a fix for
8025690: Default FileHandler constructor doesn't
throw NullPointerException if pattern is empty and count > 1
https://bugs.o
Hi Lance,
On 30/09/14 23:55, Lance Andersen wrote:
On Sep 30, 2014, at 5:20 PM, Daniel Fuchs mailto:daniel.fu...@oracle.com>> wrote:
On 9/30/14 9:09 PM, Lance Andersen wrote:
Shouldn't the other constructors indicate that an NPE will occur
similar to the default constructor if the
Hi Lance,
I probably don't know enough about rowset to qualify as reviewer
for this change, but I had a look at the tests - and I believe
they look good.
I wonder whether there should be some additional tests that would
run with a security manager on?
The only thing unusual I noticed is that the
Hi,
On 19/08/14 16:00, Jason Mehrens wrote:
Stanimir,
Looks like the int overflow on the metered stream is an issue that hasn't been
tracked. The other issues have been reported under
https://bugs.openjdk.java.net/browse/JDK-6433253
and https://bugs.openjdk.java.net/browse/JDK-8028786
Ap
Hi,
Please find below a trivial fix for
8028788: Logger.enterring uses String concatenation in a loop
https://bugs.openjdk.java.net/browse/JDK-8028788
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8028788/webrev.00
best regards
-- daniel
valueOf()
best regards,
-- daniel
Best
Lance
On 7 Oct 2014, at 11:59, Daniel Fuchs mailto:daniel.fu...@oracle.com>> wrote:
Hi,
Please find below a trivial fix for
8028788: Logger.enterring uses String concatenation in a loop
https://bugs.openjdk.java.net/browse/JDK-8028788
w
Hi,
Please find below a patch for:
8059767: FileHandler should allow 'long' limits and handle overflow
of MeteredStream.written.
https://bugs.openjdk.java.net/browse/JDK-8059767
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8059767/webrev.00/
This follows an issue reported on this
On 07/10/14 21:50, Jason Mehrens wrote:
Hi Daniel,
The only thing I noticed is a missing @since tag on the FileHandler.
Oops, thanks for catching that Jason.
-- daniel
Jason
Date: Tue, 7 Oct 2014 15:13:13 +0200
From: daniel.fu...@oracle.com
To:
Sincerely yours,
Ivan
On 07.10.2014 17:13, Daniel Fuchs wrote:
Hi,
Please find below a patch for:
8059767: FileHandler should allow 'long' limits and handle overflow
of MeteredStream.written.
https://bugs.openjdk.java.net/browse/JDK-8059767
webrev:
http://cr.openjd
Hi Konstantin,
I'm not qualified as a (R)eviewer for changes in this area,
but I believe you can do:
HotSpotDiagnosticMXBean mbean =
ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class);
to get a handle on the MBean. You don't need to go through
the MBeanServer and newPlatform
Hi,
Please find below a fix for:
8042147: test sun/util/logging/SourceClassName.java failed:
Unexpected source: java.util.Currency info
https://bugs.openjdk.java.net/browse/JDK-8042147
webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8042147/webrev.00/
It seems that something
Thanks Jason.
I wonder if that may be another issue. Interesting. I'll see if I can
work out a test case
for that tomorrow. With the test case provided in the bug - tested on 7,
8, and 9,
the only file that remained at the end was 'log' (which is as it should
be - and I ran
the test case seve
alled.
best regards,
-- daniel
Stanimir
On Thu, Oct 9, 2014 at 4:59 PM, Daniel Fuchs mailto:daniel.fu...@oracle.com>> wrote:
Thanks Jason.
I wonder if that may be another issue. Interesting. I'll see if I
can work out a test case
for that tomorrow. With the test ca
, though (ext3 [concurrently] deleting large files
for example).
Stanimir
On Thu, Oct 9, 2014 at 4:59 PM, Daniel Fuchs mailto:daniel.fu...@oracle.com>> wrote:
Thanks Jason.
I wonder if that may be another issue. Interesting. I'll see if I
can work out a test case
wards suggesting that the LogManager should hold a strong
reference on the loggers for which a Handler is explicitly
configured in the configuration file. It would ensure that
these loggers are still around when reset() is called.
best regards,
-- daniel
Stanimir
On Thu, Oct 9, 2014 at 4:
On 10/10/14 16:36, Stanimir Simeonoff wrote:
The Handler automatic closure remains problematic as they don't have a
defined lifecycle. close() should be invoked after there are no
references and it requires calling a potentially overridden method. It
can be carried by PhantomReference+WeakRefence
Hi,
Please find below a possible fix for:
8060132: Handlers configured on abstract nodes in logging.properties are
not always properly closed
https://bugs.openjdk.java.net/browse/JDK-8060132
webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.00/
Other options have been discusse
not new but it's a good time to get it straight).
Agreed.
http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.01
best regards, and thanks for all the valuable inputs & comment from
you and Jason - I really appreciate it :-)
-- daniel
Cheers
Stanimir
On Fri, Oct 10, 2014 at 5:51 PM, Dani
et/~dfuchs/webrev_8059767/webrev.02
I also logged JDK-8060457 to follow up and cleanup that in
all handlers subclasses (no impact on the actual
implementation / behavior - it's just cleanup).
Attempting the cleanup in this fix was just too much noise.
best regards,
-- daniel
On 08/10/14 11:4
n 14/10/2014 14:34, Daniel Fuchs wrote:
Hi Pavel,
I saw your mail on build-dev.
I guess the issue will resolve itself once we have the
modular image.
I wonder whether the way to go for now would be
to add a single META-INF/services file - as you suggest -
in java.naming, with the 4 lines inside
then the LogManager will not add the logger to the
persistentLoggers list.
Do you think we should do that?
best regards,
-- daniel
On 10/24/14 8:31 PM, Mandy Chung wrote:
On 10/10/2014 8:39 AM, Daniel Fuchs wrote:
http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.01
Sorry for the dela
.
http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.02/
best regards,
-- daniel
On 24/10/14 23:50, Daniel Fuchs wrote:
Hi Mandy,
Is this only problem to the abstract node of Loggers (i.e. the ancestor
is in the logging configuration but the library/app never creates such
a logger)?
No
ot;,
defaultValue);
So 'true' would instead be the default of the default...
-- daniel
Stanimir
On Tue, Nov 4, 2014 at 6:48 PM, Daniel Fuchs mailto:daniel.fu...@oracle.com>> wrote:
Hi,
Here is a revised patch that introduces a new
.handlers
On 04/11/14 23:40, Mandy Chung wrote:
On 11/4/14 8:48 AM, Daniel Fuchs wrote:
Hi,
Here is a revised patch that introduces a new
.handlers.ensureCloseOnReset=true|false
property.
You have explored several different options and as you have found,
none of them is ideal. I think having a
Hi Mandy, Stanimir,
Here is the new webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.03/index.html
best regards,
-- daniel
On 05/11/14 12:47, Daniel Fuchs wrote:
On 04/11/14 23:40, Mandy Chung wrote:
On 11/4/14 8:48 AM, Daniel Fuchs wrote:
Hi,
Here is a revised patch that
om>> wrote:
Hi Mandy, Stanimir,
Here is the new webrev:
http://cr.openjdk.java.net/~__dfuchs/webrev_8060132/webrev.__03/index.html
<http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.03/index.html>
best regards,
-- daniel
On 05/11/14 12:47, Daniel Fuc
On 07/11/14 07:42, Mandy Chung wrote:
On 11/5/2014 8:15 AM, Daniel Fuchs wrote:
Here is the new webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.03/index.html
Looks good. Minor nits and no need to generate new webrev.
line 108: {@linkplain #reset} -- # is missing.
line 918
Hi,
Please find below a trivial fix for
8065138: Encodings.isRecognizedEnconding sometimes fails to
recognize 'UTF8'
https://bugs.openjdk.java.net/browse/JDK-8065138
webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8065138/webrev.00/
The root of the issue is with
jaxp/src/java.xml/sh
Hi Aleksey,
On 19/11/14 13:02, Aleksey Shipilev wrote:
Can you also look if these files are corrupted in your build as well?
$ grep --include=\*.java --include=\*.properties -R --color='auto' -n -v
-e "^[[:alnum:][:punct:][:space:]]*$"
I see more hits in jdk/ within java.desktop and java.xml.c
On 19/11/14 18:01, Martin Buchholz wrote:
On Wed, Nov 19, 2014 at 3:17 AM, Daniel Fuchs wrote:
Hi,
Please find below a trivial fix for
8065138: Encodings.isRecognizedEnconding sometimes fails to
recognize 'UTF8'
https://bugs.openjdk.java.net/browse/JDK-8065138
we
issue. 'sed' doesn't like the special character.
-- daniel
Mandy
[1] http://openjdk.java.net/jeps/220
On 11/19/2014 10:15 AM, Daniel Fuchs wrote:
Isn't that a bug in the build system that really ought to be fixed?
If properties files are to be stored as resources in ja
On 11/20/14 12:11 AM, Martin Buchholz wrote:
On Wed, Nov 19, 2014 at 3:17 AM, Daniel Fuchs wrote:
The Encodings.properties file ends up truncated in resources.jar - it
contains only one line (the line before the special character was
encountered).
If there's an error in the build resulti
ote:
On 11/19/2014 4:09 PM, Mandy Chung wrote:
On 11/19/2014 3:49 PM, Mandy Chung wrote:
On 11/19/2014 12:50 PM, Daniel Fuchs wrote:
On 11/19/14 9:36 PM, Mandy Chung wrote:
resources.jar will be gone when we move to the modular runtime
image
(JEP 220 [1]).
JDK-8065138 and JDK-8065365 will bec
-e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@
+-e 's/\\=/=/' \
+| $(SORT) > $$@
$(CHMOD) -f ug+w $$@
# And do not forget this target
I filed a separate issue [1] for investigating the use of pipefail.
/Erik
[1] https://bugs.openjdk.java.net
On 24/11/14 10:19, Janda Martin wrote:
Hi,
I found regression in latest Java 8u40 b15 linux x64. There is missing
internal class in JDK. Submitted as bug with Review ID: 9048260.
Hi Martin,
This should now have been fixed in the jdk8u-dev forest by
https://bugs.openjdk.java.net/browse/JDK
On 24/11/14 11:44, Erik Joelsson wrote:
Hello Daniel,
Test seems like a great idea. Thanks!
OK - I have logged JDK-8065748
https://bugs.openjdk.java.net/browse/JDK-8065748
I'll send a patch for review when your fix is in :-)
Thanks!
-- daniel
/Erik
On 2014-11-20 18:25, Daniel
Hi,
Please find below a small webrev that adds a trivial sanity
test to CheckEncodingPropertiesFile.java
http://cr.openjdk.java.net/~dfuchs/webrev_8065748/webrev.00
This is as a followup of Joel's fix for
https://bugs.openjdk.java.net/browse/JDK-8065138
best regards,
-- daniel
istaken on the meaning of @bug ?
best regards,
-- daniel
Best,
Joe
On 11/24/2014 3:30 AM, Daniel Fuchs wrote:
Hi,
Please find below a small webrev that adds a trivial sanity
test to CheckEncodingPropertiesFile.java
http://cr.openjdk.java.net/~dfuchs/webrev_8065748/webrev.00
This is as a f
Hi,
Please find below a patch for:
8065991: LogManager unecessarily calls JavaAWTAccess from within
a critical section
https://bugs.openjdk.java.net/browse/JDK-8065991
Webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8065991/webrev.00/
Note: https://bugs.openjdk.java.net/browse/JDK-8
Looks good Lance.
I had to stare at the diff for a while before seeing it ;-)
best regards,
-- daniel
On 01/12/14 17:04, Lance Andersen wrote:
Hi all,
Looking for a reviewer for this trivial typo in Connection.isValid
hg diff
diff -r f619341171c0 src/java.sql/share/classes/java/sql/Connecti
Hi,
Please find below a patch for:
8065552: setAccessible(true) on fields of Class may throw
a SecurityException
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8065552/webrev.00/
Description of the problem:
The following test case passes on 8u20 but fails on 8u40 and above:
publ
expected and that we don't hit this issue
again ? It might be some
what of a heavy test for jtreg inclusion though.
It could be worth a try. But let's wait until JEP 220 is in.
best regards,
-- daniel
regards,
Sean.
On 01/12/14 16:29, Daniel Fuchs wrote:
Hi,
Please find below a
best regards,
-- daniel
On 01/12/14 19:50, Mandy Chung wrote:
On 12/1/14 8:29 AM, Daniel Fuchs wrote:
8065552: setAccessible(true) on fields of Class may throw
a SecurityException
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8065552/webrev.00/
Thanks for taking this on. Looks ok
Hi Mandy,
On 02/12/14 20:24, Mandy Chung wrote:
Hi Daniel,
On 11/26/14 9:11 AM, Daniel Fuchs wrote:
Hi,
Please find below a patch for:
8065991: LogManager unecessarily calls JavaAWTAccess from within
a critical section
https://bugs.openjdk.java.net/browse/JDK-8065991
Webrev:
http
Hi,
This is a review for a new test which has a different
implementation for JDK 8 & JDK 9
During the review of
JDK-8065552: setAccessible(true) on fields of Class may throw
a SecurityException,
it was remarked that such a test would be useful.
So here is such a test that loads all
Hi David,
On 12/4/14 4:37 AM, David Holmes wrote:
Hi Daniel,
Once clarification please ...
On 4/12/2014 8:47 AM, Daniel Fuchs wrote:
Hi,
This is a review for a new test which has a different
implementation for JDK 8 & JDK 9
During the review of
JDK-8065552: setAccessible(true) on field
e end (test.list.classes, false by default).
Thanks for your question, it triggered me into looking deeper
into what was happening :-)
best regards,
-- daniel
On 04/12/14 10:05, Daniel Fuchs wrote:
The differences between 8 & 9 are limited to:
- ClassLoader:
- on 8 we use 'n
On 04/12/14 13:06, David Holmes wrote:
Hi Daniel,
On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
Hi David,
In fact I could use 'null' on JDK 9 as well.
My first version of the JDK 9 test was parsing over all the .jimage
files under /lib/modules - which explain why I needed to
use the Sy
uot;test/java/lang/Class/" - it can be moved when
the time comes.
Agreed as well :-)
Here is a new revision of the webrev for 9 in which I have
incorporated David's comment:
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/
best regards,
-- daniel
regards,
Sean.
On
5/12/2014 3:13 AM, Daniel Fuchs wrote:
On 04/12/14 14:02, Seán Coffey wrote:
Thanks for driving efforts in this area Daniel. I think it's a very
useful test and is bound to help test code coverage. If it's currently
passing on all JPRT platforms, it's a good measure.
It seems t
Hi Peter,
On 12/6/14 11:16 AM, Peter Levart wrote:
On 12/05/2014 09:06 PM, Daniel Fuchs wrote:
Hi David, all,
@David: You're right David.
The loader parameter is never used - I have removed it.
@all: I have received a comment from Alan that it would be better to use
th
On 12/12/14 10:34 PM, Martin Buchholz wrote:
Hi Joe, Lance, Roger,
Fix ALL the stutters!
https://bugs.openjdk.java.net/browse/JDK-8067377
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/double-trouble/
Hi Martin,
Impressive! There may still be a typo in the one below:
diff --git
a/src
Hi guys,
Do I have approval to push the latest version of the test for JDK 9:
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
or are there still some objections?
best regards,
-- daniel
On 06/12/14 11:44, Daniel Fuchs wrote:
Hi Peter,
On 12/6/14 11:16 AM, Peter Levart
Hi David,
On 12/16/14 6:20 AM, David Holmes wrote:
On 16/12/2014 3:48 AM, Daniel Fuchs wrote:
Hi guys,
Do I have approval to push the latest version of the test for JDK 9:
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
or are there still some objections?
My objections
On 16/12/14 11:34, Daniel Fuchs wrote:
Here is a new version where I have removed all the 'ClassLoaders' stuff.
After all
it was not instrumental to the test. Is that good to go?
Forgot the link:
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.03/
sorry for
Hi Katja,
Sorry for not thinking of that when I replied earlier.
Your new test is so much more readable than the old shell
script :-)
These are minor suggestions but they might help analysis
if the test fails:
On 17/12/14 10:10, Yekaterina Kantserova wrote:
Hi,
Thanks for all reviews!
The n
efully
leave time enough for the while loop to take two histograms. Simply
adding the extra condition to keep looping until we have at least two
should do the trick.
best regards, and thanks again for taking care of 6977426!
-- daniel
// Katja
On 12/17/2014 10:55 AM, Daniel Fuchs wrote:
Hi Katja
enough
even for slower configurations.
Good suggestion. I should have thought of that :-)
The new webrev can be found here:
http://cr.openjdk.java.net/~ykantser/6977426/webrev.02/
Thumbs up from me!
cheers,
-- daniel
// Katja
On 12/17/2014 12:33 PM, Daniel Fuchs wrote:
On 17/12/14 12
On 04/01/15 18:58, Peter Levart wrote:
Hi,
While investigating the following issue:
https://bugs.openjdk.java.net/browse/JDK-8029891
I noticed there's a bug in deserialization code of java.util.Hashtable
(from day one probably):
https://bugs.openjdk.java.net/browse/JDK-8068427
The
Interesting... I would have expected it to throw
java.util.ConcurrentModificationException right
away, but it only does so if the list contains
exactly 1 or more than 2 elements...
best regards,
-- daniel
On 07/01/15 10:45, Remi Forax wrote:
A simple Java question, what this code does ?
A
On 07/01/15 11:31, Paul Sandoz wrote:
On Jan 7, 2015, at 10:45 AM, Remi Forax wrote:
A simple Java question, what this code does ?
ArrayList list = new ArrayList<>();
list.add("foo");
list.add("bar");
for(String s: list) {
list.remove(s);
}
:(
We could improve the best-effo
Hi Seán,
Thanks for taking care of that :-)
It looks good to me. You might want to set the copyright year to 2015.
Best regards,
-- daniel
On 08/01/15 15:41, Seán Coffey wrote:
I've taken suggested test code from Daniel and am looking to backport
8066612 to jdk7u-dev. The test differs slightl
Hi,
Please find below a webrev for:
8068730: Increase the precision of the implementation
of java.time.Clock.systemUTC()
https://bugs.openjdk.java.net/browse/JDK-8068730
The java.time.Clock.system() method (and variants thereof) are
specified to "obtain a clock that returns the current
eight.
Greetings
Bernd
Am Fri, 09 Jan 2015
17:56:28 +0100 schrieb Daniel Fuchs :
Hi,
Please find below a webrev for:
8068730: Increase the precision of the implementation
of java.time.Clock.systemUTC()
https://bugs.openjdk.java.net/browse/JDK-8068730
The java.time.Clock.s
t think of that. It looks like a sensible
RFE. Agreed.
best regards,
-- daniel
Stephen
On 9 January 2015 at 16:56, Daniel Fuchs wrote:
Hi,
Please find below a webrev for:
8068730: Increase the precision of the implementation
of java.time.Clock.systemUTC()
https://
On 12/01/15 03:20, David Holmes wrote:
Hi Daniel,
Looking at the hotspot part ...
On 10/01/2015 2:56 AM, Daniel Fuchs wrote:
Hi David,
[...]
http://cr.openjdk.java.net/~dfuchs/webrev_8068730/webrev.00/
Some more details on the patch:
native (hotspot) side:
- adds a new method to the
On 12/01/15 13:49, Stephen Colebourne wrote:
On 12 January 2015 at 12:00, Daniel Fuchs wrote:
I'm not a big fan of the current name either.
I would gladly rename it. I did think of
windows_to_java_time_micros, but it actually returns tenth of
micros - so it would be lying...
Is there a
On 12/01/15 15:41, Daniel Fuchs wrote:
On 12/01/15 13:49, Stephen Colebourne wrote:
On 12 January 2015 at 12:00, Daniel Fuchs
wrote:
I'm not a big fan of the current name either.
I would gladly rename it. I did think of
windows_to_java_time_micros, but it actually returns tenth of
micros
On 13/01/15 04:52, David Holmes wrote:
Here is the new webrev with Stephen & your feedback included
http://cr.openjdk.java.net/~dfuchs/webrev_8068730/webrev.01/
(windows_time_stamp not renamed yet)
I checked the updated webrev.02 and everything looks good on the hotspot
side.
What are your pl
Hi Paul,
Your clarification looks good and I'm glad for it!
best regards,
-- daniel
On 20/01/15 17:27, Paul Sandoz wrote:
Hi
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8032513-Spliterator-immutable-concurrent/webrev/
This is really just a clarification making what was implicitly obvious
Looks good to me Roger.
-- daniel
On 30/01/15 16:58, Roger Riggs wrote:
Please review this clarification to the optional behavior of
java.lang.Runtime and java.lang.ProcessBuilder
on platforms that don't support process creation.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-process-805
Hi,
Please find below a fix for:
8072450: 9-dev build failed on elinux-i586 and rlinux-i586
My fix for JDK-8068730 which was integrated from hs-rt into jdk9-dev
yesterday is causing a build failure in the jdk9/dev nightly on two
platforms.
It appears that these platforms have a slightly older
On 04/02/15 17:21, Christian Thalinger wrote:
-const jlong MAX_DIFF_SECS = 0x01; // 2^32
+const jlong MAX_DIFF_SECS = 0x01LL; // 2^32
Don’t use LL directly; we have a compiler-dependent macro for this:
CONST64
Hi Christian,
I have pushed the change as it was reviewed b
Hi Paul,
This looks good - I have noticed one copy/paste error in the javadoc
though:
OptionalInt.java:
looks like the throws clause of ifPresent and ifPresentOrElse have been
interverted:
138 * @throws NullPointerException if a value is present and
{@code action} is
139 * null, o
The new version looks good Paul!
-- daniel
On 2/12/15 6:50 PM, Paul Sandoz wrote:
On Feb 12, 2015, at 3:50 PM, Daniel Fuchs wrote:
Hi Paul,
This looks good - I have noticed one copy/paste error in the javadoc
though:
OptionalInt.java:
looks like the throws clause of ifPresent and
Hi,
Please find below a patch for:
8072645: java.util.logging should use java.time to get more
precise time stamps
http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
specdiff:
http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/java/util/logging/package-
Hi Jason,
On 2/13/15 10:57 PM, Jason Mehrens wrote:
Daniel,
In the XMLFormatter.format you can get rid of the double call to
getNanoAdjustment() since you have stored the value in the local var 'nanos'.
Thanks for spotting that, will do.
For the new XMLFormatter constructor what do you t
ill need to keep serializing a number of
milliseconds
and a nano second adjustment. Whether the time stamp should be stored
internally
as an Instant or as a number of milliseconds + a nano adjustment can be
discussed.
I might favor the second as it would make serialization easier
(especially
Hi Bernd,
I will make some measurements - I don't expect that the cost
of the new accessor will matter much as from my early
measurements [1] it's not that far from the cost of
System.currentTimeMillis().
best regards,
-- daniel
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-Ja
tter.formatTo(ZonedDateTime.ofInstant(time, zoneId), sb);
Will look into this.
Thanks again for your review! This is quite helpful.
-- daniel
thanks
Stephen
On 13 Feb 2015 14:57, "Daniel Fuchs" wrote:
Hi,
Please find below a patch for:
8072645: java.util.logging shou
Hi Stephen,
Thanks again for your support and suggestions!
On 14/02/15 14:03, Daniel Fuchs wrote:
If I'm not mistaken the previous SimpleFormatter used to use java.util.Date
and printed the time in the local time zone. I have tried to keep this
behavior.
I'm not sure we would want to
/02/15 20:24, Daniel Fuchs wrote:
Hi Stephen,
Thanks again for your support and suggestions!
On 14/02/15 14:03, Daniel Fuchs wrote:
If I'm not mistaken the previous SimpleFormatter used to use
java.util.Date
and printed the time in the local time zone. I have tried to keep this
behavior.
I&
/benchmarks.html
On 16/02/15 20:24, Daniel Fuchs wrote:
Hi Stephen,
Thanks again for your support and suggestions!
On 14/02/15 14:03, Daniel Fuchs wrote:
If I'm not mistaken the previous SimpleFormatter used to use
java.util.Date
and printed the time in the local time zone. I have tried to keep
Hi Behrooz,
I have made several fixes WRT to lock files used by FileHandler
recently. Could you please tell us which version of java you
are using when observing this?
I'll need to analyze your issue a bit deeper - and knowing
the version (java -version) will help me in not making false
assumpti
Hi Behrooz,
On 19/02/15 13:46, Behrooz Nobakht wrote:
The version of Java is irrelevant. We have tested our setup
on Java 7 and Java 8 u25/31. We observe the same exception.
Ok - then the version is indeed relevant ;-)
What you are observing may be a symptom of
https://bugs.openjdk.java.net/
701 - 800 of 1615 matches
Mail list logo
