Re: A few questions/comments about java.net.MulticastSocket

Hi Daniel, On Tue, Jan 19, 2021 at 2:12 PM Daniel Fuchs (sun) wrote: > Hi Vitaly, > > On 19/01/2021 19:01, Vitaly Davidovich wrote: > > That was an API mistake in Java 1.4. When DatagramChannel was > > updated to support joining multicast groups (in Java 7) it wa

Re: A few questions/comments about java.net.MulticastSocket

Thanks Alan. On Tue, Jan 19, 2021 at 1:57 PM Alan Bateman wrote: > On 19/01/2021 18:36, Vitaly Davidovich wrote: > > Hi all, > > A few colleagues and I were trying to make sense of the > joinGroup(SocketAddress, > NetworkInterface) > <https://

A few questions/comments about java.net.MulticastSocket

Hi all, A few colleagues and I were trying to make sense of the joinGroup(SocketAddress, NetworkInterface) method. In particular: - Why does this take

Re: RFR JDK-8153353: HPACK implementation

On Wednesday, April 6, 2016, Pavel Rappo wrote: > Hi again Simone :-) > > > On 6 Apr 2016, at 20:31, Simone Bordet > wrote: > > > > 1) Add a test for the decoder where you have the incoming bytes be > > passed 1 at the time to the decoder. > > Something like: > > > > ByteBuffer data = ByteBuffer

Re: "Permission denied" using socket with IPv6

Have you tried connecting with netcat? nc -6 ... should use ipv6 -- what happens with that? On Mon, Jun 1, 2015 at 4:47 PM, Bobby Bissett wrote: > On Mon, Jun 1, 2015 at 4:46 PM, Bobby Bissett wrote: > >> I *think* I have it set to allow anything. This is on the node where I'm >> running the te

Re: "Permission denied" using socket with IPv6

Is ip6tables running? sent from my phone On Jun 1, 2015 4:14 PM, "Bobby Bissett" wrote: > Hi all, > > Can someone tell me how to diagnose this issue? I can't create a > connection to another node using IPv6 because of the error below -- a short > app demonstrates the problem. Everything I've fou

Re: RFR 8027687: The constructors of URLPermission class do not behave as described in javadoc

. I also found a small casting issue with > StringBuilder.append(char) > being interpreted as StringBuilder.append(int) > > Here is the updated webrev: > > http://cr.openjdk.java.net/~michaelm/8027687/webrev.2/ > > Thanks, > Michael > > > On 02/11/13 01:03, Vitaly

Re: RFR 8027687: The constructors of URLPermission class do not behave as described in javadoc

The size to use is the length of the argument, which you're already using for the loop. On a separate note, is toLowerCase in a perf sensitive area? It makes an assumption that the lowering will need to happen (by always allocating the stringbuilder) but is that a common case? If this isn't perf s

Re: Code review: 8010464: Evolve java networking same origin policy

om my phone On May 13, 2013 10:43 AM, "Michael McMahon" wrote: > 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 > Mic

Re: Code review: 8010464: Evolve java networking same origin policy

#x27;t "in-sync" with current headers, but there's no exception. Sent from my phone On May 13, 2013 9:45 AM, "Michael McMahon" wrote: > On 13/05/13 14:12, Vitaly Davidovich wrote: > > I get what you're saying about before/after, but the difference woul

Re: Code review: 8010464: Evolve java networking same origin policy

; before or after either. In practice that won't happen, since the request > headers > aren't ever reset. > > Michael > > > > On 13/05/13 13:36, Vitaly Davidovich wrote: > > Actually, local may not work since getHeaders uses nkeys as well - can run > into AI

Re: Code review: 8010464: Evolve java networking same origin policy

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

Re: Code review: 8010464: Evolve java networking same origin policy

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

Re: RFR: JDK-8007606

Hi John, In NetworkInterface.c: 162 ret = (MIB_IFROW *) malloc(sizeof(MIB_IFROW)); 163 if(ret == NULL) 164 return NULL; tableP is left dangling if line 164 runs, no? 222 if (ret != NO_ERROR) { 223 if (tableP != NULL) { 224 free(tableP);

Re: Code Review Request: 7171415: java.net.URI.equals/hashCode not consistent for some URIs

s the hashCode itself > instead of relying on String.hashCode(): > > http://cr.openjdk.java.net/~khazra/7171415/webrev.01/ > > Thanks, > Kurchi > > On 08.01.2013 20:29, Vitaly Davidovich wrote: > > Yes, I also thought about range checks not being eliminated if using >

Re: Code Review Request: 7171415: java.net.URI.equals/hashCode not consistent for some URIs

with % anyway. Perhaps I misunderstood your point though ... Vitaly Sent from my phone On Jan 8, 2013 11:04 PM, "Kurchi Subhra Hazra" < kurchi.subhra.ha...@oracle.com> wrote: > On 1/8/13 6:55 PM, Vitaly Davidovich wrote: > > Also, I'm not sure how hot this method is in pr

Re: Code Review Request: 7171415: java.net.URI.equals/hashCode not consistent for some URIs

chars specially, like you do now. Or are you trying to take advantage of String intrinsic support in the JIT? I guess if perf is a concern you can write a micro benchmark comparing the approaches ... Sent from my phone On Jan 8, 2013 9:45 PM, "Vitaly Davidovich" wrote: > Hi Kurch

Re: Code Review Request: 7171415: java.net.URI.equals/hashCode not consistent for some URIs

Hi Kurchi, In the hash method, I suggest you move handling of strings with % into a separate method to keep the hash method small for common case (no %). Otherwise, there's a chance this method won't get inlined anymore due to its (newly increased) size. Also, I realize toLower does the same thin

Re: getportbyname in Java?

I think jdk can simply use getservbyname() in the impl - windows has the same function. I think both just look at their respective services file. Googling "java getservbyname" returns some hits so it looks like people would find this useful and it seems like it would be pretty straightforward to i