Hello,
I am adding code to OpenJDK 14 which uses a library that is currently not
part of the JDK build.
I put the .a library file in the directory where all other dependencies are
(/opt/sysroot/usr/lib/arm-linux-gnueabihf, since I am doing a
cross-compile), and I naively tried to add a reference
On 2020-05-18 08:09, Choe, Jiwon wrote:
Hello,
I am adding code to OpenJDK 14 which uses a library that is currently not
part of the JDK build.
I put the .a library file in the directory where all other dependencies are
(/opt/sysroot/usr/lib/arm-linux-gnueabihf, since I am doing a
The linking of the JDK image using the jlink tool takes a considerable
amount of time. However, the jlink tool is classified as a "small java"
tool in the build script. This should only be used on quick small tools
where a long startup time has a measurable performance impact. Clearly
this
Hi,
Please find the updated review here:
http://cr.openjdk.java.net/~phh/8244966/webrev.02/
I have added the .vscode directory to the .gitignore as well, keeping both the
.hgignore and .gitignore in sync.
Testing was re-conducted and I verified that the .vscode directory is still
ignored.
Looks good.
/Erik
On 2020-05-18 13:55, Lemmond, Dan wrote:
Hi,
Please find the updated review here:
http://cr.openjdk.java.net/~phh/8244966/webrev.02/
I have added the .vscode directory to the .gitignore as well, keeping both the
.hgignore and .gitignore in sync.
Testing was re-conducted
On 2020-05-18 07:58, Magnus Ihse Bursie wrote:
On 2020-05-18 15:16, Erik Joelsson wrote:
Should we then add the big flags instead to have some control over
memory footprint, or are we trusting the default ergonomics to do the
right thing on every possible build system out there?
You make it
Thanks again Jan for looking into and fixing this.
I looked over the new entries last week, and the new MR3 ALPN/PSS items
looked good.
My only comment is that as a newbie to this area, the "header" attribute
includes the "innerclass" parameters: innerclass isn't an attribute on
its own
I apologize, I used a wrong patch for the "data" webrev. The "class name
java/util/jar/Attributes$Name" entry in java.base-7.sym.txt is first
adding field descriptions, and then removing the old ones:
---
class name java/util/jar/Attributes$Name
field name EXTENSION_INSTALLATION descriptor
Looks good.
/Erik
On 2020-05-15 15:57, Yumin Qi wrote:
Hi, Erik
Thanks for test/review.
On 5/15/20 1:48 PM, Erik Joelsson wrote:
I tried a variant of this patch with a 32 bit intel build (server
only to get the cds archive generation enabled). It makes the build
work as expected.
The
Magnus,
Thanks! I will push.
Yumin
On 5/16/20 12:35 AM, Magnus Ihse Bursie wrote:
On 2020-05-16 00:57, Yumin Qi wrote:
Hi, Erik
Thanks for test/review.
On 5/15/20 1:48 PM, Erik Joelsson wrote:
I tried a variant of this patch with a 32 bit intel build (server
only to get the cds
Hi all,
Sorry for the long time to follow up on this patch.
From the reviewers' feedback, I have now restored all files to
make/langtools, except for those in the netbeans and intellij
directories. This also meant that in the make/ide/idea/langtools
directory there were now only an
Should we then add the big flags instead to have some control over
memory footprint, or are we trusting the default ergonomics to do the
right thing on every possible build system out there?
/Erik
On 2020-05-18 03:12, Magnus Ihse Bursie wrote:
The linking of the JDK image using the jlink tool
On 2020-05-18 15:16, Erik Joelsson wrote:
Should we then add the big flags instead to have some control over
memory footprint, or are we trusting the default ergonomics to do the
right thing on every possible build system out there?
You make it sound like we shouldn't. :-) But seriously, I
Hi,
Some new APIs have been introduced in JSR 337 MR3 (JDK 8). We should
update the historical data for JDK 8 with these new APIs.
As this was the first time we need to update data for a release that
other release data use as a baseline, it was necessary to improve the
CreateSymbols tool a
On 07/05/2020 13:22, Severin Gehwolf wrote:
> Hi,
>
> Could I please get a review of this OpenJDK 8u backport for JDK-
> 8243059? The build system is wildly different to JDK 11 and later, thus
> is the patch. In turns out on JDK 8, SetupLauncher isn't using eval()
> so the evaluation of the
15 matches
Mail list logo
