Re: RFR 8207750 : Native handle leak in java.io.WinNTFileSystem.list()

[Bernd Eckenfels]

Hello,

I am not sure about the JNi conventions, but does the jObjectArray rv need to 
be released as local reference in some of the early returns as well?

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: -1031249216m Auftrag von
Gesendet: Mittwoch, Juli 18, 2018 4:38 AM
An: Ivan Gerasimov
Cc: core-libs-dev
Betreff: Re: RFR 8207750 : Native handle leak in java.io.WinNTFileSystem.list()

Hi Ivan,

This looks all right to me.

Thanks,

Brian

On Jul 17, 2018, at 5:01 PM, Ivan Gerasimov  wrote:

> In the file WinNTFileSystem_md.c there is a potential leak of native handle 
> obtained from FindFirstFileW() in the unfortunate event of memory allocation 
> failure.
>
> Would you please help review a simple fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8207750
> WEBREV:http://cr.openjdk.java.net/~igerasim/8207750/00/webrev/

Are TimeZone instances guaranteed to be thread-safe

[Bernd Eckenfels]

Hello,

I am not sure I missed it, but it looks like there is no definition in the JCL 
JavaDoc about instances of j.u.TimeZone (specifically SimpleTimeZone as well as 
instances obtained with getDefault or by Id) beeing reentrant/thread Safe or 
not. (There are for examplequite a few non-final fields in SimpleTimeZone as 
well),

Since TimeZone is used together with Calendar it might be natural for 
developers to know.

Is there a helper/factory which would allow access to some standard timezones 
(at least GMT/UTC). This might be especially useful if we cannot define 
TimeZone instances generally as thread safe, because then we can at least 
declare it for this „fast“ implementation.

[ Background of my question is BTW the rs.getTimestamp(idx, Calendar) method in 
the JDBC API where the need for constructing a Calendar object is painful and 
it would help if I could at least use new Calendar(SimpleTimeZone.UTC). (And 
having an alternative like getTimestamp(Int, ZoneId) would be even better ]

I can imagine naming it GMT vs. UTC might also be a nice bike shed.

Gruss
Bernd
--
http://bernd.eckenfels.net

Re: Are TimeZone instances guaranteed to be thread-safe

[Bernd Eckenfels]

Ah BTW, there is a TimeZone.getTimezone(ZoneOffset.UTC) construct which can be 
used. The ZoneId is also immutable, but that construct does say nothing about 
TimeZone instance.

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Bernd Eckenfels 
Gesendet: Samstag, September 1, 2018 3:22 AM
An: core-libs-dev@openjdk.java.net
Betreff: Are TimeZone instances guaranteed to be thread-safe

Hello,

I am not sure I missed it, but it looks like there is no definition in the JCL 
JavaDoc about instances of j.u.TimeZone (specifically SimpleTimeZone as well as 
instances obtained with getDefault or by Id) beeing reentrant/thread Safe or 
not. (There are for examplequite a few non-final fields in SimpleTimeZone as 
well),

Since TimeZone is used together with Calendar it might be natural for 
developers to know.

Is there a helper/factory which would allow access to some standard timezones 
(at least GMT/UTC). This might be especially useful if we cannot define 
TimeZone instances generally as thread safe, because then we can at least 
declare it for this „fast“ implementation.

[ Background of my question is BTW the rs.getTimestamp(idx, Calendar) method in 
the JDBC API where the need for constructing a Calendar object is painful and 
it would help if I could at least use new Calendar(SimpleTimeZone.UTC). (And 
having an alternative like getTimestamp(Int, ZoneId) would be even better ]

I can imagine naming it GMT vs. UTC might also be a nice bike shed.

Gruss
Bernd
--
http://bernd.eckenfels.net

Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

[Bernd Eckenfels]

Yes you are right @apinote is aproperiate section (was confusing it with 
implnote).

Still think a ‚literal specified list‘ is no longer a good (as in canonical) 
usecase for that method.

I used it in the past often to get a List for using toString() on it, but I 
guess even for that case List.of can be used instead now.

So @see List#of and let the reader figure out when to use them?

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Jaikiran Pai 
Gesendet: Donnerstag, September 6, 2018 9:13 AM
An: Bernd Eckenfels; core-libs-dev@openjdk.java.net
Betreff: Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList



Hello Bernd,

Thank you for the review and sorry about the delayed response. Comments inline.

On 29/08/18 4:26 PM, Bernd Eckenfels wrote:
Hello,

Not an Reviewer But just wanted to give a short Feedback: I like the new 
Version it is really helpful.

However I wonder if the usage example should be outside of the apinote.


+ * @apiNote
+ * This method also provides a convenient way to create a fixed-size
  * list initialized to contain several elements:
  * 
  * List stooges = Arrays.asList("Larry", "Moe", "Curly");
  * 
  *

My limited understanding of the @apiNote is that it is supposed to be used for 
additional details of the API and/or its usage examples and the javadoc itself 
(outside of the @apiNote) should be a specification of the API. In this case, I 
moved that section to @apiNote since that part appears to mention how/when to 
use that API in. Having said that, I can move it out of @apiNote and let it 
stay the way it previously was, if you and others feel that's the way to go.


Given the existence of List.of() I wonder if you either mention it as a 
alternative to the example (with slightly different semantic) or just remove 
the sample completely?

I'm not too sure mentioning List.of() construct here will be useful, but I do 
see why you mention that. I think the existing example does seem like a useful 
usage example, irrespective of whether or not we decide to have it in or 
outside of an @apiNote.

-Jaikiran

Re: RFR 8196298 Add null Reader and Writer with latest changes

[Bernd Eckenfels]

Just a nit, Should append(CharSequence,int,int) also use checkFromIndexSize?

Greetings
Bernd
-- 
http://bernd.eckenfels.net

Von: Alan Bateman
Gesendet: Dienstag, 6. März 2018 20:35
An: Patrick Reinhart; core-libs-dev
Betreff: Re: RFR 8196298 Add null Reader and Writer with latest changes

On 05/03/2018 21:45, Patrick Reinhart wrote:
> I tried to incorporate all feedback I received so far and updated the webrev 
> accordingly:
>
> http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.01 
> 
>
I think this looks good now. I've added myself as a reviewer on the CSR 
so you should be able to finalize it.

-Alan

Re: JDK-8197594: String#repeat

[Bernd Eckenfels]

Hello,

I would not encourage makeshift number formatting by mentioning left padding as 
a major usecase:

Just remove that part:

+ * 
+ * This method may be used to create space padding for
+ * formatting text or zero padding for formatting numbers.

I think this error without an Explanation can be hard to debug. It should be 
clear that Memory allocation was not attempted and what the actual Parameters 
where:

+if (Integer.MAX_VALUE / count < len) {
+throw new OutOfMemoryError();
+}

„Repeating „ + len + „ bytes „ + count + „ times would produce a String 
exceeding maximum size.“

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Jim Laskey
Gesendet: Mittwoch, 28. Februar 2018 21:01
An: Core-Libs-Dev
Betreff: RFR: JDK-8197594: String#repeat

Introduction of a new instance method String::repeat to allow an efficient and 
concise approach for generating repeated character sequences as strings.

Performance information in JBS.

Thank you.

Cheers,

— Jim


JBS: https://bugs.openjdk.java.net/browse/JDK-8197594 

CSR: https://bugs.openjdk.java.net/browse/JDK-8198296
 
Webrev: http://cr.openjdk.java.net/~jlaskey/8197594/webrev-02/index.html 

JavaDoc: http://cr.openjdk.java.net/~jlaskey/8197594/String.html 

Re: uploading of new code

[Bernd Eckenfels]

Hello, I would put it on a standalone Git repo on one of the public hosting 
sites lile.Github, especially for a first discussion (especially good if added 
JMH comparisions). I would not expect a id quickly/easily and a in-tree webrev 
could be created by sponsor for final ok.

Bernd

Von: raffaello.giulie...@gmail.com
Gesendet: Mittwoch, 18. April 2018 19:20
An: Aleksey Shipilev; Andrew Haley; core-libs-dev
Betreff: Re: uploading of new code

On 2018-04-18 16:35, Aleksey Shipilev wrote:
> On 04/18/2018 03:58 PM, Andrew Haley wrote:
>> On 04/18/2018 02:55 PM, raffaello.giulie...@gmail.com wrote:
>>> So, how can I best proceed with this initial delivery?
>>
>> Once you have an OpenJDK id you can get an account on cr.openjdk.java.net.
>> That's where you should put your changes.
> 

@Andrew
I can't recall having got an OpenJDK id when I got my Oracle Contributor
Agreement confirmed. But I'll double check.



> ...and until that happens you can ask existing users to host the webrev for 
> you, probably your
> current sponsor. Brian Burkhalter seems to be your sponsor for this work?
> 

@Aleksey
Right, I suppose Brian is my sponsor.



Greetings
Raffaello

Re: RFR: 8198888: Reduce string allocation churn inInvokerBytecodeGenerator

[Bernd Eckenfels]

Another question is it safe to keep an unbounded strong reference to classes 
here? Maybe better Cache getName() results?

-- 
http://bernd.eckenfels.net

Von: Paul Sandoz
Gesendet: Donnerstag, 1. März 2018 19:05
An: Claes Redestad
Cc: core-libs-dev
Betreff: Re: RFR: 819: Reduce string allocation churn 
inInvokerBytecodeGenerator



> On Mar 1, 2018, at 4:14 AM, Claes Redestad  wrote:
> 
> Hi,
> 
> two trivial optimizations that get rid of a few percent on ISC startup tests.
> 
> Webrev: http://cr.openjdk.java.net/~redestad/819/jdk.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-819
> 

Looks good. 

Unsurprising that int is so common given it’s the basic carrier for other 
primitive types.

Paul.

Re: 8198888: Reduce string allocation churninInvokerBytecodeGenerator

[Bernd Eckenfels]

Cool, the lastClass varient then is pretty tempting (and I wont fix the 
multi-slot Version below, it misses a „lastUsedSlot“ field)

Unrelated to this patch I feel that unifying internal names and external names 
will be a hard task, so Class#getInternalName() looks temting for a lot of 
similiar usecases mid term.

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Claes Redestad
Gesendet: Donnerstag, 1. März 2018 20:05
An: core-libs-dev@openjdk.java.net; e...@zusammenkunft.net
Betreff: Re: 819: Reduce string allocation churninInvokerBytecodeGenerator

Hi Bernd,

to dispel your concerns about keeping references to classes then 
InvokerBytecodeGenerators are shortlived and go out of scope after 
they've been used to generate an invoker (or LF) class, so the impl. 
here should be safe from a class leak perspective. A static cache is 
tempting, but would then of course require the use of weak (or soft) 
references and a concurrent collection, which might make it cost more 
than it'd save us.

It does seem the typical answer for the number of entries that get put 
into each generator's cache is exactly one, so a single entry cache 
isn't an unreasonable alternative here.

/Claes

On 2018-03-01 19:39, Bernd Eckenfels wrote:
> +if (nameMap == null) {
> +nameMap = new HashMap<>(2);
>
> What is the typical size the map ends up with? If it stays this small 
> linearly searching an Array (or „last value“) may be faster.
>
> If the map typically grows more than a few entries having some more initial 
> buckets will decrease collissions and avoid resizes. Especially considering 
> the fact that HashMap is a rather fat object, it does not hurt to start with 
> a bigger initial table. Does the lazy initialisation actually help anything?
>
> Single entry alternative
> 
> Object lastClass; String lastName;
>
> If (lastClass == c)
>return lastName;
> lastClass = c;
> lastName = c.getName().replace(‘.‘, ‘/‘);
> return lastName;
>
> (or make it a x Slot Version…):
> ---
> Object tab_obj = new tab_obj[8];
> String tab_val = new String[8];
>
> for(int i=0; i < tab_obj.length; i++)
> {
>If (tab_obj[i] == c);
>  return tab_val[i];
> }
> i = (i+1 % tab_obj.length);
> tab_obj[i] = c;
> return (tab_val[i] = c.getName().replace());
>
> (not sure about the concurrent semantics and having this static may actually 
> help)
>
> Gruss
> Bernd

Re: Floating Point and Arithmetic Changes for Java SE Lnguage

[Bernd Eckenfels]

Hello Anon,

It is impossible to Change the Java behavior for already existing Features like 
the simple Floating Point types. I would not expect much in this area. There 
was a JSR to add a new mode, but it seems to be abandoned: 
https://jcp.org/en/jsr/detail?id=84

I think there was some discussion on Underflow/Overflow handlers, cant remeber 
where I have seen it. It seems to be not on the current JEP list: 
http://openjdk.java.net/jeps/0


BTW: please reconsider your communication strategy (especially on Mailing 
lists). Marking mails as urgent should only be done if you are sure they are 
urgent to all (thousand) receivers, not only to you.

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: A Z
Gesendet: Samstag, 3. März 2018 04:25
An: core-libs-dev@openjdk.java.net
Betreff: Floating Point and Arithmetic Changes for Java SE Lnguage
Wichtigkeit: Hoch

I have found that double and float types in java are heirs to arithmetic 
underflow and overflow at any use.

I have found that presently, floating point is an arithmetic approximation.  My 
problem is that

the java language needs to be changed here, so that one may have arithmetic 
accuracy with

floats and doubles.



There is also a trigonometric shortfall when it comes to BigDecimal.



I have attempted to, and have more carefully described these problems, via the 
java bugs database:



JDK-8190947

JDK-8197995

JDK-8190991

JDK-8190946



-These types, as things are, must be computationally discarded, used only in 
terms of push and pull,

and be programmed around using BigDecimal, which will be a waste of memory,

program execution speed, and a total confusion due to the lack of any operator

usage options on BigDecimals.



-It is the case that set, get methods, constructors and mutability methods are 
all based

around float and double, not BigDecimal, which is part of the previous problem.



-It is the case that setting up BigDecimals can be and is a circumstantial 
waste of memory

with very many tasks, combined with the fact that the fact that having to use 
BigDecimal

method calls is nowhere near as efficient or legible to developers or 
mathematics and enginner

programmers (and useful with their time) as



+, -, *, /, %, +=,-+,*=,/=,%=, ++, --



.This is a syntax argument largely, but also an instruction argument

since BigDecimals have to be set up or used with an extra, thereby second, call.



-It is the case that every other major language includes both floating point 
and accuracy mode

options with these two types and or Objects, either as a source code 
instruction or as a

compiler switch option.  These languages at least provide both options for 
floating

point and mathematical accuracy mode.



-It is so that the present arithmetic underflow and underflow are total 
disadvantages,

that need only be changed in place, for preconditions and postconditions.

This is in regard to programs that have been compiled and built already.



-It is also the case that the state of Java floating point for the last 10 
years or so is not really

any argument, given that things can be changed in place remaining reverse 
compatible,

along with how clear and necessary the problem is.



-My Oracle Support technical reviews seem not to recognise these real problems 
whatsoever, or

only interpret matters in terms of the Java Language Specification on these 
issues,

which of itself possesses inadequecies in these places.



Can someone please reply to me on these things?

Can Oracle update the Java SE language?

Re: Draft JEP proposal: JDK-8200758: Packaging Tool

[Bernd Eckenfels]

You can add-modules from the JDK (only), so if you „—add-modules 
lang.base,JDK.jcmd,jdk.crypto.mscapi“ you get a super compact JRE which still 
can start your app from the classpath.

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Remi Forax
Gesendet: Donnerstag, 28. Juni 2018 22:05
An: Bernd Eckenfels
Cc: core-libs-dev
Betreff: Re: Draft JEP proposal: JDK-8200758: Packaging Tool

no you can't,
--add-modules requires the module to have a module-info, being an automatic 
module is not good enough.

regards,
Rémi

- Mail original -
> De: "Bernd Eckenfels" 
> À: "core-libs-dev" 
> Envoyé: Jeudi 28 Juin 2018 17:34:35
> Objet: Re: Draft JEP proposal: JDK-8200758: Packaging Tool

> you can jlink without any/complete module info files by specifying the module
> names on the command line (--add-modules)as well. It produces a jre like
> Directory including Java launcher which allows additions on the classpath.
> 
> --
> https://Bernd.eckenfels.net
> 
> From: core-libs-dev  on behalf of 
> Scott
> Palmer 
> Sent: Thursday, June 28, 2018 2:32:13 PM
> To: Kevin Rushforth
> Cc: core-libs-dev@openjdk.java.net
> Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
> 
> Doesn’t jlink require a *fully* modularized application?  I.e. no non-module
> dependencies.
> The packaging tool should work with all runnable Java applications, not just
> fully modularized ones.
> 
> Modularization seems to be a bit of an effort and is one of the main reasons 
> my
> application(s) are still stuck on Java 8.
> 
> Scott
> 
> 
> 
>> On Jun 27, 2018, at 6:30 PM, Kevin Rushforth  
>> wrote:
>>
>> We're aiming to get this into JDK 12 early enough so that an EA build would 
>> be
>> available around the time JDK 11 ships. That will allow you to take a jlinked
>> image with JDK 11 and package it up using (the EA) jpackager.
>>
>> We will create a development branch in the JDK sandbox [1] some time in the 
>> next
>> week or so so you can follow the development.
>>
>> Also, thank you to those who have provided feedback. I'll reply to feedback 
>> soon
>> and then incorporate it into an updated JEP.
>>
>> -- Kevin
>>
>>
>> On 6/27/2018 3:09 AM, Buchberger, Joerg wrote:
>>> Thanks for the info! And thanks for the efforts.  [no irony, no sarcasm - I
>>> really mean it]
>>>
>>> But, to sum up my comprehension...
>>>
>>> anyone who placed their bets on javapackager, starting with last LTS Java 8
>>> will be left in the rain with followup LTS Java 11, because their ain't 
>>> neither
>>> javapackager (anymore), nor jpackager (yet).
>>>
>>> Is this correct?
>>>
>>> So, strategic choice boils down to either throw away all work done based on
>>> javapackager so far and the associated distribution concepts (reworking
>>> everything from scratch)
>>> or neglect Java 11 completely, thus placing all bets on jpackager really 
>>> coming
>>> w/ Java 12 or even waiting for Java 14 as next LTS thereafter.
>>>
>>> Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in 
>>> ...
>>>
>>> Cheers
>>> Jörg
>>>
>>>
>>> On 5/31/2018 0:10 AM, Rushforth, Kevin wrote:
>>>> I would like to propose the following Draft JEP [1] for discussion.
>>>>
>>>> JDK-8200758: Packaging Tool
>>>>
>>>> This is intended as a JDK-scope replacement for the existing
>>>> javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK
>>>> releases), and was delivered as part of the JavaFX build. The
>>>> javapackager tool has been removed from Oracle JDK 11 along with the
>>>> removal of JavaFX.
>>>>
>>>> Comments on this JEP are welcome. It is currently not targeted for a
>>>> specific release, but we are aiming for JDK 12.
>>>>
>>>> -- Kevin
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
>>>>

Re: Draft JEP proposal: JDK-8200758: Packaging Tool

[Bernd Eckenfels]

you can jlink without any/complete module info files by specifying the module 
names on the command line (--add-modules)as well. It produces a jre like 
Directory including Java launcher which allows additions on the classpath.

--
https://Bernd.eckenfels.net

From: core-libs-dev  on behalf of Scott 
Palmer 
Sent: Thursday, June 28, 2018 2:32:13 PM
To: Kevin Rushforth
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool

Doesn’t jlink require a *fully* modularized application?  I.e. no non-module 
dependencies.
The packaging tool should work with all runnable Java applications, not just 
fully modularized ones.

Modularization seems to be a bit of an effort and is one of the main reasons my 
application(s) are still stuck on Java 8.

Scott



> On Jun 27, 2018, at 6:30 PM, Kevin Rushforth  
> wrote:
>
> We're aiming to get this into JDK 12 early enough so that an EA build would 
> be available around the time JDK 11 ships. That will allow you to take a 
> jlinked image with JDK 11 and package it up using (the EA) jpackager.
>
> We will create a development branch in the JDK sandbox [1] some time in the 
> next week or so so you can follow the development.
>
> Also, thank you to those who have provided feedback. I'll reply to feedback 
> soon and then incorporate it into an updated JEP.
>
> -- Kevin
>
>
> On 6/27/2018 3:09 AM, Buchberger, Joerg wrote:
>> Thanks for the info! And thanks for the efforts.  [no irony, no sarcasm - I 
>> really mean it]
>>
>> But, to sum up my comprehension...
>>
>> anyone who placed their bets on javapackager, starting with last LTS Java 8
>> will be left in the rain with followup LTS Java 11, because their ain't 
>> neither javapackager (anymore), nor jpackager (yet).
>>
>> Is this correct?
>>
>> So, strategic choice boils down to either throw away all work done based on 
>> javapackager so far and the associated distribution concepts (reworking 
>> everything from scratch)
>> or neglect Java 11 completely, thus placing all bets on jpackager really 
>> coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter.
>>
>> Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in 
>> ...
>>
>> Cheers
>> Jörg
>>
>>
>> On 5/31/2018 0:10 AM, Rushforth, Kevin wrote:
>>> I would like to propose the following Draft JEP [1] for discussion.
>>>
>>> JDK-8200758: Packaging Tool
>>>
>>> This is intended as a JDK-scope replacement for the existing
>>> javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK
>>> releases), and was delivered as part of the JavaFX build. The
>>> javapackager tool has been removed from Oracle JDK 11 along with the
>>> removal of JavaFX.
>>>
>>> Comments on this JEP are welcome. It is currently not targeted for a
>>> specific release, but we are aiming for JDK 12.
>>>
>>> -- Kevin
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
>>>
>

Re: Is it possible to find PDB (windows debugging info) for publishedjvm.dll?

[Bernd Eckenfels]

Sorry for offtopic – figured might still be a good Addition to the question,

If you can switch the JDK (and do not yet need Java 11) then you can use the 
binaries from the ojdkbuild Project (Fedora/RH upstream), they provide the PDB 
files in the *debuginfo* packages (havent tested them myself).

Its a pitty, seems not to be a standard Service of openjdk Vendors (not even 
the paied ones).

https://github.com/ojdkbuild/ojdkbuild/releases

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Alexander Miloslavskiy
Gesendet: Mittwoch, 17. Oktober 2018 19:39
An: core-libs-dev
Betreff: Is it possible to find PDB (windows debugging info) for 
publishedjvm.dll?

Hello,

I'm trying to debug a native crash that regularly happens for one of our 
customers.

It crashes somewhere amidst java interpreter code, with corrupted value 
in CPU's RIP register. So it's quite complicated.

It would certainly help me a lot if I had access to jvm.pdb files for 
published JRE's... I'm mostly after 10.0.1+10 and 8.0_144-b01 at the moment.

According to the published binaries, the PDB's are generated here on the 
build server:
t:\workspace\build\windows-x64\support\modules_libs\java.base\server\jvm.pdb

I believe they are saved somewhere after building, at least internally?

Is there some way to obtain those pdb's myself?
If not, can someone send me the PDB's, at least for 10.0.1+10?

I understand that I can build OpenJDK myself to obtain the PDB's, but 
unfortunately they will not match dumps provided by the client.

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

[Bernd Eckenfels]

http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html

In checkContext should the security manager be null checked first instead of 
last to optimize for the typical case? (If the side effects in that expression 
are desired it should be documented)

I find the tail call optimization comment in wrapException adds only confusion 
to an otherwise clear helper. But maybe it’s just me who does not understand it.

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Vladimir Ivanov 
Gesendet: Donnerstag, November 1, 2018 5:11 AM
An: dean.l...@oracle.com; security-...@openjdk.java.net; core-libs-dev Libs; 
hotspot-dev developers
Betreff: Re: RFR(M) 8212605: Pure-Java implementation of 
AccessController.doPrivileged

Dean,

src/java.base/share/classes/java/security/AccessController.java:
+ /**
+ * Internal marker for hidden implementation frames.
+ */
+ /*non-public*/
+ @Target(ElementType.METHOD)
+ @Retention(RetentionPolicy.RUNTIME)
+ @interface Hidden {
+ }

You declare @Hidden, but then map it to _method_Hidden along with
@Hidden from java.lang.invoke.LambdaForm.

What do you think about moving LambdaForm.Hidden to
jdk.internal.vm.annotation instead and share among all usages?

Best regards,
Vladimir Ivanov

On 31/10/2018 15:23, dean.l...@oracle.com wrote:
> https://bugs.openjdk.java.net/browse/JDK-8212605
> http://cr.openjdk.java.net/~dlong/8212605/webrev.1
>
> This change implements AccessController.doPrivileged in Java.  This
> gives a performance improvement while also being useful to Project Loom
> by removing the Java --> native --> Java transition.  One reason
> doPrivileged has historically been in native is because of the need to
> guarantee the cleanup of the privileged context when doPrivileged
> returns.  To do that in Java, the information that
> AccessController.getContext needs is pushed onto the Java stack as
> arguments to a method that getContext will recognize during its stack
> walk.  This allows us to remove the native privileged stack while
> guaranteeing that the privileged context goes away when the method returns.
>
> Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security
> tests.  For the first few rounds of testing, I kept the old native
> privileged stack and compared the results of the old and new
> implementations for each getContext call, which did catch some early
> bugs.  The changes were also examined by internal security experts and
> run through additional internal security tests.
>
> The improvement on this [1] doPrivileged microbenchmark is approximate 50x.
>
> There is no attempt to optimize getContext() or security permission
> checks in this change, however, this is intended to be a first step
> towards other possible improvements, for example those proposed here [2].
>
> dl
>
> [1]
> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java
>
> [2]
> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html
>
>

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

[Bernd Eckenfels]

Hello,

I wonder if in the Windows temp case LocalLow is (still) the right place. If 
this Installer is not started in the low context it will endanger its extracted 
temp file by making them accessible to low integrity processes, right?

And if this should search %TEMP%., %LOCALAPPDATA%\temp first.

But the variables are known to have problems too, To be robust and Windows 
ready  compliant it looks like another jpackager runtime function for 
SHGetKnownFolderPath would be good (pretty sure it’s already used somewhere, 
just not with a stable API exposed?)

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Philip Race 
Gesendet: Montag, November 12, 2018 10:55 PM
An: Andy Herrick
Cc: build-dev; core-libs-dev@openjdk.java.net
Betreff: Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

74
75 static String getTmpDir() {
76 String os = System.getProperty("os.name").toLowerCase();
77 if (os.contains("win")) {
78 return System.getProperty("user.home")
79 + "\\AppData\\LocalLow\\Sun\\Java\\JPackager\\tmp";
80 } else if (os.contains("mac") || os.contains("os x")) {
81 return System.getProperty("user.home")
82 + "/Library/Application Support/Oracle/Java/JPackager/tmp";
83 } else if (os.contains("nix") || os.contains("nux")
84 || os.contains("aix")) {
85 return System.getProperty("user.home") + "/.java/jpackager/tmp";
86 }
87
88 return System.getProperty("java.io.tmpdir");


This seems unduly complex, and I don't understand the implication of
supporting AIX .. or some unknown "Unix", when packager is targeted
only at mac, linux + windows.

I think its sufficient to look for the strings windows, macos and linux.
And if you want a persistent storage location then default to the "unix"
location if there's no match .. although I am not sure it makes sense
on platforms that aren't targeted by jpackager.

-phil.
>
> -phil.
>
> On 11/12/18, 12:22 PM, Philip Race wrote:
>> Adding build-dev back ..
>>
>> I noticed that module jdk.jpackager.runtime requires java.desktop on
>> all platforms
>>
>> So far as I can tell this is for a Mac-only support for receiving and
>> handling file open events. Probably it only makes sense or gets used
>> when the API is used from a running desktop application.
>>
>> I might ask if we need this at all, but I definitely think it should
>> not be required on all platforms if needed only for Mac even if
>> we might want it on windows in a future version.
>>
>> Do we not envisage cases where you need the runtime API for
>> some kind of daemon service for which there should be a singleton ?
>> Do you really want to force the desktop module to be dragged along
>> in such a case ?
>>
>> I think we should remove this dependency even if it means losing a
>> MacOS feature at least for now.
>>
>> -phil.
>>
>> On 11/11/18, 2:40 PM, Andy Herrick wrote:
>>> On 11/9/2018 5:25 PM, Andy Herrick wrote:
 This is an update to the Request For Review of the implementation
 of the Java Packager Tool (jpackager) as described in JEP 343:
 Packaging Tool 

 This refresh renames the packages used to jdk.jpackager and
 jdk.jpackager.runtime, removes the JNLPConverter demo, adds an
 initial set of automated tests, and contains fixes to the following
 issues:

 JDK-8213324 jpackager deletes existing app directory without warning
 JDK-8213166 jpackager --argument arg is broken
 JDK-8213163 --app-image arg does not work creating exe installers
 JDK-8212089 Prepare packager for localization
 JDK-8212537 Create method and class description comments for main
 functionality
 JDK-8213332 Create minimal automated tests for jpackager
 JDK-821 Fix issues found in jpackager with automated tests
 JDK-8213394 Stop using Log.info() except for expected output.
 JDK-8213345 Secondary Launchers broken on mac.
 JDK-8213156 rename packages for jpackager
 JDK-8213244 Fix all warnings in jpackager java code
 JDK-8212143 Remove native code that supports UserJvmOptionsService
 JDK-8213162 Association description in Inno Setup cannot contain
 double quotes

 The following additional issues are targeted to be address in the
 next few weeks:
 JDK-8212936 Makefile and other improvements for jpackager
 JDK-8212164 resolve jre.list and jre.module.list
 JDK-8213392 Enhance --help and --version
 JDK-8208652 File name is not passed to main() via file
 association on OS X
 JDK-8212538 Determine standard way to determine if a Modular jar
 JDK-8213558 Create more unit tests
>>> Note: The above issues are targeted to 'internal' - meaning we
>>> expect to resolve them in the sandbox before the initial push to JDK12.
>>> Issues targeted to '12' are expected to be fixed after the initial
>>> push.
>>>
>>> /Andy

 Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.2/

 please 

Re: JarFile constructor throws undocumented exception (only) on Windows OS

[Bernd Eckenfels]

Why does that actually throw an Exception on Linux/Unix, it is a perfectly 
legal file name.

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: -2122936656m Auftrag von
Gesendet: Freitag, Oktober 5, 2018 11:00 AM
An: core-libs-dev@openjdk.java.net
Betreff: Re: JarFile constructor throws undocumented exception (only) on 
Windows OS

Just for reference - this came up while debugging an issue, that one of
our users of Apache Ant project raised here
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764#c8

-Jaikiran


On 04/10/18 3:06 PM, Jaikiran Pai wrote:
> Please consider the following trivial code:
>
> import java.util.jar.*;
> import java.io.*;
>
> public class JarFileTest {
> public static void main(final String[] args) throws Exception {
> final String tmpDir = System.getProperty("java.io.tmpdir");
> try {
> final JarFile jarFile = new JarFile(tmpDir + File.separator
> + "*");
> } catch (IOException ioe) {
> System.out.println("Got the expected IOException " + ioe);
> }
> }
> }
>
> The constructor of the JarFile is passed a string which intentionally is
> an (wildcard) invalid path. The above code (as expected) throws an
> IOException on *nix systems across various version of Java (tested
> against Java 8, 11). The same code throws an IOException (as expected)
> in Java 8 on Windows OS too. However, in Java 11, on Windows OS, this
> code throws a different exception (java.nio.file.InvalidPathException)
> which isn't IOException or a subclass of it:
>
> Exception in thread "main" java.nio.file.InvalidPathException: Illegal
> char <*> at index 38: C:\Users\someone\AppData\Local\Temp\1\*
> at
> java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
> at
> java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
> at java.base/java.io.File.toPath(File.java:2290)
> at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1220)
> at
> java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727)
> at java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:845)
> at java.base/java.util.zip.ZipFile.(ZipFile.java:245)
> at java.base/java.util.zip.ZipFile.(ZipFile.java:175)
> at java.base/java.util.jar.JarFile.(JarFile.java:341)
> at java.base/java.util.jar.JarFile.(JarFile.java:312)
> at java.base/java.util.jar.JarFile.(JarFile.java:251)
> at JarFileTest.main(JarFileTest.java:8)
>
>
> The javadoc of JarFile constructor(s) mentions that:
>
>  * @throws IOException if an I/O error has occurred
>
> Given that the javadoc doesn't mention anything about this other
> exception, would this throwing of java.nio.file.InvalidPathException be
> considered a bug in the implementation?
>
> If this indeed is considered a bug, it appears to be the code in
> java.util.zip.ZipFile$Source.get method which calls File#toPath(), which
> as per its javadoc is indeed expected to throw an
> java.nio.file.InvalidPathException if a Path cannot be constructed out
> of the File. Looking at the implementation of the underlying
> java.nio.file.FileSystem on *nix and Windows, they differ when it comes
> to whether or not the exception gets thrown (Unix one seems to always
> return a result). But keeping the implementation of
> java.nio.file.FileSystem aside, I guess the
> java.util.zip.ZipFile$Source.get code needs to have a catch block for
> the InvalidPathException to wrap that into a IOException? Something like:
>
>
> # HG changeset patch
> # User Jaikiran Pai 
> # Date 1538645309 -19800
> #  Thu Oct 04 14:58:29 2018 +0530
> # Node ID ff1bfd8cc9a3b385716fa5191bb68989d552f87e
> # Parent  8705c6d536c5c197d0210acccf145ebc48f90227
> Wrap and throw an IOException when a InvalidPathException is thrown
>
> diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java
> b/src/java.base/share/classes/java/util/zip/ZipFile.java
> --- a/src/java.base/share/classes/java/util/zip/ZipFile.java
> +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java
> @@ -35,6 +35,7 @@
>  import java.lang.ref.Cleaner.Cleanable;
>  import java.nio.charset.Charset;
>  import java.nio.charset.StandardCharsets;
> +import java.nio.file.InvalidPathException;
>  import java.nio.file.attribute.BasicFileAttributes;
>  import java.nio.file.Files;
>  import java.util.ArrayDeque;
> @@ -1218,8 +1219,13 @@
>
>
>  static Source get(File file, boolean toDelete) throws IOException {
> -Key key = new Key(file,
> -  Files.readAttributes(file.toPath(),
> BasicFileAttributes.class));
> +final Key key;
> +try {
> +key = new Key(file,
> +Files.readAttributes(file.toPath(),
> 

Re: are there src git repositories for javase (was: core-libs-dev Digest, Vol 138, Issue 30)

[Bernd Eckenfels]

Hello,

there is no official/canonical one as far as I know, but there are a few 
(externally maintained) Repos which are produced by mirroring the HG trees.

I cannot endores any of them, but in GitHub you find:

Older versions: https://github.com/openjdk-mirror
SAP maintained: https://github.com/SAP/SapMachine/tree/jdk/jdk
Ojdkbuild: https://github.com/ojdkbuild/upstream_jdk
AdoptOpenJDK: https://github.com/AdoptOpenJDK/openjdk-jdk11

Gruss
Bernd

BTW: ist not a good idea to respond to Digest mails, it messes up the threading 
and the subject
-- 
http://bernd.eckenfels.net

Von: Prakhar Makhija
Gesendet: Montag, 8. Oktober 2018 18:44
An: core-libs-dev@openjdk.java.net
Betreff: Re: core-libs-dev Digest, Vol 138, Issue 30

Guys are there src git repositories for javase?

Please share the links

I found git repos for javaee only

On Mon 8 Oct, 2018, 5:30 PM , 
wrote:

> Send core-libs-dev mailing list submissions to
> core-libs-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
> or, via email, send a message with subject or body 'help' to
> core-libs-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> core-libs-dev-ow...@openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of core-libs-dev digest..."
>
>
> Today's Topics:
>
>1. Re: RFC: JEP JDK-8208089: Implement C++14 Language Features
>   (Aleksei Voitylov)
>2. Re: RFC: JEP JDK-8208089: Implement C++14 Language Features
>   (Thomas St?fe)
>
>
> --
>
> Message: 1
> Date: Sat, 6 Oct 2018 18:07:52 +0300
> From: Aleksei Voitylov 
> To: Kim Barrett 
> Cc: build-dev , hotspot-dev developers
> , core-libs-dev@openjdk.java.net
> Subject: Re: RFC: JEP JDK-8208089: Implement C++14 Language Features
> Message-ID: <10d8f2ea-883e-ec21-4fea-06a52a52f...@bell-sw.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Kim,
>
> from an ARM port perspective, the stable GCC version is 4.9. The port
> compiles with stock GCC 7.3 but a lot of testing is required before
> moving to GCC 7.3. I agree on the overall direction and we'll commit
> resources to testing it further, but from an ARM port perspective it may
> happen JDK 12 is a little too optimistic.
>
> GCC x86 is a lot more stable than for ARM32 and AARCH64.
>
> -Aleksei
>
> On 05/10/2018 00:09, Kim Barrett wrote:
> >> On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov <
> aleksei.voity...@bell-sw.com> wrote:
> >>
> >> Kim,
> >>
> >> Thank you for posting this. It's an important step to make. I wanted to
> clarify a couple of points:
> >>
> >> 1. Since this is infrastructure JEP, is the version of JDK which will
> undergo such changes going to be some future version or does it apply to
> past versions as well? I'm concerned with how we can simplify security
> backports to 8u which (I currently assume) is not subject to this change.
> > Future version (perhaps as soon as JDK 12).  I don't think there is
> > any desire to backport this change.  And yes, introducing the use of
> > new language features will make backports even more interesting than
> > they already are.  That seems unavoidable if we're going to pursue
> > this direction.
> >
> >> 2. Which versions of GCC do you tentatively consider at this point?
> Non-x86 ports may have a problem upgrading to a specific version of GCC
> which the shared code will use and may need additional lead time to adjust.
> > I think our (ad hoc) testing has been limited to gcc 7.x. But looking
> > at the gcc language conformance tables and release notes, gcc 5.x
> > might be good enough, and gcc 6.x seems fairly likely sufficient. Of
> > course, older versions are more likely to have bugs in some of these
> > new features. Updating the minimum supported versions for gcc and
> > clang are noted as TBD in the JEP.
> >
>
>
>
> --
>
> Message: 2
> Date: Mon, 8 Oct 2018 12:48:57 +0200
> From: Thomas St?fe 
> To: Kim Barrett 
> Cc: build-dev , HotSpot Open Source
> Developers , Java Core Libs
> 
> Subject: Re: RFC: JEP JDK-8208089: Implement C++14 Language Features
> Message-ID:
>  go62sypqo9x1aw9ezeu3gxcb...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Kim,
>
> is this JEP only about C++14 features or shall we discuss older
> features too? The reason I am asking is that I would like us to
> officially endorse namespaces. Not inline namespaces, just plain old
> namespaces.
>
> HotSpot makes very limited use of namespaces.
>
> Not really true, we already use them. E.g. in metaspace coding, I used
> them to keep the global name space clean and to keep internals
> internal. This was met with positive reviews, and it works on all
> toolchains, so compiler support should not be a problem. Using
> namespaces, we 

Re: RFR: 8211859: (fc) Avoid initializing AtomicBooleanfromRandomAccessFile

[Bernd Eckenfels]

Hello,

just noticed it is probably intended to not be synchronized for the reads 
(since it is volatile)?.

In that case using `this` monitor would also allow to remove the volatile. 
However not sure if that is good or bad for the Performance (close does not do 
DCL then anymore, but ist probably not called that often anyway)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Bernd Eckenfels
Gesendet: Montag, 8. Oktober 2018 21:28
An: core-libs-dev
Betreff: AW: RFR: 8211859: (fc) Avoid initializing 
AtomicBooleanfromRandomAccessFile

getChannel() Synchronizes only on `this` and `close()` on `closeLock`. It does 
I guess work since the important part is make sure only one thread does the 
close work, however Publishing the close change to getChannel is a secondary 
effect of the AtomicBoolean which the new Version does not have(?).

I guess the most efficient method would be to only use this as a monitor. While 
this is not the cleanest usage it is already used, so it does not make it worse…

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Alan Bateman
Gesendet: Montag, 8. Oktober 2018 21:21
An: Claes Redestad; core-libs-dev
Betreff: Re: RFR: 8211859: (fc) Avoid initializing AtomicBoolean 
fromRandomAccessFile

On 08/10/2018 16:32, Claes Redestad wrote:
> Hi,
>
> aligning the closing of RandomAccessFiles with the implementation in 
> FileInput-/OutputStream improves startup in a few tests.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8211859/jdk.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8211859
This looks okay to me.

-Alan

AW: RFR: 8211859: (fc) Avoid initializing AtomicBoolean fromRandomAccessFile

[Bernd Eckenfels]

getChannel() Synchronizes only on `this` and `close()` on `closeLock`. It does 
I guess work since the important part is make sure only one thread does the 
close work, however Publishing the close change to getChannel is a secondary 
effect of the AtomicBoolean which the new Version does not have(?).

I guess the most efficient method would be to only use this as a monitor. While 
this is not the cleanest usage it is already used, so it does not make it worse…

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Alan Bateman
Gesendet: Montag, 8. Oktober 2018 21:21
An: Claes Redestad; core-libs-dev
Betreff: Re: RFR: 8211859: (fc) Avoid initializing AtomicBoolean 
fromRandomAccessFile

On 08/10/2018 16:32, Claes Redestad wrote:
> Hi,
>
> aligning the closing of RandomAccessFiles with the implementation in 
> FileInput-/OutputStream improves startup in a few tests.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8211859/jdk.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8211859
This looks okay to me.

-Alan

Re: jpackage usage

[Bernd Eckenfels]

Is this a console application? I think the launcher won’t show that. So the 
program actually runs, it just not displays a console window.

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Skillzore Gaming 
Gesendet: Mittwoch, Januar 16, 2019 9:15 PM
An: core-libs-dev@openjdk.java.net
Betreff: jpackage usage

Hi!

I am trying out jpackage from https://jdk.java.net/jpackage/. I have been 
trying to figure out how to get it to build a working exe file.
I have a helloWorld.jar built by gradle which is runnable and runs fine with 
"java -jar helloWorld.jar". But when I try to use it to build an exe file, the 
resulting installation (from the built exe file) does not work as expected.
I build the exe file with
jpackage.exe create-installer exe -n "hello" -j helloWorld.jar -o . -i . -c 
HelloWorld

It installs just fine, but when trying to run the resulting hello.exe nothing 
happens. I think that I am doing something wrong in the creation of the exe. I 
am a bit unsure of what the -o, -i and -c parameters are intended to do and 
that is probably where I fail.
Any insight would be appreciated since I am hoping to use this on a larger 
project later and the interwebs do not have much information on this as of yet.

Regards, Simon

Re: Modular Applications - Regression

[Bernd Eckenfels]

JLink works fine with applications on the classpath, all you have to do is to 
list the modules needed manually (and JDeps helps with that).

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Scott Palmer 
Gesendet: Montag, Januar 14, 2019 8:16 PM
An: Alan Bateman
Cc: core-libs-dev
Betreff: Re: Modular Applications - Regression



> On Jan 14, 2019, at 10:33 AM, Alan Bateman  wrote:
>
> On 14/01/2019 15:03, Scott Palmer wrote:
>> :
>>
>> Does this not require ALL dependencies - down the entire dependency chain, 
>> including every transitive dependency, to be 100% modular?
> Look for "automatic modules", this is how the module system facilitates 
> top-down migration where you can migrate to modules without waiting 
> everything you depend on to migrate first. Automatic modules also support 
> bridging to the class path so you can migrate without moving everything from 
> the class path to module name.

Sorry, I’m asking this in the context of building a modular app that I can then 
run jlink or jpackage on. (I *think* I understand automatic modules.) However, 
a workflow that will run perfectly fine with JDK 9 & 10 can’t easily be ported 
to JDK 11 because jlink can't work with automatic modules and java.activation 
is no-longer available as an explicit module (until the issue you cited is 
fixed, but note that the module name has changed, thus requiring a stub module 
for modules that are expecting a module named java.activation).

>
>>
>> I don’t know of many applications outside of those included in the JDK 
>> (where dependencies are not an option) that this restriction actually 
>> applies to. In fact since Java 11 there is a regression where applications 
>> that could be built as modular with JDK 9 & 10 no longer can be, because the 
>> java.activation module was removed and no modular replacement is available. 
>> Many dependency chains lead to java.activation.
> The JavaBeans Activation Framework (JAF) was always maintained as a project 
> in Java EE, never here. In any case, you can download JAF from Maven and 
> deploy it on the module path, it should just work. The only issue with link 
> time where it needs to be migrated to an explicit module before it can be 
> linked into a run-time image. There is an issue in its Eclipse project to 
> migrate it to an explicit module [1].

This issue breaks many cases where jlink used to work. This is why I refer to 
the current state of things as a regression. It’s more than a simple matter of 
obtaining the replacement module for the modules that were removed from the JDK 
- because no such modules currently exist.

Even if you modularize your library or application - you can’t run jlink on it 
if the dependency chain ever leads to an automatic module. Therefore jpackage 
and jlink tools can’t work on projects that they previously could work on due 
to the changes in the JDK being made without a suitable replacement ready for 
java.activation. Somehow java.activation became un-modularized in the process 
of removing it from the JDK.

So more to the point - very few application modules are suitable for jlink 
input. The only practical case seems to be to run jlink by explicitly including 
only modules that have no automatic module transitive dependencies (e.g. 
JavaFX). Even that can’t be done to include JAXB or JAX-WS into a Java 11 JRE 
image, to make a JRE compatible with Java 9 & 10, because of java.activation

Is that correct?

Scott

>
> -Alan
>
> [1] https://github.com/eclipse-ee4j/jaf/issues/13

Re: Modular Applications - Regression

[Bernd Eckenfels]

Well, I think that (jaxb) is a different (but related) issue.

I was just addressing the „generate smaller runtime Image with jimage for 
classpath usage“ part. And that works. You can either do it on the command line 
or introduce an empty module with the needed Imports. In both cases jlink can 
produce a minimized Image (and still have a classpath used).

Given the uncertainity involved in static scanning I would not want jlink to do 
jdeps work automatically, so there is not much else you can do besided 
providing the modules list yourself, or what would be your idea to make this 
work?

(Actually when aiming for small Images, I would even specify the modules in a 
mp path scenario, only because a third party module Imports a JDK module does 
not mean it needs it at runtime for the specific case)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Scott Palmer
Gesendet: Montag, 14. Januar 2019 21:21
An: Bernd Eckenfels
Cc: core-libs-dev
Betreff: Re: Modular Applications - Regression

Aren’t you just saying that jlink works when you don’t use the stuff that broke?

Can you use jlink with JAXB or JAX-WS that does not rely on the .jmod files 
from JDK 9 or 10?

Is there a way to use JAXB or JAX-WS on the module path like there was with JDK 
9 & 10?

>From what I can tell, if one of the modules you need is JAXB or JAX-WS and you 
>already had this working with Java 9 or 10, you have to make a lot of changes. 
> You can’t build a JRE image with jlink that contains the new replacements for 
>JAXB or JAX-WS.  You can include JAXB or JAX-WS on the classpath, but you 
>can’t go back to how it worked with JDK 9 & 10.  

Applications based on a JRE image that includes the java.xml.bind, java.xml.ws, 
or java.activation modules can’t be made to work anymore without resorting to 
hacks like running jlink to pull the .jmod files for those modules from JDK 10 
and the rest of the  runtime from JDK 11.

Scott


> On Jan 14, 2019, at 2:37 PM, Bernd Eckenfels  wrote:
> 
> JLink works fine with applications on the classpath, all you have to do is to 
> list the modules needed manually (and JDeps helps with that).
> 
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> 
> Von: core-libs-dev  im Auftrag von 
> Scott Palmer 
> Gesendet: Montag, Januar 14, 2019 8:16 PM
> An: Alan Bateman
> Cc: core-libs-dev
> Betreff: Re: Modular Applications - Regression
> 
> 
> 
>> On Jan 14, 2019, at 10:33 AM, Alan Bateman  wrote:
>> 
>> On 14/01/2019 15:03, Scott Palmer wrote:
>>> :
>>> 
>>> Does this not require ALL dependencies - down the entire dependency chain, 
>>> including every transitive dependency, to be 100% modular?
>> Look for "automatic modules", this is how the module system facilitates 
>> top-down migration where you can migrate to modules without waiting 
>> everything you depend on to migrate first. Automatic modules also support 
>> bridging to the class path so you can migrate without moving everything from 
>> the class path to module name.
> 
> Sorry, I’m asking this in the context of building a modular app that I can 
> then run jlink or jpackage on. (I *think* I understand automatic modules.) 
> However, a workflow that will run perfectly fine with JDK 9 & 10 can’t easily 
> be ported to JDK 11 because jlink can't work with automatic modules and 
> java.activation is no-longer available as an explicit module (until the issue 
> you cited is fixed, but note that the module name has changed, thus requiring 
> a stub module for modules that are expecting a module named java.activation).
> 
>> 
>>> 
>>> I don’t know of many applications outside of those included in the JDK 
>>> (where dependencies are not an option) that this restriction actually 
>>> applies to. In fact since Java 11 there is a regression where applications 
>>> that could be built as modular with JDK 9 & 10 no longer can be, because 
>>> the java.activation module was removed and no modular replacement is 
>>> available. Many dependency chains lead to java.activation.
>> The JavaBeans Activation Framework (JAF) was always maintained as a project 
>> in Java EE, never here. In any case, you can download JAF from Maven and 
>> deploy it on the module path, it should just work. The only issue with link 
>> time where it needs to be migrated to an explicit module before it can be 
>> linked into a run-time image. There is an issue in its Eclipse project to 
>> migrate it to an explicit module [1].
> 
> This issue breaks many cases where jlink used to work. This is why I refer to 
> the current state of things as a regression. It’s more than a simple matter 
> of obtaining the replacement modu

Re: High memory usage / leaks was: Best mailing list for JVM embedding

[Bernd Eckenfels]

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.

--
https://Bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Robert Marcano 
Gesendet: Mittwoch, Januar 23, 2019 2:18 AM
An: Alan Bateman
Cc: OpenJDK Dev list; core-libs-dev Libs
Betreff: Re: High memory usage / leaks was: Best mailing list for JVM embedding

On Tue, Jan 22, 2019, 5:53 AM Alan Bateman  On 22/01/2019 4:48 am, Robert Marcano wrote:
> >> :
> >>
> >> So the question now is, why signed jars could affect the memory usage
> >> of an application (we aren't doing JAR verification on our custom
> >> launcher, yet), just by being on the java.class.path? IIRC the
> >> initial application classpath JARs were never verified previously (by
> >> the java launcher alone, without JNLP around).
> >>
> >> Note: Tested with JARs signed with a self signed certificate and with
> >> one signed with a private CA. At most, signing the JARs could slow
> >> down the start up if it is now expected to these being verified by
> >> the java launcher (is it true?) but not higher memory usage and no
> >> reductions after a GC cycle but constants heap size increases.
> Signed JARs can be expensive to verify, esp. on first usage as the
> verification is likely to result in early loading of a lot of security
> classes and infrastructure. If you can narrow down the apparently memory
> leak to a small test case with analysis to suggest it's a JDK bug then
> it would be good to get a bug submitted.
>
> -Alan


Greeting. Sure, I will work on a distributable reproduction of the problem
today but it is new to me that the java launcher do JARs verification now.
If it is doing it I doesn't make sense to me, because a self signed or
unrecognized CA doesn't trigger a validation error.

>

Throwable.addSuppressed again

[Bernd Eckenfels]

Hello,

a while back I reported a Problem with „self Suppression“ in the context of 
FilterOutputStream where a „cached“ exception thrown by flush() and close() 
resulted in a IllegalArgumentException:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-May/026743.html

This was fixed for the Filter streams:

https://bugs.openjdk.java.net/browse/JDK-8042377


However the discussion if this is generally a bad behavior of 
Thread.addSuppressed had no conclusion.

I just stumbled across another case where the IllegalArgumentException of 
Throwable.addSuppressed was a Problem: i had seen a case where an 
OutOfMemoryException in a try-with-resource created the same Problem. I cant 
reproduce the Situation clearly (it is related to Closing URLClassLoaders) but 
it looks like in some cases there is an native OOM exception instances are 
re-used. So if a OOM leads to cleanup of resources which trigger the exception 
again, it will happen.

In this case it is rather unfortunate (if somebody expects to see and handle 
the OutOfMemoryException it wont be visible anymore since only the 
IllegalArgumentException is propagated)

I do think (again) that Throwable.addSuppressed should throw the IAE ever, it 
is more robust to just silently skip the Operation.

Alan, did you know if there have been any follow-up discussion?

BTW: there is also a constructor switch to not record suppressed exceptions, 
this switch is however evaluated after the identity check is done. This might 
be worth re-arranging, then Errors and VM Exceptions could at least turn the 
recording off for themselves. (not sure who and why uses this constructor)

https://hg.openjdk.java.net/jdk/jdk/file/dcbb71b9e7c0/src/java.base/share/classes/java/lang/Throwable.java#l1033

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Re: Throwable.addSuppressed again

[Bernd Eckenfels]

Just an Addition: looks like the OOME uses already enableSuppression=true (in 
most? Cases) so a change to check enableSuppression before checking 
self-supression seems like an very effective change (if it is decided to Keep 
this Assertion at all).

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Re: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random)

[Bernd Eckenfels]

Hm strange, never saw it this way. Would other types have the same problem 
(should be visible in your histogram for long as well, right?)

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Brian Burkhalter 
Gesendet: Donnerstag, Dezember 20, 2018 8:03 AM
An: core-libs-dev
Betreff: 8215441: Increase uniformity of the distribution of BigIntegers 
constructed by BigInteger(int, Random)

https://bugs.openjdk.java.net/browse/JDK-8215441

This issue was filed to cover improving the uniformity of randomly generated 
BigIntegers. It is not intended to resolve [1] which is deliberately left open. 
The proposed patch implements a modified version of the “workaround” suggested 
in [1].

The problem is that the magnitude of the random BigInteger is created from a 
sequence of bytes generated by Random.nextBytes() [2]. The likelihood that any 
of these bytes is zero is small so the distribution of the resulting random 
BigIntegers is skewed towards values close to the maximum bit size “numBits” 
specified to the constructor.

The workaround suggested in [1] is to randomly change numBits to the value 
numBits = Random.nextInt(numBits + 1) [3]. (Actually the suggested workaround 
is nextInt(numBits) which is incorrect as the parameter is an exclusive upper 
bound.) This greatly improves the uniformity of the distribution. A remaining 
problem however is that now the very largest numbers in the interval 
[0,2^numBits) are underrepresented. A modification of this approach is to 
increment the new value of numBits as numBits = Random.nextInt(numBits + 1) + 1 
[4]. This was empirically observed to improve the underrepresentation of the 
largest values.

The distribution of the random BigIntegers was estimated using [5]. For a given 
maximum bit length, bin size, and number of random values to generate, this 
creates a histogram and calculates the coefficient of variation of the numbers 
generated. The histogram bin at index zero represents the largest valued bin in 
the result. The count in a given histogram bin is the number of values for 
which that bin is the leftmost (largest valued) with at least one non-zero bit. 
The bin of maximum index represents zero.

Results for the current and two modified approaches for 256 bits with a 1-bit 
bin size and for 4096 bits with a 4-bit bin size are given at [6-11]. As may be 
observed, the original histogram is clustered towards the largest possible 
value 2^numBits - 1, and the coefficient of variation is small. The results for 
the two variants of the patch show a flattened distribution, i.e., more 
uniform, and a significantly larger coefficient of variation. The second 
approach shows better flattening of both ends of the histogram. These results 
are samples only but are exemplary of the results observed over numerous runs 
of this code.

The test ModPow is modified as the modPow() method throws an 
ArithmeticException for a zero modulus. The current algorithm never generates a 
random BigInteger equal to zero however so that exception never occurs. That is 
not the case for either modified version.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8146153
[2] 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Random.html#nextBytes(byte[])
[3] http://cr.openjdk.java.net/~bpb/8146153/webrev.00/
[4] http://cr.openjdk.java.net/~bpb/8146153/webrev.01/
[5] http://cr.openjdk.java.net/~bpb/8146153/StatsBigIntegerRandom.java
[6] http://cr.openjdk.java.net/~bpb/8146153/before-256-1.txt
[7] http://cr.openjdk.java.net/~bpb/8146153/after-256-1.txt
[8] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-256-1.txt
[9] http://cr.openjdk.java.net/~bpb/8146153/before-4096-4.txt
[10] http://cr.openjdk.java.net/~bpb/8146153/after-4096-4.txt
[11] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-4096-4.txt

DataTruncation has static message

[Bernd Eckenfels]

Hello,

The java.sql.DataTruncation Exception/warning has a few detail members, 
especially the index of the field in question. Yet it will not be reflected in 
getMessage/toString. I wonder if the message should be dynamic to at least 
include the index (if known).

http://hg.openjdk.java.net/jdk/jdk/file/7d3391e9df19/src/java.sql/share/classes/java/sql/DataTruncation.java

Gruss
Bernd
--
http://bernd.eckenfels.net

Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

[Bernd Eckenfels]

Hello,

What is the purpose of setting some of them to 0 twice? (It’s a new array which 
should be all-0 anyway.)

+  for (int i = 1; i < 9 ; i++) {
+subkeyHtbl[2*i] = 0;
+subkeyHtbl[2*i+1] = 0;
+}

Also, is the subkeyH no longer be needed (or can be redesigned to use 
subkeyHtbl[0] and 1?

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Kamath, Smita 
Gesendet: Montag, November 19, 2018 10:52 PM
An: 'Vladimir Kozlov'
Cc: Anthony Scarpino; core-libs-dev@openjdk.java.net; hotspot compiler
Betreff: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

Hi Vladimir,

I'd like to contribute an optimization for GHASH Algorithm using AVX 
Instructions. I have tested this optimization on SKX x86_64 platform and it 
shows ~20-30% performance improvement for larger message sizes (for example 8k).

I, smita.kam...@intel.com , Shay Gueuron, 
(shay.gue...@intel.com) and Regev Shemy 
(regev.sh...@intel.com) are contributors to this 
code.

Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074

Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/

For testing the implementation, I have executed TestAESMain.java. I have 
executed Jtreg tests and tested this code on 64 bit Windows and Linux platforms.

Please review and let me know if you have any comments.

Thanks and Regards,
Smita

Re: can File.exists can return false if the file exists?

[Bernd Eckenfels]

Yes it can and does, the getBooleanAttributes method of the filesystem 
providers cannot communicate IOExceptions, so it will have to return unset 
flags for this’s case.

(Also there are some OS specific conditions where the file stat might be stale, 
especially if it is a networked filesystem).

The missing possibility for returning IOExceptions on File IO was one of the 
drivers for NIO APIs (unfortunately the alternative Files.exist(Path) took no 
advantage of this)

What you can do is to open the file and inspect the exception and/or use 
Files.walkFileTree to iterate the parent (as it gives you basicfileattributes 
view based on the directory read)
.
Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von Sean 
Bridges 
Gesendet: Donnerstag, April 4, 2019 9:45 PM
An: core-libs-dev@openjdk.java.net
Betreff: can File.exists can return false if the file exists?

Hey,

Is it possible for File.exists(...) to return false even if the file
exists.

The java docs for File.exists say,

"return true if and only if the file or directory denoted by this abstract
pathname exists; false otherwise"

Looking at the implementation, the method does,

s.getBooleanAttributes(this) & FileSystem.BA_EXISTS) != 0

But FileSystem.getBooleanAttributes says,

"Return the simple boolean attributes for the file or directory denoted
by the given abstract pathname, *or zero if it does not exist or some*
* other I/O error occurs*."

So it seems that File.exists can return false for files which exist.

I think we ran into this on a linux server which reached the limit on open
file handles, and File#exists returned false even though the file existed.

Is there a way to reliably tell in java if a files exists. Even a method
which returned true/false/unknown would be preferable.

Thanks,

Sean

Re: LTS releases and JEP 182: Policy for Retiring javac -source and -target Options ?

[Bernd Eckenfels]

I had the same doubts about the @deprecation N+1 Policy. In both cases a „must 
be deprecated in at least a LTS version“ would be more conservative (but 
understandable very expensive)

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von Alan 
Bateman 
Gesendet: Mittwoch, Februar 27, 2019 2:18 PM
An: Andrew Leonard; core-libs-dev@openjdk.java.net
Betreff: Re: LTS releases and JEP 182: Policy for Retiring javac -source and 
-target Options ?

On 27/02/2019 10:18, Andrew Leonard wrote:
> Hi,
> Does anyone know if this JEP will be modified to cater for the shorter
> release cycles and LTS releases?
> https://bugs.openjdk.java.net/browse/JDK-8046172
> The original Impact statement stated: "but even with this new policy
> source code 10 or more years old should still be able to be compiled"
> however now, for example with JDK12 this policy will only support 1+3 =
> 12, 11, 10, 9, which means LTS JDK8 would not be recognised?
> "1+3" is essentially only 18 months now!
>
JDK 12 dropped support for compiling to --release 6, see JDK-8028563
[1]. You shouldn't have any issue compiling to --release 8.

The policy documented in JEP 182 pre-dates the more rapid cadence, the
policy hasn't been updated yet. The topic has come up on jdk-dev,
discuss, and other places. Joe Darcy's recent mail to jdk-dev [2] might
be useful.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8028563
[2]
https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002628.html

"java.lang.Error: Probable fatal error:No fonts found" does not show on 11

[Bernd Eckenfels]

Hello,

(please let me know in case I picked the wrong list.)

Since OpenJDK does not ship Default *.ttf font files the change that a JRE is 
installed in a way that no System Fonts can be found is quite high.

In OpenJDK8 it is a bit unfortunate that in this situation even for the 
headless graphics context that you can can a Java.lang.Error:

I wonder if this is intentional. How About returnign an empty Array or Maybe a 
RntimeException instead? In my case by upgrading from Oracle JRE to Open JDK 
(in my case Azul) a perfectly fine working Installation is not aborting.

The JasperReports component used is failing does not even need the System Fonts 
(which I will report to them seperately). For Zulu it is enough to install 
Dejavu Fonts in System Directory or copy them to JRE/lib/fonts/, but I have 
also seen OpenJDK  builds which seem to use fontmanager libraries instead of 
fixed file path. Here I guess the dependency on System config is even higher.

I tested on a minimal System with no X11:

> ls /usr/share/fonts
> cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core)

And my test program (below) Returns for Java 8:

> zulu8*x64/bin/java -cp .  FontTest
Are we headless? true
g = sun.java2d.HeadlessGraphicsEnvironment headless: true
Exception in thread "main" java.lang.Error: Probable fatal error:No fonts found.
at 
sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1236)
at 
sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100)
…
at 
sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1220)
at 
sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100)
at 
sun.font.SunFontManager.initialiseDeferredFonts(SunFontManager.java:927)
at sun.font.SunFontManager.loadFonts(SunFontManager.java:3302)
at sun.awt.X11FontManager.loadFonts(X11FontManager.java:466)
at sun.font.SunFontManager.loadFontFiles(SunFontManager.java:3429)
at 
sun.font.SunFontManager.getInstalledFontFamilyNames(SunFontManager.java:3766)
at 
sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:225)
at 
sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:252)
at 
sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:94)
at FontTest.main(FontTest.java:15)

So the error in itself is one topic I wanted to inquire About. However, even 
worse in OpenJDK 11 the error seems to have degenerated quite a bit, it Looks 
for me:

> zulu11*x64/bin/java -cp .  FontTest
Are we headless? true
g = sun.java2d.HeadlessGraphicsEnvironment headless: true
Exception in thread "main" java.lang.InternalError: 
java.lang.reflect.InvocationTargetException
at 
java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:86)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at 
java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74)
at 
java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:189)
at 
java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:223)
at 
java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:251)
at 
java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:75)
at FontTest.main(FontTest.java:15)
Caused by: java.lang.reflect.InvocationTargetException
at 
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
at 
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at 
java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:84)
... 7 more
Caused by: java.lang.NullPointerException
at 
java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1262)
at 
java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:225)
at 
java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:107)
at 
java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:719)
at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:367)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.desktop/sun.font.SunFontManager.(SunFontManager.java:312)
at java.desktop/sun.awt.FcFontManager.(FcFontManager.java:35)
at 

Re: "java.lang.Error: Probable fatal error:No fonts found" does not show on 11

[Bernd Eckenfels]

: Fontconfig returned no font for serif:regular:roman
Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts
INFO: Fontconfig returned no font for serif:bold:roman
Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts
INFO: Fontconfig returned no font for serif:regular:italic
Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts
INFO: Fontconfig returned no font for serif:bold:italic
Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts
INFO: Fontconfig returned no font for monospace:regular:roman
Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts
INFO: Fontconfig returned no font for monospace:bold:roman
Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts
INFO: Fontconfig returned no font for monospace:regular:italic
Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts
INFO: Fontconfig returned no font for monospace:bold:italic
Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts
INFO: Fontconfig returned no fonts at all.
Feb 28, 2019 9:50:32 AM sun.font.FcFontConfiguration warning
WARNING: Failed to get info from libfontconfig
Feb 28, 2019 9:50:32 AM sun.font.FcFontConfiguration warning
WARNING: Failed to get info from libfontconfig
Exception in thread "main" java.lang.InternalError: 
java.lang.reflect.InvocationTargetException
   at 
java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:86)
   at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:310)
   at 
java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74)
   at 
java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:189)
   at 
java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:223)
   at 
java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:251)
   at 
java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:75)


Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Philip Race 
Gesendet: Donnerstag, Februar 28, 2019 12:45 AM
An: Bernd Eckenfels; 2d-dev
Cc: awt-...@openjdk.java.net; Java Core Libs
Betreff: Re: "java.lang.Error: Probable fatal error:No fonts found" does not 
show on 11

Wrong list. You want 2d-dev.

-phil.

On 2/27/19, 3:26 PM, Bernd Eckenfels wrote:
> Hello,
>
> (please let me know in case I picked the wrong list.)
>
> Since OpenJDK does not ship Default *.ttf font files the change that a JRE is 
> installed in a way that no System Fonts can be found is quite high.
>
> In OpenJDK8 it is a bit unfortunate that in this situation even for the 
> headless graphics context that you can can a Java.lang.Error:
>
> I wonder if this is intentional. How About returnign an empty Array or Maybe 
> a RntimeException instead? In my case by upgrading from Oracle JRE to Open 
> JDK (in my case Azul) a perfectly fine working Installation is not aborting.
>
> The JasperReports component used is failing does not even need the System 
> Fonts (which I will report to them seperately). For Zulu it is enough to 
> install Dejavu Fonts in System Directory or copy them to JRE/lib/fonts/, but 
> I have also seen OpenJDK builds which seem to use fontmanager libraries 
> instead of fixed file path. Here I guess the dependency on System config is 
> even higher.
>
> I tested on a minimal System with no X11:
>
>> ls /usr/share/fonts
>> cat /etc/centos-release
> CentOS Linux release 7.3.1611 (Core)
>
> And my test program (below) Returns for Java 8:
>
>> zulu8*x64/bin/java -cp . FontTest
> Are we headless? true
> g = sun.java2d.HeadlessGraphicsEnvironment headless: true
> Exception in thread "main" java.lang.Error: Probable fatal error:No fonts 
> found.
> at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1236)
> at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100)
> …
> at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1220)
> at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100)
> at sun.font.SunFontManager.initialiseDeferredFonts(SunFontManager.java:927)
> at sun.font.SunFontManager.loadFonts(SunFontManager.java:3302)
> at sun.awt.X11FontManager.loadFonts(X11FontManager.java:466)
> at sun.font.SunFontManager.loadFontFiles(SunFontManager.java:3429)
> at 
> sun.font.SunFontManager.getInstalledFontFamilyNames(SunFontManager.java:3766)
> at 
> sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:225)
> at 
> sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:252)
>

Re: jpackage ALL-SYSTEM

[Bernd Eckenfels]

Can you confir it works if you start your application with a stand-alone JDK?

I suspect you have a custom jlink Image which misses the modules. Can you share 
your jpackage configuration or at least run „Java –list-modules“ and 
–validate-modules in your installed app? I think you Need at least jdk.attach


jdk.attach provides com.sun.tools.attach.spi.AttachProvider used by jdk.attach
-- 
http://bernd.eckenfels.net

Von: Michael Hall
Gesendet: Freitag, 8. März 2019 18:29
An: core-libs-dev@openjdk.java.net
Betreff: jpackage ALL-SYSTEM

I have made changes to my application that make it mostly functional with the 
exception of JMX pid attach as built by jpackage. 
I thought I had this functionality working when I first got the application to 
use Java 9 but it no longer appears to work again now, either with my Java 9 
app or my 13-internal+0-jdk13-jpackage.17 version app.
I understand for this issue serviceability-dev might be a better list for this 
but there may be one jpackage issue concerned as well.
Again, I don’t consider this a jpackage problem, my application now builds as 
successfully as it currently can with jpackage as-is.
What I get attempting  a JMX attach is…
2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers
2019-03-08 08:27:03.174 HalfPipe[2071:67749] 
com.sun.tools.attach.AttachNotSupportedException: no providers installed
2019-03-08 08:27:03.174 HalfPipe[2071:67749]at 
jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202)
2019-03-08 08:27:03.174 HalfPipe[2071:67749]at 
us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44)
2019-03-08 08:27:03.174 HalfPipe[2071:67749]at 
us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139)

The application also can’t be connected to from jconsole. Eclipse can be, so 
can a Java 8 app (Weka 3-8-2). jconsole shows Eclipse doing —add-modules 
ALL-SYSTEM
I was going to try this with my application but it did not work. The error 
persisted on that as a jvm argument.
Using it as a jpackage —add-modules parameter gets... 
Module ALL-SYSTEM does not exist.

The one question I would have for jpackage is should this work as a 
—add-modules parameter?

However, if anyone has any suggestions on getting JMX attach to work besides 
adding  serviceability-dev  to my forums that would be appreciated as well.

Thanks.

Re: jpackage ALL-SYSTEM

[Bernd Eckenfels]

Hm, we really should think about renaming --bind-services into --add-all-junk.

Will using the option by default make image creation even less useful (i.e. 
does not safe much) in jpackage? Will there be a option to turn it off? 
Otherwise I guess it’s best to only support --runtime-Image method.

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von Andy 
Herrick 
Gesendet: Freitag, März 8, 2019 9:13 PM
An: core-libs-dev@openjdk.java.net
Betreff: Re: jpackage ALL-SYSTEM

With jpackage EA 3 (build 17) the option --add-modules does not properly
recognize the special cases ALL-SYSTEM, ALL-DEFAULT, and ALL_MODULE_PATH.

This will be addressed in the next EA release.

The default jlink options used (in EA 3) may also not include
--bind-services jlink option, which it will moving forward.

In many cases the jlink options used by jpackage to construct the
runtime for a modular application may not be exactly what the
application wants.

In that case it is advisable to run jlink first to create the optimal
runtime image for a specific application, then to run jpackage with
--runtime-image option to use that runtime image when packaging the
application.

/Andy


On 3/8/2019 9:57 AM, Michael Hall wrote:
> I have made changes to my application that make it mostly functional with the 
> exception of JMX pid attach as built by jpackage.
> I thought I had this functionality working when I first got the application 
> to use Java 9 but it no longer appears to work again now, either with my Java 
> 9 app or my 13-internal+0-jdk13-jpackage.17 version app.
> I understand for this issue serviceability-dev might be a better list for 
> this but there may be one jpackage issue concerned as well.
> Again, I don’t consider this a jpackage problem, my application now builds as 
> successfully as it currently can with jpackage as-is.
> What I get attempting a JMX attach is…
> 2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers
> 2019-03-08 08:27:03.174 HalfPipe[2071:67749] 
> com.sun.tools.attach.AttachNotSupportedException: no providers installed
> 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at 
> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202)
> 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at 
> us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44)
> 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at 
> us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139)
>
> The application also can’t be connected to from jconsole. Eclipse can be, so 
> can a Java 8 app (Weka 3-8-2). jconsole shows Eclipse doing —add-modules 
> ALL-SYSTEM
> I was going to try this with my application but it did not work. The error 
> persisted on that as a jvm argument.
> Using it as a jpackage —add-modules parameter gets...
> Module ALL-SYSTEM does not exist.
>
> The one question I would have for jpackage is should this work as a 
> —add-modules parameter?
>
> However, if anyone has any suggestions on getting JMX attach to work besides 
> adding serviceability-dev to my forums that would be appreciated as well.
>
> Thanks.

Re: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes

[Bernd Eckenfels]

Instead of removing the file path, would it be possible to add it to all 
implementations guarded by jdk.includeInExceptions=filename?

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von Alan 
Bateman 
Gesendet: Freitag, März 22, 2019 5:35 PM
An: Langer, Christoph; Java Core Libs
Betreff: Re: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem 
implementation classes

On 22/03/2019 08:37, Langer, Christoph wrote:
> Hi,
>
> when contemplating over JDK-8211752, I found a few minor cleanups for the 
> implementations of UnixFileSystem/WinNTFileSystem. Can I please get reviews?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8221262
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221262.0/
This looks okay to me.

-Alan

Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

[Bernd Eckenfels]

For security reasons I would add it to `jdk.includeInExceptions`, but maybe as 
a default?

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Roger Riggs 
Gesendet: Dienstag, Februar 12, 2019 8:07 PM
An: Lindenmaier, Goetz; Java Core Libs
Cc: hotspot-runtime-...@openjdk.java.net
Betreff: Re: RFR(L): 8218628: Add detailed message to NullPointerException 
describing what is null.

Hi,

On 02/12/2019 08:14 AM, Lindenmaier, Goetz wrote:
> Hi Roger,
>
> thanks for looking at my change!
>
>> A few higher level issues should be considered, though the details of
>> the webrev captured my immediate attention.
>>
>> Is this the right feature
> Yes!!
Maybe, that's what debuggers are for.
>
>> and is this the right level of implementation (C++/native)?
> See below.
Maybe 10 years ago, when native was the only solution.
Now there are tools to analyze bytecode in java.
>
>> From a security perspective, adding field names to exceptions exposes
>> information to callers that they could not otherwise get and that breaks
>> encapsulation.
>> That needs to be evaluated.
> I can not comment on that. How can I trigger an evaluation of this?
> Who needs to evaluate this?
>
>> I think there are ways to make this easier to implement and be easier to
>> maintain and perform better.
>>
>> NullPointerException:
>> 28: unused import of Field
> Removed
>
>> 64: The lazyComputeMessage boolean should be inverted so it does not
>> require
>>initialization, false is the default, anything else adds overhead.
>>And it may not be needed.
> Peter Levart proposed to initialize the message with a sentinel instead.
> I'll implement this as a proposal.
That's an extra overhead too, any assignment is.
>
>> 91: Why do you think synchonization is necessary?  It is a performance hit.
>>It is highly unlikely to be called from multiple threads and the
>> value will
>>be the same whether it is computed once or multiple times by
>> different threads.
> I guess we can go without.
> It would be possible to construct a case where two threads
> do getMessage() on the same NPE Object but the string is not
> the same.
Really!, if the bci is the same, the bytecode is the same, what could be
different
that would change the data used to create the exception?
>
>> 99: extendedMessage will never be null (so says the javadoc of
>> getExtendedNPEMessage)
>>   Bug: If it does return null, then null is returned from getMessage
>>   regardless of the value of super.getMessage().
> Fixed.
>
>> 121: Simplify getExtendedNPEMessage by making it only responsible for
>> the detail
>>   and not concatenation with an existing message.  Put that in
>> getMessage().
> Fixed. You are right, I only call this when the message is NULL.
>
>>   Its not strictly necessary to change the updated message with
>> setMessage().
>>   Avoiding that will avoid complexity and a performance hit.
>>   The message will be computed each time it is needed, and that happens
>> infrequently.
>>   (Even in the serialization case, it will be re-computed from the
>> attached stack frames).
> No, you can not recompute it from the stacktrace because that
> does not contain the BCI. Also, after deserialization, the bytecode
> might look different or not available at all. It depends on the actual
> bytecode that has been running when the exception was thrown.
Right, I realized this too when thinking about it over the weekend.

If a suitable low impact mechanism can't be found, then just
go back to not exposing the extended message and use only the original.
Its a bad idea to twist and contort the local design and accessibility
just for serialization. What remote or delayed client needs to know this?

>
>>   And it avoids adding setMessage() to Throwable, that's significant
>> change since
>>   the current implementation only allows the message to be initialized
>> not updated.
>>   Immutable is an important characteristic to maintain.
> Yes, I don't like I have to set this. But it follows the same pattern
> as with the stack trace which is only computed on demand. Thus,
> Throwable is not immutable anyways. Before, I implemented this by a
> JNI call hiding this in the Java code.
> I proposed implementing setting the field by reflection, Christoph
> proposed a shared secret. David favored the package private setter.
> Please advice what is best.
All of them are bad. Private needs to mean private.

And making it mutable, also means that synchronization or volatile
is needed to ensure a consistent value for getMessage().
That turns into a performance issue for all throwables.
None of the above.
>
>> That makes the writeReplace() unnecessary too.
> No. I need this, see above.
See above, but is not essential to the core feature.
>
>> Additional command line arguments are an unnecessary complexity,
>> documentation, and maintenance overhead.  If the feature is as valuable as
>> you suggest, it should be enabled all the time.
> Removed.
>

PreparedStatement.setBinaryStream Javadoc

[Bernd Eckenfels]

Hello,

The JavaDoc for some of the setBinary/ASCII... methods of PS say something 
about „more practical“ but it is not clear if it means this method is more 
practical than another method, or if this method should not be used in favor of 
another.

When a very large binary value is input to a LONGVARBINARY parameter, it 
may be more practical
 to send it via a java.io.InputStream object.

Also, does this not apply to BLOB or VARBINARY?

I would clarify this to something like (if I understood the meaning correctly):

For large content the use of an InputStream/Reader can avoid keeping the 
data in memory,
It however depends on the driver how the data is internally processed or 
buffered.

BTW those functions do not mention if the stream is closed or not.

After the method returns the stream is not closed.

Some more clarifications could also be given (not sure if all of them are 
correct):

The stream is positioned after the specified length.
The reading blocks till the end of stream is signaled (will not return when 
abailable()==0)
EOFException is thrown If stream is shorter than specified length.

Gruss
Bernd
--
http://bernd.eckenfels.net

Re: High memory usage / leaks was: Best mailing list for JVM embedding

[Bernd Eckenfels]

Hello,

I think in the Java 9 timeframe the Zip implementation was changed to no longer 
mmap the Zip index table. So this was not visible in the heap but now is. 
(Although it seems to be a bit slower). That might be the reason for your 
regression. You could use the following System property in Java 8 to get the 
new method there as well (in Java 9 the property and the old method is gone)

https://bugs.openjdk.java.net/browse/JDK-8175192

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Robert Marcano 
Gesendet: Donnerstag, Januar 24, 2019 5:26 PM
An: core-libs-dev@openjdk.java.net
Betreff: Re: High memory usage / leaks was: Best mailing list for JVM embedding

On 1/23/19 8:59 AM, Sean Mullan wrote:
> 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.
>
> --Sean

I noticed that trying to identify the higher memory usage after what
looks like a big application is loaded. I am doing memory profiling and
notice JarFile taking more memory that on Java 8. Still need to detect
the real cause for an independent test case. We probably didn't notice
this slowdown before because Oracle's JNLP implementation was slow
enough at startup.

IMHO the class library should not do doing signature checks without
certificate validation, because it doesn't give any protection if the
signature is not verified, the only thing it could do now is to detect
some random bit flips, that maybe the Zip format CRC detect before that.
With no certificate verification the signature could be replaced by
anybody with bad intentions.

Maybe adding a constructor flag to URLClassloader to pass to JarFile to
skip verification and a system property to tell the Java startup code to
skip verification of java.class.path (just for compatibility with old
code that expect it to be done). There is precedent of other runtimes
that added options to disable this, like CLR [1] (Ii not only verified
signatures, It do CRL/OSCP checks too)

Our new launcher replacing JNLP now do signature verification in native
code, at download time, and install on a system area (not user home
directory), so signature verification at application launch is a
slowdown we want to avoid, but think on another kind of users, those
deploying to OS Stores (for example Windows Store), why add the slowdown
of verification when the application is verified by the store client at
install time?, this could help these situations too.

Note: This can be avoided removing the signatures of all JARs if you
distribute to an OS store, there are a few libraries that distribute
their JARs signed (The old Java Help framework comes to my mind right now)

[1]
https://blogs.msdn.microsoft.com/shawnfa/2007/05/07/bypassing-the-authenticode-signature-check-on-startup/

>
>>
>> --
>> https://Bernd.eckenfels.net
>>
>> 
>> Von: core-libs-dev  im Auftrag
>> von Robert Marcano 
>> Gesendet: Mittwoch, Januar 23, 2019 2:18 AM
>> An: Alan Bateman
>> Cc: OpenJDK Dev list; core-libs-dev Libs
>> Betreff: Re: High memory usage / leaks was: Best mailing list for JVM
>> embedding
>>
>> On Tue, Jan 22, 2019, 5:53 AM Alan Bateman > wrote:
>>
>>> On 22/01/2019 4:48 am, Robert Marcano wrote:
>>>>> :
>>>>>
>>>>> So the question now is, why signed jars could affect the memory usage
>>>>> of an application (we aren't doing JAR verification on our custom
>>>>> launcher, yet), just by being on the java.class.path? IIRC the
>>>>> initial application classpath JARs were never verified previously (by
>>>>> the java launcher alone, without JNLP around).
>>>>>
>>>>> Note: Tested with JARs signed with a self signed certificate and with
>>>>> one signed with a private CA. At most, signing the JARs could slow
>>>>> down the start up if it is now expected to these being verified by
>>>>> the java launcher (is it true?) but not higher memory usage and no
>>>>> reductions after a GC cycle but constants heap size increases.
>>> Signed JARs can be expensive to verify, esp. on first usage as the
>>> verification is likely to result in early loading of a lot of security
>>> classes and infrastructure. If you can narrow down the apparently memory
>>> leak to a small test case with analysis to suggest it's a JDK bug then
>>> it would be good to get a bug submitted.
>>>
>>> -Alan
>>
>>
>> Greeting. Sure, I will work on a distributable reproduction of the
>> problem
>> today but it is new to me that the java launcher do JARs verification
>> now.
>> If it is doing it I doesn't make sense to me, because a self signed or
>> unrecognized CA doesn't trigger a validation error.
>>
>>>

Re: RFR 8225474: JDI connector accept fails "Address already in use" with concurrent listeners

[Bernd Eckenfels]

 stopListening seems not atomically using listenMap. (Ie change get/remove to 
remove only)

BTW this would be a good usecase for a CopyOnWriteMap...


--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Andrew Leonard 
Gesendet: Freitag, Juni 7, 2019 6:14 PM
An: core-libs-dev@openjdk.java.net
Betreff: RFR 8225474: JDI connector accept fails "Address already in use" with 
concurrent listeners

Hi,
Please can I request a sponsor and review of this patch for JDK-8225474. A
problem that we have seen intermittently with JDI connector stress tests
for quite a while that is caused by an non-thread safe HashMap in the
connector class. I've created a standalone testcase that reproduces it
reliably.
http://cr.openjdk.java.net/~aleonard/8225474/webrev.00

Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leon...@uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: RFR 8230365 : Pattern for a control-char matches non-control characters

[Bernd Eckenfels]

Hallo,

Since not all combinations make sense (Exception+convert) a multi value might 
be better:

jdk.regex.control=WARN|EXCEPTION|STANDARD|LEGACY

With Exception generating an error, Standard beeing the planned new default 
(treating upper/lower same and error on all undefined chars) and legacy beeing 
the manual fallback to current behavior and WARN the same fallback but with 
logging.

I guess some form of early feedback like EXCPETION or WARN is needed, even when 
it is between a rock and a hard place. Maybe have at least one iteration where 
it defaults to LEGACY (+Release Notes announcement), then WARN and then finally 
STANDARD?

Gruss
Bernd


--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von Ivan 
Gerasimov 
Gesendet: Donnerstag, September 5, 2019 4:00 AM
An: Martin Buchholz; Stuart Marks
Cc: core-libs-dev
Betreff: Re: RFR 8230365 : Pattern for a control-char matches non-control 
characters

Thank you Martin!

On 8/30/19 6:19 PM, Martin Buchholz wrote:
> There's a strong expectation that ctrl-A and ctrl-a both map to
> \u0001, so I support Ivan's initiative.
> I'm surprised java regex gets this wrong.
> Might need a transitional system property.
>
Right.  I think it would be best to introduce two system properties:

The first, to turn on/off the restrictions on the control-char names.
This will be enabled by default, and will permit names from the limited
list: capital letters and a few other special characters.

The second one, to enable mapping of lower-case control-char names to
their upper-case counterpart.  This option should be turned off by
default for the current release of JDK, and then turned on by default
for some subsequent release (when, presumably, most applications that
use this kind of regexp are fixed).

This all feels like a little bit too much for such a rarely used
feature, but probably is a proper thing to do anyway :-)

If we have an agreement on these system properties, I can create a
separate test to verify all possible combinations.


> What's the best bit-twiddle?  Untested:
> if ((c ^= 0x40) < 0x20) return c;
> if ((c ^=0x20)  <= 26 && c > 0) return c;
>
> 0x40 is more readable than 64.
>
`((ch-0x3f)|(0x5f-ch)) >= 0` does the trick for regular (non-lower-case)
ids.

> Does ctrol-? get mapped to 0x7f ?
>
Yes. I've got it in the test at the end of the line 4997.

Would you please help review the updated webrev:

http://cr.openjdk.java.net/~igerasim/8230365/02/webrev/

With kind regards,

Ivan

Re: [JSR] [JEP] Java Specification Requirement / Java Enhancement Proposal : 'Parallel OR' and 'Parallel AND'

[Bernd Eckenfels]

Hello,

I don’t think you will get a new infix operator for this. And adding it to 
existing operators will be acquire risky change, might not improve performance 
for most situations - and most of all it is quite unlikely that you have a 
large number of terms at static compile time anyway.

However if you want to evaluate expressions in parallel on a dynamic and large 
collection, you can easily use a parallel stream. Using predicates as the 
expression terms to evaluate you can use for example findAny() for checking a 
or condition.

Gruss
Bernd


--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Prakhar Makhija 
Gesendet: Mittwoch, Juli 24, 2019 4:49 PM
An: David Holmes; core-libs-dev@openjdk.java.net
Betreff: [JSR] [JEP] Java Specification Requirement / Java Enhancement Proposal 
: 'Parallel OR' and 'Parallel AND'

Hi David / All,


Earlier wanted to discuss just the implementation of 'OR operator', neither
'Conditional OR operator', nor 'Bitwise OR operator'

Same goes with 'AND operator'

Technically OR operator and AND operator are just binary operators, that's
true

I don't find it wrong considering there can be n operands, in an
expression, with either of the two operators or a combination of both,
where n >= 2

n can go nearby anything in powers of 10, it will take those many
sequential clock cycles, to actually resolve the expression

If you consider the same n as an expression of powers of 2, the same thing
can be done in parallel clubbed with divide and conquer, taking the same
number of clock cycles, but saving actual response time

This can be given as a input from console, or as a property, specifying
which implementation to use at runtime, sequential or parallel

But with the latter would lead to very frequent resource starvage, this
would need to be handled, to actually free the resources and give to pid or
ppid, heirarically, or based upon who is the callee, or who asked who to
wait, or some more other logic

All the threads parallelly evaluating the same expression, with either
operand, should be terminated and concluded as, when any thread results to:
'true' in case of OR
'false' in case of AND

An expression can have further sub-expressions; so an expression with
combination of both operands, will be considered as parent expression

Yes it does change the conventional implementation of OR operator, and AND
operator, in Java

So it would be better to have two new operators/symbols itself

Parallel OR
|||

Parallel AND
&&&

We can go with the symbol |&& also in case of Parallel AND


Looking forward to hearing your thoughts


Best Wishes & Regards
Prakhar Makhija



Hi Prakhar,


On 22/06/2019 1:28 am, Prakhar Makhija wrote:
> Topic: OR operator represented by ||

That should be the subject of your email - not a reply to a digest.


> Query: The expression evaluation of the operands, of OR operator, does it
> happen in parallel, when Java code runs, in the current versions?

No, there is no parallel evaluation of anything in Java. It would be
wrong to do so in this case as:

"The conditional-or operator || operator is like | (§15.22.2), but
evaluates its righthand operand only if the value of its left-hand
operand is false."


David

Re: RFR [14/java.xml] 8233686: XML transformer uses excessive amount of memory

[Bernd Eckenfels]

This does save object allocations and churn, not memory footprint I guess. The 
namespace mapping contains multiple stacks (with object arrays) and a hashtable 
and initialized records, so it seems to allocate a few kb on every node 
visited. (But 100MB allocation does sound like a very constructed case)

BTW the thing I wondered, is there a process to keep xerces in sync?

Gruss
Bernd


--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von Vyom 
Tiwari 
Gesendet: Freitag, November 8, 2019 11:14 AM
An: Joe Wang
Cc: core-libs-dev
Betreff: Re: RFR [14/java.xml] 8233686: XML transformer uses excessive amount 
of memory

Hi Joe,

Fix looks OK to me , but i am not able to understand how come
"NamespaceMappings" instance can increase memory uses from (20MB to 140MB
).

Current scope of "ns" is "case Node.ELEMENT_NODE:" block and
"NamespaceMapping" seems to be very lightweight class.

Thanks,
Vyom

On Fri, Nov 8, 2019 at 12:33 AM Joe Wang  wrote:

> Please review a quick fix that reduces unnecessary object allocations.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8233686
> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8233686/webrev/
>
> Thanks,
> Joe
>
>

--
Thanks,
Vyom

Re: Apache Phoenix with OpenJDK

[Bernd Eckenfels]

Hello,

If you can’t find the needed information on the Project Website it is probably 
best to contact the project on the user mailing list.

https://phoenix.apache.org/mailing_list.html

You might want to give more information like which component is failing, what 
are the exact error logs and what are the versions of the associated products 
(like HBase).

Gruss
Bernd


--
http://bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Rachu Vmpp 
Gesendet: Freitag, Oktober 11, 2019 8:15 PM
An: core-libs-dev@openjdk.java.net
Betreff: Apache Phoenix with OpenJDK

Dear Fellas,

Is openJDK 11 compatible with Apache Phoenix? I could see some
PhoenixDialect unresolvable name error.

Can somebody help?

Re: jpackage current status

[Bernd Eckenfels]

Hello Michael,

Currently the native binaries (java launcher) are not included. If you want to 
do that, you need to generate the jlink image first (what you need to do anyway 
if you want a specific version).

This is kind of by design, but it looks like if this can be configured in 
future versions.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von 
Michael Hall 
Gesendet: Montag, Februar 24, 2020 9:33 PM
An: Kevin Rushforth
Cc: core-libs-dev
Betreff: Re: jpackage current status



> On Feb 24, 2020, at 1:48 PM, Michael Hall  wrote:
>
>
>
>> On Feb 24, 2020, at 1:15 PM, Kevin Rushforth  
>> wrote:
>>
>> Since your ToolProvider-based program doesn't explicitly require 
>> jdk.incubator.jpackage, it won't be in the module graph. It should work fine 
>> if you run with:
>>
>> $ java --add-modules jdk.incubator.jpackage ...
>>
>
> I’m not understanding the module subtleties yet but yes that does work 
> command line. Other than -add-modules into the runtime are there any special 
> considerations for using it from an application?

Ah, the obvious. Same solution for application also works. I can 
programmatically invoke jpackage with this.

>
> I am still wondering for the application embedded runtime exec not finding 
> linked native commands if this is expected not to work or is considered an 
> issue?
>

This remains a question for me. Should Runtime exec find the native commands 
included with an application embedded JRE? It currently doesn’t seem to on OS X.

Re: New candidate JEP: 371: Hidden Classes

[Bernd Eckenfels]

Hello,

I wonder will this (weak class) be useful for reflective method accessors and 
even be able to reduce/remove the need of 
jdk.internal.reflect.DelegatingClassLoaders? If so, that would be a good 
example to mention in the JEP (it only mentions Proxies).

(And I was really surprised to see Nashorn mentioned after it is deprecated, 
even when it is certainly a good Test bed).

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von 
David Holmes 
Gesendet: Friday, January 24, 2020 11:56:07 PM
An: hotspot-dev developers ; core-libs-dev Libs 

Betreff: Fwd: New candidate JEP: 371: Hidden Classes

FYI.

Cheers,
David

Re: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds

[Bernd Eckenfels]

Hello,

I wonder why there are two times the same logic in internal public static 
methods. Maybe that could be consolidated as well?

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von 
Yangfei (Felix) 
Gesendet: Tuesday, March 10, 2020 3:54:54 AM
An: core-libs-dev@openjdk.java.net 
Betreff: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds

Hi,

  We found module-info.class in java.base.jmod is not always consistent across 
different builds.
  The ModuleHashes attribute in this module-info.class is not reproducible 
between builds.
  Patch fixes the issue by using TreeMap instead of HashMap when computing 
ModuleHashes.

  Bug: https://bugs.openjdk.java.net/browse/JDK-8240734
  Webrev: http://cr.openjdk.java.net/~fyang/8240734/webrev.00/

  Passed tier1 test.  Please review.

Thanks,
Felix

Fwd: RFR: 8223187: Investigate setLocale() call in jpackage native launcher

[Bernd Eckenfels]

Hello,

What about system errors (exception messages from strerr?). I mean  in case one 
wants to enforce English version with user.locale for support reasons?

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von 
Alexander Matveev 
Gesendet: Saturday, September 12, 2020 4:22:31 AM
An: core-libs-dev@openjdk.java.net 
Betreff: RFR: 8223187: Investigate setLocale() call in jpackage native launcher

setlocale() affects several C functions. We do not use most of these functions. 
We only using isspace() and toLower().
Based on how we use it I do not see any needs for setlocale(). After removing 
it I retested jpackage by changing
locally on machine and using different language as input parameters for 
jpackage. No issues found.

-

Commit messages:
 - 8223187: Investigate setLocale() call in jpackage native launcher

Changes: https://git.openjdk.java.net/jdk/pull/138/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=138=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8223187
  Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/138/head:pull/138

PR: https://git.openjdk.java.net/jdk/pull/138

Re: jpackage OS X codesign IOException

[Bernd Eckenfels]

Looks like the codesign command is not in your PATH

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Michael 
Hall 
Gesendet: Saturday, September 26, 2020 1:57:06 PM
An: core-libs-dev@openjdk.java.net 
Betreff: jpackage OS X codesign IOException

java.io.IOException: Command [codesign, -s, Developer ID Application: X 
(X), -, 
/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage16414030388823297270/images/image-1807061985031173/HalfPipe.app]
 exited with 1 code

X values changed by me

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

[Bernd Eckenfels]

Not completely sure about which of the involved apIs have what possible 
extensions. Maybe we can somehow make two mechanisms one which is the 
compatible default and one would be the rfc compliant method. Then SASL can be 
configured and use different mechanism names with a new propert? That would 
help jgss for the other mechanisms for channel bindings (cbt) as well. Not sure 
how jgss and JSSE will talk to each other.. via SASL?


--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von 
Alexey Bakhtin 
Gesendet: Tuesday, May 26, 2020 7:46:11 PM
An: Weijun Wang 
Cc: security-...@openjdk.java.net ; 
core-libs-dev@openjdk.java.net ; Michael Osipov 

Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hello Max,

Thank you review.
If I understand correctly tls-server-end-point channel binding data is a hash 
of server certificate. Different SASL protocols could send cbData differently, 
with different prefix format. This is a reason I create TLSChannelBinding class 
and calculate hash from the LdapClient and add “tls-server-end-point:” prefix 
in the JGSS/Kerberos.

Alexey

> On 26 May 2020, at 17:50, Weijun Wang  wrote:
>
> I have a question on GssKrb5Client.java:
>
> Do you think it's a good idea to let the SASL mechanism understand what TLS 
> binding is? Instead of passing the whole TlsChannelBinding object through a 
> SASL property, is it possible to only pass the actual cbData? After all, the 
> name "com.sun.security.sasl.channelbinding" suggests it's just a general 
> ChannelBinding which is independent with any application level info.
>
> From my reading of the code change, it looks like this cbData can be 
> calculated on the LDAP side.
>
> Thanks,
> Max
>
>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin  wrote:
>>
>> Hello,
>>
>> Could you please review the following patch:
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527
>> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/
>>
>> The Windows LDAP server with LdapEnforceChannelBinding=2 uses the 
>> tls-server-end-point channel binding
>> (based on the TLS server certificate). The channel binding data is 
>> calculated as following :
>>   • The client calculates a hash of the TLS server certificate.
>>  The hash algorithm is selected on the base of the certificate 
>> signature algorithm.
>>  Also, the client should use SHA-256 algorithm, in case of the 
>> certificate signature algorithm is SHA1 or MD5 based
>>   • The channel binding information is the same as defined in rfc4121 
>> [1] with small corrections:
>>   • initiator and acceptor addresses should be set to NULL
>>   • initiator and acceptor address types should be zero.
>> It contradicts to the “Using Channel Bindings in GSS-API” 
>> document [2] that say that
>> the address type should be set to GSS_C_AF_NULLADDR=0xFF,
>> instead of GSS_C_AF_UNSPEC=0x00.
>>
>> This patch introduces changes in the LDAP, SASL and JGSS modules
>> to generate channel binding data automatically if requested by an 
>> application.
>> This patch reuses existing org.ietf.jgss.ChannelBinding class implementation 
>> but changes
>> initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to 
>> CHANNEL_BINDING_AF_UNSPEC.
>> The patch introduces new environment property “com.sun.jndi.ldap.tls.cbtype” 
>> that indicates
>> Channel Binding type that should be used in the LDAPS connection over 
>> JGSS/Kerberos.
>> Right now "tls-server-end-point" Channel Binding type is supported only.
>> The client extracts server certificate from the underlying TLS connection 
>> and creates
>> Channel Binding data for JGSS/Kerberos authentication if application 
>> indicates
>> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property.
>> Client application should also specify existing 
>> "com.sun.jndi.ldap.connect.timeout” property
>> to force and wait TLS handshake completion before JGSS/Kerberos 
>> authentication data is generated.
>>
>> [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2
>>
>> [2] -
>> https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html
>>
>> Initial discussion of this issue is available at security-dev list:
>> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html
>> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html
>> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html
>> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

[Bernd Eckenfels]

LdapCtxt:

2568 /**

2569  * Sets the read timeout value

2570  */

2571 private void setChannelBindingType(String cbTypeProp) {


Not sure if that javadoc is the right one? And I also wonder if enforcing the 
timeout is needed, and if yes if it should be documented why. Was not obvious 
to me,


what about having two type names (TlsChannelBindingType.TLS_SERVER_END_POINT 
and TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT?)


This could be configured as a SASL property and it would add the benefit that 
you don't need the instance specific if in the gssstub native code if you 
instead have two different types values?


Gruss

Bernd


Von: security-dev  im Auftrag von Alexey 
Bakhtin 
Gesendet: Mittwoch, Mai 27, 2020 11:43 AM
An: Valerie Peng
Cc: security-...@openjdk.java.net; core-libs-dev@openjdk.java.net; Thomas Maslen
Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hello Valerie, Unfortunately, Windows LDAP server with 
LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type. 
This is exact reason of these changes. I ve tried to fix inconsistency of 
address type value in the latest webrev: 
http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/

Language locales have different calendars than country locales in 9+

[Bernd Eckenfels]

Hello,

Just wanted to mention a thing I noticed when switching from 8 to 11. I knew 
before that the Locale data provider has changed, and I could notice that for 
example in the writing style for abbreviated words in dates. However something 
I did not expect is, that the definition of Calemdars change as well.

Locale.GERMAN and Locale.GERMANY construct different calemdars under Java 11 
with CLDR as opposed to Java 8 or Java 11 with compat. The most notably changes 
are when calculating calendar weeks (min days in first week) or the start of a 
week (Sunday vs. Monday).

I haven't seen that explicitely mentioned and I also wonder if this should be 
mentioned in the Locale JavaDoc that language locales and country locales might 
differ severely in that aspect.


GERMANY:
Calendar.minDays 4 
java.util.GregorianCalendar[time=1596218932830,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=…,firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=830,ZONE_OFFSET=360,DST_OFFSET=360]
11.0.1+13-LTS de_DE 2011-01-01 2010-52

GERMAN
Calendar.minDays 1 
java.util.GregorianCalendar[time=1596218932879,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=...,firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=879,ZONE_OFFSET=360,DST_OFFSET=360]
11.0.1+13-LTS de2011-01-01 2011-01

Sample code:

Date d = new Date(129384360L);

Locale l = Locale.GERMANY;

Calendar c = Calendar.getInstance(l);
System.out.println("Calendar.minDays "+ c.getMinimalDaysInFirstWeek() + " " 
+ c);

SimpleDateFormat sdf = newSimpleDateFormat("-MM-DD -ww", l);
System.out.printf("%s %-5s %s%n", System.getProperty("java.vm.version"), l, 
sdf.format(d));


--
http://bernd.eckenfels.net

Re: Language locales have different calendars than country locales in 9+

[Bernd Eckenfels]

Hello,

Is there a good description what calendar is actually used for a language-only 
locale? Is there a typical association of calendars with locales or is it a 
global default? If the unicode data does not have such a value, would it be 
better to fall back to the next provider (like COMPAT)?

I understand that it was hinted at in the release notes, but this is a very 
severe change in major locales - at least I was not expecting that (as opposed 
to textual changes to timezones or month names).

I am a bit burned by using compat flags as they might get removed in the futur, 
is there any plans on how long the JRE locale provider will be available, I.e. 
ist it s safe bet to use it?

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: naoto.s...@oracle.com 
Gesendet: Friday, July 31, 2020 11:24:33 PM
An: Bernd Eckenfels ; core-libs-dev 

Betreff: Re: Language locales have different calendars than country locales in 
9+

Hi Bernd,

As you pointed out, the change you see here is the result of this change
in JDK9:

https://bugs.openjdk.java.net/browse/JDK-8008577

where the default locale provider was switched to CLDR. Although we
don't describe those behavior changes in the spec (as it is regarded as
l10n changes which may differ across implementations), it was generally
noted in JDK9's release note:

---
As a result, users may see differences in locale sensitive services
behavior and/or translations. [1]
---

You can use the COMPAT provider through the java.locale.providers system
property if you need the pre-JDK9 behavior.

HTH,
Naoto

[1] https://www.oracle.com/java/technologies/javase/v9-issues-relnotes.html

On 7/31/20 1:17 PM, Bernd Eckenfels wrote:
> Hello,
>
> Just wanted to mention a thing I noticed when switching from 8 to 11. I knew 
> before that the Locale data provider has changed, and I could notice that for 
> example in the writing style for abbreviated words in dates. However 
> something I did not expect is, that the definition of Calemdars change as 
> well.
>
> Locale.GERMAN and Locale.GERMANY construct different calemdars under Java 11 
> with CLDR as opposed to Java 8 or Java 11 with compat. The most notably 
> changes are when calculating calendar weeks (min days in first week) or the 
> start of a week (Sunday vs. Monday).
>
> I haven't seen that explicitely mentioned and I also wonder if this should be 
> mentioned in the Locale JavaDoc that language locales and country locales 
> might differ severely in that aspect.
>
>
> GERMANY:
> Calendar.minDays 4 
> java.util.GregorianCalendar[time=1596218932830,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=…,firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=830,ZONE_OFFSET=360,DST_OFFSET=360]
> 11.0.1+13-LTS de_DE 2011-01-01 2010-52
>
> GERMAN
> Calendar.minDays 1 
> java.util.GregorianCalendar[time=1596218932879,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=...,firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=879,ZONE_OFFSET=360,DST_OFFSET=360]
> 11.0.1+13-LTS de2011-01-01 2011-01
>
> Sample code:
>
>  Date d = new Date(129384360L);
>
>  Locale l = Locale.GERMANY;
>
>  Calendar c = Calendar.getInstance(l);
>  System.out.println("Calendar.minDays "+ c.getMinimalDaysInFirstWeek() + 
> " " + c);
>
>  SimpleDateFormat sdf = newSimpleDateFormat("-MM-DD -ww", l);
>  System.out.printf("%s %-5s %s%n", System.getProperty("java.vm.version"), 
> l, sdf.format(d));
>
>
> --
> http://bernd.eckenfels.net
>

Re: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 6.0

[Bernd Eckenfels]

Hello,

What is the advantage of having such a narrow hashcode value space compared to 
the built in idendity hashcode? Would stocking to the object idendity not only 
reduce the footprint, but also make hash lookups faster? Without the unclear 
relationship to the op code?

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Joe 
Wang 
Gesendet: Friday, June 26, 2020 1:53:08 AM
An: Core-Libs-Dev 
Betreff: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 6.0

Hi,

Please review a fix to a BCEL regression. At issue was the addition of
hashCode() method to Instruction.java in BCEL 6.0. This hashCode()
method was implemented to return the instruction's opcode that
unfortunately is mutable. The problem hasn't showed up until the code
path led to calls to remove from a HashSet a target that has been
changed since it was added to the HashSet. The proposed patch is to make
the hashCode final/immutable.

This patch implies that a target object is considered the same one even
if its field values may have been changed. It therefore may not be
appropriate in other situations (or may cause problems). However, since
it had always had no hashCode() override before BCEL 6.0, thereby
relying on Object's identity hash code, its use case has been limited
and time-tested. It can benefit from this patch in that it provides the
same function as Object's hash code, and then serves as a reminder (to
any who might read the code) how it was used (objects considered to be
the same over the course as far as the hashCode is concerned).

JBS: https://bugs.openjdk.java.net/browse/JDK-8248348
webrevs: http://cr.openjdk.java.net/~joehw/jdk16/8248348/webrev/

Thanks,
Joe

Re: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 6.0

[Bernd Eckenfels]

It does not sound aligned if you allow to change the op code which is compared 
in equal() but remember the hashcode.

But I guess it would be best to use a IdendityHashMap if you care for the 
objects. In that case you can implement hashcode uncached and aligned with 
equals. (And not use it)

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Joe Wang 
Gesendet: Friday, June 26, 2020 8:29:41 AM
An: Bernd Eckenfels ; Core-Libs-Dev 

Betreff: Re: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 
6.0



On 6/25/2020 5:14 PM, Bernd Eckenfels wrote:
> Hello,
>
> What is the advantage of having such a narrow hashcode value space compared 
> to the built in idendity hashcode? Would stocking to the object idendity not 
> only reduce the footprint, but also make hash lookups faster? Without the 
> unclear relationship to the op code?

It's a general contract to override hashCode() when equals() is
overridden, although due to the hacky nature the later was implemented
and also the narrow scope it was applied in the (BCEL) code it didn't
provide more than the Object identity. Still, it's right to keep the
hashCode() method along with equals(), would have allowed all other
subtypes to behave correctly, and beneficial to others who may read the
code (who might wonder why it's missing). It's a bit improvement over no
hashCode().

-Joe
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: core-libs-dev  im Auftrag von Joe 
> Wang 
> Gesendet: Friday, June 26, 2020 1:53:08 AM
> An: Core-Libs-Dev 
> Betreff: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 
> 6.0
>
> Hi,
>
> Please review a fix to a BCEL regression. At issue was the addition of
> hashCode() method to Instruction.java in BCEL 6.0. This hashCode()
> method was implemented to return the instruction's opcode that
> unfortunately is mutable. The problem hasn't showed up until the code
> path led to calls to remove from a HashSet a target that has been
> changed since it was added to the HashSet. The proposed patch is to make
> the hashCode final/immutable.
>
> This patch implies that a target object is considered the same one even
> if its field values may have been changed. It therefore may not be
> appropriate in other situations (or may cause problems). However, since
> it had always had no hashCode() override before BCEL 6.0, thereby
> relying on Object's identity hash code, its use case has been limited
> and time-tested. It can benefit from this patch in that it provides the
> same function as Object's hash code, and then serves as a reminder (to
> any who might read the code) how it was used (objects considered to be
> the same over the course as far as the hashCode is concerned).
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8248348
> webrevs: http://cr.openjdk.java.net/~joehw/jdk16/8248348/webrev/
>
> Thanks,
> Joe
>

Re: JNLP

[Bernd Eckenfels]

Hello,

We ported a big JWS gui app to stand-alone swing with a home made 
installer/update mechanism. This was very easy to do (it had a main method for 
debugging anyway). The installer is not the most comfortable, but we can live 
with it since the whole application will be replaced by an web app anyway.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Thomas 
Vatter 
Gesendet: Thursday, December 10, 2020 1:12:45 PM
An: core-libs-dev@openjdk.java.net 
Betreff: JNLP

I'm using JNLP, how should I go on?

--
Network Inventory Software
IBM-Partner, RedHat- und SUSE-Partner, Oracle Technet Member

www.network-inventory.de
Tel. 030-79782510
Fax 030-79782512
E-Mail: thomas.vat...@network-inventory.de

Re: RFR: JDK-8255395 Implement Enhanced Pseudo-Random Number Generators (CSR)

[Bernd Eckenfels]

Hello,

Not sure if it is needed to implement a new RandumGenerator interface instead 
of extending SecureRandom, but the extensions and the discovery mechanism looks 
good.

One thing I am wondering about is if reseed() and reseed(Param) should be part 
of the new RandomGenerator interface as well.

BTW a lot of the random number Discovery and configuration could have been 
avoided when the actual implementation just would have been stronger and less 
blocking. The focus should be on the two old factory methods to make them 
return top quality, it’s hard enough to make everyone use them for the correct 
use case.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Jim 
Laskey 
Gesendet: Thursday, November 5, 2020 2:02:24 PM
An: core-libs-dev 
Betreff: RFR: JDK-8255395 Implement Enhanced Pseudo-Random Number Generators 
(CSR)

Please review the CSR for JEP-356 Enhanced Pseudo-Random Number Generators.

Thank you.

-- Jim

CSR: https://bugs.openjdk.java.net/browse/JDK-8255395 

JBS: https://bugs.openjdk.java.net/browse/JDK-8248862 

JEP: http://openjdk.java.net/jeps/356 

Re: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and ==

[Bernd Eckenfels]

I like the text it’s good to mix object and value identities. I would only miss 
unequal behavior of NaN in the description.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Joe 
Darcy 
Gesendet: Thursday, January 28, 2021 8:17:39 AM
An: core-libs-dev@openjdk.java.net 
Betreff: Re: RFR: JDK-8257086: Clarify differences between {Float, 
Double}.equals and ==

On Thu, 10 Dec 2020 01:32:24 GMT, Stuart Marks  wrote:

>
>
> Great, let me know if you'd like me to provide some text for any particular 
> topics in this area.

Before sending out another iteration in code, there the draft javadoc text of a 
discussion at the end of the class-level discussion of java.lang.Double:

 * Floating-point Equality, Equivalence,
 * and Comparison
 *
 * IEEE 754 floating-point values include finite nonzero values,
 * signed zeros ({@code +0.0} and {@code -0.0}), signed infinities
 * {@linkplain Double#POSITIVE_INFINITY positive infinity} and
 * {@linkplain Double#NEGATIVE_INFINITY negative infinity}), and
 * {@linkplain Double#NaN NaN} (not-a-number).
 *
 * An equivalence relation on a set of values is a boolean
 * relation on pairs of values that is reflexive, symmetric, and
 * transitive. A set can have multiple equivalence relations defined
 * for it. For example, {@link java.util.HashMap HashMap} compares
 * keys in the set of objects using the equivalence relation of {@link
 * Object#equals Object.equals} while {@link java.util.IdentityHashMap
 * IdentityHashMap} compares keys in the set of objects using the
 * equivalence relation of reference equality.
 *
 * For floating-point values to be used in data structures like
 * sets and maps, the {@linkplain Double#equals equals} or {@linkplain
 * Double#compareTo comparison} method must satisfy the usual
 * requirements of being an equivalence relation or analogous
 * requirement for comparison methods. However, surprisingly, the
 * built-in {@code ==} operation on floating-point values does
 * not implement an equivalence relation. Despite not
 * defining an equivalence relation, the semantics of the IEEE 754
 * {@code ==} operator were deliberately designed to meet other needs
 * of numerical computation. There are two exceptions where the
 * properties of an equivalence relations are not satisfied by {@code
 * ==} on floating-point values:
 *
 * 
 *
 * If {@code v1} and {@code v2} are both NaN, then {@code v1
 * == v2} has the value {@code false}. Therefore, for two NaN
 * arguments the reflexive property of an equivalence
 * relation is not satisfied by the {@code ==} operator.
 *
 * If {@code v1} represents {@code +0.0} while {@code v2}
 * represents {@code -0.0}, or vice versa, then {@code v1 == v2} has
 * the value {@code true} even though {@code +0.0} and {@code -0.0}
 * are distinguishable under various floating-point operations. For
 * example, {@code 1.0/+0.0} evaluates to positive infinity while
 * {@code 1.0/-0.0} evaluates to negative infinity and
 * positive infinity and negative infinity are neither equal to each
 * other nor equivalent to each other.
 *
 * 
 *
 * For ordered comparisons using the built-in comparison operator
 * ({@code <}, {@code <=}, etc.), NaN values have another anomalous
 * situation: a NaN is neither less than, greater than, nor equal to
 * any value, including itself. This means the trichotomy of
 * comparison does not hold.
 *
 * To provide the appropriate semantics for {@code equals} and {@code
 * compareTo} methods, those methods cannot simply to wrappers around
 * {@code ==} or ordered comparison operations. Instead, {@link
 * Double#equals equals} defines NaN arguments to be equal to each
 * other and defines {@code +0.0} to not be equal to {@code
 * -0.0}, restoring reflexivity. For comparisons, {@link
 * Double#compareTo compareTo} defines a total order where {@code
 * -0.0} is less than {@code +0.0} and where a NaN is equal to itself
 * and considered greater than positive infinity.
 *
 * The operational semantics of {@code equals} and {@code
 * compareTo} are expressed in terms of {@linkplain doubleToLongBigs
 * bit-wise converting} the floating-point values to integral values
 *
 * The natural ordering implemented by {@link compareTo
 * compareTo} is {@linkplain Comparable consistent with equals}; that
 * is values are only reported as equal by {@code equals} if {@code
 * compareTo} on those objects returns zero.
 *
 * @jls 4.2.3 Floating-Point Types, Formats, and Values
 * @jls 4.2.4. Floating-Point Operations
 * @jls 15.21.1 Numerical Equality Operators == and !=

Comments?

Thanks,

-

PR: https://git.openjdk.java.net/jdk/pull/1699

Re: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams

[Bernd Eckenfels]

Hello,

Hm, how is that list used? - StandardCharaet.ISO_8859_1 is a guaranteed Charset 
for JVM, and since the encoding is done in Java it should be fine. Added 
benefit is, it’s 8bit transparent.

As for OS there is not a single standard charset (ebcdic vs latin families) but 
ASCII is probably the widest available (with latin1 variants to follow)


--
https://Bernd.eckenfels.net

From: core-libs-dev  on behalf of Roger 
Riggs 
Sent: Thursday, May 20, 2021 10:52 PM
To: core-libs-dev@openjdk.java.net
Subject: Re: RFR: 8191441: (Process) add Readers and Writer access to 
java.lang.Process streams

On Thu, 20 May 2021 20:42:35 GMT, Naoto Sato  wrote:

>> Methods are added to java.lang.Process to read and write characters and 
>> lines from and to a spawned Process.
>> The Charset used to encode and decode characters to bytes can be specified 
>> or use the
>> operating system native encoding as is available from the "native.encoding" 
>> system property.
>
> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 64:
>
>> 62: return new Object[][] {
>> 63: {"UTF-8"},
>> 64: {"ISO8859-1"},
>
> `ISO8859-1` may not be available on all underlying OSes.

Is there a safe subset?
I haven't seen a failure yet, if/when it occurs, we make an exception or narrow 
the test to known systems.

> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 111:
>
>> 109: @Test(dataProvider = "CharsetCases", enabled = true)
>> 110: void testCase(String nativeEncoding) throws IOException {
>> 111: String osName = 
>> System.getProperty("os.name").toLowerCase(Locale.ROOT);
>
> Not used anywhere else.

Right, dead code now without host dependencies.

> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 122:
>
>> 120: "ReaderWriterTest$ChildWithCharset");
>> 121: var env = pb.environment();
>> 122: env.put("LANG", "en_US." + cleanCSName);
>
> Does this work on Windows?

Should be removed, the tests work because they set sun.stdout/stderr.encoding.

-

PR: https://git.openjdk.java.net/jdk/pull/4134

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

[Bernd Eckenfels]

Hello, sorry for being unpopular, but I just hate it to waste developer 
resources,

I realy think this deprecation message should be re-considered, it broke a lot 
of things, the amount of work to implement a caching solution feels like a 
waste of time and on top of it, there is no clear replacement strategy 
published yet.

I would restrict deprication (for removal if you really insist) to javadoc and 
not poison stdout/stderr.

I think we stirred up enough PR that a message was received by maintainers, no 
need to further damage java reputation by breaking perfectly working inter 
process interfaces. (This is btw true for all such warnings). And I also think 
top priority should be to publish a go-forward route which should not depend 
solely on MR-Jars,

Gruss
Bernd

--
http://bernd.eckenfels.net

Von: security-dev  im Auftrag von Daniel 
Fuchs 
Gesendet: Tuesday, June 29, 2021 8:50:08 PM
An: core-libs-dev@openjdk.java.net ; 
security-...@openjdk.java.net 
Betreff: Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager 
should only appear once for each caller

On Mon, 28 Jun 2021 21:09:43 GMT, Weijun Wang  wrote:

> Add a cache to record which sources have called `System::setSecurityManager` 
> and only print out warning lines once for each.

src/java.base/share/classes/java/lang/System.java line 337:

> 335: = Collections.synchronizedMap(new WeakHashMap<>());
> 336: }
> 337:

I wonder about the use of a WeakHashMap here. That may work well when the 
source is an interned string (a class name) which will be strongly referenced 
elsewhere and may be garbage collected if the class is unloaded, but in the 
case where it contains the name of the source jar then that string will only be 
referenced by the weak hashmap, and therefore it could be garbage collected any 
time - which would cause the mapping to be removed. In that case you cannot 
guarantee that the warning will be emitted only once.

-

PR: https://git.openjdk.java.net/jdk17/pull/166

Re: New candidate JEP: 400: UTF-8 by Default

[Bernd Eckenfels]

I like it. The only thing which I feel is missing would be an official API to 
get the operating environments default encoding (essentially to get the value 
used if COMPAT would have been specified).

For example, in our server application, we do have some code which is specified 
as using exactly this charset  (I.e. if user configures targetEncoding=PLATFORM 
we are using intentionally the no-arg APIs). We can change that code to specify 
a Charset, but then we need a way to retrieve that - without poking into 
unsupported system properties or environment properties. For example 
System.platformCharset().

I understand that this might have it’s own complications - as not all OS have 
this concept (for example on Windows there might be different codepages 
depending on the unicode status of an application). But falling back to today’s 
file.encoding code would at least be consistent and the behavior most 
implementer would desire when adapting legacy code to this JEP.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von 
mark.reinh...@oracle.com 
Gesendet: Thursday, March 11, 2021 1:27:05 AM
An: naoto.s...@oracle.com 
Cc: core-libs-dev@openjdk.java.net ; 
jdk-...@openjdk.java.net 
Betreff: New candidate JEP: 400: UTF-8 by Default

https://openjdk.java.net/jeps/400

  Summary: Use UTF-8 as the JDK's default charset, so that APIs that
  depend on the default charset behave consistently across all platforms
  and independently of the user’s locale and configuration.

- Mark

Re: New candidate JEP: 400: UTF-8 by Default

[Bernd Eckenfels]

Hello,

Thanks for the hint. The question is if this would return UTF-8 after the JEP 
is implemented or not (should probably be mentioned in the JEP). If it keeps 
returning the legacy/platform file encoding that would be a good API for my 
purpose (but sounds like that would be rather confusing in regards to the 
default constructor)


--
http://bernd.eckenfels.net

Von: Remi Forax 
Gesendet: Thursday, March 11, 2021 2:19:19 AM
An: Bernd Eckenfels 
Cc: core-libs-dev ; jdk-dev 

Betreff: Re: New candidate JEP: 400: UTF-8 by Default

- Mail original -
> De: "Bernd Eckenfels" 
> À: "core-libs-dev" 
> Cc: "jdk-dev" 
> Envoyé: Jeudi 11 Mars 2021 02:12:49
> Objet: Re: New candidate JEP: 400: UTF-8 by Default

> I like it. The only thing which I feel is missing would be an official API to
> get the operating environments default encoding (essentially to get the value
> used if COMPAT would have been specified).
>
> For example, in our server application, we do have some code which is 
> specified
> as using exactly this charset  (I.e. if user configures 
> targetEncoding=PLATFORM
> we are using intentionally the no-arg APIs). We can change that code to 
> specify
> a Charset, but then we need a way to retrieve that - without poking into
> unsupported system properties or environment properties. For example
> System.platformCharset().
>
> I understand that this might have it’s own complications - as not all OS have
> this concept (for example on Windows there might be different codepages
> depending on the unicode status of an application). But falling back to 
> today’s
> file.encoding code would at least be consistent and the behavior most
> implementer would desire when adapting legacy code to this JEP.

Hi,
FileReader has a method named getEncoding()

>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net

regards,
Rémi

Re: RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base module

[Bernd Eckenfels]

Hello,

Actually, in HTML  was a separator, and in xhtml it should enclose 
paragraphs. However I was under the impression Javadoc always used the 
separator style (it would be strange to start the first sentence in Javadoc 
with . Is this doccheck enforcing a new policy?

This officially Oracle guide for example has a different example:

https://www.oracle.com/de/technical-resources/articles/java/javadoc-tool.html#format

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: net-dev  im Auftrag von Jonathan Gibbons 

Gesendet: Tuesday, March 2, 2021 8:41:03 PM
An: core-libs-dev@openjdk.java.net ; 
hotspot-compiler-...@openjdk.java.net ; 
net-...@openjdk.java.net ; 
security-...@openjdk.java.net 
Betreff: RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base module

Please review some minor doc fixes, for issues found by _doccheck_.There 
are two kinds of errors that are addressed.

1. Incorrect use of ``. In HTML, `` marks the *beginning* of a paragraph. 
It is not a terminator, to mark the end of a paragraph, or a separator to mark 
the boundary between paragraphs.  In particular, it should not be used at the 
end of a description before a javadoc block tag, such as `@param` or before 
other HTML block tags, like `` or ``.

2. References to the id `package-description`, following the recent 
standardization of all ids generated by javadoc,

-

Commit messages:
 - JDK-8262875: doccheck: empty paragraphs, etc in java.base module

Changes: https://git.openjdk.java.net/jdk/pull/2795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2795=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262875
  Stats: 9 lines in 8 files changed: 0 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2795/head:pull/2795

PR: https://git.openjdk.java.net/jdk/pull/2795

Re: RFR: 8264208: Console charset API [v2]

[Bernd Eckenfels]

Hello,

I like the API, it is useful, however not enough to replace the defaultCharset 
once the Change to UTF8 is done. You still need a way to query the platforms 
file encoding (especially on Windows).

Also I wonder if the Javadoc needs to discuss platform aspects of console, 
especially System.out and LANG on unix vs. windows.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: security-dev  im Auftrag von Naoto 
Sato 
Gesendet: Friday, April 9, 2021 11:06:00 PM
An: core-libs-dev@openjdk.java.net ; 
security-...@openjdk.java.net 
Betreff: Re: RFR: 8264208: Console charset API [v2]

> Please review the changes for the subject issue.  This has been suggested in 
> a recent discussion thread for the JEP 400 
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>  A CSR has also been drafted, and comments are welcome 
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

Naoto Sato has updated the pull request incrementally with one additional 
commit since the last revision:

  Reflected the review comments.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/d6db04bb..8fd8f6e6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3419=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3419=00-01

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

PR: https://git.openjdk.java.net/jdk/pull/3419

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

[Bernd Eckenfels]

BTW it is probably not a good idea to overwrite Properties (for example to get 
a defined store order). Especially since changes in the past already broke 
this. However the attached discussion shows that people do need insert-order 
and/or alphabetical ordered properties — maybe a more general solution would 
help (and also make sure that existing implementations which subtype Properties 
and overwrite entrySet() would continue to work? After all properties is/was 
not final.

https://stackoverflow.com/questions/17011108/how-can-i-write-java-properties-in-a-defined-order

On a somewhat related note, I think if the Properties class is not 
deterministic, preserves order and comments, it’s maybe not a good 
file,creation APi for Maven anyway. What Plug-ins are affected for which 
operation?

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Roger 
Riggs 
Gesendet: Monday, August 30, 2021 5:00:14 PM
An: Jaikiran Pai ; core-libs-dev@openjdk.java.net 

Betreff: Re: Proposal: JDK-8231640 - (prop) Canonical property storage

Hi Jaikiran,

System properties, especially new ones, should be only settable on the
command line and read once.
It makes them visible to developers and avoids state-full dependencies
and concurrency issues.

Retiring system properties is quite difficult because there's no way to
know if they are still being
used or by whom.  The technique using system properties to revert to
previous behavior has
been used when API changes are unavoidable and the impact on existing
applications is not known.
It isn't a good solution but does provide a workaround when an issue is
discovered.

Better to not introduce them in the first place.


The use of SOURCE_DATE_EPOCH as proposed seems better than most, as its
definition
has a wider scope and longer expected life than most properties.

Since SOURCE_DATE_EPOCH is an environment variable, not a system
property, it will be
less visible to developers, but is already read-once at first use of any
environment variable
as per System.getenv().

$.02, Roger


On 8/28/21 12:45 AM, Jaikiran Pai wrote:
> Hello Roger,
>
> On 28/08/21 12:16 am, Roger Riggs wrote:
>> Hi,
>>
>> I'm finding the idea of removing the hardcoded timestamp and adding a
>> property to restore compatibility
>> strangely attractive.  I don't think we've yet found a case where the
>> timestamp was needed (but need to keep looking).
>> (Adding a timestamp to the comment by the caller of store() is
>> already possible)
>>
>> It will reveal where the timestamp is needed (via some kind of
>> failure, though perhaps not a timely one)
>> and includes a fallback mechanism when needed.
>>
>> It will generally cleanup up the behavior of an old API.
>> The other approaches make new work for developers based on unclear
>> requirements.
>
> So this is essentially the proposal 1d that I listed in one of my
> mails, with the added advantage of allowing users to switch back to
> the old behaviour with a system property setting. I hadn't considered
> the system property approach to switch to old behaviour in my
> proposals, so this is a very good input and I personally think the
> most logical proposals so far. One question that however remains is,
> how long (how many releases) do we support this new system property?
> The --illegal-access option (although not a system property) seems to
> be one such example where after a few releases, that option will no
> longer be supported and won't play any role. Perhaps this system
> property too will follow a similar lifetime?
>
> One other thing - I believe this new system property must be "set once
> at launch time" kind of property, whose value can be set at launch
> time and cannot be changed dynamically in the runtime. That would
> provide consistency in how the Properties class behaves globally
> within that runtime, instead of potentially behaving differently in
> different parts of the code, depending on how the callers set/reset
> the system property value before calling the "store(...)" APIs.
>
> -Jaikiran
>
>

Re: what does the spec say about file paths that are too long?

[Bernd Eckenfels]

I think what constitutes a „too long path“ is highly environment and data 
dependent. For some OS it depends on configuration, version, filesystem type, 
mount structure, encoding, canonicalisation and API used. Java would have a 
really hard time to codify this all. So the current solution „try the native 
API and report errors“ sounds like the only really useable option - not to 
mention it is also safe (you get an error no crash). There are some unfortunate 
problems like OS where the gui limits more like the OS (Explorer) or where one 
path type (UNC or DOS-Short or relative) can create longer path than later 
readable, but basically for them it’s also hard for Java to predict and forbid 
them (especially if used intentionally).

What could be done is to document this, document which functions actually use 
OS APIs and possibly and which Path And Filesystem API does or does not. And 
hopefully the IOException and native error Handling can be Unified and improved 
(for example Expose Errno/HERR return codes in IOException attribute which 
avoids to parse (localized error messages).

It’s a bit annoying but even if you want to handle it better: there is not much 
you can do if you have such a Path constructed. Limit inputs and install dirs 
and not use user provided names if your systems should be reliable.

--
https://Bernd.eckenfels.net

From: core-libs-dev  on behalf of Alan 
Snyder 
Sent: Thursday, August 26, 2021 12:12:33 AM
To: core-libs-dev 
Subject: Re: what does the spec say about file paths that are too long?

Lacking any new data, I guess it is fair to assume that there is no 
specification for the behavior of methods that use file paths that are too 
long, and presumably no tests, either.

So the next question is whether there should be such a specification.

I think there should be a specification because I would like to be able to use 
file paths without having to defend against possible unwanted bad effects when 
the paths are too long. By analogy, more like array indexing than integer 
overflow.

If there is to be a specification, should it be at the method level? That would 
be best, I think.

For example, the Path.toAbsolutePath() method in principle could return a path 
that is “too long” even if the original path is fine. Should an exception be 
raised at that point or only when the absolute path is used? This distinction 
was not possible with File, but it may be possible with Path, given the 
association with file providers.

(Regarding the comment from Alan B., is it the case that file paths are 
necessarily resolved before use? That would surprise me.)

Also, there is the possibility of creating a more specific exception to be 
thrown when paths that are too long are used.

A case can be made for distinguishing this error from general IOExceptions 
because it is repeatable and explainable, unlike the general IOException.

Thoughts?

  Alan







> On Aug 20, 2021, at 7:05 AM, Alan Snyder  wrote:
>
> Where did I say that I was seeing silent truncation?
>
> My question is about the specification.
>
> I want to know if I should write code that defends against silent truncation. 
> I should be writing code based on the specification, not what I observe in a 
> test program on a particular platform.
>
> I’m pleased that you believe an exception should be thrown, but is that 
> behavior mandated in the specification and tested by the JCK?
>
>  Alan
>
>
>> On Aug 20, 2021, at 2:58 AM, Alan Bateman  wrote:
>>
>> Where are you seeing "silent truncation"? You should see an I/O exception if 
>> you attempt to access a file and the resolved file path is too long.
>>
>> -Alan
>>
>

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v4]

[Bernd Eckenfels]

The message should probably more along the line of be „external sleep process 
terminated unexpected early“. But maybe it is better to actually fail the test 
when true is returned as it should not happen instead of diag output? (And for 
diag output the exit code would be more helpful than the time)

Gruss
Bernd

--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von David 
Holmes 
Gesendet: Donnerstag, September 16, 2021 1:01 AM
An: core-libs-dev@openjdk.java.net
Betreff: Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v4]

On Wed, 15 Sep 2021 22:36:14 GMT, Roger Riggs  wrote:

>> test/jdk/java/lang/ProcessBuilder/Basic.java line 2452:
>>
>>> 2450:
>>> 2451: if (p.waitFor(10, TimeUnit.MILLISECONDS)) {
>>> 2452: System.out.println("WaitFor didn't wait long enough: 
>>> " + (System.nanoTime() - start));
>>
>> Either the condition or the message seems wrong here. If waitFor returns 
>> true then the process has exited and we obviously did wait long enough.
>
> This code is diagnostic.
> After switching to native sleep, I had intermittent failures claiming it did 
> not sleep long enough.
> I was unable to find a specific cause for those failures.
> Many of the tests fail to check if the sleep processes terminate prematurely 
> and if the executable is not found, it never launched.

Okay but my comment still stands.

-

PR: https://git.openjdk.java.net/jdk/pull/5239

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3]

[Bernd Eckenfels]

I also wonder if it makes sense to either only serve files with public 
permissions, or at least Filter some critical files like .ssh/* and *.jks. 
Those command-line servers are often started „accidentially“ in the home 
directory.


--
http://bernd.eckenfels.net

Von: net-dev  im Auftrag von Jaikiran Pai 

Gesendet: Thursday, September 16, 2021 4:08:46 PM
An: build-...@openjdk.java.net ; 
core-libs-dev@openjdk.java.net ; 
net-...@openjdk.java.net 
Betreff: Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3]

On Thu, 16 Sep 2021 10:14:47 GMT, Julia Boes  wrote:

>> This change implements a simple web server that can be run on the 
>> command-line with `java -m jdk.httpserver`.
>>
>> This is facilitated by adding an entry point for the `jdk.httpserver` 
>> module, an implementation class whose main method is run when the above 
>> command is executed. This is the first such module entry point in the JDK.
>>
>> The server is a minimal HTTP server that serves the static files of a given 
>> directory, similar to existing alternatives on other platforms and 
>> convenient for testing, development, and debugging.
>>
>> Additionally, a small API is introduced for programmatic creation and 
>> customization.
>>
>> Testing: tier1-3.
>
> Julia Boes has updated the pull request incrementally with one additional 
> commit since the last revision:
>
>   correct path handling

src/jdk.httpserver/share/classes/module-info.java line 55:

> 53:  *  [-o none|info|verbose] [-h to show 
> options]
> 54:  *Options:
> 55:  *-b, --bind-address- Address to bind to. Default: 0.0.0.0 (all 
> interfaces).

I understand that the purpose of this simple server is for development and 
testing only. But even then, for security considerations, would it be more 
appropriate to default the bind address to a loopback address instead of making 
it accessible potentially to entire public? In the past, application servers 
which used to bind to all interfaces by default have now moved to using the 
loopback address as a default to avoid such accidental exposing of the server.

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v5]

[Bernd Eckenfels]

I like it, but I think you don’t Need the %n linebreak (at least the other fail 
message has none)


--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Roger 
Riggs 
Gesendet: Donnerstag, September 16, 2021 6:13 PM
An: core-libs-dev@openjdk.java.net
Betreff: Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v5]

> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified 
> unexpected messages from a child Java VM
> as the cause of the test failure.  Attempts to control the output of the 
> child VM have failed, the VM is unrepentant .
>
> There is no functionality in the child except to wait long enough for the 
> test to finish and the child is destroyed.
> The fix is to switch from using a Java child to using a native child; a new 
> executable `sleepmillis`.

Roger Riggs has updated the pull request incrementally with one additional 
commit since the last revision:

  Improve diagnostic message to add the exit value of the process.
  The test will fail if the process has terminated early.
  (It would have failed anyway due to too short wait).

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5239/files
  - new: https://git.openjdk.java.net/jdk/pull/5239/files/2a9c33fb..43a54802

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=5239=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5239=03-04

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5239.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5239/head:pull/5239

PR: https://git.openjdk.java.net/jdk/pull/5239

Re: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time

[Bernd Eckenfels]

Is there support for repeatable builds planned? Using the source file might be 
acceptable, but the class file timestamp could be changing more likely for 
repeated builds?


--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von 
Jaikiran Pai 
Gesendet: Monday, September 13, 2021 7:44:22 AM
An: compiler-...@openjdk.java.net ; 
core-libs-dev@openjdk.java.net 
Betreff: RFR: 8258117: jar tool sets the time stamp of module-info.class 
entries to the current time

The commit here is a potential fix for the issue noted in 
https://bugs.openjdk.java.net/browse/JDK-8258117.

The change here repurposes an existing internal interface `ModuleInfoEntry` to 
keep track of the last modified timestamp of a `module-info.class` descriptor.

This commit uses the timestamp of the `module-info.class` on the filesystem to 
set the time on the `JarEntry`. There are a couple of cases to consider here:

1. When creating a jar  (using `--create`), we use the source 
`module-info.class` from the filesystem and then add extended info to it 
(attributes like packages, module version etc...). In such cases, this patch 
will use the lastmodified timestamp from the filesystem of `module-info.class` 
even though we might end up updating/extending/modifying (for example by adding 
a module version) its content while storing it as a `JarEntry`.

2. When updating a jar (using `--update`), this patch will use the lastmodified 
timestamp of `module-info.class` either from the filesystem or from the source 
jar's entry (depending on whether a new `module-info.class` is being passed to 
the command). Here too, it's possible that we might end up 
changing/modifying/extending the `module-info.class` (for example, changing the 
module version to a new version) that gets written into the updated jar file, 
but this patch _won't_ use `System.currentTimeMillis()` even in such cases.

If we do have to track actual changes that might happen to `module-info.class` 
while extending its info (in `extendedInfoBytes()`) and then decide whether to 
use current system time as last modified time, then this will require a bigger 
change and also a discussion on what kind of extending of module-info.class 
content will require a change to the lastmodifiedtime of that entry.

-

Commit messages:
 - 8258117: jar tool sets the time stamp of module-info.class entries to the 
current time

Changes: https://git.openjdk.java.net/jdk/pull/5486/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5486=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258117
  Stats: 317 lines in 2 files changed: 298 ins; 0 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486

PR: https://git.openjdk.java.net/jdk/pull/5486

Re: (ch) InnocuousThread names

[Bernd Eckenfels]

Looking at the code some more I wonder:

  *if defaultThreadFactoty should use a Thread group for the pool or at 
least for NIO?
  *   If it can skip the security manager check and use InnocousThread in all 
cases (to avoid ThreadLocals - not sure if some encode cache is hurt by it?)

  *   If it can skip the priveledged call as IThread does that itself.

https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/nio/ch/ThreadPool.java#L76

--
http://bernd.eckenfels.net

Von: Bernd Eckenfels 
Gesendet: Sunday, October 17, 2021 4:56:17 AM
An: OpenJDK Dev list ; nio-...@openjdk.java.net 

Betreff: InnocuousThread names (was: [8u] RFR 8190482: InnocuousThread creation 
should not require the caller to possess enableContextClassLoaderOverride)

Apropos InnocousThread backporting - I Wonder if we should remove the auto 
threadname infrastructure and only create properly named threads. The generic 
name seems to be rather confusing and it seems it is only used in an NIO Pool, 
where a thread-name should be set, anyway?

https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/nio/ch/ThreadPool.java#L86

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: jdk8u-dev  im Auftrag von Zhengyu Gu 

Gesendet: Sunday, October 17, 2021 1:39:12 AM
An: Hohensee, Paul ; jdk8u-dev 
Betreff: Re: [8u] RFR 8190482: InnocuousThread creation should not require the 
caller to possess enableContextClassLoaderOverride

Thanks, Paul

-Zhengyu


On 10/15/21 17:30, Hohensee, Paul wrote:
> Lgtm.
>
> Thanks,
> Paul
>
> -Original Message-
> From: jdk8u-dev  on behalf of Zhengyu Gu 
> 
> Date: Tuesday, October 5, 2021 at 8:12 AM
> To: jdk8u-dev 
> Subject: [8u] RFR 8190482: InnocuousThread creation should not require the 
> caller to possess enableContextClassLoaderOverride
>
> This backport is for parity with Oracle 8u321.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8190482
> Webrev: http://hg.openjdk.java.net/jdk/jdk/rev/5e7cf99b1303
>
> The original patch does not apply cleanly. There is not newThread(String
> name, Runnable target) method in 8u, so discard this part of change.
>
>
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8190482-8u/webrev.00/
>
>
> Thanks,
>
> -Zhengyu
>
>

InnocuousThread names (was: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride)

[Bernd Eckenfels]

Apropos InnocousThread backporting - I Wonder if we should remove the auto 
threadname infrastructure and only create properly named threads. The generic 
name seems to be rather confusing and it seems it is only used in an NIO Pool, 
where a thread-name should be set, anyway?

https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/nio/ch/ThreadPool.java#L86

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: jdk8u-dev  im Auftrag von Zhengyu Gu 

Gesendet: Sunday, October 17, 2021 1:39:12 AM
An: Hohensee, Paul ; jdk8u-dev 
Betreff: Re: [8u] RFR 8190482: InnocuousThread creation should not require the 
caller to possess enableContextClassLoaderOverride

Thanks, Paul

-Zhengyu


On 10/15/21 17:30, Hohensee, Paul wrote:
> Lgtm.
>
> Thanks,
> Paul
>
> -Original Message-
> From: jdk8u-dev  on behalf of Zhengyu Gu 
> 
> Date: Tuesday, October 5, 2021 at 8:12 AM
> To: jdk8u-dev 
> Subject: [8u] RFR 8190482: InnocuousThread creation should not require the 
> caller to possess enableContextClassLoaderOverride
>
> This backport is for parity with Oracle 8u321.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8190482
> Webrev: http://hg.openjdk.java.net/jdk/jdk/rev/5e7cf99b1303
>
> The original patch does not apply cleanly. There is not newThread(String
> name, Runnable target) method in 8u, so discard this part of change.
>
>
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8190482-8u/webrev.00/
>
>
> Thanks,
>
> -Zhengyu
>
>

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v7]

[Bernd Eckenfels]

Just a nit, but how about:

* For all interfaces use “-b ​​​0.0.0.0“ (IPv4) or “-b ::“ (IPv6)

Instead of:

* For 0.0.0.0 (all interfaces) use -b 0.0.0.0 or -b ::0

In the usage?

(I think „::“ is canon?)

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: net-dev  im Auftrag von Daniel Fuchs 

Gesendet: Tuesday, September 28, 2021 12:20:11 PM
An: build-...@openjdk.java.net ; 
core-libs-dev@openjdk.java.net ; 
net-...@openjdk.java.net 
Betreff: Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v7]

On Tue, 28 Sep 2021 10:08:29 GMT, Julia Boes  wrote:

>> This change implements a simple web server that can be run on the 
>> command-line with `java -m jdk.httpserver`.
>>
>> This is facilitated by adding an entry point for the `jdk.httpserver` 
>> module, an implementation class whose main method is run when the above 
>> command is executed. This is the first such module entry point in the JDK.
>>
>> The server is a minimal HTTP server that serves the static files of a given 
>> directory, similar to existing alternatives on other platforms and 
>> convenient for testing, development, and debugging.
>>
>> Additionally, a small API is introduced for programmatic creation and 
>> customization.
>>
>> Testing: tier1-3.
>
> Julia Boes has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains 20 commits:
>
>  - use ipv4/ipv6 specific loopback address and add add how-to output for all 
> interfaces
>  - Merge branch 'master' into simpleserver
>  - change default bind address from anylocal to loopback
>  - address PR comments
>  - Merge branch 'master' into simpleserver
>  - Merge remote-tracking branch 'origin/simpleserver' into simpleserver
>  - Merge branch 'master' into simpleserver
>  - refactor isHidden,isReadable,isSymlink checks and cleanup tests
>  - Merge branch 'master' into simpleserver
>  - check isHidden, isSymlink, isReadable for all path segments
>  - ... and 10 more: 
> https://git.openjdk.java.net/jdk/compare/87998565...7f994476

Thanks Julia, the new changes look good to me.

-

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: Windows 10 (since Windows 10 version 1903) and Windows 11 support UTF-8 as the default codepage through an executable manifest option

[Bernd Eckenfels]

John do you know if this also switches a console window into utf8 for such a 
launcher? (And if so, also for a already open console?)

The problem will be similar to initial jep400 that some still might need to 
know the legacy ansi codepage for the OS, and I guess the new method won’t give 
us that if the manifest is changed?

--
https://Bernd.eckenfels.net

From: core-libs-dev  on behalf of Naoto 
Sato 
Sent: Monday, October 4, 2021 10:23:47 PM
To: core-libs-dev@openjdk.java.net 
Subject: Re: Windows 10 (since Windows 10 version 1903) and Windows 11 support 
UTF-8 as the default codepage through an executable manifest option

Hi John,

Please see the JEP 400, which changes the default charset to UTF-8
across platforms:

https://openjdk.java.net/jeps/400

HTH,
Naoto

On 10/4/21 8:47 AM, John Platts wrote:
> Windows 10 (since Windows 10 version 1903) and Windows 11 support UTF-8 as 
> the default codepage by setting an option in the application manifest.
>
> To enable UTF-8 as the default codepage for JDK executables on Windows 10 
> (starting with the May 2019 update) and Windows 11, the following 
> modifications can be made to the 
> src/java.base/windows/native/launcher/java.manifest file (or the 
> jdk/src/windows/resource/java.manifest in JDK 8):
>...
>
>
>   xmlns:dpi1="http://schemas.microsoft.com/SMI/2005/WindowsSettings;
> 
> xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings;
> 
> xmlns:utf8="http://schemas.microsoft.com/SMI/2019/WindowsSettings;>
>true/PM
>PerMonitorV2, PerMonitor, system
>UTF-8
>  
>
>...
>
> The GetACP() and GetOEMCP() API's will both return 65001 on Windows 10 
> Version 1903 or later if UTF-8 
> element is added to the executable manifest.
>
> GetLocaleInfo(lcid, LOCALE_IDEFAULTANSICODEPAGE, ret+2, 14) will return 
> different results from GetACP() if 
> UTF-8 is present in the executable 
> manifest, and java.nio.charset.Charset.defaultCharset() should return 
> StandardCharsets.UTF_8 on Windows platforms if GetACP() returns 65001.
>

Re: Implementing JEP 400 on Windows 10 and Windows 11

[Bernd Eckenfels]

I think the last sentence was missing a „not“ and referring to the same 
manifest?

However the results are a bit of a mess, but utf-8 handling for argv would be 
great plus (if converted correctly), right?


--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Magnus 
Ihse Bursie 
Gesendet: Tuesday, October 5, 2021 10:34:26 AM
An: John Platts ; core-libs-dev 

Betreff: Re: Implementing JEP 400 on Windows 10 and Windows 11

On 2021-10-05 03:22, John Platts wrote:
> I wrote a test program (in C++) to detect the codepages that would be 
> returned by the GetACP(), GetOEMCP(), and GetConsoleCP() functions when the 
> UTF-8 setting is added to the 
> manifest.
>
> The  manifest element (supported on Windows 10 Version 
> 1903 or later) is in the 
> http://schemas.microsoft.com/SMI/2019/WindowsSettings namespace and is added 
> to the asmv3:WindowsSettings element as shown below:
>  xmlns:dpi1="http://schemas.microsoft.com/SMI/2005/WindowsSettings;
> 
> xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings;
> 
> xmlns:utf8="http://schemas.microsoft.com/SMI/2019/WindowsSettings;>
>  true/PM
>  PerMonitorV2, PerMonitor, system
>  UTF-8
> 
>
> Here is the output of the test program without the 
> UTF-8 setting present in the 
> executable manifest:
> GetACP() result:   1252
> GetOEMCP() result: 437
> GetConsoleCP() result: 437
> System default LCID:   1033
> User default LCID: 1033
> User default UI LCID:  1033
> Codepage from system default LCID:  1252
> Codepage from user default LCID:1252
> Codepage from user default UI LCID: 1252
>
> Here is the output of the same test program with an executable manifest that 
> includes the UTF-8 setting:
> GetACP() result:   65001
> GetOEMCP() result: 65001
> GetConsoleCP() result: 437
> System default LCID:   1033
> User default LCID: 1033
> User default UI LCID:  1033
> Codepage from system default LCID:  1252
> Codepage from user default LCID:1252
> Codepage from user default UI LCID: 1252
>
> Note that the UTF-8 setting in the 
> application manifest changes the results of the GetACP() and GetOEMCP() calls 
> but not the GetConsoleCP() call.
This is really confusing. I'm glad you are gathering empirical evidence
of how it works. :-)

> I wrote another test program, and the argument strings passed into the 
> main(int argc, char** argv) function are converted to UTF-8 if the 
> UTF-8 setting is there in the 
> application manifest whereas the argument strings passed into the main (int 
> argc, char** argv) function are converted to the ANSI codepage (which is 
> usually code page 1252 on US English systems) if the 
> UTF-8 setting is there in the 
> UTF-8 manifest.

I'm not sure I understand this. What is the difference between "the
application manifest" and "the UTF-8 manifest"?

/Magnus

Re: a quick question about String

[Bernd Eckenfels]

new String() always creates a new instance.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Alan 
Snyder 
Gesendet: Thursday, December 23, 2021 6:59:18 PM
An: core-libs-dev 
Betreff: a quick question about String

Do the public constructors of String actually do what their documentation says 
(allocate a new instance), or is there some kind of compiler magic that might 
avoid allocation?

OutputStreamWriter (not) flushing stateful Charsetencoder

[Bernd Eckenfels]

(I thought this was discussed  a while back on a OpenJDK mailing list, but I 
can’t find it. So apologies if this is a duplicate, but I might have seen it on 
Apache Commons-io instead - which fixed a similar issue on reader side)

The problem: I have code using a OutputStreamWriter with a customer defined 
charset name. this writer is flushed, and the code expects all pending bytes to 
be written. However when a stateful charset like cp930 is used, this is not the 
case. The final unshift byte for example is only written when the writer is 
closed. This is probably because it does not call end of data encode on the 
encoder in the flush().

The class does not clearly say or not say what is the correct behavior, however 
the flush() is formulated in a way that one could expect it should produce a 
complete stream.

So, is this a Bug in the implementation, if not should it be added to the 
documentation?

Here is a small JShell reproducer, you see the extra unshift byte (dec 15) only 
after the close:

var b = new byte[] { 0x31, (byte)0xef, (byte)0xbc, (byte)0x91 };
var s = new String(b, "UTF-8"); // „1２“ (1 is ascii, 2 is fw)
var bos = new ByteArrayOutputStream();
var w = new OutputStreamWriter(bos, "cp930"); // stateful ebcdic with Shift 
chars
w.write(s);
w.flush();
bos.toByteArray()
$8 ==> byte[4] { -15, 14, 66, -15 }
w.close();
bos.toByteArray()
$10 ==> byte[5] { -15, 14, 66, -15, 15 }

--
http://bernd.eckenfels.net

Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v3]

[Bernd Eckenfels]

What about a new API multiply method which takes an forkjoinpool, and only if 
that is used/specified it will use the parallel mode (and only if Notsitzes 
threshold applies?). Most of the pool tuning can then done with this argument. 
It also avoids surprise threads.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von kabutz 

Gesendet: Thursday, November 18, 2021 11:41:40 AM
An: core-libs-dev@openjdk.java.net 
Betreff: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger 
[v3]

On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes  wrote:

> To add my 2c IMO a parallel version of this type absolutely **must** be 
> opt-in. There are simply far too many side-effects of using the FJP and 
> multiple threads to perform the calculation in parallel as if it is just a 
> minor implementation detail. A clear API is 1000x better than a "kill switch".
>
> And yes you may still need to expose some kind of tuning knob.
>
> David

Yes, it **must** be opt-in. However I'm not sure that a tuning knob will be 
necessary. BigInteger has thresholds for using different multiply algorithms 
and these are also not configurable.

-

PR: https://git.openjdk.java.net/jdk/pull/6409

Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v3]

[Bernd Eckenfels]

Yes but that does not help with the decision if parallel should be used or not. 
But yes, if it is generally not wanted to make the pool explicite a simple 
parallel signature without argument would also work to make the decision 
explicite (I.e. new api). That won’t automatically tune the performance but it 
does allow users to use it - majority would be crypto anyway where it can be 
used by the JCE and JSSE (maybe?).

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Remi Forax 
Gesendet: Thursday, November 18, 2021 12:16:31 PM
An: Bernd Eckenfels 
Cc: core-libs-dev 
Betreff: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger 
[v3]

- Original Message -
> From: "Bernd Eckenfels" 
> To: "core-libs-dev" 
> Sent: Jeudi 18 Novembre 2021 12:07:19
> Subject: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger 
> [v3]

> What about a new API multiply method which takes an forkjoinpool, and only if
> that is used/specified it will use the parallel mode (and only if Notsitzes
> threshold applies?). Most of the pool tuning can then done with this argument.
> It also avoids surprise threads.

You don't need it, here is the usual trick if you want to specify a specific 
fork join pool
https://stackoverflow.com/questions/21163108/custom-thread-pool-in-java-8-parallel-stream

>
> Gruss
> Bernd

regards,
Rémi

> --
> http://bernd.eckenfels.net
> 
> Von: core-libs-dev  im Auftrag von kabutz
> 
> Gesendet: Thursday, November 18, 2021 11:41:40 AM
> An: core-libs-dev@openjdk.java.net 
> Betreff: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
> [v3]
>
> On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes  wrote:
>
>> To add my 2c IMO a parallel version of this type absolutely **must** be 
>> opt-in.
>> There are simply far too many side-effects of using the FJP and multiple
>> threads to perform the calculation in parallel as if it is just a minor
>> implementation detail. A clear API is 1000x better than a "kill switch".
>>
>> And yes you may still need to expose some kind of tuning knob.
>>
>> David
>
> Yes, it **must** be opt-in. However I'm not sure that a tuning knob will be
> necessary. BigInteger has thresholds for using different multiply algorithms
> and these are also not configurable.
>
> -
>
> PR: https://git.openjdk.java.net/jdk/pull/6409

Re: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream [v8]

[Bernd Eckenfels]

Hello,

> So although you can transfer the contents to the file without requiring the 
> access
> to the byte array, you end up creating a new copy of that array (through the 
> use
> of `baos.toByteArray()`)

You can avoid the copy and the additional buffer with baos.writeTo() I think.

try (OutputStream os = Files.newOutputStream(entry.file)) { // maybe append?
baos.writeTo(os);
}
// release the underlying byte array
baos = null;
// append any further data to the file with buffering enabled
tmpFileOS = new BufferedOutputStream(Files.newOutputStream(entry.file, APPEND));


--
http://bernd.eckenfels.net

Von: nio-dev  im Auftrag von Jaikiran Pai 

Gesendet: Thursday, July 22, 2021 2:55:46 PM
An: core-libs-dev@openjdk.java.net ; 
nio-...@openjdk.java.net 
Betreff: Re: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) 
leads to a negative initial size for ByteArrayOutputStream [v8]

On Wed, 21 Jul 2021 04:09:23 GMT, Jaikiran Pai  wrote:

> > > For some context - the new `FileRolloverOutputStream` extends 
> > > `ByteArrayOutputStream` and hence cannot have a `throws IOException` in 
> > > its overridden `write` methods.
> >
> >
> > Have you tried wrapping a BAOS rather than extending, that might allow the 
> > exception wrapping/unwapping to go away.
>
> Hello Alan,
>
> I did experiment with it earlier, before going with the current approach in 
> this PR. The disadvantage, as I see it, with wrapping a 
> `ByteArrayOutputStream` instead of extending it is that when trying to 
> rollover the contents to a file, you don't have access to the (inner 
> protected) byte array of the ByteArrayOutputStream.
>
> The rollover code would then look something like:
>
> ```
> private void transferToFile() throws IOException {
> // create a tempfile
> entry.file = getTempPathForEntry(null);
> // transfer the already written data from the byte array buffer into this 
> tempfile
> try (OutputStream os = new 
> BufferedOutputStream(Files.newOutputStream(entry.file))) {
> new ByteArrayInputStream(baos.toByteArray(), 0, 
> baos.size()).transferTo(os);
> }
> // release the underlying byte array
> baos = null;
> // append any further data to the file with buffering enabled
> tmpFileOS = new BufferedOutputStream(Files.newOutputStream(entry.file, 
> APPEND));
> }
> ```
>
> So although you can transfer the contents to the file without requiring the 
> access to the byte array, you end up creating a new copy of that array 
> (through the use of `baos.toByteArray()`), which can be at most 10MB in size. 
> I thought avoiding a new copy of that (potentially 10MB) array during this 
> transfer would be a good save and hence decided to settle on extending 
> `ByteArrayOutputStream` instead of wrapping it.
>
> The use of `extends` of course now means dealing with the 
> `UncheckedIOException` as done in this PR. But if you think that the array 
> copy isn't a concern and wrapping the `ByteArrayOutputStream` is a better 
> way, then I'll go ahead and update this PR accordingly.

Now that the mailing lists integration seems to be back to normal, just adding 
this dummy comment to bring to attention the latest comments in this PR.

-

PR: https://git.openjdk.java.net/jdk/pull/4607

Re: RFR: 8266936: Add a finalization JFR event [v4]

[Bernd Eckenfels]

Hello,

I know I am a bit late, but just wanted to mention, that since finding 
finalizers with Bytecode analysis is doable (and probably easier to deal with 
such scan reports), I don’t see much value in a JFR event, especially 
considering it even has native code executed. (Not so sure about dynamically 
loaded classes, would the event content help to identify sources?)

Having said that, this event would be more useful from a runtime perspective if 
It would actually record execution counts and time per class. Then one can 
concentrate on the worst offenders, first and even use it for runtime 
monitoring. Is there already a finalizer profiler?

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Markus 
Grönlund 
Gesendet: Tuesday, July 27, 2021 5:14:29 PM
An: core-libs-dev@openjdk.java.net ; 
hotspot-jfr-...@openjdk.java.net 
Betreff: Re: RFR: 8266936: Add a finalization JFR event [v4]

> Greetings,
>
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to 
> replace and mitigate Object.finalize() uses in the JDK libraries; please see 
> https://bugs.openjdk.java.net/browse/JDK-8253568 for more information.
>
> We also like to assist users in replacing and mitigating uses in non-JDK code.
>
> Hence, this changeset adds a periodic JFR event to help identify which 
> classes are overriding Object.finalize().
>
> Thanks
> Markus

Markus Grönlund has updated the pull request incrementally with one additional 
commit since the last revision:

  remove build directive

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4731/files
  - new: https://git.openjdk.java.net/jdk/pull/4731/files/58fc3f0a..44988036

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4731=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4731=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731

PR: https://git.openjdk.java.net/jdk/pull/4731

Re: RFR: 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure

[Bernd Eckenfels]

Should probably explain why it removes the private modifier?

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Сергей 
Цыпанов 
Gesendet: Saturday, March 5, 2022 2:14:20 PM
An: core-libs-dev@openjdk.java.net 
Betreff: RFR: 8282701: Use Class.getInterfaces(false) where possible to reduce 
allocation pressure

`Class.getInterfaces(false)` does not clone underlying array and can be used in 
cases when the returned array is only read from.

-

Commit messages:
 - 8282701: Use Class.getInterfaces(false) where possible to reduce allocation 
pressure

Changes: https://git.openjdk.java.net/jdk/pull/7714/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7714=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282701
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7714.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7714/head:pull/7714

PR: https://git.openjdk.java.net/jdk/pull/7714

Re: Discussion about Java Floating Point?

[Bernd Eckenfels]

Please stop sending mails marked as urgent to a mailing list, you just make a 
fool of yourself.

The need to round floating point numbers for commercial math (and the risk 
involved in doing so) is nothing new, it predates the IEEE standard and should 
be subject for even basic comp sci curriculums all over the world.

(Having said that, automatic precision/rounding for number formats in C++ looks 
neat)

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von A Z 

Gesendet: Dienstag, März 15, 2022 5:24 AM
An: core-libs-dev@openjdk.java.net 
Betreff: Discussion about Java Floating Point?

To core-libs-dev@openjdk.java.net,

In terms of floating point, it seems there are thus
three (3) phenomena that are relevant.

1) Arithmetic on float and double, via operators.
2) Elementary function calls, namely
   those made from java.lang.StrictMath, as it is,
   on double values.
3) Comparison operators.  ==, !=, >, <, >=,<=.

Java floating point successfully has 3) the way required,
even though other languages, particularly C++ , do not
compare their floats and doubles through those comparison
operators.  The point at issue is Java although, so Java is
satisfactory at point 3).

My point of contention is that Java does not have 1) and 2)
operating as they should, even though C++ and other
languages do, in those two areas, namely C++:

Martin has submitted the following:
?The following statement is not entirely true when using finite floating
point precision:

> (?snip?) It is a mathematical fact that, for
> consistent, necessary and even fast term, 10% of 10% must
> always precisely be 1%, and by no means anything else."
/*
#include 

using namespace std;

int main()
{
cout << "Program has started..." << endl;
double a = 0.1D;
double b = 0.1D;
double c = a*b;
cout << endl << c << endl << endl;
float d = 0.1F;
float e = 0.1F;
float f = d*e;
cout << f << endl << endl;
cout << "Program has Finished.";
return 0;
}
*/
/*
Program has started...

0.01

0.01

Program has Finished.
*/

This is actually not fully or finally true, including SSE, SSE algorithm logic 
and further.
The included C++ example of mine above here disproves this.  Even though I do
contextually admit these answers can only work within the range of the
involved types, it is still actually the case that 10% of 10% can and always
precisely be 1%, within the range of the type used, and by no means
anything else.  Because of the laws of decimal arithmetic.

See https://en.wikipedia.org/wiki/Floating-point_arithmetic
and the starting sentence:

'In computing, floating-point arithmetic (FP) is arithmetic using formulaic
representation of real numbers as an approximation to support a
trade-off betwee range and precision.'

However, it simply isn't the case that reduced precision has to exist inside
the range, certainly not any more.  Rationally, one would have to think,
with the present SSE support in ubiquity, and the preimplementation
that is possible and already around elsewhere, that this kind of tradeoff
in floating point isn't any kind of use or advantage any more.

This is part of the issue with Java and the OpenJDK at this time, and I am 
trying
to contend that this should be changed, either at default or in
some mutual compatibility mode.  The other part is java.lang.StrictMath,
since it generates denormal and pronormal values on its own, also.

Raffaello has stated:
To summarize, Java uses IEEE 754 binary arithmetic as by specification,
as do most other languages, including C/C++. It is however fundamentally
wrong to use binary floating-point arithmetic to emulate decimal
behavior. Also, pay attention to the output routines that convert float
and double values to a decimal representation. Usually, C and C++ will
have information loss by default, as in your case.
What we and others are beginning to need to happen, in detailed Java 2D
and 3D (JMonkeyEngine 3.5) projects, and more widely again, is that Java
floating point arithmetic and function behaviour, on float and double,
within their ranges, do need to perfectly match decimal behaviour.

C++ arithmetic, at least, has had no problem using floating point arithmetic,
at least, to emulate decimal behaviour.  I am trying to prove the opposite to
Raffaello's statements, that floating point can and indeed must represent 
decimal behaviour.
Output functions in any language that alter the appearance of the float or 
double
value become irrelevant, because the only relevant factor is the operator 
behaviour
and the innate, representation viewpoint of those float or double values.

In contrast to Raffaelo, we assert that Java SE and OpenJDK floating point must 
be changed
so that it upholds base ten (10) arithmetic, algebra,and elementary functions 
on real value
arguments within the ranges of double and/or float.  Alongside a calculator 
class that upholds
the same.  These are in keeping with the Wikipedia 

Re: Should System.exit be controlled by a Scope Local?

[Bernd Eckenfels]

Alternatively you can make this “first setter wins” (either globally or per 
thread), then you don’t have to care or check from where the call is coming. 
Could be even integrated with a system property similar to the 
securitymanager=allow.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Kasper 
Nielsen 
Gesendet: Monday, February 28, 2022 9:23:11 PM
An: Ethan McCue 
Cc: core-libs-dev 
Betreff: Re: Should System.exit be controlled by a Scope Local?

Is there really a need to make this so complicated?

In all the examples I've seen so far it would be fine to set
system-exit restrictions up from the program's main class.
So why not just restrict it to the main class by default?
I assume this class is under the control of the user or
an IDE/Application Server.

Add this method to java.lang.Runtime

void restrictExit(MethodHandles.Lookup lookup, IntConsumer interceptor) {
  if (lookup.lookupClass() != "JAVA_MAIN_CLASS" ||
!lookup.hasFullPrivilegeAccess())
{
 throw new IllegalArgumentException("Invalid Lookup class");
  }
  ...
  Register interceptor to be called before System.exit
  ...
}

People could then call it, for example, from a static initializer block in
the
Main class. And use scope locals or whatever they want.

static {
  Runtime.restrictExit(MethodHandles.lookup(), ...)
}

Ideally, everyone would be using the module system, And we would have some
kind
of "application module" concept, which would be the module containing the
program's entry point. And which could have these special permissions by
default.
It might even be possible to delegate permissions to other modules if
needed.

/Kasper

On Sat, 26 Feb 2022 at 22:27, Ethan McCue  wrote:

> I have a feeling this has been considered and I might just be articulating
> the obvious - but:
>
> As called out in JEP 411, one of the remaining legitimate uses of the
> Security Manager is to intercept calls to System.exit. This seems like a
> decent use case for the Scope Local mechanism.
>
>
>

Re: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes

[Bernd Eckenfels]

Hello,

Not sure how often skip is actually used so it might not matter, but this 
change would increase allocations if skip is called regularly. Not sure if EA 
can prevent that if it is only medium hot and therefore the callsite is not 
compiled or inlined?

An alternative would be to make this static and/or allocate lazy (or even share 
it with more places which need a write-only array?)

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Lance 
Andersen 
Gesendet: Sunday, March 20, 2022 11:51:23 AM
An: core-libs-dev@openjdk.java.net 
Betreff: Re: RFR: 8283411: InflaterInputStream holds on to a temporary byte 
array of 512 bytes

On Sun, 20 Mar 2022 04:24:07 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which handles 
> https://bugs.openjdk.java.net/browse/JDK-8283411?
>
> The commit here moves the temporary byte array from being a member of the 
> class to a local variable within the `skip` method which is the only place 
> where it is used as a temporary buffer.
>
> tier1, tier2, tier3 tests have been run successfully with this change.

Hi Jaikiran,

This looks fine.  Please add the label noreg-trivial to the bug otherwise you 
will get a ping as there is no test associated with the PR

-

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7875

Re: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes

[Bernd Eckenfels]

I wonder should the CSR not describe what’s the advantage of this change is and 
what the compatibility problems are and why they don’t apply here? Especially 
given the fact that the specific sub exceptions are not sealed I wonder if the 
risk of breaking existing code is worth it? (But I do see the beauty of such a 
construct for new code!)

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von 
Jaikiran Pai 
Gesendet: Friday, March 25, 2022 10:27:40 AM
An: core-libs-dev@openjdk.java.net 
Betreff: Re: RFR: JDK-8283668: Update IllegalFormatException to use sealed 
classes

On Fri, 25 Mar 2022 04:17:57 GMT, Joe Darcy  wrote:

> Working down the list of candidates to be sealed, this time 
> IllegalFormatException.
>
> Please also review the companion CSR: 
> https://bugs.openjdk.java.net/browse/JDK-8283669

Marked as reviewed by jpai (Committer).

-

PR: https://git.openjdk.java.net/jdk/pull/7950

Re: fast way to infer caller

[Bernd Eckenfels]

Some loggers do need to find the location of the log statement (class and line 
where the logger is used not where it is instantiated).

 for those (it makes loggers more useful) getting the call site is time 
critical even if they are not in tight performance critical loops.

But it actually does matter if/how the JVM optimizes such introspection.. if 
the JVM can inline (and maybe even constant intrinsic) the stalkwalker it would 
benefit such use cases just as well.

--
https://bernd.eckenfels.net

From: core-libs-dev  on behalf of Michael 
Kuhlmann 
Sent: Thursday, April 7, 2022 7:55:16 PM
To: core-libs-dev@openjdk.java.net 
Subject: Re: fast way to infer caller



On 4/7/22 19:27, Kasper Nielsen wrote:
>>
>> nope, see my previous mail to Ceki, the VM is cheating here if it can
>> inline the call to MethodHandles.lookup()
>>
>
> Does how the VM cheats really matter? The fact is that the code in the JDK
> can
> get the calling class and implement something like MethodHandles.lookup() so
> it takes ~3 ns. If you implemented something like a lookup class as a normal
> user your best bet would be StackWalker.GetCallingClass() and you would end
> up with something that is at least 2 magnitudes slower. That is probably not
> an issue for most use cases. But for some, it might be a bit of a steep
> cost.
>
> /Kasper

Hi Kasper,

sorry to jump in here as an uninvolved onlooker, but I can't resist.
I really don't see why this should matter. Getting the caller class is a
rare edge case that you just do in exceptional situations; most often
it's more for debugging or something.

What users really are interested in is high performance for standard
cases. Implementing a specific optimization into Hotspot to gain few
milliseconds is the least thing I expect from the JVM developers.

I also don't understand why someone should instantiate a logger during
performance critical procedures. In more than 20 years of Java
development, I've never seen the need to create a logger on the fly.
They are *always* assigned to final static variables, or at least to
predefined pools. Everything else would be just wrong: To instantiate a
logger, you have to fetch at least the log level definition from some
configuration source, and this can never be fast. At least not that
we're talking about nanoseconds here.

All logging implementations I know of (and all that make sense) are
highly optimized on log throughput; this can only be achieved by
preprocessing during initialization, why this is slow. But that doesn't
matter, because, as said, you should anyway create logger instances
beforehand.

Sorry for the rant, but I really don't see the use case here.

Re: RFR: 8285445: cannot open file "NUL:"

[Bernd Eckenfels]

Is that really a needed fix?  enabling ADS and less strict parsing might 
introduce vulnerability but on the other hand NUL: should be allowed for it is 
a drive style not a ADS.

I would also think the number of users who want use NUL: is smaller than the 
number of users who benefit from ADS being forbidden. Especially since \\.\NUL 
or NUL should already work.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Brian 
Burkhalter 
Gesendet: Saturday, April 23, 2022 3:20:02 AM
An: core-libs-dev@openjdk.java.net 
Betreff: RFR: 8285445: cannot open file "NUL:"

Change the default value of the `jdk.io.File.enableADS` property to `true`.

-

Commit messages:
 - 8285445: cannot open file "NUL:"

Changes: https://git.openjdk.java.net/jdk/pull/8373/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8373=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285445
  Stats: 57 lines in 2 files changed: 52 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8373/head:pull/8373

PR: https://git.openjdk.java.net/jdk/pull/8373

Zlib update

[Bernd Eckenfels]

Since the new upstream version for zlib 1.2.12 is available since 4 weeks and I 
don’t see them in GitHub (not even after April cpu merges) I wonder when is an 
update planned?

(I also noticed at least one vendor claims to have a zlib fix, I am not yet 
sure if this is a vendor specific thing)

If the system zlib on Linux is used, can OS updates to zlib be applied, is this 
compatible?

Gruss
Bernd
--
http://bernd.eckenfels.net

Regression after April Java 17 Update (mime types)

[Bernd Eckenfels]

Hello,

We just tried to push out the Java 17 April Update but it failed with some 
incompatible behavior. We found out it is caused due to a new mime-type (and a 
bug in Apache VFS) that JAR files could no longer be opened in an overlay 
(technically a JAR URL suddenly had a mime-type and therefore VFS no longer 
looked at the file extension).

Just wanted to give a heads up in case anybody else has that problem. The 
change 8273655 (a backport 828109) was not mentioned in the 17.0.3 release 
notes (it is also in 11.0.16) from Oracle and Azul - will it show up in the 
OpenJDK announcement?

This specific case is a changed behavior (even when it has rather unexpected 
negative consequences), it would be therefore good to be called out 
specifically.

Gruss
Bernd


--
http://bernd.eckenfels.net

Re: Regression after April Java 17 Update (mime types)

[Bernd Eckenfels]

Hello Christoph,

The actual release notes I initially looked up are the April  Release notes 
from Azul (17.34) for 17.0.3. I already opened a case there. However I then 
also checked the Oracle Release Notes (I thought they would contain the same 
17.0.3 changes).

The incompatibility in VFS was actually a shortcoming in VFS: if you want to 
determine who can handle a file type it would check the mime type or the 
extension. But it was coded in a way that if it has a mime type but no handler 
for that type it won’t check for the file extension. This way it could no 
longer browser URLs ending in .jar or uncompres .go files (or generally all 
files where there was previously only a file extension handler registered).

I would asume this negative consequences is hard to predict, especially since 
VFS could in this case prevemt it. However for an application it is unfortunate 
that this breaks (especially when hoping to ship a quarterly security update 
quickly). Bit generally it’s a noteworthy new feature.

Thanks for the reminder of the Shipilev release notes, I did actually not check 
them after looking at two vendors (and not finding a Release announcement mail 
like there was one for 17.0.2. Can I asume those are no longer sent after X.0.2 
is published? I guess my comment to „not including it in the release notes“ was 
not valid for the OpenJDK Updates project and I will take it up with Azul to 
check the source they are using.

If you want to look deeper into this:

The VFS logic might be a bit hard to follow, it basically works on URLs and it 
has a filesystem layering mode which checks on mime type and/or extension: 
https://issues.apache.org/jira/browse/VFS-770
This is the actual fix commit for it: 
https://github.com/apache/commons-vfs/commit/f3b7a06f28aab2db829806e0e857c05b71a14305
It is retrieving the contentType for a URL here 
https://github.com/apache/commons-vfs/blob/64da24778ea075ffc5de8588a29a0f50c6c8d94e/commons-vfs2/src/main/java/org/apache/commons/vfs2/impl/FileContentInfoFilenameFactory.java#L41

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Langer, Christoph 
Gesendet: Tuesday, April 26, 2022 5:18:38 PM
An: Bernd Eckenfels ; jdk-updates-...@openjdk.java.net 

Cc: core-libs-dev 
Betreff: RE: Regression after April Java 17 Update (mime types)

Hi Bernd,

I just noticed your report regarding the regression after JDK-8273655. I'm 
directing this communication to jdk-updates-dev now as it seems more 
appropriate.

I assume with release notes you're referring to the Oracle 17.0.3 release 
notes? This change, if you look closely at the backports, was only brought to 
OpenJDK 17.0.3 and it will hit the OpenJDK 11u update 11.0.16 in July. So, it 
would not be reflected in Oracle release notes. The best you can get for 
OpenJDK 17.0.3 release notes is [0], to my knowledge.

Do you have some more information regarding the incompatibility? What I'm 
understanding is that this backport unveils a problem with Apache VFS? Do you 
have a bug link for that one? If it's just uncovering a bug in another 3rd 
party software, I assume it doesn't merit a backout, though.

Best regards
Christoph

[0] https://builds.shipilev.net/backports-monitor/release-notes-17.0.3.html


> -Original Message-
> From: core-libs-dev  On Behalf Of Bernd
> Eckenfels
> Sent: Montag, 25. April 2022 19:39
> To: core-libs-dev 
> Subject: Regression after April Java 17 Update (mime types)
>
> Hello,
>
> We just tried to push out the Java 17 April Update but it failed with some
> incompatible behavior. We found out it is caused due to a new mime-type (and
> a bug in Apache VFS) that JAR files could no longer be opened in an overlay
> (technically a JAR URL suddenly had a mime-type and therefore VFS no longer
> looked at the file extension).
>
> Just wanted to give a heads up in case anybody else has that problem. The
> change 8273655 (a backport 828109) was not mentioned in the 17.0.3 release
> notes (it is also in 11.0.16) from Oracle and Azul - will it show up in the
> OpenJDK announcement?
>
> This specific case is a changed behavior (even when it has rather unexpected
> negative consequences), it would be therefore good to be called out
> specifically.
>
> Gruss
> Bernd
>
>
> --
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbernd.eck
> enfels.net%2Fdata=05%7C01%7Cchristoph.langer%40sap.com%7C9ca8f
> 2471e24471c3d8308da26e286b1%7C42f7676cf455423c82f6dc2d99791af7%7
> C0%7C0%7C637865052069446373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7Csdata=J3kfVCvkDUH9UxiRqkoS9g9o85nB46ksbpUF5HihRP8
> %3Dreserved=0

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v3]

[Bernd Eckenfels]

The change does not seem to be related to your description, and the description 
does not match the shown exception. In fact the example stacktrace contains the 
authority value twice and your change adds a diagnostic which is not really 
helpful for the case of the underscore? I would not be too specific for such 
general parsing rules.


--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von 
Matthias Baesken 
Gesendet: Tuesday, June 14, 2022 1:36:36 PM
An: core-libs-dev@openjdk.java.net ; 
security-...@openjdk.java.net 
Betreff: Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat 
[v3]

> When trying to construct an LdapURL object with a bad input string (in this 
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run 
> into the exception below :
>
> import com.sun.jndi.ldap.LdapURL;
>  
> String url = "ldap://ad_jbs.ttt.net:389/xyz;; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
>
>
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: 
> ldap://ad_jbs.ttt.net:389/xyz [Root exception is 
> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: 
> ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
>
> I would like to add the host and port info to the exception (in the example 
> it is host:port of URI:null:-1] ) so that it is directly visible that the 
> input caused the construction of a URI
> with "special"/problematic host and port values.

Matthias Baesken has updated the pull request incrementally with one additional 
commit since the last revision:

  fix copy paste error

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9126/files
  - new: https://git.openjdk.org/jdk/pull/9126/files/1050c724..bdbe2204

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=9126=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9126=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9126/head:pull/9126

PR: https://git.openjdk.org/jdk/pull/9126

Re: RFR: 8284638: store skip buffers in InputStream Object [v2]

[Bernd Eckenfels]

If you consider doing benchmarks in detail maybe consider a static buffer, too? 
(Especially if it can be used in multiple implementations?)

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von 
XenoAmess 
Gesendet: Wednesday, April 13, 2022 11:58:06 PM
An: core-libs-dev@openjdk.java.net 
Betreff: Re: RFR: 8284638: store skip buffers in InputStream Object [v2]

On Wed, 13 Apr 2022 16:02:10 GMT, Alan Bateman  wrote:

>>> @AlanBateman You are correct about this. But I wonder if this be a problem, 
>>> why Reader class can afford store a skip buffer for each Reader.
>>>
>>> Is there anything different in the situations about skipBuffer in Reader 
>>> and InputStream?
>>
>> Maybe the skip buffer in Reader should be looked at too, esp. as it 
>> couldpotentially grow to 16k bytes. The concern with changing 
>> InputStream.skip is that there may be a lot more input streams than readers 
>> in use, esp. if there is an input stream for every socket connection.
>
>> @AlanBateman Is the concern about holding more memory sufficient to retain 
>> the buffer using a SoftReference so it can be freed eagerly?
>> These buffers are never read from, so are quite a waste, but at least they 
>> are only used when
>> the underlying stream overrides skip.
>
> Maybe but I think it needs some benchmarks to know if caching a byte[] will 
> help or just bloat memory. If the InputStream is to a file or socket then 
> maybe skip is dominated by the I/O rather than the array allocation and 
> zero'ing.

@AlanBateman jmh test added

-

PR: https://git.openjdk.java.net/jdk/pull/5872

Re: RFR: 8284932: [Vector API] Incorrect implementation of LSHR operator for negative byte/short elements

[Bernd Eckenfels]

Hello,

Maybe offer operations which can do all variants (shift, roll, signed/unsigned) 
- maybe even with support for byte/int conversion? Any of those bit fiddling 
activities in a pipeline can benefit from vectoring.

And also, the Javadoc can list the equivalent operator based code and maybe bit 
pattern examples for all overflow cases.

And also.. the unit tests can double as snipped code.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Jie Fu 

Gesendet: Monday, April 18, 2022 3:51:40 AM
An: core-libs-dev@openjdk.java.net ; 
hotspot-compiler-...@openjdk.java.net 
Betreff: Re: RFR: 8284932: [Vector API] Incorrect implementation of LSHR 
operator for negative byte/short elements

On Sun, 17 Apr 2022 23:53:49 GMT, Quan Anh Mai  wrote:

> According to JLS section 5.8, any operand in a numeric arithmetic context 
> undergoes a promotion to int, long, float or double and the operation is only 
> defined for values of the promoted types. This means that `>>>` is not 
> defined for byte/short values and the real behaviour here is that `src[i]` 
> get promoted to int by a signed cast before entering the unsigned shift 
> operation. This is different from `VectorOperators.LSHR` which is defined for 
> byte/short element types. The scalar code does not do a byte unsigned shift 
> but an int unsigned shift between a promotion and a narrowing cast, the 
> explicit cast `(byte)` notifies the user of this behaviour.

I can't understand why people can't use `>>>` for negative bytes/shorts.
 - Does the spec forbidden this usage?
 - Is there any compile error?
 - Is there any runtime error?
 - Is the behavior to be undefined?

The JLS you mentioned actually defines how to compute `>>>` for bytes/shorts in 
Java, which applies to both positive and negative bytes/shorts.
 - First, it gets promoted.
 - Then, do something else.

So I disagree with you if the JLS spec doesn't say people are not allowed to 
use `>>>` for negative bytes/shorts.




>
> Secondly, consistency is the key, having a byte unsigned shift promoting 
> elements to ints is not consistent, I can argue why aren't int elements being 
> promoted to longs, or longs being promoted to the 128-bit integral type, too.
>


Well, this kind of behavior was specified by the Java spec rules many years ago.
We have to just follow these rules if you can't change the specs.


> Finally, as I have mentioned in #7979, this usage of unsigned shift seems 
> more likely to be a bug than an intended behaviour, so we should not bother 
> to optimise this pattern.

Since the behavior of shift operations is clearly defined by the Java specs and 
supported by the language, how do you know there is no one to use it intendedly?

-

PR: https://git.openjdk.java.net/jdk/pull/8276