o - I'm hoping to port this to JDK 11u also so I might spin the
specification changes into a different bug ID.
regards,
Sean.
On 03/02/2020 09:05, Peter Levart wrote:
Hi Seán,
On 2/1/20 12:22 AM, Seán Coffey wrote:
The following is also possible:
// 1st try finding a Ser
Hi Seán,
On 2/1/20 12:22 AM, Seán Coffey wrote:
The following is also possible:
// 1st try finding a ServiceLoader.Provider with type()
of correct name
factory = loader
.stream()
.filter(p -> p.type().getName().equals(className))
d
approach
* insert use of sleep which testing GC.
http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/
regards,
Sean.
On 30/01/2020 07:59, Peter Levart wrote:
Hi Seán,
WeakHashMap is not safe to be called concurrently. Even get() method,
although it may seem read-only, can modify interna
On 1/30/20 8:59 AM, Peter Levart wrote:
So if you know that the (implementation class of)
InitialContextFactory instance is always resolvable (by class name)
from the ClassLoader you are using for the caching key (the TCCL),
then this utility might be just right for your purpose.
Thinking
Hi Seán,
WeakHashMap is not safe to be called concurrently. Even get() method,
although it may seem read-only, can modify internal state (expunging
stale Weak entries), so holding a READ lock while accessing WeakHashMap
it is wrong.
getInitialContext() static method is called with an env Has
Hi,
On 12/2/19 6:13 PM, Bob Vandette wrote:
2)
How should we deal with "not supported" for booleans/arrays, etc.?
Would it make sense to return record objects from the Metrics API so
that this could be dealt with? E.g.
Metrics m = ...
MetricResult result = m.getCpuSetCpus();
switch(result.getTy
Hi Maurizio,
Nice work!
I see the API prefixes each independent access to memory with a call to
the following MemorySegmentImpl method:
157 @Override
158 public final void checkValidState() {
159 if (owner != Thread.currentThread()) {
160 throw new IllegalState
Hi Mandy,
http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.03/
In Lookup's findBoundCallerClass and checkSecurityManager the javadoc is
still talking about private access only although the checks are now made
against full privilege access.
Some possible nano optimization / simpli
Hi Hamlin,
in TCPTransport.decrementExportCount():
283 try {
284 if (tcpLog.isLoggable(Log.BRIEF)) {
285 tcpLog.log(Log.BRIEF, "close server socket on
" + ss);
286 }
287 ss.close();
288 } catch (I
= 2331 ms (+106%)
webrev.04: Elapsed time = 3746 ms (+ 28%)
I'll measure larger benchmark and try to think if we can reduce the
overhead of memory barrier.
Regards,
Ogata
Peter Levart wrote on 2019/10/09 16:44:13:
From: Peter Levart
To: Kazunori Ogata , core-libs-dev@openjdk.java.net
On 10/8/19 8:37 PM, Claes Redestad wrote:
On 2019-10-08 18:57, Kazunori Ogata wrote:
Hi Claes,
Thank you for your review and comment.
I was also wondering why only these two fields aren't initialized in the
constructor. Shall I also make the change you mentioned?
I think it might be be
Hi Ogata,
May I just add that volatile field ensured that MethodAccessor object
was correctly published. DelegatingMethodAccessortImpl is not safe to be
published via data race because it contains plain `delegate` field
initialized in the constructor. In addition, the object that is first
ass
Hi Stuart,
I also prefer your wording. There's just a nit...
On 10/5/19 1:46 AM, Stuart Marks wrote:
On 10/3/19 8:32 AM, Joe Darcy wrote:
In response to the recent and on-going review of serializable types
in the base module and elsewhere, I thought it would be helpful if
the collections sp
Oh god, a typo in a typo comment... I better go to sleep now ;-)
On 10/4/19 11:14 PM, Peter Levart wrote:
+ * serialized. Otherwise, is one or more objects in a collection are
s/is/in/
s/is/if/
Peter
Hi Joe,
On 10/3/19 5:32 PM, Joe Darcy wrote:
Hello,
In response to the recent and on-going review of serializable types in
the base module and elsewhere, I thought it would be helpful if the
collections specs discussed how collections were serialiazable. In
particular, the proposed terminolo
Hi Ivan,
On 10/1/19 10:26 PM, Ivan Gerasimov wrote:
Hello!
The constructors of SocketPermission and FilePermission expect a
String argument with comma-separated list of actions.
If the list is malformed, then the constructors throw
IllegalArgumentException.
It turns out that the current i
On 9/25/19 12:15 PM, Remi Forax wrote:
that said, i believe we should deprecate LinkedList (and any other List
implementation that doesn't implement RandomAccess) because there are too much
code out there that suppose that list.get() is O(1).
Hi Remi,
Deprecating LinkedList as a whole is may
Once more, for the list (sorry)...
Hi,
On 9/21/19 12:31 PM, Chris Hegarty wrote:
Roger,
On 20 Sep 2019, at 19:51, Roger Riggs wrote:
Please review code cleanup that will remove the need to suppress soon
to be introduced
warnings [1] about static typing of serialization related fields.
A f
Hi Joe,
I've been thinking of this example:
83 final class Ser implements Externalizable {
84
...
99 /** The object being serialized. */
100 @SuppressWarnings("serial") // Not statically typed as
Serializable
101 private Object object;
Externalizable does extend Serializa
Hi Claes,
Your changes look good. But I spotted a pre-existing and unusual use of
@Stable annotation in java.lang.invoke.MethodTypeForm class:
// Cached adapter information:
@Stable final SoftReference[] methodHandles;
// Cached lambda form information, for basic types only:
f
patibility problem, it's really a bug.
User can't understand why the size method return a negative number.
Best, lamber-ken
-- --
??: "Peter Levart"??: ""<2217232...@qq.com&
javadoc of the method described this corner case, he/she
would understand?
Regards, Peter
Best, lamber-ken
--?0?2?0?2--
*??????:*?0?2"Peter Levart";
*:*?0?22019??9??5??(??) 3:51
*??:*?0?2""<2217232...@qq.c
Hi 未来阳光,
As David has pointed out, your proposed fix would break binary and
source compatibility of BitSet.size() method, so it is not acceptable.
BitSet API allows addressing individual bits using non-negative 'int'
typed indexes (analogous to indexes of Java arrays). The range of
indexes i
On 8/13/19 3:57 PM, Aleksey Shipilev wrote:
On 8/13/19 3:33 AM, Mandy Chung wrote:
On 8/12/19 5:13 PM, Frederic Parain wrote:
96 // VM adds 1 to the code index to StackFrameInfo::bci field such that
97 // zero (and negative values) indicates invalid BCI. So substract 1.
http://cr.openjdk.jav
Hi Mandy,
Just a question...
On 8/12/19 10:24 PM, Mandy Chung wrote:
Having a second thought, I'm keeping @Stable bci field while zero
indicates an invalid BCI that makes it obvious that this field will be
updated. VM will set StackFrameInfo::bci to value+1.
http://cr.openjdk.java.net/~mchu
On 7/31/19 9:59 AM, Peter Levart wrote:
Hi,
I think Daniel is talking about the "dispatch" semantics of
unreflectSpecial here, right Daniel?
The findSpecial / unreflectSpecial is a MethodHandle equivalent for
bytecode instruction invokespecial (sans actual invoking).
invoke
Hi,
I think Daniel is talking about the "dispatch" semantics of
unreflectSpecial here, right Daniel?
The findSpecial / unreflectSpecial is a MethodHandle equivalent for
bytecode instruction invokespecial (sans actual invoking). invokespecial
is typically used for implementing the super.metho
Hi Brian,
On 7/26/19 12:42 AM, Brian Burkhalter wrote:
On Jul 11, 2019, at 12:52 AM, Peter Levart <mailto:peter.lev...@gmail.com>> wrote:
On 7/11/19 9:47 AM, Peter Levart wrote:
http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/
Another
Hi Claes,
Am I reading correct that package-private
ClassLoader.loadLibrary(Class fromClass, String name, boolean
isAbsolute) wouldn't need to consult SecurityManager wasn't it for
accessing system properties in private ClassLoader.initializePath(String
propName). So perhaps if the two calls
Hi Jaikiran,
On 7/12/19 9:07 AM, Jaikiran Pai wrote:
The new updated webrev is at
http://cr.openjdk.java.net/~jpai/webrev/8225763/4/webrev/
I don't know if there are any custom subclasses of Inflater/Deflater
around and what they do, but hypothetically consider a subclass of
Deflater simila
On 7/11/19 9:47 AM, Peter Levart wrote:
http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/
Another thing to consider (done in above webrev.02) is what to do with
unbalanced cancelDeleteOnExit(). I think it is better to throw exception
than to
Hi,
On 7/11/19 3:51 AM, Ivan Gerasimov wrote:
On 7/10/19 5:17 PM, Brian Burkhalter wrote:
I incorporated Peter’s version, adding the security check in
cancelDeleteOnExit(), tweaking its verbiage along with that of
deleteOnExit(), and modified the test DeleteOnExit to verify the new
method. T
On 7/10/19 6:03 PM, Joe Darcy wrote:
Hello,
I'd advise against including at least part of the comment
// declare serialization compatibility with JDK 8 (see JDK-8227368)
We generally don't include bug numbers in the text of the code and
rely mapping from the SCM to the bug database to pro
Hi,
On 7/9/19 8:08 PM, Brian Burkhalter wrote:
On Jul 9, 2019, at 8:31 AM, Brian Burkhalter
wrote:
Since deleteOnExit() is an deliberate act, perhaps there should be a
corresponding withdrawDeleteOnExit() that reverses it so that it is intentional
and not a side-effect of other File method
Hi Stuart,
On 7/10/19 4:32 AM, Stuart Marks wrote:
1. New changeset with constant version of EnumSet.serialVersionUID.
This is already in the webrev.01 changeset. webrev.02 is an attempt
to sneak the change without being visible in the serialized-form.html.
Ah. I skipped webrev.01 because I
On 7/9/19 1:57 AM, Stuart Marks wrote:
2. Create draft CSR.
Created:
https://bugs.openjdk.java.net/browse/JDK-8227432
Regards, Peter
ngeset. webrev.02 is an attempt to
sneak the change without being visible in the serialized-form.html.
2. Create draft CSR.
I'll try that right away.
Regards, Peter
Thanks,
s'marks
[1] http://openjdk.java.net/jeps/3
[2] http://openjdk.java.net/projects/jdk/13/
On 7/7/
On 7/7/19 4:31 PM, Peter Levart wrote:
On 6/29/19 2:00 AM, Stuart Marks wrote:
Daniel Fuchs pointed me to a weird thing they had to do with the
serialVersionUID in one of the JMX classes:
https://hg.openjdk.java.net/jdk/jdk/file/c59f36ed7b52/src/java.management/share/classes/javax/management
, it would seem sensible to file a bug and start on a fix
for the current release(s). Would you be able to do that?
Again, thanks for finding this.
s'marks
On 6/18/19 7:32 AM, Peter Levart wrote:
On 6/18/19 4:00 PM, Martin Buchholz wrote:
Java Historian says:
I was a reviewer for
8:24 AM, Peter Levart wrote:
Hi Mandy,
On 7/2/19 7:20 PM, Mandy Chung wrote:
Webrev updated:
http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.01/
I just skimmed across code and I think there's a little optimization
possible in VerifyAccess:
:
...instead of seting prevLookupModu
Hi Mandy,
On 7/2/19 7:20 PM, Mandy Chung wrote:
Webrev updated:
http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.01/
I just skimmed across code and I think there's a little optimization
possible in VerifyAccess:
224 // cross-module access
225 // 1. refc is i
On 6/21/19 9:41 AM, Andrew Haley wrote:
On 6/20/19 9:31 PM, Peter Levart wrote:
I would also add overflow checks when computing the length of
resulting byte[]. First I would pre-check the length of passed in
int[] array (it must be less than Integer.MAX_VALUE / 3), then
checking for
On 6/20/19 2:39 PM, Kasper Nielsen wrote:
If you allowed a two-time pass of the primitive array you could
actually create a version that only allocated the actual String and
backing array.
I tried implementing it
https://gist.github.com/kaspernielsen/62e4eedffdb395228777925551a45e7f
And got a
Hi,
On 6/20/19 10:50 AM, Kasper Nielsen wrote:
Hi,
On Wed, 19 Jun 2019 at 14:12, Сергей Цыпанов wrote:
Hello,
in JDK code base we have many places (mainly in j.u.Arrays) where we convert
array to String using verbose constructions with StringBuilder.
As far as we have got StringJoiner for
quirement
simply be relaxed with no ill consequences?
Regards, Peter
On Tue, Jun 18, 2019 at 5:32 AM Peter Levart <mailto:peter.lev...@gmail.com>> wrote:
Hi,
I recently stumbled on an exception thrown when deserializing stream
produced on JDK 8 and read with JDK 11. I
Hi,
I recently stumbled on an exception thrown when deserializing stream
produced on JDK 8 and read with JDK 11. I narrowed the problem down to
serialization/deserialization of a public EnumSet.class object. There
were several changes made to EnumSet in the Mercurial history of jdk
repo, but
On 5/31/19 7:24 PM, Roger Riggs wrote:
Hi Martin,
True, calling System.gc() and then checking for its hoped-for/expected
side-effects is the norm.
But its robustness depends on a combination of gc implementation
behavior and
the particular side-effect expected: allocation, reference processi
Yes Roger, this sounds better to me.
Maybe even easier:
"There is no guarantee that this effort will recycle any particular
number of unused objects, reclaim any particular amount of space, or
complete before the method returns (or ever)."
So, hypothetically, the effort triggered by System.g
Hi,
On 5/29/19 9:25 PM, Roger Riggs wrote:
Any other comments on:
"* Runs the garbage collector in the Java Virtual Machine.
*
* Calling this method suggests that the Java Virtual Machine
* expend effort toward recycling unused objects in order to
* make the memory they currently occupy availab
On 5/26/19 6:25 PM, Martin Buchholz wrote:
On Mon, May 13, 2019 at 5:29 PM Stuart Marks
wrote:
- addition of FIXME comment and reference to javadoc bug report, where
doc
comment from interface cannot be inherited
This is yet another symptom of Java's fundamental design mistake of being
Hi,
Excuse me for asking, but I can't find any text describing motivation
for introduction of this method in JEP-355 other than "Developers will
have access to this algorithm via String::stripIndent instance method"...
If I understand the JEP correctly, this is an algorithm that is applied
t
On 5/20/19 11:11 AM, Ivan Gerasimov wrote:
Hi Peter!
On 5/19/19 11:17 PM, Peter Levart wrote:
Hi Ivan, Roger,
What about "calcNewLength" ?
The word "new" gives enough hint as to what the method does - it
calculates the length of new array to be allocated instead o
Hi Ivan, Roger,
What about "calcNewLength" ?
The word "new" gives enough hint as to what the method does - it
calculates the length of new array to be allocated instead of old one.
Regards, Peter
On 5/17/19 8:45 PM, Ivan Gerasimov wrote:
Hi Roger!
I think that not only the name, but also t
Hi Alan,
I can sympathize with the performance loss aspect of this patch, but I
nevertheless think it is a move in the right direction. You must admit
that the performance optimization of AbstractSet.removeAll was a rather
shaky one (dependent on the relative sizes of the two collections) and
Hi Ivan,
On 5/9/19 8:07 PM, Ivan Gerasimov wrote:
3. I know that this is not new and has been copied from the old code.
However,
I'm not sure I understand the meaning of "unless necessary" here:
/**
* The maximum size of array to allocate (unless necessary).
It means that if the min
On 4/30/19 6:43 AM, Ivan Gerasimov wrote:
I used StringConcatHelper.newArray() to avoid bringing Unsafe into
StringLatin1.
In the StringLatin1.replace(), the newly allocated array is guaranteed
to be filled up, and the filling code should never throw, so I believe
using uninitialized arrays
Hi Claes,
On 4/28/19 8:24 PM, Peter Levart wrote:
Hi Claes,
If you had just one prepend method shape:
static long prepend(long indexCoder, byte[] buf, String prefix,
long value, String suffix) {
if (suffix != null) indexCoder = prepend(indexCoder, buf,
suffix
/Claes
On 2019-04-26 15:55, Claes Redestad wrote:
Hi Peter,
thanks for looking at this!
On 2019-04-26 11:08, Peter Levart wrote:
Hi Claes,
I wonder if it is even possible to create a test that would do
something like the following:
String s = ...
String s2 = s + "const1&qu
On 4/26/19 11:08 AM, Peter Levart wrote:
I wonder if it is even possible to create a test that would do
something like the following:
String s = ...
String s2 = s + "const1" + "const2" + s;
...since javac concatenates consecutive constants into a singl
Hi Claes,
I wonder if it is even possible to create a test that would do something
like the following:
String s = ...
String s2 = s + "const1" + "const2" + s;
...since javac concatenates consecutive constants into a single
constant. So this actually becomes:
String
Just a thought...
Would it be feasible to create a brand new "Generic Caching Filesystem"
implementation that would delegate to another filesystem for persistent
storage (be it ZipFilesystem or any other) and implement interesting
caching strategies (lazy flushing, concurrent flushing, etc...)
On 4/9/19 10:42 AM, Claes Redestad wrote:
Hi Andrew,
On 2019-04-09 10:20, Andrew Dinn wrote:
If the patch is to go in -- and I concede there is an acceptable
argument for that -- then it
needs commenting to help avoid this happening.
open.02 already adds what I believed to be sufficient c
Hi Aleksey,
On 4/9/19 10:11 AM, Aleksey Shipilev wrote:
2. No risk of hashcode recomputation for the 2^-32 case.
This might seem laughable, until you remember that it's exactly
those cases that DOS attackers like to create.
Alt-hashing covers this obscure case in the course of mitigating much
On 4/8/19 1:40 PM, Aleksey Shipilev wrote:
On 4/8/19 1:28 PM, Peter Levart wrote:
The reasoning is very similar as with just one field. With one field (hash) the
thread sees either
the default value (0) or a non-zero value calculated either by this thread
sometime before or by a
concurrent
On 4/8/19 12:28 PM, Aleksey Shipilev wrote:
However, you also said in your opening criticism
"I had hard time convincing myself that code is concurrency-safe"
I think that is a more telling complaint. Can you elaborate on why you
found it hard to convince yourself of this? (I know what I
:
by adding a bit to String that is true iff String.hash has been calculated as
being 0, we can get
rid of the corner case where such hash
codes are recalculated on every call.
Peter Levart came up with a elegant scheme for ensuring that we can keep
using non-volatile stores without explicit fe
On 4/5/19 10:48 AM, Andrew Dinn wrote:
Hi Peter,
Regarding the static initializer ... there is an explanatory implNote
explaining the rationale for the static block in the class javadoc at
the top of the file. I agree this could be improved by explaining that
the block is executed and then it
Hi Andrew,
For a casual reader (like me) the comments in the UnsafeConstants for
each field:
69 * @implNote
70 * The actual value for this field is injected by the JVM.
...make one wonder what is actually going on regarding the static
initializer at the end of the class. Is it
Map1.get() should be much faster with this patch too, right?
Peter
On 4/4/19 11:11 PM, Stuart Marks wrote:
Hi all,
An unmodifiable map with one entry doesn't throw NPE from get(null).
Instead, it returns null. This makes it quite an outlier:
Map.of().get(null) ==> NPE
Map.of().containsKey(n
Hi Claes,
I also think that the variant shown below should be compatible with
existing VM code that "injects" hash value. No changes necessary, right?
Peter
On 4/2/19 12:53 PM, Peter Levart wrote:
Hi Claes,
On 4/2/19 10:29 AM, Claes Redestad wrote:
Hi Peter,
On 2019-04-01 23
Hi Claes,
On 4/2/19 10:29 AM, Claes Redestad wrote:
Hi Peter,
On 2019-04-01 23:54, Peter Levart wrote:
In addition, this might not be easy from another point of view. You
all know that there's no synchronization performed when caching the
hash value. This works, because 32 bits are a
On 4/1/19 10:44 PM, Claes Redestad wrote:
We actually looked at this idea earlier today, and squeezing a "not-
computed" value into String might be "free" since there seems to be a
padding gap on all VM varieties (at least according to JOL estimates[1])
That'd be a larger endeavor, though, sin
On 3/29/19 4:36 PM, Peter Levart wrote:
On 3/29/19 8:49 AM, Lindenmaier, Goetz wrote:
So I want to withdraw my claim that NPEs are thrown frequently.
Probably I was biased by my compiler construction background,
remembering NPE checks are all over the place in the code.
But I think I can
On 3/29/19 8:49 AM, Lindenmaier, Goetz wrote:
So I want to withdraw my claim that NPEs are thrown frequently.
Probably I was biased by my compiler construction background,
remembering NPE checks are all over the place in the code.
But I think I can still keep the claim that the message is
pri
On 3/28/19 4:46 PM, Peter Levart wrote:
Reflection.verifyMemberAccess() is called not only from
AccessibleObject.slowVerifyAccess() but from elsewhere too.
For example, from ReflectUtil.ensureMemberAccess which is used in @CS
AtomicXxxFieldUpdater(s), or from @CS
On 3/28/19 4:08 PM, Alan Bateman wrote:
On 28/03/2019 14:48, Peter Levart wrote:
:
In addition, if access from null caller is granted and it is
performed to a member in a "concealed" package, there's no warning
displayed
The proposed check is that the package is exported
On 3/28/19 3:48 PM, Peter Levart wrote:
In addition, if access from null caller is granted and it is performed
to a member in a "concealed" package, there's no warning displayed
(the further logic in the AccessibleObject is skipped).
What would it look like if Accessible
Hi,
On 3/28/19 9:40 AM, Alan Bateman wrote:
On 27/03/2019 23:17, Mandy Chung wrote:
:
The proposed fix is to perform proper access check. When there is no
caller frame, it only allows to access to public members of a public
type
in an unconditional exported API package.
The approach seems
Hi,
On 3/26/19 7:44 PM, Daniel Fuchs wrote:
Hi Peter,
On 26/03/2019 18:01, Peter Levart wrote:
Would such method addition be worth it?
Here is the impl of Set.copyOf:
static Set copyOf(Collection coll) {
if (coll instanceof ImmutableCollections.AbstractImmutableSet
Hi,
This change is OK, but I was thinking that in general, for cases like
this one, it would be better to check that the Set obtained from the
'graph' Map is already immutable and throw an exception if that is not
the case. Like Objects.requireNonNull method, there could be a similar
static m
Hi,
I think that Seth's case is a general problem with serialization of
circular graph(s) with classes containing readResolve() method(s). The
issue is being described here in full:
https://bugs.openjdk.java.net/browse/JDK-6785441
In short: readResolve() method is specified to be invoked aft
eckObjFieldValueTypes(ObjectStreamClass.java:1407)
at
java.base/java.io.ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2371)
at
java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2278)
...
which suggests that my claims are correct...
Peter
On 3/26/
Hi Seth,
I think you stumbled on a "defect" of Java Serialization mechanism.
Namely, the inability for it to correctly deserialize object graphs
containing a cycle when an object in such cycle uses the "readResolve()"
special method to replace the deserialized object with a replacement
object
On 3/21/19 2:17 PM, fo...@univ-mlv.fr wrote:
for some reason i was convinced that IntStream.iterator() was returning a
PrimitiveIterator.OfInt and not an Iterator,
so yes, it will work but i don't understand why it's not BaseStream instead of
Stream that inherits from Iterable.
I think it'
Hi Sergei,
I don't know if you are aware that the new invokedynamic based
translation of string concatenation expressions introduced in JDK 9
(http://openjdk.java.net/jeps/280) only applies to code outside
java.base module. java.base module is still compiled with old-style
StringBuilder based
On 3/15/19 10:07 AM, Ivan Gerasimov wrote:
On 3/15/19 1:51 AM, Peter Levart wrote:
On 3/15/19 9:38 AM, Ivan Gerasimov wrote:
Hi Peter!
On 3/15/19 1:24 AM, Peter Levart wrote:
On 3/15/19 9:03 AM, fo...@univ-mlv.fr wrote:
* @since 13
*/
interface Once {}
What do
what
you'd typically get if you signed a JAR file today.
/Claes
On 2019-03-15 17:07, Peter Levart wrote:
Hi Claes,
If you have observed memory churn allocating Name objects when
reading jar files, then perhaps we could do something to the logic of
Attributes class so that lazily alloca
Hi Claes,
If you have observed memory churn allocating Name objects when reading
jar files, then perhaps we could do something to the logic of Attributes
class so that lazily allocated Name(s) would get interned too?
As a separate change of course. This looks good as is.
Regards, Peter
On 3
On 3/15/19 9:38 AM, Ivan Gerasimov wrote:
Hi Peter!
On 3/15/19 1:24 AM, Peter Levart wrote:
On 3/15/19 9:03 AM, fo...@univ-mlv.fr wrote:
* @since 13
*/
interface Once {}
What do you think of that?
It's not clear to me if an annotation, available at runtime, is n
On 3/15/19 9:24 AM, Peter Levart wrote:
On 3/15/19 9:03 AM, fo...@univ-mlv.fr wrote:
* @since 13
*/
interface Once {}
What do you think of that?
It's not clear to me if an annotation, available at runtime, is not a better
fit.
Anyway, i'm not sure not sure i
On 3/15/19 9:03 AM, fo...@univ-mlv.fr wrote:
* @since 13
*/
interface Once {}
What do you think of that?
It's not clear to me if an annotation, available at runtime, is not a better
fit.
Anyway, i'm not sure not sure introducing such interface/annotation worth its
mainten
Hi,
On 3/14/19 9:51 PM, Remi Forax wrote:
yes, i think i prefer this solution, one Iterable to rule them all.
First, it's not in the spirit of the Collection API to multiply the interfaces,
by example, we have only one kind of Iterator and not an Iterator and a
ReadOnlyIterator even if a lot
On 3/15/19 12:16 AM, Stephen Colebourne wrote:
On Thu, 14 Mar 2019 at 19:45, Brian Goetz wrote:
Why not make `Iterator` implement `IterableOnce`? The default method
would obviously just return `this`.
Such a default would not conform to the contract, as IO requires that
subsequent calls th
Now that Brian put it so nicely, I'm convinced and I'd like to draw back
and support this proposal as is...
On 3/14/19 3:50 PM, Stephen Colebourne wrote:
On Thu, 14 Mar 2019 at 14:21, Brian Goetz wrote:
There's a reason it took as long as it did for Stuart to come up with
this proposal; all t
Hi Stuart,
The Alternatives section of the proposal is very thorough and it
mentions the following alternative:
"
An alternative adapter is to add a default method to Stream:
default Iterable asIterable() { return this::iterator; }
for (T t : asIterable(stream)) {
...
ent of "have you thought about extensively>".)
On 3/6/2019 10:50 AM, Peter Levart wrote:
In this respect Iterable should be a subtype of IterableOnce and
foreach loop should be retrofitted to work with IterableOnce.
Hi John,
On 3/12/19 12:07 AM, John Rose wrote:
public static void main(String[] args) {
for(int i : range(0, 100)) {
System.out.println(i);
}
}
It correctly compiles and prints numbers from 0 to 99. As IntStream
extends BaseStream and BaseStream> defines Iterator iterator(), it would be
Hi,
On 3/11/19 5:29 PM, Joe Darcy wrote:
Hello,
Always surprising how much discussion an (apparently) simple
refactoring can generate!
Thanks to Tagir for spotting this issue.
For completeness, the two-argument forms of requireNonNull which takes
a Supplier is not applicable to preserve th
Hello,
I stumbled on the specification of a static utility method
CharSequence#compare introduced in Java 11 which says:
* Compares two {@code CharSequence} instances lexicographically.
Returns a
* negative value, zero, or a positive value if the first sequence
is lexicographically
On 3/10/19 9:19 PM, Martin Buchholz wrote:
We should stop discussing this here, but ...
... I think that we really should, but ...
On Sun, Mar 10, 2019 at 1:51 AM Peter Levart <mailto:peter.lev...@gmail.com>> wrote:
In this particular case, this is not true. A lambda that
301 - 400 of 2235 matches
Mail list logo
