Re: [8u] PING: RFR: 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs.

[Mario Torre]

Hi Severin,

The patch looks good to me.

Cheers,
Mario

On Fri, Sep 27, 2019 at 10:38 AM Severin Gehwolf  wrote:
>
> Hi!
>
> I'd appreciate a review of this one. Thanks in advance! See below.
>
> On Tue, 2019-09-03 at 17:50 +0200, Severin Gehwolf wrote:
> > On Mon, 2019-08-26 at 17:54 +0200, Severin Gehwolf wrote:
> > > Hi,
> > >
> > > Please review this 8u backport. The OpenJDK 11u patch does not apply
> > > cleanly after path-reshuffeling due to a) test and code for jaxp are
> > > split in JDK 8 b) Some rejects in comments - copyright and last
> > > modified date. I've omitted rejected comments. I can manually add them
> > > if that's preferred. See below.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213734
> > > webrevs:
> > >   jdk:  
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/
> > >   jaxp: 
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/01/webrev/
> > >
> > > Testing: tier1 on Linux x86_64. javax/xml/jaxp tests. New test on
> > >  Windows without the fix fails and passes with it.
> > >
> > > Thanks to Simon Tooke who helped testing this patch on Windows.
> > >
> > > Rejects:
> > > $ cat 
> > > src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java.rej
> > > --- XMLEntityManager.java
> > > +++ XMLEntityManager.java
> > > @@ -1,5 +1,5 @@
> > >  /*
> > > - * Copyright (c) 2009, 2017, Oracle and/or its affiliates. All rights 
> > > reserved.
> > > + * Copyright (c) 2009, 2018, Oracle and/or its affiliates. All rights 
> > > reserved.
> > >   */
> > >  /*
> > >   * Licensed to the Apache Software Foundation (ASF) under one or more
> > > @@ -89,7 +89,7 @@
> > >   * @author K.Venugopal SUN Microsystems
> > >   * @author Neeraj Bajaj SUN Microsystems
> > >   * @author Sunitha Reddy SUN Microsystems
> > > - * @LastModified: Oct 2017
> > > + * @LastModified: Nov 2018
> > >   */
> > >  public class XMLEntityManager implements XMLComponent, XMLEntityResolver 
> > > {
> > >
> >
> > Gentle reminder.
>
> Anyone? It's been a month :(
>
> FWIW, I've updated XMLEntityManager to include the copyright update
> upper bound to 2018. The @LastModified lines don't exist in JDK 8u, so
> I've omitted that. Latest webrevs:
>
> webrevs:
>jdk:  
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/
>jaxp: 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/02/webrev/
>
> Thanks,
> Severin
>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

[Mario Torre]

For a moment I had to check if this was 1st of April, but yikes! :)

Thanks for cleaning it up.

Cheers,
Mario
Il giorno mar 11 dic 2018 alle ore 16:33 Alan Bateman
 ha scritto:
>
> On 11/12/2018 15:03, Adam Farley8 wrote:
> > Hey All,
> >
> > I've spotted 12 instances of swear words in OpenJDK source comments, and
> > it seems appropriate to remove them.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8215217
> >
> > I've created a webrev and attached to the bug.
> >
> > Also, I've mentioned in the bug that there are additional swears in more
> > excusable locations. It would be good to get the community's take on
> > those.
> >
> > Reviews and opinions welcome. :)
> "Where's that damn torpedo?" might be from Star Trek.
>
>
>


-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Clean-room implementation of Double::toString(double) and Float::toString(float)

[Mario Torre]

2018-04-12 10:12 GMT+02:00 Raffaello Giulietti :

> I asked Oracle about how the copyright notice should be adapted to meet the
> OCA requirements but, as of today, I got no answer.

All the headers need to have a valid copyright text, you can just copy
the headers from any other file in the OpenJDK sources, as they are
all the same (just keep attention to the year, as this may not always
be up to date).

The license and other useful things are explained here:

http://openjdk.java.net/legal/

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Coding conventions for core-libs-dev

[Mario Torre]

As a special exception, if you commit tomorrow, you can use CRLF ;)

Cheers,
Mario
On Sat 31. Mar 2018 at 17:30, <raffaello.giulie...@gmail.com> wrote:

> On 2018-03-31 16:51, Mario Torre wrote:
> > Yes, but please try to keep the 80 columns (as per the document Remi
> > suggested, unless it kills readability). It seems archaic, but not so
> > much when you review patches and read code on a mobile device. Lots of
> > people also like to keep their monitors in portrait mode, which means
> > less real estate for long lines, not talking about the fact that this
> > limit forces you to write more concise code!
> >
> > Cheers,
> > Mario
>
> Portrait orientation might invite writing longer methods and choosing
> shorter names, which is arguably even worse than long lines ;-)
>
> Anyway, while 80 chars/line is not my first choice I'll or course adhere
> to the guidelines mentioned by Rémi. BTW, does "80" include the ending LF?
>
>
>
> Raffaello
>
> >
> >
> > On Sat 31. Mar 2018 at 16:35, Remi Forax <fo...@univ-mlv.fr
> > <mailto:fo...@univ-mlv.fr>> wrote:
> >
> > http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html
> > is the closest you can find as an official coding convention for the
> > OpenJDK.
> >
> > Rémi
> >
> > - Mail original -
> > > De: "raffaello giulietti" <raffaello.giulie...@gmail.com
> > <mailto:raffaello.giulie...@gmail.com>>
> > > À: "core-libs-dev" <core-libs-dev@openjdk.java.net
> > <mailto:core-libs-dev@openjdk.java.net>>
> > > Envoyé: Samedi 31 Mars 2018 16:24:53
> > > Objet: Coding conventions for core-libs-dev
> >
> > > Hi,
> > >
> > > are there any Java coding conventions to follow?
> > >
> > > I found very outdated guidelines at
> > >
> >
> http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html
> > > with ab archaic line limitation of 80 or even 70 chars/line.
> > >
> > > Are there official, semi-official or suggested documents?
> > >
> > >
> > >
> > > Greetings
> > > Raffaello
> >
>
>

Re: Coding conventions for core-libs-dev

[Mario Torre]

Yes, but please try to keep the 80 columns (as per the document Remi
suggested, unless it kills readability). It seems archaic, but not so much
when you review patches and read code on a mobile device. Lots of people
also like to keep their monitors in portrait mode, which means less real
estate for long lines, not talking about the fact that this limit forces
you to write more concise code!

Cheers,
Mario


On Sat 31. Mar 2018 at 16:35, Remi Forax  wrote:

> http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html
> is the closest you can find as an official coding convention for the
> OpenJDK.
>
> Rémi
>
> - Mail original -
> > De: "raffaello giulietti" 
> > À: "core-libs-dev" 
> > Envoyé: Samedi 31 Mars 2018 16:24:53
> > Objet: Coding conventions for core-libs-dev
>
> > Hi,
> >
> > are there any Java coding conventions to follow?
> >
> > I found very outdated guidelines at
> >
> http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html
> > with ab archaic line limitation of 80 or even 70 chars/line.
> >
> > Are there official, semi-official or suggested documents?
> >
> >
> >
> > Greetings
> > Raffaello
>

Re: Floating Point and Arithmetic Changes for Java SE Lnguage

[Mario Torre]

I don’t remember ever having read another reply to this mailing list with
so much interest in years!

Cheers,
Mario
On Wed 7. Mar 2018 at 21:36, joe darcy  wrote:

> Legend has it that after the ancient Greek Hippasus shared with his
> fellow travelers the elegant proof [1] that the square root of 2 is not
> a rational number, he was thrown off the ship by Pythagoreans outraged
> that such numbers should exist. Hippasus subsequently drowned. Whatever
> catharsis was released by his death did not change the fact that
> mathematically sqrt(2) cannot be exactly represented by the ratio of two
> integers.
>
> Rational numbers are simple and elegant. However, in many areas we
> cannot limit ourselves to dealing with rational numbers since values
> like sqrt(2) cannot be accommodated. To greatly abbreviate the
> development of different kinds of numbers, real numbers are commonly
> used, despite their complexities, since they contain their limits,
> meaning that transcendental values like pi are inside the system.
>
> Floating-point arithmetic is a systematic approximation to real
> arithmetic, an approximation with pragmatic compromises to facilitate
> calculation on computers. Floating-point numbers can represent numbers
> over vast scales and are (typically) fixed-sized. These aspects of
> floating-point arithmetic force most field axioms to fail to hold, field
> axioms being the familiar properties of arithmetic such as addition
> being associative ((a+b) + c == a + (b+c)).
>
> Other fixed-size approximations that have been explored, such as
> fixed-slash and floating-slash arithmetic, have been found to have worse
> computational shortcomings than floating-point arithmetic.
>
> It is true that using a binary floating-point representation rather than
> a decimal floating-point representation can cause additional surprises
> since 1/10 is not exactly representable in binary. However, all the
> field axioms that fail to hold for binary floating-point arithmetic also
> fail to hold for decimal floating-point arithmetic. In addition, the
> distances between adjacent decimal numbers makes a larger relative jump
> (ten-fold) across exponent boundaries than for binary (doubling).
>
> The IEEE 754-2008 standard incorporated decimal arithmetic into an
> update of the 1985 version of the standard. This included fixed-size 64
> and 128 bit decimal formats, amenable for hardware support. However, few
> architectures have added such support.
>
> Moreover, the roundoff errors from floating-point computation are only
> one source of errors in a computation. *Even if arithmetic were done
> exactly, numerical analysis would still be needed.* As numerical analyst
> Nick Trefethen has said "If rounding errors vanished, 95% of numerical
> analysis would remain." For example, exact arithmetic does not remove
> modeling error, where the model does have sufficient fidelity with
> reality. Many calculations involve sums of an infinite number of
> decreasing terms so truncation errors occurs for the tail of the total
> sum once the terms are no longer included.
>
> The bugs have you filed and the emails you have sent to this alias are
> all known situations and have all received responses:
>
>  JDK-8190947 -- Insufficient arithmetic Behaviour
>  Closed -- will not fix, including citations to additional
> explanations of floating-point.
>
>  JDK-8197995 - BigDecimal and BigInteger Defaulting Behaviour
>  Closed -- not an issue, long-existing documentation describes
> exactly how to avoid the reported problem.
>
>  JDK-8190991 - Forward and Inverse operations accuracy.
>  Closed -- not an issue. With fixed-precision, it is not possible to
> invert operations over the entire domain,as previously discussed on
> this list
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050393.html
> .
>
>  JDK-8190946 - There is no elementary functions support for
> BigDecimal and BigInteger.
>  Closed as a duplicate of  JDK-4297957, which in turn was created in
> 1999 and closed as will not fix in 2006.
>
> Repeatedly ignoring these responses and the reasons given for them will
> not make advancing your cause easier and wastes the time of those
> crafting the replies.
>
> To examine a few of these more closely, for JDK-8190991: "Forward and
> Inverse operations accuracy" the responses give examples where for a
> fixed-precision result, the function cannot be exacted inverted even in
> the case where the true function is monotonically increasing (where it
> is defined), like square root. The concrete example previously sent to
> core libs: sqrt on the domain [1, 2) is in the range [1, ~1.4). From the
> pigeon-hole principle, this cannot be in inverted in the same precision
> since (of necessity) multiple elements of the domain map to the same
> element in the domain. In fact, a majority of elements of range must
> have two or more corresponding domain elements.
>
> For 

Re: Getting a live view of environment variables (Gradle and JDK 9)

[Mario Torre]

2017-10-12 11:58 GMT+02:00 Cédric Champeau :

> 1. an API in 18.3 which would let us refresh the environment variables,
> even if inherently unsafe (we can take the risk, if the Javadocs explains
> that if you're really unlucky calling such a method could kill your VM).

Being a public API we would expose everyone to this risk, and the API
should be supported on all platforms maybe forever. I know other
people have different opinion here, but this seems to be high risk,
high impact to be worth.

> 2. we change the way Gradle works and force explicit declaration of all
> environment variables a user script can use. Then, we would only spawn a
> new VM if the current daemon environment variables do not match those
> required found by the client.

This.

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Getting a live view of environment variables (Gradle and JDK 9)

[Mario Torre]

2017-05-16 20:38 GMT+02:00 Cédric Champeau :
> Let me rephrase: it's tiring to have to repeat why we need it, and why we
> honor the contract of environment variables. Why is it so hard to admit the
> JDK has a bug?

Hello Cédric,

I hope you don't take it wrong or personal, but we really are here to
help, unfortunately this attitude is not helping us helping you. I
suggest to re-read what Brian just said.

The reason why you get suggestion to change how you work is because
changing the JDK effect billions of users that may be affected
negatively by the changes.

Regarding your example:

"""
println System.getenv('MY_VAR')

doesn't print "foo" after doing:

MY_VAR=foo gradle printVar
"""

I agree that the environment variables may change during the program
execution and that perhaps Java may eventually need to reflect that,
but this example is not really appropriate, the Java process started
with an environment variable not set, the one that starts with
MY_VAR=foo is technically a different process...

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Getting a live view of environment variables (Gradle and JDK 9)

[Mario Torre]

2017-05-15 7:14 GMT+02:00 David Holmes :
>> There would have to be a caveat on System.getenv(true) if we went that
>> path, that it is up to the user to ensure it is called in as safe a
>> manner as possible having regard to any concurrent updates in their
>> application code and how the environment is managed on a given platform.

If we get a System.setEnv in Java we can synchronise that method
access, either internally or by asking the user to explicitly
synchronise.

That would not protect from direct system calls, but it with a proper
Java API that would be the recommended way to set environment
variables, thus lowering the risk.

The question is if this use case is really that compelling that
justify an official wrapper against set/putEnv.

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: IBM RSA-II "virtual drive" feature does not work with OpenJDK

[Mario Torre]

2017-05-08 13:45 GMT+02:00 dalibor topic :
> Hi Martin,
>
> we don't provide OpenJDK binaries in Linux distributions.
>
> I'd suggest reporting it to the provider of your binaries directly (Debian
> in this case), as we don't provide a browser plugin implementation, either.
> Alternatively, you may want to give the distro-pkg-dev mailing list a try,
> where the developers of the IcedTea-Web plugin and/or Debian packages may be
> found.
>
> cheers,
> dalibor topic

This is probably something to report to IBM first, I suspect some use
of some weird hidden internal code. Jigsaw is long overdue...

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: RFR(m): 8140281 deprecate Optional.get()

[Mario Torre]

2016-04-27 19:43 GMT+02:00 Maurizio Cimadamore :
>
>
> On 27/04/16 09:31, Andrew Haley wrote:
>>
>> what they say makes
>> sense to me
>
> It makes sense to me to. Having an innocently-named get() method throwing an
> exception is not something you see everyday. And in this case it's doubly
> confusing because one could imagine also a different behavior (i.e. return
> null if no object is there). So I'm in favor for making things clearer by
> choosing a more explicit name (whether the proposed one or a better one).

This thread looks funny, so I chime in too.

+1 for the change overall, I really do like when methods are self
explanatory and I don't need to read the manual ;)

But please consider the getWhenPresent sounds to me like it's trying
to suggest that the method would block and returns *when* the value is
present, not sure if it's just me and the fact that I'm not native
english speaker though.

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Bug in ArrayList iterator

[Mario Torre]

2015-01-07 12:22 GMT+01:00 Stanislav Baiduzhyi sbaid...@redhat.com:
 On Wednesday 07 January 2015 11:20:57 you wrote:
 On 07/01/15 10:57, Stanislav Baiduzhyi wrote:
  On Wednesday 07 January 2015 10:56:01 Chris Hegarty wrote:
 public boolean hasNext() {
 
  -return cursor != size;
  +return cursor != itrSize;
 
 }
 
  If the user will invoke list.remove(E) to remove current or previous
  element then iterator will be skipping some elements.

 If this happens, then next() and/or remove() will throw CME.

   Throwing ConcurrentModification

  in hasNext() looks better in such case.

 It is not clear to me that users would be expecting CME from hasNext(),
 whereas it is more next() and remove() is more obvious.

 Yes, but that exactly how it works now, that's why second invocation of
 hasNext() returns false and we can see the issue Remi is talking about. If
 hasNext() will be throwing ConcurrentModification than will work as early
 warning system that something is wrong with this iterator.

But hasNext isn't modifying things, why should it throw
ConcurrentModification? I would find it very confusing, and also
likely non backward compatible.

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Losing features of JVM_Open, e.g. CLOEXEC

[Mario Torre]

This is exactly what I was about to reply. One can only spot those
things if there is a standardised API, and even in this case it's not
at all easy. That doesn't stop from trying :) but removing the API was
likely a mistake, which would not be a terrible one because of what
David points, except the fact that it's invalidating a fix (at least
this is what I understood from Martin's original mail).

On a related note, some time ago there was a process of standardising
and documenting the VM abstraction (Andrew Hughes was doing that),
does anybody knows what's the state of that? Afaik there's a lot of
infrastructure in place, but it seems more like we have it more or
less when it makes sense rather than a carefully planned long term
project. But I think it may be worth expanding over this rather than
reducing it.

This would benefit external VM implementation, which is a good thing,
but the main goal for me would be to have a clearly documented and
logical API with the overall benefit that if we abstract those things
out, we have one single place where bugs can possible be [fixed].

What do you think?

Cheers,
Mario

2014-10-30 10:45 GMT+01:00 David Holmes david.hol...@oracle.com:
 On 30/10/2014 6:46 PM, Alan Bateman wrote:

 On 29/10/2014 21:15, Mario Torre wrote:


 +1

 We should have spotted it in the review though.


 We should but the ultimate rat catcher should be the tests, it's
 possible that we have a hole there.


 Not sure how the presence or absence of CLOEXEC would be visible to any test
 - especially given all the other uses of raw open in the JDK sources.

 David




-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Losing features of JVM_Open, e.g. CLOEXEC

[Mario Torre]

I've been thinking perhaps one can use fcntl to check what flags are
passed given we can retrieve all the file descriptors that have been
opened?

Using raw open complicates the matter though.

Cheers,
Mario

2014-10-30 11:16 GMT+01:00 Mario Torre neugens.limasoftw...@gmail.com:
 This is exactly what I was about to reply. One can only spot those
 things if there is a standardised API, and even in this case it's not
 at all easy. That doesn't stop from trying :) but removing the API was
 likely a mistake, which would not be a terrible one because of what
 David points, except the fact that it's invalidating a fix (at least
 this is what I understood from Martin's original mail).

 On a related note, some time ago there was a process of standardising
 and documenting the VM abstraction (Andrew Hughes was doing that),
 does anybody knows what's the state of that? Afaik there's a lot of
 infrastructure in place, but it seems more like we have it more or
 less when it makes sense rather than a carefully planned long term
 project. But I think it may be worth expanding over this rather than
 reducing it.

 This would benefit external VM implementation, which is a good thing,
 but the main goal for me would be to have a clearly documented and
 logical API with the overall benefit that if we abstract those things
 out, we have one single place where bugs can possible be [fixed].

 What do you think?

 Cheers,
 Mario

 2014-10-30 10:45 GMT+01:00 David Holmes david.hol...@oracle.com:
 On 30/10/2014 6:46 PM, Alan Bateman wrote:

 On 29/10/2014 21:15, Mario Torre wrote:


 +1

 We should have spotted it in the review though.


 We should but the ultimate rat catcher should be the tests, it's
 possible that we have a hole there.


 Not sure how the presence or absence of CLOEXEC would be visible to any test
 - especially given all the other uses of raw open in the JDK sources.

 David




 --
 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
 Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

 Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
 Proud GNU Classpath developer: http://www.classpath.org/
 OpenJDK: http://openjdk.java.net/projects/caciocavallo/

 Please, support open standards:
 http://endsoftpatents.org/



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Losing features of JVM_Open, e.g. CLOEXEC

[Mario Torre]

Indeed, but /proc/$PID/fd can perhaps be useful here? Not sure if this
can make a reasonable test though.

Cheers,
Mario

2014-10-30 18:30 GMT+01:00 Martin Buchholz marti...@google.com:
 On Thu, Oct 30, 2014 at 3:24 AM, Mario Torre
 neugens.limasoftw...@gmail.com wrote:
 I've been thinking perhaps one can use fcntl to check what flags are
 passed given we can retrieve all the file descriptors that have been
 opened?

 It's possible to find all the open file descriptors (e.g. using
 /proc/self/fd), but they may not belong to the JDK.



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Losing features of JVM_Open, e.g. CLOEXEC

[Mario Torre]

+1

We should have spotted it in the review though.

Cheers,
Mario
Il 29/ott/2014 21:47 Christos Zoulas chris...@zoulas.com ha scritto:

 On Oct 29,  1:12pm, marti...@google.com (Martin Buchholz) wrote:
 -- Subject: Losing features of JVM_Open, e.g. CLOEXEC

 | throwing away use of old shared infrastructure and replacing with naked
 | calls to the OS.  Although understandable, this abandons benefits of
 using
 | shared infrastructure.  Here I'm thinking of the close-on-exec flag.  I
 | just added use of O_CLOEXEC to linux hotspot, but e.g. zip file opening
 no
 | longer uses JVM_Open, which is a code hygiene regression.
 |
 | What we want is to have almost all file descriptors have the
 close-on-exec
 | flag automatically set at fd creation time, using O_CLOEXEC where
 | available, and FD_CLOEXEC where not.  How do we get there?
 |
 | I'm distressed that the JDK core libraries should be moving towards
 having
 | *more* shared native code infrastructure, but here we seem to be moving
 in
 | the opposite direction.  Having abandoned JVM_Open, the responsibility of
 | doing these things right belongs entirely to the core libraries team.  So
 | where's the core-library replacement for JVM_Open?

 I totally agree with Martin here. Changes like this are harmful.

 christos

Re: JEP 198: Light-Weight JSON API

[Mario Torre]

I never gave a +1 with more enthusiasm! :)

Cheers,
Mario
Il 31/lug/2014 03:27 Wang Weijun weijun.w...@oracle.com ha scritto:


 On Jul 31, 2014, at 8:35, Remi Forax fo...@univ-mlv.fr wrote:

 
  On 07/25/2014 04:45 PM, mark.reinh...@oracle.com wrote:
  New JEP Candidate: http://openjdk.java.net/jeps/198
 
  - Mark
 
  Hi Mark, Hi Mike,
  Implementing a json API was one of the use case I've used during the
 development of the lambdas,
  so maybe you are interested by this gist
   https://gist.github.com/forax/81a56cf2684bfa2e46ec

 I am reading [ \foo\, \bar\ ] and feel we need a JEP for new styles
 of literal strings. Long long ago there was a proposal for multi-line raw
 strings. Still alive?

 Thanks
 Max

Re: JAXP JEP: Update Xerces implementation in the JDK

[Mario Torre]

Yes,

And it would be even nicer if we could get some of the patches integrated
upstream so that it could be eventually possible to not maintaining this
code, but instead use upstream bundles directly.

Not sure how this could be done, but would be awesome.

Cheers,
Mario
Il 03/feb/2014 22:14 Martijn Verburg martijnverb...@gmail.com ha
scritto:

 Hi Huizhe,

 Is there a possibility to look at having a more loosely coupled
 relationship between Xerces and what is core JDK? I'm thinking about (in
 combination with) Jigsaw that you could allow the Xerces components to be
 kept up to date more often (assuming API compatibility etc is retained).

 Cheers,
 Martijn


 On 3 February 2014 20:19, huizhe wang huizhe.w...@oracle.com wrote:

  Hi,
 
  We'd like to propose a JEP to update the Xerces implementation in the JDK
  and bring it to up to date to the current Xerces release. Please review
 the
  draft.
 
  Thanks,
  Joe
 
 

Re: JAXP JEP: Update Xerces implementation in the JDK

[Mario Torre]

Il 03/feb/2014 22:50 Alan Bateman alan.bate...@oracle.com ha scritto:

 In any case, I think this JEP is a good step as it brings the
implementations closer and also revs the support on a number of standards.

Indeed!
Mario

Re: Time to put a stop to Thread.stop?

[Mario Torre]

2013/5/16 David Holmes david.hol...@oracle.com:

 +1

 I think it should also blow at runtime unless people passes some fancy
 argument (like -XX:recallRetired :), this way is easier for people to
 fix their code, or, in case they can't, do workaround it.


 Interesting suggestions but I for one do not think that after 15 years of
 deprecation we need to go to such lengths to keep stop(Throwable) on
 life-support - it is @Deceased in my opinion :)


Hi David,

In fact, I fully agree for Thread.stop we should probably just do as
you suggest and kill it :) but my interest shifted to the @Retired
annotation which could be a nice general thing to have (Thread.stop
could actually be a test case for it).

Ideally, by Java 9, we could go through most of the @Deprecated and
convert them to @Retired and give one platform lifetime to make people
adjust their code. Java 10 could be finally free of all those ancient
vestiges of a glorious past :)

Cheers,
Mario
--
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Time to put a stop to Thread.stop?

[Mario Torre]

2013/5/15 Remi Forax fo...@univ-mlv.fr:
 On 05/15/2013 10:39 AM, Martin Desruisseaux wrote:

 Le 15/05/13 10:05, David Holmes a écrit :

 There is a huge difference between blowing away a complete process with
 kill and having a single thread starting to propagate an async exception,
 unwinding its stack and executing finally blocks with completely broken
 state invariants.


 Given the risk, what about a mechanism similar to the one which currently
 hides the Sun internal packages from the compilation phase but not yet from
 the runtime phase? Would it be acceptable to have 'javac' and 'javadoc'
 woking as if the 'Thread.stop(Throwable)' method did not existed anymore,
 while having the method still working (for now) at runtime for existing
 libraries? Maybe with an annotation yet stronger than @Deprecated.

 Martin


 yes, I propose @Retired.

+1

I think it should also blow at runtime unless people passes some fancy
argument (like -XX:recallRetired :), this way is easier for people to
fix their code, or, in case they can't, do workaround it.

Cheers,
Mario

--
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Remove the assert in Integer.valueOf()

[Mario Torre]

2012/4/23 Rémi Forax fo...@univ-mlv.fr:

 The issue is that Hotspot also count the bytecodes related to assert
 in its inlining heuristic.
 If the assert is commented, the inlining tree is good.

[...]

 Given that Integer.valueOf() is a method used very often and that if the
 inlining fails,
 the escape analysis will not remove the allocation,
 I think it's a good idea to comment this assert.

Hi Rémi,

I'm not sure if it's a good idea or not to remove the assert.

What happens if we replace the assert with a specific check, is it
still not inlined?

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: JEP 154: Remove Serialization

[Mario Torre]

2012/4/4 David M. Lloyd david.ll...@redhat.com:
 I was going to post a patch  feature request to add goto into the
 language.  But I had a baby and so I didn't have time to finish it up,
 unfortunately.  The best part is that I was (and am) half-serious about it
 :)

 Doing a JEP is even more clever though.  It lends a certain amount of
 credibility.  At least until you read the Motivation section anyway.

But the best part of it is that those JEP are still online :)

http://openjdk.java.net/jeps/0

And there you really see them listed by name!

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Disambiguating empty catch blocks

[Mario Torre]

Il giorno mer, 14/04/2010 alle 22.49 +1200, Bruce Chapman ha scritto:
 Thanks Martin,
 
 comment inline.
 
 Bruce
 
 
 Martin Buchholz wrote:
  Hi Bruce,
 
  I don't think you're going to find enough support for adding
  rarely used new methods to existing exception classes.

 Of course it is rare at present - it doesn't yet exist. So rarely used 
 is at this point subjective and hypothetical. My feeling is that it 
 would be useful, if you think not, then that is another data point. 
 Maybe a weekly survey question for java.net?  - I am sure they could 
 find a way to turn it into 5 choices.  :)
  There's already a clear way to indicate to human readers
  that an exception should be ignored or is expected
 
  catch (SomeException ignored) { }
 
  catch (SomeException expected) { }

 
 Oh dear, I thought we had finally got away from magic name solutions. 
 Of course in JDK7 we'll be able to
 
 catch (@Ignored SomeException ex) { }
 
 catch (@Impossible SomeException ex) { }

It think I like this one.

I also used

catch (SomeException _) { /* ignored */ }

The _ is a clear sign. If you don't name it, it means you're not
interested in it, and the comment is purely optional then.

Cheers,
Mario
-- 
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas GmbH, Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Geschäftsführer: Dr. James J. Hunt

pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Please, support open standards: http://endsoftpatents.org/

Re: C system() equivalent method.

[Mario Torre]

Il 15/10/2009 15:32, Frédéric Martini ha scritto:

Hello,


Sorry to revive this request, but I think this is as simple but very useful
method that must be present on Java 7.

No one have an opinion on this?

Fred,


I'm not sure.

In my opinion this is easy to do in application code using something 
similar to what you did or Runtime.exec, but doesn't fit into the core 
library.


Also, in this implementation you are assuming lots of things that are 
not valid everywhere, like:


The system is either Windows or Linux or Solaris (or some other sane 
unix variant), the system has /bin/sh, and it's possible to use it to 
execute process etc...


I would not like much to see this in the standard library, especially in 
java.lang, as this thing is non portable by definition.


Cheers,
Mario

--
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-44
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Geschäftsführer: Dr. James J. Hunt

Please, support open standards:
http://endsoftpatents.org/

Re: First round of java.util.Objects for code review (bug 6797535)

[Mario Torre]

Il 08/10/2009 20:10, Joseph D. Darcy ha scritto:

Hi Joseph!

Of course, it's nitpicking but:

 +  System.err.printf(When equating %s to %s, got %b intead of %b%n.,
 + a, b, result, expected);

has a typo in there :)

There are others similar, copy and paste errors I suppose.

Cheers,
Mario

Re: malloc failures in java/util/zip/Deflater

[Mario Torre]

Il 09/07/2009 18:57, Kelly O'Hair ha scritto:

I tend to agree.

Shouldn't a zero length entry be treated special, or disallowed?

-kto


Hi Kelly,

Maybe I misunderstood the code, because I didn't went into it in so 
great details, but I think that the zero length is already considered 
special because it signals the end of the stream, and the variable 
finished is hence set in the code.


I'll spend some more time on that, and tell you. In the meantime, to 
test it, what I did was something like:


if (len == 0) {
  in_buf = NULL;

} else {
  in_buf = malloc(len); // len == 0
}

if (in_buf == 0  len  0) {
/* throw the exception */
}

and it worked without crashing :)

Cheers,
Mario

Re: malloc failures in java/util/zip/Deflater

[Mario Torre]

Il 09/07/2009 19:41, Xueming Shen ha scritto:


Zero length entry should be allowed. This is a regression, the result of
the
un-successful fix for 6728376:-(

The webrev for 6728376 is
http://cr.openjdk.java.net/~sherman/6728376/webrev

We have the same in Inflater as well. I will file a bug for it.

Thanks Mario for catching this.

Sherman


Hi!

Actually in my code I also spotted the same issue, as we got an endless 
loop there, but we use a slightly older OpenJDK code base.


Maybe that my fix is not complete, I would like to be alerted when the 
bug gets filed, is it possible?


Mario

Re: malloc failures in java/util/zip/Deflater

[Mario Torre]

Il 08/07/2009 20:52, Roman Kennke ha scritto:

Hi Mario,


According to the specs, malloc may return either a valid pointer that
can be passed to free, or NULL, while generally NULL is considered to be
a failure. Linux and Solaris, albeit non specifying it, return always a
valid pointer, as far as I know


I think NULL is returned in an out of memory situation, which is very
rare on modern OSes, but I think it's still possible. The right thing to
do here is check for NULL and (try to) throw an OOME. Which is what is
beeing done already (AFAICS). What are you trying to solve by
additionally checking for len  0?

/Roman


Hi Roman,

The OutOfMemory is thrown correctly in case of failure (it wasn't up to 
some builds ago, though :).


The problem is when passing a 0 length argument to malloc (from the man 
page):


malloc()  allocates  size  bytes and returns a pointer to the allocated
  memory.  The memory is not  cleared.   If  size  is  0, then
  malloc() returns  either  NULL, or a unique pointer value
  that can later be successfully passed to free().

Linux and Solaris AFAIK return a pointer to valid memory, but this is 
not specified, and the code only checks for NULL as in failure. So it 
may be the case that this changes in future. In my case I have a 
not-so-modern OS that returns NULL in such case.


So, to decide if we have a memory error or not, we need the additional 
len  0 check.


Cheers,
Mario