Re: [Patch][JDK10] Use Class.getPackageName() where possible

The private static helper in ObjectStreamClass became a oneliner and can be removed and the callsites can transform from getPackageName(c) to c.getPackageName(). Gruss Bernd -- http://bernd.eckenfels.net _ From: mandy chung

Re: [Patch][JDK10] Use Class.getPackageName() where possible

On 11/3/17 1:06 AM, Christoph Dreis wrote: Thanks - I updated both as you suggested to use Class::getPackageName. Please find the updated patch below. I have created https://bugs.openjdk.java.net/browse/JDK-8190733 for this patch. There is also a public static

Re: [10] RFR 8186046 Minimal ConstantDynamic support

> On 3 Nov 2017, at 11:14, Karen Kinnear wrote: > > Thank you so much for doing this jointly. > > Couple of questions/comments: > 1. thank you for making UseBootstrapCallInfo diagnostic > > 2. org/objectweb/asmClassReader.java > why hardcoded 17 instead of

Re: JDK-8067661: transferTo proposal for Appendable

Hi Alan, I will have a version ready at Devoxx next week ;-) -Patrick > Am 03.11.2017 um 13:49 schrieb Alan Bateman : > > On 02/11/2017 19:55, Patrick Reinhart wrote: >> : >> If we are all happy with the API so far, I could start adding an initial >> implementation

Re: [10] RFR 8186046 Minimal ConstantDynamic support

Thank you so much for doing this jointly. Couple of questions/comments: 1. thank you for making UseBootstrapCallInfo diagnostic 2. org/objectweb/asmClassReader.java why hardcoded 17 instead of ClassWriter.CONDY? 3. java/lang/invoke/package-info.java 128-134 Error handling could be clearer. My

Re: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)

Hi, On 11/03/2017 02:17 PM, Alan Bateman wrote: On 03/11/2017 08:11, Christoph Dreis wrote: Hi John, this has a bigger impact on the overall footprint of Method/Executable objects. What are your thoughts on this? The footprint is probably about the same.  Small List.of values do not contain

Re: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)

On 2017-11-03 14:17, Alan Bateman wrote: On 03/11/2017 08:11, Christoph Dreis wrote: Hi John, this has a bigger impact on the overall footprint of Method/Executable objects. What are your thoughts on this? The footprint is probably about the same.  Small List.of values do not contain

Re: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)

On 03/11/2017 08:11, Christoph Dreis wrote: Hi John, this has a bigger impact on the overall footprint of Method/Executable objects. What are your thoughts on this? The footprint is probably about the same. Small List.of values do not contain arrays, and may be smaller than arrays with the

Re: JDK-8067661: transferTo proposal for Appendable

On 02/11/2017 19:55, Patrick Reinhart wrote: : If we are all happy with the API so far, I could start adding an initial implementation and test… I think the API looks fine so go ahead. -Alan

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Sherman, I think this looks good now. Thanks. Regards, Peter On 11/01/2017 08:17 PM, Xueming Shen wrote: Hi Peter, I like the idea of moving get/releaseInflter() into CleanableResource, though I doubt how much it can really help the GC it should be a good thing to do to remove the

RE: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)

Hi John, >> this has a bigger impact on the overall footprint of Method/Executable >> objects. What are your thoughts on this? > The footprint is probably about the same. Small List.of values > do not contain arrays, and may be smaller than arrays with the > same number of elements, since they

RE: [Patch][JDK10] Use Class.getPackageName() where possible

Hi Mandy, > It's good to see JDK code be updated to use Class::getPackageName. One thing > to pay attention is that Class.getPackageName() returns "java.lang" for > primitive type and void. Your patch fixing ObjectStreamClass::getPackageName > and Proxy::checkNewProxyPermission look fine. >

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Am 02.11.2017 um 20:08 schrieb Roger Riggs: > Hi, > > It would also support a more fluent use of the APIs.  Though if we > start down that road > it may become littered with convenience methods.  Something to ponder > for a bit. > One one hand I see your obligation, on the other hand we would open