Hi Kumar,
On 24/02/2015 8:14 AM, Kumar Srinivasan wrote:
Hello,
Please review the fix for the above issue.
Webrev:
http://cr.openjdk.java.net/~ksrini/8066185/webrev.00/
The fix is self explanatory, as for the test I have done the following:
I found the comment:
/*
+ * Si
On 24/02/2015 12:20 AM, Martin Desruisseaux wrote:
Hello all
java.util.ServiceLoader does not seem to support usage of a second
Iterator in the middle of a previous iteration.
Nope it doesn't. At a minimum this should be documented. The distinct
Iterator instances returned by iterator() share
In fact, find another redundant in jdk.httpserver. I have updated the
synopsis of JDK-8073696 to remove redundant imports in java.corba and
jdk.httpserver
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8073696/webrev.00/
Mandy
diff --git
a/src/java.corba/share/classes/javax/rmi/CORBA/GetORBPropertiesFileAction.java
b/src/java.corba/share/classes/javax/rmi/CORBA/GetORBPropertiesFileAction.java
---
a/src/java.corba/share/classes/javax/rmi/CORBA/GetORBPropertiesFileAction.java
+++
b/src/java.corba/share/classes/javax/rm
I reject this. Not enough justification.
Kumar
On 2/19/2015 11:19 PM, mikhail cherkasov wrote:
Sorry, I sent link to the old webrev, this is correct one:
http://cr.openjdk.java.net/~mcherkas/8073187/webrev.01/src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java.udiff.html
On 2/20/2
On 2015-02-23 22:58, Peter Levart wrote:
On 02/23/2015 10:55 PM, Xueming Shen wrote:
If we're talking about using java.time from ZipEntry, then that's
another story. I belive that VM startup does not need the conversion
from DOS time to Java time in ZipEntry, but that should be checked
to be
Hi Daniel,
On 02/23/2015 06:41 PM, Daniel Fuchs wrote:
Hi,
Please find below a small patch for
8073394: Clock.systemUTC() should return a constant
http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.00/
best regards,
-- daniel
What about the following idea:
- create a (maybe still p
Hello,
Please review the fix for the above issue.
Webrev:
http://cr.openjdk.java.net/~ksrini/8066185/webrev.00/
The fix is self explanatory, as for the test I have done the following:
a. refactored it from a single longish test to sub-tests for readability.
b. added new sub-test for NMT Argumen
On 02/23/2015 10:55 PM, Xueming Shen wrote:
If we're talking about using java.time from ZipEntry, then that's
another story. I belive that VM startup does not need the conversion
from DOS time to Java time in ZipEntry, but that should be checked to
be sure...
I was talking about to use j.tim
On 02/23/2015 08:36 PM, Stephen Colebourne wrote:
Looking at the patch, all that may be needed is to change the type of
the instance variable used for the cache from ZoneId to Object, and
cast where necessary. Adds the cost of the cast to the main flow, but
that is pretty minimal.
Stephen
Hav
Hi Chris,
On 02/23/2015 12:01 PM, Chris Hegarty wrote:
Peter, David, Vitaly,
Can you please take a look at the latest version of this change:
http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/
There are still a couple of issues with this version:
- You are issuing freeze act
The rest of the java.time code tends to put the data provider method
before the test, and mostly uses a naming convention of
"data_systemClocks". Neither of which are particularly important
things.
Stephen
On 23 February 2015 at 20:02, Daniel Fuchs wrote:
> On 23/02/15 19:50, Roger Riggs wrote:
On 23/02/15 19:50, Roger Riggs wrote:
Hi Daniel,
Typically, a TestNG DataProvider would have been used to supply the case
data
instead of an internal Map.
Thanks Roger. I should take some time to learn more about TestNG.
Here is the new webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_80733
Hi,
Please find below a small patch for
8073394: Clock.systemUTC() should return a constant
http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.00/
best regards,
-- daniel
On 23/02/15 15:59, Paul Sandoz wrote:
On Feb 23, 2015, at 4:40 PM, Chris Hegarty wrote:
On 23/02/15 15:30, Vitaly Davidovich wrote:
Ok Chris, sounds good.
It could be, but I omitted it as it requires a pesky explicit
assignment of false in the case where there are not final fields!
Hi,
My understanding is that only whole classes can be explicitly exported
from a module.
If not exported, they are module private.
Roger
On 2/23/2015 10:54 AM, Peter Levart wrote:
On 02/23/2015 03:32 PM, Roger Riggs wrote:
Hi,
Does it make sense that the shared secret mechanism may no lon
On Feb 23, 2015, at 4:40 PM, Chris Hegarty wrote:
> On 23/02/15 15:30, Vitaly Davidovich wrote:
>> Ok Chris, sounds good.
>>
>>It could be, but I omitted it as it requires a pesky explicit
>>assignment of false in the case where there are not final fields!
>>
>>
>> You could use a loc
On 02/23/2015 03:32 PM, Roger Riggs wrote:
Hi,
Does it make sense that the shared secret mechanism may no longer be
needed in JDK 9,
at least within modules, since the module access controls should
provide the desired scoping.
Roger
Will there be a language-level "module" access modifier f
On 02/22/2015 10:16 PM, Xueming Shen wrote:
On 2/21/15 6:11 PM, Claes Redestad wrote:
Hi Sherman,
On 2015-02-21 19:49, Xueming Shen wrote:
Hi Claes,
This change basically undo the "fix" for 4759491 [1], for better
performance ...
my intent was never to break current behavior, but that mi
On 23/02/15 15:30, Vitaly Davidovich wrote:
Ok Chris, sounds good.
It could be, but I omitted it as it requires a pesky explicit
assignment of false in the case where there are not final fields!
You could use a local (non-final) boolean to track this state (assigned
with false), and th
Ok Chris, sounds good.
It could be, but I omitted it as it requires a pesky explicit assignment of
> false in the case where there are not final fields!
You could use a local (non-final) boolean to track this state (assigned
with false), and then set the field with it after the looping is over.
On 23/02/15 14:08, Vitaly Davidovich wrote:
Likewise, seems fine.
Thanks Vitaly.
By the way, is there a reason not to call
freeze() right before returning obj? Is there something special about
the place it's invoked at now?
Probably not. The freeze should probably happen before the
Object
On 23/02/15 12:30, David Holmes wrote:
Hi Chris,
On 23/02/2015 9:01 PM, Chris Hegarty wrote:
Peter, David, Vitaly,
Can you please take a look at the latest version of this change:
http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/
It seems reasonable
Thanks.
but I don
Hi,
Does it make sense that the shared secret mechanism may no longer be
needed in JDK 9,
at least within modules, since the module access controls should provide
the desired scoping.
Roger
On 2/23/2015 6:24 AM, Daniel Fuchs wrote:
Agreed. I'm just not a big fan of using SharedSecrets if t
Hello all
java.util.ServiceLoader does not seem to support usage of a second
Iterator in the middle of a previous iteration. The attached Java file
provides two simple tests with a ServiceLoader iterating over two
elements. The first test creates two iterators and invokes their
hasNext() / next()
Likewise, seems fine. By the way, is there a reason not to call freeze()
right before returning obj? Is there something special about the place it's
invoked at now?
Also, hasFinal field can be final, unless I missed some context in the
webrev.
sent from my phone
On Feb 23, 2015 7:30 AM, "David
Hi Everyone,
Webrev updated in-place (press shift-reload)
http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/
Updated formatting.
Hack in main.cpp replaced with true error check.
-Dmitry
On 2015-02-23 05:07, David Holmes wrote:
> On 21/02/2015 4:27 AM, Dmitry Samersoff wrote:
>> Hi
Hi Chris,
On 23/02/2015 9:01 PM, Chris Hegarty wrote:
Peter, David, Vitaly,
Can you please take a look at the latest version of this change:
http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/
It seems reasonable but I don't have a clear picture of the connection
between r
Having recently spent time on performance myself, I know that there
are a number of things in the java.time package that need some work.
Improving ZoneId.systemDefault() is definitely an improvement I
welcome. The change is along the lines of that I would have made,
involving a "secret" location t
On 02/23/2015 12:24 PM, Daniel Fuchs wrote:
Hi Peter,
On 23/02/15 11:29, Peter Levart wrote:
Caching of ZoneId in the defensive clone of defualt TimeZone object
would not have a desired effect as the clone is thrown away in each call
to ZoneId.systemDefault(). We must get hold of the TimeZone i
Hi Peter,
On 23/02/15 11:29, Peter Levart wrote:
Caching of ZoneId in the defensive clone of defualt TimeZone object
would not have a desired effect as the clone is thrown away in each call
to ZoneId.systemDefault(). We must get hold of the TimeZone instance
that is cached. Another way to do tha
Peter, David, Vitaly,
Can you please take a look at the latest version of this change:
http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/
On 20/02/15 15:09, Peter Levart wrote:
...
This looks good now. But I wonder if issuing fences after nested calls
to readObject() makes mu
Hi Daniel,
On 02/23/2015 10:50 AM, Daniel Fuchs wrote:
Hi Peter,
On 22/02/15 21:21, Peter Levart wrote:
Hi,
I noticed internal JDK class java.util.zip.ZipUtils uses deprecated
java.util.Date API for implementing two methods for converting DOS to
Java time and back. I thought I'd try translati
Hi Peter,
On 22/02/15 21:21, Peter Levart wrote:
Hi,
I noticed internal JDK class java.util.zip.ZipUtils uses deprecated
java.util.Date API for implementing two methods for converting DOS to
Java time and back. I thought I'd try translating them to use new
java.time API. Translation was straigh
34 matches
Mail list logo
