On 15/05/2013 12:46, Michael McMahon wrote:
updated here:
http://cr.openjdk.java.net/~michaelm/8010464/webrev.3/
Michael.
This looks much better.
In HttpURLConnection then odd formatting in the declaration of
followRedirect0 (which probably needs a better name, maybe
implFollowRedirect?)
On 15/05/13 12:12, Michael McMahon wrote:
On 15/05/13 12:02, Alan Bateman wrote:
On 15/05/2013 11:34, Michael McMahon wrote:
...
I'll post one more webrev, and push it soon afterwards as I'd like
to make the
code freeze today.
Okay.
updated here:
http://cr.openjdk.java.net/~michaelm
On 15/05/13 12:02, Alan Bateman wrote:
On 15/05/2013 11:34, Michael McMahon wrote:
:
On MessageHeader then getHeaderNamesInList could use
java.util.StringJoiner to avoid rolling your own.
I can see the benefit of using StringJoiner (and a lambda) if I am
starting off from a Collection
and
On 15/05/2013 11:34, Michael McMahon wrote:
:
On MessageHeader then getHeaderNamesInList could use
java.util.StringJoiner to avoid rolling your own.
I can see the benefit of using StringJoiner (and a lambda) if I am
starting off from a Collection
and this is something that only struck me w
On 15/05/13 11:04, Alan Bateman wrote:
On 14/05/2013 12:54, Michael McMahon wrote:
I have updated the webrev for this at:
http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/
I took a pass over the updated webrev and it mostly looks good to me.
In HttpURLConnection then I wonder if it woul
On 14/05/2013 12:54, Michael McMahon wrote:
I have updated the webrev for this at:
http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/
I took a pass over the updated webrev and it mostly looks good to me.
In HttpURLConnection then I wonder if it would be better if
getInputStream, getOutpu
On 15/05/13 10:09, Chris Hegarty wrote:
What you have in the latest version of this webrev look fine to me.
Thanks Chris!
Michael
-Chris.
On 14/05/2013 12:54, Michael McMahon wrote:
I have updated the webrev for this at:
http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/
Thanks
Mich
What you have in the latest version of this webrev look fine to me.
-Chris.
On 14/05/2013 12:54, Michael McMahon wrote:
I have updated the webrev for this at:
http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/
Thanks
Michael.
I have updated the webrev for this at:
http://cr.openjdk.java.net/~michaelm/8010464/webrev.2/
Thanks
Michael.
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
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
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 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 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
Michael,
It might be better to narrow permissions right now with code like below:
private static
AccessControlContext withPermissions(Permission ... perms){
Permissions col = new Permissions();
for (Permission thePerm : perms ) {
col.add(thePerm);
}
final ProtectionDomain pd = new
On 10/05/2013 12:34, Michael McMahon wrote:
Hi,
This is the webrev for the HttpURLPermission addition.
As well as the new permission class, the change
includes the use of the permission in java.net.HttpURLConnection.
The code basically checks for a HttpURLPermission in plainConnect(),
getInputS
28 matches
Mail list logo
