Hi Roger,
Thanks for looking into it and for your reply.I don't see a compulsory
reason to change the code.
In context of JDK-8217375 I happened to touch the issue and I agree to
Max to solve it differently in that particular case now by creating a
real deep copy based on reading the manifest
Hello Alan, here is a second webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.1/
I moved the Windows-only code into a new file
src/java.base/windows/native/libjli/parse_manifest_md.c
Best regards, Matthias
> -Original Message-
> From: Alan Bateman
> Sent: Mittwoch,
See also official downport documentation:
http://openjdk.java.net/projects/jdk-updates/approval.html
Cheers, Thomas
On Wed, Jan 23, 2019 at 12:46 PM Lindenmaier, Goetz <
goetz.lindenma...@sap.com> wrote:
> Hi Steve,
>
> feel free to request the downport of this change.
>
> For this, you must
On 23/01/2019 15:59, Haug, Gunter wrote:
:
As Volker writes, we still think that the overhead of the up-calls is
acceptable but it would be possible to introduce a switch which is based on a
system property.
There are concerns with the approach and patch. The replies from David
hint that he
Hi Alan, David
Here are the results of the measurements. As mentioned before, I had measured
some of the standard Java benchmarks and there was no impact. This is probably
not surprising to anybody as the overhead up-calls is minuscule in comparison
to the calculations that take place and is
Hi Mandy,
Food for thought:
- From John's email, it looked like he was advocating a clarification
change to the spec (which requires no CSR).
- A test case is attached to the bug. It displays "current behaviour", but
doesn't show a clear "pass" or "fail", because at the start of this there
+1
Naoto
On 1/22/19 3:25 PM, Mandy Chung wrote:
On 1/22/19 2:25 PM, Roger Riggs wrote:
Hi Mandy,
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-2/
Looks good.
Other changes look good.
BTW,
> I have not found a reproducer for jdk 12, it only occurs on
+1 to retaining and correcting the javadoc to match the implementation.
Thanks, Roger
On 01/22/2019 07:47 PM, Lance Andersen wrote:
On Jan 22, 2019, at 12:02 PM, Alan Bateman wrote:
On 19/01/2019 12:46, Lance Andersen wrote:
Hi all,
Please review the fix for JDK-8217393 which updates the
Hi Adam,
On 1/23/19 8:33 AM, Adam Farley8 wrote:
Hi Mandy,
Food for thought:
- From John's email, it looked like he was advocating a clarification
change to the spec (which requires no CSR).
While the new behavior was intended when the spec was written, this fix
changes the current
Hi,
like many other I ran into bug JDK-698217 which is about
AbstractSet.removeAll() and it's "aptitude" in wasting CPU time if you
accidentally hit this bug. And there are hundred of developers hitting
this bug every year.
I simply don't understand why there was no progress in 8 years, on
Hi,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8217366
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8217366/webrev.00/
The gist of the issue is that CLDR's "no inheritance marker" slipped
into the final zone strings
Hi Naoto,
Looks fine to me.
Roger
On 01/23/2019 12:47 PM, Naoto Sato wrote:
Hi,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8217366
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8217366/webrev.00/
The gist of the issue
Hi Ichiroh,
Sorry for the delay,
yes, the change looks fine.
I'll sponsor, and push it tomorrow.
Thanks, Roger
On 01/23/2019 07:21 AM, Ichiroh Takiguchi wrote:
Hello.
Could you review the fix and give your suggestion ?
Thanks,
Ichiroh Takiguchi
On 2019-01-16 21:32, Ichiroh Takiguchi
Hi Jan,
I'm amazed to see this performance problem has persisted for so long. As a
Java developer, I wasn't even aware of it, so thanks for the information.
>
> The relevant part of the current implementation is as follows:
>
> if (size() > c.size()) {
> for (Object e : c)
On 1/22/19 8:50 PM, Bernd Eckenfels wrote:
I don’t think the launcher is doing this, it is the class loader, that’s
nothing new. You can turn on verbose security debug to see it in all versions.
Yes, and it only verifies the signature(s) on the JAR. It doesn't
validate the certificate chain.
Hi Volker,
Do you think it would be possible to get the change you committed to JDK12
http://cr.openjdk.java.net/~simonis/webrevs/2018/8214063/
for this issue https://bugs.openjdk.java.net/browse/JDK-8214063
back-ported to JDK11, as JDK11 is a LTS release and it woud be good to
have this fix?
Hi Steve,
feel free to request the downport of this change.
For this, you must first check whether the change applies cleanly:
cd jdk/jdk; hg export -r 7384e00d5860 > 8215962.changeset (you find the hash
in the JBS)
cd jdk11u; hg import 8215962.changeset
If so, you flag the bug in JBS as
Hello.
Could you review the fix and give your suggestion ?
Thanks,
Ichiroh Takiguchi
On 2019-01-16 21:32, Ichiroh Takiguchi wrote:
Hello Alan and Roger.
I appreciate your suggestions.
Could you review the fix again ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8214533
Change:
Hi,
The Multi-Release JarFile support JEP[1] notes that the jar file is
expected to contain a main attribute:
Multi-Release: true
The JarFile javadoc[1] on the other hand makes no mention of the value
for such an attribute and just mentions that the Multi-Release main
attribute needs to be
On 23/01/2019 14:27, Jaikiran Pai wrote:
Hi,
The Multi-Release JarFile support JEP[1] notes that the jar file is
expected to contain a main attribute:
Multi-Release: true
The JarFile javadoc[1] on the other hand makes no mention of the value
for such an attribute and just mentions that the
Thank you Alan.
-Jaikiran
On 23/01/19 8:09 PM, Alan Bateman wrote:
> On 23/01/2019 14:27, Jaikiran Pai wrote:
>> Hi,
>>
>> The Multi-Release JarFile support JEP[1] notes that the jar file is
>> expected to contain a main attribute:
>>
>> Multi-Release: true
>>
>> The JarFile javadoc[1] on the
21 matches
Mail list logo
