Re: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle [v2]

On Fri, 10 Jun 2022 06:45:00 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/jdk/internal/misc/Signal.java line 180: >> >>> 178: if (newH == 2) { >>> 179: handlers.put(sig, handler); >>> 180: } >> >> If you made this change instead: >> >>

Re: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle

On Thu, 9 Jun 2022 07:35:43 GMT, Andrey Turbanov wrote: > https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178 > > Instead of separate Hashtable.get/remove calls we can just use value returned > by

Re: RFR: 8285445: cannot open file "NUL:"

On Sat, 23 Apr 2022 15:24:13 GMT, Alan Bateman wrote: > > FWIW we fixed the same problem by simply using `NUL` instead of `NUL:`. > > Hopefully newer code can use OutputStream.nullOutputStream(). It's portable > and avoids depending on these legacy Windows specific reserved names. One

Re: RFR: 8285445: cannot open file "NUL:"

On Sat, 23 Apr 2022 01:11:56 GMT, Brian Burkhalter wrote: > Change the default value of the `jdk.io.File.enableADS` property to `true`. FWIW we fixed the same problem by simply using `NUL` instead of `NUL:`. - PR: https://git.openjdk.java.net/jdk/pull/8373

Re: RFR 9: 8165641 : Deprecate Object.finalize

In regards to the optimized-out "this" stuff - remember that a while ago Paul Sandoz introduced java.lang.ref.Reference#reachabilityFence()... On 03/12/2017 06:55 PM, Hans Boehm wrote: I agree that's indeed a solvable problem, perhaps not terribly elegantly, but without too much user-visible

Re: NPE on "return" bytecode of java.net.NetworkInterface

On 11/14/2016 11:07 AM, David M. Lloyd wrote: On 11/14/2016 11:02 AM, David M. Lloyd wrote: On 11/14/2016 09:54 AM, David M. Lloyd wrote: On 11/14/2016 09:39 AM, Chris Hegarty wrote: On 14/11/16 15:29, Andrew Haley wrote: On 14/11/16 14:47, David M. Lloyd wrote: Since this method

Re: NPE on "return" bytecode of java.net.NetworkInterface

On 11/14/2016 11:02 AM, David M. Lloyd wrote: On 11/14/2016 09:54 AM, David M. Lloyd wrote: On 11/14/2016 09:39 AM, Chris Hegarty wrote: On 14/11/16 15:29, Andrew Haley wrote: On 14/11/16 14:47, David M. Lloyd wrote: Since this method is called from a native method, is it possible

Re: NPE on "return" bytecode of java.net.NetworkInterface

On 11/14/2016 09:54 AM, David M. Lloyd wrote: On 11/14/2016 09:39 AM, Chris Hegarty wrote: On 14/11/16 15:29, Andrew Haley wrote: On 14/11/16 14:47, David M. Lloyd wrote: Since this method is called from a native method, is it possible that somehow the native method is generating an NPE

Re: NPE on "return" bytecode of java.net.NetworkInterface

On 11/14/2016 09:39 AM, Chris Hegarty wrote: On 14/11/16 15:29, Andrew Haley wrote: On 14/11/16 14:47, David M. Lloyd wrote: Since this method is called from a native method, is it possible that somehow the native method is generating an NPE, but the Java method is still in the stack context

Re: NPE on "return" bytecode of java.net.NetworkInterface

On 11/14/2016 09:29 AM, Langer, Christoph wrote: Hi David, can this be reproduced? It's part of the test suite of our application server, so, probably, but probably not easily. What platform is it about? There have been fixes for some Windows native coding lately:

Re: NPE on "return" bytecode of java.net.NetworkInterface

On 11/14/2016 09:29 AM, Andrew Haley wrote: On 14/11/16 14:47, David M. Lloyd wrote: Since this method is called from a native method, is it possible that somehow the native method is generating an NPE, but the Java method is still in the stack context? I assume that what is happening here

NPE on "return" bytecode of java.net.NetworkInterface

I'm trying to work out something a colleague has observed during testing on an OpenJDK based on 1.8.0_111 (build 1.8.0_111-b16). The business end of the stack trace looks like this: Caused by: java.lang.NullPointerException at java.net.NetworkInterface.(NetworkInterface.java:80)

Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

On 11/11/2016 05:07 AM, Alan Bateman wrote: On 11/11/2016 10:46, Vladimir Ivanov wrote: Alan, I've looked through the current thread and also review thread [1] for original change (8165793), but haven't found any discussion why making it static (instead of instance final) is undesirable.

Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

My original suggestion for the method was to make it static, and possibly even caller-sensitive, for just this reason. On 11/09/2016 04:53 PM, Brent Christian wrote: Hi, It seems that the method name used in 8165793[1], "isParallelCapable", was a little *too* intuitive. An existing use of

Re: Proposal for adding O_DIRECT support into JDK 9

I still feel like it could be a problem to have just one simple getPageSize method, given how many CPU architectures and OSes support multiple page sizes. On 11/04/2016 11:58 AM, Paul Sandoz wrote: Hi Lucy, I am struggling to find an entirely satisfactory location to place a method such as

Re: Proposal for adding O_DIRECT support into JDK 9

What happens if you're using large pages? Are the direct buffers always allocated off of small pages? On 11/02/2016 06:34 PM, Lu, Yingqi wrote: Hi All, Our most recent DirectIO patch is available at http://cr.openjdk.java.net/~igraves/8164900-3/ In this version, we made following changes:

Another ProcessBuilder enhancement: execve

It would be useful for processes which self-update or otherwise self-manage to be able to exec a new process which replaces the current one, in the manner of POSIX execve. This might tie in with ProcessBuilder, though there are a few key differences: 1. The method to execute the process

Re: RFR 9: 8164908: ReflectionFactory support for IIOP and custom serialization

On 10/19/2016 02:59 PM, Roger Riggs wrote: The support in sun.reflect.ReflectionFactory for custom serialization, such as IIOP input and output streams, is being expanded beyond the necessary constructor of a serializable class to include access to the private methods readObject, writeObject,

Re: Deprecate all java.util.concurrent.*FieldUpdater

I'm sure I recall an email from the past few months which proposed that *FieldUpdater are still going to be recommended in many cases over VarHandle because the latter is probably too low-level for casual uses. It was (IIRC) an argument in favor of more advanced fence methods or something like

Re: RFC: System.console().encoding()

On 09/15/2016 02:06 AM, Xueming Shen wrote: -1 :-) Console is supposed to be a "char/String" based class, "encoding" really should have no business here in its api. Simply for some implementation convenience is really not a good reason to add such a public method. Let's look at the two

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Without a resolution to https://bugs.openjdk.java.net/browse/JDK-8008240 (atomics for buffers) or https://bugs.openjdk.java.net/browse/JDK-6476827 (memory consistency properties of buffers), how meaningful is this? On 03/31/2016 07:06 PM, Hans Boehm wrote: The expectation would be that such

Re: JAXP default implementation and JDK-8152063

/2016 01:42 PM, David M. Lloyd wrote: The reason is because we use a single boot path but we don't know at the time of boot whether or not we will have a JAXP provider, nor where it will come from; that is up to the server configuration that we end up running. With the system properties approach we

Re: JAXP default implementation and JDK-8152063

g a provider through the Layer of the caller if TCCL fails. I think the assumption in the previous discussion was that a new method would be introduced to take a Layer as an argument. -Joe On 3/24/2016 3:36 PM, David M. Lloyd wrote: This is all for the case where the user is calling e.g. javax.xml.str

Re: JAXP default implementation and JDK-8152063

FAICT it will fail with Jigsaw because we can't access the JDK's default implementations". So the question is, why did you have to override the JAXP process for the services that you don't have an AppServer-level provider ( "overriding implementation(s)" )? Thanks, Joe On 3/25/2016 5:5

Re: JAXP default implementation and JDK-8152063

fails. I think the assumption in the previous discussion was that a new method would be introduced to take a Layer as an argument. -Joe On 3/24/2016 3:36 PM, David M. Lloyd wrote: This is all for the case where the user is calling e.g. javax.xml.stream.XMLInputFactory#newFactory

Re: JAXP default implementation and JDK-8152063

to the new API. Would you expect that would happen or would you still have existing applications that can not be updated? -Joe On 3/24/2016 2:02 PM, David M. Lloyd wrote: On 03/24/2016 03:54 PM, huizhe wang wrote: In this discussion so far, a) I see that you seemed to have successfully used

Re: JAXP default implementation and JDK-8152063

On 03/24/2016 03:54 PM, huizhe wang wrote: In this discussion so far, a) I see that you seemed to have successfully used the method with a class loader as Daniel suggested. I assume that solved the issue reported in JDK-8152063. Am I right, that you no longer have issue with using a proxy? Or

Re: JAXP default implementation and JDK-8152063

On 03/24/2016 11:26 AM, Alan Bateman wrote: On 24/03/2016 16:09, David M. Lloyd wrote: : If the Layer of the module of the class calling the newInstance/newFactory/etc. method could somehow be consulted in service resolution decisions, that would definitely solve the problem because our

Re: JAXP default implementation and JDK-8152063

On 03/22/2016 08:59 AM, Daniel Fuchs wrote: Would adding a method that resolves the concrete service implementation against a Layer supplied by the caller be of any help in your scenario? I think I misunderstood this when you asked it. You mean let the Layer have a hand in looking up the

Re: JAXP default implementation and JDK-8152063

On 03/24/2016 09:51 AM, Alan Bateman wrote: On 24/03/2016 14:29, David M. Lloyd wrote: Daniel, I have hacked together a way to use the system class loader (which should be "good enough", I hope), but there is one further problem: org.xml.sax.helpers.XMLReaderFactory does not have

Re: JAXP default implementation and JDK-8152063

On 03/23/2016 07:12 AM, David M. Lloyd wrote: On 03/22/2016 08:59 AM, Daniel Fuchs wrote: Hi David, On 22/03/16 13:53, David M. Lloyd wrote: Am I understanding it correctly that you're pointing the system property to a "proxy" as stated in JDK-8152063, not an actual implementatio

Re: JAXP default implementation and JDK-8152063

On 03/22/2016 08:59 AM, Daniel Fuchs wrote: Hi David, On 22/03/16 13:53, David M. Lloyd wrote: Am I understanding it correctly that you're pointing the system property to a "proxy" as stated in JDK-8152063, not an actual implementation? So it's sort of a provider-locating mechani

Re: JAXP default implementation and JDK-8152063

On 03/21/2016 07:42 PM, huizhe wang wrote: On 3/21/2016 12:55 PM, David M. Lloyd wrote: On 03/21/2016 01:38 PM, Alan Bateman wrote: On 21/03/2016 14:39, David M. Lloyd wrote: This message is in reference to the aforementioned issue [1] that I've requested my colleague Andrew Hughes to open

Re: JAXP default implementation and JDK-8152063

On 03/21/2016 01:38 PM, Alan Bateman wrote: On 21/03/2016 14:39, David M. Lloyd wrote: This message is in reference to the aforementioned issue [1] that I've requested my colleague Andrew Hughes to open on my behalf. As expressed in that issue, the means of specifying a JAXP default provider

JAXP default implementation and JDK-8152063

This message is in reference to the aforementioned issue [1] that I've requested my colleague Andrew Hughes to open on my behalf. As expressed in that issue, the means of specifying a JAXP default provider (via system property which specifies a class name on the application class path) is

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

On 03/07/2016 03:43 AM, Paul Sandoz wrote: Hi Uwe, Alan, Uwe, thanks so much for testing and investigating, that is very helpful and really appreciated. The EA process is working as intended, although i wish the result was not so debilitating in this case. Sorry about that. [...] Here is a

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

On 02/22/2016 12:11 PM, mark.reinh...@oracle.com wrote: 2016/1/28 9:25 -0800, g...@azul.com: This thread seems to have "hopped away" to the concurrency-interest list in mid-Dec-2015. This posting is intended to capture a summary of reasoning and some of the discussion there so that we have it

Re: DeserializationPermission Proposal

Things are getting confused (for me anyway) so I'm going to try and spell out each idea separately. Given a class hierarchy H of: C -> B -> A -> NonSerializableClass -> Object where C, B, and A are serializable classes, and protection domain M which is initiating deserialization, I think the

Re: DeserializationPermission Proposal

On 02/11/2016 03:52 AM, Peter Firmstone wrote: An example might be more useful. Traditionally, when the first non serializable superclass zero argument constructor is called, the domains of the subclasses aren't present on the call stack. Any security checks performed in the constructor of the

Re: DeserializationPermission Proposal

On 02/08/2016 10:19 PM, Peter Firmstone wrote: Why not, just prior to instantiating an object just prior to deserializing, add each class' ProtectionDomain in the objects hierarchy to an AccessControlContext and pass this to the SecurityManager's two argument checkPermission call? This

Re: API review of VarHandles

On 01/21/2016 07:32 PM, Brian Goetz wrote: I am baffled as to how the original language syntax proposal of using some trick like "xx.volatile.imaginaryMethod()" plus maybe one or two new bytecodes was considered unacceptable; looking at this API, I know that none of the aforementioned metrics

Re: API review of VarHandles

On 01/22/2016 07:29 AM, Vitaly Davidovich wrote: Experts need control more than anything else. This is not to say they'll be happy with a subpar API but control typically means lots of details so there's a limit on how abstracted the API can be. As mentioned, given the API provides low level

Re: API review of VarHandles

ter. On Fri, Jan 22, 2016 at 8:34 AM, David M. Lloyd <david.ll...@redhat.com> wrote: On 01/22/2016 07:29 AM, Vitaly Davidovich wrote: Experts need control more than anything else. This is not to say they'll be happy with a subpar API but control typically means lots of details so there's

Re: API review of VarHandles

On 01/22/2016 07:57 AM, Aleksey Shipilev wrote: On 01/22/2016 04:54 PM, David M. Lloyd wrote: The costs are both performance and memory overhead. The Atomic*FieldUpdaters are good for memory usage and reasonably usable, but suffer from performance problems and generics issues. Hopefully

Re: API review of VarHandles

On 01/21/2016 04:42 PM, Paul Sandoz wrote: Hi This is a request to review the VarHandles API. The code reviews and pushes will occur separately, and flow through the hs-comp repo, most likely from the bottom up first with Unsafe changes. The specdiff can be found here:

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Yeah I think that replacing finalize is a bad example. With Reference.reachabilityFence() around the corner, if you want finalize you can (and should, I guess) just use finalize. IMO Cleaners are better when you do not want the instance of an object to be accessible at all before you clean

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

Or perhaps a builder... On 12/08/2015 08:33 AM, Roger Riggs wrote: Hi Chris, Supporting the use case in Thread is a good addition. Adding an argument to the most flexible constructor of Thread bulks up an already heavy weight constructor. Look at the cases being replaced, none of them use

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 12/08/2015 07:41 AM, Peter Levart wrote: (once again, for the list - I can't seem to hit the right button :-) On 12/08/2015 01:51 PM, David M. Lloyd wrote: Yeah I think that replacing finalize is a bad example. With Reference.reachabilityFence() around the corner, if you want finalize you

Re: Code Review for JEP 259: Stack-Walking API

On 11/16/2015 06:13 PM, Mandy Chung wrote: I’d like to get the code review done by this week. I renamed the static factory method from create to getInstance since “create” implies to create a new instance but the method returns a cached instance instead. I also changed the spec of

Re: Proposed API for JEP 259: Stack-Walking API

On 11/13/2015 06:07 PM, Brian Goetz wrote: I considered Optional. I believe it is rare to have a JNI attached thread calling StackWalker::getCallerClass from native. Most common cases will find a caller class. Returning an Optional will force most common uses to handle the case if it’s

Re: Code Review for JEP 259: Stack-Walking API

One other kind of stack metadata that is missing (yet is present with external tools such as jstack etc.) is ancillary data about stack frames indicating whether the frame holds or is waiting on a lock. I'm not sure whether it's practical to add all this stuff though, performance-wise, unless

Re: Proposed API for JEP 259: Stack-Walking API

On 11/04/2015 07:15 PM, Mandy Chung wrote: [...] For short-circuiting, I also think it’s reasonable to expect the user know how many remaining frames it expects to traverse and it may not need to increase the batch size i.e. it might not need to update the remainingNeeded over time. The user

Re: Proposed API for JEP 259: Stack-Walking API

On 11/03/2015 03:33 PM, Mandy Chung wrote: On Nov 3, 2015, at 4:45 AM, Peter Levart wrote: Hi Mandy, Great API. One thing I noticed is method StackWalker.getCallerClass() which is described as equivalent to the following: walk((s) ->

Re: Proposed API for JEP 259: Stack-Walking API

I also agree - when an object type "passes through" a method, it's usually best to use an invariant type variable. On 11/02/2015 06:44 AM, Paul Sandoz wrote: I agree with Maurizio, the first signature is good enough. One could argue that it might be better to apply PECS since it would

Re: Proposed API for JEP 259: Stack-Walking API

On 10/30/2015 11:24 PM, Mandy Chung wrote: On Oct 30, 2015, at 3:38 PM, David M. Lloyd <david.ll...@redhat.com> wrote: (that's what I was looking for before), or maybe even ToIntFunction where X is something that might inform the next batch size based on the work that has already been

Re: Proposed API for JEP 259: Stack-Walking API

On 10/30/2015 03:26 PM, Remi Forax wrote: The batchSizeMapper should probably be something better than a Function, no? All that boxing seems unnecessary... the next best candidate I can see though is IntToLongFunction. I wonder why we didn't do an IntToIntFunction in JSR 335.

Re: Proposed API for JEP 259: Stack-Walking API

On 10/30/2015 03:39 PM, Mandy Chung wrote: On Oct 30, 2015, at 12:59 PM, David M. Lloyd <david.ll...@redhat.com> wrote: Since this is very likely to be a one-implementation API, is there a reason to have a separate WalkerOption interface and Option enum? Seems like you could jus

Re: Proposed API for JEP 259: Stack-Walking API

On 10/30/2015 02:04 PM, Mandy Chung wrote: JEP 259: http://openjdk.java.net/jeps/259 Javadoc for the proposed StackWalker API: http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html A simple way to walk the stack: StackWalker walker = new

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

FWIW I agree - it's just weird to have the behavior change after the fact like that. On 10/26/2015 11:37 PM, Xueming Shen wrote: Hi Steve, I know I stared to sound like a broken record :-) But I would like to suggest the team one more time to reconsider the current decision of using the "set"

Re: Spin Loop Hint support: Draft JEP proposal

On 10/08/2015 05:58 AM, Doug Lea wrote: On 10/06/2015 09:28 PM, Gil Tene wrote: As for fitting in with larger-picture or theme things (listed above). I think that agonizing over the choice of where to put this is important To avoid the kinds of problems we later saw when basic JVM methods

Re: JEP 264: Platform Logging API and Service

On 09/18/2015 11:17 AM, mark.reinh...@oracle.com wrote: New JEP Candidate: http://openjdk.java.net/jeps/264 +1 good idea! -- - DML

Re: RFR: 8132541 : (process) ProcessBuilder support for redirection to discard output

Nifty, thanks! On 09/11/2015 10:30 AM, Roger Riggs wrote: Please review a proposed [1] ProcessBuilder addition to define a Redirect that will discard output. The implementation is to redirect output to /dev/null or NUL on Windows. Please review and comment if there are any unexpected side

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

Or, the Java methods which wrap this access can just catch NPE and throw the new exception type. On 09/10/2015 09:35 AM, Vitaly Davidovich wrote: Well, you'd probably want something other than NPE here -- perhaps a new dedicated exception to signal this condition. And this means the segfault

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

On 09/10/2015 08:22 AM, Andrew Haley wrote: On 09/10/2015 12:25 PM, Vitaly Davidovich wrote: The safepoint happiness is unfortunately a separate issue in Hotspot, and it's definitely not happy times :). Part of the problem is the piggybacking of various operations on a safepoint - the

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

On 09/09/2015 08:17 AM, Andrew Haley wrote: On 09/09/2015 02:13 PM, David M. Lloyd wrote: How would you hook into the safepoint to perform the unmapping? You'd have to wait for all threads to arrive at safepoints, wouldn't you? Yes. That happens in the VM already, e.g. when we need

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

On 09/09/2015 07:49 AM, Andrew Haley wrote: On 09/09/2015 01:41 PM, David M. Lloyd wrote: If the answer to both of these can be shown to be affirmative, then I think there is a real viable solution which allows immediate release of backing resources, with the address space being reclaimed by GC

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

If you have access to a Windows development environment, it seems to me that you could help directly with the testing required to determine a solution. I think my proposed remapping approach will work, but it is contingent on testing the following on Windows: * Determine if it is possible

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

its thing. Perhaps such an implementation could suffice until such time that a specialized HotSpot-based solution (like what Andrew described) or other better option could be achieved. On 09/09/2015 07:41 AM, David M. Lloyd wrote: If you have access to a Windows development environment

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

On 09/08/2015 01:37 PM, Andrew Haley wrote: On 09/08/2015 06:54 PM, David M. Lloyd wrote: I think the only questionable platform at this point is Windows (to me at least, given that I do not have much experience on it). That's right, and it's Windows which has the worst problem: on UNIX you

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

On 09/08/2015 12:40 PM, Andrew Haley wrote: On 09/08/2015 06:03 PM, David M. Lloyd wrote: On 09/08/2015 08:11 AM, Andrew Haley wrote: On 09/08/2015 12:37 PM, David M. Lloyd wrote: Then you do the real unmap when the buffer is GC'd (maybe via Cleaner). This is very akin to how file

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

On 09/08/2015 08:03 AM, Mike Hearn wrote: If you're already doing this, why not skip the level of indirection and mprotect the entire mapped region to PROT_NONE when the user unmaps? ... Then you do the real unmap when the buffer is GC'd (maybe via Cleaner). Because the

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

On 09/08/2015 08:11 AM, Andrew Haley wrote: On 09/08/2015 12:37 PM, David M. Lloyd wrote: Then you do the real unmap when the buffer is GC'd (maybe via Cleaner). This is very akin to how file descriptors are cleaned up, AFAICT. Indeed it is, and it's no better than the status quo

One more minor addition to ProcessBuilder

Roger co.: Since you're already on the topic of manipulating pipes, I thought I'd mention one very small yet very useful potential enhancement. It would be very handy to be able to specify a NULL/bit-bucket source/destination for pipes. For the target process' input, the user can

Re: Why isn't Object.notify() a synchronized method?

Since most of the time you have to hold the lock anyway for other reasons, I think this would generally be an unwelcome change since I expect the cost of recursive lock acquisition is nonzero. On 05/28/2015 11:08 AM, Ulf Zibis wrote: Hi all, in the Javadoc of notify(), notifyAll() and

Re: RFR 9: 8077350 Process API Updates Implementation Review

On 04/17/2015 11:53 AM, Roger Riggs wrote: Hi Peter, On 4/17/2015 4:05 AM, Peter Levart wrote: Hi Roger, Retrieving and caching the process start time as soon as ProcessHandle is instantiated might be a good idea. destroy native code would then use pid *and* start time to check the identity

Re: Fw: Re: RFR [9] 8071472: Add field access to support, setting final fields in readObject

On 03/20/2015 09:31 AM, Peter Levart wrote: On 03/20/2015 02:03 PM, David M. Lloyd wrote: private static void altReadObject(ObjectInputStream in, FieldAccess fieldAccess) throws IOException, ClassNotFoundException { // the same as in readObject, but doesn't have

Re: RFR [9] 8071472: Add field setter API for setting final fields in readObject

On 03/25/2015 04:58 PM, Chris Hegarty wrote: On 25 Mar 2015, at 17:32, Peter Levart peter.lev...@gmail.com wrote: On 03/25/2015 05:55 PM, Peter Levart wrote: On 03/25/2015 04:49 PM, Chris Hegarty wrote: I have been thinking about this and I see several solutions: 1. provide protected final

Re: Fw: Re: RFR [9] 8071472: Add field access to support, setting final fields in readObject

Levart wrote: On 03/20/2015 02:03 PM, David M. Lloyd wrote: private static void altReadObject(ObjectInputStream in, FieldAccess fieldAccess) throws IOException, ClassNotFoundException { // the same as in readObject, but doesn't have direct access to instance state, so everything must go

Re: Fw: Re: RFR [9] 8071472: Add field access to support setting final fields in readObject

On 03/20/2015 05:49 AM, Peter Firmstone wrote: - Original message - From Peter Levart peter.lev...@gmail.com Sent Fri, 20 Mar 2015, 01:21:17 EST To Peter Firmstone peter.firmst...@zeus.net.au, core-libs-dev@openjdk.java.net Subject Re: RFR [9] 8071472: Add field access to support

Re: Fw: Re: RFR [9] 8071472: Add field access to support setting final fields in readObject

On 03/20/2015 09:31 AM, Peter Levart wrote: On 03/20/2015 02:03 PM, David M. Lloyd wrote: private static void altReadObject(ObjectInputStream in, FieldAccess fieldAccess) throws IOException, ClassNotFoundException { // the same as in readObject, but doesn't have direct access

Re: JEP 238: Multi-Version JAR Files

On 02/27/2015 07:27 AM, Florian Weimer wrote: On 02/12/2015 09:52 PM, Paul Sandoz wrote: Hi In connection with the JEP there is also a design document to help the discussion: http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md We are especially interesting in

Re: JEP 238: Multi-Version JAR Files

On 02/25/2015 11:41 AM, Paul Sandoz wrote: On Feb 25, 2015, at 5:27 PM, Brian Goetz brian.go...@oracle.com wrote: On 2/12/2015 5:59 PM, Stephen Colebourne wrote: Interesting direction. Reading carefully, the goal is actually very limited in scope, by preventing any public API changes. It

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

It's an awful lot of pain to avoid what IMO should be an obvious addition: (Short|Character|Integer|Long).(get|put)(Little|Big)EndianBytes([value,] byte[] b, int offs) This could (it seems to me) be easily intrinsified, is hugely useful both within and outside of the JDK, and fits perfectly

Re: JEP 102 Process Updates revised API draft

On 02/13/2015 09:15 AM, Peter Levart wrote: On 02/13/2015 03:22 PM, Paul Sandoz wrote: It*is* inconvenient for the user to have to use wildcards in specifying types: CompletableFuture? extends Process cf = process.completableFuture(); ...but it doesn't hinder the use of above 'cf' quite so

Re: JEP 102 Process Updates revised API draft

On 02/09/2015 07:52 PM, Roger Riggs wrote: On 2/9/15 6:44 PM, David M. Lloyd wrote: Also, as a general comment, there isn't really a good explanation as to what the difference is between a normal destroy and a forcible destroy. Given that you've added an isDestroyForcible() method, I think

Re: JEP 102 Process Updates revised API draft

On 02/09/2015 05:25 PM, Roger Riggs wrote: Hi, After a protracted absence from working on JEP 102, the updated API draft provides access to process hierarchies and individual process information; as permitted by the OS. The relationship between Process and ProcessHandle is clarified and the

Re: Explicit Serialization API and Security

At some point, the responsibility *must* fall on the author of the serializable class in question to avoid constructs which are exploitable - like finalizers, and classes that can have side-effects before validation can be completed. On 01/21/2015 02:26 PM, Peter Firmstone wrote: Don't

Re: Explicit Serialization API and Security

On 01/12/2015 05:51 AM, Chris Hegarty wrote: On 08/01/15 22:03, David M. Lloyd wrote: private static void validate(GetField fields) { if (fields.getInt(lo) fields.getInt(hi)) { ... } } ... In fact you cannot validate invariants across multiple objects at all

Re: Explicit Serialization API and Security

On 01/08/2015 02:10 PM, Brian Goetz wrote: 1) Validate invariants A clear and easy to understand mechanism that can validate the deserialized fields. Does not prevent the use of final fields, as the serialization framework will be responsible for setting them. Something along the

Re: Explicit Serialization API and Security

On 01/08/2015 02:32 AM, Peter Firmstone wrote: Thank you all for participating in this discussion. Initially a constructor signature for deserialization was proposed to enforce invariants and encapsulation, however there appears to be interest in using alternative methods, although they appear

Re: Explicit Serialization API and Security

On 01/07/2015 10:02 AM, Peter Levart wrote: On 01/07/2015 03:54 PM, Chris Hegarty wrote: On 06/01/15 17:49, Peter Levart wrote: On 01/06/2015 06:21 PM, Chris Hegarty wrote: On 6 Jan 2015, at 15:06, Peter Levart peter.lev...@gmail.com wrote: On 01/06/2015 04:03 PM, Peter Levart wrote:

Re: Explicit Serialization API and Security

On 01/03/2015 09:36 AM, Peter Levart wrote: On 01/03/2015 01:38 PM, Peter Firmstone wrote: Hi, I would like to know what are the potential issues with simple constructor chaining where each constructor checks the invariant of its class state (with the already initialized state of

Re: Explicit Serialization API and Security

On 01/03/2015 02:29 PM, Peter Firmstone wrote: - Original message - Wouldn't it be better to register for finalization just those instances that complete their construction or deserialization normally? I'm just trying to understand why it is the way it is. Perhaps that might be an

Re: RFR JDK-8066867: Add InputStream transferTo to transfer content to an OutputStream

On 12/09/2014 09:47 AM, Pavel Rappo wrote: Hi everyone, Could you please review my change for JDK-8066867? http://cr.openjdk.java.net/~prappo/8066867/webrev.00/ In the NIO version of this method, it accepts a 'long' parameter which indicates how many bytes should be transferred (similar to

Re: Should some JDK system properties be read only ?

On 12/04/2014 09:42 AM, Seán Coffey wrote: Apologies if this has been raised in past. I've run into issues in the past where bad user code (app server) has set the java.home system property to a value other than the default. This has consequences for apps/code that depend heavily on java.home

Re: Should some JDK system properties be read only ?

On 12/04/2014 10:21 AM, Seán Coffey wrote: On 04/12/2014 16:00, David M. Lloyd wrote: On 12/04/2014 09:42 AM, Seán Coffey wrote: Apologies if this has been raised in past. I've run into issues in the past where bad user code (app server) has set the java.home system property to a value other

Re: RFR: 8060130: Simplify the synchronization of defining and getting java.lang.Package

On 10/14/2014 07:22 PM, Mandy Chung wrote: On 10/13/2014 5:50 AM, David M. Lloyd wrote: On 10/10/2014 07:31 PM, Mandy Chung wrote: On 10/10/2014 8:10 AM, Claes Redestad wrote: Hi all, please review this patch which attempts to clean up synchronization and improve scalability when defining

Re: RFR: 8060130: Simplify the synchronization of defining and getting java.lang.Package

On 10/10/2014 07:31 PM, Mandy Chung wrote: On 10/10/2014 8:10 AM, Claes Redestad wrote: Hi all, please review this patch which attempts to clean up synchronization and improve scalability when defining and getting java.lang.Package objects. I agree with David that getting Package objects

Re: Why is finalize wrong?

On 09/03/2014 06:48 AM, Stanimir Simeonoff wrote: Hi Andrew, On Wed, Sep 3, 2014 at 12:58 PM, Andrew Haley a...@redhat.com wrote: On 03/09/14 01:15, Stanimir Simeonoff wrote: Like David Lloyd mentioned finalize() can be invoked concurrently to some methods (if there is no reachability to

Re: WAR == single classloader was: Benefits of activeReferenceQueue

On 08/04/2014 06:27 AM, Florian Weimer wrote: On 08/01/2014 06:39 AM, Jaroslav Tulach wrote: Dne Út 29. července 2014 14:13:25, Florian Weimer napsal(a): On 07/29/2014 10:05 AM, Jaroslav Tulach wrote: Plus, because there is a single classloader which loads all the classes from a WAR, by

  1   2   3   >