Re: problems with sun.reflect.Reflection.getCallerClass(int)

Thank you! On 31. Juli 2013 at 22:43:39, mark.reinh...@oracle.com (mark.reinh...@oracle.com) wrote: FYI, we're going to revert this method to its previous behavior in JDK 7u40: http://bugs.sun.com/view_bug.do?bug_id=8021946 . What will happen to this method in JDK 8 requires further thought

hg: jdk8/tl/langtools: 8014826: c.s.t.javac.tree.Pretty.visitNewArray() prints duplicate dimension markers

Changeset: 05370ef9dccb Author:ksrini Date: 2013-07-31 08:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/05370ef9dccb 8014826: c.s.t.javac.tree.Pretty.visitNewArray() prints duplicate dimension markers Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/jav

Re: Remaining doclint issues in java.net

On 7/29/13 7:28 AM, Chris Hegarty wrote: There are two remaining doclint warnings in the java.net package. >:javac -Xdoclint:all/protected src/share/classes/java/net/DatagramPacket.java src/share/classes/java/net/DatagramPacket.java:142: warning: no @throws for java.net.SocketException pu

Re: problems with sun.reflect.Reflection.getCallerClass(int)

That is, indeed, great news! I have almost completed a patch that I will propose later this week to make this a public API. Nick On Jul 31, 2013, at 3:42 PM, mark.reinh...@oracle.com wrote: > FYI, we're going to revert this method to its previous behavior in > JDK 7u40: http://bugs.sun.com/vie

Re: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X

On 7/30/13 4:06 PM, David DeHaven wrote: Judging from the docs, nl_langinfo seems like a Unix portability function (something more likely to be happier with ASCII in a terminal), not something to be used by a native Cocoa application. Exactly - so I think it expects to be called from a cmdline

Re: problems with sun.reflect.Reflection.getCallerClass(int)

FYI, we're going to revert this method to its previous behavior in JDK 7u40: http://bugs.sun.com/view_bug.do?bug_id=8021946 . What will happen to this method in JDK 8 requires further thought. - Mark

Getting ciObject from oop/jobject

In native code (library_call.cpp), if I have an oop (which I can convert to a jobject if need be), how do I get a ciObject? I see that ciEnv has a ciObject* get_object(oop) method, but it's private. And ciObjectFactory has a ciObject* get(oop) method, but I can't figure out how to get the ciObje

hg: jdk8/tl/jdk: 8006324: [TEST_BUG] sun/invoke/util/ValueConversionsTest.java should be modified

Changeset: 4bd51f6268f4 Author:rbackman Date: 2013-07-24 10:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bd51f6268f4 8006324: [TEST_BUG] sun/invoke/util/ValueConversionsTest.java should be modified Reviewed-by: kvn, twisti ! test/sun/invoke/util/ValueConversionsTest.ja

Re: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X

I suspect that Apple might be unlikely to change the value that nl_langinfo returns when LANG is unset. However, it might be possible to fix this issue without second-guessing the character set reported by the OS by calling [NSLocale currentLocale] (or the CFLocale equivalent) instead of nl_lan

Re: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X

Then shouldn't you be complaining to Apple that the value returned by nl_langinfo needs to be changed? David's point seems to be that second guessing the character set reported by the OS is likely to cause a different set of problems. Scott On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin <

Re: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X

Hi, On Tue, 30 Jul 2013, David Holmes wrote: > On 30/07/2013 5:54 AM, Brent Christian wrote: > > On 7/28/13 10:13 PM, David Holmes wrote: > > > On 27/07/2013 3:53 AM, Brent Christian wrote: > > > > Please review my fix for 8011194 : "Apps launched via double-clicked > > > > .jars have file.encodi

Re: ProblemList.txt Update ( add ThreadLocalSupplierTest )

On 31/07/2013 08:20, Chris Hegarty wrote: I would to add ThreadLocalSupplierTest to the ProblemList.txt until 8021230 issue can be resolved. hg diff test/ProblemList.txt diff -r 5561b34f6d4c test/ProblemList.txt --- a/test/ProblemList.txt Tue Jul 30 10:35:06 2013 -0700 +++ b/test/ProblemLi

Re: RFR 8015987: The corba repo contains unneeded .sjava files

Looks good from me also. I think these files were leftovers from some old development projects. Good to clean up. regards, Sean. On 31/07/13 13:15, Aleksej Efimov wrote: Hi, There are unused .sjava files in corba repository which can be deleted. The webrev: http://cr.openjdk.java.net/~aefimov

hg: jdk8/tl/jdk: 8020539: Clean up doclint problems in java.util package, part 2

Changeset: 5561b34f6d4c Author:bpb Date: 2013-07-30 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5561b34f6d4c 8020539: Clean up doclint problems in java.util package, part 2 Summary: Clean up doclint errors and warnings in classes in java.util Reviewed-by: darcy, cheg

ProblemList.txt Update ( add ThreadLocalSupplierTest )

I would to add ThreadLocalSupplierTest to the ProblemList.txt until 8021230 issue can be resolved. hg diff test/ProblemList.txt diff -r 5561b34f6d4c test/ProblemList.txt --- a/test/ProblemList.txt Tue Jul 30 10:35:06 2013 -0700 +++ b/test/ProblemList.txt Wed Jul 31 16:15:25 2013 +0100

Re: Review request: JDK-8020191 System.getProperty( " os.name " ) returns " Windows NT (unknown) " on Windows 8.1

Changes look good to me (once Alan's point is verified). Thanks, - Kurchi On Wed, Jul 31, 2013 at 7:15 AM, Alan Bateman wrote: > > The changes in the webrev look okay to me but the reference to the "app > compatibility shim" in the MS article is a bit confusing and not clear to > me (with chec

Re: Try to run core libs tests -- All IO tests failing

try: make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ *jdk_core* -Chris. On 31/07/2013 15:49, Nick Williams wrote: That's how I'm running it. $ pwd /foo/bar/jdk8/jdk8 $ cd test $ make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-releas

Re: RFR 8015987: The corba repo contains unneeded .sjava files

On 31/07/2013 07:46, Chris Hegarty wrote: OK for me. -Chris. Looks okay to me too (and I actually thought these had been deleted already). -Alan

Re: Try to run core libs tests -- All IO tests failing

Nick, A *workaround* for this problem would be to locally edit the names of the problem tests into jdk/test/ProblemList.txt so that they are not run. There is general work underway to improve/simplify the Makefile support for jtreg, that should address this problem. -- Jon On 07/31/2013 07

Re: Try to run core libs tests -- All IO tests failing

Yea, I've been working around it by running the modules one at a time. It's just a pain, that's all. N On Jul 31, 2013, at 9:56 AM, Jonathan Gibbons wrote: > Nick, > > A *workaround* for this problem would be to locally edit the names of the > problem tests into jdk/test/ProblemList.txt so th

Re: Try to run core libs tests -- All IO tests failing

That's how I'm running it. $ pwd /foo/bar/jdk8/jdk8 $ cd test $ make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all If one test fails in a batch, none of the following batches run. So if one test fails in java.io, java.lang won't run. Makes it difficult

Re: RFR 8015987: The corba repo contains unneeded .sjava files

OK for me. -Chris. On 31/07/2013 13:15, Aleksej Efimov wrote: Hi, There are unused .sjava files in corba repository which can be deleted. The webrev: http://cr.openjdk.java.net/~aefimov/8015987/webrev.00/ BUG: http://bugs.sun.com/bugda

Re: Try to run core libs tests -- All IO tests failing

I believe if you run the tests from the top-level test/Makefile, not jdk/test/Makefile, all individual test batches ( invocations of jtreg ) get run. -Chris. On 30/07/2013 21:46, Jonathan Gibbons wrote: jtreg itself does not "stop on error". If you're driving the tests through the makefiles,

Re: RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx]

On 31/07/2013 14:45, Alan Bateman wrote: On 31/07/2013 05:18, Aleksej Efimov wrote: Hi, Can I have a review for the following problem: The MACOSX JDK (more precisely - the java.net classes) uses the select() system call to wait for different events on sockets fds. And the default behaviour for s

Re: Try to run core libs tests -- All IO tests failing

On 31/07/2013 05:53, Chris Hegarty wrote: Thanks for bringing this back to our attention Jon. I will follow up with the Apple folks to see what system call they are using in their Java6 implementation. I suspect they are using getsockname to determine the local IP address. It may be appropria

Re: Review request: JDK-8020191 System.getProperty( " os.name " ) returns " Windows NT (unknown) " on Windows 8.1

The changes in the webrev look okay to me but the reference to the "app compatibility shim" in the MS article is a bit confusing and not clear to me (with checking into it more) whether this might consider java.exe as something that isn't targeted to Windows 8.1. So can you verify that you ha

Re: RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx]

On 31/07/2013 05:18, Aleksej Efimov wrote: Hi, Can I have a review for the following problem: The MACOSX JDK (more precisely - the java.net classes) uses the select() system call to wait for different events on sockets fds. And the default behaviour for select() on Darwin is to fail when fdset

Re: Classes on the stack trace

Okay, but I don't think @CallerSensitive is necessary to prevent MethodHandles from spoofing caller classes. I'll admit I don't know very much about MethodHandle, what it does, or how its invocation methods are different from Method.invoke(). In the code that I copied into this email from jvm.cp

Review request: JDK-8020191 System.getProperty( " os.name " ) returns " Windows NT (unknown) " on Windows 8.1

Bug description: https://jbs.oracle.com/bugs/browse/JDK-8020191 http://bugs.sun.com/view_bug.do?bug_id=8020191 Here is the suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8020191/webrev.00/ Summary: We need to be consistent with the rest of OS, so I extend the case for

Re: Try to run core libs tests -- All IO tests failing

On 30/07/2013 22:05, Jonathan Gibbons wrote: Bumped the isue to P2, marked it "Affect 8" and added a link to this thread. Thanks for bringing this back to our attention Jon. I will follow up with the Apple folks to see what system call they are using in their Java6 implementation. I suspect t

RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx]

Hi, Can I have a review for the following problem: The MACOSX JDK (more precisely - the java.net classes) uses the select() system call to wait for different events on sockets fds. And the default behaviour for select() on Darwin is to fail when fdset contains the fd with id greater than FDSET_

RFR 8015987: The corba repo contains unneeded .sjava files

Hi, There are unused .sjava files in corba repository which can be deleted. The webrev: http://cr.openjdk.java.net/~aefimov/8015987/webrev.00/ BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015987 After execution of tests fro

hg: jdk8/tl/langtools: 8013179: assertion failure in javac when compiling with -source 1.6 -target 1.6

Changeset: 7696282873f6 Author:vromero Date: 2013-07-31 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7696282873f6 8013179: assertion failure in javac when compiling with -source 1.6 -target 1.6 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Trans

Re: Classes on the stack trace

Hi Nick, The @CallerSensitive annotation is an annotation that prevents some other infrastructure, namely the MethodHandles, to "spoof" caller classes. Try this: MethodHandles.Lookup lookup = MethodHandles.lookup().in(Object.class); MethodHandle mh = lookup.findStatic(Class.c

hg: jdk8/tl/jdk: 8021883: j.u.Random/RandomStream.java test needs more robust timeout duration

Changeset: d30f357c6050 Author:psandoz Date: 2013-07-30 14:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d30f357c6050 8021883: j.u.Random/RandomStream.java test needs more robust timeout duration Reviewed-by: chegar ! test/java/util/Random/RandomStreamTest.java

Re: RFR: 8021591 : (s) Additional explicit null checks

On Jul 31, 2013, at 12:57 AM, Mike Duigou wrote: >> >> >> - * @throws NullPointerException if a specified key or value is null, >> + * @throws NullPointerException if a specified key or newValue is null, >> * and this map does not permit null keys or values >> + * @throws