Thanks Henry！[2] looks good to me!
BRs,
Lin
> 在 2020年4月4日，下午1:14，Henry Jen 写道：
>
> Internal test shows that inline implementation is not working for some
> Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined,
> so it is actually broken. :)
>
>> [2020-04-03T15:59:26
Internal test shows that inline implementation is not working for some Solaris
artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is
actually broken. :)
> [2020-04-03T15:59:26,981Z] Creating
> support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s)
> [2020
Hi,
Following up on review requests of API [0], Java implementation [1] and
General Hotspot changes[3] for Vector API, here's a request for review
of x86 backend changes required for supporting the API:
JEP: https://openjdk.java.net/jeps/338
JBS: https://bugs.openjdk.java.net/browse/JDK-822
Hi Andy,
http://cr.openjdk.java.net/~herrick/8237490/webrev.07/test/jdk/tools/jpackage/macosx/base/SigningBase.java.frames.html
Maybe better to check for Catalina case as well, instead of disabling
check. We can assume that on Catalina code 3 and not notarized will
consider as pass. In case if
Hi Peter,
I added a JBS comment [1] to describe this special case trying to put
the story together (let me know if it needs more explanation). More
comment inline below.
On 4/3/20 4:40 AM, Peter Levart wrote:
Ok, I think I found one such use-case. In the following example:
package test;
pub
Looks good.
/Erik
On 2020-04-03 08:43, Roger Riggs wrote:
Please review the CSR[1] and changes to remove the RMI static stub
compiler (rmic).
RMIC was deprecated for removal in JDK 13 [3].
The components modified are:
- remove the jdk.rmic module
- remove the jdk.rmic man page
- remove all
Hi Roger,
This looks good and brought back memories of removing the Java EE modules :-)
Best
Lance
> On Apr 3, 2020, at 11:43 AM, Roger Riggs wrote:
>
> Please review the CSR[1] and changes to remove the RMI static stub compiler
> (rmic).
> RMIC was deprecated for removal in JDK 13 [3].
>
>
Please review the CSR[1] and changes to remove the RMI static stub
compiler (rmic).
RMIC was deprecated for removal in JDK 13 [3].
The components modified are:
- remove the jdk.rmic module
- remove the jdk.rmic man page
- remove all tests of rmic or relying on rmic
- update or remove makefil
On 4/3/2020 10:40 AM, James Elliott wrote:
This sounds promising! I just wanted to check if there is a mechanism to
specify a custom set of entitlements needed by the application when running
jpackage, in case it needs more than the normal set that Java itself does. Or
does Java already ask
This sounds promising! I just wanted to check if there is a mechanism to
specify a custom set of entitlements needed by the application when running
jpackage, in case it needs more than the normal set that Java itself does. Or
does Java already ask for every possible entitlement in its original
sorry missing webrev pointer [4]
[4] - http://cr.openjdk.java.net/~herrick/8237490/webrev.07
/Andy
On 4/3/2020 9:24 AM, Andy Herrick wrote:
please review this revised webrev [4] to issue [2]
The previous version generated a signed app that could be notarized,
but then couldn't run because si
Thanks, Claes.
> -Original Message-
> From: Claes Redestad
> Sent: Donnerstag, 2. April 2020 23:05
> To: Langer, Christoph ; jigsaw-
> d...@openjdk.java.net; core-libs-dev@openjdk.java.net
> Subject: Re: RFR: 8242039: Improve jlink VersionPropsPlugin
>
>
>
> On 2020-04-02 20:21, Langer
Hi Mark,
> -Original Message-
> From: mark.reinh...@oracle.com
> Sent: Donnerstag, 2. April 2020 23:13
> To: Langer, Christoph
> Cc: jigsaw-...@openjdk.java.net; core-libs-dev@openjdk.java.net
> Subject: Re: RFR: 8242039: Improve jlink VersionPropsPlugin
>
> 2020/4/2 8:01:28 -0700, chri
please review this revised webrev [4] to issue [2]
The previous version generated a signed app that could be notarized, but
then couldn't run because signing the whole app resigned the executable
with reduced entitlements.
This revision adds back in the entitlements when signing the whole app
Ok, I think I found one such use-case. In the following example:
package test;
public class LambdaTest {
protected void m() {
}
}
package test.sub;
public class LambdaTestSub extends test.LambdaTest {
public void test() {
Runnable r = this::m;
r.run();
}
}
...whe
Hi,
I noticed that the JDK itself still uses Method.getParameterTypes().length in a
couple of places.
This could be replaced with Method.getParameterCount() to avoid unnecessary
cloning overhead.
While this is often optimized away, I guess it's still good to not rely on
that. Additionally, it'
Hi Mandy,
Good work.
I'm trying to find out which language use-case is covered by the
InnerClassLambdaMetafactory needing to inject method handle into the
generated proxy class to be invoked instead of proxy class directly
invoking the method:
useImplMethodHandle =
!implClass.getPa
17 matches
Mail list logo
