Re: JAXP JEP: Update Xerces implementation in the JDK

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

Re: JAXP JEP: Update Xerces implementation in the JDK

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: JEP 198: Light-Weight JSON API

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:

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

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

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

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

Re: JEP 154: Remove Serialization

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

Re: Remove the assert in Integer.valueOf()

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

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

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

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

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

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

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

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

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.

Re: C system() equivalent method.

, 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

Re: Disambiguating empty catch blocks

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

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

+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

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

: 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

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

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

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

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

Re: Bug in ArrayList iterator

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

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

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

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

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

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

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

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

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,

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

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).

Re: Floating Point and Arithmetic Changes for Java SE Lnguage

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]

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

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

Re: Coding conventions for core-libs-dev

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

Re: Coding conventions for core-libs-dev

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 > > sugge

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

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

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

gt; > { > > > > > > > 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