From stuart.marks at oracle.com Sat Oct 3 02:20:06 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 2 Oct 2015 19:20:06 -0700 Subject: Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application In-Reply-To: <560C3B56.4060309@gmx.de> References: <560C3B56.4060309@gmx.de> Message-ID: <560F3B56.3060309@oracle.com> Hi Sebastian, Good to see you contributing to OpenJDK again! I'm not sure it's sensible to have a regression test for this sort of thing. This seems more like static code analysis to me. In fact, Findbugs already seems to have a pattern that detects calls to the Boolean constructor: http://findbugs.sourceforge.net/bugDescriptions.html#DM_BOOLEAN_CTOR (I believe that people are running Findbugs over the JDK regularly, but we don't really have a workflow for processing diagnostics that it generates.) Now, regression tests are there to prevent bugs from reappearing once they're fixed. So how would we do this? For cases like this, there's another approach, which is deprecation: https://bugs.openjdk.java.net/browse/JDK-4941777 If the Boolean constructor is deprecated, then a warning will be issued wherever they're called. By default, the JDK build treats warnings as errors, so this will effectively prohibit any uses of Boolean constructors. (The two legitimate uses of the Boolean constructor can be annotated with @SuppressWarnings to prevent this.) An interesting exercise would be to add the @Deprecated annotation to the Boolean constructor and build the JDK and see how many warnings result. That might be a quick way to find the code that needs to be fixed. As for your other questions: 2. Boolean is a special case since there are exactly two boxed boolean values. Possibly Byte as well, since all Byte values are cached. (See spec for Byte.valueOf(byte).) There is a moderate preference for valueOf() over the constructors of Character, Integer, and Short, since those cache a subset of values. It's not clear to me these are worth worrying about though. (Long, Float, and Double don't have caches.) 3. I would say that it's more likely that future JDK enhancements would be able to optimize auto-boxing than explicit method calls that deal with boxed values. 4. Unfortunately, different portions of code are handled by different groups, and are thus reviewed on different mailing lists. I think asking on jdk9-dev, as you've been doing, about where things need to be reviewed, is the right thing to do. I'll reply on macosx-port-dev on your specific changes there. s'marks On 9/30/15 12:43 PM, Sebastian Sickelmann wrote: > Hi, > > a few days ago i started to investigate JDK-5108778[1] and started > discussions > for a small parts of it in macosx-port-dev[2] and hotspot-dev[3]. As > suggested by > Alexandr there should be a test that saves for regression for such > changes. I would > like to introduce a test like[4], what do you think? > > It scans for all jimage-files in /lib/modules and opens every > classfile > and scans every-method for a NEW-bytecode to a Wrapper-Type Classname. > Every match that is not in the Wrapper-Type itself is reported and counted. > > > I have some questions about this: > 1. Is there a good way to get rid of the "9.0" part for reading the > classes out of the jimage? > 2. What is with other Wrapper-Types (Byte,Short,Integer,Long, Character) > is it a good idea to also change such ctor of those? Would someone raise > an enhancement > for those? > 3. How are value-types related to such an issue. Is it counterproductive > to change to XYZ.valueOf Method uses, or should we change to autoboxing > where possible? I haven't changed to autoboxing where i thought it would > be much less readable. > 4. Should the changes be discussed in the group-lists? Or is there a > good place for discussion off central-changes? > > > -- Sebastian > > > [1] https://bugs.openjdk.java.net/browse/JDK-5108778 > [2] > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2015-September/006970.html > [3] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-September/020018.html > [4] > https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/test_0/webrev/index.html > From sebastian.sickelmann at gmx.de Sun Oct 4 07:00:46 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sun, 4 Oct 2015 09:00:46 +0200 Subject: Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application In-Reply-To: <560F3B56.3060309@oracle.com> References: <560C3B56.4060309@gmx.de> <560F3B56.3060309@oracle.com> Message-ID: <5610CE9E.7060600@gmx.de> Hi Stuart, thanks for the feedback. I will answer inline. On 10/03/2015 04:20 AM, Stuart Marks wrote: > Hi Sebastian, > > Good to see you contributing to OpenJDK again! > > I'm not sure it's sensible to have a regression test for this sort of > thing. This seems more like static code analysis to me. In fact, > Findbugs already seems to have a pattern that detects calls to the > Boolean constructor: > > http://findbugs.sourceforge.net/bugDescriptions.html#DM_BOOLEAN_CTOR > > (I believe that people are running Findbugs over the JDK regularly, > but we don't really have a workflow for processing diagnostics that it > generates.) That would be the best case. It checks the source-code and not the resulting classfiles. It would be much better if we could integrate Findbugs somehow. > > Now, regression tests are there to prevent bugs from reappearing once > they're fixed. So how would we do this? For cases like this, there's > another approach, which is deprecation: > > https://bugs.openjdk.java.net/browse/JDK-4941777 > > If the Boolean constructor is deprecated, then a warning will be > issued wherever they're called. By default, the JDK build treats > warnings as errors, so this will effectively prohibit any uses of > Boolean constructors. (The two legitimate uses of the Boolean > constructor can be annotated with @SuppressWarnings to prevent this.) > > An interesting exercise would be to add the @Deprecated annotation to > the Boolean constructor and build the JDK and see how many warnings > result. That might be a quick way to find the code that needs to be > fixed. I have tried it, but i think i have done something wrong. I build via make clean JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" DISABLE_WARNINGS="-Xlint:all" LOG=info images CONF=linux-x86_64-normal-server-release And looked at the resulting build.log but get only one warning: ~/jdk9$ less build/linux-x86_64-normal-server-release/build.log | grep warning | grep Boolean /home/sebastian/jdk9/jaxp/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/JavaClass.java:464: warning: [deprecation] Boolean(String) in Boolean has been deprecated Where the class-scanning shows me 92 hits. I have looked to some of those to evaluate if there are some @SuppressWarnings but didn't find any. So i think the problem is somewhere in the Makefile/Autoconf-files. Unfortunately i dont't have enough knowledge in those to have an idea where to search. > > As for your other questions: > > 2. Boolean is a special case since there are exactly two boxed boolean > values. Possibly Byte as well, since all Byte values are cached. (See > spec for Byte.valueOf(byte).) There is a moderate preference for > valueOf() over the constructors of Character, Integer, and Short, > since those cache a subset of values. It's not clear to me these are > worth worrying about though. (Long, Float, and Double don't have caches.) I agree. Only Byte and maybe Character and Short should be considered. I have looked at all Wrappertypes and find that also Long has a Cache. I think Character is worth to think about, because i think in most cases the cached area is used. Is there a big downside of using autoboxing/valueOf for all Classes? > > 3. I would say that it's more likely that future JDK enhancements > would be able to optimize auto-boxing than explicit method calls that > deal with boxed values. So Integer, Long, Float and Double and maybe Short should be changed not before we can say what is the best optimization strategy for those. > 4. Unfortunately, different portions of code are handled by different > groups, and are thus reviewed on different mailing lists. I think > asking on jdk9-dev, as you've been doing, about where things need to > be reviewed, is the right thing to do. That is no problem. Should we create multiple "sub-task" in JBS for each area ? > > I'll reply on macosx-port-dev on your specific changes there. > > s'marks -- Sebastian > > > On 9/30/15 12:43 PM, Sebastian Sickelmann wrote: >> Hi, >> >> a few days ago i started to investigate JDK-5108778[1] and started >> discussions >> for a small parts of it in macosx-port-dev[2] and hotspot-dev[3]. As >> suggested by >> Alexandr there should be a test that saves for regression for such >> changes. I would >> like to introduce a test like[4], what do you think? >> >> It scans for all jimage-files in /lib/modules and opens every >> classfile >> and scans every-method for a NEW-bytecode to a Wrapper-Type Classname. >> Every match that is not in the Wrapper-Type itself is reported and >> counted. >> >> >> I have some questions about this: >> 1. Is there a good way to get rid of the "9.0" part for reading the >> classes out of the jimage? >> 2. What is with other Wrapper-Types (Byte,Short,Integer,Long, Character) >> is it a good idea to also change such ctor of those? Would someone raise >> an enhancement >> for those? >> 3. How are value-types related to such an issue. Is it counterproductive >> to change to XYZ.valueOf Method uses, or should we change to autoboxing >> where possible? I haven't changed to autoboxing where i thought it would >> be much less readable. >> 4. Should the changes be discussed in the group-lists? Or is there a >> good place for discussion off central-changes? >> >> >> -- Sebastian >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-5108778 >> [2] >> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2015-September/006970.html >> >> [3] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-September/020018.html >> >> [4] >> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/test_0/webrev/index.html >> >> > From stuart.marks at oracle.com Tue Oct 6 23:33:52 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 6 Oct 2015 16:33:52 -0700 Subject: Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application In-Reply-To: <5610CE9E.7060600@gmx.de> References: <560C3B56.4060309@gmx.de> <560F3B56.3060309@oracle.com> <5610CE9E.7060600@gmx.de> Message-ID: <56145A60.1010900@oracle.com> On 10/4/15 12:00 AM, Sebastian Sickelmann wrote: >> (I believe that people are running Findbugs over the JDK regularly, >> but we don't really have a workflow for processing diagnostics that it >> generates.) > That would be the best case. It checks the source-code and not the > resulting classfiles. It would be much better if we could integrate > Findbugs somehow. OK. My main point here is that there are static analysis frameworks out there already, such as FindBugs, SonarQube, etc., so we needn't develop duplicate technology for static analysis and put it into the regression suite. (Note that FindBugs analyzes bytecodes, not source code, but it still falls into the general category of static analysis tools.) >> An interesting exercise would be to add the @Deprecated annotation to >> the Boolean constructor and build the JDK and see how many warnings >> result. That might be a quick way to find the code that needs to be >> fixed. > I have tried it, but i think i have done something wrong. > I build via > > make clean JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" > DISABLE_WARNINGS="-Xlint:all" LOG=info images > CONF=linux-x86_64-normal-server-release > > And looked at the resulting build.log but get only one warning: [...] Hm, strange. I did make clean JAVAC_WARNINGS='-Xlint:deprecation -Xmaxwarns 10000' \ DISABLE_WARNINGS='-Xlint:deprecation -Xmaxwarns 10000' images and grep 'warning: \[deprecation\] Boolean' logfile results in 94 matches. That's two more than your 92, since I added @Deprecated to the Boolean(String) constructor as well, and there are warnings for that. But my results match what you expected, which is good. It could be that -Xlint:all adds so many other warnings that it hits the default limit of 100 very quickly, and the deprecation warnings are omitted. >> 2. Boolean is a special case since there are exactly two boxed boolean >> values. Possibly Byte as well, since all Byte values are cached. (See >> spec for Byte.valueOf(byte).) There is a moderate preference for >> valueOf() over the constructors of Character, Integer, and Short, >> since those cache a subset of values. It's not clear to me these are >> worth worrying about though. (Long, Float, and Double don't have caches.) > I agree. Only Byte and maybe Character and Short should be considered. I > have looked at all Wrappertypes and find that also Long has a Cache. I > think Character is worth to think about, because i think in most cases > the cached area is used. > > Is there a big downside of using autoboxing/valueOf for all Classes? At this point I'd say that in an overwhelming number of cases, autoboxing is preferable to the explicit boxing and unboxing calls like Integer.valueOf() and Integer.intValue(). And both of autoboxing and explicit boxing are preferable to calling the constructors. I can only think of a few cases where it *might* be useful to have explicit un/boxing calls, such as if the boxed object is nullable (as in one of the cases in your macosx-port-dev review), or if somebody does something that is truly sensitive to the identity of a box, such as synchronization. But I'd argue that such code is bad anyway and should be fixed. A related point, which Stephen Colebourne has taken up on core-libs-dev, is whether and how many of the box constructors should be deprecated. >> 3. I would say that it's more likely that future JDK enhancements >> would be able to optimize auto-boxing than explicit method calls that >> deal with boxed values. > So Integer, Long, Float and Double and maybe Short should be changed not > before we can say what is the best optimization strategy for those. Sorry, I didn't really finish my thought. Suppose there's a call like this: Integer box = new Integer(17); It provides an immediate benefit to convert this to Integer box = Integer.valueOf(17); since the library can use its cache. But there's still a method call. If the code is converted to this: Integer i3 = 17; there is an additional immediate benefit of reducing code clutter. Plus, there is a potential future benefit that the compiler might be able to optimize this more than an explicit method call. This is speculation on my part, though. Anyway, since autoboxing reduces code clutter, and since it *might* enable better optimization in the future, I'd say that we should convert most code directly to autoboxing. >> 4. Unfortunately, different portions of code are handled by different >> groups, and are thus reviewed on different mailing lists. I think >> asking on jdk9-dev, as you've been doing, about where things need to >> be reviewed, is the right thing to do. > That is no problem. Should we create multiple "sub-task" in JBS for each > area ? Once you've developed a patch for a particular area, you'll need a person to sponsor the change for you. This is the person who will handle the actual commit. Presumably that person could create JIRA sub-tasks for you. If you eventually get the Author role, you can apply for a JIRA account, and at that point you can create and modify the sub-tasks yourself. s'marks From dalibor.topic at oracle.com Fri Oct 9 19:49:41 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 9 Oct 2015 21:49:41 +0200 Subject: CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms In-Reply-To: <5F00A8A5-A66D-4739-AE9F-AB3BE96C22AC@oracle.com> References: <20150929164407.GI3157@redhat.com> <5F00A8A5-A66D-4739-AE9F-AB3BE96C22AC@oracle.com> Message-ID: <56181A55.3030107@oracle.com> Vote: Yes. The OpenJDK Porters Group is a sponsor of this Project. cheers, dalibor topic, OpenJDK Porters Group Lead -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From bob.vandette at oracle.com Tue Oct 13 17:05:29 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 13 Oct 2015 13:05:29 -0400 Subject: Result: New Project: Mobile Message-ID: <97F00014-ADA8-4EDF-9EBD-4BF3D99700B4@oracle.com> Voting on the Mobile Project with initial lead Bob Vandette [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the new Project and its initial Lead. - Bob Vandette [1] http://mail.openjdk.java.net/pipermail/announce/2015-September/000200.html [2] http://openjdk.java.net/bylaws#lazy-consensus From sebastian.sickelmann at gmx.de Thu Oct 22 16:03:58 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Thu, 22 Oct 2015 18:03:58 +0200 Subject: How to update my cr.openjdk.java.net ssh key pairs? Message-ID: <562908EE.4070805@gmx.de> /Hi All, ////I hope there is any one who could help me solve this problem. ////I have an account for cr.openjdk.java.net. However for some reason I //think i somehow broke my pub key on the server. In one call of rsync it works, and a few seconds later, where i realised that i have done a typing error in the rsync command my key is not accepted anymore.//////Is there a way to recreate my key from the initial request, or maybe i can send it againg? I found on this mailing-list a email-address mentioned: keys at openjdk.java.net,//which i mailed 2 days ago. Is this email-address the right way? If it was my faulty rsync command, is there a way to prevent it to technically prevent this in future? I have done: rsync -av 8139754/ sebastian at cr.openjdk.java.net: instead of rsync -av 8139754 sebastian at cr.openjdk.java.net: Thanks for your support Sebastian / From sebastian.sickelmann at gmx.de Fri Oct 23 02:35:41 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 23 Oct 2015 04:35:41 +0200 Subject: How to update my cr.openjdk.java.net ssh key pairs? In-Reply-To: <562908EE.4070805@gmx.de> References: <562908EE.4070805@gmx.de> Message-ID: <56299CFD.1060009@gmx.de> For future reference, the list for this type of access issue is ops at openjdk.java.net And yes. The Slash after the directory that should be sync'ed changed the file permissions of my home directory in such a way the system does not trust my key anymore. But now it works again. -- Sebastian On 10/22/2015 06:03 PM, Sebastian Sickelmann wrote: > /Hi All, ////I hope there is any one who could help me solve this problem. ////I have an account for cr.openjdk.java.net. However for some reason I //think i somehow broke my pub key on the server. In one call of rsync it > works, and a few seconds later, where i realised that i have done a > typing error in the rsync command my key is not accepted anymore.//////Is there a way to recreate my key from the initial request, or maybe i > can send it againg? I found on this mailing-list a email-address > mentioned: keys at openjdk.java.net,//which i mailed 2 days ago. Is this email-address the right way? If it > was my faulty rsync command, is there a way to prevent it to technically > prevent this in future? I have done: rsync -av 8139754/ > sebastian at cr.openjdk.java.net: instead of rsync -av 8139754 > sebastian at cr.openjdk.java.net: Thanks for your support Sebastian / > > From adinn at redhat.com Fri Oct 23 08:35:37 2015 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 23 Oct 2015 09:35:37 +0100 Subject: What is the status of JEP 159 and it's accompanying implementation? Message-ID: <5629F159.4040904@redhat.com> First off, apologies if the discuss list is not the right place to post this. As a nod to the dubiousness of that address and in ignorance of any possible JEP process that might apply I have cced this to: Thomas Wuerthinger as the owner of JEP 159 John Rose as one of those who reviewed it Mark Reinhold as ultimate JEP wrangler and curator The subject line says almost all. Is the JEP still active and moving towards inclusion in a dev build? Is there anything Red Hat can do to help it progress into a release? I'll add that the reason for asking is that Red Hat is interested in this JEP as a means to better support hot redeploy. n.b. also cced are two highly interested parties from Red Hat, Stuart Douglas (author of fakereplace, a JRebel-like tool) and Max Andersen (dev manager for JBoss Developer Studio, Red Hat's eclipse-based Java EE development suite). Please be sure to include them in any follow-ups. Thanks! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland)