On Sun, 17 Apr 2022 16:17:30 GMT, liach wrote:
> Convert dynamic proxies to hidden classes. Modifies the serialization of
> proxies (requires change in "Java Object Serialization Specification"). Makes
> the proxies hidden in stack traces. Removes duplicate logic in proxy building.
>
> The mai
On Wed, 16 Mar 2022 13:09:30 GMT, liach wrote:
> Change `CallSite` to a sealed class, as `CallSite` is an abstract class which
> does not allow direct subclassing by users per its documentation. Since I
> don't have a JBS account, I posted the content for the CSR in a GitHub Gist
> at https://
On Tue, 25 Jan 2022 21:35:27 GMT, Mandy Chung wrote:
>> The MethodHandle of a default method should be made as a fixed arity method
>> handle because it is invoked via Proxy's invocation handle with a non-vararg
>> array of arguments. On the other hand, the
>> `InvocationHandle::invokeDefault
On Mon, 24 Jan 2022 23:03:49 GMT, Mandy Chung wrote:
>> The MethodHandle of a default method should be made as a fixed arity method
>> handle because it is invoked via Proxy's invocation handle with a non-vararg
>> array of arguments. On the other hand, the
>> `InvocationHandle::invokeDefault
On Fri, 21 Jan 2022 22:49:38 GMT, Mandy Chung wrote:
> The MethodHandle of a default method should be made as a fixed arity method
> handle because it is invoked via Proxy's invocation handle with a non-vararg
> array of arguments. On the other hand, the `InvocationHandle::invokeDefault`
> me
Hi and welcome.
I would not consider JDK-8253396 (Please add `not()` method to
`java.util.function.BiPredicate`) a good starter bug.
Generally, any bug that tries to add new APIs are hard, and require a
lot of time and effort.
While the implementation of java.util.function.BiPredicate.not()
On Fri, 12 Mar 2021 13:27:39 GMT, Claes Redestad wrote:
> Remove unused methods.
LGTM
-
Marked as reviewed by jkuhn (Author).
PR: https://git.openjdk.java.net/jdk/pull/2969
html#jvms-4.9.1
On 2/23/21 6:38 AM, Johannes Kuhn wrote:
I want to learn about writing a CSR, and need a sponsor teaching me
the ropes.
Bug: https://bugs.openjdk.java.net/browse/JDK-8262003
Currently, Class.arrayType() will throw an IllegalArgumentException if
the maximum number of dim
I want to learn about writing a CSR, and need a sponsor teaching me the
ropes.
Bug: https://bugs.openjdk.java.net/browse/JDK-8262003
Currently, Class.arrayType() will throw an IllegalArgumentException if
the maximum number of dimensions will be exceeded.
Throwing an IllegalArgumentExce
I now implemented a prototype for JDK-6824466: [1]
The goal I set here was to remove the old AccessorGenerator.
The good news:
- It works - all tier1 tests pass, except one that requires the old
implementation.
- A lot of code has been removed. And even more could be removed.
The bad news:
On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad wrote:
> This patch refactor JDK internal charsets to initialize charset mapping data
> lazily when needed via holder classes. This means both a startup improvement
> in some cases, and possible throughput improvements for all DoubleByte-based
>
On Wed, 3 Feb 2021 18:40:15 GMT, Mandy Chung wrote:
>> JDK-8013527: calling MethodHandles.lookup on itself leads to errors
>> JDK-8257874: MethodHandle injected invoker doesn't have necessary private
>> access
>>
>> Johannes Kuhn is also a contributor to th
On Wed, 3 Feb 2021 18:34:55 GMT, Mandy Chung wrote:
>> You are right, got it confused with the future use.
>>
>> With this fix, MethodHandle -> Method.invoke -> MethodHandles.lookup() will
>> still return a lookup on the injected invoker.
>> I somehow missed that this is not part of the fix,
On Wed, 3 Feb 2021 17:25:04 GMT, Mandy Chung wrote:
>> Only `Lookup` with the original access can access `MethodHandles.classData`.
>> A hidden class `HC$$InjectedInvoker/0x1234` can access private members of
>> another class `C` in the same nest but not `C`'s class data.
>>
>> I don't follo
On Wed, 3 Feb 2021 01:50:36 GMT, Mandy Chung wrote:
> JDK-8013527: calling MethodHandles.lookup on itself leads to errors
> JDK-8257874: MethodHandle injected invoker doesn't have necessary private
> access
>
> Johannes Kuhn is also a contributor to this patch.
>
>
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-January/073184.html
On 02-Feb-21 11:07, Alan Bateman wrote:
On 01/02/2021 15:19, Johannes Kuhn wrote:
:
Thanks Rémi.
The problem here is that (according to Peter Levart tests), the cold
use of a MHMethodAccessor is 11x as expensiv
on method
handles. This would greatly simplify the work to add support for a new
feature for example Valhalla primitive classes only in method handles.
I plan to keep the native method accessor for startup use (or switch
to method handles when module system is initialized).
Ma
On 01-Feb-21 15:58, Remi Forax wrote:
- Mail original -
De: "Johannes Kuhn"
À: "core-libs-dev"
Envoyé: Lundi 1 Février 2021 15:50:51
Objet: JDK-6824466 java.lang.reflect.Method should use
java.lang.invoke.MethodHandle
While implementing a prototype for
While implementing a prototype for JDK-8242888 (Convert dynamic proxy to
hidden classes) I came across the problem that hidden classes can't be
mentioned in the constant pool, breaking the constructor for serialization.
To remedy that problem, I used a MHConstructorAccessor which delegates
the
On Fri, 8 Jan 2021 09:38:40 GMT, Johannes Kuhn
wrote:
> Simple fix - one line change:
> https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0.
>
> Most of the changes come from an additional test that fails without this fix:
>
> Error:
59395.
> You can view the output of the test without patch here:
> https://github.com/DasBrain/jdk/runs/1668078245
>
> Thanks to @AlanBateman for pointing out the right fix.
Johannes Kuhn has updated the pull request incrementally with one additional
commit since the last revision:
Re
On Wed, 20 Jan 2021 18:29:00 GMT, Johannes Kuhn
wrote:
> Add explicit range check to `MethodHandles.collectArgumentsCheck`.
> Added test case that exercises all cases.
>
> This is a behavioral change, from throwing an unspecified exception to
> throwing an IllegalArgume
On Fri, 22 Jan 2021 00:48:51 GMT, Johannes Kuhn
wrote:
>> Looks good. What tests have you ran?
>
> On the latest commit, only my own test.
> On the previous commit (4f74e2d) I did run the full tier1.
>
> Currently a full test tier1 run on my machine and github acti
On Fri, 22 Jan 2021 00:44:12 GMT, Mandy Chung wrote:
>> Johannes Kuhn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Implement suggestions by Mandy Chung.
>
> Looks good. What tests have you ran?
On
nge needed, as the IllegalArgumentException is already specified
> to be thrown in those cases.
>
> Feel free to suggest a better place for the tests.
Johannes Kuhn has updated the pull request incrementally with one additional
commit since the last revision:
Implement suggestions by Mandy Chung.
On Thu, 21 Jan 2021 22:54:56 GMT, Mandy Chung wrote:
>> Add explicit range check to `MethodHandles.collectArgumentsCheck`.
>> Added test case that exercises all cases.
>>
>> This is a behavioral change, from throwing an unspecified exception to
>> throwing an IllegalArgumentException, as spec
Add explicit range check to `MethodHandles.collectArgumentsCheck`.
Added test case that exercises all cases.
This is a behavioral change, from throwing an unspecified exception to throwing
an IllegalArgumentException, as specified.
No spec change needed, as the IllegalArgumentException is alr
59395.
> You can view the output of the test without patch here:
> https://github.com/DasBrain/jdk/runs/1668078245
>
> Thanks to @AlanBateman for pointing out the right fix.
Johannes Kuhn has updated the pull request incrementally with one additional
commit since the last revision:
59395.
> You can view the output of the test without patch here:
> https://github.com/DasBrain/jdk/runs/1668078245
>
> Thanks to @AlanBateman for pointing out the right fix.
Johannes Kuhn has updated the pull request incrementally with one additional
commit since the last revision:
On Tue, 19 Jan 2021 16:14:51 GMT, Alan Bateman wrote:
>>>
>>>
>>> This issue requires a Reviewer from someone working in this area. Please do
>>> not sponsor or integrate until that review has been done.
>>
>> Ok, increased the number of required reviewers to 2.
>> Hope that was the right m
uried in
https://github.com/openjdk/jdk/compare/master...mlchung:method-invoke. I
will extract that fix and post a PR on my proposed fix.
Mandy
On 1/16/21 10:07 AM, Johannes Kuhn wrote:
After digging though the JBS, I found this comment from John Rose[1].
I like the general idea, but I don't thin
JDK-8013527[1] has somehow become the umbrella bug for "Using
MethodHandles to call caller sensitive methods leads to interesting
results".
To recap: A caller sensitive method knows about who called it, and can
behave differently when called from an other context.
Examples are: Class.forName,
nt-tabpanel#comment-13611844
On 09-Dec-20 21:09, Johannes Kuhn wrote:
On 09-Dec-20 19:44, Mandy Chung wrote:
On 12/8/20 6:02 PM, Johannes Kuhn wrote:
There are a lot of things to consider when trying to fix JDK-8013527.
Exactly in particular security implication! What is clear is that t
On Mon, 11 Jan 2021 14:13:47 GMT, Alan Bateman wrote:
>
>
> This issue requires a Reviewer from someone working in this area. Please do
> not sponsor or integrate until that review has been done.
Ok, increased the number of required reviewers to 2.
Hope that was the right move, as I don't s
On Mon, 11 Jan 2021 14:06:12 GMT, Attila Szegedi wrote:
>> Johannes Kuhn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add a missing pesky newline.
>
> Marked as reviewed by attila (Reviewer).
Than
59395.
> You can view the output of the test without patch here:
> https://github.com/DasBrain/jdk/runs/1668078245
>
> Thanks to @AlanBateman for pointing out the right fix.
Johannes Kuhn has updated the pull request incrementally with one additional
commit since the last revision:
59395.
> You can view the output of the test without patch here:
> https://github.com/DasBrain/jdk/runs/1668078245
>
> Thanks to @AlanBateman for pointing out the right fix.
Johannes Kuhn has updated the pull request incrementally with one additional
commit since the last revision
On Sun, 10 Jan 2021 15:14:31 GMT, Alan Bateman wrote:
>> Simple fix - one line change:
>> https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0.
>>
>> Most of the changes come from an additional test that fails without this fix:
>>
>> Error: Unable to load main class somelib.tes
Simple fix, complex test case.
Thanks to @AlanBateman for pointing out the right fix.
-
Commit messages:
- * Minor cleanup.
- * Fix Whitespace V2
- * Fix whitespace
- * Fix JDK-8259395 - test now passes
- Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8259395
This brings up some stuff I wanted to mention for some time:
* Console.cs is one of the fields projects like JRuby hack into (at
least in the past). My guess is that they handle encodings in Ruby, and
not using the Java facilities for that.
The fact that it is also exported as shared secret f
On Sat, 2 Jan 2021 14:45:51 GMT, Attila Szegedi wrote:
> _(NB: For this leak to occur, an application needs to be either creating and
> discarding linkers frequently, or creating and discarding class loaders
> frequently while creating Dynalink type converters for classes in them.
> Neither is
On Sat, 2 Jan 2021 14:45:51 GMT, Attila Szegedi wrote:
> _(NB: For this leak to occur, an application needs to be either creating and
> discarding linkers frequently, or creating and discarding class loaders
> frequently while creating Dynalink type converters for classes in them.
> Neither is
shared secrets don't have
fields. The better news: reference assignment also can't be teared.
- Johannes
[1]: https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
On 29-Dec-20 18:53, Hans Boehm wrote:
On Tue, Dec 29, 2020 at 5:56 AM Johannes Kuhn <mailto:i..
Depends on what `initialize()` is.
If it (at least) reads a volatile field, then the compiler can't reorder
the second read before the first.
- Johannes
On 29-Dec-20 14:42, some-java-user-99206970363698485...@vodafonemail.de
wrote:
Hello,
the class `jdk.internal.access.SharedSecrets` provid
tps://github.com/openjdk/jdk/pull/960
On 12/17/20 2:07 PM, Johannes Kuhn wrote:
Now that class data support for hidden classes in master, I decided to
tackle JDK-8229959 again.
JDK-8229959: Convert proxy class to use constant dynamic [1]
JDK-8242888: Convert dynamic proxy to hidden classes [2
Now that class data support for hidden classes in master, I decided to
tackle JDK-8229959 again.
JDK-8229959: Convert proxy class to use constant dynamic [1]
JDK-8242888: Convert dynamic proxy to hidden classes [2]
The idea is simple: Define proxies as hidden classes, pass the methods
as class
On 09-Dec-20 19:44, Mandy Chung wrote:
On 12/8/20 6:02 PM, Johannes Kuhn wrote:
There are a lot of things to consider when trying to fix JDK-8013527.
Exactly in particular security implication! What is clear is that the
expected lookup class should not be the injected class. The key
On 09-Dec-20 1:16, Mandy Chung wrote:
On 12/8/20 5:07 AM, Johannes Kuhn wrote:
Not sure if I read this correctly as "please share some example of
code that tries to do that" or "please share code that you write to
fix that".
So I do both.
I was curious to find o
On 08-Dec-20 5:40, Mandy Chung wrote:
Thanks David. I was about to create one.
This is indeed a gap in injecting this trampoline class for supporting
@CallerSensitive methods. The InjectedInvoker ensures that the
InjectedInvoker class has the same class loader as the lookup class.
W.r.t. y
Let's start with the reproducer:
public class NestmateBug {
private static int field = 0;
public static void main(String[] args) throws Throwable {
Lookup l = MethodHandles.lookup();
Field f = NestmateBug.class.getDeclaredField("field");
Met
From my understanding, Unsafe.throwException throws the passed
Throwable, more commonly known as "snaky throws".
There are other ways to archive the same result, one commonly found is
by (ab)using generics:
public static void sneakyThrows(Throwable t)
throws T {
throw (T) t;
On 14-Jun-20 18:28, Peter Levart wrote:
Hi,
I noticed that deserializing records (new preview Java feature in
JDK14 and JDK15) is slow compared to equivalent classical classes. I
created a JMH benchmark [1] to se how it compares (ran it on JDK14):
Benchmark Mode Cnt Score Err
Relevant StackOverlow question:
https://stackoverflow.com/questions/61504956/records-in-jlinked-application-throws-exception
It talks about JLink, but the error message is the same, so I expect the
same root cause:
The ASM version shipped with JDK 14 doesn't support records yet. It is
already
Hi,
half a year ago, I proposed a patch that implements JDK-8229959: Convert
proxy class to use constant dynamic [2].
**Background**: java.lang.reflect.Proxy creates a class file at runtime
that extends j.l.r.Proxy and implements the passed interfaces.
Methods invoked on that proxy are passed
-20 21:23, Mandy Chung wrote:
It's fixed. Thanks
Mandy
On 5/28/20 4:35 PM, Johannes Kuhn wrote:
Hi,
just noticed a small thing:
The magic is 4 bytes, but readUnsignedShort reads two bytes.
- Johannes
On 28-May-20 19:25, Mandy Chung wrote:
On 5/28/20 6:55 AM, Alan Bateman wrote:
On
Hi,
just noticed a small thing:
The magic is 4 bytes, but readUnsignedShort reads two bytes.
- Johannes
On 28-May-20 19:25, Mandy Chung wrote:
On 5/28/20 6:55 AM, Alan Bateman wrote:
On 28/05/2020 05:13, Mandy Chung wrote:
Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk15/webrevs/82
Found a small mismatch between the specification of
DataInputStream.readFully(byte[] b, int off, int len) and its
implementation.
In particular, it doesn't throw an IndexOutOfBoundsException if offset
is negative and len is 0.
Reproducer below.
I suggest changing the specification of this m
On 11-May-20 10:59, Alan Bateman wrote:
On 10/05/2020 15:47, Johannes Kuhn wrote:
:
After the discussion with Naoto, I would like to change the one line
to strcpy(ret + 2, "1252")
diff --git a/src/java.base/windows/native/libjava/java_props_md.c
b/src/java.base/windows/nati
On 09-May-20 1:27, Brent Christian wrote:
On 5/7/20 5:50 AM, Alan Bateman wrote:
On 07/05/2020 12:37, Johannes Kuhn wrote:
:
In the end, I don't know what causes the bug, or how I can replicate
it.
I think I did find a likely suspect.
>
Good sleuthing. I don't what the condi
hange the additional line to "strcpy(ret+2, "1252");" as Cp is copied
in the following switch.
Naoto
On 5/7/20 5:50 AM, Alan Bateman wrote:
On 07/05/2020 12:37, Johannes Kuhn wrote:
:
In the end, I don't know what causes the bug, or how I can replicate
it.
I th
I just saw a question on StackOverflow [1] which reports to have the
same issue as in JDK-8226810 [2] - with the same stack trace.
While I could not reproduce the issue, I tried to understand which code
path could lead to that outcome.
While doing so I did come across getEncodingInternal in ja
of the close() method should be changed.
The same applies for the other XML Stream/Event Reader/Writer.
Thanks,
Johannes
On 16-Apr-20 9:28, Alan Bateman wrote:
On 16/04/2020 01:28, Johannes Kuhn wrote:
:
I did not restrict my enumeration to public and exported types - it
was easier not to do that
DK-7057061
Thanks,
-Joe
On 4/15/2020 5:28 PM, Johannes Kuhn wrote:
After failing to wrap a XMLStreamReader in a try-with-resources after
discovering it's close() method,
I thought about checking what other classes have a public void
close() method in the JDK but don't implement
After failing to wrap a XMLStreamReader in a try-with-resources after
discovering it's close() method,
I thought about checking what other classes have a public void close()
method in the JDK but don't implement AutoCloseable.
So I wrote a small program that enumerates all classes present in in
ly, something is going to go wrong :) Anyway, I'll notify about
>results when this is done.
>
>Regards,
>Sergey Tsypanov
>
>
>26.11.2019, 21:57, "Johannes Kuhn" :
>> On November 26, 2019 8:29:06 PM GMT+01:00, "Сергей Цыпанов"
> wrote:
>>
Hi,
Just had the chance to look at the proposal, and I have a small suggestion:
MemorySegmenent::mapFromPath should state that it can throw a SecurityException
if a SecurityManager is installed in the javadoc.
The description can be copied from FileChannel::open.
With best regards,
Johannes
On November 26, 2019 8:29:06 PM GMT+01:00, "Сергей Цыпанов"
wrote:
>Hello,
>
>while using java.lang.Integer.TYPE I've found out that currently
>wrapper classes for primitives initialize their own TYPE-fields by
>calling native method java.lang.Class.getPrimitiveClass().
>
>This can be simplifi
On 11/23/2019 10:40 PM, Brian Goetz wrote:
Finally, we can benchmark the current approach against the LDC
approach on a per-Method basis. The LDC approach may well be doing
more work per Method, so it's a tradeoff to determine whether
deferring that work is a win.
By this last bit, I mea
On 11/23/2019 6:09 PM, Brian Goetz wrote:
Thanks for the examples.
A few comments:
- A reasonable place to consider putting the bootstrap is in Proxy
itself. I am not sure that ConstantBootstraps is the right place (or
anywhere in JLI for that matter) unless Method is retrofitted to
imple
On 22.11.2019 22:41, Remi Forax wrote:
i wonder if some codes in the wild rely on that ?
I don't think some code does, but you never know.
There is perhaps a better way, as part of the branch nestmates of valhalla,
Mandy has added a way to transfer a live object to a Class when defining it,
w
esh this out with a code
example, that shows the proposed old and new translation. This would
make it easier for folks to evaluate the benefits and costs of the
approach, and possibly suggest improvements.
>
> On 11/21/2019 10:23 PM, Johannes Kuhn wrote:
>>
>> * What benefits wou
benefits and costs of the
approach, and possibly suggest improvements.
On 11/21/2019 10:23 PM, Johannes Kuhn wrote:
* What benefits would such a change have?
First, it allows us to drop the static final fields and the class
initializer for the generated proxy classes.
Second, it allows the code (both
ave to be made
and where. In that case, I volunteer to write those requests and send
them to my sponsor, who can (at their sole discretion) forward it to the
relevant places.
If you have any additional questions, please don't hesitate to answer to
this mail. I will try to answer all questi
On 13.11.2019 20:07, Mandy Chung wrote:
Thank you for all those changes. It fixed two of my reported bugs
(JDK-8209005, JDK-8209078).
Thanks for filing these good reports. JDK-8173978 resolved the
issues reported by JDK-8209005 and JDK-8209078.
I'm happy I could help.
It also makes my sugge
On 11.11.2019 22:23, Mandy Chung wrote:
This is a follow-up of JDK-8226916. Lookup::hasPrivateAccess intends
to test if this lookup is a full-power lookup; that is created by the
original caller class calling MethodHandles::lookup. The current
specification for Lookup::hasPrivateAccess returns
Hi,
thanks for your quick reply.
On 16/09/2018 11:15, Alan Bateman wrote:
> On 14/09/2018 20:34, Johannes Kuhn wrote:
>> :
>>
>> 1. Use Case:
>>
>> The most obvious use case is to to "implement" default methods in
>> insta
y to express that. Instead
don't allow any lookup on members in a different module if the MODULE
flag is not set.
But this is only a suggestion. It's up to you to decide how to deal with
this.
Please keep up the good work you are doing, and I hope this mail will
help you fixi
77 matches
Mail list logo
