Re: RFR: 8007519: [unpack200] produces bad class files when producing BootstrapMethods attribute

Good fix; thumbs up. — John On Feb 8, 2013, at 10:19 AM, Kumar Srinivasan wrote: > Hi, > > Please review > http://cr.openjdk.java.net/~ksrini/8007519/webrev.0/ > > Bug: > https://jbs.oracle.com/bugs/browse/JDK-8007519 > > Thanks > Kumar >

Re: Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor

On Feb 11, 2013, at 6:34 PM, Krystal Mo wrote: > This might look a bit hacky... > > The idea is, DirectMethodHandle.make(Class receiver, MemberName member) > should keep its behavior as it used to P.S. I wonder if we could get rid of that old overloading of DirectMethodHandle.make. I can s

Re: Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor

On Feb 11, 2013, at 6:34 PM, Krystal Mo wrote: > Let's get John's comment and see if my understanding of that part is correct. The new code treats findSpecial and unreflectSpecial as corner cases. In these corner cases, refKind is invokespecial, *and* this is visible to the user. These cases

Re: Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor

On Feb 8, 2013, at 10:38 AM, Krystal Mo wrote: > For the record, credit goes to John Rose who did the actual fix. I only added > the unit test to verify the fix. Also FTR, your unit test found a bug which led you to amend the fix. So the final version of the fix, as well as the unit test, is

Re: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string

On Feb 11, 2013, at 9:04 PM, Mike Duigou wrote: > I have been following up on this issue. I am going to have to adapt the code > a bit because there have been some changes in JDK8. > > I won't forget this issue though. It is possible I may not have time to > backport it to Java 7. > Please l

Re: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string

I have been following up on this issue. I am going to have to adapt the code a bit because there have been some changes in JDK8. I won't forget this issue though. It is possible I may not have time to backport it to Java 7. Mile On Feb 3 2013, at 21:26 , Steven Schlansker wrote: > > On Feb 1

hg: jdk8/tl: 8006595: Use jdk/test/Makefile targets in preference to local definitions

Changeset: 7817368287cd Author:mduigou Date: 2013-02-06 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7817368287cd 8006595: Use jdk/test/Makefile targets in preference to local definitions Reviewed-by: alanb ! common/makefiles/Main.gmk ! test/Makefile

hg: jdk8/tl/jdk: 8006594: Add jdk_core target to jdk/test/Makefile

Changeset: 465cce29a9ed Author:mduigou Date: 2013-02-06 11:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/465cce29a9ed 8006594: Add jdk_core target to jdk/test/Makefile Reviewed-by: alanb ! make/jprt.properties ! test/Makefile ! test/ProblemList.txt

Re: Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor

Thank you for the review, Chris. Comments inline: On 02/11/2013 06:06 PM, Christian Thalinger wrote: src/share/classes/java/lang/invoke/DirectMethodHandle.java: + static DirectMethodHandle make(Class receiver, MemberName member) { + byte refKind = member.getReferenceKind(); +

Re: Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor

On Feb 8, 2013, at 10:38 AM, Krystal Mo wrote: > Hi all, > > Could I have a couple of review for this change: > > 7087570: java.lang.invoke.MemberName information wrong for method handles > created with findConstructor > Summary: REF_invokeSpecial DMHs (which are unusual) get marked explicitl

Re: RFR JDK-8007609

John, I think the functional fix is okay but you have obscured it in so much "cleanup" that it is hard to say with 100% certainty. Please leave extensive cleanups to separate bugs - in this case I'm not seeing improvements in readability in a number of places (indentation is odd) and in at le

Re: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

javac will not replace concat ops across loop iterations, it will replace whichever ones are inside one loop iteration. This will still create temporary StringBuilder instances. As for JIT optimizing further, it would have to fully unroll the loop to have a chance at eliminating this; I'd be real

Re: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

Am 11.02.2013 22:26, schrieb Hildeberto Mendonça: Hello Ulf, On Mon, Feb 11, 2013 at 9:03 PM, Ulf Zibis mailto:ulf.zi...@cosoco.de>> wrote: Hi Hildeberto, maybe your believe is correct. You could have a look in the byte code by javap. And additionally you could run a benchmar

Re: RFR: 7199858: Marshal exception is wrong

Looks Ok Dmeetry. Best Lance On Feb 11, 2013, at 3:58 PM, Dmeetry Degrave wrote: > Hi, > > Resending a code review request for a corba fix for 7 and 8, which is > identical to fix went to earlier releases. > > A wrong unexpectedUnionDefault exception is thrown in TypeCode handling code > when

hg: jdk8/tl/langtools: 8007574: Provide isFunctionalInterface in javax.lang.model

Changeset: 01af1b5c631d Author:darcy Date: 2013-02-11 13:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/01af1b5c631d 8007574: Provide isFunctionalInterface in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/sh

RFR: 7199858: Marshal exception is wrong

Hi, Resending a code review request for a corba fix for 7 and 8, which is identical to fix went to earlier releases. A wrong unexpectedUnionDefault exception is thrown in TypeCode handling code when an OptUnion value with false discriminator is inserted into any of NV struct on server side f

Re: hg: jdk8/tl/jdk: 8007405: Update java.lang.reflect API to replace SYNTHESIZED with MANDATED

Drat! The change-set author should be "emc" (Eric McCorkle), not me. I was only pushing Eric's patch as he's not a jdk8 committer at this time. On 11/02/2013 20:20, alan.bate...@oracle.com wrote: Changeset: f21a4b761424 Author:alanb Date: 2013-02-11 20:16 + URL: http://hg.o

hg: jdk8/tl/jdk: 8007405: Update java.lang.reflect API to replace SYNTHESIZED with MANDATED

Changeset: f21a4b761424 Author:alanb Date: 2013-02-11 20:16 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f21a4b761424 8007405: Update java.lang.reflect API to replace SYNTHESIZED with MANDATED Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java ! src/s

Re: Code review request: 8006691: Remove jvm_version_info.is_kernel_jvm field

ZhengYu - Just realize that you are a committer [1]. You can push the fix to TL yourself. Mandy [1] http://openjdk.java.net/census#zgu On 2/11/13 10:30 AM, Mandy Chung wrote: Hi ZhengYu, Looks good to me. I will sponsor this change and push it to JDK8. To backport to jdk7u, you will need t

Re: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

Am 11.02.2013 16:39, schrieb Hildeberto Mendonça: On Mon, Feb 11, 2013 at 3:29 PM, Ulf Zibis mailto:ulf.zi...@cosoco.de>> wrote: Am 11.02.2013 12:54, schrieb Hildeberto Mendonça: we have a scenario where a project with approximately 500K lines of code is going through a lar

Re: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

Is there something we can do to push it forward? Maybe a patch, tests, text, or something else? On Mon, Feb 11, 2013 at 7:32 PM, Hildeberto Mendonça wrote: > On Mon, Feb 11, 2013 at 6:08 PM, Vitaly Davidovich wrote: > >> It should be isEmpty() -- empty() is usually for returning empty versions >>

Re: Code review request: 8006691: Remove jvm_version_info.is_kernel_jvm field

Hi ZhengYu, Looks good to me. I will sponsor this change and push it to JDK8. To backport to jdk7u, you will need to get an approval and please follow the processes [1]. You have filed a CCC request for this change - FWIW this is private implementation-specific and no CCC is needed for this.

Re: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

On Mon, Feb 11, 2013 at 6:08 PM, Vitaly Davidovich wrote: > It should be isEmpty() -- empty() is usually for returning empty versions > of the class. isEmpty is also consistent with String. > Yes. Also, being consistent with String helps to reduce effort during refactoring. -- Hildeberto Mendo

Define JNIEXPORT as visibility default with GCC?

Hi folks, Pardon if this has come up before; a quick search didn't indicate anything, but the mailing list archives are kind of hard to search. I wonder if it makes sense to define JNIEXPORT as meaning __attribute__ ((visibility ("default"))) when compiling with gcc. Currently, anyone building J

hg: jdk8/tl/jdk: 8007420: add test for 6805864 to com/sun/jdi, add test for 7182152 to java/lang/instrument

Changeset: abd530253f01 Author:dcubed Date: 2013-02-11 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abd530253f01 8007420: add test for 6805864 to com/sun/jdi, add test for 7182152 to java/lang/instrument Reviewed-by: coleenp, sspitsyn + test/com/sun/jdi/RedefineAbst

Code review request: 8006691: Remove jvm_version_info.is_kernel_jvm field

Kernel VM has been deprecated since JDK7 and related JVM code has also been removed recently. This change is to remove is_kernel_jvm flag from jvm_version_info structure in jvm.h on JDK side. Bug: http://bugs.sun.com/view_bug.do?bug_id=8006691 CCC: http://ccc.us.oracle.com/8006691 JDK7: htt

Re: zip64 compatibility problems

On Mon, Feb 11, 2013 at 6:53 AM, Alan Bateman wrote: > One improvement would be to use try-with-resources. > I did that, despite the loss of portability. Portable java programs might be able to start using these new-fangled features starting around 2020.

Re: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

It should be isEmpty() -- empty() is usually for returning empty versions of the class. isEmpty is also consistent with String. Sent from my phone On Feb 11, 2013 12:03 PM, "Paul Benedict" wrote: > Do you want isEmpty() for bean access, or empty() like Collections? Since > there isn't a getLeng

Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

Do you want isEmpty() for bean access, or empty() like Collections? Since there isn't a getLength() but just length() (and size() for collections), I think the latter would be preferred. Paul

Re: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

On Mon, Feb 11, 2013 at 3:29 PM, Ulf Zibis wrote: > Am 11.02.2013 12:54, schrieb Hildeberto Mendonça: > > we have a scenario where a project with approximately 500K lines of code is >> going through a large refactoring. One of the changes was to replace >> string >> concatenations in loops by Str

Re: zip64 compatibility problems

On 11/02/2013 03:59, Martin Buchholz wrote: On Sat, Feb 9, 2013 at 1:50 AM, Peter Levart > wrote: Also, this does not disable ZIP64 - it only disables it when it is not needed (most other zip implementations can still read the output) "inhibit" see

hg: jdk8/tl/jdk: 8007536: Incorrect copyright header in JDP files

Changeset: 1df991184045 Author:dsamersoff Date: 2013-02-11 18:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1df991184045 8007536: Incorrect copyright header in JDP files Summary: Copyright header in JDP files missed the "classpath exception" rule. Reviewed-by: mikael ! s

Re: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

It won't replace them in loops or at least not entirely (may get intermediate builders for each iteration). I also agree on the isEmpty() point. Sent from my phone On Feb 11, 2013 9:30 AM, "Ulf Zibis" wrote: > Am 11.02.2013 12:54, schrieb Hildeberto Mendonça: > >> Hello, >> >> we have a scenari

Re: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

Am 11.02.2013 12:54, schrieb Hildeberto Mendonça: Hello, we have a scenario where a project with approximately 500K lines of code is going through a large refactoring. One of the changes was to replace string concatenations in loops by StringBuilder. Are you aware, that behind the scenes, Stri

Re: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

Yes. That's definitively a good approach. I think there are many other opportunities to improve StringBuilder and other subclasses of CharSequence, but this isEmpty() method is a very important one. A lot of developers might be constantly doing this kind of refactoring and it may reduce the effort

Re: Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

This could be a default method in CharSequence Regards, Peter On 02/11/2013 12:54 PM, Hildeberto Mendonça wrote: Hello, we have a scenario where a project with approximately 500K lines of code is going through a large refactoring. One of the changes was to replace string concatenations in

Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

Hello, we have a scenario where a project with approximately 500K lines of code is going through a large refactoring. One of the changes was to replace string concatenations in loops by StringBuilder. Within the logic we found the following condition: for(...) { if(str.isEmpty()) { // do