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
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 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 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
I was going to post a patch & feature request to add "goto" into the
language. But I had a baby and so I didn't have time to finish it up,
unfortunately. The best part is that I was (and am) half-serious about
it :)
Doing a JEP is even more clever though. It lends a certain amount of
credi
Excellent :) The reason I got onto this path was building compact DFAs.
It actually seems like something Java ought to be able to do IMO. For
now I'm looking into bytecode generation though, which will probably
suffice.
On 04/04/2012 11:49 AM, Joe Darcy wrote:
On 4/4/2012 8:48 AM, Da
On 06/18/2012 04:12 PM, mark.reinh...@oracle.com wrote:
Posted: http://openjdk.java.net/jeps/155
- Mark
Might Doug's two-field atomic operations support idea possibly be a part
of this (i.e. make it in time for Java 8)?
--
- DML
On 04/27/2009 12:10 PM, Ulf Zibis wrote:
Hi all,
IMHO, implementing "Method-Invocation-Chaining" by simply returning
"this" from regarding methods in Java-API was bad idea, because it
doesn't really work, if a class is subclassed. For example see XxxBuffer
classes, subclassed from java.nio.Bu
On 09/02/2009 11:27 AM, Martin Buchholz wrote:
On Wed, Sep 2, 2009 at 01:07, Ulf Zibis mailto:ulf.zi...@gmx.de>> wrote:
Am 02.09.2009 05:21, Martin Buchholz schrieb:
On Tue, Sep 1, 2009 at 01:29, Ulf Zibis mailto:ulf.zi...@gmx.de>> wrote:
{...@code is now the preferred way. I tried
On 09/02/2009 12:03 PM, Martin Buchholz wrote:
On Wed, Sep 2, 2009 at 09:40, David M. Lloyd mailto:david.ll...@redhat.com>> wrote:
Why not just do {...@code \uD800}? I'm like 60% sure that would work
just fine. :-)
I'm pretty sure it would fail. Prove me wrong!
S
On 09/10/2009 01:47 PM, Xueming Shen wrote:
I think we have enough discussion on this topic, it's time to make a
final decision. Seems like we are all happy on the
changes in Deflater and new DOS.flush(mode), the only difference is
whether or not we should change the existing
behavior of DOS.fl
On 09/10/2009 04:51 PM, Xueming Shen wrote:
David M. Lloyd wrote:
On 09/10/2009 01:47 PM, Xueming Shen wrote:
I think we have enough discussion on this topic, it's time to make a
final decision. Seems like we are all happy on the
changes in Deflater and new DOS.flush(mode), the only diffe
On 09/12/2009 04:45 PM, Martin Buchholz wrote:
On Fri, Sep 11, 2009 at 16:13, Xueming Shen wrote:
David wrote:
This is not unusual in the JDK or elsewhere - that a stream calls the
underlying stream's flush() method I mean - and I think in the (unlikely) event
that someone wants to flush the u
On 09/16/2009 10:20 AM, Joel Kamentz wrote:
It's more for I/O, not general Object, but some methods which I almost ALWAYS
use in a project are null-safe canonicalization and null-safe close methods.
Yeah I think that these would belong in an I/O package. That said...
static File canonic
Java has had "real" enums since Java 5:
http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html
- DML
On 09/16/2009 04:03 PM, assembling signals wrote:
Hello everyone!
I want to propose an enum-enhancing feature, which would not require
any changes to the language spec and would work as
On 10/06/2009 06:43 PM, Joe Darcy wrote:
David Holmes - Sun Microsystems wrote:
Hi Joe,
I thought the point that Jason Mehrens was making was that this:
+ public static String toString(Object o) {
+ String.valueOf(o); hat Jason Mehrens was making was that this:
+ public static String toString
On 11/09/2009 03:30 PM, Pawel Veselov wrote:
Hi,
it again caught my attention, and I though that may be there is
something that can be done about this.
The issue is obvious -- having 'final transient' instance fields makes
little sense if the object is ever serialized.
Logically, there may be pe
This is exactly the solution I present to users of JBoss Marshalling. The
access check performed verifies that the field being updated is a
non-static instance field (final or otherwise, any access level) of the
caller's class; IllegalAccessException is then not thrown at "runtime" when
the fi
There is no need to deal with Unsafe for this. If you use a reflection
Field, while ugly, it *does* publish writes to a final field with volatile
semantics internally. I would argue that using a ThreadLocal in this
fashion would be far uglier.
There is another alternative. Use writeReplace
As they should. I agree that this diagnostic should exist. If they have
broken code which triggers the warning, I for one have no sympathy for them.
Put another way, there's no such thing as "incidental" serializability.
Like it or not, you're taking on that contract when you extend a class
On 08/04/2010 10:24 AM, Florian Weimer wrote:
Inner exception classes probably should be non-static.
You mean static, surely?
And many incidentally serializable classes already receive a warning under
-Xlint due to a missing serialVersionUID field.
If necessary, the warning could be restric
On 11/22/2010 07:52 AM, Alan Bateman wrote:
This is a patch to default deserialization so that it uses
volatile-write when setting final fields:
http://cr.openjdk.java.net/~alanb/6647361/webrev/
Please don't go farther down the path of "only JDK/proprietary classes
can properly deserialize".
In my experience, the following are true:
1. Usage of any object has a hash key whose equals() result depends on
external or mutable factors should never be used as a hash key for any
reason.
2. Any object class for which, when given two instances "a" and "b", a
== b is true but a.equals(b) is fal
On 01/13/2011 02:06 PM, Brian Goetz wrote:
I propose to change these to be called checkNonNull(), so their
null-checking behavior is obvious to readers of code
I agree with this, but...
and to leave room
to LATER provide methods like
public static T nonNull(T[] obj) {
return (obj == null) ?
On 01/13/2011 04:31 PM, Rémi Forax wrote:
On 01/13/2011 11:11 PM, Brian Goetz wrote:
I disagree with Tom here. We have *already* made the billion dollar
mistake, and we can't eliminate that headache (but we can provide
easier access to aspirin.) Java developers are *constantly* writing
methods
On 01/13/2011 05:36 PM, David Holmes wrote:
Brian Goetz said the following on 01/14/11 09:15:
to go either way (both checkNonNull and ensureNonNull better
match the actual behavior of the method than plain nonNull) but
we might as well pick the right convention.
Rémi's throwIfNull(x) suggestio
On 01/27/2011 10:58 PM, David Holmes wrote:
Rémi Forax said the following on 01/27/11 18:43:
On 01/27/2011 09:38 AM, Stephen Colebourne wrote:
As I said before, removing this method is the best option now. Get it
right in v8.
Stephen
I think we can't.
This method is already used at many place
On 02/14/2011 07:12 PM, David Holmes wrote:
Dmytro Sheyko said the following on 02/15/11 03:49:
I can see that such system property as "sun.cpu.isalist" is not set on
Linux, but it is set on Solaris and Windows.
What is the purpose of this property and shouldn't it be set on Linux
as well?
I d
This series of patches adds the java.io.Closeable interface to a few
different core JDK classes. Some of them are more obvious/better fits than
others; I've split the patch up into groups based on how "out there" I
think the idea is. :-)
Anyway please comment on these patches.
- DML
Add Closeable to core I/O classes and interfaces. This one is a no-brainer
- I hope. ;-)
Included is java.util.zip.ZipFile, since that class has a close method
which exactly matches the Closeable interface specification.
- DML
--
diff -r 92ea0ac77d2f src/share/classes/java/io/ObjectInput.j
Add Closeable to two util classes: Scanner, and the JDK logging Handler class.
--
diff -r 92ea0ac77d2f src/share/classes/java/util/Scanner.java
--- a/src/share/classes/java/util/Scanner.java Tue Apr 22 18:58:40 2008 +0200
+++ b/src/share/classes/java/util/Scanner.java Thu May 01 09:58:43 2008
Add Closeable to MIDI and sound channel classes. Though the close() method
on these classes don't throw an exception, they still could implement this
interface.
- DML
--
diff -r 92ea0ac77d2f src/share/classes/javax/sound/midi/MidiDevice.java
--- a/src/share/classes/javax/sound/midi/MidiDevic
On 05/03/2008 08:40 AM, Paulo Levi wrote:
Is it possible to make the java.sql interface Connection, Statement and
ResultSet descend from closeable?
Not that I'm aware of, since SQLException doesn't extend IOException. That
said, it might be nice to have a java.sql.Closeable for some future JD
On 05/05/2008 09:09 AM, Neal Gafter wrote:
On Mon, May 5, 2008 at 5:54 AM, David M. Lloyd <[EMAIL PROTECTED]> wrote:
On 05/03/2008 08:40 AM, Paulo Levi wrote:
Is it possible to make the java.sql interface Connection, Statement and
ResultSet descend from closeable?
Not that I'
Is there an effort underway to produce a JSR for adding an embedded HTTP
server (like the one currently in OpenJDK under the com.sun.net.httpserver)
to the JDK (under e.g. javax.net.httpserver or similar)?
If not... does anyone besides me think this is a good idea?
- DML
On 05/27/2008 01:29 PM, Juha Lindfors wrote:
On Tue, May 27, 2008 at 7:03 PM, David M. Lloyd <[EMAIL PROTECTED]>
wrote:
If not... does anyone besides me think this is a good idea?
I think it would be a great idea... the only reason I've shied away from
using the current embedded
On 05/27/2008 02:15 PM, Alan Bateman wrote:
Juha Lindfors wrote:
On Tue, May 27, 2008 at 7:03 PM, David M. Lloyd
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
If not... does anyone besides me think this is a good idea?
I think it would be a great idea... the
On 06/18/2008 11:03 AM, Christopher Hegarty - Sun Microsystems Ireland wrote:
I think that this thread should be moved to the net-dev alias.
I know that Michael is certainly a member of net-dev and is currently
the owner of the HTTP server.
OK, great. To restate the original subject of this
On 06/24/2008 11:08 AM, Ulf Zibis wrote:
I many cases I also could shorten the encoding mappings.
Example:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/milestone1/src/sun/nio/cs/ext/IBM870.java?rev=223&view=markup
Would a 'switch' statement
On 06/25/2008 03:57 AM, Ulf Zibis wrote:
Hi David,
can you show an example using a 'switch' statement which is shorter or
faster than:
char c = c2bMap.charAt(c2bMapIndex[(current & MASK1) >>
SHIFT] + (current & MASK2));
Faster - maybe or maybe not; but the "c2bMap", being sparse
On 06/25/2008 11:33 AM, Ulf Zibis wrote:
Hi David,
please don't CC to me. Otherwise I get your message twice. I read the list.
Every poster on every list seems to have their own preference :-) It would
help if there were proper Reply-To: headers in messages from the mailing list.
Internall
On 08/01/2008 11:04 AM, Martin Buchholz wrote:
As often happens with me, this change is ever-expanding out of scope.
If we have consensus on the covariant returns for other Buffers,
I am willing to add these to the change.
You've got my vote! Not that it's worth anything. :-)
- DML
On 08/02/2008 04:54 AM, Ulf Zibis wrote:
Am 01.08.2008 10:39, Alan Bateman schrieb:
In particular the Buffer flip/etc. methods come up quite often as the
more specific return type would facilitate better method invocation
chaining.
Some time ago I've discussed this with Neal Gafter. My conclu
One could always go the awt route:
public interface CharSequence2 extends CharSequence {
...new methods here...
}
then change things to implement CharSequence2 instead, using covariance as
appropriate (thus at least somewhat avoiding the casting problem). At
least then the program would f
Currently, nested enum members are labeled as "static class"; furthermore,
nested elements of interfaces and elements that *are* interfaces are
redundantly labeled "static".
This simple patch would cause nested members to be properly labeled.
--
Index:
tl/langtools/src/share/classes/com/sun/t
Just a random thought I had. Why not add methods to create two- or
three-element sets in the same spirit as Set singleton(T)? The idea
could be expanded beyond three elements but I think the initial comparisons
would get too complex.
Also fixes a javadoc nit in singleton().
BTW, I'm sceptic
On 02/16/2009 10:22 AM, Ulf Zibis wrote:
Hi all,
can anybody tell me, how I could get al list or enumeration of the
classes, which belong to a package.
I can't see any appropriate method in java.lang.Package :-(
This isn't really possible at run time, since one doesn't know whether a
class
After running into the problem described in this bug for the umpteenth
time, I decided to get off my duff and do something about it.
Following are two patches. The first one adds the notion of class-local
storage, and the second adds class loader-local storage; both mechanisms
work basically
/
+package java.lang;
+
+import java.util.Map;
+
+/**
+ * This class provides class local variables. Data stored in a class local
+ * variable is strongly referenced by the class it is associated with.
+ *
+ * @author David M. Lloyd
+ * @param the type of the value of this class local variable
+ *
ed additional information or
+ * have any questions.
+ */
+package java.lang;
+
+import java.util.Map;
+
+/**
+ * This class provides class loader local variables. Data stored in a class
+ * loader local variable is strongly referenced by the class loader it is
+ * associated with.
+ *
+ * @author D
On 02/27/2009 12:10 PM, Bob Lee wrote:
I have a simpler and more secure solution. I just need one method on
ClassLoader:
public class ClassLoader {
public void keepReferenceTo(Object o) { ... }
...
}
The ClassLoader would keep a strong reference to the passed reference
indefinitely (usi
On 02/27/2009 12:52 PM, Bob Lee wrote:
On Fri, Feb 27, 2009 at 10:40 AM, David M. Lloyd wrote:
Seems like a reasonable alternate approach, *however* I think there ought to
be a way to clear the reference as well, which would complicate matters a
little with respect to the internal data
On 02/27/2009 01:15 PM, Bob Lee wrote:
On Fri, Feb 27, 2009 at 11:04 AM, David M. Lloyd wrote:
A couple use cases, off the top of my head:
1) I've got a set of FooBars that associate with Classes; now for whatever
reason, I want to change the FooBar that is associated with the Class. Th
On 02/27/2009 02:18 PM, Bob Lee wrote:
On Fri, Feb 27, 2009 at 11:44 AM, David M. Lloyd wrote:
WeakHashMap, Externalizer>()
*fails* because Externalizer instances are usually customized to the class
they externalize (which, by the way, could well be a system class). This
means t
On 02/27/2009 02:59 PM, Bob Lee wrote:
On Fri, Feb 27, 2009 at 12:48 PM, David M. Lloyd wrote:
I don't think you understood what I wrote
I understood. I just think you're trying to solve a problem that no
one really has. 99% of the time, the problem is with a class from a
parent cl
On 02/27/2009 03:51 PM, Bob Lee wrote:
There's no need for insults, David. Have some perspective. I've been
nothing but civil and respectful (even after you presumed to know what I
do and don't understand).
I haven't insulted you that I am aware of, only stated the facts as I see
them. Since
On 02/27/2009 07:08 PM, Bob Lee wrote:
David,
I regret making my suggestion in the first place. I really think we need
ephemerons, but for the sake of discussion:
OK, so you say that you don't think this feature should exist, period,
until and unless ephemerons are implemented. Why? There'
On 03/02/2009 10:45 PM, Bob Lee wrote:
David,
Here's the problem I'd like to see solved: enable a library to hold an
indirect reference to a Class without preventing that Class's loader
from being reclaimed. The reclamation should happen automatically when
the loader is not otherwise strongly
On 03/03/2009 12:13 PM, Bob Lee wrote:
On Mon, Mar 2, 2009 at 10:37 PM, David M. Lloyd <mailto:david.ll...@redhat.com>> wrote:
If not, then there is no automatic solution possible, even with
special VM ephemeron support (this basically IS an ephemeron
implementation,
On 03/03/2009 02:17 PM, Bob Lee wrote:
On Tue, Mar 3, 2009 at 11:43 AM, David M. Lloyd <mailto:david.ll...@redhat.com>> wrote:
No, actually what I've implemented *exactly* matches this
definition: a mapping where the value is held strongly until the key
is known
Switch to atomic ops for the various sequence numbers, as opposed to
synchronizing on the class object on every object construction.
- DML
--
diff -r dde3fe2e8164 src/share/classes/java/util/logging/LogRecord.java
--- a/src/share/classes/java/util/logging/LogRecord.java Wed Feb 25
14:32:01 200
On 03/12/2009 05:41 PM, Mark Reinhold wrote:
You might want to have a look at the new contribution process [1].
Using that will increase the probability that someone will evaluate
your patch sooner rather than later.
- Mark
[1] http://openjdk.java.net/contribute
Consider my post to be step 2
On 03/12/2009 07:01 PM, Dalibor Topic wrote:
David M. Lloyd wrote:
On 03/12/2009 05:41 PM, Mark Reinhold wrote:
You might want to have a look at the new contribution process [1].
Using that will increase the probability that someone will evaluate
your patch sooner rather than later.
- Mark
15:35, David M. Lloyd wrote:
Switch to atomic ops for the various sequence numbers, as opposed to
synchronizing on the class object on every object construction.
- DML
--
diff -r dde3fe2e8164 src/share/classes/java/util/logging/LogRecord.java
--- a/src/share/classes/java/util/logging/LogRecord
On 03/12/2009 07:13 PM, Andrew John Hughes wrote:
This is actually an interesting rare case where two atomic variables
can replace a synchronised block. Looking at the code, there seems to
be no issue with the thread being descheduled and then resumed during
the operation of this constructor. B
Opened as a BugZilla bug:
https://bugs.openjdk.java.net/show_bug.cgi?id=100021
- DML
On 03/12/2009 05:35 PM, David M. Lloyd wrote:
Switch to atomic ops for the various sequence numbers, as opposed to
synchronizing on the class object on every object construction.
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
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
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 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 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 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
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/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
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 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
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/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
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
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
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
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
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/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
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: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 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
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 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)
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
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/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
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
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
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
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
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
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 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/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
1 - 100 of 267 matches
Mail list logo
