From hadrabap at gmail.com Fri Sep 11 11:14:26 2015 From: hadrabap at gmail.com (Petr Hadraba) Date: Fri, 11 Sep 2015 13:14:26 +0200 Subject: Performance Issues Message-ID: <5C293CDA-F973-4993-986A-6267B27655B2@gmail.com> Hello guys, I?m facing a strange issue. Let me explain: I?ve been using JDK 1.8.0_51 with no issues. A few days earlier an JDK 1.8.0_60 update comms in place and I tried that. My problem is that all of my JUnit tests become extremely slow. Its a complex ANT-based build system which builds around three EARs. Each EAR consist of several sub-modules which are covered with JUnit. On JDK 1.8.0_51 the build process takes around one minute. When using JDK 1.8.0_60 it takes more than five minutes. Well, to be honest, I didn?t debug it yet, need to work on it so I downgraded back to the 51 build. But I?m quite curious what?s going on here. My JUnit version is the default one coming with NetBeans (JUnit 4.10). I?m using Mac OS X 10.10.5. Is anybody here experiencing the same problem? Maybe I?ve just mislead some kind of configuration etc? Thank you very much for your help. With kind regards, PETR From tobi at ultramixer.com Mon Sep 14 09:51:39 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 14 Sep 2015 11:51:39 +0200 Subject: JarBundler / AppBundler to use Java 1.6 on Mac 10.11 / El Capitan Message-ID: <9CAF7EF0-0102-43D2-8127-E13311FF468A@ultramixer.com> Hi everbody, our Java application can?t be started on Mac OS X 10.11 / El Capitan anymore because the Java launcher seams to not recognise the Info.plist format anymore? Does anyone has found a solution? Is it possible to use the new AppBundler for Java 6 too? Is there a new JavaAppLauncher for Mac 10.11 available? What?s the reason for the problem on 10.11? Best regards, Tobi From Sergey.Bylokhov at oracle.com Mon Sep 14 14:58:36 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 14 Sep 2015 17:58:36 +0300 Subject: Performance Issues In-Reply-To: <5C293CDA-F973-4993-986A-6267B27655B2@gmail.com> References: <5C293CDA-F973-4993-986A-6267B27655B2@gmail.com> Message-ID: <55F6E09C.2010202@oracle.com> Hi, Petr. Probably the compiler-dev is right place to ask this question. Did you recognize the hot method? On 11.09.2015 14:14, Petr Hadraba wrote: > Hello guys, > > I?m facing a strange issue. Let me explain: > > I?ve been using JDK 1.8.0_51 with no issues. A few days earlier an JDK 1.8.0_60 update comms in place and I tried that. My problem is that all of my JUnit tests become extremely slow. Its a complex ANT-based build system which builds around three EARs. Each EAR consist of several sub-modules which are covered with JUnit. > > On JDK 1.8.0_51 the build process takes around one minute. When using JDK 1.8.0_60 it takes more than five minutes. > > Well, to be honest, I didn?t debug it yet, need to work on it so I downgraded back to the 51 build. But I?m quite curious what?s going on here. My JUnit version is the default one coming with NetBeans (JUnit 4.10). > > I?m using Mac OS X 10.10.5. > > Is anybody here experiencing the same problem? Maybe I?ve just mislead some kind of configuration etc? > > Thank you very much for your help. > > With kind regards, > > PETR > -- Best regards, Sergey. From ebakke at mit.edu Fri Sep 18 18:18:18 2015 From: ebakke at mit.edu (Eirik Bakke) Date: Fri, 18 Sep 2015 18:18:18 +0000 Subject: Bug: SystemFlavorMap.addFlavorForUnencodedNative ineffective on MacOS Message-ID: Hi, macosx-port-dev. There seems to be a bug in the MacOS implementation underlying SystemFlavorMap.addFlavorForUnencodedNative. Where would the best place to report this be? Is this the relevant mailing list? The bug report follows: My Java application allows users to paste selections from Microsoft Excel. The data is retrieved using Excel's binary BIFF8 format rather than in plain text format in order to reliably detect date formatting, preserve numerical precision, and such. On Windows, getting to the relevant clipboard InputStream can be achieved by calling SystemFlavorMap.addUnencodedNativeForFlavor to map a new DataFlavor to a native data type identifier. On MacOS, however, there seems to be a bug that renders SystemFlavorMap.addUnencodedNativeForFlavor ineffective. Looking at the JDK source code, the bug seems to be that sun.lwawt.macosx.CDataTransferer.registerFormatWithPasteboard is never called when SystemFlavorMap.addUnencodedNativeForFlavor/ addFlavorForUnencodedNative is used to register a new native clipboard data format. This leads Java_sun_lwawt_macosx_CClipboard_getClipboardFormats in macosx/native/sun/awt/CClipboard.m to never return formats of the new type, because indexForFormat (in CDataTransferer.m) will always return -1. The observation above lead me to a workaround for the bug, which is to call sun.awt.datatransfer.DataTransferer.getInstance().getFormatsForFlavor(myNewFlavor, (SystemFlavorMap) SystemFlavorMap.getDefaultFlavorMap()) once after first mapping the flavor using addUnencodedNativeForFlavor and addFlavorForUnencodedNative. This works because the call to getFormatsForFlavor forces DataTransferer.getFormatForNativeAsLong to be called with the new native data type identifier, which in turn causes registerFormatWithPasteboard to be called in CDataTransferer.m. I'm worried that the workaround will cease to work in the future, however, since it relies on an obscure side-effect of a method in a private API from the sun.awt package. I've assembled a minimal example here: https://gist.github.com/eirikbakke/e8022f9f8d26c28eecd7 -- Eirik From Sergey.Bylokhov at oracle.com Fri Sep 18 18:35:54 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 18 Sep 2015 21:35:54 +0300 Subject: Bug: SystemFlavorMap.addFlavorForUnencodedNative ineffective on MacOS In-Reply-To: References: Message-ID: <55FC598A.2050402@oracle.com> Hi, Eirik. Thanks for report! Please file a new bug at http://bugreport.sun.com/bugreport , don't forget to add a steps to reproduce, then send me a bugid. On 18.09.15 21:18, Eirik Bakke wrote: > Hi, macosx-port-dev. > > There seems to be a bug in the MacOS implementation underlying SystemFlavorMap.addFlavorForUnencodedNative. Where would the best place to report this be? Is this the relevant mailing list? > > The bug report follows: > > My Java application allows users to paste selections from Microsoft Excel. The data is retrieved using Excel's binary BIFF8 format rather than in plain text format in order to reliably detect date formatting, preserve numerical precision, and such. On Windows, getting to the relevant clipboard InputStream can be achieved by calling SystemFlavorMap.addUnencodedNativeForFlavor to map a new DataFlavor to a native data type identifier. On MacOS, however, there seems to be a bug that renders SystemFlavorMap.addUnencodedNativeForFlavor ineffective. > > Looking at the JDK source code, the bug seems to be that sun.lwawt.macosx.CDataTransferer.registerFormatWithPasteboard is never called when SystemFlavorMap.addUnencodedNativeForFlavor/ addFlavorForUnencodedNative is used to register a new native clipboard data format. This leads Java_sun_lwawt_macosx_CClipboard_getClipboardFormats in macosx/native/sun/awt/CClipboard.m to never return formats of the new type, because indexForFormat (in CDataTransferer.m) will always return -1. > > The observation above lead me to a workaround for the bug, which is to call sun.awt.datatransfer.DataTransferer.getInstance().getFormatsForFlavor(myNewFlavor, (SystemFlavorMap) SystemFlavorMap.getDefaultFlavorMap()) once after first mapping the flavor using addUnencodedNativeForFlavor and addFlavorForUnencodedNative. This works because the call to getFormatsForFlavor forces DataTransferer.getFormatForNativeAsLong to be called with the new native data type identifier, which in turn causes registerFormatWithPasteboard to be called in CDataTransferer.m. I'm worried that the workaround will cease to work in the future, however, since it relies on an obscure side-effect of a method in a private API from the sun.awt package. > > I've assembled a minimal example here: https://gist.github.com/eirikbakke/e8022f9f8d26c28eecd7 > > -- Eirik > -- Best regards, Sergey. From ebakke at mit.edu Fri Sep 18 19:01:02 2015 From: ebakke at mit.edu (Eirik Bakke) Date: Fri, 18 Sep 2015 19:01:02 +0000 Subject: Bug: SystemFlavorMap.addFlavorForUnencodedNative ineffective on MacOS In-Reply-To: <55FC598A.2050402@oracle.com> References: <55FC598A.2050402@oracle.com> Message-ID: Hi, Sergey. I've filed the bug and received review ID JI-9024567 for now. Thanks! -- Eirik On 9/18/15, 2:58 PM, "Bug-Report-Daemon_WW at ORACLE.COM" wrote: >Dear Java Developer, >Thank you for reporting this issue. > >We are evaluating this report and have assigned it a Review ID: >JI-9024567. In the event this report is determined to be a defect or >enhancement request, it will be referenced with a new Bug ID and will be >listed on Bugs.java.com. For other related issues, please visit our Bug >Database at http://bugs.java.com. > >We try to process all newly posted bugs in a timely manner, but make no >promises about the amount of time in which a bug might be fixed. If the >issue just reported could have a major impact on your project, consider >using one of the technical support offerings available at Oracle Support. > >Regards, >Java Community Developer Support > On 9/18/15, 2:35 PM, "Sergey Bylokhov" wrote: >Hi, Eirik. >Thanks for report! Please file a new bug at >http://bugreport.sun.com/bugreport , don't forget to add a steps to >reproduce, then send me a bugid. > > >On 18.09.15 21:18, Eirik Bakke wrote: >> Hi, macosx-port-dev. >> >> There seems to be a bug in the MacOS implementation underlying >>SystemFlavorMap.addFlavorForUnencodedNative. Where would the best place >>to report this be? Is this the relevant mailing list? >> >> The bug report follows: >> >> My Java application allows users to paste selections from Microsoft >>Excel. The data is retrieved using Excel's binary BIFF8 format rather >>than in plain text format in order to reliably detect date formatting, >>preserve numerical precision, and such. On Windows, getting to the >>relevant clipboard InputStream can be achieved by calling >>SystemFlavorMap.addUnencodedNativeForFlavor to map a new DataFlavor to a >>native data type identifier. On MacOS, however, there seems to be a bug >>that renders SystemFlavorMap.addUnencodedNativeForFlavor ineffective. >> >> Looking at the JDK source code, the bug seems to be that >>sun.lwawt.macosx.CDataTransferer.registerFormatWithPasteboard is never >>called when SystemFlavorMap.addUnencodedNativeForFlavor/ >>addFlavorForUnencodedNative is used to register a new native clipboard >>data format. This leads >>Java_sun_lwawt_macosx_CClipboard_getClipboardFormats in >>macosx/native/sun/awt/CClipboard.m to never return formats of the new >>type, because indexForFormat (in CDataTransferer.m) will always return >>-1. >> >> The observation above lead me to a workaround for the bug, which is to >>call >>sun.awt.datatransfer.DataTransferer.getInstance().getFormatsForFlavor(myN >>ewFlavor, (SystemFlavorMap) SystemFlavorMap.getDefaultFlavorMap()) once >>after first mapping the flavor using addUnencodedNativeForFlavor and >>addFlavorForUnencodedNative. This works because the call to >>getFormatsForFlavor forces DataTransferer.getFormatForNativeAsLong to be >>called with the new native data type identifier, which in turn causes >>registerFormatWithPasteboard to be called in CDataTransferer.m. I'm >>worried that the workaround will cease to work in the future, however, >>since it relies on an obscure side-effect of a method in a private API >>from the sun.awt package. >> >> I've assembled a minimal example here: >>https://gist.github.com/eirikbakke/e8022f9f8d26c28eecd7 >> >> -- Eirik >> > > >-- >Best regards, Sergey. From ebakke at mit.edu Fri Sep 18 19:50:32 2015 From: ebakke at mit.edu (Eirik Bakke) Date: Fri, 18 Sep 2015 19:50:32 +0000 Subject: Bug: SystemFlavorMap.addFlavorForUnencodedNative ineffective on MacOS In-Reply-To: References: <55FC598A.2050402@oracle.com> Message-ID: I can see the bug now at http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8136781 . Thanks again! -- Eirik On 9/18/15, 3:01 PM, "macosx-port-dev on behalf of Eirik Bakke" on behalf of ebakke at mit.edu> wrote: Hi, Sergey. I've filed the bug and received review ID JI-9024567 for now. Thanks! -- Eirik On 9/18/15, 2:58 PM, "Bug-Report-Daemon_WW at ORACLE.COM" > wrote: Dear Java Developer, Thank you for reporting this issue. We are evaluating this report and have assigned it a Review ID: JI-9024567. In the event this report is determined to be a defect or enhancement request, it will be referenced with a new Bug ID and will be listed on Bugs.java.com. For other related issues, please visit our Bug Database at http://bugs.java.com. We try to process all newly posted bugs in a timely manner, but make no promises about the amount of time in which a bug might be fixed. If the issue just reported could have a major impact on your project, consider using one of the technical support offerings available at Oracle Support. Regards, Java Community Developer Support On 9/18/15, 2:35 PM, "Sergey Bylokhov" > wrote: Hi, Eirik. Thanks for report! Please file a new bug at http://bugreport.sun.com/bugreport , don't forget to add a steps to reproduce, then send me a bugid. On 18.09.15 21:18, Eirik Bakke wrote: Hi, macosx-port-dev. There seems to be a bug in the MacOS implementation underlying SystemFlavorMap.addFlavorForUnencodedNative. Where would the best place to report this be? Is this the relevant mailing list? The bug report follows: My Java application allows users to paste selections from Microsoft Excel. The data is retrieved using Excel's binary BIFF8 format rather than in plain text format in order to reliably detect date formatting, preserve numerical precision, and such. On Windows, getting to the relevant clipboard InputStream can be achieved by calling SystemFlavorMap.addUnencodedNativeForFlavor to map a new DataFlavor to a native data type identifier. On MacOS, however, there seems to be a bug that renders SystemFlavorMap.addUnencodedNativeForFlavor ineffective. Looking at the JDK source code, the bug seems to be that sun.lwawt.macosx.CDataTransferer.registerFormatWithPasteboard is never called when SystemFlavorMap.addUnencodedNativeForFlavor/ addFlavorForUnencodedNative is used to register a new native clipboard data format. This leads Java_sun_lwawt_macosx_CClipboard_getClipboardFormats in macosx/native/sun/awt/CClipboard.m to never return formats of the new type, because indexForFormat (in CDataTransferer.m) will always return -1. The observation above lead me to a workaround for the bug, which is to call sun.awt.datatransfer.DataTransferer.getInstance().getFormatsForFlavor(myN ewFlavor, (SystemFlavorMap) SystemFlavorMap.getDefaultFlavorMap()) once after first mapping the flavor using addUnencodedNativeForFlavor and addFlavorForUnencodedNative. This works because the call to getFormatsForFlavor forces DataTransferer.getFormatForNativeAsLong to be called with the new native data type identifier, which in turn causes registerFormatWithPasteboard to be called in CDataTransferer.m. I'm worried that the workaround will cease to work in the future, however, since it relies on an obscure side-effect of a method in a private API from the sun.awt package. I've assembled a minimal example here: https://gist.github.com/eirikbakke/e8022f9f8d26c28eecd7 -- Eirik -- Best regards, Sergey. From philip.race at oracle.com Mon Sep 21 21:25:38 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 21 Sep 2015 14:25:38 -0700 Subject: com.apple.concurrent.Dispatch in the modular JDK In-Reply-To: <94162343-0C45-4293-AB5E-6D15C5206909@me.com> References: <555BCECB.8060107@oracle.com> <94162343-0C45-4293-AB5E-6D15C5206909@me.com> Message-ID: <560075D2.4070407@oracle.com> An update on this. We have not found any widespread use of this API The expectation (nascent plan) is that this package will not be carried forward into the modular JDK. I suppose it is possible some new JEP may revive it as a standard API for in JDK 10 but there is no plan for that. -phil. On 05/19/2015 09:28 PM, Andrew Thompson wrote: > A few years ago I had a brief email exchange with Doug Lea I the idea of providing an SPI so platforms could plug in implementations for a "default" ExecutorService. The idea was this could be a regular fixed thread pool or something more exotic like libdispatch, which is, after all OS managed and supposedly plays nicely with power management etc. > > I didn't take the idea any further, but something similar cropped up when lamdas were added in Java 8, the idea of a default mechanism for parallel lambda execution. > > I still think there's a good idea in there. The notion of a default thread pool that could be backed by more native code on various platforms. But that whole infrastructure would need to be created. It's more like a JEP. If that were to exist then the Dispatch class would be a natural way to implement on OS X. > > Andrew > >> On May 19, 2015, at 8:01 PM, Phil Race wrote: >> >> Apple's JDK 6 provided the non-standard "com.apple.concurrent.Dispatch" class >> which was a means for Java code to access Apple's "libdispatch". >> To quote the documentation at >> http://www.coderanch.com/how-to/javadoc/appledoc/api/com/apple/concurrent/Dispatch.html >> >> " Factory for |Executor|s and |ExecutorService|s backed by libdispatch. >> Access is controlled through the Dispatch.getInstance() method, >> because performed tasks occur on threads owned by libdispatch" >> >> The class carried over into Oracle JDK for OS X and is there all the way up >> to current JDk 9 dev builds. >> >> The question is what to do with this class in the 'modular JDK' where >> we need to decide on the 'supportedness' of many APIs and what >> to do with them as a result. >> >> There is one Eclipse bug from 2010 where one of the methods was >> added to support embedding SWT in AWT applets in the browser : >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=303869 >> >> but that was for JDK 6 and SWT can't be embedded in the current JDK 7/8/9 >> Java Plugin for OS X which runs out of process .. so that usage is moot. >> >> So the current thinking is that since we do not know of anyone who >> uses this class that it should be unsupported in JDK 9 and not >> visible in the modular JDK image. >> >> So .. any comments ? >> >> -phil. >> >> >> >> >> From lordpixel at me.com Mon Sep 21 22:05:22 2015 From: lordpixel at me.com (Andrew Thompson) Date: Mon, 21 Sep 2015 18:05:22 -0400 Subject: com.apple.concurrent.Dispatch in the modular JDK In-Reply-To: <560075D2.4070407@oracle.com> References: <555BCECB.8060107@oracle.com> <94162343-0C45-4293-AB5E-6D15C5206909@me.com> <560075D2.4070407@oracle.com> Message-ID: <1B0550E4-4592-4BD3-B65F-8D56362E600D@me.com> That seems reasonable. The question of whether the Java platform should play nicely with power management and whether threadpools are the right abstraction for that is a worthy one but keeping this little known API around isn't going to solve that. In any case there's always my own implementation which predates Apple's that folks can use if they want to. http://pixel.recoil.org/code/rococoa/ Andrew > On Sep 21, 2015, at 5:25 PM, Phil Race wrote: > > An update on this. We have not found any widespread use of this API > The expectation (nascent plan) is that this package will not be carried > forward into the modular JDK. I suppose it is possible some new JEP may > revive it as a standard API for in JDK 10 but there is no plan for that. > > -phil. > >> On 05/19/2015 09:28 PM, Andrew Thompson wrote: >> A few years ago I had a brief email exchange with Doug Lea I the idea of providing an SPI so platforms could plug in implementations for a "default" ExecutorService. The idea was this could be a regular fixed thread pool or something more exotic like libdispatch, which is, after all OS managed and supposedly plays nicely with power management etc. >> >> I didn't take the idea any further, but something similar cropped up when lamdas were added in Java 8, the idea of a default mechanism for parallel lambda execution. >> >> I still think there's a good idea in there. The notion of a default thread pool that could be backed by more native code on various platforms. But that whole infrastructure would need to be created. It's more like a JEP. If that were to exist then the Dispatch class would be a natural way to implement on OS X. >> >> Andrew >> >>> On May 19, 2015, at 8:01 PM, Phil Race wrote: >>> >>> Apple's JDK 6 provided the non-standard "com.apple.concurrent.Dispatch" class >>> which was a means for Java code to access Apple's "libdispatch". >>> To quote the documentation at >>> http://www.coderanch.com/how-to/javadoc/appledoc/api/com/apple/concurrent/Dispatch.html >>> >>> " Factory for |Executor|s and |ExecutorService|s backed by libdispatch. >>> Access is controlled through the Dispatch.getInstance() method, >>> because performed tasks occur on threads owned by libdispatch" >>> >>> The class carried over into Oracle JDK for OS X and is there all the way up >>> to current JDk 9 dev builds. >>> >>> The question is what to do with this class in the 'modular JDK' where >>> we need to decide on the 'supportedness' of many APIs and what >>> to do with them as a result. >>> >>> There is one Eclipse bug from 2010 where one of the methods was >>> added to support embedding SWT in AWT applets in the browser : >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=303869 >>> >>> but that was for JDK 6 and SWT can't be embedded in the current JDK 7/8/9 >>> Java Plugin for OS X which runs out of process .. so that usage is moot. >>> >>> So the current thinking is that since we do not know of anyone who >>> uses this class that it should be unsupported in JDK 9 and not >>> visible in the modular JDK image. >>> >>> So .. any comments ? >>> >>> -phil. > From sebastian.sickelmann at gmx.de Sat Sep 26 15:42:48 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sat, 26 Sep 2015 17:42:48 +0200 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application Message-ID: <5606BCF8.6090603@gmx.de> Hello, my name is Sebastian Sickelmann and i signed the OCA. Actually I am searching through the JBS for low hanging fruits. Right now i am looking through the openjdk-sources and try to evaluate if i can make something about JDK-5108778. As i am not an author, i am actually not able to host webrevs on cr.openjdk.java.net. Is there someone who would support at hosting the macosx-part of JDK-5108778 on cr.openjdk.java.net for reviewing? I placed the macosx part in my dropbox at: https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/macosx_0/webrev/index.html or as zip: https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/macosx_0/webrev.zip Unfortunately I am not able to compile or run the tests for this on my machine because I don't have a macosx running on my hardware. Maybe someone can support here, too? -- Sebastian From alexandr.scherbatiy at oracle.com Mon Sep 28 09:03:05 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 28 Sep 2015 12:03:05 +0300 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application In-Reply-To: <5606BCF8.6090603@gmx.de> References: <5606BCF8.6090603@gmx.de> Message-ID: <56090249.6040809@oracle.com> On 9/26/2015 6:42 PM, Sebastian Sickelmann wrote: > Hello, > > my name is Sebastian Sickelmann and i signed the OCA. > > Actually I am searching through the JBS for low hanging fruits. > Right now i am looking through the openjdk-sources and try to evaluate > if i can make something about JDK-5108778. > > As i am not an author, i am actually not able to host webrevs on > cr.openjdk.java.net. > > Is there someone who would support at hosting the macosx-part of > JDK-5108778 on cr.openjdk.java.net for reviewing? Thank you for the contribution. Here is the created link: http://cr.openjdk.java.net/~alexsch/sebastian.sickelmann/5108778/webrev.00/ > I placed the macosx part in my dropbox at: > https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/macosx_0/webrev/index.html > or as zip: > https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/macosx_0/webrev.zip Is it possible to use autoboxing in the fix instead of Boolean.valueOf(someBooleanVariable)? It is required to have automated tests for a fix where it is possible. Can an automated test be written which checks that number of Boolean valueas are not too much? The issue 5108778 is too broad. Are you going to fix it only in JDK client area? If so, you can file a specific issue on it. > > Unfortunately I am not able to compile or run the tests for this on my > machine because I don't have a macosx running on my hardware. I compiled the code and at least it does not have errors. > Maybe > someone can support here, too? Is it possible to use a virtual machine on your desktop? Thanks, Alexandr. > > > -- Sebastian From sebastian.sickelmann at gmx.de Wed Sep 30 03:38:33 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Wed, 30 Sep 2015 05:38:33 +0200 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application In-Reply-To: References: <5608201C.4020109@gmx.de> Message-ID: <560B5939.6010100@gmx.de> Yes it is the only (non-test) source i could find in hotspot, but i want to change it in all openjdk sources i can find it. I thought i really must discuss it part by part in the mailing-lists. Actually i am working on the issue to save against regression on this. Thanks Alexandr for this input. So there will be something that integrates into jtreg for this too. -- Sebastian On 09/30/2015 01:11 AM, Christian Thalinger wrote: > Thanks for volunteering to look into such old bugs! > > Is this the only occurrence of that pattern in the hotspot repository? If you want to fix this in hotspot only without the jdk changes described in the RFE (I just changed the type from Bug to Enhancement) then we have to file a new RFE because we can?t close the original one. > >> On Sep 27, 2015, at 6:58 AM, Sebastian Sickelmann wrote: >> >> Hello, >> >> my name is Sebastian Sickelmann and i signed the OCA. >> >> Actually I am searching through the JBS for low hanging fruits. >> Right now i am looking through the openjdk-sources and try to evaluate >> if i can make something about JDK-5108778. >> >> As I am not an author, I am actually not able to host webrevs on >> cr.openjdk.java.net. >> >> Is there someone who would support at hosting the hotspot-part of >> JDK-5108778 on cr.openjdk.java.net for reviewing? >> >> I placed the hotspot part in my dropbox at: >> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev/index.html >> or as zip: >> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev.zip >> >> I executed all jtreg tests in hotspot/test and get no more errors than before the change. >> >> -- Sebastian >> >