Re: RFR [8023130] (process) ProcessBuilder#inheritIO does not work on Windows

[Ivan Gerasimov]

Hello Alan, Martin, everyone!

Some update on the issue.
When trying to integrate my test into Basic.java, I found that it 
already contains exactly the same.

I have just overlooked it before.

Additional investigation showed that inheritIO() doesn't always fail on 
Windows.

If the scenario is like following:
- java application creates a child java process (no IO inheritance, 
redirecting IO through pipes by default),
- child process creates a grandchild which inherits the child's 
stdin/out/err,

everything works as expected.

However, if the java app (started from a console) creates an immediate 
child that inherits its parent stdin/out/err, it fails.


That's why this bug hasn't been caught by Basic.java before - because it 
uses the first testing scenario.
And that's why I had to introduce a new shell script test - because the 
problem couldn't be reproduced otherwise.


Would you please review the updated webrev?
http://cr.openjdk.java.net/~igerasim/8023130/1/webrev/ 



The proposed fix remained the same.
I only created a new shell script that reuses Basic.java functionality.
I also made a minor change to Basic.java to include testing of 
ProcessBuilder#redirectXXX(Redirect.INHERIT) method calls.


I manually tested the fixed jdk to check that we haven't reintroduced 
4244515 bug with this fix.
As Martin said, unfortunately there is no automated test for windowed 
apps behavior.


Sincerely yours,
Ivan Gerasimov


On 26.08.2013 3:31, Martin Buchholz wrote:

Historical notes:

I maintained this code for a while, but I've never been a "Windows" 
guy, and I rarely sat at an actual Windows machine console.  I don't 
know of any test infrastructure for windowed apps.



On Fri, Aug 23, 2013 at 9:11 AM, Ivan Gerasimov 
mailto:ivan.gerasi...@oracle.com>> wrote:


Thank you Alan!


On 23.08.2013 14:28, Alan Bateman wrote:

On 23/08/2013 04:07, Ivan Gerasimov wrote:

Hello everybody!

The method ProcessBuilder#inheritIO() is reported to not
have any effect on Windows platform.
The same story is with
redirectOutput/Input/Error(Redirect.INHERIT) methods.
As the result, standard in/out/err aren't inherited.

It turn out that the culprit is the CREATE_NO_WINDOW flag
passed to CreateProcessW().
MS doc says about this flag: "The process is a console
application that is being run without a console window."

CREATE_NO_WINDOW flag was added with the fix for
http://bugs.sun.com/view_bug.do?bug_id=4244515 to suppress
a console window on a newly created process, when it is
created from a program launched with javaw.exe.
Thus, I left this flag only for cases when the program
doesn't have a console associated with it.

Would you please help review a fix for this problem?

BUGURL: http://bugs.sun.com/view_bug.do?bug_id=8023130
WEBREV:
http://cr.openjdk.java.net/~igerasim/8023130/0/webrev/


Good sleuthing!

Just so I understand, if we have a console (DOS command window
for example) then will dropping CREATE_NO_WINDOW result in a
new window or not?

No new console for a console application without CREATE_NO_WINDOW
flag.
I used a sample program to confirm that:
---
class InheritIO {
public static void main(String[] args) throws Exception {
int err = new

ProcessBuilder(args).inheritIO().redirectErrorStream(true).start().waitFor();
System.err.println("Exit value: " + err);
}
}
---
With the proposed fix running it as '> java InheritIO cmd /?'
copies the output of the command to the existing console.
No new console is created.


One thing that it does highlight is that the coverage for
inherit in ProcessBuilder/Basic.java was not sufficient as
this should have been caught a long time ago. My preference
would be to add to this test rather than introduce a new one
(ProcessBuilder.java is Martin's original mother-of-all tests
for ProcessBuilder).

Yes, I agree. It would be better to integrate this test into
Basic.java.

Sincerely yours,
Ivan

-Alan.

Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings

[Dmitry Nadezhin]

The short answer: because it is a backport to JDK 7 of part of this JDK 8
change:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017958.html

The long answer is the theory behind the change.
Java conversion from decimal string to double is specified as if it happens
in two steps:
1) Convert decimal string to mathematical real number exactly;
2) Round the real number to nearest Java double number. If real number is
in the middle between
   two adjacent Java double numbers then round to double with zero last bit.
The step between adjacent real numbers is called ULP (unit in the last
place or unit of least precision).
Each ULP segment between adjacent real numbers can be split in two half-ULP
segements.
All reals in each half-ULP segment are rounded to same Java double number.
So we can safely patch a long decimal string
when we sure that the real value of patched string lies in the same
half-ulp segment as the real value of the original string.

The above patch keeps first MAX_NDIGIT of long decimal string, discards
tail and repalces it by a single non-zero decimal digit ('1').
It is correct when the half of binary ULP of double number is a multiple of
the decimal ULP of truncated decimal string with MAX_NDIGITS kept.

When I prepared the patch I didn't try to find the optimal MAX_NDIGITS, but
I was sure that MAX_NDIGITS = 1100 is enough.
Here is an expanation:
1) If value of decimal string is larger than pow(10,309) then it is
converted to positive infinity before the test of nDigits;
2) If value of decimal string is smaller than pow(10,309) and larger than
pow(2,53) then it rounds to Java double with ulp >= 2.
   Half-ulp >= 1.
   The patch is correct when decimal ULP of kept digits is 1 or less. It is
true beacuse MAX_NDIGITS = 1100 > 309;
3) If value of decimal string is smaller than pow(2,53) but larger than
0.5*Doulle.MIN_VALUE = pow(2,-1022-52-1), than
   binary ULP is a multiple of pow(2,-1074).
   Half-ULP is a multiple of pow(2,-1075).
   The patch is correct when decimal ULP of kept digits is pow(10,-1075) of
less.
   pow(2,53) has 17 decimal decimal digits. MAX_NDIGITS = 1100 > 1075 + 17 .
4) If value of decimal string is smaller than 0.5*Double.MIN_VALUE then it
is converted to zero before the test of nDigits.


You can treat replacement of 1075 + 17 by 1100 as my paranoia.
It still was interesting for me what is the optimal truncation of decimal
string.
I made an explration after the change was accepted to JDK 8, but I want to
postpone this refinement to JDK 9.

The exploration was accompanied by a formal proof.
I used ACL2 - both a programming language and a proof tool.
http://www.cs.utexas.edu/~moore/acl2/
It's language is Lisp-like.
Here you can find definitions and the proof:
http://cr.openjdk.java.net/~bpb/nDigits/acl2/
The snipped portion of this:


; This function returns such "e" that all decimal digits below "e" can be
; be safely ignnored.
; Informally, 10^e must divide binary half-ulp

(defun find-exp (dec-exponent p q)
   (declare (xargs :guard (and (integerp dec-exponent)
   (integerp p) (> p 1)
   (integerp q) (> q 0
   (let* ((m (expt 10 (- dec-exponent 1)))
  (e (expo m)))
(if (>= e p) 0 (- (ulp-e m p q) 1)))
)

<>

; Final theorem. All numbers in ( m*h, (m+1)*h ) rounds to the same
floating-point number
; if h = 10^(find-exp decexponent)

(defthmd ulp-rnd-rat-near-eq
  (implies (and (integerp p) (> p 1)
(integerp q) (> q 0)
(rationalp h) (> h 0)
(integerp dec-exponent)
(rationalp x)
(<= (expt 10 (- dec-exponent 1)) x)
(rationalp y)
(<= (expt 10 (- dec-exponent 1)) y)
(= h (expt 10 (find-exp dec-exponent p q)))
(not (integerp (/ x h)))
(not (integerp (/ y h)))
(= (fl (/ x h)) (fl (/ y h
 (= (rnd-rat x 'near p q)
(rnd-rat y 'near p q)))
  :hints (
("Goal" :in-theory (disable rnd-rat find-exp ulp))
("Goal'" :use (:instance ulp-rnd-rat-near+-h-find-exp (x x)))
("Goal''" :use (:instance ulp-rnd-rat-near+-h-find-exp (x y)))
   )
)



A function find-exp is defined above in the snipplet.
It has three arguments:
find-exp(dec-exponent,p,q) .
p and q are parameters of floating-point format.
p is number of bits in significand, q is number of bits in exponent.
Java double: p = 53, q = 11 .
Java float: p = 24, q = 8.
dec-exponent specifies a range of real numbers with the same decimal
exponent:
pow(10,dec-exponent-1) <= x < pow(10,dec-exponent)
The function returns the position of lowest decimal digit to be kept.
The algorithm is "take m - minimal value of the range, and return binary
exponent of minimum of its binary half-ulp and 1".

The theorem says that
for any binary floating-point format with parameters p and q.
for any dec-exponent
for step h=pow(10, find-exp(dec-exponent,p,q))
for any

Re: RFR: 8024525 - Make Logger log methods call isLoggable()

[Mandy Chung]

On 9/11/2013 10:59 AM, Daniel Fuchs wrote:

Hi,

Please find below a changeset for a small logging RFE:

8024525 - Make Logger log methods call isLoggable()





Looks good.


...
The test is a bit obscure but it calls all the methods
that have been modified and checks that they log when isLoggable()
is true and don't log when isLoggable() is false.



I only skimmed on the test which looks okay.

thanks
Mandy

Re: Please review clarification of java.time serialized form

[Mike Duigou]

On Sep 11 2013, at 17:56 , Stephen Colebourne wrote:

> HijrahChronology mixes "final transient"  and "transient final". They
> should be consistently one way or the other files should be checked,
> and I think there is an official coding standard for this).

The resource I have been quoted for the "blessed modifier ordering" is:

http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Modifier.html#toString%28int%29

I know it's what Doug uses for JSR166 and there's been a general effort to make 
other usage consistent with this.

Mike

Re: Please review clarification of java.time serialized form

[Stephen Colebourne]

HijrahChronology mixes "final transient"  and "transient final". They
should be consistently one way or the other files should be checked,
and I think there is an official coding standard for this).

Some classes have had transient added, while others haven't. For
example LocalDate doesn't use transient. Since the instance fields are
never directly serialized, but do appear in the serialized form,
perhaps they should be marked as transient?

The byte code numbers for MinguoDate and ThaiBuddhistDate are now out
of line as you removed the ERA constants in Ser.

Otherwise looks like a good improvement.
Stephen



On 6 September 2013 20:06, roger riggs  wrote:
> The specification of the serialized-form[1] of the java.time classes has
> been
> improved in response to issue 8024164: JSR310 serialization should be
> described in detail
>
>  - Add descriptions in the Ser classes of the mapping between the type bytes
> and
>corresponding serialized classes.
>  - Add missing specification of the serial data to writeReplace methods
>  - Add missing readResolve methods that prevent deserialization from
> improperly formatted streams.
>  - The Era that are Enum's do not need customized serialization;
>remove unused writeReplace, writeExternal, and readExternal methods,
>remove unused java.time.chrono.Ser type codes for *Eras and renumber.
>
> [1]:
> http://cr.openjdk.java.net/~rriggs/javadoc-serial-8024164/serialized-form.html
>
> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serial-8024164/
> Javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-serial-8024164/
>
> Please review and comment.
> Thanks, Roger
>
>
>
>

Re: RFR: 8024009 : Remove jdk.map.useRandomSeed system property

[Mike Duigou]

Hi Brent;

Thanks for cleaning this up. The changes look fine.

(A simplifying change in Collections, how unexpected!)

Mike

On Sep 11 2013, at 17:13 , Brent Christian wrote:

> Please review my fix to remove the jdk.map.useRandomSeed system property 
> added earlier in jdk8.
> 
> Some history is in the bug report,
> http://bugs.sun.com/view_bug.do?bug_id=8024009
> 
> HashMap and LinkedHashMap stopped using the random hash seed as of
> 8023463.  This change removes the code to read the jdk.map.useRandomSeed 
> property and setup the hashSeed in Hashtable and WeakHashMap.
> 
> Hashtable got a couple extra things cleaned up:
> * hash() calls were converted back to key.hashCode(), returning the code to 
> its state prior to 7126277 (alternative String hashing).
> 
> * With the hashSeed gone, the 8000955 change [1] should no longer be 
> necessary, and we can go back to using the key's hash value stored in 
> Entry.hash instead of re-calculating it.
> 
> I also removed tests (or test @runs) which are now obsolete.
> 
> Automated build and test runs look good.
> 
> 
> Webrev:
> http://cr.openjdk.java.net/~bchristi/8024009/webrev.00/
> 
> Thanks,
> -Brent
> 
> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/5eed4a92ca8c

RFR: 8024009 : Remove jdk.map.useRandomSeed system property

[Brent Christian]

Please review my fix to remove the jdk.map.useRandomSeed system property 
added earlier in jdk8.


Some history is in the bug report,
http://bugs.sun.com/view_bug.do?bug_id=8024009

HashMap and LinkedHashMap stopped using the random hash seed as of
8023463.  This change removes the code to read the jdk.map.useRandomSeed 
property and setup the hashSeed in Hashtable and WeakHashMap.


Hashtable got a couple extra things cleaned up:
* hash() calls were converted back to key.hashCode(), returning the code 
to its state prior to 7126277 (alternative String hashing).


* With the hashSeed gone, the 8000955 change [1] should no longer be 
necessary, and we can go back to using the key's hash value stored in 
Entry.hash instead of re-calculating it.


I also removed tests (or test @runs) which are now obsolete.

Automated build and test runs look good.


Webrev:
http://cr.openjdk.java.net/~bchristi/8024009/webrev.00/

Thanks,
-Brent

[1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/5eed4a92ca8c

Re: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]

[David DeHaven]

>>> The bottom line is, if what you have now allows you to write to
>>> ~/Documents and you're sandboxed then this change should not
>>> affect your application at all, except maybe in the UI if you're
>>> displaying that path to the user. The user won't notice the
>>> difference otherwise.
>> 
>> My users *will* notice because I display this path in the export dialog,
>> along with the other export options they can use.
> 
> If the path displayed is coming from the selected file, then it will continue 
> to show the correct path.

I don't think I was clear on that comment... if you're building the path from 
say System.getProperty("user.home") + "/Documents/blah" and showing it to the 
user, then that's a problem. If you're showing paths returned by the open/save 
panels then you're fine, the user will never see the container path.

-DrD-

Re: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]

[Brent Christian]

On 9/11/13 11:09 AM, Nicholas Rahn wrote:

On David DeHaven wrote:

>

In my app, I have an export dialog where the user can select the
file to export as well as choose some other export options. In
that dialog, after the user has selected the file to export (via
the file selection dialog), I display the full path to the file
that was returned from the file selection Dialog.

So, if I understand you correctly (sorry, I haven't had time to
verify this myself), with this change, passing in
"user.home/Documents" to the file dialog, the user will see
"~/Documents" in the file dialog, but the full Container path will
be returned as the selected file.


The user will see ~/Documents, and a selected file in ~/Documents will 
have a full path into ~/Documents.


The user is not meant to know anything about the sandbox container, and 
the file dialog enforces that.  If you point it to the Container path, 
it takes you to ~ instead, and from then on you're working within ~.



The bottom line is, if what you have now allows you to write to
~/Documents and you're sandboxed then this change should not
affect your application at all, except maybe in the UI if you're
displaying that path to the user. The user won't notice the
difference otherwise.


My users *will* notice because I display this path in the export dialog,
along with the other export options they can use.


If the path displayed is coming from the selected file, then it will 
continue to show the correct path.



Side note: I'm using SWT and it boils down to the NSOpenPanel and
NSSavePanel.


Yep, that should work fine.


Additionally what's not clear is (again, sorry, I haven't had time to
verify this myself), if I do export the file to the Documents
directory under the Container path, where does the file actually get
saved? In /Users/nick/Documents or in
/Users/nick/Library/Container/my.app/Data/Documents?


A path selected by the user using a file dialog will not point into the 
Container; you'd have to go out of your way to do this.


But if you did, say, write a file into
  /Users/nick/Library/Container/my.app/Data/Documents/
that's where it would get written.


If it saves it to the Container's Documents folder, for other
applications (Finder, Excel, Preview, etc) will it be visible in
/Users/nick/Documents ?


No - as you point out, there's no symlink for Documents - they're 
different directories.



The Documents directory in the Container is NOT a symlink. It
is an actual directory.  So the 2 key questions are:

1. Is there a way to convert from
/Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv to
~/Documents/somefile.csv to display in the UI for the user?


I haven't heard of anything special to help do that.  I don't imagine 
that's something that is expected to be needed.



2. If the file gets saved to
/Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv, can
other applications (such as Excel) access the file from
~/Documents/somefile.csv ?


No, the container directory is hidden.  It would not be visible to the 
Finder or most other apps without some extra work on the part of the user.


Again, this is why files meant for user consumption shouldn't go into 
the container.



What bothers me about this proposed change is that you're taking away
a useful property (the user's $HOME) and replacing it with something
that, to me, is best done in an app's platform specific code, not in
the JDK's. And I still need to know the user's $HOME, since the
answers to my 2 questions above are probably 'no', so I'll have to
add more to my app's Mac sandbox-specific code to get it.


$HOME is not accessible to a sandboxed app, except through a file 
dialog, and the file dialog will still take you $HOME with the updated 
value of user.home.


Given how it all works, the usefulness of $HOME within the sandbox seems 
pretty low (reflected by the fact that Apple returns the Container path 
instead of $HOME when NSHomeDirectory is called within the sandbox).


Our aim here, of course, is to require *less* platform-specific code to 
do the right thing, in particular to minimize extra code needed to move 
an app to the App Sandbox by following Apple's recommendations re: 
NSHomeDirectory vs getpwuid().


Thanks,
-Brent

hg: jdk8/tl/langtools: 8015496: Information that package is deprecated is missing in profiles view

[bhavesh . x . patel]

Changeset: cf37c3775397
Author:bpatel
Date:  2013-09-11 14:50 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cf37c3775397

8015496: Information that package is deprecated is missing in profiles view
Reviewed-by: jjg

! 
src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! 
src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java
+ test/com/sun/javadoc/testProfiles/profile-rtjar-includes-nopkgs.txt

Re: RFR: Caching MethodType's descriptor string improves lambda linkage performance

[Sergey Kuksenko]

On 09/11/2013 09:01 PM, Aleksey Shipilev wrote:
> On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.00/
> 
> As much as I hate to see the hand code tweaking instead of relying on
> compiler to do it's job, I understand this is about interpreter. Seems
> good then.
> 
> * Formatting: "if(...)" should be "if (...")
Will do
> 
> * Formatting: "//NPE" should be "// null check"
I just preserve exiting comments.
Decided don't modify original code which is not important to required
functionality.

> 
> * Formatting: "desc =  " should be "desc = "
> 
> * Formatting: this one should not use braces (for consistency with other
> usages)?
>  364 if(nptype == null) { //NPE
>  365 throw new NullPointerException();
>  366 }
Let ask code owner.
> 
> * Explicit null-checks: implicits via .getClass and .equals always
> bothered me in j.l.i.*; the idea was seemingly to piggyback on the
> compiler intrinsics. 
anyway it is doesn't matter after C1/C2

> Any idea what's the cost of using
> Objects.requireNonNull there?
If we are running under the interpreter Objects.requireNonNull costs
enough to eliminate benefits from this fine tuning.

-- 
Best regards,
Sergey Kuksenko

Re: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]

[Nicholas Rahn]

In my app, I have an export dialog where the user can select the file to
export as well as choose some other export options. In that dialog, after
the user has selected the file to export (via the file selection dialog), I
display the full path to the file that was returned from the file selection
Dialog.

So, if I understand you correctly (sorry, I haven't had time to verify this
myself), with this change, passing in "user.home/Documents" to the file
dialog, the user will see "~/Documents" in the file dialog, but the full
Container path will be returned as the selected file. So in my export
dialog, the user would see the full Container path, even though the file
selection dialog had shown a normal ~/Documents path?

Additionally what's not clear is (again, sorry, I haven't had time to
verify this myself), if I do export the file to the Documents directory
under the Container path, where does the file actually get saved? In
/Users/nick/Documents or in
/Users/nick/Library/Container/my.app/Data/Documents? If it saves it to the
Container's Documents folder, for other applications (Finder, Excel,
Preview, etc) will it be visible in /Users/nick/Documents ?

@Brent - you wrote:
"As it is now, apps needing to write app-specific data would need to
special-case for the App Sandbox and go find the Container directory, since
$HOME is not accessible (and only becomes accessible if the user interacts
with a FileDialog)."

Well, I already had to special case where I write app-specific data for
each of the 3 platforms I support (Mac, Windows & Linux). Any Java app that
is really cross-platform is going to have some platform specific code and
platform specific jvm-launching/packaging, if they want to do things the
recommended way for that platform. A sandboxed Mac version was just another
special case.  For that, I use the AppBundler fork to launch the JVM and
set some MAS specific properties so that I know that I'm running in the Mac
sandbox and where the Container directory is. Then the right
platform-specific initialization code in my app can be used to build the
app-specific data in the right place.

Thanks,
Nick

On Wed, Sep 11, 2013 at 2:27 AM, Brent Christian  wrote:

> Adding a little to what Dave said, based on my understanding...
>
> On 9/10/13 3:36 PM, David DeHaven wrote:
>
> > Nicholas Rahn wrote:
>
>>
>>  In my app, the user selects where he wants to export individual
>>> files, such as CSVs and PDFs. These are files he'll use outside of
>>> my app.
>>>
>>> If user.home points to the app's sandbox Container, it will break
>>> this usage.  Opening a file dialog to
>>> /Users/Bob/Library/Containers/**my.app/Data/Documents will definitely
>>> confuse the user and if they save a file there, they will never be
>>> able to find it later from outside of my app.
>>>
>>
>> The user won't know the difference, all they'll see is ~/Documents as
>> provided by powerbox.
>>
>
> Note that PowerBox+NSOpenPanel recognize the Container path, and
> automagically take the user to their *actual* $HOME, Documents, etc
> directories.
>
> With this change, then, telling a native FileDialog to open user.home (or
> user.home/Documents, etc), will (still) show the user their real $HOME (or
> $HOME/Documents, etc) directory, whether sandboxed (user.home is the app
> Container, redirected by PowerBox to $HOME) or not (user.home=$HOME).
>
> The selected file returned from the FileDialog will point to a location
> within $HOME, and because of the *.files.user-selected.* entitlement, the
> app will now have access to it.
>
>
>  Yes, I understand the whole sandboxing concept. I'm not asking for
>>> unrestricted access to the file system. I use the
>>> "com.apple.security.files.**user-selected.read-write" entitlement so
>>> that the user can select where he wants to save files, and I want
>>> to present him with a standard, well-known, default location for
>>> that (like ~/Documents).
>>>
>>> If user.home doesn't point to the user's actual home folder (i.e.
>>> NSHomeDirectoryForUser), it makes creating a standard, well-known
>>> location path (like ~/Documents) much more difficult.
>>>
>>
> BTW, NSHomeDirectoryForUser() for the current user returns the same
> sandboxed value as NSHomeDirectory().
>
> Without this change, user.home is obtained using the POSIX getpwuid() call
> - really not the Apple-recommended way for dealing with the sandbox.
>
>
>  Powerbox solves exactly that problem... and yes, yes it is users home
>> folder, from the perspective of a sandboxed application!
>>
> >
> > ...
>
> >
>
>> the user will never see the app container path unless you
>> explicitly report it to them.
>>
>
> ...though it's really not mean to be presented to the user (and I haven't
> been able to convince FileDialog to take me to it).  The Container
> directory is meant only for files used by the app itself. From [1]:
>
> "The container is in a hidden location, and so users do not interact with
> it directly. Specifically, the container is not for us

Re: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]

[Nicholas Rahn]

> > In my app, I have an export dialog where the user can select the file to
> export as well as choose some other export options. In that dialog, after
> the user has selected the file to export (via the file selection dialog), I
> display the full path to the file that was returned from the file selection
> Dialog.
> >
> > So, if I understand you correctly (sorry, I haven't had time to verify
> this myself), with this change, passing in "user.home/Documents" to the
> file dialog, the user will see "~/Documents" in the file dialog, but the
> full Container path will be returned as the selected file. So in my export
> dialog, the user would see the full Container path, even though the file
> selection dialog had shown a normal ~/Documents path?
>
> If you're using FileDialog (or some variant that eventually boils down to
> NSSavePanel) then your app will continue to function properly. If you're
> using a custom dialog then you'll need to switch to FileDialog (or
> variant...) since NSSavePanel is what triggers powerbox to do it's thing,
> if NSSavePanel is not invoked to choose the exported file then your app
> will never be granted permission to write to the file (unless you incant
> some other, more complicated, voodoo magic).
>
> The bottom line is, if what you have now allows you to write to
> ~/Documents and you're sandboxed then this change should not affect your
> application at all, except maybe in the UI if you're displaying that path
> to the user. The user won't notice the difference otherwise.
>
>
My users *will* notice because I display this path in the export dialog,
along with the other export options they can use.

Side note: I'm using SWT and it boils down to the NSOpenPanel and
NSSavePanel.


> > Additionally what's not clear is (again, sorry, I haven't had time to
> verify this myself), if I do export the file to the Documents directory
> under the Container path, where does the file actually get saved? In
> /Users/nick/Documents or in
> /Users/nick/Library/Container/my.app/Data/Documents? If it saves it to the
> Container's Documents folder, for other applications (Finder, Excel,
> Preview, etc) will it be visible in /Users/nick/Documents ?
>
> If you look in the app container you'll see that the Data directory
> returned by NSHomeDirectory() is set up with symlinks back to the users
> home directory, so when you access files in those directories you're
> accessing the correct files. IOW,
> ~/Library/Containers/com.blah.someapp/Data/Documents is the same as
> ~/Documents, the system does all this for you when the app container is
> created.
>
>
Actually, the Documents directory in the Container is NOT a symlink. It is
an actual directory.  So the 2 key questions are:

1. Is there a way to convert from
/Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv to
~/Documents/somefile.csv to display in the UI for the user?

2. If the file gets saved to
/Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv, can
other applications (such as Excel) access the file from
~/Documents/somefile.csv ?


> > @Brent - you wrote:
> > "As it is now, apps needing to write app-specific data would need to
> special-case for the App Sandbox and go find the Container directory, since
> $HOME is not accessible (and only becomes accessible if the user interacts
> with a FileDialog)."
> >
> > Well, I already had to special case where I write app-specific data for
> each of the 3 platforms I support (Mac, Windows & Linux). Any Java app that
> is really cross-platform is going to have some platform specific code and
> platform specific jvm-launching/packaging, if they want to do things the
> recommended way for that platform. A sandboxed Mac version was just another
> special case.  For that, I use the AppBundler fork to launch the JVM and
> set some MAS specific properties so that I know that I'm running in the Mac
> sandbox and where the Container directory is. Then the right
> platform-specific initialization code in my app can be used to build the
> app-specific data in the right place.
>
> That's the unfortunately truth of modern (secure) applications, each
> platform has it's own way of doing things. Have you tried Windows 8 yet?
>
> Changes like what Brent is proposing is helping to keep Java consistent
> with the ever evolving app model, which is ultimately a good thing.
>
>
Platform specific code for any Java desktop app is inevitable. What bothers
me about this proposed change is that you're taking away a useful property
(the user's $HOME) and replacing it with something that, to me, is best
done in an app's platform specific code, not in the JDK's. And I still need
to know the user's $HOME, since the answers to my 2 questions above are
probably 'no', so I'll have to add more to my app's Mac sandbox-specific
code to get it.

Windows 8: I do have a few people using my software on W8, but I have not
done anything specific for it. That is to say, I do the same platform
specific stuff as

Re: RFR: Direct LambdaMetaFactory invocation from CallSite significantly improves lambda linkage performance

[John Rose]

Yes, this is a good tactic, but as written it is too much of a point hack for 
lambdas (important though they are).

I have an alternate solution I would like you to measure.  It provides a fast 
path for other BSM lookups like Nashorn's, so (if it works well for lambda) it 
is preferable.

I will attach a patch to the bug report.

— John

On Sep 11, 2013, at 9:23 AM, Sergey Kuksenko  wrote:

> Please review the webrev at:
> 
> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/
> 
> LambdaMetafactory is is a quite frequent bootstrap method for
> invokedynamic in JDK8.
> We can do direct method (LambdaMetafactory) invocation as fastpath when
> proved that bootstrap MethodHandle points to LambdaMetafactory.
> The modification gives +10% - +35% to lambda linkage performance
> (depends on amount of lambdas).
> 
> -- 
> Best regards,
> Sergey Kuksenko

Re: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type

[Joel Borggrén-Franck]

Thanks everyone for the reviews and suggestions for improvements.

cheers
/Joel

On Sep 4, 2013, at 3:55 PM, Joel Borggren-Franck  wrote:

> Hi,
> 
> Please review fix for: http://bugs.sun.com/view_bug.do?bug_id=4987375
> 
> Webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.01/
> Specdiff: 
> http://cr.openjdk.java.net/~jfranck/4987375/specdiff/java/lang/Class.html
> 
> There are two issues here,
> 
> - First a getInterfaces() call on an array Class instance does return
>  Cloneable and Serializable. This is specified for
>  getGenericInterfaces() but not specified in getInterface(). The fix is
>  to update the spec to match the implementation, which also aligns it
>  with getGenericInterfaces().
> 
> - Also even though JLS states that array types have an implementation of
>  clone() overriding the Object method, it is not included in
>  get{Declared}Method{s}. Again the fix is to note this in the spec.
> 
> Me and Alex have also worked on the structure of the docs trying to
> unify them and have a better flow. Rough outline is:
> 
> 
> 
> 
> 
> 
> cheers
> /Joel

hg: jdk8/tl/jdk: 8024500: Missing API coverage for java.util.function.BiFunction andThen

[henry . jen]

Changeset: 70aab3db56de
Author:henryjen
Date:  2013-09-11 11:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70aab3db56de

8024500: Missing API coverage for java.util.function.BiFunction andThen
Reviewed-by: mduigou, alanb

+ test/java/util/Collections/SingletonIterator.java
+ test/java/util/function/BiFunction/BiFunctionTest.java

Re: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]

[Nicholas Rahn]

I use user.home to do things like:

String userHomePath = System.getProperty("user.home"**);
myFileDialog.setDirectory(**userHomePath + "/Documents");

In my app, the user selects where he wants to export individual files, such
as CSVs and PDFs. These are files he'll use outside of my app.

If user.home points to the app's sandbox Container, it will break this
usage.  Opening a file dialog to
/Users/Bob/Library/Containers/my.app/Data/Documents will definitely confuse
the user and if they save a file there, they will never be able to find it
later from outside of my app.

Yes, I understand the whole sandboxing concept. I'm not asking for
unrestricted access to the file system. I use the "com.apple.
security.files.user-selected.read-write" entitlement so that the user can
select where he wants to save files, and I want to present him with a
standard, well-known, default location for that (like ~/Documents).

If user.home doesn't point to the user's actual home folder (i.e.
NSHomeDirectoryForUser), it makes creating a standard, well-known location
path (like ~/Documents) much more difficult.  (And IMHO, it breaks the
definition of the user.home property: "User home directory", not "App home
directory".)

Nick



On Tue, Sep 10, 2013 at 10:32 PM, David DeHaven wrote:

>
> > This isn't every other platform, this is Mac OS X and all the baggage
> that goes along with it! :)
> >
> > What do you actually need access to user.home for? Do you have empirical
> evidence that this will break your application?
> >
> > The whole point of sandboxing is you no longer have direct access to the
> entire system. The app must play inside it's sandbox, period, end of story.
> Gone are the days of unrestricted access to the filesystem, that's the
> whole point of sandboxing! This is all pretty well outlined in the
> "Sandboxing Your App" documentation on ADC.
> >
> > Powerbox is there to solve your problem of opening user documents (with
> the right entitlements) and there are mechanisms in place to allow opening
> related files (with the users permission of course). Even a sandboxed
> application can show the user the contents of his various folders in a file
> open dialog. This all happens regardless of whether NSHomeDirectory returns
> /Users/JoeBob or /Users/JoeBob/Library/Containers/com.blah.someapp
>
>
> That should have been:
> /Users/JoeBob/Library/Containers/com.blah.someapp/Data
>
> Which, btw, is a shadow of the users home directory... including symlinks
> to various folders contained therein.
>
> -DrD-
>
>
>

hg: jdk8/tl/nashorn: 6 new changesets

[sundararajan . athijegannathan]

Changeset: b6c7cd8b962b
Author:jlaskey
Date:  2013-09-09 13:35 -0300
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b6c7cd8b962b

8024397: Nashorn FX Libraries need to be finalized.
Reviewed-by: sundar, hannesw, lagergren
Contributed-by: james.las...@oracle.com

! src/jdk/nashorn/internal/runtime/resources/fx/base.js
! src/jdk/nashorn/internal/runtime/resources/fx/fxml.js
! src/jdk/nashorn/internal/runtime/resources/fx/graphics.js
! src/jdk/nashorn/internal/runtime/resources/fx/media.js
! src/jdk/nashorn/internal/runtime/resources/fx/swing.js
! src/jdk/nashorn/internal/runtime/resources/fx/swt.js
! src/jdk/nashorn/internal/runtime/resources/fx/web.js

Changeset: 483b42e56da4
Author:jlaskey
Date:  2013-09-10 14:21 -0300
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/483b42e56da4

8024539: FX Libraries update missing file
Reviewed-by: sundar
Contributed-by: james.las...@oracle.com

! src/jdk/nashorn/internal/runtime/resources/fx/controls.js

Changeset: badf750dda21
Author:attila
Date:  2013-09-11 10:27 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/badf750dda21

8024130: We no longer need slots for temporaries in self-assign indices
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/codegen/Attr.java

Changeset: 2d4c8fa8a5f4
Author:sundar
Date:  2013-09-11 20:49 +0530
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2d4c8fa8a5f4

8024615: Refactor ScriptObjectMirror and JSObject to support external JSObject 
implementations
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/api/scripting/JSObject.java
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeFunction.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java
! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java
+ src/jdk/nashorn/internal/runtime/arrays/JSObjectIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseJSObjectIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectMirrorIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ScriptObjectMirrorIterator.java
! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java
+ test/src/jdk/nashorn/api/scripting/PluggableJSObjectTest.java
! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java

Changeset: 66db7354e7e2
Author:sundar
Date:  2013-09-11 22:51 +0530
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/66db7354e7e2

8024644: PluggableJSObject.iteratingJSObjectTest fails with jdk8-tl build
Reviewed-by: jlaskey, hannesw

! test/src/jdk/nashorn/api/scripting/PluggableJSObjectTest.java

Changeset: aa86166c6770
Author:sundar
Date:  2013-09-11 22:53 +0530
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/aa86166c6770

Merge

- src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectMirrorIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ScriptObjectMirrorIterator.java

Re: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]

[Nicholas Rahn]

If you're saying that NSHomeDirectory is the correct behaviour for the Java
user.home property, then I have to disagree. On every other platform,
including non-sandboxed Mac, user.home is the actual user's home directory
(i.e. /home/ or /Users/ or C:\Users\). Setting user.home
to the *application's* home directory (which is what NSHomeDirectory
returns in a sandboxed environment) would seem to me to break the
definition of the user.home property.

On a mac, in a sandboxed and non-sandboxed environment, I would expect
user.home to be NSHomeDirectoryForUser. A sandboxed Java app definitely
needs to know about the app's Container directory (and even whether it's
actually being run sandboxed or not), but redefining user.home doesn't seem
like the right solution. Having AppBundler (or even the JRE) provide that
information via special properties feels better from my developer's
perspective.

Nick



On Fri, Sep 6, 2013 at 6:18 PM, David DeHaven wrote:

>
> >> As someone with a Java app in the Mac App Store (MAS), I would like to
> vote against this change.
> >>
> >> It is still important to know the user's actual home directory
> (/Users/) even if the app is running in the sandbox.  Using the
> entitlement, com.apple.security.files.user-selected.read-write, we can
> still write to user selected directories (such as ~/Documents).  So
> changing the user.home property to point to somewhere in the app's
> Container would make it more difficult to get the actual home directory and
> thus, other directories that the end-user is familiar with. I also think
> this change would lead to more developer confusion and make application
> code more complicated.
> >>
> >> I don't know all what the user.home property is used for in the JDK
> itself, but concerns about the MAS sandbox would be, IMHO, better handled
> using special Mac/MAS only properties, such as those setup by
> infinitekind's Appbundler fork on bitbucket:
> https://bitbucket.org/infinitekind/appbundler
> >>
> >> Nick
> > I'm sure Brent wants to do the right thing here and maybe this needs
> some input from the Apple or other Mac-savvy folks as to whether sandboxed
> apps are really supposed to know about the actual user's home directory.
> >
> > FWIW, the original recommendaiton to switch to NSHomeDirectory came from
> Scott Kovatch when he was working on Application Bundler. It's very
> possible that things have changed since then.
>
>
> I haven't had a chance to look at the changes yet, so this may be a bit
> premature...
>
>
> Using NSHomeDirectory is the CORRECT behavior, whether the app is
> sandboxed or not (that extends to ALL apps, not just Java based).
>
> If the application needs to access Documents, Music, Movies, etc then
> those entitlements need to be added. Additionally, even if sandboxed an
> application can open documents in any folder the user has access to as long
> as the standard file chooser is used (which I believe we already do), the
> app will be granted (indirect) access to the selected file(s).
>
> -DrD-
>
>

RFR: 8024525 - Make Logger log methods call isLoggable()

[Daniel Fuchs]

Hi,

Please find below a changeset for a small logging RFE:

8024525 - Make Logger log methods call isLoggable()



This change makes the various Logger logging method call isLoggable()
instead of simply inlining the checks.
This should make the life easier for subclasses of Logger which
want to control when messages should be logged.

The test is a bit obscure but it calls all the methods
that have been modified and checks that they log when isLoggable()
is true and don't log when isLoggable() is false.

best regards,

-- daniel

hg: jdk8/tl/jdk: 8024338: Constant fields introduced by JDK-4759491 fix in b94 are exposed as public fields in public API

[xueming . shen]

Changeset: 60b4cbdb446d
Author:sherman
Date:  2013-09-11 11:29 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60b4cbdb446d

8024338: Constant fields introduced by JDK-4759491 fix in b94 are exposed as 
public fields in public API
Summary: to move the new constants out of ZipConstants.java
Reviewed-by: martin

! src/share/classes/java/util/zip/ZipConstants.java
! src/share/classes/java/util/zip/ZipConstants64.java
! src/share/classes/java/util/zip/ZipEntry.java

Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings

[Aleksey Shipilev]

On 09/11/2013 12:58 AM, Brian Burkhalter wrote:
> Please review at your convenience.
> 
> Issue:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024356
> Webrev:   http://cr.openjdk.java.net/~bpb/8024356/

"MAX_NDIGITS = 1100"
 Stupid question. Why exactly this magic number?

-Aleksey.

Re: RFR: Direct LambdaMetaFactory invocation from CallSite significantly improves lambda linkage performance

[Aleksey Shipilev]

On 09/11/2013 08:53 PM, Sergey Kuksenko wrote:
>> On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
>>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/
>>
>> * webrev metadata: "invokation" -> "invocation"
> misprint. Should I fix it right now, or may it be done later?

I think later is good. Don't propagate that typo into the final
changset, that what I meant.

>> * Why $caller is MethodHandles.Lookup now? Is it known to have that type?
> Yes.
> MethodHandles.Lookup is return type of IMPL_LOOKUP.in()

I see, OK then.

>> * I would put the entire LMF.metafactory call inside the new method.
>> That way, instanceof checks are right before the (otherwise potentially
>> unsafe) casts.
> 
> At that case the single method should return two values: boolean flag
> success/failure and CallSite.

Is "null" already reserved as the return value for metafactory? What
bothers me is that I need to scroll down to figure out the arguments are
indeed checked before you do the casts.

>>> The modification gives +10% - +35% to lambda linkage performance
>>> (depends on amount of lambdas).
>>
>> Any JSR292/Nashorn benchmarks to prove it does not degrade the "usual"
>> bootstrap scenarios? I understand most of the performance is dominated
>> by already-linked sites, but still.
> 
> I check it on octane - no perf difference. But I need somebody to
> recheck my measurements.

Good. That is good enough for me.

-Aleksey.

Re: RFR: Caching MethodType's descriptor string improves lambda linkage performance

[Aleksey Shipilev]

On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.00/

As much as I hate to see the hand code tweaking instead of relying on
compiler to do it's job, I understand this is about interpreter. Seems
good then.

* Formatting: "if(...)" should be "if (...")

* Formatting: "//NPE" should be "// null check"

* Formatting: "desc =  " should be "desc = "

* Formatting: this one should not use braces (for consistency with other
usages)?
 364 if(nptype == null) { //NPE
 365 throw new NullPointerException();
 366 }

* Explicit null-checks: implicits via .getClass and .equals always
bothered me in j.l.i.*; the idea was seemingly to piggyback on the
compiler intrinsics. Any idea what's the cost of using
Objects.requireNonNull there?

-Aleksey.

RFR: 8024338: Constant fields introduced by JDK-4759491 fix in b94 are exposed as public fields in public API

[Xueming Shen]

Hi,

The background of this bug is the anti-pattern of defining constants in 
interfaces. In this case all the
constants defined in package private interface ZipConstants are being exposed 
as public fields of the
classes that implements it. This is JDK 1.0 era design/implementation, 
something we can't reverse any
more for compatibility concern. However it appears reasonable to not further 
add more new constants
into this interface class while it might be a logical place for them. The 
proposed change here is to move
these constants (all added in jdk8) to ZipConstants64.java, with comment add 
for why they are there,
so these constants will be kept as an implementation details.

http://cr.openjdk.java.net/~sherman/8024338/webrev

Thanks,
-Sherman

Re: RFR: Direct LambdaMetaFactory invocation from CallSite significantly improves lambda linkage performance

[Sergey Kuksenko]

> On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/
> 
> * webrev metadata: "invokation" -> "invocation"

misprint. Should I fix it right now, or may it be done later?

> * Why $caller is MethodHandles.Lookup now? Is it known to have that type?
Yes.
MethodHandles.Lookup is return type of IMPL_LOOKUP.in()


> * I would put the entire LMF.metafactory call inside the new method.
> That way, instanceof checks are right before the (otherwise potentially
> unsafe) casts.

At that case the single method should return two values: boolean flag
success/failure and CallSite.

>> The modification gives +10% - +35% to lambda linkage performance
>> (depends on amount of lambdas).
> 
> Any JSR292/Nashorn benchmarks to prove it does not degrade the "usual"
> bootstrap scenarios? I understand most of the performance is dominated
> by already-linked sites, but still.

I check it on octane - no perf difference. But I need somebody to
recheck my measurements.

-- 
Best regards,
Sergey Kuksenko

Re: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]

[David DeHaven]

> In my app, I have an export dialog where the user can select the file to 
> export as well as choose some other export options. In that dialog, after the 
> user has selected the file to export (via the file selection dialog), I 
> display the full path to the file that was returned from the file selection 
> Dialog. 
> 
> So, if I understand you correctly (sorry, I haven't had time to verify this 
> myself), with this change, passing in "user.home/Documents" to the file 
> dialog, the user will see "~/Documents" in the file dialog, but the full 
> Container path will be returned as the selected file. So in my export dialog, 
> the user would see the full Container path, even though the file selection 
> dialog had shown a normal ~/Documents path?

If you're using FileDialog (or some variant that eventually boils down to 
NSSavePanel) then your app will continue to function properly. If you're using 
a custom dialog then you'll need to switch to FileDialog (or variant...) since 
NSSavePanel is what triggers powerbox to do it's thing, if NSSavePanel is not 
invoked to choose the exported file then your app will never be granted 
permission to write to the file (unless you incant some other, more 
complicated, voodoo magic).

The bottom line is, if what you have now allows you to write to ~/Documents and 
you're sandboxed then this change should not affect your application at all, 
except maybe in the UI if you're displaying that path to the user. The user 
won't notice the difference otherwise.


> Additionally what's not clear is (again, sorry, I haven't had time to verify 
> this myself), if I do export the file to the Documents directory under the 
> Container path, where does the file actually get saved? In 
> /Users/nick/Documents or in 
> /Users/nick/Library/Container/my.app/Data/Documents? If it saves it to the 
> Container's Documents folder, for other applications (Finder, Excel, Preview, 
> etc) will it be visible in /Users/nick/Documents ?

If you look in the app container you'll see that the Data directory returned by 
NSHomeDirectory() is set up with symlinks back to the users home directory, so 
when you access files in those directories you're accessing the correct files. 
IOW, ~/Library/Containers/com.blah.someapp/Data/Documents is the same as 
~/Documents, the system does all this for you when the app container is created.


> @Brent - you wrote:
> "As it is now, apps needing to write app-specific data would need to 
> special-case for the App Sandbox and go find the Container directory, since 
> $HOME is not accessible (and only becomes accessible if the user interacts 
> with a FileDialog)."
> 
> Well, I already had to special case where I write app-specific data for each 
> of the 3 platforms I support (Mac, Windows & Linux). Any Java app that is 
> really cross-platform is going to have some platform specific code and 
> platform specific jvm-launching/packaging, if they want to do things the 
> recommended way for that platform. A sandboxed Mac version was just another 
> special case.  For that, I use the AppBundler fork to launch the JVM and set 
> some MAS specific properties so that I know that I'm running in the Mac 
> sandbox and where the Container directory is. Then the right 
> platform-specific initialization code in my app can be used to build the 
> app-specific data in the right place.  

That's the unfortunately truth of modern (secure) applications, each platform 
has it's own way of doing things. Have you tried Windows 8 yet?

Changes like what Brent is proposing is helping to keep Java consistent with 
the ever evolving app model, which is ultimately a good thing.

-DrD-

Re: RFR: Direct LambdaMetaFactory invocation from CallSite significantly improves lambda linkage performance

[Aleksey Shipilev]

Seems like a good trick.

On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/

* webrev metadata: "invokation" -> "invocation"

* Why $caller is MethodHandles.Lookup now? Is it known to have that type?

* I would put the entire LMF.metafactory call inside the new method.
That way, instanceof checks are right before the (otherwise potentially
unsafe) casts.

> The modification gives +10% - +35% to lambda linkage performance
> (depends on amount of lambdas).

Any JSR292/Nashorn benchmarks to prove it does not degrade the "usual"
bootstrap scenarios? I understand most of the performance is dominated
by already-linked sites, but still.

-Aleksey.

RFR: Caching MethodType's descriptor string improves lambda linkage performance

[Sergey Kuksenko]

Please review the webrev at:

http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.00/

MethodType.toMethodDescriptorString() is frequently invoked when
generating lambda classes from InnerClassLambdaMetafactory.
Caching resulting string into the field of MethodType  gives +5% - +10%
to lambda linkage performance.

Minor performance improvement: private method "checkPtype" was inlined
and eliminated. "checkRtype" and "checkPtypes" were refactored for
better perfomance in HotSpot interpreter (important for lambda linkage).
overall result +1%.


-- 
Best regards,
Sergey Kuksenko

RFR: Direct LambdaMetaFactory invocation from CallSite significantly improves lambda linkage performance

[Sergey Kuksenko]

Please review the webrev at:

http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/

LambdaMetafactory is is a quite frequent bootstrap method for
invokedynamic in JDK8.
We can do direct method (LambdaMetafactory) invocation as fastpath when
proved that bootstrap MethodHandle points to LambdaMetafactory.
The modification gives +10% - +35% to lambda linkage performance
(depends on amount of lambdas).

-- 
Best regards,
Sergey Kuksenko

Re: RFR: 8024500: Missing API coverage for java.util.function.BiFunction andThen

[Henry Jen]

Thanks, it should be deliver. I'll fix before push it.

Cheers,
Henry

On Sep 10, 2013, at 10:19 PM, Mike Duigou  wrote:

> Tests look fine. 
> 
> In the BiFunction test the unknown word "delieve" is used. I am not sure what 
> word was intended.
> 
> Mike
> 
> On Sep 10 2013, at 22:03 , Henry Jen wrote:
> 
>> Sorry I forgot it again. Copied but not pasted. :(
>> 
>> http://cr.openjdk.java.net/~henryjen/tl/8024500/0/webrev/
>> 
>> Thanks for reviewing.
>> 
>> Cheers,
>> Henry
>> 
>> On Sep 10, 2013, at 8:47 PM, Henry Jen  wrote:
>> 
>>> Hi,
>>> 
>>> Please review a simple webrev that adds two tests, one for
>>> 
>>> java.util.function.BiFunction.andThen() another to cover
>>> java.util.Collections.SingletonIterator.
>>> 
>>> Cheers,
>>> Henry
>> 
> 

Re: RFR: 8024500: Missing API coverage for java.util.function.BiFunction andThen

[Henry Jen]

Yes, the alignment is off, will fix.

Cheers,
Henry


On Sep 11, 2013, at 7:36 AM, Alan Bateman  wrote:

> On 11/09/2013 06:03, Henry Jen wrote:
>> Sorry I forgot it again. Copied but not pasted. :(
>> 
>> http://cr.openjdk.java.net/~henryjen/tl/8024500/0/webrev/
>> 
>> Thanks for reviewing.
>> 
> A minor comment but you might want to double check SingletonIterator.java as 
> it looks a bit misaligned (might be tabs, might be webrev).
> 
> -Alan.

hg: jdk8/tl/jdk: 2 new changesets

[roger . riggs]

Changeset: 292d93f32aa1
Author:rriggs
Date:  2013-09-11 10:16 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/292d93f32aa1

8024164: JSR310 serialization should be described in details
Summary: The serialized-form.html should specify the stream format for 
interoperability
Reviewed-by: alanb

! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Ser.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZoneRegion.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/HijrahEra.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/JapaneseEra.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/MinguoEra.java
! src/share/classes/java/time/chrono/Ser.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistEra.java
! src/share/classes/java/time/zone/Ser.java
! src/share/classes/java/time/zone/ZoneOffsetTransition.java
! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java
! src/share/classes/java/time/zone/ZoneRules.java
! test/java/time/tck/java/time/chrono/TCKChronologySerialization.java

Changeset: 8b4aef582087
Author:rriggs
Date:  2013-09-11 10:35 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b4aef582087

Merge

hg: jdk8/tl/jdk: 2 new changesets

[michael . x . mcmahon]

Changeset: 1ec241501e60
Author:michaelm
Date:  2013-09-11 15:00 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ec241501e60

8024601: Windows networking code prevents use of -Xlint:auxiliaryclass in jdk 
build
Reviewed-by: chegar

! src/share/classes/java/net/AbstractPlainSocketImpl.java
+ src/share/classes/java/net/InetAddressContainer.java

Changeset: 7dcb9d944910
Author:michaelm
Date:  2013-09-11 15:02 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7dcb9d944910

Merge

Re: RFR: 8024500: Missing API coverage for java.util.function.BiFunction andThen

[Alan Bateman]

On 11/09/2013 06:03, Henry Jen wrote:

Sorry I forgot it again. Copied but not pasted. :(

http://cr.openjdk.java.net/~henryjen/tl/8024500/0/webrev/

Thanks for reviewing.

A minor comment but you might want to double check 
SingletonIterator.java as it looks a bit misaligned (might be tabs, 
might be webrev).


-Alan.

Re: Please review clarification of java.time serialized form

[Alan Bateman]

On 06/09/2013 20:06, roger riggs wrote:

:

Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serial-8024164/
Javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-serial-8024164/

I looked through the webrev and sampled a few cases in the serialized 
form and it looks okay to me.


-Alan.

RFR(S + new test) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError

[David Chase]

[repeat]
new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
Same small changes to the sources, plus a test.

bug: wrong exception was thrown in call of methodhandle to private method

fix: detect special case of IllegalAccessException, convert to 
IllegalAccessError

testing:
verified that the test would pass with modified library
verified that the test would fail with old library
verified that the test would fail if the class substitution (for some reason) 
did not occur
jtreg of jdk/test/java/lang/invoke -- note that the new exception thrown is a 
subtype of the old one, so this is unlikely to create a new surprise

hg: jdk8/tl/jdk: 6962494: Update documentation on Executable.getParameterAnnotations()

[eric . mccorkle]

Changeset: c3ef78cd9081
Author:emc
Date:  2013-09-11 09:24 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3ef78cd9081

6962494: Update documentation on Executable.getParameterAnnotations()
Summary: Update javadoc comments on getParameterAnnotations to correctly 
describe its behavior
Reviewed-by: darcy, jfranck

! src/share/classes/java/lang/reflect/Executable.java

hg: jdk8/tl/jdk: 8024332: sun/util/resources/en split between rt.jar and localedata.jar

[naoto . sato]

Changeset: 7bfe3da4fad6
Author:naoto
Date:  2013-09-11 05:38 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bfe3da4fad6

8024332: sun/util/resources/en split between rt.jar and localedata.jar
Reviewed-by: alanb, erikj

! make/java/java/genlocales.gmk
! make/java/java/localegen.sh
! make/java/text/base/FILES_java.gmk
! make/java/util/FILES_java.gmk
! make/java/util/FILES_properties.gmk
! make/sun/text/FILES_java.gmk
! make/sun/text/FILES_properties.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcLocaleDataMetaInfo.gmk
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! 
src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template

Re: JDK-6962494: Update documentation on Executable.getParameterAnnotations()

[Eric McCorkle]

Thanks for the review.

On 09/10/13 17:31, Joe Darcy wrote:
> Hi Eric,
> 
> Looks good, modulo some typos:
> 
>  434  * this object.  Synthetic and mandated parameters (see
>  435  * explanation below), such as the inner this parameter to an
> 
> Inner class constructors have an *outer* this parameter.

Argh!  Fixed.

> 
>  437  * array.  If the executable has no parameters (including
>  438  * synthetic and mandated parameters), ...
> 
> For extra clarity, I would rephrase this as "... (including no synthetic
> and no mandated parameters) ..."
> 

I worded this as "If the executable has no parameters (meaning no
formal, no synthetic, and no mandated...)"

> Thanks,
> 
> -Joe
> 
> On 9/10/2013 6:28 AM, Eric McCorkle wrote:
>> A new webrev has been posted, with some improvements to the comment.
>>
>> On 09/09/13 17:41, Eric McCorkle wrote:
>>> Hello,
>>>
>>> Please review this patch which updates the javadoc comments for
>>> java.lang.reflect.Executable.getParameterAnnotations().  The patch
>>> corrects the javadocs to describe the actual behavior of this method.
>>> It also refers users to the new java.lang.reflect.Parameter API.
>>>
>>> See comments on the bug report for more details:
>>> https://bugs.openjdk.java.net/browse/JDK-6962494
>>>
>>> The webrev is here:
>>> http://cr.openjdk.java.net/~emc/6962494/
>>>
>>> This is also under review in crucible.  The review link is here:
>>> http://sthinfra10.se.oracle.com:8060/cru/CR-JDK8TL-171
>>>
>>> Thanks,
>>> Eric
>>>
> 

hg: jdk8/tl/langtools: 8024510: lib/combo/tools/javac/combo/TemplateTest.java fails

[eric . mccorkle]

Changeset: 65c218b25b61
Author:emc
Date:  2013-09-11 08:30 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/65c218b25b61

8024510: lib/combo/tools/javac/combo/TemplateTest.java fails
Summary: Edit regex in Template to allow "MAJOR." pattern.
Reviewed-by: briangoetz

! test/lib/combo/tools/javac/combo/Template.java

Re: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8

[Magnus Ihse Bursie]

On 2013-09-11 00:00, Kumar Srinivasan wrote:

Here are the updated changes:

The build changes are here:
  http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/
the delta changes since last reviewed:
http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/webrev.delta/index.html 



The jdk changes are here:
  http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.2/
The delta changes since last reviewed:
http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.2/webrev.delta/index.html 



Looks good!

/Magnus

hg: jdk8/tl/jdk: 8023090: Additional debug info for java/net/NetworkInterface/Equals.java

[chris . hegarty]

Changeset: d389dedd1ccb
Author:chegar
Date:  2013-09-11 11:32 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d389dedd1ccb

8023090: Additional debug info for java/net/NetworkInterface/Equals.java
Reviewed-by: alanb

! test/java/net/NetworkInterface/Equals.java

Re: @Supported design issues

[Alan Bateman]

On 11/09/2013 03:50, David M. Lloyd wrote:


I'm aware of that; however I guarantee you that if you try to munge 
this functionality up with the concept of exported classes or packages 
before the module system is realized, it's going to end up wrong and 
we'll have yet more dead cruft in the API.
There isn't any real functionality here, it's simply an effort to make 
it clear which com.sun.** APIs are okay for developers to depend on. 
This is useful for JDK maintainers too.


If/when we move to a modular JDK then it would be reasonable to expect 
that the @Exported APIs would be APIs that applications can continue to 
depend on. It may be that some of the non-@Exported JDK-specific APIs 
are completely hidden from applications, in which case having @Exported 
now is a good thing as it helps developers and tooling be aware that 
they may be directly using JDK internal APIs, perhaps unknowingly. We 
also include rudimentary tooling (jdeps) to help in the effort to 
understand dependencies. It may be that jdeps should be extended to also 
look at the @Exported annotation.


As I mention non-@Exported APIs then I don't think (and Joe can confirm) 
that there is any intention to add @Exported(false) to thousands of 
JDK-internal classes (and their package-info.java if it exists). Rather, 
if @Exported is not present then the default answer has to be that it is 
ambiguous and so not safe to depend on. Assuming I have this right then 
it means that @jdk.Exported (or whatever the final name is) will only be 
added to the small number of JDK-specific APIs that are long term 
stable/supported/documented APIs. This is consistent with the patches 
that have been discussed to date [1][2].


-Alan

[1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/011cf7e0a148
[2] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014691.html

hg: jdk8/tl/jdk: 8024508: Fix doclint issues in com.sun.nio.sctp

[chris . hegarty]

Changeset: 517c5e99fb2f
Author:chegar
Date:  2013-09-11 11:03 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/517c5e99fb2f

8024508: Fix doclint issues in com.sun.nio.sctp
Reviewed-by: alanb

! src/share/classes/com/sun/nio/sctp/Association.java
! src/share/classes/com/sun/nio/sctp/IllegalReceiveException.java
! src/share/classes/com/sun/nio/sctp/IllegalUnbindException.java
! src/share/classes/com/sun/nio/sctp/InvalidStreamException.java
! src/share/classes/com/sun/nio/sctp/MessageInfo.java
! src/share/classes/com/sun/nio/sctp/Notification.java
! src/share/classes/com/sun/nio/sctp/SctpChannel.java
! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java
! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java

Re: RFR: 8009411 : getMethods should not inherit static methods from interfaces

[Joel Borggren-Franck]

On 2013-09-09, Remi Forax wrote:
> On 09/09/2013 07:27 PM, Joel Borggrén-Franck wrote:
> >On 9 sep 2013, at 19:00, Joel Borggrén-Franck  wrote:
> >
> >>The issue is that since we added static methods to interfaces those have 
> >>erroneously been reflected in getMethods of implementing classes. This fix 
> >>filters out static interface methods from superinterfaces when adding 
> >>methods. I have also added a note to the javadoc for both getMembers and 
> >>getDeclaredMembers pointing this out (though it is implied from JLS).
> >Correcting myself, I added a note to getMethods() and getMethod(String name 
> >…)
> >
> >getDeclaredMethod{s} shouldn't need a note.
> >
> >cheers
> >/Joel
> 
> also Joel you can use for-each and avoid to load ma[i] twice
> (even if the JIT will certainly avoid the double load in this
> specific case).
> 
> void addAllNonStatic(Method[] methodArray) {
> for (Method method:methodArray) {
> if (!Modifier.isStatic(method.getModifiers())) {
> add(method);
> }
> }
> }
> 

I should use foreach if possible in any case, looks much cleaner.

cheres
/Joel

hg: jdk8/tl/jdk: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array types

[joel . franck]

Changeset: b271ea30f440
Author:jfranck
Date:  2013-09-11 09:45 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b271ea30f440

4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for 
array types
Summary: Update spec to match long standing behavior
Reviewed-by: darcy, mchung

! src/share/classes/java/lang/Class.java
+ test/java/lang/Class/ArrayMethods.java