From weijun.wang at oracle.com Fri Aug 1 05:39:39 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 1 Aug 2014 13:39:39 +0800 Subject: nameservers in solaris/.../ResolverConfigurationImpl not static Message-ID: <6128EF53-8B15-4AB2-AED2-E47D28D42022@oracle.com> There are 2 sun.net.dns.ResolverConfigurationImpl implementations. The cached searchlist and nameservers in the solaris version are instance fields and those in windows are static. The cache mechanism in both is guarded by static fields changed and lastRefresh. Therefore it seems the solaris searchlist/nameservers should also be static. --Max From mark.sheppard at oracle.com Thu Aug 7 18:15:48 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 07 Aug 2014 19:15:48 +0100 Subject: RFR: JDK-8054118 - java/net/ipv6tests/UdpTest.java failed intermittently Message-ID: <53E3C254.4040803@oracle.com> Hi, please oblige and review the following fix http://cr.openjdk.java.net/~msheppar/8054118/webrev/ to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8054118 The Windows test environment has a Teredo interface. This oscillates between being configured with IPv6 and not been configured. The configured state is transient. When configured its IPv6 is retrieved as first local ipv6 address. As such, it can happen that during the test the interface is disabled, and the test will fail with the report Socket receive timeout. This fix removes the Teredo interface from the testing scenario, so that a more stable interface will be used. regards Mark From chris.hegarty at oracle.com Thu Aug 7 18:20:24 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 7 Aug 2014 19:20:24 +0100 Subject: RFR: JDK-8054118 - java/net/ipv6tests/UdpTest.java failed intermittently In-Reply-To: <53E3C254.4040803@oracle.com> References: <53E3C254.4040803@oracle.com> Message-ID: Thanks Mark, Reviewed. -Chris. P.S. At some point in the future, we should try to create a general test utility library to retrieve suitable network interfaces for tests to use. On 7 Aug 2014, at 19:15, Mark Sheppard wrote: > Hi, > please oblige and review the following fix > http://cr.openjdk.java.net/~msheppar/8054118/webrev/ > > to address the issue raised in > https://bugs.openjdk.java.net/browse/JDK-8054118 > > The Windows test environment has a Teredo interface. > This oscillates between being configured with IPv6 and not been configured. > The configured state is transient. When configured its IPv6 is retrieved as > first local ipv6 address. As such, it can happen that during the test the > interface is disabled, and the test will fail with the report Socket receive timeout. > > This fix removes the Teredo interface from the testing scenario, so that a more stable interface > will be used. > > regards > Mark From mark.sheppard at oracle.com Thu Aug 7 18:21:27 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 07 Aug 2014 19:21:27 +0100 Subject: RFR: JDK-8054118 - java/net/ipv6tests/UdpTest.java failed intermittently In-Reply-To: References: <53E3C254.4040803@oracle.com> Message-ID: <53E3C3A7.3030300@oracle.com> thanks Chris On 07/08/2014 19:20, Chris Hegarty wrote: > Thanks Mark, Reviewed. > > -Chris. > > P.S. At some point in the future, we should try to create a general test utility library to retrieve suitable network interfaces for tests to use. > > On 7 Aug 2014, at 19:15, Mark Sheppard wrote: > >> Hi, >> please oblige and review the following fix >> http://cr.openjdk.java.net/~msheppar/8054118/webrev/ >> >> to address the issue raised in >> https://bugs.openjdk.java.net/browse/JDK-8054118 >> >> The Windows test environment has a Teredo interface. >> This oscillates between being configured with IPv6 and not been configured. >> The configured state is transient. When configured its IPv6 is retrieved as >> first local ipv6 address. As such, it can happen that during the test the >> interface is disabled, and the test will fail with the report Socket receive timeout. >> >> This fix removes the Teredo interface from the testing scenario, so that a more stable interface >> will be used. >> >> regards >> Mark From dmitry.samersoff at oracle.com Thu Aug 7 18:25:41 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 07 Aug 2014 22:25:41 +0400 Subject: RFR: JDK-8054118 - java/net/ipv6tests/UdpTest.java failed intermittently In-Reply-To: <53E3C254.4040803@oracle.com> References: <53E3C254.4040803@oracle.com> Message-ID: <53E3C4A5.6050006@oracle.com> Mark, We can put nic.getDisplayName() under isWindows and save a bit of computer power. -Dmitry On 2014-08-07 22:15, Mark Sheppard wrote: > Hi, > please oblige and review the following fix > http://cr.openjdk.java.net/~msheppar/8054118/webrev/ > > to address the issue raised in > https://bugs.openjdk.java.net/browse/JDK-8054118 > > The Windows test environment has a Teredo interface. > This oscillates between being configured with IPv6 and not been configured. > The configured state is transient. When configured its IPv6 is retrieved as > first local ipv6 address. As such, it can happen that during the test the > interface is disabled, and the test will fail with the report Socket > receive timeout. > > This fix removes the Teredo interface from the testing scenario, so that > a more stable interface > will be used. > > regards > Mark -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From peter.firmstone at zeus.net.au Sat Aug 9 05:56:16 2014 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 09 Aug 2014 15:56:16 +1000 Subject: The future of Serialization Message-ID: <1407563776.1841.30.camel@Nokia-N900> I've noticed there's not much interest in improving Serialization on these lists. This makes me wonder if java Serialization has lost relevance in recent years with the rise of protocol buffers apache thrift and other means of data transfer over byte streams. The burden of implementing Serializable can significantly hamper developers efforts when refactoring, it's quite common for some projects to make no guarantee regarding Serialization compatibility between releases. Also implementation of Serializable can double project development hours, hamper future development and increase software maintenance costs. Serialization also presents opportunities for attackers and has been responsible for a number of zero day exploits. I don't know if isolates will be included with JDK 9 for Jigsaw, or whether ClassLoaders alone will provide isolation for modules. The ability to limit visibility and provide isolation of implementation classes as well as providing limits on memory and threads for isolated modules would also improve platform security. Serialization may provide a means to hot upgrade modules, but more flexible options that doesn't cause serial data lock in need to be developed. Should Serializable eventually be deprecated? Should Serialization be disabled by default? Should a new mechanism be developed? If a new mechanism is developed, what about circular object relationships? Regards, Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Sat Aug 9 17:20:47 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 09 Aug 2014 13:20:47 -0400 Subject: The future of Serialization In-Reply-To: <1407563776.1841.30.camel@Nokia-N900> References: <1407563776.1841.30.camel@Nokia-N900> Message-ID: <53E6586F.7080906@oracle.com> > I've noticed there's not much interest in improving Serialization on > these lists. This makes me wonder if java Serialization has lost > relevance in recent years with the rise of protocol buffers apache > thrift and other means of data transfer over byte streams. I sense your frustration, but I think you may be reaching the wrong conclusion. The lack of response is probably not evidence that there's no interest in fixing serialization; its that fixing serialization, with all the constraints that "fix" entails, is just really really hard, and its much easier to complain about it (and even say "let's just get rid of it") than to fix it. > Should Serializable eventually be deprecated? Should Serialization be > disabled by default? Should a new mechanism be developed? If a new > mechanism is developed, what about circular object relationships? As I delved into my own explorations of serialization, I started to realize why such a horrible approach was the one that was ultimately chosen; while serialization is horrible and awful and leaky and insecure and complex and brittle, it does address problems like cyclic data structures and independent evolution of subclass and superclass better than the "clean" models. My conclusion is, at best, a new mechanism would have to live side-by-side with the old one, since it could only handle 95% of the cases. It might handle those 95% much better -- more cleanly, securely, and allowing easier schema evolution -- but the hard cases are still there. Still, reducing the use of the horrible old mechanism may still be a worthy goal, even if it can't be killed outright. From peter.firmstone at zeus.net.au Mon Aug 11 10:12:14 2014 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 11 Aug 2014 20:12:14 +1000 Subject: The future of Serialization In-Reply-To: <53E6586F.7080906@oracle.com> References: <1407563776.1841.30.camel@Nokia-N900> <53E6586F.7080906@oracle.com> Message-ID: <53E896FE.3030706@zeus.net.au> Brian, Thanks for picking up on my frustration ;) I have something in mind for Serializable2 to address cyclic data structures and the possibility of independant evolution of super and child classes, while retaining a relatively clean public api, with one optional private method. The methods and interfaces proposed are suitable for any alternative ObjectInput and ObjectOutput implementation. An interface exists in Apache River, it's called Startable, it has one method: public void start() throws Exception; It's called by a framework to allow an Object to start threads, publish "this" or throw an exception after construction. The intent is to allow an object to be immutable with final fields and be provided with a thread of execution after construction and before publication. Something similar can be used to wire up circular relations, let met explain: Every class that implements Serializable has one thing in common, the Serialization protocol and every Object instance of a Serializable class has an arbitrary serial form. I propose a final class representing SerialForm for an object, that cannot be extended, requires privilege to instantiate and also performs method guard security checks, for all callers with the exception of a calling class reading or writing its own serial form. SerialForm needs a parameter field key identity represented by the calling Class, the method name and the field's Class type, this key would be used for both writing and retrieving a field entry in SerialForm. SerialForm will also provide a method to advise if a field key contains a circular relation, any field entry in SerialForm that would contain a circular relation is not populated until after construction of the current object is complete. An arbitrary Serializable2 Object instance may be composed of a hierarchy of classes, each belonging to a separate ProtectionDomain. For the following interface: public interface Serializable2 { void writeObject(SerialForm serial) throws IOException; } Implementers of Serializable2 must: 1. Implement writeObject 2. Implement a constructor with the signature: (SerialForm serial). Implementors that need to check invariants, delay throwing an Exception, publish "this" or set a circular reference after construction should: 4. Implement: private void readObjectNoData() throws InvalidObjectException; Child class implementations should: 5. Call their super class writeObject method and superclass constructor, but may call any super class constructor or methods. Compatibility and Evolution: 1. Fields can be included or omitted from SerialForm, by an implementation, without breaking compatibility, provided a null reference is accepted during deserialization. 2. Child classes in a hierarchy; all Serializable2 implementing superclass constructors have the same signature; the superclass implementation can be substituted, without breaking child class deserialization (provided this is the constructor used by the child class). 3. There is no serialVersionUID. 4. Child class Serializable2 implementations can extend a superclass without a zero arg constructor that doesn't itself implement Serializable2. 5. Child classes that do not override writeObject will not be serialized, so can effectively opt out. 6. Because implementations are required to implement public methods, there is no "Magic". 7. Serializable2 shouldn't extend Serializable, allowing classes to implement both interfaces for a period of time (for that reason the signature for readObjectNoData may need to be changed for Serializable2). 8. ObjectInputStream and ObjectOutputStream can be extended to support both implementations for compatibility, however alternative stream implementations would be preferable for Serializable2 to avoid Serializable security issues. The new implementations should be possible to substitute because both types would use the same Stream Protocol, provided the classes being deserialized implement Serializable2. My reasoning for retaining readObjectNoData() and for updating field entry's in SerialForm that contain circular relations after construction, is: 1. An object reference for the object currently being deserialized can be passed to another object's constructor (via a SerialForm instance) after the current Object's constructor completes, allowing safe publication of final field freezes that occur at the end of construction. 2. When the Serialization2 Framework becomes aware of an object that contains a circular relationship while that object is in the process of being deserialized, the second object will not be instantiated until after the constructor of the first object in the relationship completes. Data read in from the stream can be stored in a SerialForm without requiring object instantation. 3. After construction completes, the object that has just been deserialized can retain a copy of its SerialForm and look up the field containing a circular relationship, the Serialization framework will update its SerialForm with the new object that holds a circular relationship, prior to calling readObjectNoData() on the first object. 4. If the developer of the implementing class is not aware of the possibility of a circular relationship, then the worst consequence is a field will be set to null during construction, "this" will not escape. 5. The second Object holding a link to an object that apears earlier in the stream, may not be aware that the object it holds a reference to also needs a reference to it. The first object will not obtain a reference to the second until both Object constructors have completed. The second object may not need to implement readObjectNoData(). 6. readObjectNoData() needs to be called on every class belonging to a single Object's inheritance hierarchy, when defined, after all constructors have completed, it should be called in the order of superclass to child class. Thoughts? Regards, Peter. On 10/08/2014 3:20 AM, Brian Goetz wrote: >> I've noticed there's not much interest in improving Serialization on >> these lists. This makes me wonder if java Serialization has lost >> relevance in recent years with the rise of protocol buffers apache >> thrift and other means of data transfer over byte streams. > > I sense your frustration, but I think you may be reaching the wrong > conclusion. The lack of response is probably not evidence that > there's no interest in fixing serialization; its that fixing > serialization, with all the constraints that "fix" entails, is just > really really hard, and its much easier to complain about it (and even > say "let's just get rid of it") than to fix it. > >> Should Serializable eventually be deprecated? Should Serialization be >> disabled by default? Should a new mechanism be developed? If a new >> mechanism is developed, what about circular object relationships? > > As I delved into my own explorations of serialization, I started to > realize why such a horrible approach was the one that was ultimately > chosen; while serialization is horrible and awful and leaky and > insecure and complex and brittle, it does address problems like cyclic > data structures and independent evolution of subclass and superclass > better than the "clean" models. > > My conclusion is, at best, a new mechanism would have to live > side-by-side with the old one, since it could only handle 95% of the > cases. It might handle those 95% much better -- more cleanly, > securely, and allowing easier schema evolution -- but the hard cases > are still there. Still, reducing the use of the horrible old > mechanism may still be a worthy goal, even if it can't be killed > outright. > From peter.firmstone at zeus.net.au Mon Aug 11 10:18:28 2014 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 11 Aug 2014 20:18:28 +1000 Subject: The future of Serialization In-Reply-To: <53E896FE.3030706@zeus.net.au> References: <1407563776.1841.30.camel@Nokia-N900> <53E6586F.7080906@oracle.com> <53E896FE.3030706@zeus.net.au> Message-ID: <53E89874.8060902@zeus.net.au> On 11/08/2014 8:12 PM, Peter Firmstone wrote: > Brian, > > Thanks for picking up on my frustration ;) > > I have something in mind for Serializable2 to address cyclic data > structures and the possibility of independant evolution of super and > child classes, while retaining a relatively clean public api, with one > optional private method. The methods and interfaces proposed are > suitable for any alternative ObjectInput and ObjectOutput implementation. > > An interface exists in Apache River, it's called Startable, it has one > method: > > public void start() throws Exception; > > It's called by a framework to allow an Object to start threads, > publish "this" or throw an exception after construction. The intent > is to allow an object to be immutable with final fields and be > provided with a thread of execution after construction and before > publication. > > Something similar can be used to wire up circular relations, let met > explain: > > Every class that implements Serializable has one thing in common, the > Serialization protocol and every Object instance of a Serializable > class has an arbitrary serial form. > > I propose a final class representing SerialForm for an object, that > cannot be extended, requires privilege to instantiate and also > performs method guard security checks, for all callers with the > exception of a calling class reading or writing its own serial form. > SerialForm needs a parameter field key identity represented by the > calling Class, Sorry, that should read "field name", not "method name". > the method name and the field's Class type, this key would be used for > both writing and retrieving a field entry in SerialForm. SerialForm > will also provide a method to advise if a field key contains a > circular relation, any field entry in SerialForm that would contain a > circular relation is not populated until after construction of the > current object is complete. > > An arbitrary Serializable2 Object instance may be composed of a > hierarchy of classes, each belonging to a separate ProtectionDomain. > > For the following interface: > > public interface Serializable2 { > > void writeObject(SerialForm serial) throws IOException; > > } > > Implementers of Serializable2 must: > > 1. Implement writeObject > 2. Implement a constructor with the signature: (SerialForm serial). > > Implementors that need to check invariants, delay throwing an > Exception, publish "this" or set a circular reference after > construction should: > > 4. Implement: private void readObjectNoData() throws > InvalidObjectException; > > Child class implementations should: > > 5. Call their super class writeObject method and superclass > constructor, but may call any super class constructor or methods. > > Compatibility and Evolution: > > 1. Fields can be included or omitted from SerialForm, by an > implementation, without breaking compatibility, provided a null > reference is accepted during deserialization. > 2. Child classes in a hierarchy; all Serializable2 implementing > superclass constructors have the same signature; the superclass > implementation can be substituted, without breaking child class > deserialization (provided this is the constructor used by the > child class). > 3. There is no serialVersionUID. > 4. Child class Serializable2 implementations can extend a superclass > without a zero arg constructor that doesn't itself implement > Serializable2. > 5. Child classes that do not override writeObject will not be > serialized, so can effectively opt out. > 6. Because implementations are required to implement public methods, > there is no "Magic". > 7. Serializable2 shouldn't extend Serializable, allowing classes to > implement both interfaces for a period of time (for that reason > the signature for readObjectNoData may need to be changed for > Serializable2). > 8. ObjectInputStream and ObjectOutputStream can be extended to > support both implementations for compatibility, however > alternative stream implementations would be preferable for > Serializable2 to avoid Serializable security issues. The new > implementations should be possible to substitute because both > types would use the same Stream Protocol, provided the classes > being deserialized implement Serializable2. > > > My reasoning for retaining readObjectNoData() and for updating field > entry's in SerialForm that contain circular relations after > construction, is: > > 1. An object reference for the object currently being deserialized > can be passed to another object's constructor (via a SerialForm > instance) after the current Object's constructor completes, > allowing safe publication of final field freezes that occur at the > end of construction. > 2. When the Serialization2 Framework becomes aware of an object that > contains a circular relationship while that object is in the > process of being deserialized, the second object will not be > instantiated until after the constructor of the first object in > the relationship completes. Data read in from the stream can be > stored in a SerialForm without requiring object instantation. > 3. After construction completes, the object that has just been > deserialized can retain a copy of its SerialForm and look up the > field containing a circular relationship, the Serialization > framework will update its SerialForm with the new object that > holds a circular relationship, prior to calling readObjectNoData() > on the first object. > 4. If the developer of the implementing class is not aware of the > possibility of a circular relationship, then the worst consequence > is a field will be set to null during construction, "this" will > not escape. > 5. The second Object holding a link to an object that apears earlier > in the stream, may not be aware that the object it holds a > reference to also needs a reference to it. The first object will > not obtain a reference to the second until both Object > constructors have completed. The second object may not need to > implement readObjectNoData(). > 6. readObjectNoData() needs to be called on every class belonging to > a single Object's inheritance hierarchy, when defined, after all > constructors have completed, it should be called in the order of > superclass to child class. > > Thoughts? > > Regards, > > Peter. > > On 10/08/2014 3:20 AM, Brian Goetz wrote: >>> I've noticed there's not much interest in improving Serialization on >>> these lists. This makes me wonder if java Serialization has lost >>> relevance in recent years with the rise of protocol buffers apache >>> thrift and other means of data transfer over byte streams. >> >> I sense your frustration, but I think you may be reaching the wrong >> conclusion. The lack of response is probably not evidence that >> there's no interest in fixing serialization; its that fixing >> serialization, with all the constraints that "fix" entails, is just >> really really hard, and its much easier to complain about it (and >> even say "let's just get rid of it") than to fix it. >> >>> Should Serializable eventually be deprecated? Should Serialization be >>> disabled by default? Should a new mechanism be developed? If a new >>> mechanism is developed, what about circular object relationships? >> >> As I delved into my own explorations of serialization, I started to >> realize why such a horrible approach was the one that was ultimately >> chosen; while serialization is horrible and awful and leaky and >> insecure and complex and brittle, it does address problems like >> cyclic data structures and independent evolution of subclass and >> superclass better than the "clean" models. >> >> My conclusion is, at best, a new mechanism would have to live >> side-by-side with the old one, since it could only handle 95% of the >> cases. It might handle those 95% much better -- more cleanly, >> securely, and allowing easier schema evolution -- but the hard cases >> are still there. Still, reducing the use of the horrible old >> mechanism may still be a worthy goal, even if it can't be killed >> outright. >> > From Alan.Bateman at oracle.com Mon Aug 11 11:21:01 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Aug 2014 12:21:01 +0100 Subject: The future of Serialization In-Reply-To: <1407563776.1841.30.camel@Nokia-N900> References: <1407563776.1841.30.camel@Nokia-N900> Message-ID: <53E8A71D.70407@oracle.com> On 09/08/2014 06:56, Peter Firmstone wrote: > > I've noticed there's not much interest in improving Serialization on > these lists. This makes me wonder if java Serialization has lost > relevance in recent years with the rise of protocol buffers apache > thrift and other means of data transfer over byte streams. > Just to add to Brian's comments, I think part of it is that many people are busy with other things, preparing for JDK 9 for example. So I think there is a lot of support for investigation and proposals that would improve things, it's just that some people are too busy to respond. > > I don't know if isolates will be included with JDK 9 for Jigsaw, or > whether ClassLoaders alone will provide isolation for modules. > > The ability to limit visibility and provide isolation of > implementation classes as well as providing limits on memory and > threads for isolated modules would also improve platform security. > If by "isolates" you mean JSR 121 then I think that would be well beyond the scope, as would resource management. This isn't really the thread to discuss how module boundaries will work but just to say that class loaders and visibility can be weak when it comes to module boundaries. There are other options available, particularly when the ability to extend the access control rules are on the table. So I would suggest not making any assumptions here for now. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Mon Aug 11 12:06:48 2014 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 11 Aug 2014 22:06:48 +1000 Subject: The future of Serialization In-Reply-To: <53E8A71D.70407@oracle.com> References: <1407563776.1841.30.camel@Nokia-N900> <53E8A71D.70407@oracle.com> Message-ID: <53E8B1D8.1000200@zeus.net.au> Thanks Alan, I can relate to time poverty :) I might be assuming too much, but if there's interest in doing something with Serialization, I'd be interested in learning about plans or difficulties involved in deserialization and modules. It can be a little more difficult to find the correct ClassLoader to resolve classes during deserialization when ClassLoader relationships aren't hierarchial. Object streams can be annotated with module information to assist resolution. On the subject of isolates, I found Ribbons interesting: https://www.cs.purdue.edu/homes/peugster/Ribbons/RJ.pdf https://www.cs.purdue.edu/homes/peugster/Ribbons/ Got any links to info on extending access control rules? Regards, Peter. On 11/08/2014 9:21 PM, Alan Bateman wrote: > On 09/08/2014 06:56, Peter Firmstone wrote: >> >> I've noticed there's not much interest in improving Serialization on >> these lists. This makes me wonder if java Serialization has lost >> relevance in recent years with the rise of protocol buffers apache >> thrift and other means of data transfer over byte streams. >> > Just to add to Brian's comments, I think part of it is that many > people are busy with other things, preparing for JDK 9 for example. So > I think there is a lot of support for investigation and proposals that > would improve things, it's just that some people are too busy to respond. > > >> >> I don't know if isolates will be included with JDK 9 for Jigsaw, or >> whether ClassLoaders alone will provide isolation for modules. >> >> The ability to limit visibility and provide isolation of >> implementation classes as well as providing limits on memory and >> threads for isolated modules would also improve platform security. >> > If by "isolates" you mean JSR 121 then I think that would be well > beyond the scope, as would resource management. This isn't really the > thread to discuss how module boundaries will work but just to say that > class loaders and visibility can be weak when it comes to module > boundaries. There are other options available, particularly when the > ability to extend the access control rules are on the table. So I > would suggest not making any assumptions here for now. > > -Alan. From Alan.Bateman at oracle.com Mon Aug 11 14:18:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Aug 2014 15:18:20 +0100 Subject: The future of Serialization In-Reply-To: <53E8B1D8.1000200@zeus.net.au> References: <1407563776.1841.30.camel@Nokia-N900> <53E8A71D.70407@oracle.com> <53E8B1D8.1000200@zeus.net.au> Message-ID: <53E8D0AC.3060108@oracle.com> On 11/08/2014 13:06, Peter Firmstone wrote: > Thanks Alan, I can relate to time poverty :) > > I might be assuming too much, but if there's interest in doing > something with Serialization, I'd be interested in learning about > plans or difficulties involved in deserialization and modules. It can > be a little more difficult to find the correct ClassLoader to resolve > classes during deserialization when ClassLoader relationships aren't > hierarchial. Object streams can be annotated with module information > to assist resolution. The issues around visibility when deserializing are somewhat independent of modules. The usual way to deal with such matters is to override the resolveClass method. Another long standing suggestion is for ObjectInputStream to define a new constructor that takes a class loader to avoid the stack walk to get the user-defined loader. It remains to seen but if we can avoid changing visibility then we don't change the status quo. > : > > Got any links to info on extending access control rules? Not yet, a future JSR will define the standard module system and there will be a corresponding JEP for the implementation. -Alan. From mark.sheppard at oracle.com Mon Aug 11 14:24:31 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Mon, 11 Aug 2014 15:24:31 +0100 Subject: RFR: JDK-8054118 - java/net/ipv6tests/UdpTest.java failed intermittently In-Reply-To: <53E3C4A5.6050006@oracle.com> References: <53E3C254.4040803@oracle.com> <53E3C4A5.6050006@oracle.com> Message-ID: <53E8D21F.6000504@oracle.com> grand ... thanks Dmitry Mark On 07/08/2014 19:25, Dmitry Samersoff wrote: > Mark, > > We can put nic.getDisplayName() under isWindows and save a bit of > computer power. > > -Dmitry > > > On 2014-08-07 22:15, Mark Sheppard wrote: >> Hi, >> please oblige and review the following fix >> http://cr.openjdk.java.net/~msheppar/8054118/webrev/ >> >> to address the issue raised in >> https://bugs.openjdk.java.net/browse/JDK-8054118 >> >> The Windows test environment has a Teredo interface. >> This oscillates between being configured with IPv6 and not been configured. >> The configured state is transient. When configured its IPv6 is retrieved as >> first local ipv6 address. As such, it can happen that during the test the >> interface is disabled, and the test will fail with the report Socket >> receive timeout. >> >> This fix removes the Teredo interface from the testing scenario, so that >> a more stable interface >> will be used. >> >> regards >> Mark > From peter.firmstone at zeus.net.au Tue Aug 12 09:03:53 2014 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 12 Aug 2014 19:03:53 +1000 Subject: The future of Serialization In-Reply-To: <53E8D0AC.3060108@oracle.com> References: <1407563776.1841.30.camel@Nokia-N900> <53E8A71D.70407@oracle.com> <53E8B1D8.1000200@zeus.net.au> <53E8D0AC.3060108@oracle.com> Message-ID: <1407834233.6396.10.camel@Nokia-N900> Interesting, language features for modules, won't necessarily involve ClassLoader's (my assumptions were based on existing systems) although you'd expect modules to have their own ProtectionDomain. An alternative to isolates, is separate processes with jvm class sharing enabled. I'll keep an eye out for the JSR. When is a better timeframe, roughly, to discuss Serializable? Regards, Peter. ----- Original message ----- > On 11/08/2014 13:06, Peter Firmstone wrote: > > Thanks Alan, I can relate to time poverty :) > > > > I might be assuming too much, but if there's interest in doing > > something with Serialization, I'd be interested in learning about > > plans or difficulties involved in deserialization and modules. It can > > be a little more difficult to find the correct ClassLoader to resolve > > classes during deserialization when ClassLoader relationships aren't > > hierarchial.? Object streams can be annotated with module information > > to assist resolution. > The issues around visibility when deserializing are somewhat independent > of modules. The usual way to deal with such matters is to override the > resolveClass method. Another long standing suggestion is for > ObjectInputStream to define a new constructor that takes a class loader > to avoid the stack walk to get the user-defined loader. It remains to > seen but if we can avoid changing visibility then we don't change the > status quo. > > : > > > > Got any links to info on extending access control rules? > Not yet, a future JSR will define the standard module system and there > will be a corresponding JEP for the implementation. > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Aug 13 13:13:45 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Aug 2014 14:13:45 +0100 Subject: The future of Serialization In-Reply-To: <1407834233.6396.10.camel@Nokia-N900> References: <1407563776.1841.30.camel@Nokia-N900> <53E8A71D.70407@oracle.com> <53E8B1D8.1000200@zeus.net.au> <53E8D0AC.3060108@oracle.com> <1407834233.6396.10.camel@Nokia-N900> Message-ID: <53EB6489.4000309@oracle.com> On 12/08/2014 10:03, Peter Firmstone wrote: > > Interesting, language features for modules, won't necessarily involve > ClassLoader's (my assumptions were based on existing systems) although > you'd expect modules to have their own ProtectionDomain. > I think it would be reasonable to expect to that you should be able to grant permissions to specific modules. This is something for a difference discussion thread of course. > > When is a better timeframe, roughly, to discuss Serializable? > I'm sure there isn't a best time that works for everyone that is interested in this topic. However, in terms of JDK 9 then it seems early enough to do the exploration and prototypes, and get moving on proposals. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Wed Aug 13 14:02:29 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 13 Aug 2014 16:02:29 +0200 Subject: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net Message-ID: <53EB6FF5.1050103@oracle.com> Hi, can I have a review for this patch to take advantage of offset-based parseInt methods added in 8041972 for java.net/sun.net classes? bug: https://bugs.openjdk.java.net/browse/JDK-8055032 webrev: http://cr.openjdk.java.net/~redestad/8055032/webrev.0 This causes fewer temporary String objects to be allocated and shows a direct throughput improvement in micros (1.2x in java.net.URLDecoder#decode and sun.net.www.ParseUtil#decode, for example) /Claes From Alan.Bateman at oracle.com Thu Aug 14 07:37:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Aug 2014 08:37:54 +0100 Subject: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net In-Reply-To: <53EB6FF5.1050103@oracle.com> References: <53EB6FF5.1050103@oracle.com> Message-ID: <53EC6752.6000601@oracle.com> On 13/08/2014 15:02, Claes Redestad wrote: > Hi, > > can I have a review for this patch to take advantage of offset-based > parseInt methods added in > 8041972 for java.net/sun.net classes? > > bug: https://bugs.openjdk.java.net/browse/JDK-8055032 > webrev: http://cr.openjdk.java.net/~redestad/8055032/webrev.0 > > This causes fewer temporary String objects to be allocated and shows a > direct throughput improvement > in micros (1.2x in java.net.URLDecoder#decode and > sun.net.www.ParseUtil#decode, for example) These changes look okay to although the downside is that it's less readable in a few places. Are there micro benchmarks being created as part of this work? If so, are they being pushed to a repository in OpenJDK for use by others? -Alan From claes.redestad at oracle.com Thu Aug 14 09:32:30 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 14 Aug 2014 11:32:30 +0200 Subject: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net In-Reply-To: <53EC6752.6000601@oracle.com> References: <53EB6FF5.1050103@oracle.com> <53EC6752.6000601@oracle.com> Message-ID: <53EC822E.6000602@oracle.com> On 08/14/2014 09:37 AM, Alan Bateman wrote: > On 13/08/2014 15:02, Claes Redestad wrote: >> Hi, >> >> can I have a review for this patch to take advantage of offset-based >> parseInt methods added in >> 8041972 for java.net/sun.net classes? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8055032 >> webrev: http://cr.openjdk.java.net/~redestad/8055032/webrev.0 >> >> This causes fewer temporary String objects to be allocated and shows >> a direct throughput improvement >> in micros (1.2x in java.net.URLDecoder#decode and >> sun.net.www.ParseUtil#decode, for example) > These changes look okay to although the downside is that it's less > readable in a few places. Thanks for looking at this, Alan! Any particular place where you think readability becomes a problem? I've grown fond of the parseInt(s, radix, offset) form myself, but I'm biased. ;-) > > Are there micro benchmarks being created as part of this work? If so, > are they being pushed to a repository in OpenJDK for use by others? We currently don't have a suitable landing place for microbenchmarks in the OpenJDK. I hope to one day be able to push benchmarks together with changesets like these. I have a few internal benchmarks where I've extensively benchmarked the new parseInt methods and some sanity tests to ensure it gives reasonable benefits for public methods like java.net.URLDecoder::decode /Claes > > -Alan From Alan.Bateman at oracle.com Thu Aug 14 11:30:47 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Aug 2014 12:30:47 +0100 Subject: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net In-Reply-To: <53EC822E.6000602@oracle.com> References: <53EB6FF5.1050103@oracle.com> <53EC6752.6000601@oracle.com> <53EC822E.6000602@oracle.com> Message-ID: <53EC9DE7.3070007@oracle.com> On 14/08/2014 10:32, Claes Redestad wrote: > : > > Any particular place where you think readability becomes a problem? > I've grown fond of the > parseInt(s, radix, offset) form myself, but I'm biased. ;-) It's somewhat subjective but when a method has a sequence of parameters that are the same type (int in this case) then reading the code requires a bit of extra effort to match up the parameters. Looking at this again then I just wonder if the radix should be last parameter rather than having it appear before the range. I think it would be clearer if the range were to follow the CharSequence rather than having the radix appear in the middle. I didn't have cycles to follow the recent discussion/review on core-libs-dev when these methods were added. Did the ordering come up? -Alan. From claes.redestad at oracle.com Thu Aug 14 11:42:52 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 14 Aug 2014 13:42:52 +0200 Subject: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net In-Reply-To: <53EC9DE7.3070007@oracle.com> References: <53EB6FF5.1050103@oracle.com> <53EC6752.6000601@oracle.com> <53EC822E.6000602@oracle.com> <53EC9DE7.3070007@oracle.com> Message-ID: <53ECA0BC.4070206@oracle.com> On 08/14/2014 01:30 PM, Alan Bateman wrote: > On 14/08/2014 10:32, Claes Redestad wrote: >> : >> >> Any particular place where you think readability becomes a problem? >> I've grown fond of the >> parseInt(s, radix, offset) form myself, but I'm biased. ;-) > It's somewhat subjective but when a method has a sequence of > parameters that are the same type (int in this case) then reading the > code requires a bit of extra effort to match up the parameters. > > Looking at this again then I just wonder if the radix should be last > parameter rather than having it appear before the range. I think it > would be clearer if the range were to follow the CharSequence rather > than having the radix appear in the middle. I didn't have cycles to > follow the recent discussion/review on core-libs-dev when these > methods were added. Did the ordering come up? Noone brought it up, as far as I can recall. Since parseInt(String, int radix) already existed, I figured adding the range parameters to the end would be overall less awkward than to push the radix parameter right in the new methods. The chosen implementation maintains that the second parameter is always radix, which I think helps maintain consistency. /Claes > > -Alan. From Alan.Bateman at oracle.com Thu Aug 14 12:00:30 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Aug 2014 13:00:30 +0100 Subject: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net In-Reply-To: <53ECA0BC.4070206@oracle.com> References: <53EB6FF5.1050103@oracle.com> <53EC6752.6000601@oracle.com> <53EC822E.6000602@oracle.com> <53EC9DE7.3070007@oracle.com> <53ECA0BC.4070206@oracle.com> Message-ID: <53ECA4DE.5040300@oracle.com> On 14/08/2014 12:42, Claes Redestad wrote: > > Noone brought it up, as far as I can recall. Since parseInt(String, > int radix) already existed, I figured adding the range parameters to > the end would be overall less awkward than to push the radix parameter > right in the new methods. The chosen implementation maintains that the > second parameter is always radix, which I think helps maintain > consistency. I think consistency could be argued both ways as the radix is also the last parameter in the existing methods. When I look at this method: public static int parseInt(CharSequence s, int radix, int beginIndex, int endIndex) and then feels more error prone than if the beginIndex/endIndex were immediately after the CharSequence. I'm interested in other opinions on this. -Alan. From roger.riggs at oracle.com Thu Aug 14 13:15:14 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 14 Aug 2014 09:15:14 -0400 Subject: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net In-Reply-To: <53ECA4DE.5040300@oracle.com> References: <53EB6FF5.1050103@oracle.com> <53EC6752.6000601@oracle.com> <53EC822E.6000602@oracle.com> <53EC9DE7.3070007@oracle.com> <53ECA0BC.4070206@oracle.com> <53ECA4DE.5040300@oracle.com> Message-ID: <53ECB662.9030501@oracle.com> Hi, My preference would be to keep the offsets immediately following the CharSequence, that clearly identifies the substring being operated on. Roger On 8/14/2014 8:00 AM, Alan Bateman wrote: > On 14/08/2014 12:42, Claes Redestad wrote: >> >> Noone brought it up, as far as I can recall. Since parseInt(String, >> int radix) already existed, I figured adding the range parameters to >> the end would be overall less awkward than to push the radix >> parameter right in the new methods. The chosen implementation >> maintains that the second parameter is always radix, which I think >> helps maintain consistency. > I think consistency could be argued both ways as the radix is also the > last parameter in the existing methods. When I look at this method: > > public static int parseInt(CharSequence s, int radix, int beginIndex, > int endIndex) > > and then feels more error prone than if the beginIndex/endIndex were > immediately after the CharSequence. > > I'm interested in other opinions on this. > > -Alan. From claes.redestad at oracle.com Thu Aug 14 13:23:04 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 14 Aug 2014 15:23:04 +0200 Subject: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net In-Reply-To: <53ECB662.9030501@oracle.com> References: <53EB6FF5.1050103@oracle.com> <53EC6752.6000601@oracle.com> <53EC822E.6000602@oracle.com> <53EC9DE7.3070007@oracle.com> <53ECA0BC.4070206@oracle.com> <53ECA4DE.5040300@oracle.com> <53ECB662.9030501@oracle.com> Message-ID: <53ECB838.3070201@oracle.com> How about methods only taking beginIndex? Integer.parseInt("x: 10000000", 3, 10)? I guess these could to be dropped to avoid ambiguity and instead allow for variations where radix can be left out. I think there are two alternatives to the current implementation: - only keep parseInt(CharSequence s, int beginIndex, int endIndex, int radix) - optional radix: parseInt(CharSequence s, int beginIndex, int endIndex), parseInt(CharSequence s, int beginIndex, int endIndex, int radix) (Should this discussion be moved to core-libs-dev?) /Claes On 08/14/2014 03:15 PM, roger riggs wrote: > Hi, > > My preference would be to keep the offsets immediately following the > CharSequence, > that clearly identifies the substring being operated on. > > Roger > > > On 8/14/2014 8:00 AM, Alan Bateman wrote: >> On 14/08/2014 12:42, Claes Redestad wrote: >>> >>> Noone brought it up, as far as I can recall. Since parseInt(String, >>> int radix) already existed, I figured adding the range parameters to >>> the end would be overall less awkward than to push the radix >>> parameter right in the new methods. The chosen implementation >>> maintains that the second parameter is always radix, which I think >>> helps maintain consistency. >> I think consistency could be argued both ways as the radix is also >> the last parameter in the existing methods. When I look at this method: >> >> public static int parseInt(CharSequence s, int radix, int beginIndex, >> int endIndex) >> >> and then feels more error prone than if the beginIndex/endIndex were >> immediately after the CharSequence. >> >> I'm interested in other opinions on this. >> >> -Alan. > From Alan.Bateman at oracle.com Thu Aug 14 13:39:27 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Aug 2014 14:39:27 +0100 Subject: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net In-Reply-To: <53ECB838.3070201@oracle.com> References: <53EB6FF5.1050103@oracle.com> <53EC6752.6000601@oracle.com> <53EC822E.6000602@oracle.com> <53EC9DE7.3070007@oracle.com> <53ECA0BC.4070206@oracle.com> <53ECA4DE.5040300@oracle.com> <53ECB662.9030501@oracle.com> <53ECB838.3070201@oracle.com> Message-ID: <53ECBC0F.7060604@oracle.com> On 14/08/2014 14:23, Claes Redestad wrote: > How about methods only taking beginIndex? Integer.parseInt("x: > 10000000", 3, 10)? I guess these could to be dropped > to avoid ambiguity and instead allow for variations where radix can be > left out. > > I think there are two alternatives to the current implementation: > - only keep parseInt(CharSequence s, int beginIndex, int endIndex, int > radix) That's my preference, and core-libs-dev would be the place to move the discussion. -Alan. > - optional radix: parseInt(CharSequence s, int beginIndex, int > endIndex), parseInt(CharSequence s, int beginIndex, int endIndex, int > radix) > > (Should this discussion be moved to core-libs-dev?) > > /Claes From peter.levart at gmail.com Fri Aug 15 08:36:20 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 15 Aug 2014 10:36:20 +0200 Subject: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net In-Reply-To: <53ECA4DE.5040300@oracle.com> References: <53EB6FF5.1050103@oracle.com> <53EC6752.6000601@oracle.com> <53EC822E.6000602@oracle.com> <53EC9DE7.3070007@oracle.com> <53ECA0BC.4070206@oracle.com> <53ECA4DE.5040300@oracle.com> Message-ID: <53EDC684.1060908@gmail.com> On 08/14/2014 02:00 PM, Alan Bateman wrote: > On 14/08/2014 12:42, Claes Redestad wrote: >> >> Noone brought it up, as far as I can recall. Since parseInt(String, >> int radix) already existed, I figured adding the range parameters to >> the end would be overall less awkward than to push the radix >> parameter right in the new methods. The chosen implementation >> maintains that the second parameter is always radix, which I think >> helps maintain consistency. > I think consistency could be argued both ways as the radix is also the > last parameter in the existing methods. When I look at this method: > > public static int parseInt(CharSequence s, int radix, int beginIndex, > int endIndex) > > and then feels more error prone than if the beginIndex/endIndex were > immediately after the CharSequence. > > I'm interested in other opinions on this. > > -Alan. 'radix' parameter could be typed as short. It typically is called with a constant literal and beginIndex/endIndex are usually int expressions. This would catch majority of mistakes where the caller mixes the order. But would not be consistent with public methods though... Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Aug 16 08:33:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 16 Aug 2014 09:33:20 +0100 Subject: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net In-Reply-To: <53ECBC0F.7060604@oracle.com> References: <53EB6FF5.1050103@oracle.com> <53EC6752.6000601@oracle.com> <53EC822E.6000602@oracle.com> <53EC9DE7.3070007@oracle.com> <53ECA0BC.4070206@oracle.com> <53ECA4DE.5040300@oracle.com> <53ECB662.9030501@oracle.com> <53ECB838.3070201@oracle.com> <53ECBC0F.7060604@oracle.com> Message-ID: <53EF1750.7030005@oracle.com> On 14/08/2014 14:39, Alan Bateman wrote: > On 14/08/2014 14:23, Claes Redestad wrote: >> How about methods only taking beginIndex? Integer.parseInt("x: >> 10000000", 3, 10)? I guess these could to be dropped >> to avoid ambiguity and instead allow for variations where radix can >> be left out. >> >> I think there are two alternatives to the current implementation: >> - only keep parseInt(CharSequence s, int beginIndex, int endIndex, >> int radix) > That's my preference, and core-libs-dev would be the place to move the > discussion. I've created JDK-8055251 to track re-examining these methods. -Alan From fweimer at redhat.com Mon Aug 18 15:07:04 2014 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 18 Aug 2014 17:07:04 +0200 Subject: AES GCM slow In-Reply-To: <20140127164647.AD74D64D2@mail.openjdk.java.net> References: <52E6283A.7000401@oracle.com> <52E66AE5.5050303@oracle.com> <20140127164647.AD74D64D2@mail.openjdk.java.net> Message-ID: <53F21698.3090903@redhat.com> On 01/27/2014 05:46 PM, Michael StJohns wrote: > GCM uses a GF2 multiply as part of the integrity calculation. That > operation is pretty expensive. My guess is that if the code was > profiled, you'd find a lot of time being spent in > com.sun.crypto.provider.GHASH. I ran into this and posted a fix: The AES-GCM implementation still conses a lot in unrelated parts of the code, but that's a separate fix. -- Florian Weimer / Red Hat Product Security From fweimer at redhat.com Mon Aug 18 15:10:08 2014 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 18 Aug 2014 17:10:08 +0200 Subject: RFR [9] 8035897 : FD_SETSIZE should be set on macosx In-Reply-To: <53109FD7.5090103@oracle.com> References: <53109FD7.5090103@oracle.com> Message-ID: <53F21750.3000409@redhat.com> On 02/28/2014 03:40 PM, Chris Hegarty wrote: > Either: > 1) FD_SETSIZE needs to be set to a larger value, but what value, the > kernel limit, or other? This is wasteful for most typical apps that > don't use large numbers of file descriptors. Or, > 2) If fd is greater than 1024, then an appropriate amount of memory > could be allocated and cast to an fd_set. The FD_SET macro will > write past FD_SETSIZE. 3) use poll Why do we have to use select here? -- Florian Weimer / Red Hat Product Security From michael.x.mcmahon at oracle.com Mon Aug 18 15:21:43 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 18 Aug 2014 16:21:43 +0100 Subject: sun.net.www.protocol.https.HttpsURLConnectionImpl doesn't equal to self In-Reply-To: References: Message-ID: <53F21A07.6020109@oracle.com> I'll file a bug for this Stanimir. Thanks for reporting it. Should be able to fix it in JDK 9 fairly promptly and we'll see about back porting it then. - Michael. On 18/08/14 15:04, Stanimir Simeonoff wrote: > Hi, > > As the title says there is a major bug with HttpsURLConnection as it breaks > the contract of equals. So the instance cannot be contained (mostly > removed) in any collection reliably. (Concurrent)HashMap has a provision to > test equality by reference prior calling equals, though. > Finding the bug in production is quite a ride as the http variant doesn't > exhibit the problem. > > Here is a simple test case. > > public static void main(String[] args) throws Throwable{ > URLConnection c = new URL("https://oracle.com").openConnection(); > System.out.println(c.getClass().getName()+" equals self: " > +c.equals(c)); > c.getInputStream().close(); > System.out.println(c.getClass().getName()+" equals self: " > +c.equals(c)); > } > > > The culprit is in HttpsURLConnectionImpl.equals that blindly calls > delagate.equals: > > public boolean equals(Object obj) { > return delegate.equals(obj); > } > > It should be changed to: > > public boolean equals(Object obj) { > return this==obj || (obj instanceof HttpsURLConnectionImpl) && > delegate.equals( ((HttpsURLConnectionImpl)obj).delegate ); > } > > > The class has some other issue that involves declaring "finalize" method to > simply call delegate's dispose. The finalize method is unneeded and just > creates unnecessary link in the finalization queue + Finalizer object. > > Thanks > Stanimir From christos at zoulas.com Mon Aug 18 15:36:26 2014 From: christos at zoulas.com (Christos Zoulas) Date: Mon, 18 Aug 2014 11:36:26 -0400 Subject: RFR [9] 8035897 : FD_SETSIZE should be set on macosx In-Reply-To: <53F21750.3000409@redhat.com> from Florian Weimer (Aug 18, 5:10pm) Message-ID: <20140818153626.0B45417FDA3@rebar.astron.com> On Aug 18, 5:10pm, fweimer at redhat.com (Florian Weimer) wrote: -- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx | On 02/28/2014 03:40 PM, Chris Hegarty wrote: | > Either: | > 1) FD_SETSIZE needs to be set to a larger value, but what value, the | > kernel limit, or other? This is wasteful for most typical apps that | > don't use large numbers of file descriptors. Or, | > 2) If fd is greater than 1024, then an appropriate amount of memory | > could be allocated and cast to an fd_set. The FD_SET macro will | > write past FD_SETSIZE. | | 3) use poll | | Why do we have to use select here? Because poll is still broken on UDP sockets. christos From fweimer at redhat.com Mon Aug 18 15:42:53 2014 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 18 Aug 2014 17:42:53 +0200 Subject: RFR [9] 8035897 : FD_SETSIZE should be set on macosx In-Reply-To: <20140818153626.0B45417FDA3@rebar.astron.com> References: <20140818153626.0B45417FDA3@rebar.astron.com> Message-ID: <53F21EFD.1080507@redhat.com> On 08/18/2014 05:36 PM, Christos Zoulas wrote: > On Aug 18, 5:10pm, fweimer at redhat.com (Florian Weimer) wrote: > -- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx > > | On 02/28/2014 03:40 PM, Chris Hegarty wrote: > | > Either: > | > 1) FD_SETSIZE needs to be set to a larger value, but what value, the > | > kernel limit, or other? This is wasteful for most typical apps that > | > don't use large numbers of file descriptors. Or, > | > 2) If fd is greater than 1024, then an appropriate amount of memory > | > could be allocated and cast to an fd_set. The FD_SET macro will > | > write past FD_SETSIZE. > | > | 3) use poll > | > | Why do we have to use select here? > > Because poll is still broken on UDP sockets. Ugh. Can you provide details, such as affected platforms? Thanks. -- Florian Weimer / Red Hat Product Security From christos at zoulas.com Mon Aug 18 16:08:13 2014 From: christos at zoulas.com (Christos Zoulas) Date: Mon, 18 Aug 2014 12:08:13 -0400 Subject: RFR [9] 8035897 : FD_SETSIZE should be set on macosx In-Reply-To: <53F21EFD.1080507@redhat.com> from Florian Weimer (Aug 18, 5:42pm) Message-ID: <20140818160813.3F1EA17FDA7@rebar.astron.com> On Aug 18, 5:42pm, fweimer at redhat.com (Florian Weimer) wrote: -- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx | On 08/18/2014 05:36 PM, Christos Zoulas wrote: | > On Aug 18, 5:10pm, fweimer at redhat.com (Florian Weimer) wrote: | > -- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx | > | > | On 02/28/2014 03:40 PM, Chris Hegarty wrote: | > | > Either: | > | > 1) FD_SETSIZE needs to be set to a larger value, but what value, the | > | > kernel limit, or other? This is wasteful for most typical apps that | > | > don't use large numbers of file descriptors. Or, | > | > 2) If fd is greater than 1024, then an appropriate amount of memory | > | > could be allocated and cast to an fd_set. The FD_SET macro will | > | > write past FD_SETSIZE. | > | | > | 3) use poll | > | | > | Why do we have to use select here? | > | > Because poll is still broken on UDP sockets. | | Ugh. Can you provide details, such as affected platforms? Thanks. Just macos/x. Empty UDP packets don't make poll fire. https://bugs.openjdk.java.net/browse/JDK-7131399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel christos From peter.levart at gmail.com Tue Aug 19 10:51:11 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 19 Aug 2014 12:51:11 +0200 Subject: RFR JDK-8049228: Improve multithreaded scalability of InetAddress cache In-Reply-To: <53BD2D05.8080100@gmail.com> References: <53B2FF8D.5040503@gmail.com> <20140701220621.00005e21.bernd-2014@eckenfels.net> <53B3F377.3090208@gmail.com> <53BA7DA3.70205@oracle.com> <53BA9C40.3080402@gmail.com> <53BAAB14.1010907@oracle.com> <53BD2D05.8080100@gmail.com> Message-ID: <53F32C1F.2020800@gmail.com> Hi Michael, I have re-based the patch to the new jdk9 source layout. Nothing changes from the webrev.03 except paths: http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.04/ Regards, Peter On 07/09/2014 01:52 PM, Peter Levart wrote: > Hi Michael, > > Thanks for testing. I have prepared another webrev: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.03/ > > It only cleans up two comments suggested by Bernd (removed superfluous > phrase "with 0" from statements about comparing time instants). So do > you think this needs more testing / another review or can I consider > this reviewed for jdk9-dev ? > > Regards, Peter > > > On 07/07/2014 04:13 PM, Michael McMahon wrote: >> Peter, >> >> Thanks for the explanation. No. I think your change is good. I've run >> tests here locally >> and I'm happy with it overall. >> >> Michael >> >> On 07/07/14 14:10, Peter Levart wrote: >>> On 07/07/2014 12:59 PM, Michael McMahon wrote: >>>> Hi Peter, >>>> >>>> Is it necessary to remove the cache entry in the local host case >>>> (L1226) ? >>>> It seems redundant to cache it here, and also explicitly in the >>>> CachedLocalHost object >>>> >>>> Michael >>> >>> Hi Michael, >>> >>> Thanks for looking into this. >>> >>> getLocalHost() seems to have a special hard-coded policy of positive >>> caching for 5 seconds that is independent of general getByName() >>> caching policy (30 seconds by default). The behaviour of original >>> code that I'm trying to replicate is such that when getLocalHost() >>> notices a change of local host name -> address mapping, the mapping >>> in global cache for this change is also updated. I think this is to >>> avoid situations like: >>> >>> Let's say the local host name is "cube": >>> >>> InetAddress addr1 = InetAddress.getLocalHost(); >>> InetAddress addr2 = InetAddress.getByName("cube"); >>> // addr1.equals(addr2) here >>> >>> // 5 seconds later, cube -> IP mapping is updated in DNS or >>> /etc/hosts ... >>> >>> addr1 = InetAddress.getLocalHost(); >>> addr2 = InetAddress.getByName("cube"); >>> // if getLocalHost() did not update global cache, >>> // addr1 (new IP address) would be different from addr2 (old IP >>> address) >>> >>> >>> Another way to accomplish similar guarantee would be to special-case >>> the caching policy in global cache which would check whether the >>> entry is for local host name and set 'expiryTime' accordingly. This >>> would be a little different behaviourally, because >>> InetAddress.getByName() would get a 5 second expiry for local host >>> name too, regardless of whether InetAddress.getLocalHost() has been >>> called at all. But we could get rid of special CachedLocalHost class >>> then. Is such behavioural change warranted? >>> >>> Regards, Peter >>> >>>> >>>> On 02/07/14 12:56, Peter Levart wrote: >>>>> Hi, >>>>> >>>>> I updated the webrev with first two suggestions from Bernd >>>>> (expireTime instead of createTime and cacheNanos + only use >>>>> putIfAbsent instead of get followed by putIfAbsent): >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.02/ >>>>> >>>>> >>>>> Thanks, Bernd. >>>>> >>>>> The id field in CachedAddresses is necessary for compareTo to >>>>> never return 0 for two different instances (used as element in >>>>> ConcurrentSkipListSet). >>>>> >>>>> For last two suggestions I'm not sure whether they are desired, so >>>>> I'm currently leaving them as is. >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> On 07/01/2014 10:06 PM, Bernd Eckenfels wrote: >>>>>> Looks good, like it, Peter. >>>>>> >>>>>> some nits: instead of adding createTime and cacheNanos, only have a >>>>>> expireAfter? >>>>>> >>>>>> L782: is it better to use putIfAbsent unconditionally, instead of >>>>>> get/putIfAbsent in NameServicdeAddr? >>>>>> >>>>>> L732: I am unsure about the id field, isnt it enough to have the >>>>>> identity equality check for the replacement check and otherwise >>>>>> depend >>>>>> on equals()? >>>>>> >>>>>> L1223: What about moving the cache exiry inside the if (useCache) >>>>>> >>>>>> BTW1: might be the wrong RFR, but considering your good performance >>>>>> numbers for an active cache, would having 100ms or similiar default >>>>>> negative cache time make sense without impacting (visible) the >>>>>> semantic. >>>>>> >>>>>> >>>>>> >>>>>> Gruss >>>>>> Bernd >>>>>> >>>>>> >>>>>> Am Tue, 01 Jul 2014 20:35:57 +0200 >>>>>> schrieb Peter Levart : >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I propose a patch for this issue: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-7186258 >>>>>>> >>>>>>> The motivation to re-design caching of InetAddress-es was not this >>>>>>> issue though, but a desire to attack synchronization bottlenecks in >>>>>>> methods like URL.equals and URL.hashCode which use host name to IP >>>>>>> address mapping. I plan to tackle the synchronization in URL in a >>>>>>> follow-up proposal, but I wanted to 1st iron-out the "leaves" of >>>>>>> the >>>>>>> call-tree. Here's the proposed patch: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.01/ >>>>>>> >>>>>>> >>>>>>> sun.net.InetAddressCachePolicy: >>>>>>> >>>>>>> - two static methods (get() and getNegative()) were synchronized. >>>>>>> Removed synchronization and made underlying fields volatile. >>>>>>> - also added a normalization of negative policy in >>>>>>> setNegativeIfNotSet(). The logic in InetAddress doesn't cope with >>>>>>> negative values distinct from InetAddressCachePolicy.FOREVER >>>>>>> (-1), so >>>>>>> this was a straight bug. The setIfNotSet() doesn't need this >>>>>>> normalization, because checkValue() throws exception if passed-in >>>>>>> value < InetAddressCachePolicy.FOREVER. >>>>>>> >>>>>>> java.net.InetAddress: >>>>>>> >>>>>>> - complete redesign of caching. Instead of distinct >>>>>>> Positive/Negative >>>>>>> caches, there's only one cache - a ConcurrentHashMap. The value in >>>>>>> the map knows if it contains positive or negative answer. >>>>>>> - the design of this cache is similar but much simpler than >>>>>>> java.lang.reflect.WeakCache, since it doesn't have to deal with >>>>>>> WeakReferences and keys are simpler (just strings - hostnames). >>>>>>> Similarity is in how concurrent requests for the same key >>>>>>> (hostname) >>>>>>> are synchronized when the entry is not cached yet, but still avoid >>>>>>> synchronization when entry is cached. This preserves the >>>>>>> behaviour of >>>>>>> original InetAddress caching code but simplifies it greatly (100+ >>>>>>> lines removed). >>>>>>> - I tried to preserve the interaction between >>>>>>> InetAddress.getLocalHost() and InetAddress.getByName(). The >>>>>>> getLocalHost() caches the local host address for 5 seconds >>>>>>> privately. >>>>>>> When it expires it performs new name service look-up and >>>>>>> "refreshes" >>>>>>> the entry in the InetAddress.getByName() cache although it has not >>>>>>> expired yet. I think this is meant to prevent surprises when >>>>>>> getLocalHost() returns newer address than getByName() which is >>>>>>> called >>>>>>> after that. >>>>>>> - I also fixed the JDK-7186258 as a by-product (but don't know yet >>>>>>> how to write a test for this issue - any ideas?) >>>>>>> >>>>>>> I created a JMH benchmark that tests the following methods: >>>>>>> >>>>>>> - InetAddress.getLocalHost() >>>>>>> - InetAddress.getByName() (with positive and negative answer) >>>>>>> >>>>>>> Here're the results of running on my 4-core (8-threads) i7/Linux: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/InetAddress.Cache_bench_results.01.pdf >>>>>>> >>>>>>> >>>>>>> >>>>>>> The getByNameNegative() test does not show much improvement in >>>>>>> patched vs. original code. That's because by default the policy >>>>>>> is to >>>>>>> NOT cache negative answers. Requests for same hostname to the >>>>>>> NameService(s) are synchronized. If >>>>>>> "networkaddress.cache.negative.ttl" system property is set to some >>>>>>> positive value, results are similar to those of getByNamePositive() >>>>>>> test (the default policy for positive caching is 30 seconds). >>>>>>> >>>>>>> I ran the jtreg tests in test/java/net and have the same score as >>>>>>> with original unpatched code. I have 3 failing tests from original >>>>>>> and patched runs: >>>>>>> >>>>>>> JT Harness : Tests that failed >>>>>>> java/net/MulticastSocket/Promiscuous.java: Test for interference >>>>>>> when >>>>>>> two sockets are bound to the same port but joined to different >>>>>>> multicast groups >>>>>>> java/net/MulticastSocket/SetLoopbackMode.java: Test >>>>>>> MulticastSocket.setLoopbackMode >>>>>>> java/net/MulticastSocket/Test.java: IPv4 and IPv6 multicasting >>>>>>> broken >>>>>>> on Linux >>>>>>> >>>>>>> And 1 test that had error trying to be run: >>>>>>> >>>>>>> JT Harness : Tests that had errors >>>>>>> java/net/URLPermission/nstest/lookup.sh: >>>>>>> >>>>>>> Because of: >>>>>>> >>>>>>> test result: Error. Can't find source file: >>>>>>> jdk/testlibrary/*.java in >>>>>>> directory-list: >>>>>>> /home/peter/work/hg/jdk9-dev/jdk/test/java/net/URLPermission/nstest >>>>>>> /home/peter/work/hg/jdk9-dev/jdk/test/lib/testlibrary >>>>>>> >>>>>>> All other 258 java/net tests pass. >>>>>>> >>>>>>> >>>>>>> >>>>>>> So what do you think? >>>>>>> >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>> >>>>> >>>> >>> >> > From michael.x.mcmahon at oracle.com Wed Aug 20 12:47:59 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 20 Aug 2014 13:47:59 +0100 Subject: RFR JDK-8049228: Improve multithreaded scalability of InetAddress cache In-Reply-To: <53F32C1F.2020800@gmail.com> References: <53B2FF8D.5040503@gmail.com> <20140701220621.00005e21.bernd-2014@eckenfels.net> <53B3F377.3090208@gmail.com> <53BA7DA3.70205@oracle.com> <53BA9C40.3080402@gmail.com> <53BAAB14.1010907@oracle.com> <53BD2D05.8080100@gmail.com> <53F32C1F.2020800@gmail.com> Message-ID: <53F498FF.5080205@oracle.com> This still looks fine to me Peter. Thanks Michael On 19/08/14 11:51, Peter Levart wrote: > Hi Michael, > > I have re-based the patch to the new jdk9 source layout. Nothing > changes from the webrev.03 except paths: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.04/ > > > Regards, Peter > > On 07/09/2014 01:52 PM, Peter Levart wrote: >> Hi Michael, >> >> Thanks for testing. I have prepared another webrev: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.03/ >> >> >> It only cleans up two comments suggested by Bernd (removed >> superfluous phrase "with 0" from statements about comparing time >> instants). So do you think this needs more testing / another review >> or can I consider this reviewed for jdk9-dev ? >> >> Regards, Peter >> >> >> On 07/07/2014 04:13 PM, Michael McMahon wrote: >>> Peter, >>> >>> Thanks for the explanation. No. I think your change is good. I've >>> run tests here locally >>> and I'm happy with it overall. >>> >>> Michael >>> >>> On 07/07/14 14:10, Peter Levart wrote: >>>> On 07/07/2014 12:59 PM, Michael McMahon wrote: >>>>> Hi Peter, >>>>> >>>>> Is it necessary to remove the cache entry in the local host case >>>>> (L1226) ? >>>>> It seems redundant to cache it here, and also explicitly in the >>>>> CachedLocalHost object >>>>> >>>>> Michael >>>> >>>> Hi Michael, >>>> >>>> Thanks for looking into this. >>>> >>>> getLocalHost() seems to have a special hard-coded policy of >>>> positive caching for 5 seconds that is independent of general >>>> getByName() caching policy (30 seconds by default). The behaviour >>>> of original code that I'm trying to replicate is such that when >>>> getLocalHost() notices a change of local host name -> address >>>> mapping, the mapping in global cache for this change is also >>>> updated. I think this is to avoid situations like: >>>> >>>> Let's say the local host name is "cube": >>>> >>>> InetAddress addr1 = InetAddress.getLocalHost(); >>>> InetAddress addr2 = InetAddress.getByName("cube"); >>>> // addr1.equals(addr2) here >>>> >>>> // 5 seconds later, cube -> IP mapping is updated in DNS or >>>> /etc/hosts ... >>>> >>>> addr1 = InetAddress.getLocalHost(); >>>> addr2 = InetAddress.getByName("cube"); >>>> // if getLocalHost() did not update global cache, >>>> // addr1 (new IP address) would be different from addr2 (old IP >>>> address) >>>> >>>> >>>> Another way to accomplish similar guarantee would be to >>>> special-case the caching policy in global cache which would check >>>> whether the entry is for local host name and set 'expiryTime' >>>> accordingly. This would be a little different behaviourally, >>>> because InetAddress.getByName() would get a 5 second expiry for >>>> local host name too, regardless of whether >>>> InetAddress.getLocalHost() has been called at all. But we could get >>>> rid of special CachedLocalHost class then. Is such behavioural >>>> change warranted? >>>> >>>> Regards, Peter >>>> >>>>> >>>>> On 02/07/14 12:56, Peter Levart wrote: >>>>>> Hi, >>>>>> >>>>>> I updated the webrev with first two suggestions from Bernd >>>>>> (expireTime instead of createTime and cacheNanos + only use >>>>>> putIfAbsent instead of get followed by putIfAbsent): >>>>>> >>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.02/ >>>>>> >>>>>> >>>>>> Thanks, Bernd. >>>>>> >>>>>> The id field in CachedAddresses is necessary for compareTo to >>>>>> never return 0 for two different instances (used as element in >>>>>> ConcurrentSkipListSet). >>>>>> >>>>>> For last two suggestions I'm not sure whether they are desired, >>>>>> so I'm currently leaving them as is. >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> On 07/01/2014 10:06 PM, Bernd Eckenfels wrote: >>>>>>> Looks good, like it, Peter. >>>>>>> >>>>>>> some nits: instead of adding createTime and cacheNanos, only have a >>>>>>> expireAfter? >>>>>>> >>>>>>> L782: is it better to use putIfAbsent unconditionally, instead of >>>>>>> get/putIfAbsent in NameServicdeAddr? >>>>>>> >>>>>>> L732: I am unsure about the id field, isnt it enough to have the >>>>>>> identity equality check for the replacement check and otherwise >>>>>>> depend >>>>>>> on equals()? >>>>>>> >>>>>>> L1223: What about moving the cache exiry inside the if (useCache) >>>>>>> >>>>>>> BTW1: might be the wrong RFR, but considering your good performance >>>>>>> numbers for an active cache, would having 100ms or similiar default >>>>>>> negative cache time make sense without impacting (visible) the >>>>>>> semantic. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Gruss >>>>>>> Bernd >>>>>>> >>>>>>> >>>>>>> Am Tue, 01 Jul 2014 20:35:57 +0200 >>>>>>> schrieb Peter Levart : >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I propose a patch for this issue: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7186258 >>>>>>>> >>>>>>>> The motivation to re-design caching of InetAddress-es was not this >>>>>>>> issue though, but a desire to attack synchronization >>>>>>>> bottlenecks in >>>>>>>> methods like URL.equals and URL.hashCode which use host name to IP >>>>>>>> address mapping. I plan to tackle the synchronization in URL in a >>>>>>>> follow-up proposal, but I wanted to 1st iron-out the "leaves" >>>>>>>> of the >>>>>>>> call-tree. Here's the proposed patch: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> sun.net.InetAddressCachePolicy: >>>>>>>> >>>>>>>> - two static methods (get() and getNegative()) were synchronized. >>>>>>>> Removed synchronization and made underlying fields volatile. >>>>>>>> - also added a normalization of negative policy in >>>>>>>> setNegativeIfNotSet(). The logic in InetAddress doesn't cope with >>>>>>>> negative values distinct from InetAddressCachePolicy.FOREVER >>>>>>>> (-1), so >>>>>>>> this was a straight bug. The setIfNotSet() doesn't need this >>>>>>>> normalization, because checkValue() throws exception if passed-in >>>>>>>> value < InetAddressCachePolicy.FOREVER. >>>>>>>> >>>>>>>> java.net.InetAddress: >>>>>>>> >>>>>>>> - complete redesign of caching. Instead of distinct >>>>>>>> Positive/Negative >>>>>>>> caches, there's only one cache - a ConcurrentHashMap. The value in >>>>>>>> the map knows if it contains positive or negative answer. >>>>>>>> - the design of this cache is similar but much simpler than >>>>>>>> java.lang.reflect.WeakCache, since it doesn't have to deal with >>>>>>>> WeakReferences and keys are simpler (just strings - hostnames). >>>>>>>> Similarity is in how concurrent requests for the same key >>>>>>>> (hostname) >>>>>>>> are synchronized when the entry is not cached yet, but still avoid >>>>>>>> synchronization when entry is cached. This preserves the >>>>>>>> behaviour of >>>>>>>> original InetAddress caching code but simplifies it greatly (100+ >>>>>>>> lines removed). >>>>>>>> - I tried to preserve the interaction between >>>>>>>> InetAddress.getLocalHost() and InetAddress.getByName(). The >>>>>>>> getLocalHost() caches the local host address for 5 seconds >>>>>>>> privately. >>>>>>>> When it expires it performs new name service look-up and >>>>>>>> "refreshes" >>>>>>>> the entry in the InetAddress.getByName() cache although it has not >>>>>>>> expired yet. I think this is meant to prevent surprises when >>>>>>>> getLocalHost() returns newer address than getByName() which is >>>>>>>> called >>>>>>>> after that. >>>>>>>> - I also fixed the JDK-7186258 as a by-product (but don't know yet >>>>>>>> how to write a test for this issue - any ideas?) >>>>>>>> >>>>>>>> I created a JMH benchmark that tests the following methods: >>>>>>>> >>>>>>>> - InetAddress.getLocalHost() >>>>>>>> - InetAddress.getByName() (with positive and negative answer) >>>>>>>> >>>>>>>> Here're the results of running on my 4-core (8-threads) i7/Linux: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/InetAddress.Cache_bench_results.01.pdf >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The getByNameNegative() test does not show much improvement in >>>>>>>> patched vs. original code. That's because by default the policy >>>>>>>> is to >>>>>>>> NOT cache negative answers. Requests for same hostname to the >>>>>>>> NameService(s) are synchronized. If >>>>>>>> "networkaddress.cache.negative.ttl" system property is set to some >>>>>>>> positive value, results are similar to those of >>>>>>>> getByNamePositive() >>>>>>>> test (the default policy for positive caching is 30 seconds). >>>>>>>> >>>>>>>> I ran the jtreg tests in test/java/net and have the same score as >>>>>>>> with original unpatched code. I have 3 failing tests from original >>>>>>>> and patched runs: >>>>>>>> >>>>>>>> JT Harness : Tests that failed >>>>>>>> java/net/MulticastSocket/Promiscuous.java: Test for >>>>>>>> interference when >>>>>>>> two sockets are bound to the same port but joined to different >>>>>>>> multicast groups >>>>>>>> java/net/MulticastSocket/SetLoopbackMode.java: Test >>>>>>>> MulticastSocket.setLoopbackMode >>>>>>>> java/net/MulticastSocket/Test.java: IPv4 and IPv6 multicasting >>>>>>>> broken >>>>>>>> on Linux >>>>>>>> >>>>>>>> And 1 test that had error trying to be run: >>>>>>>> >>>>>>>> JT Harness : Tests that had errors >>>>>>>> java/net/URLPermission/nstest/lookup.sh: >>>>>>>> >>>>>>>> Because of: >>>>>>>> >>>>>>>> test result: Error. Can't find source file: >>>>>>>> jdk/testlibrary/*.java in >>>>>>>> directory-list: >>>>>>>> /home/peter/work/hg/jdk9-dev/jdk/test/java/net/URLPermission/nstest >>>>>>>> >>>>>>>> /home/peter/work/hg/jdk9-dev/jdk/test/lib/testlibrary >>>>>>>> >>>>>>>> All other 258 java/net tests pass. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> So what do you think? >>>>>>>> >>>>>>>> >>>>>>>> Regards, Peter >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From michael.x.mcmahon at oracle.com Wed Aug 20 13:02:35 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 20 Aug 2014 14:02:35 +0100 Subject: RFR: 8055299 HttpsURLConnection.equals() broken Message-ID: <53F49C6B.7080807@oracle.com> This is the recently reported fix to HttpsURLConnection.equals http://cr.openjdk.java.net/~michaelm/8055299/webrev.1/ The fix includes a test. Not shown in the webrev is java key store file called testkeys, which is copied from another location in the test tree and is to be installed in the same directory as the new test. Thanks Michael From peter.levart at gmail.com Wed Aug 20 16:28:45 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 20 Aug 2014 18:28:45 +0200 Subject: RFR JDK-8049228: Improve multithreaded scalability of InetAddress cache In-Reply-To: <53F498FF.5080205@oracle.com> References: <53B2FF8D.5040503@gmail.com> <20140701220621.00005e21.bernd-2014@eckenfels.net> <53B3F377.3090208@gmail.com> <53BA7DA3.70205@oracle.com> <53BA9C40.3080402@gmail.com> <53BAAB14.1010907@oracle.com> <53BD2D05.8080100@gmail.com> <53F32C1F.2020800@gmail.com> <53F498FF.5080205@oracle.com> Message-ID: <53F4CCBD.4050101@gmail.com> On 08/20/2014 02:47 PM, Michael McMahon wrote: > This still looks fine to me Peter. > > Thanks > Michael Hi Michael, Do I need another reviewer to push this to jdk9-dev ? I don't have a clear picture about how many reviewers are needed for what parts of JDK code. Regards, Peter > > On 19/08/14 11:51, Peter Levart wrote: >> Hi Michael, >> >> I have re-based the patch to the new jdk9 source layout. Nothing >> changes from the webrev.03 except paths: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.04/ >> >> >> >> Regards, Peter >> >> On 07/09/2014 01:52 PM, Peter Levart wrote: >>> Hi Michael, >>> >>> Thanks for testing. I have prepared another webrev: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.03/ >>> >>> >>> It only cleans up two comments suggested by Bernd (removed >>> superfluous phrase "with 0" from statements about comparing time >>> instants). So do you think this needs more testing / another review >>> or can I consider this reviewed for jdk9-dev ? >>> >>> Regards, Peter >>> >>> >>> On 07/07/2014 04:13 PM, Michael McMahon wrote: >>>> Peter, >>>> >>>> Thanks for the explanation. No. I think your change is good. I've >>>> run tests here locally >>>> and I'm happy with it overall. >>>> >>>> Michael >>>> >>>> On 07/07/14 14:10, Peter Levart wrote: >>>>> On 07/07/2014 12:59 PM, Michael McMahon wrote: >>>>>> Hi Peter, >>>>>> >>>>>> Is it necessary to remove the cache entry in the local host case >>>>>> (L1226) ? >>>>>> It seems redundant to cache it here, and also explicitly in the >>>>>> CachedLocalHost object >>>>>> >>>>>> Michael >>>>> >>>>> Hi Michael, >>>>> >>>>> Thanks for looking into this. >>>>> >>>>> getLocalHost() seems to have a special hard-coded policy of >>>>> positive caching for 5 seconds that is independent of general >>>>> getByName() caching policy (30 seconds by default). The behaviour >>>>> of original code that I'm trying to replicate is such that when >>>>> getLocalHost() notices a change of local host name -> address >>>>> mapping, the mapping in global cache for this change is also >>>>> updated. I think this is to avoid situations like: >>>>> >>>>> Let's say the local host name is "cube": >>>>> >>>>> InetAddress addr1 = InetAddress.getLocalHost(); >>>>> InetAddress addr2 = InetAddress.getByName("cube"); >>>>> // addr1.equals(addr2) here >>>>> >>>>> // 5 seconds later, cube -> IP mapping is updated in DNS or >>>>> /etc/hosts ... >>>>> >>>>> addr1 = InetAddress.getLocalHost(); >>>>> addr2 = InetAddress.getByName("cube"); >>>>> // if getLocalHost() did not update global cache, >>>>> // addr1 (new IP address) would be different from addr2 (old IP >>>>> address) >>>>> >>>>> >>>>> Another way to accomplish similar guarantee would be to >>>>> special-case the caching policy in global cache which would check >>>>> whether the entry is for local host name and set 'expiryTime' >>>>> accordingly. This would be a little different behaviourally, >>>>> because InetAddress.getByName() would get a 5 second expiry for >>>>> local host name too, regardless of whether >>>>> InetAddress.getLocalHost() has been called at all. But we could >>>>> get rid of special CachedLocalHost class then. Is such behavioural >>>>> change warranted? >>>>> >>>>> Regards, Peter >>>>> >>>>>> >>>>>> On 02/07/14 12:56, Peter Levart wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I updated the webrev with first two suggestions from Bernd >>>>>>> (expireTime instead of createTime and cacheNanos + only use >>>>>>> putIfAbsent instead of get followed by putIfAbsent): >>>>>>> >>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.02/ >>>>>>> >>>>>>> >>>>>>> Thanks, Bernd. >>>>>>> >>>>>>> The id field in CachedAddresses is necessary for compareTo to >>>>>>> never return 0 for two different instances (used as element in >>>>>>> ConcurrentSkipListSet). >>>>>>> >>>>>>> For last two suggestions I'm not sure whether they are desired, >>>>>>> so I'm currently leaving them as is. >>>>>>> >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>> On 07/01/2014 10:06 PM, Bernd Eckenfels wrote: >>>>>>>> Looks good, like it, Peter. >>>>>>>> >>>>>>>> some nits: instead of adding createTime and cacheNanos, only >>>>>>>> have a >>>>>>>> expireAfter? >>>>>>>> >>>>>>>> L782: is it better to use putIfAbsent unconditionally, instead of >>>>>>>> get/putIfAbsent in NameServicdeAddr? >>>>>>>> >>>>>>>> L732: I am unsure about the id field, isnt it enough to have the >>>>>>>> identity equality check for the replacement check and otherwise >>>>>>>> depend >>>>>>>> on equals()? >>>>>>>> >>>>>>>> L1223: What about moving the cache exiry inside the if (useCache) >>>>>>>> >>>>>>>> BTW1: might be the wrong RFR, but considering your good >>>>>>>> performance >>>>>>>> numbers for an active cache, would having 100ms or similiar >>>>>>>> default >>>>>>>> negative cache time make sense without impacting (visible) the >>>>>>>> semantic. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Gruss >>>>>>>> Bernd >>>>>>>> >>>>>>>> >>>>>>>> Am Tue, 01 Jul 2014 20:35:57 +0200 >>>>>>>> schrieb Peter Levart : >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I propose a patch for this issue: >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7186258 >>>>>>>>> >>>>>>>>> The motivation to re-design caching of InetAddress-es was not >>>>>>>>> this >>>>>>>>> issue though, but a desire to attack synchronization >>>>>>>>> bottlenecks in >>>>>>>>> methods like URL.equals and URL.hashCode which use host name >>>>>>>>> to IP >>>>>>>>> address mapping. I plan to tackle the synchronization in URL in a >>>>>>>>> follow-up proposal, but I wanted to 1st iron-out the "leaves" >>>>>>>>> of the >>>>>>>>> call-tree. Here's the proposed patch: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> sun.net.InetAddressCachePolicy: >>>>>>>>> >>>>>>>>> - two static methods (get() and getNegative()) were synchronized. >>>>>>>>> Removed synchronization and made underlying fields volatile. >>>>>>>>> - also added a normalization of negative policy in >>>>>>>>> setNegativeIfNotSet(). The logic in InetAddress doesn't cope with >>>>>>>>> negative values distinct from InetAddressCachePolicy.FOREVER >>>>>>>>> (-1), so >>>>>>>>> this was a straight bug. The setIfNotSet() doesn't need this >>>>>>>>> normalization, because checkValue() throws exception if passed-in >>>>>>>>> value < InetAddressCachePolicy.FOREVER. >>>>>>>>> >>>>>>>>> java.net.InetAddress: >>>>>>>>> >>>>>>>>> - complete redesign of caching. Instead of distinct >>>>>>>>> Positive/Negative >>>>>>>>> caches, there's only one cache - a ConcurrentHashMap. The >>>>>>>>> value in >>>>>>>>> the map knows if it contains positive or negative answer. >>>>>>>>> - the design of this cache is similar but much simpler than >>>>>>>>> java.lang.reflect.WeakCache, since it doesn't have to deal with >>>>>>>>> WeakReferences and keys are simpler (just strings - hostnames). >>>>>>>>> Similarity is in how concurrent requests for the same key >>>>>>>>> (hostname) >>>>>>>>> are synchronized when the entry is not cached yet, but still >>>>>>>>> avoid >>>>>>>>> synchronization when entry is cached. This preserves the >>>>>>>>> behaviour of >>>>>>>>> original InetAddress caching code but simplifies it greatly (100+ >>>>>>>>> lines removed). >>>>>>>>> - I tried to preserve the interaction between >>>>>>>>> InetAddress.getLocalHost() and InetAddress.getByName(). The >>>>>>>>> getLocalHost() caches the local host address for 5 seconds >>>>>>>>> privately. >>>>>>>>> When it expires it performs new name service look-up and >>>>>>>>> "refreshes" >>>>>>>>> the entry in the InetAddress.getByName() cache although it has >>>>>>>>> not >>>>>>>>> expired yet. I think this is meant to prevent surprises when >>>>>>>>> getLocalHost() returns newer address than getByName() which is >>>>>>>>> called >>>>>>>>> after that. >>>>>>>>> - I also fixed the JDK-7186258 as a by-product (but don't know >>>>>>>>> yet >>>>>>>>> how to write a test for this issue - any ideas?) >>>>>>>>> >>>>>>>>> I created a JMH benchmark that tests the following methods: >>>>>>>>> >>>>>>>>> - InetAddress.getLocalHost() >>>>>>>>> - InetAddress.getByName() (with positive and negative answer) >>>>>>>>> >>>>>>>>> Here're the results of running on my 4-core (8-threads) i7/Linux: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/InetAddress.Cache_bench_results.01.pdf >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The getByNameNegative() test does not show much improvement in >>>>>>>>> patched vs. original code. That's because by default the >>>>>>>>> policy is to >>>>>>>>> NOT cache negative answers. Requests for same hostname to the >>>>>>>>> NameService(s) are synchronized. If >>>>>>>>> "networkaddress.cache.negative.ttl" system property is set to >>>>>>>>> some >>>>>>>>> positive value, results are similar to those of >>>>>>>>> getByNamePositive() >>>>>>>>> test (the default policy for positive caching is 30 seconds). >>>>>>>>> >>>>>>>>> I ran the jtreg tests in test/java/net and have the same score as >>>>>>>>> with original unpatched code. I have 3 failing tests from >>>>>>>>> original >>>>>>>>> and patched runs: >>>>>>>>> >>>>>>>>> JT Harness : Tests that failed >>>>>>>>> java/net/MulticastSocket/Promiscuous.java: Test for >>>>>>>>> interference when >>>>>>>>> two sockets are bound to the same port but joined to different >>>>>>>>> multicast groups >>>>>>>>> java/net/MulticastSocket/SetLoopbackMode.java: Test >>>>>>>>> MulticastSocket.setLoopbackMode >>>>>>>>> java/net/MulticastSocket/Test.java: IPv4 and IPv6 multicasting >>>>>>>>> broken >>>>>>>>> on Linux >>>>>>>>> >>>>>>>>> And 1 test that had error trying to be run: >>>>>>>>> >>>>>>>>> JT Harness : Tests that had errors >>>>>>>>> java/net/URLPermission/nstest/lookup.sh: >>>>>>>>> >>>>>>>>> Because of: >>>>>>>>> >>>>>>>>> test result: Error. Can't find source file: >>>>>>>>> jdk/testlibrary/*.java in >>>>>>>>> directory-list: >>>>>>>>> /home/peter/work/hg/jdk9-dev/jdk/test/java/net/URLPermission/nstest >>>>>>>>> >>>>>>>>> /home/peter/work/hg/jdk9-dev/jdk/test/lib/testlibrary >>>>>>>>> >>>>>>>>> All other 258 java/net tests pass. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> So what do you think? >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, Peter >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Thu Aug 21 11:33:36 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 21 Aug 2014 12:33:36 +0100 Subject: RFR 8055747: Move SimpleSSLContext to jdk/testlibrary Message-ID: <53F5D910.5070009@oracle.com> Before I push the other change to HttpsURLConnection, I'd like to make this change to stop the proliferation of binary testkeys files in the test tree and make the SimpleSSLContext class more accessible. http://cr.openjdk.java.net/~michaelm/8055747/webrev.01/ Thanks, Michael From mark.sheppard at oracle.com Thu Aug 21 15:31:14 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 21 Aug 2014 16:31:14 +0100 Subject: RFR: JDK-8035571 - Check jdk/src/windows/native/java/net/TwoStacksPlain* for JNI pending exceptions In-Reply-To: <53220E5E.4080004@oracle.com> References: <53220E5E.4080004@oracle.com> Message-ID: <53F610C2.5020903@oracle.com> Hi, please oblige and review the updated webrev http://cr.openjdk.java.net/~msheppar/8035571/webrev.02/ for the issue https://bugs.openjdk.java.net/browse/JDK-8035571 this is applying the previous un-reviewed patch to the updated jdk9 modular src structure. regards Mark -------- Original Message -------- Subject: RFR: JDK-8035571 - Check jdk/src/windows/native/java/net/TwoStacksPlain* for JNI pending exceptions Date: Thu, 13 Mar 2014 20:00:30 +0000 From: Mark Sheppard Organization: Oracle Corporation To: OpenJDK Network Dev list Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8035571/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8035571 summary: JNI return value and pending exception checks added -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.sheppard at oracle.com Thu Aug 21 16:02:00 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 21 Aug 2014 17:02:00 +0100 Subject: RFR: JDK-8044306 - java.net.Inet4AddressImpl.getLocalHostName() uses IPv6 rather than IPv4 Message-ID: <53F617F8.5060106@oracle.com> Hi please oblige and review the small change http://cr.openjdk.java.net/~msheppar/8044306/webrev/ to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8044306 hints.ai_family is assigned AF_INET rather than AF_UNSPEC as the native function Java_java_net_Inet4AddressImpl_getLocalHostName is part of an IPv4 call flow, such that AF_UNSPEC allows an IPv6 data to be retrieved as highlighted in bug report regards Mark From sean.coffey at oracle.com Fri Aug 22 15:24:08 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 22 Aug 2014 16:24:08 +0100 Subject: RFR : 8032808, 8047186, 8029607, 8048212 - SO_FLOW_SLA support for solaris, Set TOS in IPv6 header Message-ID: <53F76098.3010108@oracle.com> I'd like to backport these fixes into the jdk7u-dev codeline. They're already in jdk8u-dev. https://bugs.openjdk.java.net/browse/JDK-8032808 - SO_FLOW_SLA support for solaris https://bugs.openjdk.java.net/browse/JDK-8047186 - Exception handling change linked to above https://bugs.openjdk.java.net/browse/JDK-8029607 - Set TOS in IPv6 header https://bugs.openjdk.java.net/browse/JDK-8048212 - Testcase failure with above fix some of the changes are quite different from jdk8u in that the make system is different. I've put some of the main differences in bullet points : * new makefiles to capture the jdk/net classes * Different javadoc makefile layout for 7u * static src/share/native/java/net/jdk_net_SocketFlow.h header file (dynamic in jdk8u) * Alter src/share/classes/jdk/net/Sockets.java : - throw new Error(e); instead of throw new InternalError(e); (older API) * removal of lambda use in testcase webrev : http://cr.openjdk.java.net/~coffeys/webrev.sla_tos/webrev/ CCC for 7u has been submitted. Regards, Sean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Fri Aug 22 16:05:09 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 22 Aug 2014 17:05:09 +0100 Subject: RFR : 8032808, 8047186, 8029607, 8048212 - SO_FLOW_SLA support for solaris, Set TOS in IPv6 header In-Reply-To: <53F76098.3010108@oracle.com> References: <53F76098.3010108@oracle.com> Message-ID: <53F76A35.1070001@oracle.com> There doesn't seem to be any change to SocksProxy.java apart from the copyright date. Otherwise, the change looks fine. It just occurred to me that an update to policytool was made to know about the new NetworkPermission class. I don't think we backported it to 8 even. But, for completeness sake we might want to backport it to both of these releases at some point in the future. Michael On 22/08/14 16:24, Se?n Coffey wrote: > I'd like to backport these fixes into the jdk7u-dev codeline. They're > already in jdk8u-dev. > > https://bugs.openjdk.java.net/browse/JDK-8032808 - SO_FLOW_SLA support > for solaris > https://bugs.openjdk.java.net/browse/JDK-8047186 - Exception handling > change linked to above > > https://bugs.openjdk.java.net/browse/JDK-8029607 - Set TOS in IPv6 header > https://bugs.openjdk.java.net/browse/JDK-8048212 - Testcase failure > with above fix > > some of the changes are quite different from jdk8u in that the make > system is different. I've put some of the main differences in bullet > points : > > * new makefiles to capture the jdk/net classes > * Different javadoc makefile layout for 7u > * static src/share/native/java/net/jdk_net_SocketFlow.h header file > (dynamic in jdk8u) > * Alter src/share/classes/jdk/net/Sockets.java : > - throw new Error(e); instead of throw new InternalError(e); (older API) > * removal of lambda use in testcase > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.sla_tos/webrev/ > CCC for 7u has been submitted. > > Regards, > Sean. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Fri Aug 22 17:08:47 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Fri, 22 Aug 2014 18:08:47 +0100 Subject: RFR : 8032808, 8047186, 8029607, 8048212 - SO_FLOW_SLA support for solaris, Set TOS in IPv6 header In-Reply-To: <53F76A35.1070001@oracle.com> References: <53F76098.3010108@oracle.com> <53F76A35.1070001@oracle.com> Message-ID: <53F7791F.4080808@oracle.com> Not sure how the SocksProxy.java change occurred. I'll fix that up before pushing. Thanks for catching. Good point about the NetworkPermission changes for policytool - I don't see it in jdk 9 either (I see NetPermission being catered for) jdk/src/jdk.runtime/share/classes/sun/security/tools/policytool/PolicyTool.java Will look into that as a follow up. regards, Sean. On 22/08/14 17:05, Michael McMahon wrote: > There doesn't seem to be any change to SocksProxy.java apart from the > copyright date. > Otherwise, the change looks fine. It just occurred to me that an > update to policytool > was made to know about the new NetworkPermission class. I don't think > we backported it to > 8 even. But, for completeness sake we might want to backport it to > both of these releases > at some point in the future. > > Michael > > On 22/08/14 16:24, Se?n Coffey wrote: >> I'd like to backport these fixes into the jdk7u-dev codeline. They're >> already in jdk8u-dev. >> >> https://bugs.openjdk.java.net/browse/JDK-8032808 - SO_FLOW_SLA >> support for solaris >> https://bugs.openjdk.java.net/browse/JDK-8047186 - Exception handling >> change linked to above >> >> https://bugs.openjdk.java.net/browse/JDK-8029607 - Set TOS in IPv6 header >> https://bugs.openjdk.java.net/browse/JDK-8048212 - Testcase failure >> with above fix >> >> some of the changes are quite different from jdk8u in that the make >> system is different. I've put some of the main differences in bullet >> points : >> >> * new makefiles to capture the jdk/net classes >> * Different javadoc makefile layout for 7u >> * static src/share/native/java/net/jdk_net_SocketFlow.h header file >> (dynamic in jdk8u) >> * Alter src/share/classes/jdk/net/Sockets.java : >> - throw new Error(e); instead of throw new InternalError(e); (older >> API) >> * removal of lambda use in testcase >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.sla_tos/webrev/ >> CCC for 7u has been submitted. >> >> Regards, >> Sean. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Aug 24 12:11:58 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 24 Aug 2014 13:11:58 +0100 Subject: RFR: JDK-8044306 - java.net.Inet4AddressImpl.getLocalHostName() uses IPv6 rather than IPv4 In-Reply-To: <53F617F8.5060106@oracle.com> References: <53F617F8.5060106@oracle.com> Message-ID: <53F9D68E.7000907@oracle.com> On 21/08/2014 17:02, Mark Sheppard wrote: > Hi > please oblige and review the small change > http://cr.openjdk.java.net/~msheppar/8044306/webrev/ > > to address the issue raised in > https://bugs.openjdk.java.net/browse/JDK-8044306 > > hints.ai_family is assigned AF_INET rather than AF_UNSPEC > as the native function > Java_java_net_Inet4AddressImpl_getLocalHostName > is part of an IPv4 call flow, such that AF_UNSPEC allows > an IPv6 data to be retrieved as highlighted in bug report This looks okay to me, clearly a corner case for this to happen. -Alan From xuelei.fan at oracle.com Mon Aug 25 02:09:22 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 25 Aug 2014 10:09:22 +0800 Subject: RFR: 8055299 HttpsURLConnection.equals() broken In-Reply-To: <53F49C6B.7080807@oracle.com> References: <53F49C6B.7080807@oracle.com> Message-ID: <53FA9AD2.1000708@oracle.com> Looks fine to me. Thanks for the update. Xuelei On 8/20/2014 9:02 PM, Michael McMahon wrote: > This is the recently reported fix to HttpsURLConnection.equals > > http://cr.openjdk.java.net/~michaelm/8055299/webrev.1/ > > The fix includes a test. Not shown in the webrev is java key store > file called testkeys, which is copied from another location > in the test tree and is to be installed in the same directory > as the new test. > > Thanks > Michael From michael.x.mcmahon at oracle.com Mon Aug 25 09:58:32 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 25 Aug 2014 10:58:32 +0100 Subject: RFR : 8032808, 8047186, 8029607, 8048212 - SO_FLOW_SLA support for solaris, Set TOS in IPv6 header In-Reply-To: <53F7791F.4080808@oracle.com> References: <53F76098.3010108@oracle.com> <53F76A35.1070001@oracle.com> <53F7791F.4080808@oracle.com> Message-ID: <53FB08C8.4010602@oracle.com> On 22/08/14 18:08, Se?n Coffey wrote: > Not sure how the SocksProxy.java change occurred. I'll fix that up > before pushing. Thanks for catching. > > Good point about the NetworkPermission changes for policytool - I > don't see it in jdk 9 either (I see NetPermission being catered for) > jdk/src/jdk.runtime/share/classes/sun/security/tools/policytool/PolicyTool.java > > Will look into that as a follow up. > Actually, you are right. I was thinking about the update that was done for URLPermission. I need to file a bug for NetworkPermission. Michael > regards, > Sean. > > On 22/08/14 17:05, Michael McMahon wrote: >> There doesn't seem to be any change to SocksProxy.java apart from the >> copyright date. >> Otherwise, the change looks fine. It just occurred to me that an >> update to policytool >> was made to know about the new NetworkPermission class. I don't think >> we backported it to >> 8 even. But, for completeness sake we might want to backport it to >> both of these releases >> at some point in the future. >> >> Michael >> >> On 22/08/14 16:24, Se?n Coffey wrote: >>> I'd like to backport these fixes into the jdk7u-dev codeline. >>> They're already in jdk8u-dev. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8032808 - SO_FLOW_SLA >>> support for solaris >>> https://bugs.openjdk.java.net/browse/JDK-8047186 - Exception >>> handling change linked to above >>> >>> https://bugs.openjdk.java.net/browse/JDK-8029607 - Set TOS in IPv6 >>> header >>> https://bugs.openjdk.java.net/browse/JDK-8048212 - Testcase failure >>> with above fix >>> >>> some of the changes are quite different from jdk8u in that the make >>> system is different. I've put some of the main differences in bullet >>> points : >>> >>> * new makefiles to capture the jdk/net classes >>> * Different javadoc makefile layout for 7u >>> * static src/share/native/java/net/jdk_net_SocketFlow.h header file >>> (dynamic in jdk8u) >>> * Alter src/share/classes/jdk/net/Sockets.java : >>> - throw new Error(e); instead of throw new InternalError(e); >>> (older API) >>> * removal of lambda use in testcase >>> >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.sla_tos/webrev/ >>> CCC for 7u has been submitted. >>> >>> Regards, >>> Sean. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Mon Aug 25 10:47:00 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 25 Aug 2014 11:47:00 +0100 Subject: RFR: 8055299 HttpsURLConnection.equals() broken In-Reply-To: <53FA9AD2.1000708@oracle.com> References: <53F49C6B.7080807@oracle.com> <53FA9AD2.1000708@oracle.com> Message-ID: <53FB1424.5010202@oracle.com> Thanks for looking at it. I need to get this one reviewed first though, to re-organise one of the test support classes it uses https://bugs.openjdk.java.net/browse/JDK-8055747 Michael On 25/08/14 03:09, Xuelei Fan wrote: > Looks fine to me. Thanks for the update. > > Xuelei > > On 8/20/2014 9:02 PM, Michael McMahon wrote: >> This is the recently reported fix to HttpsURLConnection.equals >> >> http://cr.openjdk.java.net/~michaelm/8055299/webrev.1/ >> >> The fix includes a test. Not shown in the webrev is java key store >> file called testkeys, which is copied from another location >> in the test tree and is to be installed in the same directory >> as the new test. >> >> Thanks >> Michael From chris.hegarty at oracle.com Mon Aug 25 13:06:22 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 25 Aug 2014 14:06:22 +0100 Subject: RFR 8055747: Move SimpleSSLContext to jdk/testlibrary In-Reply-To: <53F5D910.5070009@oracle.com> References: <53F5D910.5070009@oracle.com> Message-ID: <53FB34CE.1090003@oracle.com> Michael, This looks mainly ok to me. It is nice to be adding to the common test infrastructure, where possible. Just a few minor comments... 1) Do the tests what use this also need to ensure that the classfile is compiled? We had trouble in the past when running concurrently. @build jdk.testlibrary.SimpleSSLContext 2) For the purposes of the policy files it would be nice to be able to specify the location relative to the TEST.ROOT, but I'm not sure if jtreg provides a property, or other, to expose this. -Chris. On 21/08/14 12:33, Michael McMahon wrote: > Before I push the other change to HttpsURLConnection, I'd like > to make this change to stop the proliferation of binary testkeys files > in the test tree and make the SimpleSSLContext class more accessible. > > http://cr.openjdk.java.net/~michaelm/8055747/webrev.01/ > > Thanks, > Michael From chris.hegarty at oracle.com Mon Aug 25 13:07:57 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 25 Aug 2014 14:07:57 +0100 Subject: RFR: 8055299 HttpsURLConnection.equals() broken In-Reply-To: <53FB1424.5010202@oracle.com> References: <53F49C6B.7080807@oracle.com> <53FA9AD2.1000708@oracle.com> <53FB1424.5010202@oracle.com> Message-ID: <53FB352D.8090702@oracle.com> Michael, The source changes look fine to me, but I know you are waiting on another dependent bug to be able to update the test. -Chris. On 25/08/14 11:47, Michael McMahon wrote: > Thanks for looking at it. I need to get this one reviewed first > though, to re-organise one of the test support classes it uses > > https://bugs.openjdk.java.net/browse/JDK-8055747 > > Michael > > On 25/08/14 03:09, Xuelei Fan wrote: >> Looks fine to me. Thanks for the update. >> >> Xuelei >> >> On 8/20/2014 9:02 PM, Michael McMahon wrote: >>> This is the recently reported fix to HttpsURLConnection.equals >>> >>> http://cr.openjdk.java.net/~michaelm/8055299/webrev.1/ >>> >>> The fix includes a test. Not shown in the webrev is java key store >>> file called testkeys, which is copied from another location >>> in the test tree and is to be installed in the same directory >>> as the new test. >>> >>> Thanks >>> Michael > From michael.x.mcmahon at oracle.com Mon Aug 25 13:41:50 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 25 Aug 2014 14:41:50 +0100 Subject: RFR 8055747: Move SimpleSSLContext to jdk/testlibrary In-Reply-To: <53FB34CE.1090003@oracle.com> References: <53F5D910.5070009@oracle.com> <53FB34CE.1090003@oracle.com> Message-ID: <53FB3D1E.6030900@oracle.com> On 25/08/14 14:06, Chris Hegarty wrote: > Michael, > > This looks mainly ok to me. It is nice to be adding to the common test > infrastructure, where possible. Just a few minor comments... > > 1) Do the tests what use this also need to ensure that the classfile is > compiled? We had trouble in the past when running concurrently. > > @build jdk.testlibrary.SimpleSSLContext > Good question. I'll look into this. It's an annoying feature of jtreg if it is the case. > 2) For the purposes of the policy files it would be nice to be able to > specify the location relative to the TEST.ROOT, but I'm not sure if > jtreg provides a property, or other, to expose this. > I looked into it, and there's nothing usable in the environment unfortunately. It's a pity TEST.ROOT isn't provided. Thanks, Michael > -Chris. > > On 21/08/14 12:33, Michael McMahon wrote: >> Before I push the other change to HttpsURLConnection, I'd like >> to make this change to stop the proliferation of binary testkeys files >> in the test tree and make the SimpleSSLContext class more accessible. >> >> http://cr.openjdk.java.net/~michaelm/8055747/webrev.01/ >> >> Thanks, >> Michael From amanda.jiang at oracle.com Mon Aug 25 16:48:43 2014 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Mon, 25 Aug 2014 11:48:43 -0500 Subject: RFR 8047031: Need new tests to check socket permission In-Reply-To: <53D6CDDB.7020705@oracle.com> References: <53D6CDDB.7020705@oracle.com> Message-ID: <53FB68EB.5050107@oracle.com> Hi Michael, Chris and others We?re working on moving our internal security tests to open idk repo(Include refactoring effort). Could you please help to review these tests? Thanks, Amanda On 7/28/14 5:25 PM, Amanda Jiang wrote: > Hi All, > > Could you please review 1 new test to be added for SocketPermission. > New test is added to check socket permissions, for instance - > - java.net.SocketPermission with "connect", "resolve", "accept", "listen" > with Socket, DatagramSocket, MulticastSocket etc. > > JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8047031 > WebRev: http://cr.openjdk.java.net/~rhalade/8047031/webrev.00/ > > Thanks, > Amanda > > From weijun.wang at oracle.com Tue Aug 26 00:58:47 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 26 Aug 2014 08:58:47 +0800 Subject: RFR 8055901: Update policytool for jdk.net.NetworkPermission Message-ID: <666E7747-71CB-4D1F-9731-C24F5FA036CA@oracle.com> Hi Michael Please review the code change at http://cr.openjdk.java.net/~weijun/8055901/webrev.00/ With this change, the policy tool can generate a file like grant { permission jdk.net.NetworkPermission "setOption.SO_FLOW_SLA"; }; Please confirm the grammar is correct. BTW, I also add some missing targets in a nearby permission type. Noreg-trivial. Thanks Max From michael.x.mcmahon at oracle.com Tue Aug 26 07:57:01 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 26 Aug 2014 08:57:01 +0100 Subject: RFR 8055901: Update policytool for jdk.net.NetworkPermission In-Reply-To: <666E7747-71CB-4D1F-9731-C24F5FA036CA@oracle.com> References: <666E7747-71CB-4D1F-9731-C24F5FA036CA@oracle.com> Message-ID: <53FC3DCD.1060308@oracle.com> Thanks for doing this Max. The syntax looks fine. Just one question. Do you think it is better to specify each socket option literally in the tool as you have done (ie. the only supported NetworkPermission is SO_FLOW_SLA with this change) or allow users to type in the option name as free-form text I guess you can always edit policy files manually, but if more socket options get added in future, then we will need to update the tool again. Michael On 26/08/14 01:58, Wang Weijun wrote: > Hi Michael > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8055901/webrev.00/ > > With this change, the policy tool can generate a file like > > grant { > permission jdk.net.NetworkPermission "setOption.SO_FLOW_SLA"; > }; > > Please confirm the grammar is correct. > > BTW, I also add some missing targets in a nearby permission type. > > Noreg-trivial. > > Thanks > Max > From weijun.wang at oracle.com Tue Aug 26 08:05:04 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 26 Aug 2014 16:05:04 +0800 Subject: RFR 8055901: Update policytool for jdk.net.NetworkPermission In-Reply-To: <53FC3DCD.1060308@oracle.com> References: <666E7747-71CB-4D1F-9731-C24F5FA036CA@oracle.com> <53FC3DCD.1060308@oracle.com> Message-ID: <647366ED-0727-4F00-B0AC-4E47DEE87449@oracle.com> On Aug 26, 2014, at 15:57, Michael McMahon wrote: > Thanks for doing this Max. The syntax looks fine. > Just one question. Do you think it is better to specify each socket option literally in the tool > as you have done (ie. the only supported NetworkPermission > is SO_FLOW_SLA with this change) or allow users to type in the option name as free-form text Well, IMO policytool is for people who cannot remember the exact permission/target/actions names. Otherwise, it's quite easy to write a policy file using any text editor. Also, you might have noticed that even if you select one target name you can still edit it to something else. Therefore forgetting to update the tool is not fatal. --Max > I guess you can always edit policy files manually, but if more socket options get added > in future, then we will need to update the tool again. > > Michael > > On 26/08/14 01:58, Wang Weijun wrote: >> Hi Michael >> >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/8055901/webrev.00/ >> >> With this change, the policy tool can generate a file like >> >> grant { >> permission jdk.net.NetworkPermission "setOption.SO_FLOW_SLA"; >> }; >> >> Please confirm the grammar is correct. >> >> BTW, I also add some missing targets in a nearby permission type. >> >> Noreg-trivial. >> >> Thanks >> Max >> > From michael.x.mcmahon at oracle.com Tue Aug 26 08:07:13 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 26 Aug 2014 09:07:13 +0100 Subject: RFR 8055901: Update policytool for jdk.net.NetworkPermission In-Reply-To: <647366ED-0727-4F00-B0AC-4E47DEE87449@oracle.com> References: <666E7747-71CB-4D1F-9731-C24F5FA036CA@oracle.com> <53FC3DCD.1060308@oracle.com> <647366ED-0727-4F00-B0AC-4E47DEE87449@oracle.com> Message-ID: <53FC4031.9050808@oracle.com> On 26/08/14 09:05, Wang Weijun wrote: > On Aug 26, 2014, at 15:57, Michael McMahon wrote: > >> Thanks for doing this Max. The syntax looks fine. >> Just one question. Do you think it is better to specify each socket option literally in the tool >> as you have done (ie. the only supported NetworkPermission >> is SO_FLOW_SLA with this change) or allow users to type in the option name as free-form text > Well, IMO policytool is for people who cannot remember the exact permission/target/actions names. Otherwise, it's quite easy to write a policy file using any text editor. Also, you might have noticed that even if you select one target name you can still edit it to something else. Therefore forgetting to update the tool is not fatal. Good points. That's fine then. Thanks! Michael > --Max > >> I guess you can always edit policy files manually, but if more socket options get added >> in future, then we will need to update the tool again. > >> Michael >> >> On 26/08/14 01:58, Wang Weijun wrote: >>> Hi Michael >>> >>> Please review the code change at >>> >>> http://cr.openjdk.java.net/~weijun/8055901/webrev.00/ >>> >>> With this change, the policy tool can generate a file like >>> >>> grant { >>> permission jdk.net.NetworkPermission "setOption.SO_FLOW_SLA"; >>> }; >>> >>> Please confirm the grammar is correct. >>> >>> BTW, I also add some missing targets in a nearby permission type. >>> >>> Noreg-trivial. >>> >>> Thanks >>> Max >>> From michael.x.mcmahon at oracle.com Tue Aug 26 14:01:08 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 26 Aug 2014 15:01:08 +0100 Subject: RFR 8056065: sun/net/www/protocol/http/RedirectOnPost.java failing. Message-ID: <53FC9324.6080902@oracle.com> Could I get the following small change reviewed please? One file was missed from my earlier change to SimpleSSLContext http://cr.openjdk.java.net/~michaelm/8056065/webrev.1/ Thanks, Michael. From Alan.Bateman at oracle.com Tue Aug 26 14:06:10 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Aug 2014 15:06:10 +0100 Subject: RFR 8056065: sun/net/www/protocol/http/RedirectOnPost.java failing. In-Reply-To: <53FC9324.6080902@oracle.com> References: <53FC9324.6080902@oracle.com> Message-ID: <53FC9452.7080800@oracle.com> On 26/08/2014 15:01, Michael McMahon wrote: > Could I get the following small change reviewed please? > > One file was missed from my earlier change to SimpleSSLContext > > http://cr.openjdk.java.net/~michaelm/8056065/webrev.1/ This looks okay to me, I assume that all the :jdk_net tests are passing now. -Alan From michael.x.mcmahon at oracle.com Tue Aug 26 14:08:23 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 26 Aug 2014 15:08:23 +0100 Subject: RFR 8056065: sun/net/www/protocol/http/RedirectOnPost.java failing. In-Reply-To: <53FC9452.7080800@oracle.com> References: <53FC9324.6080902@oracle.com> <53FC9452.7080800@oracle.com> Message-ID: <53FC94D7.5000106@oracle.com> On 26/08/14 15:06, Alan Bateman wrote: > On 26/08/2014 15:01, Michael McMahon wrote: >> Could I get the following small change reviewed please? >> >> One file was missed from my earlier change to SimpleSSLContext >> >> http://cr.openjdk.java.net/~michaelm/8056065/webrev.1/ > This looks okay to me, I assume that all the :jdk_net tests are > passing now. > > -Alan Some of them fail over VPN, which is probably how I missed it. But, I'll check again to be sure. Thanks, Michael From chris.hegarty at oracle.com Tue Aug 26 14:09:55 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 Aug 2014 15:09:55 +0100 Subject: RFR 8056065: sun/net/www/protocol/http/RedirectOnPost.java failing. In-Reply-To: <53FC9452.7080800@oracle.com> References: <53FC9324.6080902@oracle.com> <53FC9452.7080800@oracle.com> Message-ID: On 26 Aug 2014, at 15:06, Alan Bateman wrote: > On 26/08/2014 15:01, Michael McMahon wrote: >> Could I get the following small change reviewed please? >> >> One file was missed from my earlier change to SimpleSSLContext >> >> http://cr.openjdk.java.net/~michaelm/8056065/webrev.1/ > This looks okay to me, I assume that all the :jdk_net tests are passing now. +1 -Chris. > > -Alan From paul.sandoz at oracle.com Wed Aug 27 09:51:06 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Aug 2014 11:51:06 +0200 Subject: The future of Serialization In-Reply-To: <53E6586F.7080906@oracle.com> References: <1407563776.1841.30.camel@Nokia-N900> <53E6586F.7080906@oracle.com> Message-ID: On Aug 9, 2014, at 7:20 PM, Brian Goetz wrote: >> I've noticed there's not much interest in improving Serialization on >> these lists. This makes me wonder if java Serialization has lost >> relevance in recent years with the rise of protocol buffers apache >> thrift and other means of data transfer over byte streams. > > I sense your frustration, but I think you may be reaching the wrong conclusion. The lack of response is probably not evidence that there's no interest in fixing serialization; its that fixing serialization, with all the constraints that "fix" entails, is just really really hard, and its much easier to complain about it (and even say "let's just get rid of it") than to fix it. > >> Should Serializable eventually be deprecated? Should Serialization be >> disabled by default? Should a new mechanism be developed? If a new >> mechanism is developed, what about circular object relationships? > > As I delved into my own explorations of serialization, I started to realize why such a horrible approach was the one that was ultimately chosen; while serialization is horrible and awful and leaky and insecure and complex and brittle, it does address problems like cyclic data structures and independent evolution of subclass and superclass better than the "clean" models. > > My conclusion is, at best, a new mechanism would have to live side-by-side with the old one, since it could only handle 95% of the cases. It might handle those 95% much better -- more cleanly, securely, and allowing easier schema evolution -- but the hard cases are still there. Still, reducing the use of the horrible old mechanism may still be a worthy goal, even if it can't be killed outright. > Also many serialization-based libraries use sun.misc.Unsafe or sun.reflect.ReflectionFactory for various reasons (with backup plans if such classes are not available or accessible). As part to the future of serialization i think we need to evaluate libraries such as XStream and Objenesis to see what unsafe/internal mechanisms can be replaced by functionally equivalent safe public mechanisms. I have more questions than answers at the moment with regards to that :-( Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From chris.hegarty at oracle.com Wed Aug 27 15:45:08 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 27 Aug 2014 16:45:08 +0100 Subject: RFR 8047031: Need new tests to check socket permission In-Reply-To: <53FB68EB.5050107@oracle.com> References: <53D6CDDB.7020705@oracle.com> <53FB68EB.5050107@oracle.com> Message-ID: <53FDFD04.30909@oracle.com> Amanda, I see you have implemented a getFreePort in this test, and it attempts to find a port within a range of 10 of the given port. I would have a concern about this when the test is run concurrently. Though we have come across similar issues in the past, as the socket permission needs to have a defined port range. I'm not sure if we ever came up with a good solution. Do you think it would be possible to get the free port first, and then create the socket permission instances dynamically accordingly? Or would this make the test very difficult to debug? -Chris. On 25/08/14 17:48, Amanda Jiang wrote: > Hi Michael, Chris and others > > We?re working on moving our internal security tests to open idk > repo(Include refactoring effort). Could you please help to review these > tests? > > Thanks, > Amanda > > On 7/28/14 5:25 PM, Amanda Jiang wrote: >> Hi All, >> >> Could you please review 1 new test to be added for SocketPermission. >> New test is added to check socket permissions, for instance - >> - java.net.SocketPermission with "connect", "resolve", "accept", "listen" >> with Socket, DatagramSocket, MulticastSocket etc. >> >> JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8047031 >> WebRev: http://cr.openjdk.java.net/~rhalade/8047031/webrev.00/ >> >> Thanks, >> Amanda >> >> > From amanda.jiang at oracle.com Fri Aug 29 18:39:51 2014 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Fri, 29 Aug 2014 13:39:51 -0500 Subject: RFR 8047031: Need new tests to check socket permission In-Reply-To: <53FDFD04.30909@oracle.com> References: <53D6CDDB.7020705@oracle.com> <53FB68EB.5050107@oracle.com> <53FDFD04.30909@oracle.com> Message-ID: <5400C8F7.7080202@oracle.com> Hi Chris, Thanks for reviewing this test. I have upgraded the test by your suggestions, in the new version, free port is generated first then socket permission instances are created dynamically. Lambda and TestNG are also applied for simplifying tests and reducing redundant codes. Please check the webrev below: http://cr.openjdk.java.net/~tyan/amandaj/8047031/webrev00/ Thanks, Amanda On 8/27/14 10:45 AM, Chris Hegarty wrote: > Amanda, > > I see you have implemented a getFreePort in this test, and it attempts > to find a port within a range of 10 of the given port. I would have a > concern about this when the test is run concurrently. Though we have > come across similar issues in the past, as the socket permission needs > to have a defined port range. I'm not sure if we ever came up with a > good solution. > > Do you think it would be possible to get the free port first, and then > create the socket permission instances dynamically accordingly? Or > would this make the test very difficult to debug? > > -Chris. > > On 25/08/14 17:48, Amanda Jiang wrote: >> Hi Michael, Chris and others >> >> We?re working on moving our internal security tests to open idk >> repo(Include refactoring effort). Could you please help to review these >> tests? >> >> Thanks, >> Amanda >> >> On 7/28/14 5:25 PM, Amanda Jiang wrote: >>> Hi All, >>> >>> Could you please review 1 new test to be added for SocketPermission. >>> New test is added to check socket permissions, for instance - >>> - java.net.SocketPermission with "connect", "resolve", "accept", >>> "listen" >>> with Socket, DatagramSocket, MulticastSocket etc. >>> >>> JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8047031 >>> WebRev: http://cr.openjdk.java.net/~rhalade/8047031/webrev.00/ >>> >>> Thanks, >>> Amanda >>> >>> >>