Hi,
Bug: https://bugs.openjdk.java.net/browse/JDK-8248910
Webrev: http://cr.openjdk.java.net/~fyang/8248910/webrev.00/
The overall procedure is described by the newly add test.
For a slice from a ByteBuffer, it does not have a cleaner, which leads to
the NPE.
Here, I thinks
Alexander,
We probably need a clean separation of logging from error reporting as
Andy pointed out in his comment. I don't think having timestamps only in
verbose output is a good idea.
Besides at some point we might will use java.util.logging.Logger instead
of jdk.incubator.jpackage.internal.
I agree - but I would rather then that Log.error() never show timestamp.
It would be better still if we could differentiate fatal error messages
from warning messages - right now we are using Log.error for both.
/Andy
On 7/7/2020 6:51 PM, alexander.matv...@oracle.com wrote:
Hi Andy,
Timest
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8248695
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8248695/webrev.00/
There were two causes that resulted in throwing exceptions. One was that
the Host adapter for Windo
Hi Andy,
Timestamps for error message without verbose output are meaningless in
my opinion. This is why I did not add them. Also, in some cases output
does not look right. For example when timestamp is added to error
message always:
jpackage --someoption
WARNING: Using incubator modules: jdk.
- Mail original -
> De: "Paul Sandoz"
> À: "Remi Forax"
> Cc: "Peter Levart" , "Patrick Concannon"
> , "Julia Boes"
> , "core-libs-dev"
> Envoyé: Mardi 7 Juillet 2020 21:04:09
> Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more
> amenable to pushing’
> Hi Remi,
>
Hi Anthony,
It's a good point.
You're correct in saying that `Stream.Builder` is a superset of `Consumer`,
however `Stream.Builder`'s usual usage is in the creation of new streams. To
use it in this context brings with it the connotation that we are going to
create a new stream, something we
Hi Remi,
I stress again that the short-circuiting optimizations are an implementation
detail that are partially applied. The behavior is not specified. It's already
inconsistent.
We might be able to improve on certain cases, as in Peter’s example, and apply
an optimization consistently for fl
At the same time,
mapMulti and flatMap are two sides of the same coins,
flatMap uses a pull API while mapMulti uses a push API.
so having mapMulti and flatMap doing cancellation differently is inconsistent.
Consistency is a good way to avoid to expect that all operations do
short-circuiting opti
Looks good!
- Alexey
On 7/7/2020 12:45 PM, Andy Herrick wrote:
looks good.
/Andy
On 7/6/2020 7:35 PM, alexander.matv...@oracle.com wrote:
Please review the jpackage fix for bug [1] at [2].
Substituted old File APIs with Path/Files APIs when it was possible
and makes sense.
[1] https://bu
Hi Peter,
You guessed correctly about the motivation from the API perspective.
I would like to stress that short-circuiting optimizations are an
implementation detail that are only partially applied. Surfacing the notion of
cooperative cancellation for one operation has quite a cost, and will l
Hi,
I will not comment on the changes to libfdlibm/k_standard.c
Concerning NetworkInterface.c I believe the proposed changes are
incorrect - and I do not see the issue with the current code.
> +if (sizeof(if2.ifr_name) < sizeof(name)) {
> +return -1;
> +}
If I'm not mistaken `s
looks good.
/Andy
On 7/6/2020 7:35 PM, alexander.matv...@oracle.com wrote:
Please review the jpackage fix for bug [1] at [2].
Substituted old File APIs with Path/Files APIs when it was possible
and makes sense.
[1] https://bugs.openjdk.java.net/browse/JDK-8223955
[2] http://cr.openjdk.java.
Hello Sean,
Thank you for review.
You are right, we can eliminate requirements for connection timeout property.
I’ve added handshakeComletedListener to the LDAP over SSl. In this case we’ll
have no possible performance impact caused by synchronous handshake.
Also, it allows to exclude changes in
> On Jul 7, 2020, at 9:59 AM, Erik Joelsson wrote:
>
> Doc changes look good.
>
> /Erik
>
> On 2020-07-06 18:10, Kim Barrett wrote:
>> I just noticed that doc/building.{md,html} describes minimum toolchain
>> versions,
>> so also needs to be updated. Here’s the update, matching what’s now in
This is in response to
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067571.html
Hi,
Your fix looks good to me.
Thanks
-Sundar
Doc changes look good.
/Erik
On 2020-07-06 18:10, Kim Barrett wrote:
I just noticed that doc/building.{md,html} describes minimum toolchain versions,
so also needs to be updated. Here’s the update, matching what’s now in the JEP:
full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/
in
All looks good, except maybe Log.error().
I think Log.error() should have the same output whether verbose or not,
adding timestamp to the message only if verbose does not look right.
Problem is that Log.error() is used for two fundamentally different
purposes:
1.) by Main and Arguments to d
18 matches
Mail list logo
