Hi Claes,
How did you measure this performance improvement?
On 1/20/20 7:54 am, Claes Redestad wrote:
Hi,
some minor cleanups and enhancements in and around java.lang.ClassLoader
which add up to a small startup improvement:
- Remove use of Vector/Hashtable from ClassLoader, along with a few
On 1/20/20 2:16 PM, Claes Redestad wrote:
Ok, new version here:
http://cr.openjdk.java.net/~redestad/8236075/open.02/
+1
Mnady
On 2020-01-20 22:00, Mandy Chung wrote:
On 1/20/20 12:46 PM, Alan Bateman wrote:
On 20/01/2020 15:54, Claes Redestad wrote:
Hi,
some minor cleanups and enhancements in and around java.lang.ClassLoader
which add up to a small startup improvement:
- Remove use of Vector/Hashtable from
Hi!
First of I want to say thank you Remi, for at least trying to answer.
On Sat, 2020-01-18 at 00:36 +0100, Remi Forax wrote:
> Hi Robert,
> first this is the wrong mailing list, ...
Ok. I was hoping to get in contact with the people behind the
ObjectInputFilter and discuss how it is supposed
On 1/20/20 12:46 PM, Alan Bateman wrote:
On 20/01/2020 15:54, Claes Redestad wrote:
Hi,
some minor cleanups and enhancements in and around java.lang.ClassLoader
which add up to a small startup improvement:
- Remove use of Vector/Hashtable from ClassLoader, along with a few
other
On 20/01/2020 15:54, Claes Redestad wrote:
Hi,
some minor cleanups and enhancements in and around java.lang.ClassLoader
which add up to a small startup improvement:
- Remove use of Vector/Hashtable from ClassLoader, along with a few
other improvements/modernizations.
- Refactor
Hi Claes,
On 1/20/20 7:54 AM, Claes Redestad wrote:
Hi,
some minor cleanups and enhancements in and around java.lang.ClassLoader
which add up to a small startup improvement:
- Remove use of Vector/Hashtable from ClassLoader, along with a few
other improvements/modernizations.
- Refactor
Hi,
some minor cleanups and enhancements in and around java.lang.ClassLoader
which add up to a small startup improvement:
- Remove use of Vector/Hashtable from ClassLoader, along with a few
other improvements/modernizations.
- Refactor ClassLoader::sys_paths/user_paths so that they're
Hi Philipp,
thanks for the reply .. comments inline
On 19/01/20 16:09, Philipp Kunz wrote:
Hi Sean,
I figure that distinguishing zips and jars is ambiguous in a certain
way. After having signed a zip, it contains a manifest and is also a
jar file according to the specs. That would mean we
Daniel, Lance, Seán,
thanks for reviewing!
/Claes
On 2020-01-20 13:37, Daniel Fuchs wrote:
On 20/01/2020 12:15, Claes Redestad wrote:
Makes sense to keep even trivial logic out of the access bridge. Let's
also clean up the placement of the static variable and the pre-existing
use of the
Hello.
I have 2 concerns about CLDR Timezone translated data.
The detail information is in JDK-8236548 [1].
Can you show me how to solve this kind of ICU related issue ?
[1] https://bugs.openjdk.java.net/browse/JDK-8236548
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
On 20/01/2020 12:15, Claes Redestad wrote:
Makes sense to keep even trivial logic out of the access bridge. Let's
also clean up the placement of the static variable and the pre-existing
use of the unconventional "final static" combo:
http://cr.openjdk.java.net/~redestad/8237508/open.01/
+1
Looks good Claes
Best,
Lance
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPad
> On Jan 20, 2020, at 7:12 AM, Claes Redestad wrote:
>
> Makes sense to keep even
Hello.
This is just a gentle reminder.
Could you review CSR JDK-8233385 [1] ?
[1] https://bugs.openjdk.java.net/browse/JDK-8233385
Thanks,
Ichiroh Takiguchi
On 2020-01-10 22:13, Ichiroh Takiguchi wrote:
Hello.
Could you review CSR JDK-8233385 [1] ?
[1]
Looks good to me Claes - thanks for fixing.
Regards,
Sean.
On 20/01/20 12:15, Claes Redestad wrote:
Makes sense to keep even trivial logic out of the access bridge. Let's
also clean up the placement of the static variable and the pre-existing
use of the unconventional "final static" combo:
Makes sense to keep even trivial logic out of the access bridge. Let's
also clean up the placement of the static variable and the pre-existing
use of the unconventional "final static" combo:
http://cr.openjdk.java.net/~redestad/8237508/open.01/
/Claes
On 2020-01-20 12:35, Daniel Fuchs wrote:
Hi Claes,
Looks OK to me but I'd have a slight preference to a solution
that confines the hack to the JarFile class.
Would making the isIntializing field private and introducing
a static boolean isInitializing() method in JarFile bring the
same benefits WRT startup?
best regards,
-- daniel
Hi,
JDK-8234466[1] introduced isInitializing to JarFile, which cause a small
startup regression in various tests due increasing the number of classes
loaded and earlier lambda bootstrapping. The regression can be resolved
by not explicitly initializing the thread local variable to a non-null
18 matches
Mail list logo
