core-libs-dev Digest, Vol 113, Issue 53
David Holmes
david.holmes at oracle.com
Fri Sep 16 01:47:43 UTC 2016
Hi Manjunath,
When replying to something you see in a digest it would be a lot easier
to follow if you could use the original subject line, or even go to the
archives and respond to the original mail.
Thanks,
David
On 16/09/2016 12:39 AM, Manjunath SV wrote:
> Hi,
>
> I monitored memory usage, below are the details.
>
> Heap usage :- 857mb
> Virtual memory:- 12.6gb
> -Xmx set to 4gb.
>
> I have taken virtual and heap memory usage when Java spawns sub
> processes.
>
> Thanks & Regards,
> Manjunath
>
> On 15 Sep 2016 4:17 p.m., <core-libs-dev-request at openjdk.java.net> wrote:
>
> Send core-libs-dev mailing list submissions to
> core-libs-dev at 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-request at openjdk.java.net
>
> You can reach the person managing the list at
> core-libs-dev-owner at 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: System.console().encoding() (Xueming Shen)
> 2. Re: RFC: System.console().encoding() (Dawid Weiss)
> 3. Re: RFC: System.console().encoding() (Claes Redestad)
> 4. Re: RFR: JDK-8134373: explore potential uses of convenience
> factories within the JDK (Jonathan Bluett-Duncan)
> 5. Re: Reg - Sub Process creation from java takes more time
> (ecki at zusammenkunft.net)
> 6. Re: RFC: System.console().encoding() (Jochen Theodorou)
> 7. Re: RFC: System.console().encoding() (Dawid Weiss)
> 8. Re: RFR: JDK-8134373: explore potential uses of convenience
> factories within the JDK (Pavel Rappo)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 15 Sep 2016 00:06:05 -0700
> From: Xueming Shen <xueming.shen at oracle.com>
> To: core-libs-dev at openjdk.java.net
> Subject: Re: RFC: System.console().encoding()
> Message-ID: <57DA485D.100 at oracle.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> -1 :-)
>
> Console is supposed to be a "char/String" based class, "encoding" really
> should
> have no business here in its api. Simply for some implementation convenience
> is really not a good reason to add such a public method.
>
> That said, I would be fine to have such informative info in the system
> properties,
> together with its siblings, file,encoding and another "supposed to be
> private"
> property sun.jnu.encoding.
>
> sherman
>
>
> On 9/14/16, 11:42 PM, Aleksey Shipilev wrote:
>> Hi,
>>
>> Claes pointed out that our own reflective hacks to figure out console
>> encoding do not work anymore [1]. But, we need the console encoding for
>> reliably printing on the console from within different sources. Note
>> that you would normally just use System.console() and its PrintWriter,
>> but reality is a bit more complicated, and sometimes you need to write
>> the plain char stream directly into the byte[]-accepting methods,
>> encoding on your own.
>>
>> So, my question: should we, in the light of extended Jigsaw-solving
>> crunch, provide the public Console.encoding() method that would return
>> the console charset?
>>
>> Thanks,
>> -Aleksey
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html
>>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 15 Sep 2016 09:21:01 +0200
> From: Dawid Weiss <dawid.weiss at gmail.com>
> To: Xueming Shen <xueming.shen at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFC: System.console().encoding()
> Message-ID:
> <CAM21Rt8rhp3ZBOKMQtFR5j959sb_jjVf-AWyn_uNhhu2324-kQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
>> Console is supposed to be a "char/String" based class, "encoding" really
>> should have no business here in its api.
>
> While I agree with your concerns about the functional side of the API,
> I disagree about this method having no practical use. I can give you a
> concrete example. The use case that we had was to check whether the
> "terminal" (console) would be able to handle non-ASCII characters. A
> Writer doesn't tell you anything. An encoding does provide at least
> some confidence that certain characters will be translated properly --
> if your encoding is US-ASCII or ISO8859-1 then Polish diacritics won't
> get displayed for sure. This doesn't mean 100% confidence in actual
> glyph rendering of course, but it's a cheap and safe sanity check of
> the terminal's capabilities.
>
> An (undocumented) proprietary property? Sure, but I really don't see
> the reason why this shouldn't be in the API, unless you know of
> terminals that handle Unicode-based streams directly (in which case
> the encoding method would simply return UTF32).
>
> Dawid
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 15 Sep 2016 10:18:29 +0200
> From: Claes Redestad <claes.redestad at oracle.com>
> To: core-libs-dev at openjdk.java.net
> Subject: Re: RFC: System.console().encoding()
> Message-ID: <57DA5955.4070401 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> +1
>
> Won't be enough, though, since in JMH it appears you're also getting
> the encoding from System.out (java.io.PrintStream) via reflective
> hacks.
>
> /Claes
>
> On 2016-09-15 08:42, Aleksey Shipilev wrote:
>> Hi,
>>
>> Claes pointed out that our own reflective hacks to figure out console
>> encoding do not work anymore [1]. But, we need the console encoding for
>> reliably printing on the console from within different sources. Note
>> that you would normally just use System.console() and its PrintWriter,
>> but reality is a bit more complicated, and sometimes you need to write
>> the plain char stream directly into the byte[]-accepting methods,
>> encoding on your own.
>>
>> So, my question: should we, in the light of extended Jigsaw-solving
>> crunch, provide the public Console.encoding() method that would return
>> the console charset?
>>
>> Thanks,
>> -Aleksey
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html
>>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 15 Sep 2016 09:52:47 +0100
> From: Jonathan Bluett-Duncan <jbluettduncan at gmail.com>
> To: Patrick Reinhart <patrick at reini.net>, Stuart Marks
> <stuart.marks at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8134373: explore potential uses of convenience
> factories within the JDK
> Message-ID:
> <CAPMys85-DqhvwYaOmN+izBqPkZDGoa4Ju4wPpduPiM-3UB1msQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Thanks Patrick!
>
> Stuart, would you be happy to sponsor this change?
>
> If anyone else has any thoughts regarding this change, then I'm all ears.
>
> Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373
> Rationale for changes:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-
> September/043484.html
>
> Kind regards,
> Jonathan
>
>
> On 14 September 2016 at 21:55, Patrick Reinhart <patrick at reini.net> wrote:
>
>> Hi Jonathan,
>>
>> Here are your changes in a webrev:
>>
>> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00
>>
>> -Patrick
>>
>> Am 13.09.2016 um 14:45 schrieb Patrick Reinhart <patrick at reini.net>:
>>
>> Hi Jonathan,
>>
>> On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote:
>>
>> Hi Patrick,
>> Thank you very much for the offer to hold my patch for me!
>>
>>
>> No problem.
>>
>> Is it common practice to send patches to others using PGP?
>>
>>
>> No, this is my personal setting.
>>
>> Kind regards,
>> Jonathan
>> On 12 September 2016 at 21:08, Patrick Reinhart <patrick at reini.net> wrote:
>>
>> Hi Jonathan,
>> As I just also wanted to help some more clean-up in the JDKs final phase,
> I
>> could offer you to hold that patch. Just send it to me and I will prepare
>> the webrev for you?.
>> -Patrick
>>
>>
>> -Patrick
>>
>>
>>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 15 Sep 2016 11:01:01 +0200
> From: <ecki at zusammenkunft.net>
> To: "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
> Subject: Re: Reg - Sub Process creation from java takes more time
> Message-ID: <57da634c.c336c20a.19b0c.bec8 at mx.google.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> Do you monitor heap usage and virtual memory size of your Java process? I
> would look out for increase (which causes slower for tines).
>
> Also it is generally a good idea to turn on GC logging and look into it if
> a java process degregades over time
>
> Gruss
> Bernd
>
> Just BTW: I think Java would not be the right tool to spawn and control
> sich a high number of external processes. Maybe it would be better to hand
> that off to a more native component.
> --
> http://bernd.eckenfels.net
>
> Von: Manjunath SV
>
> ------------------------------
>
> Message: 6
> Date: Thu, 15 Sep 2016 12:05:04 +0200
> From: Jochen Theodorou <blackdrag at gmx.org>
> To: core-libs-dev at openjdk.java.net
> Subject: Re: RFC: System.console().encoding()
> Message-ID: <57DA7250.9020406 at gmx.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>
>
> On 15.09.2016 09:21, Dawid Weiss wrote:
>>> Console is supposed to be a "char/String" based class, "encoding" really
>>> should have no business here in its api.
>>
>> While I agree with your concerns about the functional side of the API,
>> I disagree about this method having no practical use. I can give you a
>> concrete example. The use case that we had was to check whether the
>> "terminal" (console) would be able to handle non-ASCII characters. A
>> Writer doesn't tell you anything. An encoding does provide at least
>> some confidence that certain characters will be translated properly --
>> if your encoding is US-ASCII or ISO8859-1 then Polish diacritics won't
>> get displayed for sure. This doesn't mean 100% confidence in actual
>> glyph rendering of course, but it's a cheap and safe sanity check of
>> the terminal's capabilities.
>
> out of curiosity... what will you do if you find the encoding lacking
> what you need?
>
>
> bye Jochen
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 15 Sep 2016 12:17:26 +0200
> From: Dawid Weiss <dawid.weiss at gmail.com>
> To: Jochen Theodorou <blackdrag at gmx.org>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFC: System.console().encoding()
> Message-ID:
> <CAM21Rt-NF6nuxpJMhmqh--pA-LTO6zmX0x5K0f7=RRWj_ATB0w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
>> out of curiosity... what will you do if you find the encoding lacking what
>> you need?
>
> Oh, display a warning. Helps to figure out where those "???"
> characters are coming from...
>
> Naive, I know. But it's the best one can do and it works (most of the time).
>
> D.
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 15 Sep 2016 11:46:17 +0100
> From: Pavel Rappo <pavel.rappo at oracle.com>
> To: Jonathan Bluett-Duncan <jbluettduncan at gmail.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8134373: explore potential uses of convenience
> factories within the JDK
> Message-ID: <FD16B50E-CC8A-4D49-94F2-80E16531B330 at oracle.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> I have had a look at the change. It looks good.
>
> Retrofitting Collections.unmodifiableXXX/Arrays.asList with Convenience
> Factory
> Methods requires extra carefulness as the factory methods are stricter than
> any
> of those. Not only do they provide unconditional non-modifiability [0], they
> also do not tolerate `null` elements.
>
> It looks like you took all that into account.
> Tiny little comments and suggestions.
>
> 1. It might be the case we no longer need this [1]:
>
> finderList.forEach(Objects::requireNonNull);
>
> as the List.of does the same thing for free. Though it might be okay to
> leave it
> as an explicit check.
>
> Also, could you please fix a typo here (the same file):
>
> * will be propogated to the caller of the resulting module finder's
> ^
> 2. An interesting question (though it's a completely different issue) is
> whether
> or not the `cookieHeader` list in the map should also be unmodifiable [2]?
>
> 3. Could you please also fix the same (copy-pasted?) typo in FileTreeWalker?
>
> if {@code options} is {@ocde null} or the options
> ^^
> 4. Please remove this line from the ZoneRules constructor's javadoc:
>
> @return the zone rules, not null
>
> 5. Maybe we should revisit javadoc on those fields in [3]:
>
> This <code>List</code> is {@linkplain Collections#unmodifiableList(List)
> unmodifiable}.
>
> Since it's no longer the case.
>
> 6. I couldn't find any evidence that `resolverFields` might contain `null`.
> Am I missing a javadoc or a line of code? Maybe we should talk to java.time
> folks to see if it's the case?
>
> 7. Try to not make lines longer than they were before: 80 characters. Unless
> it's really needed.
>
> Thanks,
> -Pavel
>
> ------------------------------------------------------------
> --------------------
> [0] Compare List.of().remove(new Object()) with
> Collections.emptyList().remove(new
> Object())
> [1] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/
> webrev.00/src/java.base/share/classes/java/lang/module/
> ModuleFinder.java.sdiff.html
> [2] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/
> webrev.00/src/java.base/share/classes/java/net/CookieManager.java.sdiff.html
> [3] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/
> webrev.00/src/java.base/share/classes/java/util/
> ResourceBundle.java.sdiff.html
>
>> On 15 Sep 2016, at 09:52, Jonathan Bluett-Duncan <jbluettduncan at gmail.com>
> wrote:
>>
>> Thanks Patrick!
>>
>> Stuart, would you be happy to sponsor this change?
>>
>> If anyone else has any thoughts regarding this change, then I'm all ears.
>>
>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373
>> Rationale for changes:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-
> September/043484.html
>>
>> Kind regards,
>> Jonathan
>>
>>
>> On 14 September 2016 at 21:55, Patrick Reinhart <patrick at reini.net> wrote:
>>
>>> Hi Jonathan,
>>>
>>> Here are your changes in a webrev:
>>>
>>> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00
>>>
>>> -Patrick
>>>
>>> Am 13.09.2016 um 14:45 schrieb Patrick Reinhart <patrick at reini.net>:
>>>
>>> Hi Jonathan,
>>>
>>> On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote:
>>>
>>> Hi Patrick,
>>> Thank you very much for the offer to hold my patch for me!
>>>
>>>
>>> No problem.
>>>
>>> Is it common practice to send patches to others using PGP?
>>>
>>>
>>> No, this is my personal setting.
>>>
>>> Kind regards,
>>> Jonathan
>>> On 12 September 2016 at 21:08, Patrick Reinhart <patrick at reini.net>
> wrote:
>>>
>>> Hi Jonathan,
>>> As I just also wanted to help some more clean-up in the JDKs final
> phase, I
>>> could offer you to hold that patch. Just send it to me and I will prepare
>>> the webrev for you?.
>>> -Patrick
>>>
>>>
>>> -Patrick
>>>
>>>
>>>
>
>
>
> End of core-libs-dev Digest, Vol 113, Issue 53
> **********************************************
>
More information about the core-libs-dev
mailing list