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:
>>
>> Suggest
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 `remo
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 possible
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
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 co
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 is
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
that
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
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
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: http://hg.openjdk.java.n
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 is
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)
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.
Can
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 tha
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 g
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:
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 (obvi
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,
rea
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
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 likely
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 m
Peter
On 03/28/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 pr
ookup process to try locating 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 i
hese APIs, then AFAICT 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)"
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() with no
adapt 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 use
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
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
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 serv
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
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 implemen
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
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 op
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
pro
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 rela
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 pos
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 in
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
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
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 permis
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, not
o better.
On Fri, Jan 22, 2016 at 8:34 AM, David M. Lloyd
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 a limit on
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 co
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 w
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:
http://cr.openjdk.
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 finaliz
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 all
Great! Now all we need is a way to tell threads to remove all thread
locals on exit, and the scourge of ITL might be somewhat mitigated. :-)
On 12/08/2015 08:15 AM, Chris Hegarty wrote:
Many threads created by the platform are short lived and perform some
simple async operation on behalf of the
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 it
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 getCallerCl
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 absent
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
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
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) -> s.map(StackFrame::getDeclaringClass)
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 encourag
On 10/30/2015 11:24 PM, Mandy Chung wrote:
On Oct 30, 2015, at 3:38 PM, David M. Lloyd 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
done - maybe even a Stream
On 10/30/2015 03:39 PM, Mandy Chung wrote:
On Oct 30, 2015, at 12:59 PM, David M. Lloyd 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
just skip the interface.
Locals and
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 StackWalker(StackWalke
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. Or maybe the stre
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"
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 wer
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
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 effec
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
h
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 safepoin
r GC to do 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 envir
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
On 09/09/2015 08:06 AM, Andrew Haley wrote:
On 09/09/2015 01:58 PM, David M. Lloyd wrote:
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
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
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 to
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: o
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
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
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 reas
On 09/08/2015 04:30 AM, Andrew Haley wrote:
On 09/08/2015 09:58 AM, Paul Sandoz wrote:
This is fundamentally about *integrity* of the runtime. It follows
there are security implications, but it’s still fundamentally an
integrity issue and guarding an unsafe operation with a Security
Manager is
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 generall
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 wait(..
I believe this is similar to how InterruptedIOException works, FWIW.
On 04/23/2015 09:20 AM, Peter Levart wrote:
Hi Chris,
Currently InputStream guarantees that either some bytes are read *xor*
EOF (-1) is returned *xor* IOException is thrown. Even with default
implementation of read(byte[], in
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
On 03/25/2015 04:58 PM, Chris Hegarty wrote:
On 25 Mar 2015, at 17:32, Peter Levart 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 methods
ObjectInputStr
the stream, a StreamCorruptedException will
> > > occur when an earlier class implementation reads it.
> > >
> > > For that reason, I'd reccommend against including it in the spec.
> > >
> > > Regards,
> > >
> > > Peter.
> >
3/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
acce
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
acce
On 03/20/2015 05:49 AM, Peter Firmstone wrote:
- Original message -
From Peter Levart
Sent Fri, 20 Mar 2015, 01:21:17 EST
To Peter Firmstone , core-libs-dev@openjdk.java.net
Subject Re: RFR [9] 8071472: Add field access to support setting final fields
in readObject
On 03/19/2015 11
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 hearing
On 02/25/2015 11:41 AM, Paul Sandoz wrote:
On Feb 25, 2015, at 5:27 PM, Brian Goetz 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 doesn't help adoption o
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 w
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 cf = process.completableFuture();
>
>...but it doesn't hinder the use of above 'cf' quite so much as 'len'
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,
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 secu
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 forget
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
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
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 t
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 wrote:
On 01/06/2015 04:03 PM, Peter Levart wrote:
private void readObject(Obje
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 o
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 sup
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 s
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
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 ret
1 - 100 of 267 matches
Mail list logo
