Re: Android and Log4j

Martin, Do they also ignore the class files in META-INF/versions? Ralph > On Dec 6, 2017, at 2:35 PM, Martin Buchholz wrote: > > Very latest Android Studio comes with two compilers, dx and d8. > https://developer.android.com/studio/preview/features/index.html >

Re: Review Request: JDK-8193159: Reduce the number of classes loaded due to NativeLibrary

On 12/6/17 6:08 PM, Martin Buchholz wrote: Google decided that LinkedList is almost never the best choice, so any use of LinkedList is discouraged. ArrayDeque's backing array never shrinks, so you might want to give it an explicit initial size. The initial size is 16 which is okay.  I

Re: RFR(s): 8177681: Remove methods Runtime.getLocalized{Input, Output}Stream

2017/12/6 17:33:36 -0500, stuart.ma...@oracle.com: > Please review the removal of these methods, which were part of an obsolete > internationalization mechanism. They were deprecated in JDK 1.1 and > deprecated > for removal in JDK 9. As far as I can see, there is no usage of these methods >

Re: RFR 4358774: Add null InputStream and OutputStream

On Wed, Dec 6, 2017 at 4:01 PM, Jason Mehrens wrote: > Brian, > > My understand is JDK-6533165 is moving the bytes that are rarely invoked > to a cold method. > > Therefore: > > if (closed) { >throw new IOException("Stream closed"); > } > ==becomes=== > if

Re: Finalization and dead references: another proposal

On Wed, Dec 6, 2017 at 7:38 PM Hans Boehm wrote: > We're still trying to deal with a fair amount of code that implicitly > assumes that finalization or similar clean-up will not occur while a > pointer to the affected object is in scope. Which is of course not true. > > As a

Re: Java SE Maths questions.

On 12/6/2017 6:02 PM, David Holmes wrote: cc'ing core-libs-dev. Despite the notation on JEP 306 I don't think there's anyone from hotspot active in this area and most of the below is about SE library classes. David On 7/12/2017 11:39 AM, A Z wrote: These are Java SE questions. -Is it

Re: Review Request: JDK-8193159: Reduce the number of classes loaded due to NativeLibrary

Google decided that LinkedList is almost never the best choice, so any use of LinkedList is discouraged. ArrayDeque's backing array never shrinks, so you might want to give it an explicit initial size. On Wed, Dec 6, 2017 at 4:33 PM, mandy chung wrote: > A tiny startup

Re: Java SE Maths questions.

cc'ing core-libs-dev. Despite the notation on JEP 306 I don't think there's anyone from hotspot active in this area and most of the below is about SE library classes. David On 7/12/2017 11:39 AM, A Z wrote: These are Java SE questions. -Is it likely that JEP 306 could be updated in a Java

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

> On 6 Dec 2017, at 16:12, Claes Redestad wrote: >> >> and i do not understand why the field size is not declared @Stable anymore, >> ok, it can be equals to zero, but in that case the JIT will emit a move >> so it's better than always asking for a move (or i

RFR(XS) : 8181118 : update java/time tests to use RandomFactory from the top level testlibrary

http://cr.openjdk.java.net/~iignatyev/8181118/webrev.00 > 115 lines changed: 0 ins; 108 del; 7 mod; Hi all, could you please review this small fix for java/time tests? RandomFactory has been moved to the top level testlibrary by 8180805[1], but java/time weren't updated when b/c jtreg didn't

Review Request: JDK-8193159: Reduce the number of classes loaded due to NativeLibrary

A tiny startup fix - useArrayDeque instead of LinkedList for ClassLoader.NativeLibrary which is typically loaded at startup for example when loading a JAR file. Thanks Mandy diff --git a/src/java.base/share/classes/java/lang/ClassLoader.java

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi Rémi, On 2017-12-06 23:57, Remi Forax wrote: Hi Claes, - both constructors of SubList should be package private, deal! - in listIterator, i can be declared outside of the ListIterator as a local variable that would be captured by the anonymous class, so index is not used inside the

Re: Android and Log4j

I can neither confirm nor deny that dx is going to die, but it sure looks like "Google" is replacing it with "D8". https://android-developers.googleblog.com/2017/08/next-generation-dex-compiler-now-in.html On Wed, Dec 6, 2017 at 2:03 PM, wrote: > > >

Re: Fw: Question about JEP 306.

PS With a more concrete example below On 12/5/2017 6:55 PM, Joseph D. Darcy wrote: Hello, On 12/5/2017 5:07 PM, David Holmes wrote: Adding core-libs-dev as both mailing lists are named in this JEP. [snip] It should also be the case that there should be a round half up for the

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi, On 2017-12-06 22:20, Martin Buchholz wrote: Guava struggled with this as well with their immutable collections.  You could look at their revision history (I haven't). Maybe they got rid of SingletonImmutableList for the same reason? I've not looked at guava sources, but I've seen

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi Claes, - both constructors of SubList should be package private, - in listIterator, i can be declared outside of the ListIterator as a local variable that would be captured by the anonymous class, so index is not used inside the anonymous class. Also you can use the diamond syntax for

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi Jonathan, On 2017-12-06 21:58, Jonathan Bluett-Duncan wrote: Hi Claes, Looking at http://cr.openjdk.java.net/~redestad/8193128/open.00/src/java.base/share/classes/java/util/ImmutableCollections.java.cdiff.html

Re: RFR(s): 8177681: Remove methods Runtime.getLocalized{Input,Output}Stream

+1,  About time! On 12/6/2017 5:33 PM, Stuart Marks wrote: Hi all, Please review the removal of these methods, which were part of an obsolete internationalization mechanism. They were deprecated in JDK 1.1 and deprecated for removal in JDK 9. As far as I can see, there is no usage of these

Re: RFR(s): 8177681: Remove methods Runtime.getLocalized{Input, Output}Stream

+1 Brian On Dec 6, 2017, at 2:33 PM, Stuart Marks wrote: > Please review the removal of these methods, which were part of an obsolete > internationalization mechanism. They were deprecated in JDK 1.1 and > deprecated for removal in JDK 9. As far as I can see, there

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

Hi Sherman, Looking good. Deflater(573) and Inflater(398), and ZipFile(890):    For consistency, where is says "phantom-reachable" in the finalize methods it can say "unreachable". ZStreamRef:  - line 92: FinalizableZStreamRef  - owner should be final Regards,  Roger On 12/4/2017 6:14 PM,

RFR(s): 8177681: Remove methods Runtime.getLocalized{Input,Output}Stream

Hi all, Please review the removal of these methods, which were part of an obsolete internationalization mechanism. They were deprecated in JDK 1.1 and deprecated for removal in JDK 9. As far as I can see, there is no usage of these methods anywhere. Bug link:

Re: Android and Log4j

> De: "Martin Buchholz" > À: "Remi Forax" > Cc: "Ralph Goers" , "core-libs-dev" > > Envoyé: Mercredi 6 Décembre 2017 22:35:42 > Objet: Re: Android and Log4j > Very latest Android Studio comes

Re: Android and Log4j

Hi Google :) great news. Rémi > De: "Martin Buchholz" > À: "Remi Forax" > Cc: "Ralph Goers" , "core-libs-dev" > > Envoyé: Lundi 4 Décembre 2017 21:03:23 > Objet: Re: Android and Log4j > On

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On 12/5/17 8:41 PM, Bernd Eckenfels wrote: Should the test also check for the case the generator returns under- and oversized arrays? Did you mean that the default implementation (and various overriding implementations) of toArray(generator) should do checks on the array that's returned

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Guava struggled with this as well with their immutable collections. You could look at their revision history (I haven't). Maybe they got rid of SingletonImmutableList for the same reason? On Wed, Dec 6, 2017 at 12:21 PM, Claes Redestad wrote: > Hi, > > please help

Re: RFR 4358774: Add null InputStream and OutputStream

Brian, My understand is JDK-6533165 is moving the bytes that are rarely invoked to a cold method. Therefore: if (closed) { throw new IOException("Stream closed"); } ==becomes=== if (closed) { throw sc(); } private static IOException sc() { return new IOException("Stream

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi Claes, Looking at http://cr.openjdk.java.net/~redestad/8193128/open.00/src/java.base/share/classes/java/util/ImmutableCollections.java.cdiff.html, there are sections labelled --- 646,657 and --- 834,845 where lines like `Objects.requireNonNull(0 /* zero */);` are written. I believe

Re: RFR 4358774: Add null InputStream and OutputStream

On Dec 6, 2017, at 12:46 PM, Patrick Reinhart wrote: >> Yes I still need to look through the JDK source base for some code to >> replace with this, assuming this is approved. > > You got min - even I’m not eligible to give you an official one :-) Thanks. >> Is there also a

Re: RFR 4358774: Add null InputStream and OutputStream

> Am 06.12.2017 um 21:43 schrieb Brian Burkhalter : > > On Dec 6, 2017, at 12:36 PM, Patrick Reinhart > wrote: > >> Sounds great, perfect to remove some more own code… > > Yes I still need to look through the JDK

Re: RFR 4358774: Add null InputStream and OutputStream

On Dec 6, 2017, at 12:36 PM, Patrick Reinhart wrote: > Sounds great, perfect to remove some more own code… Yes I still need to look through the JDK source base for some code to replace with this, assuming this is approved. > Is there also a issue for the same kind of

Re: RFR 4358774: Add null InputStream and OutputStream

Sounds great, perfect to remove some more own code… Is there also a issue for the same kind of methods for Reader and Writer? -Patrick > Am 06.12.2017 um 20:00 schrieb Brian Burkhalter : > > https://bugs.openjdk.java.net/browse/JDK-4358774 >

[10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi, please help review this patch to consolidate the number of implementation classes returned by the static collection factories: http://cr.openjdk.java.net/~redestad/8193128/open.00/ I set out to explore options for addressing small inefficiencies we've been running into, the latest after

Re: RFR 4358774: Add null InputStream and OutputStream

Jason, On Dec 6, 2017, at 11:54 AM, Jason Mehrens wrote: > For nullInputStream would it make any sense to use the ByteArrayInputStream > with a (private static) empty byte array? Maybe 'return new > ByteArrayInputStream("".getBytes());'? One side effect is that

Re: RFR 4358774: Add null InputStream and OutputStream

Brian, For nullInputStream would it make any sense to use the ByteArrayInputStream with a (private static) empty byte array? Maybe 'return new ByteArrayInputStream("".getBytes());'? One side effect is that mark support returns true. Does it make sense to follow the advice in

Re: RFR 8191216: SimpleTimeZone.clone() has a data race on cache fields

Hi Peter, Venkat, Thank you for the fix. It looks good to me. Improved performance is a nice bonus! Would you be able to provide with a regression test? Naoto On 12/6/17 6:10 AM, Peter Levart wrote: Hi, On 12/06/2017 02:30 PM, Alan Bateman wrote: I think this class is normally maintained

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On 12/5/17 6:54 PM, Tagir Valeev wrote: I think, CopyOnWriteArrayList and a List returned by Arrays.asList deserve specialized implementation as well. Sure, I can add one to Array.asList right away (as part of this changeset). It's even covered by tests already. I'll work with Martin to

Re: RFR 4358774: Add null InputStream and OutputStream

The name “emptyStream()” was considered for InputStream and “discardingStream()” for OutputStream. It was thought that “null” or “empty” would be more likely to be found by developers due to familiarity. FWIW there is precedent in third party libraries for the “null” names. Brian On Dec 6,

Re: RFR 4358774: Add null InputStream and OutputStream

"null" is a significant term in the Java ecosystem, and the relationship here, to /dev/null or NUL seems somewhat tenuous. Have any other names been considered?  At least for the InputStream, calling it an "empty stream" seems more intuitive than a "null stream". -- Jon On 12/6/17 11:00

RFR 4358774: Add null InputStream and OutputStream

https://bugs.openjdk.java.net/browse/JDK-4358774 http://cr.openjdk.java.net/~bpb/4358774/webrev.00/ Add nullStream() method to each of InputStream and OutputStream. Thanks, Brian

Re: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

Thanks Vyom, these should be fixed in: http://cr.openjdk.java.net/~robm/8160768/webrev.07/ Comments inline: On 06/12/17 22:14, vyom tewari wrote: > Hi Rob, > > Please find below comments. > > DefaultLdapDnsProvider.java > >  line 35:     convert it to for-each code will be more readable. >

Re: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

Hi Rob, Please find below comments. DefaultLdapDnsProvider.java  line 35:     convert it to for-each code will be more readable. LdapDnsProviderService.java  line 21: constant name does not follow Java naming convention, there are other places as well please fix it. getInstance() is

Proposal for New Functionality: Allow module-info merging in GenModuleInfoSource.java

Hi All, Currently, GenModuleInfoSource.java does not allow you to merge extra module-info files into the primary module-info file (for a given module) at build time. Put simply; I think it should have this functionality. Can committers please review and opine? You can already see this code

Re: RFR 8191216: SimpleTimeZone.clone() has a data race on cache fields

Hi, On 12/06/2017 02:30 PM, Alan Bateman wrote: I think this class is normally maintained on i18n-dev but I think introducing the Cache object looks good and making this much easier to understand. -Alan Thanks Alan, I'm forwarding to i18n-dev to see if maintainers of that part of JDK

Re: RFR 8191216: SimpleTimeZone.clone() has a data race on cache fields

On 06/12/2017 11:32, David Holmes wrote: Hi Peter, On 6/12/2017 9:08 PM, Peter Levart wrote: Hi David, Can I consider your comment as a Review? I'd like to get this patch into JDK10 if possible. No sorry. I see what you're doing and I think it is okay but the regular owners/maintainers of

RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java

Hi All, We have a bug in OpenJDK where if you pass an info-only option (like -agentlib:jdwp=help) in through the JNI interface, it can exit your code with RC 0. I think this is a bug because if you planned to do anything after starting a Java VM, you have to do it in an exit hook. If an

Re: RFR 8191216: SimpleTimeZone.clone() has a data race on cache fields

Hi Peter, On 6/12/2017 9:08 PM, Peter Levart wrote: Hi David, Can I consider your comment as a Review? I'd like to get this patch into JDK10 if possible. No sorry. I see what you're doing and I think it is okay but the regular owners/maintainers of this code need to have the say on any

Re: RFR 8191216: SimpleTimeZone.clone() has a data race on cache fields

Hi David, Can I consider your comment as a Review? I'd like to get this patch into JDK10 if possible. Regards, Peter On 11/28/2017 08:17 AM, David Holmes wrote: Hi Peter, I like what you have done here. That said the general thread-unsafeness of the code in SimpleTimeZone still causes me