The ClassLoader used to create the pseudo module-info interface is
parent-first, so if there are any modules on the classpath, it will try to load
the module-info.class file from there instead of the synthetic that is being
generated in the method. This interface is generated if you try to read
> If I understand correctly, this class represents an immutable empty map. As
> a result, operations like put or remove have been implemented to throw
> UnsupportedOperationException; this makes sense to me. However, this is
> also the implementation for computeIfPresent, which I believe may be too
Hi Stuart
Thanks for the references to the discussion regarding .stream() on Iterable;
I had been wondering that myself from time to time why they weren't there.
It has always bothered my, that converting an Iterable to a Stream is a bit
cumbersome, having to go through the spliterator and the St
(CharSequence delimiter,
Iterable elements) {
return join(delimiter, elements, Function.identity());
}
Kind regards
Michael Rasmussen
Hi,
When JDK-8068498 was implemented (in JDK9), it simply changed PrintWriter and
BufferedWriter to use System.lineSeparator(), but the spec for the classes and
methods still mentions line.separator system property, thus giving the
impression that changing that system property has an impact.
I
The current implementation seems very counter-intuitive with anything that
doesn't have the same comparison semantics, for instance a TreeSet/Map with a
Comparator, Identity-based Set/Map etc.
The output of the following snippet would probably surprise most:
/* --- snip --- */
import java.util.*
> On 7/01/2019 8:46 pm, Michael Rasmussen wrote:
> > Hi,
> >
> > We recently discovered something similar, although with the native
> > counterparts of getDeclaredMethods: the JVM-TI function GetClassMethods and
> > the JDI method ReferenceType.methods().
>
From: core-libs-dev on behalf of
Michael Rasmussen
Sent: 07 January 2019 12:46:16
To: Roger Riggs; David Holmes; core-libs-dev@openjdk.java.net
Subject: Re: Class.getDeclaredMethods() is returning inherited methods
Hi,
We recently discovered something similar, although with the native counte
anywhere. For abbreviation, here is grepped
output:
javap -v app1.Test$Child | grep method
#4 = Utf8 method2
public abstract java.lang.String method2();
For comparison, tried running on IBM SDK 8, and OpenJDK 11 with OpenJ9. Neither
of those listed method() from the native methods.
K
From: Peter Levart
> From consistency point of view HashMap might be expected to not modify
> its internal state when it's obvious that the external view of its state
> doesn't change. .computeIfAbsent() is violating that expectation.
> WeakHashMap is violating that expectation too, but it has
A quick snippet of code that shows this, by reflecting into the Map to get the
table field, and see that it changes:
/* --- snip --- */
package com.test;
import java.lang.reflect.Field;
import java.util.HashMap;
import java.util.function.Function;
public class Test {
public static void main(S
From: Andrew Dinn
> I have to ask the obvious: Why does the question matter?
I'm trying to figure out if something is a bug in HashMap in the JDK, or in
Weld :D
The case in question is basically, a HashMap is created, and then the keys are
iterated over concurrently.
The issue here though is t
an existing key should not be a structural
modification, the current implementation is bugged.
Kind regards
Michael Rasmussen
gards
Michael Rasmussen.
/* --- snip --- */
package app1;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import java.lang.reflect.AnnotatedType;
import java.lang.reflect.Executable;
i
> I noticed a few others nearby. It's startling that a new occurrence has crept
> it.
At least I haven't seen it on return types, like: public byte toArray() [] {
... }
> An interesting exercise would be to write a detector for this declaration
> style.
Can a language syntax/feature be deprecat
See the comments here https://bugs.openjdk.java.net/browse/JDK-8180410
/Michael
From: core-libs-dev on behalf of
Christian Ullenboom
Sent: 11 September 2018 01:18:42
To: core-libs-dev@openjdk.java.net
Subject: ByteArrayOutputStream should not have a new wri
Hi
StackWalker::getCallerClass can throw "UnsupportedOperationException:
StackWalker::getCallerClass called from @CallerSensitive", depending on how the
underlying fetchNextBatch/fill_in_frames splits the stacktrace.
This seems to be a result of what was introduced in JDK-8157464.
The followin
3 May 2018 00:13
To: Michael Rasmussen
Cc: core-libs-dev
Subject: Re: RFR: Here are some easy patches
Michael, Thanks.
This may be tricky. isArray is a native method, and we don't want to pay for
native method overhead - we're depending on hotspot intrinsification. I
suspect isArray
Hi Martin,
Did you consider using Class::isArray in the loop? Something like the following:
for (Object element : a) {
final int elementHash;
if (element == null) {
elementHash = 0;
}
else {
final Class cl = element.getClass();
if (!cl.isArray())
elementHash = element.h
On 26 September 2017 at 14:18, David Holmes wrote:
> Hi Michael,
>
> On 26/09/2017 9:01 PM, David Holmes wrote:
>
>> Hi Michael,
>>
>> Moving over to core-libs-dev.
>>
>> The discussion in 8185540 is a bit confusing to me.
>>
>
> I've re-read the discussion and related bugs. As I understand it wh
On 15 June 2017 at 21:31, Jeremy Manson wrote:
> My initial thought in this general direction was to write a JVMTI agent
> that takes a list of JAR files as arguments. It then does two things:
>
> - Intercepts all loads of classes using the ClassFileLoadHook, checks to
> see if there is a class w
21 matches
Mail list logo
