Hi Thorsten, since you have problems filing bugs on JBS, I filed the
following bug on your behalf.
https://bugs.openjdk.java.net/browse/JDK-8234363
I have not investigated the issue in detail yet. How often do you see
ERROR_NO_MORE_FILES happening? Have you checked if your process
(apache?) h
* Florian Weimer:
> __kernel_standard in src/java.base/share/native/libfdlibm/k_standard.c
> is built for _IEEE_LIBM targets as well, but it appears superfluous
> there.
>
> In noticed this because GCC 10 flags an uninitialized variable in this
> code:
>
> …/src/java.base/share/native/libfdlibm/k_
You'd have to look at the spec. For most names a pattern plus the country
name is used. That can be overridden with a non-composed name where needed.
{phone}
On Sun, Nov 17, 2019, 21:50 Martin Buchholz wrote:
> I've always wondered how the timezone-related translations are managed.
> CLDR seems
Thanks for investigating the issue. It is indeed fixed in the latest version
(jpackage 70). Thanks!
--
Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Core-Libraries-f45829.html
Could you file a ticket at
https://unicode-org.atlassian.net/ ?
{phone}
On Mon, Nov 18, 2019, 16:02 wrote:
> Thanks, Mark.
>
> Apparently there seems to be a bug in CLDR converter code, which cannot
> generate the localized names for "Turkey" metazone. Thus the localized
> names from the legacy
Hi Roger, Julia,
> On Nov 18, 2019, at 10:10 AM, Roger Riggs wrote:
>
> If we're putting "public" on the same line as the method then
> it seems useful to put the /* non-public */ on the same line too.
> Though I don't know we have style guidance for that.
> (And elsewhere too).
>
-
Hi Christoph,
Sorry for the late reply but I was out of the office Friday
> On Nov 15, 2019, at 3:40 AM, Langer, Christoph
> wrote:
>
> Hi Lance,
>
> thanks for reviewing. I've addressed your points:
>
>> I would suggesting moving the code added to the constructor for checking
>> the releaseV
I should have been clearer, but the bug seems to be in the JDK tool
which converts CLDR's xml into JDK's resource bundles. I implemented the
CLDR's time zone names fallback spec with
https://bugs.openjdk.java.net/browse/JDK-8181157, but again there seems
to be a bug in the code.
Filed a JDK b
Hi Letu,
Here are my comments to your changes:
- You will need a regression test for this fix. Take a look at
test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate
test cases.
- Fix comment should follow the OpenJDK changeset guideline [1]
- As to the change itself, I would p
On 11/13/2019 7:23 PM, Andy Herrick wrote:
Please review changes for [1] which is the implementation bug for
JEP-343.
The webrev at [2] is the total cumulative webrev of changes for the
jpackage tool, currently in the JDK-8200758-branch branch of the open
sandbox repository.
The webrev a
Thanks, Mark.
Apparently there seems to be a bug in CLDR converter code, which cannot
generate the localized names for "Turkey" metazone. Thus the localized
names from the legacy COMPAT locale data are being used. I will look
into it.
Apart from this, what Letu found out stands by itself as
Hello Alan,
On 18/11/19 9:17 PM, Alan Bateman wrote:
> On 18/11/2019 15:03, Jaikiran Pai wrote:
>> FWIW - this was reported by one of Quarkus project users here
>> https://github.com/quarkusio/quarkus/issues/5359
>>
> BTW: Do you know if this is a mistake in this project or something in
> a plugin
Hi Hamlin,
TCPConnection.java:212:
Keep the "close connection" logging and add the socket to the same log
message:
If anyone is scraping the log, they won't loose this message.
TCPTransport.tcpLog.log(Log.BRIEF, "close connection, socket: " + socket);
TCPTransport.java
277-278: combine t
On 18/11/2019 15:03, Jaikiran Pai wrote:
FWIW - this was reported by one of Quarkus project users here
https://github.com/quarkusio/quarkus/issues/5359
BTW: Do you know if this is a mistake in this project or something in a
plugin used in its build? There was an outreach effort to tack to down
On 18/11/2019 15:01, Jaikiran Pai wrote:
:
So this Class-Path entry is being ignored starting Java 13.
Yes, bad values are now ignored, bringing an end to an effort on the
run-time over multiple releases to fix the problems this area.
JDK-8224253[1] is the JDK 13 release note to announce this
Hi Julia,
Can you recheck the edit to java/lang/invoke/ClassSpecializer.java: 544
I would think the line should be broken at the "..."
* class TopClass { ... * private static final class Species_LLI extends
TopClass {
MemberName.java:1098
It seems like there should be some indentation of th
Guten Tag Langer, Christoph,
am Montag, 18. November 2019 um 14:22 schrieben Sie:
> I saw your other mail already but didn't find time to reply.
Thanks, I wasn't sure if I'm received at all. Now that I know and
because of your negative answer, I'm going to leave this thread alone
and whoever is i
FWIW - this was reported by one of Quarkus project users here
https://github.com/quarkusio/quarkus/issues/5359
-Jaikiran
On 18/11/19 8:31 PM, Jaikiran Pai wrote:
> Imagine 2 jar files. One called helloworld.jar which contains just a
> single org.myapp.HelloWorld class which prints to System.out f
Imagine 2 jar files. One called helloworld.jar which contains just a
single org.myapp.HelloWorld class which prints to System.out from its
main method. The other jar called manifest-cp-test.jar. This
manifest-cp-test.jar contains (only a) META-INF/MANIFEST.MF with the
following content:
Manifest-V
Editing glitch.Was there but then it was gone. Thanks Brent.
http://cr.openjdk.java.net/~jlaskey/8233116/webrev.04/index.html
> On Nov 15, 2019, at 7:47 PM, Brent Christian
> wrote:
>
> Hi, Jim
>
>
> src/java.base/share/classes/java/lang/String.java
>
> These changes look fine.
>
> --
>
Hi Thorsten,
I saw your other mail already but didn't find time to reply.
I'm actually not convinced that it is a good idea to add ERROR_NO_MORE_FILES to
lastErrorReportable. The error codes listed there are conditions on which
canonicalization of a path is stopped but the result is deemed corr
Guten Tag Langer, Christoph,
am Donnerstag, 14. November 2019 um 16:37 schrieben Sie:
> please review this cleanup change regarding function "canonicalize" of
> libjava.
[...]
> The goal is to cleanup how this function is defined and used.[...]
If you are already changing "lastErrorReportable" f
Hi,
This cleanup work addresses an outdated coding convention in java.base.
It removes the line break from a class declaration, for example:
public
TypeNameOnNextLine
becomes
public TypeNameOnSameLine
Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234335/webrev.00/
Bug: ht
> I plan to review this change. We also need to figure out how to remove
> the dependency on this function from the JPLIS agent as that should not
> be there.
Agree. I'd hope, however, that this can be done with a different change (unless
you have an idea for a very simple, straightforward way th
On 18/11/2019 09:00, Langer, Christoph wrote:
:
Any other reviews (e.g. Gerard?)
I plan to review this change. We also need to figure out how to remove
the dependency on this function from the JPLIS agent as that should not
be there.
-Alan
Hi David,
> This all seems fine to me. One clarification:
Thanks for the review.
>
> - /* The appropriate location of getPrefixed() should be io_util_md.c, but
> -java.lang.instrument package has hardwired canonicalize_md.c into their
> -dll, to avoid complicate solution such as includi
Guten Tag Thorsten Schöning,
am Donnerstag, 14. November 2019 um 20:46 schrieben Sie:
> So, how about adding ERROR_NO_MORE_FILES there as well?
Does nobody care about that request or am I not even received by
others on the list? In the first case, is anyone willing to tell me
where I should ask i
27 matches
Mail list logo
