From hannes.wallnoefer at oracle.com Tue Jul 9 13:23:43 2019 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 9 Jul 2019 15:23:43 +0200 Subject: RFR: Update double-conversion to version 3.1.5 Message-ID: Please review the update of the Java port of the V8 double conversion library to the most recent release. JBS: https://bugs.openjdk.java.net/browse/JDK-8227391 Webrev: http://cr.openjdk.java.net/~hannesw/8227391/webrev.00/ Although the commit log between the two releases is very long [1] (I?m not sure the list is totally accurate since they are on different branches) the actual changes to the code are quite limited. The majority of changes either pertains to the code layout, build system, or are C++ specific and do not apply to the Java port. In the end it amounts to two fixes plus tests along with some code cleanup. [1]: https://github.com/google/double-conversion/compare/57b1e09...5fa81e8 This will go into 13 or 14, depending on whether the late enhancement is allowed. Thanks, Hannes From szegedia at gmail.com Tue Jul 9 13:55:37 2019 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 9 Jul 2019 15:55:37 +0200 Subject: RFR: Update double-conversion to version 3.1.5 In-Reply-To: References: Message-ID: +1. This is really a refreshingly small change :-) Attila. > On 2019. Jul 9., at 15:23, Hannes Walln?fer wrote: > > Please review the update of the Java port of the V8 double conversion library to the most recent release. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8227391 > Webrev: http://cr.openjdk.java.net/~hannesw/8227391/webrev.00/ > > Although the commit log between the two releases is very long [1] (I?m not sure the list is totally accurate since they are on different branches) the actual changes to the code are quite limited. The majority of changes either pertains to the code layout, build system, or are C++ specific and do not apply to the Java port. In the end it amounts to two fixes plus tests along with some code cleanup. > > [1]: https://github.com/google/double-conversion/compare/57b1e09...5fa81e8 > > This will go into 13 or 14, depending on whether the late enhancement is allowed. > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Tue Jul 9 14:48:48 2019 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 9 Jul 2019 16:48:48 +0200 Subject: RFR: 8223451: Make optimistic types disabled by default Message-ID: <26EE8FFD-B5DA-49BD-BA08-6CBCCBC651BE@oracle.com> Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8223451 Webrev: http://cr.openjdk.java.net/~hannesw/8223451/webrev.00/ A lot of Nashorn usage we see is with command line scripts from the Node.js and Web ecosystems. These usually run for a short time, but can be quite complex and large. Optimistic compilation is a bad match for this type of application, as a lot of time is spent optimizing and recompiling code that is only run once. Additionally, optimistic types is both the newest and one of the most complex parts of Nashorn, so a large proportion of Nashorn bugs turn out to be related to it. Based on these considerations this change disables optimistic types by default. Users that want to use it can easily continue to do so using a command line or engine option. The change is straightforward and does not affect user observable behaviour apart from the amount of time spent in script execution and compilation. Hannes From sundararajan.athijegannathan at oracle.com Tue Jul 9 15:02:36 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 09 Jul 2019 20:32:36 +0530 Subject: RFR: 8223451: Make optimistic types disabled by default In-Reply-To: <26EE8FFD-B5DA-49BD-BA08-6CBCCBC651BE@oracle.com> References: <26EE8FFD-B5DA-49BD-BA08-6CBCCBC651BE@oracle.com> Message-ID: <5D24AC8C.7070303@oracle.com> Looks good! -Sundar On 09/07/19, 8:18 PM, Hannes Walln?fer wrote: > Please review: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223451 > Webrev: http://cr.openjdk.java.net/~hannesw/8223451/webrev.00/ > > A lot of Nashorn usage we see is with command line scripts from the Node.js and Web ecosystems. These usually run for a short time, but can be quite complex and large. Optimistic compilation is a bad match for this type of application, as a lot of time is spent optimizing and recompiling code that is only run once. Additionally, optimistic types is both the newest and one of the most complex parts of Nashorn, so a large proportion of Nashorn bugs turn out to be related to it. > > Based on these considerations this change disables optimistic types by default. Users that want to use it can easily continue to do so using a command line or engine option. The change is straightforward and does not affect user observable behaviour apart from the amount of time spent in script execution and compilation. > > Hannes From james.laskey at oracle.com Tue Jul 9 15:05:03 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 9 Jul 2019 12:05:03 -0300 Subject: RFR: 8223451: Make optimistic types disabled by default In-Reply-To: <26EE8FFD-B5DA-49BD-BA08-6CBCCBC651BE@oracle.com> References: <26EE8FFD-B5DA-49BD-BA08-6CBCCBC651BE@oracle.com> Message-ID: +1 > On Jul 9, 2019, at 11:48 AM, Hannes Walln?fer wrote: > > Please review: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223451 > Webrev: http://cr.openjdk.java.net/~hannesw/8223451/webrev.00/ > > A lot of Nashorn usage we see is with command line scripts from the Node.js and Web ecosystems. These usually run for a short time, but can be quite complex and large. Optimistic compilation is a bad match for this type of application, as a lot of time is spent optimizing and recompiling code that is only run once. Additionally, optimistic types is both the newest and one of the most complex parts of Nashorn, so a large proportion of Nashorn bugs turn out to be related to it. > > Based on these considerations this change disables optimistic types by default. Users that want to use it can easily continue to do so using a command line or engine option. The change is straightforward and does not affect user observable behaviour apart from the amount of time spent in script execution and compilation. > > Hannes From szegedia at gmail.com Wed Jul 10 18:38:30 2019 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 10 Jul 2019 20:38:30 +0200 Subject: RFR: 8223451: Make optimistic types disabled by default In-Reply-To: <26EE8FFD-B5DA-49BD-BA08-6CBCCBC651BE@oracle.com> References: <26EE8FFD-B5DA-49BD-BA08-6CBCCBC651BE@oracle.com> Message-ID: <50274D1B-0F61-4420-A236-227B53EFA535@gmail.com> I agree this is the best course of action. +1. Attila. > On 2019. Jul 9., at 16:48, Hannes Walln?fer wrote: > > Please review: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223451 > Webrev: http://cr.openjdk.java.net/~hannesw/8223451/webrev.00/ > > A lot of Nashorn usage we see is with command line scripts from the Node.js and Web ecosystems. These usually run for a short time, but can be quite complex and large. Optimistic compilation is a bad match for this type of application, as a lot of time is spent optimizing and recompiling code that is only run once. Additionally, optimistic types is both the newest and one of the most complex parts of Nashorn, so a large proportion of Nashorn bugs turn out to be related to it. > > Based on these considerations this change disables optimistic types by default. Users that want to use it can easily continue to do so using a command line or engine option. The change is straightforward and does not affect user observable behaviour apart from the amount of time spent in script execution and compilation. > > Hannes From mahdiumd at gmail.com Sun Jul 14 17:16:43 2019 From: mahdiumd at gmail.com (Matt Zand) Date: Sun, 14 Jul 2019 13:16:43 -0400 Subject: Parsing files and folders with Java Message-ID: Hi, I have a content folder on my website with more than few thousand images and videos. I want to write Java code to do following: 1- Read all files on the folder 2- Remove all files that are older than 2 years ago 3- Loop through all content files to check file type and save them in two arrays (one for images and another for videos) 4- Merge new image array files with an existing image folder files but if duplicate exists, override the older version of file. What is best way to achieve this? -- Cheers, Matt Zand Cell: 202-420-9192 Work: 240-200-6131 High School Technology Services DC Web Makers Coding Bootcamps