Changeset: a50bad038f31
Author:darcy
Date: 2013-05-13 22:16 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a50bad038f31
8014365: Restore Objects.requireNonNull(T, Supplier)
Reviewed-by: mduigou
! src/share/classes/java/util/Objects.java
! test/java/util/Objects/BasicObjectsT
Changeset: ae35fdbab949
Author:sherman
Date: 2013-05-13 20:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae35fdbab949
8013386: (tz) Support tzdata2013c
Summary: updated tz data to version 2013c
Reviewed-by: peytoia, okutsu
! make/sun/javazic/tzdata/VERSION
! make/sun/jav
Changeset: 8dd528992c15
Author:jlahoda
Date: 2013-05-10 15:15 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8dd528992c15
8012929: Trees.getElement should work not only for declaration trees, but also
for use-trees
Reviewed-by: jjg
Contributed-by: Dusan Balek , Jan Lah
Changeset: 86c1e8c799f5
Author:khazra
Date: 2013-05-13 13:48 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86c1e8c799f5
8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive
Summary: Rearrange event-handling code to remove bottle-neck. Also reviewed
Greetings:
I posted a new webrev image:
http://cr.openjdk.java.net/~jzavgren/8008972/webrev.03/
that fixes a memory leak.
The leak in
src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c is
caused by an unfortunate interplay between two actions:
1.) dynamically allocating a larger pa
On 5/13/2013 3:19 AM, Chris Hegarty wrote:
On 11/05/2013 00:35, Kurchi Hazra wrote:
This is a simple improvement in the javadocs of the Socket and
ServerSocket
classes, to cross-reference the SocketOptions class where appropriate.
It looks
like a lot of changes in the webrev, only because I ha
No, the class is used for both request and response headers.
Also, Arrays.asList() doesn't work in this case because we have to
account for the number
of elements used. So, something like what you are suggesting below
should work.
Michael
On 13/05/13 16:10, Vitaly Davidovich wrote:
If the h
If the headers are supposed to be parsed and then readonly, then the class
can be made immutable? Don't know how much work that would entail.
To minimize synch overhead, I think you can assign the array and nkeys to
locals inside a synch region and then do the copying outside of it.
Sent from my
Okay, adding or removing elements would do that (though it won't happen
in practice)
as opposed to reset(). So, I guess it's better practice to make it
synchronized.
Thanks
Michael.
On 13/05/13 15:19, Vitaly Davidovich wrote:
If the array or nkeys is modified while getHeaders is running, you
If the array or nkeys is modified while getHeaders is running, you can get
NPE or ArrayIndexOutOfBoundsException. If you synchronize, the method
returns some list of headers, and it's true that as soon as it returns some
other thread can mutate the headers and thus the returned list isn't
"in-sync
Okay, I get you now. I think this is just a (complicating) consequence
of the syntax. I don't think there is anything we can do about it.
BTW, I probably should warn you that we are looking at changing the spec
again
to allow port number ranges, the same as SocketPermission...
- Michael
On 13
On 5/13/13 9:38 PM, Michael McMahon wrote:
On 13/05/13 14:29, Weijun Wang wrote:
Hi Michael
Until now, for all types of permissions, the "actions" property takes
the form of a comma separated list, and it's always accumulative. For
example, it can be "read", or "write", or "read, write". In f
On 13/05/13 14:12, Vitaly Davidovich wrote:
I get what you're saying about before/after, but the difference would
be that if it's called during then you get an exception purely due to
missing synchronization; in the before/after case, caller may observe
"stale" entries but that's fine, as you
On 13/05/13 14:29, Weijun Wang wrote:
Hi Michael
Until now, for all types of permissions, the "actions" property takes
the form of a comma separated list, and it's always accumulative. For
example, it can be "read", or "write", or "read, write". In fact, the
policytool makes use of this style
Hi Michael
Until now, for all types of permissions, the "actions" property takes
the form of a comma separated list, and it's always accumulative. For
example, it can be "read", or "write", or "read, write". In fact, the
policytool makes use of this style so that you can click on single
actio
I get what you're saying about before/after, but the difference would be
that if it's called during then you get an exception purely due to missing
synchronization; in the before/after case, caller may observe "stale"
entries but that's fine, as you say.
Maybe headers aren't reset in practice, but
Changeset: 46db0e633240
Author:xuelei
Date: 2013-05-13 06:05 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46db0e633240
8005598: (reopened) Need to clone array of input/output parameters
Reviewed-by: weijun
! src/share/classes/com/sun/jndi/dns/DnsContext.java
! src/share/cl
Hi Vitali,
I was going to switch to use Arrays.asList() as you and Alan suggested.
So getHeaderNames() would look like:
public List getHeaderNames() {
return Arrays.asList(keys);
}
So, it turns out synchronizing nkeys and keys is no longer necessary.
It's true that reset() co
Changeset: 76998d11a643
Author:xuelei
Date: 2013-05-13 05:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76998d11a643
8005535: SSLSessionImpl should have protected finalize()
Reviewed-by: weijun, wetmore
! src/share/classes/sun/security/ssl/SSLSessionImpl.java
Actually, local may not work since getHeaders uses nkeys as well - can run
into AIOBE. Probably best to just synchronize given current implementation.
Sent from my phone
On May 13, 2013 8:30 AM, "Vitaly Davidovich" wrote:
> Hi Michael,
>
> On the synchronized issue, I think you do need it; if s
Hi Michael,
On the synchronized issue, I think you do need it; if someone, e.g., calls
reset() while this method is running, you'll get NPE. Maybe pull the keys
array into a local then and iterate over the local instead?
Also, why LinkedList instead of ArrayList(or Arrays.asList, as Alan
mention
On 13/05/13 11:08, Chris Hegarty wrote:
On 12/05/2013 08:13, Alan Bateman wrote:
At a high-level it would be nice if the fields were final but I guess
the parsing of actions and being serialized complicates this.
This would be my preference too. You could use the serialization proxy
pat
Thanks for the review. On the javadoc comments, there are a couple
of small spec changes that will probably happen after feature freeze anyway.
So, that might be the best time to address the other javadoc issues.
I agree with your other comments. On the synchronized method in
MessageHeader,
I do
On 11/05/2013 00:35, Kurchi Hazra wrote:
This is a simple improvement in the javadocs of the Socket and ServerSocket
classes, to cross-reference the SocketOptions class where appropriate.
It looks
like a lot of changes in the webrev, only because I have re-justified
the text
in some cases.
Bug:
On 12/05/2013 08:13, Alan Bateman wrote:
At a high-level it would be nice if the fields were final but I guess
the parsing of actions and being serialized complicates this.
This would be my preference too. You could use the serialization proxy
pattern, and with some restructuring I think
On 11/05/2013 00:35, Kurchi Hazra wrote:
Hi,
This is a simple improvement in the javadocs of the Socket and
ServerSocket
classes, to cross-reference the SocketOptions class where appropriate.
It looks
like a lot of changes in the webrev, only because I have re-justified
the text
in some
On 12/05/2013 08:13, Alan Bateman wrote:
A partial review, focusing mostly on the spec as we've been through a
few rounds on that part already. Overall I think the javadoc looks quite
good. I realize someone suggested using lowercase "url" in the javadoc
but as the usage is as an acronym th
27 matches
Mail list logo
