From alexandr.scherbatiy at oracle.com  Tue Nov  5 11:16:21 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 05 Nov 2013 15:16:21 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5272C1AB.9030202@gmail.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
Message-ID: <5278D385.2000205@oracle.com>


    Thank you for the review.

   Could you look at the updated fix:
      http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/

   - URL is parsed to protocol, host, port, and path parts in the 
LWCToolkit class.
      I checked that URL(protocol, host, port, file) constructor 
correctly handles -1 port value.
   - Only last file name after last '/' in the URL path  is converted to 
@2x name
   - Tests that check correct URL and path translation to @2x names are 
added to the ScalableImageTest

   Thanks,
   Alexandr.


On 11/1/2013 12:46 AM, Peter Levart wrote:
>
> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>> 2. I'm not sure that the proposed getScaledImageName() 
>>> implementation in ScalableToolkitImage works perfectly for URLs like 
>>> this:
>>>
>>> http://www.exampmle.com/dir/image
>>>
>>> In this case it will try to find 2x image here:
>>>
>>> http://www.example at 2x.com/dir/image
>>>
>>> which doesn't look correct.
>>        Fixed. Only path part of a URL is converted to path2x. 
>
> Hi Alexander,
>
> URLs like this:
>
> http://www.example.com/dir.ext/image
>
> will still be translated to:
>
> http://www.example.com/dir at 2x.ext/image
>
>
> I think you need to search for last '.' after the last  '/' in the 
> getScaledImageName();
>
>
> Also the following code has some additional bugs:
>
>   853         static Image toScalableImage(Image image, URL url) {
>   854
>   855             if (url != null && !url.toString().contains("@2x")
>   856                     && !(image instanceof ScalableToolkitImage)) {
>   857                 String protocol = url.getProtocol();
>   858                 String host = url.getHost();
>   859                 String file = url.getPath();
>   860                 String file2x =*host +*getScaledImageName(file);
>   861                 try {
>   862                     URL url2x = new URL(protocol, host, file2x);
>   863                     url2x.openStream();
>   864                     return new ScalableToolkitImage(image, getDefaultToolkit().getImage(url2x));
>   865                 } catch (Exception ignore) {
>   866                 }
>   867             }
>   868             return image;
>   869         }
>
> Why are you prepending *host* to getScaledImageName(file) in line 860? 
> Let's take the following URL for example:
>
> http://www.example.com/dir/image.jpg
>
> protocol = "http"
> host = "www.example.com"
> file = "/dir/image.jpg"
> file2x = "*www.example.com*/dir/image at 2x.jpg"
> url2x = URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>
>
> You are missing a part in URL (de)construction - the optional port! 
> For example in the following URL:
>
> http://www.example.com:8080/dir/image.jpg
>
> You should extract the port from original URL and use it in new URL 
> construction if present (!= -1).
>
>
> I would also close the stream explicitly after probing for existence 
> of resource rather than delegating to GC which might not be promptly 
> and can cause resource exhaustion (think of MAX. # of open file 
> descriptors):
>
>         try (InputStream probe = url.openStream()) {}
>
>
>
> Regards, Peter
>
>



From james.graham at oracle.com  Tue Nov  5 17:14:39 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 05 Nov 2013 09:14:39 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for JDK-8025684 -
 Fix Raw and unchecked warnings java.awt.image classes
In-Reply-To: <5266DBFF.40005@oracle.com>
References: <524B43EF.4080603@oracle.com> <524BEF41.2000304@oracle.com>
	<524C9AA7.6010500@oracle.com> <525C5816.5010909@oracle.com>
	<525D178D.9030301@oracle.com> <5266DBFF.40005@oracle.com>
Message-ID: <5279277F.30003@oracle.com>

Unfortunately, I already exceeded my "generics pay grade" in the 
comments I gave before.  Is there a 2D reviewer with some better 
understanding of generics out there who can give a more informed approval?

FWIW, the non-properties changes are pretty straightforward and I can 
say that those are approved, but I don't understand the semantics of <?> 
and generics casting to vet the properties changes...

			...jim

On 10/22/13 1:11 PM, srikalyan chandrashekar wrote:
> Hi 2D folks any 2nd take on this for approval?
>
> ---
> Thanks
> kalyan
>
> On 10/15/2013 3:23 AM, Artem Ananiev wrote:
>>
>> On 10/15/2013 12:46 AM, srikalyan chandrashekar wrote:
>>> Hi Jim, Thanks for reviewing and apologies for the delayed response, I
>>> have made sure to set the properties type as String -> Object but mostly
>>> the public constructor(OR) setter method enforces <?, ?> where <Object,
>>> Object> being too loose is guaranteed to not break at runtime but
>>> <String, Object> is brittle and may break at runtime . But as you said
>>> if it is documented then having this hole should be OK.  I have updated
>>> the webrev and is available in same location
>>> <https://github.com/srikalyc/JDKfixes/blob/master/java.awt.image.raw_unchecked_webrev.zip>.
>>>
>>
>> The new version is uploaded here:
>>
>> http://cr.openjdk.java.net/~art/srikalyc/8025684.02/
>>
>> Thanks,
>>
>> Artem
>>
>>> --
>>> Thanks
>>> kalyan
>>>
>>> On 10/2/13 3:13 PM, Jim Graham wrote:
>>>> I'm not the greatest expert on generics (in particular, in terms of
>>>> issues of retrofitting generics into existing public code without
>>>> breaking compatibility), but I'll note that the properties on an image
>>>> were always "documented" to be String->Object, but that was well
>>>> before generics and so we just accepted bare hash tables everywhere.
>>>> Is it possible to have at least some of the declarations of various
>>>> properties objects to be declared as <String, Object> even though we
>>>> are loose on the acceptance criteria in various constructors - or
>>>> would that just completely break compatibility.  I know that we use
>>>> type erasure so we would never break binary compatibility, but there
>>>> may be some places where we can have them more strongly typed
>>>> internally for now, but more accepting at the external API level and
>>>> then possibly consider improving the externally-visible typing in
>>>> future versions when a source incompatibility is more appropriate?
>>>>
>>>> (I'm asking because I don't understand all of the compatibility issues
>>>> that this might cause...)
>>>>
>>>>              ...jim
>>>>
>>>> On 10/2/13 3:02 AM, Artem Ananiev wrote:
>>>>>
>>>>> java.awt.image is one of the Java2D packages, so I'm adding 2d-dev to
>>>>> CC. Please, wait for at least one approval from Java2D team.
>>>>>
>>>>> For easier review, I put the webrev here:
>>>>>
>>>>> http://cr.openjdk.java.net/~art/srikalyc/8025684.00/
>>>>>
>>>>> It looks fine to me. There is one "unchecked" warning still left, at
>>>>> BufferedImage.java:645, it can be fixed by introducing a local
>>>>> variable
>>>>> and @SuppressWarnings("unchecked"), but I'm not sure it's worth doing.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Artem
>>>>>
>>>>> On 10/2/2013 1:51 AM, srikalyan chandrashekar wrote:
>>>>>> Hi team ,  could someone review the fix
>>>>>>       Bug      : https://bugs.openjdk.java.net/browse/JDK-8025684
>>>>>>       Webrev   :
>>>>>> https://github.com/srikalyc/JDKfixes/blob/master/java.awt.image.raw_unchecked_webrev.zip
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>       Fix      : Raw and unchecked warnings in AWT image classes fixed
>>>>>>
>>>
>


From james.graham at oracle.com  Tue Nov  5 17:37:29 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 05 Nov 2013 09:37:29 -0800
Subject: [OpenJDK 2D-Dev] Request for review: Additional fix for
	JDK-7159455
In-Reply-To: <CAFvQSYSw0-8UrHBJYHZKSjuv-TnE2y_XrQBW=vegR3yx2n9uaw@mail.gmail.com>
References: <CAFvQSYTFmZacH1yt4r4PaX6u-uczt4rmWBu9n2Za0cO9X0hXPw@mail.gmail.com>
	<525F056E.2050104@oracle.com>
	<CAFvQSYT2e+FX-enfmxHJc=PpdVgBwcqcr0hpP+Fv1LF0vKQbrg@mail.gmail.com>
	<525F2D1A.80601@oracle.com>
	<CAFvQSYQxvW8iz5r94TgPjTmCBHN6NdJpj6aTDbpVjyK5sgGbzg@mail.gmail.com>
	<CAFvQSYSbe-ndHVh+jU0snRJzB56TNMA61NvcOHgJVUpJnu=7JQ@mail.gmail.com>
	<CAFvQSYSw0-8UrHBJYHZKSjuv-TnE2y_XrQBW=vegR3yx2n9uaw@mail.gmail.com>
Message-ID: <52792CD9.6030007@oracle.com>

Hi Clemens,

I sincerely apologize for not seeing this sooner, my email sorting is a 
little primitive, but I should check these alternate folders more often.

The one thing I am concerned about here is the rounding that is going on 
for scaled images.  You removed a comment about non-integer coordinates 
that I think is germane.  In particular, if a scale is animating and an 
image is rendered to 0,0=>10,10 and then 0,0=>10.25,10.25 then the 
pixels chosen will subtly change, but the code there rounds the 
coordinates to integers so you would see no change.  While the bounds of 
the result would be correct, the exact pixels chosen from the source 
image for each pixel in the destination would not be quite right.  Where 
can you communicate to the maskBuffer.compositeBlit() method that, while 
the coordinates given represent the bounds of interest, they aren't the 
exact definition of the precise scaling parameters in play?

			...jim

On 10/18/13 4:45 AM, Clemens Eisserer wrote:
> Another revision was required, available at:
> http://cr.openjdk.java.net/~ceisserer/fix12/webrev.04/
>
> When the destination-area is quadratic, no geometry is stored inside
> the mask and therefore the composition-window is used for clipping and
> it's size has to be rounded properly.
> In cases where it is not quadrant transformed, the code makes now sure
> no pixels are clipped away unintentionally.
>
> Thanks for your patience, Clemens
>


From linuxhippy at gmail.com  Tue Nov  5 21:24:43 2013
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Tue, 5 Nov 2013 16:24:43 -0500
Subject: [OpenJDK 2D-Dev] Request for review: Additional fix for
	JDK-7159455
In-Reply-To: <52792CD9.6030007@oracle.com>
References: <CAFvQSYTFmZacH1yt4r4PaX6u-uczt4rmWBu9n2Za0cO9X0hXPw@mail.gmail.com>
	<525F056E.2050104@oracle.com>
	<CAFvQSYT2e+FX-enfmxHJc=PpdVgBwcqcr0hpP+Fv1LF0vKQbrg@mail.gmail.com>
	<525F2D1A.80601@oracle.com>
	<CAFvQSYQxvW8iz5r94TgPjTmCBHN6NdJpj6aTDbpVjyK5sgGbzg@mail.gmail.com>
	<CAFvQSYSbe-ndHVh+jU0snRJzB56TNMA61NvcOHgJVUpJnu=7JQ@mail.gmail.com>
	<CAFvQSYSw0-8UrHBJYHZKSjuv-TnE2y_XrQBW=vegR3yx2n9uaw@mail.gmail.com>
	<52792CD9.6030007@oracle.com>
Message-ID: <CAFvQSYS0Mh-M-4QGNFb+-ecJvLoqr6+9eQjH1moB0ErZJE_NqA@mail.gmail.com>

Hi Jim,

> I sincerely apologize for not seeing this sooner, my email sorting is a little primitive,
> but I should check these alternate folders more often.
Never mind :)

> The one thing I am concerned about here is the rounding that is going on for
> scaled images.  You removed a comment about non-integer coordinates that I
> think is germane.  In particular, if a scale is animating and an image is
> rendered to 0,0=>10,10 and then 0,0=>10.25,10.25 then the pixels chosen will
> subtly change, but the code there rounds the coordinates to integers so you
> would see no change.  While the bounds of the result would be correct, the
> exact pixels chosen from the source image for each pixel in the destination
> would not be quite right.  Where can you communicate to the
> maskBuffer.compositeBlit() method that, while the coordinates given
> represent the bounds of interest, they aren't the exact definition of the
> precise scaling parameters in play?

The scaling parameters are stored as properties of the xrender source
surface and are set within the validateAsSource() method, while the
parameters passed to the compositeBlit()-function only specify the
size of the composition window.

Regards, Clemens


From james.graham at oracle.com  Wed Nov  6 01:23:08 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 05 Nov 2013 17:23:08 -0800
Subject: [OpenJDK 2D-Dev] Request for review: Additional fix for
	JDK-7159455
In-Reply-To: <CAFvQSYS0Mh-M-4QGNFb+-ecJvLoqr6+9eQjH1moB0ErZJE_NqA@mail.gmail.com>
References: <CAFvQSYTFmZacH1yt4r4PaX6u-uczt4rmWBu9n2Za0cO9X0hXPw@mail.gmail.com>
	<525F056E.2050104@oracle.com>
	<CAFvQSYT2e+FX-enfmxHJc=PpdVgBwcqcr0hpP+Fv1LF0vKQbrg@mail.gmail.com>
	<525F2D1A.80601@oracle.com>
	<CAFvQSYQxvW8iz5r94TgPjTmCBHN6NdJpj6aTDbpVjyK5sgGbzg@mail.gmail.com>
	<CAFvQSYSbe-ndHVh+jU0snRJzB56TNMA61NvcOHgJVUpJnu=7JQ@mail.gmail.com>
	<CAFvQSYSw0-8UrHBJYHZKSjuv-TnE2y_XrQBW=vegR3yx2n9uaw@mail.gmail.com>
	<52792CD9.6030007@oracle.com>
	<CAFvQSYS0Mh-M-4QGNFb+-ecJvLoqr6+9eQjH1moB0ErZJE_NqA@mail.gmail.com>
Message-ID: <527999FC.8090303@oracle.com>

Ah, I see.  And, I was about to rant about MT issues, but I see now that 
this is all inside an AWTLock.

I guess that also explains why the source coordinates were multiplied by 
the scale, though that seems a rather odd way to handle these issues.

A new question/issue - on line 314, what happens if the case is both 
quadrant rotated and extra-alpha'd?  Either of those will get us into 
that code block, but also both of them could be true at the same time in 
which case it looks like you forego the retreival of the EA mask...?

			...jim

On 11/5/13 1:24 PM, Clemens Eisserer wrote:
> Hi Jim,
>
>> I sincerely apologize for not seeing this sooner, my email sorting is a little primitive,
>> but I should check these alternate folders more often.
> Never mind :)
>
>> The one thing I am concerned about here is the rounding that is going on for
>> scaled images.  You removed a comment about non-integer coordinates that I
>> think is germane.  In particular, if a scale is animating and an image is
>> rendered to 0,0=>10,10 and then 0,0=>10.25,10.25 then the pixels chosen will
>> subtly change, but the code there rounds the coordinates to integers so you
>> would see no change.  While the bounds of the result would be correct, the
>> exact pixels chosen from the source image for each pixel in the destination
>> would not be quite right.  Where can you communicate to the
>> maskBuffer.compositeBlit() method that, while the coordinates given
>> represent the bounds of interest, they aren't the exact definition of the
>> precise scaling parameters in play?
>
> The scaling parameters are stored as properties of the xrender source
> surface and are set within the validateAsSource() method, while the
> parameters passed to the compositeBlit()-function only specify the
> size of the composition window.
>
> Regards, Clemens
>


From james.graham at oracle.com  Wed Nov  6 01:39:45 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 05 Nov 2013 17:39:45 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <52728302.406@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com>
Message-ID: <52799DE1.8080906@oracle.com>

Why is getScaledInstance() being consulted here?  It seems a misuse of 
that method.

The method was designed to return a rescaled version of the same pixels 
that you would get if you examined the raw pixels.  You are overriding 
it to return a different image.  That does not fit in with the original 
intent of that method as I created it.

It is also causing implementation headaches (read reflection) in the 
SG2D code to try to use it that way.

The @2x mechanism should be based on different API.  I guess it would 
have to be internal-only for 8.0 and could be exposed to allow 
developers to call it and possibly to be a provider for it in JDK9...

			...jim

On 10/31/13 9:19 AM, Alexander Scherbatiy wrote:
>
>   Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8011059/webrev.04/
>
>     The reflection is used to skip the Image.getScaledInstance() method
> call if it is not overridden by a user.
>
> On 10/29/2013 11:08 PM, Sergey Bylokhov wrote:
>> Hi, Alexander.
>> The fix looks fine to me in general. But there is at least one issue.
>> I build you fix and test it:
>>  - Consuming of cpu increased by 500 times Java2Demo on images tab.
>>  - FPS is dropped from 220(jdk8)/35(jdk7u40) to 15 in guimark2. Note
>> that jdk6 has the same FPS(15) on my system.
>
>     The main problem is that the Image.SCALE_DEFAULT hint is used to
> retrieve a scaled image from Image.getScaledInstance() method.
>     It always uses the ReplicateScaleFilter for images which
> getScaledInstance() method has not been overridden.
>     The ReplicateScaleFilter creates a lot of arrays and consumes the
> CPU during the image parsing.
>
>     The better fix would be to introduce the new Image.SCALE_CUSTOM hint
> which could be used to get a scaled image and does not use filters by
> default.
>     But it should be a separated bug with a new CCC request.
>
>    Thanks,
>    Alexandr.
>
>>
>> On 29.10.2013 20:45, Alexander Scherbatiy wrote:
>>>
>>>   Could you review the updated fix:
>>>     http://cr.openjdk.java.net/~alexsch/8011059/webrev.03
>>>
>>> On 10/28/2013 2:33 PM, Artem Ananiev wrote:
>>>> Hi, Alexander,
>>>>
>>>> a few comments:
>>>>
>>>> 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here?
>>>      The isHiDPIImage() method is used to check that the
>>> drawHiDPIImage should be called like:
>>>         if (isHiDPIImage(img)) {
>>>             return drawHiDPIImage(...);
>>>         }
>>>
>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>> implementation in ScalableToolkitImage works perfectly for URLs like
>>>> this:
>>>>
>>>>   http://www.exampmle.com/dir/image
>>>>
>>>> In this case it will try to find 2x image here:
>>>>
>>>>   http://www.example at 2x.com/dir/image
>>>>
>>>> which doesn't look correct.
>>>        Fixed. Only path part of a URL is converted to path2x.
>>>
>>>> 3. RenderingHints spec references Retina or non-Retina displays,
>>>> which should be removed.
>>>        Fixed.
>>>
>>>     - devScale is used instead of transform parsing in the
>>> drawHiDPIImage() method just to not have performance regression more
>>> than 2 times on HiDPI displays
>>>     - LWCToolkit.ScalableToolkitImage is made public for the fix
>>> 8024926 [macosx] AquaIcon HiDPI support.
>>>
>>>     Thanks,
>>>     Alexandr.
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>> On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>>    Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/
>>>>>
>>>>>    - Scaled image width and height are transformed according to the
>>>>> AffineTransform type.
>>>>>    - ToolkitImage subclass is used to hold @2x image instance.
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>>>> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>   Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/
>>>>>>
>>>>>>   The JCK failures has been resolved:
>>>>>>     - Some tests tries to draw an image with Integer.MAX_VALUE width
>>>>>> or height. Passing large values to image.getScaledImage(width,
>>>>>> height,
>>>>>> hints).
>>>>>>        leads that an Image filter is not able to create necessary
>>>>>> arrays.  The fix uses the original image if width or height are equal
>>>>>> to Integer.MAX_VALUE.
>>>>>>     - Using Image.SCALE_DEFAULT hint for the getScaledImage(width,
>>>>>> height, hints) method to get the high resolution image interferes
>>>>>> with
>>>>>>        JCK tests that expect that the scaled image by certain
>>>>>> algorithm is returned. This is fixed by invoking the
>>>>>> super.getScaledImage(width, height, hints)
>>>>>>        method in ToolkitImage in case if a high resolution image is
>>>>>> not set.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Alexandr.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review the fix:
>>>>>>>
>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8011059
>>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00
>>>>>>>
>>>>>>>   The IMAGE_SCALING rendering hint is added to the RenderingHints
>>>>>>> class.
>>>>>>>   Enabling the image scaling rendering hint forces the SunGraphics2D
>>>>>>> to use getScaledInstance(width, height, hints) method
>>>>>>>   from Image class with SCALE_DEFAULT hint.
>>>>>>>
>>>>>>>   By default the image scaling rendering hint is enabled on HiDPI
>>>>>>> display and disabled for standard displays.
>>>>>>>
>>>>>>>   User can override the getScaledInstance(width, height, hints)
>>>>>>> method and return necessary high resolution image
>>>>>>>   according to the given image width and height.
>>>>>>>
>>>>>>>   For example:
>>>>>>>   ---------------------
>>>>>>>         final Image highResolutionImage =
>>>>>>>                 new BufferedImage(2 * WIDTH, 2 * HEIGHT,
>>>>>>> BufferedImage.TYPE_INT_RGB);
>>>>>>>         Image image = new BufferedImage(WIDTH, HEIGHT,
>>>>>>> BufferedImage.TYPE_INT_RGB) {
>>>>>>>
>>>>>>>             @Override
>>>>>>>             public Image getScaledInstance(int width, int height,
>>>>>>> int
>>>>>>> hints) {
>>>>>>>                 if ((hints & Image.SCALE_DEFAULT) != 0) {
>>>>>>>                     return (width <= WIDTH && height <= HEIGHT)
>>>>>>>                             ? this : highResolutionImage;
>>>>>>>                 }
>>>>>>>                 return super.getScaledInstance(width, height,
>>>>>>> hints);
>>>>>>>             }
>>>>>>>         };
>>>>>>>   ---------------------
>>>>>>>
>>>>>>>   The LWCToolkit and ToolkitImage classes are patched to
>>>>>>> automatically get provided image at 2x.ext images on MacOSX.
>>>>>>>
>>>>>>>   There are no significant changes in the Java2D demo to make it
>>>>>>> look
>>>>>>> perfect on Retina displays.
>>>>>>>   It needs only to put necessary images with the @2x postfix and
>>>>>>> they
>>>>>>> will be automatically drawn.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>


From alexandr.scherbatiy at oracle.com  Wed Nov  6 13:19:29 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 06 Nov 2013 17:19:29 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <52799DE1.8080906@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
Message-ID: <527A41E1.9020103@oracle.com>

On 11/6/2013 5:39 AM, Jim Graham wrote:
> Why is getScaledInstance() being consulted here?  It seems a misuse of 
> that method.
     We need to introduce a new API that allows developers to return 
scaled images for HiDPI displays.
     Scaled images are just new images N times bigger than the original 
one and created by designers.

     The good way is to allow a user to override a method like 
getScaledImage() which has either scaledFactor or width and height 
parameters and returns necessary scaled images.
     It could look like:
    -----------------
         final Image image1 = ImageIO.read("image1.png");
         final Image image2 = ImageIO.read("image2.png");
         final Image image3 = ImageIO.read("image3.png");

         final int WIDTH = image1.getWidth(null);
         final int HEIGHT = image1.getHeight(null);

         Image image = new BufferedImage(WIDTH, HEIGHT, 
BufferedImage.TYPE_INT_RGB) {
             @Override
             public Image getScaledImage(int width, int height) {
                 if (width < WIDTH && height < HEIGHT) {
                     return this;
                 } else if (width < 2 * WIDTH && height < 2 * HEIGHT) {
                     return image2;
                 } else if (width < 3 * WIDTH && height < 3 * HEIGHT) {
                     return image3;
                 }
             }
         };

         image.getGraphics().drawImage(image1, 0, 0, null);
    -----------------

     But the  getScaledImage(width, height) method looks similar to the 
getScaledInstance(width, height, hints). It also can confuse a user 
which method should be overridden to return
     the scaled version of an image.

    The current fix is based on the CCC request 8011059 where it has 
been approved to use the getScaledInstance(width, height, hints) method 
for this purposes.

> The method was designed to return a rescaled version of the same 
> pixels that you would get if you examined the raw pixels.  You are 
> overriding it to return a different image.  That does not fit in with 
> the original intent of that method as I created it.
>
> It is also causing implementation headaches (read reflection) in the 
> SG2D code to try to use it that way.
      The Image.SCALE_DEFAULT hint is used to retrieve user scaled 
images in the CCC request 8011059.
      That was a wrong idea. There are intersections with the original 
meaning with the SCALE_DEFAULT hint.
      Also there are performance regression and exceptions like OOM or 
IOBE if the getScaledInstance(width, height, hints) is not overridden 
and it is invoked for each image.

      The better way could be to use a new Image hint designed only to 
retrieve scaled images provided by a user.
      I have created the CCC request 8027655 for this.
      Once the request will be approved it will be possible to get rid 
of the reflection usage.

    Thanks,
    Alexandr.

>
> The @2x mechanism should be based on different API.  I guess it would 
> have to be internal-only for 8.0 and could be exposed to allow 
> developers to call it and possibly to be a provider for it in JDK9...
>
>             ...jim
>
> On 10/31/13 9:19 AM, Alexander Scherbatiy wrote:
>>
>>   Could you review the updated fix:
>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.04/
>>
>>     The reflection is used to skip the Image.getScaledInstance() method
>> call if it is not overridden by a user.
>>
>> On 10/29/2013 11:08 PM, Sergey Bylokhov wrote:
>>> Hi, Alexander.
>>> The fix looks fine to me in general. But there is at least one issue.
>>> I build you fix and test it:
>>>  - Consuming of cpu increased by 500 times Java2Demo on images tab.
>>>  - FPS is dropped from 220(jdk8)/35(jdk7u40) to 15 in guimark2. Note
>>> that jdk6 has the same FPS(15) on my system.
>>
>>     The main problem is that the Image.SCALE_DEFAULT hint is used to
>> retrieve a scaled image from Image.getScaledInstance() method.
>>     It always uses the ReplicateScaleFilter for images which
>> getScaledInstance() method has not been overridden.
>>     The ReplicateScaleFilter creates a lot of arrays and consumes the
>> CPU during the image parsing.
>>
>>     The better fix would be to introduce the new Image.SCALE_CUSTOM hint
>> which could be used to get a scaled image and does not use filters by
>> default.
>>     But it should be a separated bug with a new CCC request.
>>
>>    Thanks,
>>    Alexandr.
>>
>>>
>>> On 29.10.2013 20:45, Alexander Scherbatiy wrote:
>>>>
>>>>   Could you review the updated fix:
>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.03
>>>>
>>>> On 10/28/2013 2:33 PM, Artem Ananiev wrote:
>>>>> Hi, Alexander,
>>>>>
>>>>> a few comments:
>>>>>
>>>>> 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here?
>>>>      The isHiDPIImage() method is used to check that the
>>>> drawHiDPIImage should be called like:
>>>>         if (isHiDPIImage(img)) {
>>>>             return drawHiDPIImage(...);
>>>>         }
>>>>
>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>> implementation in ScalableToolkitImage works perfectly for URLs like
>>>>> this:
>>>>>
>>>>> http://www.exampmle.com/dir/image
>>>>>
>>>>> In this case it will try to find 2x image here:
>>>>>
>>>>> http://www.example at 2x.com/dir/image
>>>>>
>>>>> which doesn't look correct.
>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>
>>>>> 3. RenderingHints spec references Retina or non-Retina displays,
>>>>> which should be removed.
>>>>        Fixed.
>>>>
>>>>     - devScale is used instead of transform parsing in the
>>>> drawHiDPIImage() method just to not have performance regression more
>>>> than 2 times on HiDPI displays
>>>>     - LWCToolkit.ScalableToolkitImage is made public for the fix
>>>> 8024926 [macosx] AquaIcon HiDPI support.
>>>>
>>>>     Thanks,
>>>>     Alexandr.
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Artem
>>>>>
>>>>> On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>    Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/
>>>>>>
>>>>>>    - Scaled image width and height are transformed according to the
>>>>>> AffineTransform type.
>>>>>>    - ToolkitImage subclass is used to hold @2x image instance.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>
>>>>>> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>   Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/
>>>>>>>
>>>>>>>   The JCK failures has been resolved:
>>>>>>>     - Some tests tries to draw an image with Integer.MAX_VALUE 
>>>>>>> width
>>>>>>> or height. Passing large values to image.getScaledImage(width,
>>>>>>> height,
>>>>>>> hints).
>>>>>>>        leads that an Image filter is not able to create necessary
>>>>>>> arrays.  The fix uses the original image if width or height are 
>>>>>>> equal
>>>>>>> to Integer.MAX_VALUE.
>>>>>>>     - Using Image.SCALE_DEFAULT hint for the getScaledImage(width,
>>>>>>> height, hints) method to get the high resolution image interferes
>>>>>>> with
>>>>>>>        JCK tests that expect that the scaled image by certain
>>>>>>> algorithm is returned. This is fixed by invoking the
>>>>>>> super.getScaledImage(width, height, hints)
>>>>>>>        method in ToolkitImage in case if a high resolution image is
>>>>>>> not set.
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>     Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Could you review the fix:
>>>>>>>>
>>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8011059
>>>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00
>>>>>>>>
>>>>>>>>   The IMAGE_SCALING rendering hint is added to the RenderingHints
>>>>>>>> class.
>>>>>>>>   Enabling the image scaling rendering hint forces the 
>>>>>>>> SunGraphics2D
>>>>>>>> to use getScaledInstance(width, height, hints) method
>>>>>>>>   from Image class with SCALE_DEFAULT hint.
>>>>>>>>
>>>>>>>>   By default the image scaling rendering hint is enabled on HiDPI
>>>>>>>> display and disabled for standard displays.
>>>>>>>>
>>>>>>>>   User can override the getScaledInstance(width, height, hints)
>>>>>>>> method and return necessary high resolution image
>>>>>>>>   according to the given image width and height.
>>>>>>>>
>>>>>>>>   For example:
>>>>>>>>   ---------------------
>>>>>>>>         final Image highResolutionImage =
>>>>>>>>                 new BufferedImage(2 * WIDTH, 2 * HEIGHT,
>>>>>>>> BufferedImage.TYPE_INT_RGB);
>>>>>>>>         Image image = new BufferedImage(WIDTH, HEIGHT,
>>>>>>>> BufferedImage.TYPE_INT_RGB) {
>>>>>>>>
>>>>>>>>             @Override
>>>>>>>>             public Image getScaledInstance(int width, int height,
>>>>>>>> int
>>>>>>>> hints) {
>>>>>>>>                 if ((hints & Image.SCALE_DEFAULT) != 0) {
>>>>>>>>                     return (width <= WIDTH && height <= HEIGHT)
>>>>>>>>                             ? this : highResolutionImage;
>>>>>>>>                 }
>>>>>>>>                 return super.getScaledInstance(width, height,
>>>>>>>> hints);
>>>>>>>>             }
>>>>>>>>         };
>>>>>>>>   ---------------------
>>>>>>>>
>>>>>>>>   The LWCToolkit and ToolkitImage classes are patched to
>>>>>>>> automatically get provided image at 2x.ext images on MacOSX.
>>>>>>>>
>>>>>>>>   There are no significant changes in the Java2D demo to make it
>>>>>>>> look
>>>>>>>> perfect on Retina displays.
>>>>>>>>   It needs only to put necessary images with the @2x postfix and
>>>>>>>> they
>>>>>>>> will be automatically drawn.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>



From linuxhippy at gmail.com  Wed Nov  6 17:38:44 2013
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 6 Nov 2013 18:38:44 +0100
Subject: [OpenJDK 2D-Dev] Request for review: Additional fix for
	JDK-7159455
In-Reply-To: <527999FC.8090303@oracle.com>
References: <CAFvQSYTFmZacH1yt4r4PaX6u-uczt4rmWBu9n2Za0cO9X0hXPw@mail.gmail.com>
	<525F056E.2050104@oracle.com>
	<CAFvQSYT2e+FX-enfmxHJc=PpdVgBwcqcr0hpP+Fv1LF0vKQbrg@mail.gmail.com>
	<525F2D1A.80601@oracle.com>
	<CAFvQSYQxvW8iz5r94TgPjTmCBHN6NdJpj6aTDbpVjyK5sgGbzg@mail.gmail.com>
	<CAFvQSYSbe-ndHVh+jU0snRJzB56TNMA61NvcOHgJVUpJnu=7JQ@mail.gmail.com>
	<CAFvQSYSw0-8UrHBJYHZKSjuv-TnE2y_XrQBW=vegR3yx2n9uaw@mail.gmail.com>
	<52792CD9.6030007@oracle.com>
	<CAFvQSYS0Mh-M-4QGNFb+-ecJvLoqr6+9eQjH1moB0ErZJE_NqA@mail.gmail.com>
	<527999FC.8090303@oracle.com>
Message-ID: <CAFvQSYRTu2y56fUP_Dxgi74tLrQ7o1JxTgvETdvkafR-Qcmdgg@mail.gmail.com>

Hi Jim,

Thanks for taking the time to review this in-depth.

> I guess that also explains why the source coordinates were multiplied by the
> scale, though that seems a rather odd way to handle these issues.

Indeed, the offsets could be also stored as part of the transformation
(as it is done for TransformBlit), which would be more elegant.


> A new question/issue - on line 314, what happens if the case is both
> quadrant rotated and extra-alpha'd?  Either of those will get us into that
> code block, but also both of them could be true at the same time in which
> case it looks like you forego the retreival of the EA mask...?

In this case a 1x1 mask with EA prepared in advance by
XRCompositionManager will be used, returned by
xrMgr.getExtraAlphaMask().

However, thinking about it again, it seems to me the code could be
simplified a bit more.
As soon as a TransformBlit is quadrant rotated, the else-branch (line
321) can handle all cases even with extra-alpha (compositeBlit handles
EA in a generic way) - which would make the conditional at line 314
redundant.
However, I tended to versimplify this part, so maybe this is something
for JDK9 ;)

- Clemens


From james.graham at oracle.com  Wed Nov  6 21:40:19 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 06 Nov 2013 13:40:19 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527A41E1.9020103@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com>
Message-ID: <527AB743.8050106@oracle.com>



On 11/6/13 5:19 AM, Alexander Scherbatiy wrote:
> On 11/6/2013 5:39 AM, Jim Graham wrote:
>> Why is getScaledInstance() being consulted here?  It seems a misuse of
>> that method.
>      We need to introduce a new API that allows developers to return
> scaled images for HiDPI displays.

Then we should introduce new API.

>      Scaled images are just new images N times bigger than the original
> one and created by designers.

No, they are different images for the same content that are designed to 
have more or less detail for a given resolution from the start.

>      The good way is to allow a user to override a method like
> getScaledImage() which has either scaledFactor or width and height
> parameters and returns necessary scaled images.

If that is a new API with new semantics, then I agree.

>      But the  getScaledImage(width, height) method looks similar to the
> getScaledInstance(width, height, hints). It also can confuse a user
> which method should be overridden to return
>      the scaled version of an image.

A better name would help.  I don't think width/height are really the 
best parameters for such a method since you want an image that can be 
substituted and the original image has already established an aspect 
ratio.  A single resolution would have been preferable.

>     The current fix is based on the CCC request 8011059 where it has
> been approved to use the getScaledInstance(width, height, hints) method
> for this purposes.

Note that in addition to the issues I raise wherein that method was 
never intended to support this new behavior, and the fact that a hint on 
G2D would cause that method on *all* images to be executed whether or 
not that image is one of the images that a developer needed the 
resolution support, this method also suffers from having a set of 
arguments that are poorly applicable to this operation.  The fact that 
the API request had to mention which type of pixel replication algorithm 
would be used to mean "we really actually don't want pixel replication 
in the first place" is a pretty good indicator that this API is not up 
to the task.

>> The method was designed to return a rescaled version of the same
>> pixels that you would get if you examined the raw pixels.  You are
>> overriding it to return a different image.  That does not fit in with
>> the original intent of that method as I created it.
>>
>> It is also causing implementation headaches (read reflection) in the
>> SG2D code to try to use it that way.
>       The Image.SCALE_DEFAULT hint is used to retrieve user scaled
> images in the CCC request 8011059.
>       That was a wrong idea. There are intersections with the original
> meaning with the SCALE_DEFAULT hint.

There should be no scaling hints in the first place for an alternate 
resolution source.

>       Also there are performance regression and exceptions like OOM or
> IOBE if the getScaledInstance(width, height, hints) is not overridden
> and it is invoked for each image.

And there are 10 years of potential overrides that developers could have 
created that could be even worse than the default implementation from a 
performance perspective.  "Whether or not the method is overridden" is a 
bad heuristic from the get go and it is much, much more inappropriate to 
apply to a legacy method that has been in the wild for over a decade.

>       The better way could be to use a new Image hint designed only to
> retrieve scaled images provided by a user.
>       I have created the CCC request 8027655 for this.
>       Once the request will be approved it will be possible to get rid
> of the reflection usage.

The suggestion to add a new hint to a decade old API is unwise. 
Additionally, the hint requested "SCALE_CUSTOM" could mean anything and 
is documented so loosely that resolution swapping is only one of an 
infinite number of responses an application could make.  The spec of 
that hint also violates the contract of the getScaledInstance() method 
which states that the returned instance will be of the requested size, 
but you are planning on returning an image that can have a different size.

Allowing developers to return a substitute image for a different screen 
resolution is a good goal, but none of these API hacks are really suited 
to the task and they are attempting to leverage a very dated legacy API 
for a purpose that it was expressly designed not to do in the first place...

			...jim

>> The @2x mechanism should be based on different API.  I guess it would
>> have to be internal-only for 8.0 and could be exposed to allow
>> developers to call it and possibly to be a provider for it in JDK9...
>>
>>             ...jim
>>
>> On 10/31/13 9:19 AM, Alexander Scherbatiy wrote:
>>>
>>>   Could you review the updated fix:
>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.04/
>>>
>>>     The reflection is used to skip the Image.getScaledInstance() method
>>> call if it is not overridden by a user.
>>>
>>> On 10/29/2013 11:08 PM, Sergey Bylokhov wrote:
>>>> Hi, Alexander.
>>>> The fix looks fine to me in general. But there is at least one issue.
>>>> I build you fix and test it:
>>>>  - Consuming of cpu increased by 500 times Java2Demo on images tab.
>>>>  - FPS is dropped from 220(jdk8)/35(jdk7u40) to 15 in guimark2. Note
>>>> that jdk6 has the same FPS(15) on my system.
>>>
>>>     The main problem is that the Image.SCALE_DEFAULT hint is used to
>>> retrieve a scaled image from Image.getScaledInstance() method.
>>>     It always uses the ReplicateScaleFilter for images which
>>> getScaledInstance() method has not been overridden.
>>>     The ReplicateScaleFilter creates a lot of arrays and consumes the
>>> CPU during the image parsing.
>>>
>>>     The better fix would be to introduce the new Image.SCALE_CUSTOM hint
>>> which could be used to get a scaled image and does not use filters by
>>> default.
>>>     But it should be a separated bug with a new CCC request.
>>>
>>>    Thanks,
>>>    Alexandr.
>>>
>>>>
>>>> On 29.10.2013 20:45, Alexander Scherbatiy wrote:
>>>>>
>>>>>   Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.03
>>>>>
>>>>> On 10/28/2013 2:33 PM, Artem Ananiev wrote:
>>>>>> Hi, Alexander,
>>>>>>
>>>>>> a few comments:
>>>>>>
>>>>>> 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here?
>>>>>      The isHiDPIImage() method is used to check that the
>>>>> drawHiDPIImage should be called like:
>>>>>         if (isHiDPIImage(img)) {
>>>>>             return drawHiDPIImage(...);
>>>>>         }
>>>>>
>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>> implementation in ScalableToolkitImage works perfectly for URLs like
>>>>>> this:
>>>>>>
>>>>>> http://www.exampmle.com/dir/image
>>>>>>
>>>>>> In this case it will try to find 2x image here:
>>>>>>
>>>>>> http://www.example at 2x.com/dir/image
>>>>>>
>>>>>> which doesn't look correct.
>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>>
>>>>>> 3. RenderingHints spec references Retina or non-Retina displays,
>>>>>> which should be removed.
>>>>>        Fixed.
>>>>>
>>>>>     - devScale is used instead of transform parsing in the
>>>>> drawHiDPIImage() method just to not have performance regression more
>>>>> than 2 times on HiDPI displays
>>>>>     - LWCToolkit.ScalableToolkitImage is made public for the fix
>>>>> 8024926 [macosx] AquaIcon HiDPI support.
>>>>>
>>>>>     Thanks,
>>>>>     Alexandr.
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>> On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>    Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/
>>>>>>>
>>>>>>>    - Scaled image width and height are transformed according to the
>>>>>>> AffineTransform type.
>>>>>>>    - ToolkitImage subclass is used to hold @2x image instance.
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>   Alexandr.
>>>>>>>
>>>>>>> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>>   Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/
>>>>>>>>
>>>>>>>>   The JCK failures has been resolved:
>>>>>>>>     - Some tests tries to draw an image with Integer.MAX_VALUE
>>>>>>>> width
>>>>>>>> or height. Passing large values to image.getScaledImage(width,
>>>>>>>> height,
>>>>>>>> hints).
>>>>>>>>        leads that an Image filter is not able to create necessary
>>>>>>>> arrays.  The fix uses the original image if width or height are
>>>>>>>> equal
>>>>>>>> to Integer.MAX_VALUE.
>>>>>>>>     - Using Image.SCALE_DEFAULT hint for the getScaledImage(width,
>>>>>>>> height, hints) method to get the high resolution image interferes
>>>>>>>> with
>>>>>>>>        JCK tests that expect that the scaled image by certain
>>>>>>>> algorithm is returned. This is fixed by invoking the
>>>>>>>> super.getScaledImage(width, height, hints)
>>>>>>>>        method in ToolkitImage in case if a high resolution image is
>>>>>>>> not set.
>>>>>>>>
>>>>>>>>     Thanks,
>>>>>>>>     Alexandr.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Could you review the fix:
>>>>>>>>>
>>>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8011059
>>>>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00
>>>>>>>>>
>>>>>>>>>   The IMAGE_SCALING rendering hint is added to the RenderingHints
>>>>>>>>> class.
>>>>>>>>>   Enabling the image scaling rendering hint forces the
>>>>>>>>> SunGraphics2D
>>>>>>>>> to use getScaledInstance(width, height, hints) method
>>>>>>>>>   from Image class with SCALE_DEFAULT hint.
>>>>>>>>>
>>>>>>>>>   By default the image scaling rendering hint is enabled on HiDPI
>>>>>>>>> display and disabled for standard displays.
>>>>>>>>>
>>>>>>>>>   User can override the getScaledInstance(width, height, hints)
>>>>>>>>> method and return necessary high resolution image
>>>>>>>>>   according to the given image width and height.
>>>>>>>>>
>>>>>>>>>   For example:
>>>>>>>>>   ---------------------
>>>>>>>>>         final Image highResolutionImage =
>>>>>>>>>                 new BufferedImage(2 * WIDTH, 2 * HEIGHT,
>>>>>>>>> BufferedImage.TYPE_INT_RGB);
>>>>>>>>>         Image image = new BufferedImage(WIDTH, HEIGHT,
>>>>>>>>> BufferedImage.TYPE_INT_RGB) {
>>>>>>>>>
>>>>>>>>>             @Override
>>>>>>>>>             public Image getScaledInstance(int width, int height,
>>>>>>>>> int
>>>>>>>>> hints) {
>>>>>>>>>                 if ((hints & Image.SCALE_DEFAULT) != 0) {
>>>>>>>>>                     return (width <= WIDTH && height <= HEIGHT)
>>>>>>>>>                             ? this : highResolutionImage;
>>>>>>>>>                 }
>>>>>>>>>                 return super.getScaledInstance(width, height,
>>>>>>>>> hints);
>>>>>>>>>             }
>>>>>>>>>         };
>>>>>>>>>   ---------------------
>>>>>>>>>
>>>>>>>>>   The LWCToolkit and ToolkitImage classes are patched to
>>>>>>>>> automatically get provided image at 2x.ext images on MacOSX.
>>>>>>>>>
>>>>>>>>>   There are no significant changes in the Java2D demo to make it
>>>>>>>>> look
>>>>>>>>> perfect on Retina displays.
>>>>>>>>>   It needs only to put necessary images with the @2x postfix and
>>>>>>>>> they
>>>>>>>>> will be automatically drawn.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexandr.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>
>


From james.graham at oracle.com  Wed Nov  6 21:44:52 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 06 Nov 2013 13:44:52 -0800
Subject: [OpenJDK 2D-Dev] Request for review: Additional fix for
	JDK-7159455
In-Reply-To: <CAFvQSYRTu2y56fUP_Dxgi74tLrQ7o1JxTgvETdvkafR-Qcmdgg@mail.gmail.com>
References: <CAFvQSYTFmZacH1yt4r4PaX6u-uczt4rmWBu9n2Za0cO9X0hXPw@mail.gmail.com>
	<525F056E.2050104@oracle.com>
	<CAFvQSYT2e+FX-enfmxHJc=PpdVgBwcqcr0hpP+Fv1LF0vKQbrg@mail.gmail.com>
	<525F2D1A.80601@oracle.com>
	<CAFvQSYQxvW8iz5r94TgPjTmCBHN6NdJpj6aTDbpVjyK5sgGbzg@mail.gmail.com>
	<CAFvQSYSbe-ndHVh+jU0snRJzB56TNMA61NvcOHgJVUpJnu=7JQ@mail.gmail.com>
	<CAFvQSYSw0-8UrHBJYHZKSjuv-TnE2y_XrQBW=vegR3yx2n9uaw@mail.gmail.com>
	<52792CD9.6030007@oracle.com>
	<CAFvQSYS0Mh-M-4QGNFb+-ecJvLoqr6+9eQjH1moB0ErZJE_NqA@mail.gmail.com>
	<527999FC.8090303@oracle.com>
	<CAFvQSYRTu2y56fUP_Dxgi74tLrQ7o1JxTgvETdvkafR-Qcmdgg@mail.gmail.com>
Message-ID: <527AB854.4080108@oracle.com>

Hi Clemens,

On 11/6/13 9:38 AM, Clemens Eisserer wrote:
>> A new question/issue - on line 314, what happens if the case is both
>> quadrant rotated and extra-alpha'd?  Either of those will get us into that
>> code block, but also both of them could be true at the same time in which
>> case it looks like you forego the retreival of the EA mask...?
>
> In this case a 1x1 mask with EA prepared in advance by
> XRCompositionManager will be used, returned by
> xrMgr.getExtraAlphaMask().

I think I had that backwards.  I was referring to the other case which 
does not call xrMgr.getExtraAlphaMask():

  312                 // For quadrant-transformed blits geometry is not 
stored inside the mask
  313                 // therefore we can use a repeating 1x1 mask for 
applying extra alpha.
  314                 int maskPicture = isQuadrantRotated ? 
xrMgr.getExtraAlphaMask()
  315                         : mask.prepareBlitMask(x11sdDst, maskTX, 
width, height);

In the "mask.prepareBlitMask" case I don't see where extra alpha is 
processed, but perhaps I am missing something and it is already 
registered in some data structure somewhere?

			...jim


From linuxhippy at gmail.com  Wed Nov  6 21:51:51 2013
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 6 Nov 2013 16:51:51 -0500
Subject: [OpenJDK 2D-Dev] Request for review: Additional fix for
	JDK-7159455
In-Reply-To: <527AB854.4080108@oracle.com>
References: <CAFvQSYTFmZacH1yt4r4PaX6u-uczt4rmWBu9n2Za0cO9X0hXPw@mail.gmail.com>
	<525F056E.2050104@oracle.com>
	<CAFvQSYT2e+FX-enfmxHJc=PpdVgBwcqcr0hpP+Fv1LF0vKQbrg@mail.gmail.com>
	<525F2D1A.80601@oracle.com>
	<CAFvQSYQxvW8iz5r94TgPjTmCBHN6NdJpj6aTDbpVjyK5sgGbzg@mail.gmail.com>
	<CAFvQSYSbe-ndHVh+jU0snRJzB56TNMA61NvcOHgJVUpJnu=7JQ@mail.gmail.com>
	<CAFvQSYSw0-8UrHBJYHZKSjuv-TnE2y_XrQBW=vegR3yx2n9uaw@mail.gmail.com>
	<52792CD9.6030007@oracle.com>
	<CAFvQSYS0Mh-M-4QGNFb+-ecJvLoqr6+9eQjH1moB0ErZJE_NqA@mail.gmail.com>
	<527999FC.8090303@oracle.com>
	<CAFvQSYRTu2y56fUP_Dxgi74tLrQ7o1JxTgvETdvkafR-Qcmdgg@mail.gmail.com>
	<527AB854.4080108@oracle.com>
Message-ID: <CAFvQSYQkWKVc8VBD4QoxnZxTK8=k2JPGgLpBLzqqTeOf8My0Ag@mail.gmail.com>

> I think I had that backwards.  I was referring to the other case which does
> not call xrMgr.getExtraAlphaMask():
>
>  312                 // For quadrant-transformed blits geometry is not
> stored inside the mask
>  313                 // therefore we can use a repeating 1x1 mask for
> applying extra alpha.
>  314                 int maskPicture = isQuadrantRotated ?
> xrMgr.getExtraAlphaMask()
>  315                         : mask.prepareBlitMask(x11sdDst, maskTX, width,
> height);
>
> In the "mask.prepareBlitMask" case I don't see where extra alpha is
> processed, but perhaps I am missing something and it is already registered
> in some data structure somewhere?

Yes, prepareBlitMask handles EA too - the XRMaskImage instance of
actually fetched from XRCompositeManager, which was designed to
encapsulate EA handling.
I hope to get especially this piece of code into more consistent state
with JDK9, as there is no real need to handle EA explicitly inside the
Blits.

Thanks, Clemens


From Sergey.Bylokhov at oracle.com  Wed Nov  6 23:09:54 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 07 Nov 2013 03:09:54 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527AB743.8050106@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>
	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>
	<527AB743.8050106@oracle.com>
Message-ID: <527ACC42.6060001@oracle.com>

Hi , Jim.
On 07.11.2013 1:40, Jim Graham wrote:
> On 11/6/13 5:19 AM, Alexander Scherbatiy wrote:
>> On 11/6/2013 5:39 AM, Jim Graham wrote:
>>> Why is getScaledInstance() being consulted here?  It seems a misuse of
>>> that method.
>>      We need to introduce a new API that allows developers to return
>> scaled images for HiDPI displays.
>
> Then we should introduce new API.
Well during draw of the image we should request appropriate scale image 
from the user, who possible know better how its image can be scaled.
What can be better, than a method which "Creates a scaled version of 
this image."?
>>      The good way is to allow a user to override a method like
>> getScaledImage() which has either scaledFactor or width and height
>> parameters and returns necessary scaled images.
>
> If that is a new API with new semantics, then I agree.
>
>>      But the  getScaledImage(width, height) method looks similar to the
>> getScaledInstance(width, height, hints). It also can confuse a user
>> which method should be overridden to return
>>      the scaled version of an image.
>
> A better name would help.  I don't think width/height are really the 
> best parameters for such a method since you want an image that can be 
> substituted and the original image has already established an aspect 
> ratio.  A single resolution would have been preferable.
But it can be used independently, if the graphics is scaled in one 
direction. And to allow the user to decide how to scale the picture 
depending on how it will be expanded. And there is no direct 
relationship with retina and its scale factor.

We can move deeper and request here the actual size of the image 
including transform of the graphics (<=TRANSFORM_TRANSLATESCALE). So the 
user can apply IMAGE_SCALING hint to the transformed sg2d and all images 
will have a chance to use custom scale instead of  some scaling from the 
sg2d.
>
> And there are 10 years of potential overrides that developers could 
> have created that could be even worse than the default implementation 
> from a performance perspective.  "Whether or not the method is 
> overridden" is a bad heuristic from the get go and it is much, much 
> more inappropriate to apply to a legacy method that has been in the 
> wild for over a decade. 
If user overrides this method and provides some specific scale algorithm 
is not what we want from the beginning?
"Whether or not the method is overridden" come in to play because 
default scale operation in SG2D and the results of default 
implementation of getScaledInstance is quite similar, but performance is 
extremely different.
So it can be rephrased as "Whether or not the default scale algorithm is 
use", so in the fix we use default from the S2G2 not Image.
>
> The suggestion to add a new hint to a decade old API is unwise. 
> Additionally, the hint requested "SCALE_CUSTOM" could mean anything 
> and is documented so loosely that resolution swapping is only one of 
> an infinite number of responses an application could make.  The spec 
> of that hint also violates the contract of the getScaledInstance() 
> method which states that the returned instance will be of the 
> requested size, but you are planning on returning an image that can 
> have a different size.
It return the image which is rendered to appropriate width and height by 
default. It is not necessary to be always the same sized image. Moreover 
it can be a different size image in case of negative width/height.
This hint will be enabled on the retina device by default, but can be 
enabled by the user as well for any graphics

In general an idea of the fix is: The image know better how it could be 
scaled
  - It could use some pixel replicate scale filters
  - it could use different files images
  - it could redraw itself from scratch if it use vectors graphics.
The only parameters it needed is width and height.

The CUSTOM hint is used for two reasons
  - to use default scale from graphics and to skip default in image
  - to explicitly document new usage of getScaledInstance().

And additionally about compatibility you can compare this version of the 
fix and version of jdk7(where demos was rewritten). If I understand it 
correctly nothing should be changed in demos in the current version of 
the fix(except new x2 images.)
http://closedjdk.us.oracle.com/jdk7u/jdk7u-dev/jdk/src/closed/rev/335cba03699d

>
>
>             ...jim
>
>>> The @2x mechanism should be based on different API.  I guess it would
>>> have to be internal-only for 8.0 and could be exposed to allow
>>> developers to call it and possibly to be a provider for it in JDK9...
>>>
>>>             ...jim
>>>
>>> On 10/31/13 9:19 AM, Alexander Scherbatiy wrote:
>>>>
>>>>   Could you review the updated fix:
>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.04/
>>>>
>>>>     The reflection is used to skip the Image.getScaledInstance() 
>>>> method
>>>> call if it is not overridden by a user.
>>>>
>>>> On 10/29/2013 11:08 PM, Sergey Bylokhov wrote:
>>>>> Hi, Alexander.
>>>>> The fix looks fine to me in general. But there is at least one issue.
>>>>> I build you fix and test it:
>>>>>  - Consuming of cpu increased by 500 times Java2Demo on images tab.
>>>>>  - FPS is dropped from 220(jdk8)/35(jdk7u40) to 15 in guimark2. Note
>>>>> that jdk6 has the same FPS(15) on my system.
>>>>
>>>>     The main problem is that the Image.SCALE_DEFAULT hint is used to
>>>> retrieve a scaled image from Image.getScaledInstance() method.
>>>>     It always uses the ReplicateScaleFilter for images which
>>>> getScaledInstance() method has not been overridden.
>>>>     The ReplicateScaleFilter creates a lot of arrays and consumes the
>>>> CPU during the image parsing.
>>>>
>>>>     The better fix would be to introduce the new Image.SCALE_CUSTOM 
>>>> hint
>>>> which could be used to get a scaled image and does not use filters by
>>>> default.
>>>>     But it should be a separated bug with a new CCC request.
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>
>>>>>
>>>>> On 29.10.2013 20:45, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>   Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.03
>>>>>>
>>>>>> On 10/28/2013 2:33 PM, Artem Ananiev wrote:
>>>>>>> Hi, Alexander,
>>>>>>>
>>>>>>> a few comments:
>>>>>>>
>>>>>>> 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here?
>>>>>>      The isHiDPIImage() method is used to check that the
>>>>>> drawHiDPIImage should be called like:
>>>>>>         if (isHiDPIImage(img)) {
>>>>>>             return drawHiDPIImage(...);
>>>>>>         }
>>>>>>
>>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>>> implementation in ScalableToolkitImage works perfectly for URLs 
>>>>>>> like
>>>>>>> this:
>>>>>>>
>>>>>>> http://www.exampmle.com/dir/image
>>>>>>>
>>>>>>> In this case it will try to find 2x image here:
>>>>>>>
>>>>>>> http://www.example at 2x.com/dir/image
>>>>>>>
>>>>>>> which doesn't look correct.
>>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>>>
>>>>>>> 3. RenderingHints spec references Retina or non-Retina displays,
>>>>>>> which should be removed.
>>>>>>        Fixed.
>>>>>>
>>>>>>     - devScale is used instead of transform parsing in the
>>>>>> drawHiDPIImage() method just to not have performance regression more
>>>>>> than 2 times on HiDPI displays
>>>>>>     - LWCToolkit.ScalableToolkitImage is made public for the fix
>>>>>> 8024926 [macosx] AquaIcon HiDPI support.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Alexandr.
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Artem
>>>>>>>
>>>>>>> On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>>    Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/
>>>>>>>>
>>>>>>>>    - Scaled image width and height are transformed according to 
>>>>>>>> the
>>>>>>>> AffineTransform type.
>>>>>>>>    - ToolkitImage subclass is used to hold @2x image instance.
>>>>>>>>
>>>>>>>>   Thanks,
>>>>>>>>   Alexandr.
>>>>>>>>
>>>>>>>> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>>   Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/
>>>>>>>>>
>>>>>>>>>   The JCK failures has been resolved:
>>>>>>>>>     - Some tests tries to draw an image with Integer.MAX_VALUE
>>>>>>>>> width
>>>>>>>>> or height. Passing large values to image.getScaledImage(width,
>>>>>>>>> height,
>>>>>>>>> hints).
>>>>>>>>>        leads that an Image filter is not able to create necessary
>>>>>>>>> arrays.  The fix uses the original image if width or height are
>>>>>>>>> equal
>>>>>>>>> to Integer.MAX_VALUE.
>>>>>>>>>     - Using Image.SCALE_DEFAULT hint for the 
>>>>>>>>> getScaledImage(width,
>>>>>>>>> height, hints) method to get the high resolution image interferes
>>>>>>>>> with
>>>>>>>>>        JCK tests that expect that the scaled image by certain
>>>>>>>>> algorithm is returned. This is fixed by invoking the
>>>>>>>>> super.getScaledImage(width, height, hints)
>>>>>>>>>        method in ToolkitImage in case if a high resolution 
>>>>>>>>> image is
>>>>>>>>> not set.
>>>>>>>>>
>>>>>>>>>     Thanks,
>>>>>>>>>     Alexandr.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Could you review the fix:
>>>>>>>>>>
>>>>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8011059
>>>>>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00
>>>>>>>>>>
>>>>>>>>>>   The IMAGE_SCALING rendering hint is added to the 
>>>>>>>>>> RenderingHints
>>>>>>>>>> class.
>>>>>>>>>>   Enabling the image scaling rendering hint forces the
>>>>>>>>>> SunGraphics2D
>>>>>>>>>> to use getScaledInstance(width, height, hints) method
>>>>>>>>>>   from Image class with SCALE_DEFAULT hint.
>>>>>>>>>>
>>>>>>>>>>   By default the image scaling rendering hint is enabled on 
>>>>>>>>>> HiDPI
>>>>>>>>>> display and disabled for standard displays.
>>>>>>>>>>
>>>>>>>>>>   User can override the getScaledInstance(width, height, hints)
>>>>>>>>>> method and return necessary high resolution image
>>>>>>>>>>   according to the given image width and height.
>>>>>>>>>>
>>>>>>>>>>   For example:
>>>>>>>>>>   ---------------------
>>>>>>>>>>         final Image highResolutionImage =
>>>>>>>>>>                 new BufferedImage(2 * WIDTH, 2 * HEIGHT,
>>>>>>>>>> BufferedImage.TYPE_INT_RGB);
>>>>>>>>>>         Image image = new BufferedImage(WIDTH, HEIGHT,
>>>>>>>>>> BufferedImage.TYPE_INT_RGB) {
>>>>>>>>>>
>>>>>>>>>>             @Override
>>>>>>>>>>             public Image getScaledInstance(int width, int 
>>>>>>>>>> height,
>>>>>>>>>> int
>>>>>>>>>> hints) {
>>>>>>>>>>                 if ((hints & Image.SCALE_DEFAULT) != 0) {
>>>>>>>>>>                     return (width <= WIDTH && height <= HEIGHT)
>>>>>>>>>>                             ? this : highResolutionImage;
>>>>>>>>>>                 }
>>>>>>>>>>                 return super.getScaledInstance(width, height,
>>>>>>>>>> hints);
>>>>>>>>>>             }
>>>>>>>>>>         };
>>>>>>>>>>   ---------------------
>>>>>>>>>>
>>>>>>>>>>   The LWCToolkit and ToolkitImage classes are patched to
>>>>>>>>>> automatically get provided image at 2x.ext images on MacOSX.
>>>>>>>>>>
>>>>>>>>>>   There are no significant changes in the Java2D demo to make it
>>>>>>>>>> look
>>>>>>>>>> perfect on Retina displays.
>>>>>>>>>>   It needs only to put necessary images with the @2x postfix and
>>>>>>>>>> they
>>>>>>>>>> will be automatically drawn.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>


-- 
Best regards, Sergey.



From linuxhippy at gmail.com  Thu Nov  7 00:05:06 2013
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 6 Nov 2013 19:05:06 -0500
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527ACC42.6060001@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com> <527AB743.8050106@oracle.com>
	<527ACC42.6060001@oracle.com>
Message-ID: <CAFvQSYTCjm0xRhA_Wpz=BP4ROWgSzEd0fNdgja6fkqVgwWpVPg@mail.gmail.com>

Hi Sergey,

> Well during draw of the image we should request appropriate scale image from
> the user, who possible know better how its image can be scaled.
> What can be better, than a method which "Creates a scaled version of this
> image."?

getScaledImage() returns a scaled "reference" (not a copy) of the
original image.
So when the original image is changed, the scaled instance has to change too.
When this is overriden like you suggest, this changes semantics of the API.

In case getScaledInstance() is not overridden, the user is stuck with
non-accelerated blits.
Chris has written a nice blog post about getScaledImage() and why it
should be avoided:
https://today.java.net/pub/a/today/2007/04/03/perils-of-image-getscaledinstance.html

Regards, Clemens


From james.graham at oracle.com  Thu Nov  7 00:09:59 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 06 Nov 2013 16:09:59 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527ACC42.6060001@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>
	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>
	<527AB743.8050106@oracle.com> <527ACC42.6060001@oracle.com>
Message-ID: <527ADA57.3020803@oracle.com>

On 11/6/13 3:09 PM, Sergey Bylokhov wrote:
> Hi , Jim.
> On 07.11.2013 1:40, Jim Graham wrote:
>> On 11/6/13 5:19 AM, Alexander Scherbatiy wrote:
>>> On 11/6/2013 5:39 AM, Jim Graham wrote:
>>>> Why is getScaledInstance() being consulted here?  It seems a misuse of
>>>> that method.
>>>      We need to introduce a new API that allows developers to return
>>> scaled images for HiDPI displays.
>>
>> Then we should introduce new API.
> Well during draw of the image we should request appropriate scale image
> from the user, who possible know better how its image can be scaled.
> What can be better, than a method which "Creates a scaled version of
> this image."?

That method "returns a scaled version of *this* image".  It specifically 
refers to recombining the pixels of the image you would normally get 
into a new image that, by default, renders at the requested size.

The method has parameters to control the pixel replication/elimination 
*algorithm*.

This is a pixel manipulation method pure and simple.  It is also not 
anywhere documented that it is used by drawImage(), in fact it is 
documented that the developer call this method and then the result is 
for the developer to use when they call drawImage().

drawImage() should *NOT* be using this method on its own, and the method 
should not be involved in choosing alternate designs.  It is for 
manually resampling an image into a new permanent image.

>>>      The good way is to allow a user to override a method like
>>> getScaledImage() which has either scaledFactor or width and height
>>> parameters and returns necessary scaled images.
>>
>> If that is a new API with new semantics, then I agree.
>>
>>>      But the  getScaledImage(width, height) method looks similar to the
>>> getScaledInstance(width, height, hints). It also can confuse a user
>>> which method should be overridden to return
>>>      the scaled version of an image.
>>
>> A better name would help.  I don't think width/height are really the
>> best parameters for such a method since you want an image that can be
>> substituted and the original image has already established an aspect
>> ratio.  A single resolution would have been preferable.
> But it can be used independently, if the graphics is scaled in one
> direction. And to allow the user to decide how to scale the picture
> depending on how it will be expanded. And there is no direct
> relationship with retina and its scale factor.

Currently we only have one case of HiDPI displays (retina) and they have 
the same pixel scaling in both directions.  It is true that a more 
complete API would allow for having different resolutions in X and Y, 
though I'm not sure that will ever be a case needed in practice.

> We can move deeper and request here the actual size of the image
> including transform of the graphics (<=TRANSFORM_TRANSLATESCALE). So the
> user can apply IMAGE_SCALING hint to the transformed sg2d and all images
> will have a chance to use custom scale instead of  some scaling from the
> sg2d.

I see no reason for this.  We are trying to solve image fidelity for 
retina displays here, (and hopefully whatever Windows comes up with for 
similar purposes).  The graphics object already has plenty of 
information at its disposal to determine how to scale images.

I also don't think we want to take the transform into consideration.  We 
are either "on a hi res display" or we are not on such a display and we 
should use the variant of the image that is appropriate for that 
display, even if they are scaled up or down by 2x or more - we don't 
want an image to suddenly change its look just because they are 
animating its size (though we could offer a hint in the future that 
might indicate that they would like us to do that, I don't think it 
should be the standard or default behavior and I am not sure anyone 
would ever actually want it in the first place as it creates a visual 
discontinuity in what should be a smooth seamless process).

>> And there are 10 years of potential overrides that developers could
>> have created that could be even worse than the default implementation
>> from a performance perspective.  "Whether or not the method is
>> overridden" is a bad heuristic from the get go and it is much, much
>> more inappropriate to apply to a legacy method that has been in the
>> wild for over a decade.
> If user overrides this method and provides some specific scale algorithm
> is not what we want from the beginning?

No, that method is provided for developers to call to get "scaled 
versions" of an image.  If they've provided some custom code - of 
unknown performance capability - in their libraries and apps then they 
have probably not expected this to ever be used in any automatic sense 
by drawImage().

> "Whether or not the method is overridden" come in to play because
> default scale operation in SG2D and the results of default
> implementation of getScaledInstance is quite similar, but performance is
> extremely different.
> So it can be rephrased as "Whether or not the default scale algorithm is
> use", so in the fix we use default from the S2G2 not Image.

They came into play because you were calling that method in a place that 
you should never have been calling that method.

>> The suggestion to add a new hint to a decade old API is unwise.
>> Additionally, the hint requested "SCALE_CUSTOM" could mean anything
>> and is documented so loosely that resolution swapping is only one of
>> an infinite number of responses an application could make.  The spec
>> of that hint also violates the contract of the getScaledInstance()
>> method which states that the returned instance will be of the
>> requested size, but you are planning on returning an image that can
>> have a different size.
> It return the image which is rendered to appropriate width and height by
> default. It is not necessary to be always the same sized image. Moreover
> it can be a different size image in case of negative width/height.
> This hint will be enabled on the retina device by default, but can be
> enabled by the user as well for any graphics

Fact: getScaledInstance() *MUST ALWAYS* return an image that is the 
requested WxH.  It has no other option.  you can't override that *API 
REQUIREMENT* in the documentation of a hint.  Read the documentation for 
it: "A new Image object is returned which will render the image at the 
specified width and height by default."  In other words, if you call 
g.drawImage(thenewscaledinstance, x, y) (i.e. the version with no w,h 
parameters in the drawImage() signature) then it will draw at the size 
requested when "thenewscaledinstance" was created.

> In general an idea of the fix is: The image know better how it could be
> scaled
>   - It could use some pixel replicate scale filters
>   - it could use different files images
>   - it could redraw itself from scratch if it use vectors graphics.
> The only parameters it needed is width and height.

You are not understanding that it is a new scaled version of *THIS* 
image.  The pixels from the original image must be used.  This is about 
pixel replication algorithms, not about redesigning a representation.

> The CUSTOM hint is used for two reasons
>   - to use default scale from graphics and to skip default in image
>   - to explicitly document new usage of getScaledInstance().
>
> And additionally about compatibility you can compare this version of the
> fix and version of jdk7(where demos was rewritten). If I understand it
> correctly nothing should be changed in demos in the current version of
> the fix(except new x2 images.)
> http://closedjdk.us.oracle.com/jdk7u/jdk7u-dev/jdk/src/closed/rev/335cba03699d

I am not suggesting that we change the demos.  I am suggesting that we 
handle this internally for now with an option to provide a developer to 
inspect and/or intercept the process when we can create new API.

There is no reason our own internal toolkit images could not provide an 
internal API that only our toolkits have access to in JDK7/8 which is 
very similar to the way that you are using getScaledInstance() here, but 
it is using private internal interfaces that won't be confused with 
legacy public API and won't run into legacy performance issues and won't 
redesign a legacy API to do a job it was never intended or designed to 
do and which it was specifically designed and specified to not do.

In other words:

package sun.awt.image;

public interface MultiResImage {
     public Image getResolutionVariant(float resolution);
}

public class MacImage extends Image implements MultiResImage {
     public Image getResolutionVariant(float resolution) {
         if (resolution >= 2f && ImageAt2x != null) {
             return ImageAt2x;
         }
         return this;
     }
}

SG2D.drawImage() {
     if (img instanceof MultiResImage && dest.pixelscale != 1) {
         img = ((MultiResImage) img).getResolutionVariant(dest.pixelscale);
     }
}

			...jim

>>>> The @2x mechanism should be based on different API.  I guess it would
>>>> have to be internal-only for 8.0 and could be exposed to allow
>>>> developers to call it and possibly to be a provider for it in JDK9...
>>>>
>>>>             ...jim
>>>>
>>>> On 10/31/13 9:19 AM, Alexander Scherbatiy wrote:
>>>>>
>>>>>   Could you review the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.04/
>>>>>
>>>>>     The reflection is used to skip the Image.getScaledInstance()
>>>>> method
>>>>> call if it is not overridden by a user.
>>>>>
>>>>> On 10/29/2013 11:08 PM, Sergey Bylokhov wrote:
>>>>>> Hi, Alexander.
>>>>>> The fix looks fine to me in general. But there is at least one issue.
>>>>>> I build you fix and test it:
>>>>>>  - Consuming of cpu increased by 500 times Java2Demo on images tab.
>>>>>>  - FPS is dropped from 220(jdk8)/35(jdk7u40) to 15 in guimark2. Note
>>>>>> that jdk6 has the same FPS(15) on my system.
>>>>>
>>>>>     The main problem is that the Image.SCALE_DEFAULT hint is used to
>>>>> retrieve a scaled image from Image.getScaledInstance() method.
>>>>>     It always uses the ReplicateScaleFilter for images which
>>>>> getScaledInstance() method has not been overridden.
>>>>>     The ReplicateScaleFilter creates a lot of arrays and consumes the
>>>>> CPU during the image parsing.
>>>>>
>>>>>     The better fix would be to introduce the new Image.SCALE_CUSTOM
>>>>> hint
>>>>> which could be used to get a scaled image and does not use filters by
>>>>> default.
>>>>>     But it should be a separated bug with a new CCC request.
>>>>>
>>>>>    Thanks,
>>>>>    Alexandr.
>>>>>
>>>>>>
>>>>>> On 29.10.2013 20:45, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>   Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.03
>>>>>>>
>>>>>>> On 10/28/2013 2:33 PM, Artem Ananiev wrote:
>>>>>>>> Hi, Alexander,
>>>>>>>>
>>>>>>>> a few comments:
>>>>>>>>
>>>>>>>> 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here?
>>>>>>>      The isHiDPIImage() method is used to check that the
>>>>>>> drawHiDPIImage should be called like:
>>>>>>>         if (isHiDPIImage(img)) {
>>>>>>>             return drawHiDPIImage(...);
>>>>>>>         }
>>>>>>>
>>>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>>>> implementation in ScalableToolkitImage works perfectly for URLs
>>>>>>>> like
>>>>>>>> this:
>>>>>>>>
>>>>>>>> http://www.exampmle.com/dir/image
>>>>>>>>
>>>>>>>> In this case it will try to find 2x image here:
>>>>>>>>
>>>>>>>> http://www.example at 2x.com/dir/image
>>>>>>>>
>>>>>>>> which doesn't look correct.
>>>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>>>>
>>>>>>>> 3. RenderingHints spec references Retina or non-Retina displays,
>>>>>>>> which should be removed.
>>>>>>>        Fixed.
>>>>>>>
>>>>>>>     - devScale is used instead of transform parsing in the
>>>>>>> drawHiDPIImage() method just to not have performance regression more
>>>>>>> than 2 times on HiDPI displays
>>>>>>>     - LWCToolkit.ScalableToolkitImage is made public for the fix
>>>>>>> 8024926 [macosx] AquaIcon HiDPI support.
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>     Alexandr.
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Artem
>>>>>>>>
>>>>>>>> On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>>    Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/
>>>>>>>>>
>>>>>>>>>    - Scaled image width and height are transformed according to
>>>>>>>>> the
>>>>>>>>> AffineTransform type.
>>>>>>>>>    - ToolkitImage subclass is used to hold @2x image instance.
>>>>>>>>>
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>>>
>>>>>>>>> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>>   Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/
>>>>>>>>>>
>>>>>>>>>>   The JCK failures has been resolved:
>>>>>>>>>>     - Some tests tries to draw an image with Integer.MAX_VALUE
>>>>>>>>>> width
>>>>>>>>>> or height. Passing large values to image.getScaledImage(width,
>>>>>>>>>> height,
>>>>>>>>>> hints).
>>>>>>>>>>        leads that an Image filter is not able to create necessary
>>>>>>>>>> arrays.  The fix uses the original image if width or height are
>>>>>>>>>> equal
>>>>>>>>>> to Integer.MAX_VALUE.
>>>>>>>>>>     - Using Image.SCALE_DEFAULT hint for the
>>>>>>>>>> getScaledImage(width,
>>>>>>>>>> height, hints) method to get the high resolution image interferes
>>>>>>>>>> with
>>>>>>>>>>        JCK tests that expect that the scaled image by certain
>>>>>>>>>> algorithm is returned. This is fixed by invoking the
>>>>>>>>>> super.getScaledImage(width, height, hints)
>>>>>>>>>>        method in ToolkitImage in case if a high resolution
>>>>>>>>>> image is
>>>>>>>>>> not set.
>>>>>>>>>>
>>>>>>>>>>     Thanks,
>>>>>>>>>>     Alexandr.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>
>>>>>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8011059
>>>>>>>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00
>>>>>>>>>>>
>>>>>>>>>>>   The IMAGE_SCALING rendering hint is added to the
>>>>>>>>>>> RenderingHints
>>>>>>>>>>> class.
>>>>>>>>>>>   Enabling the image scaling rendering hint forces the
>>>>>>>>>>> SunGraphics2D
>>>>>>>>>>> to use getScaledInstance(width, height, hints) method
>>>>>>>>>>>   from Image class with SCALE_DEFAULT hint.
>>>>>>>>>>>
>>>>>>>>>>>   By default the image scaling rendering hint is enabled on
>>>>>>>>>>> HiDPI
>>>>>>>>>>> display and disabled for standard displays.
>>>>>>>>>>>
>>>>>>>>>>>   User can override the getScaledInstance(width, height, hints)
>>>>>>>>>>> method and return necessary high resolution image
>>>>>>>>>>>   according to the given image width and height.
>>>>>>>>>>>
>>>>>>>>>>>   For example:
>>>>>>>>>>>   ---------------------
>>>>>>>>>>>         final Image highResolutionImage =
>>>>>>>>>>>                 new BufferedImage(2 * WIDTH, 2 * HEIGHT,
>>>>>>>>>>> BufferedImage.TYPE_INT_RGB);
>>>>>>>>>>>         Image image = new BufferedImage(WIDTH, HEIGHT,
>>>>>>>>>>> BufferedImage.TYPE_INT_RGB) {
>>>>>>>>>>>
>>>>>>>>>>>             @Override
>>>>>>>>>>>             public Image getScaledInstance(int width, int
>>>>>>>>>>> height,
>>>>>>>>>>> int
>>>>>>>>>>> hints) {
>>>>>>>>>>>                 if ((hints & Image.SCALE_DEFAULT) != 0) {
>>>>>>>>>>>                     return (width <= WIDTH && height <= HEIGHT)
>>>>>>>>>>>                             ? this : highResolutionImage;
>>>>>>>>>>>                 }
>>>>>>>>>>>                 return super.getScaledInstance(width, height,
>>>>>>>>>>> hints);
>>>>>>>>>>>             }
>>>>>>>>>>>         };
>>>>>>>>>>>   ---------------------
>>>>>>>>>>>
>>>>>>>>>>>   The LWCToolkit and ToolkitImage classes are patched to
>>>>>>>>>>> automatically get provided image at 2x.ext images on MacOSX.
>>>>>>>>>>>
>>>>>>>>>>>   There are no significant changes in the Java2D demo to make it
>>>>>>>>>>> look
>>>>>>>>>>> perfect on Retina displays.
>>>>>>>>>>>   It needs only to put necessary images with the @2x postfix and
>>>>>>>>>>> they
>>>>>>>>>>> will be automatically drawn.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alexandr.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>
>


From james.graham at oracle.com  Thu Nov  7 00:12:42 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 06 Nov 2013 16:12:42 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <CAFvQSYTCjm0xRhA_Wpz=BP4ROWgSzEd0fNdgja6fkqVgwWpVPg@mail.gmail.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com> <527AB743.8050106@oracle.com>
	<527ACC42.6060001@oracle.com>
	<CAFvQSYTCjm0xRhA_Wpz=BP4ROWgSzEd0fNdgja6fkqVgwWpVPg@mail.gmail.com>
Message-ID: <527ADAFA.40503@oracle.com>

Thanks Clemens, I completely forgot about how this all interacts with 
old 1.1-style "generated images", but that is a further complication in 
that those images that never sent an IMAGE_COMPLETE notification were 
dynamic in a very unhealthy way and creating a scaled instance was just 
one of those cases where everything could bog down.

We should be looking to obsolete and delete getScaledInstance(), not 
giving it a new lease on life with new capabilities...

			...jim

On 11/6/13 4:05 PM, Clemens Eisserer wrote:
> Hi Sergey,
>
>> Well during draw of the image we should request appropriate scale image from
>> the user, who possible know better how its image can be scaled.
>> What can be better, than a method which "Creates a scaled version of this
>> image."?
>
> getScaledImage() returns a scaled "reference" (not a copy) of the
> original image.
> So when the original image is changed, the scaled instance has to change too.
> When this is overriden like you suggest, this changes semantics of the API.
>
> In case getScaledInstance() is not overridden, the user is stuck with
> non-accelerated blits.
> Chris has written a nice blog post about getScaledImage() and why it
> should be avoided:
> https://today.java.net/pub/a/today/2007/04/03/perils-of-image-getscaledinstance.html
>
> Regards, Clemens
>


From linuxhippy at gmail.com  Thu Nov  7 00:19:21 2013
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 6 Nov 2013 19:19:21 -0500
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527ADAFA.40503@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com> <527AB743.8050106@oracle.com>
	<527ACC42.6060001@oracle.com>
	<CAFvQSYTCjm0xRhA_Wpz=BP4ROWgSzEd0fNdgja6fkqVgwWpVPg@mail.gmail.com>
	<527ADAFA.40503@oracle.com>
Message-ID: <CAFvQSYRFH+HVu7tix-1auyMtoCnFOQ3-jd3w7EHvmOS5ej2Zmg@mail.gmail.com>

Hi Jim,

> We should be looking to obsolete and delete getScaledInstance(), not giving
> it a new lease on life with new capabilities...

Marking it deprecated would probably be a good idea, at least the JDK7
javadocs don't warn developers in any way about the implications of
using getScaledInstance().
Maybe something like getScaledCopy() could be provided as replacement
(I've never seen code where the in-sync feature of getScaledInstance
was used intentionally).

- Clemens


From Sergey.Bylokhov at oracle.com  Thu Nov  7 00:49:08 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 07 Nov 2013 04:49:08 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <CAFvQSYTCjm0xRhA_Wpz=BP4ROWgSzEd0fNdgja6fkqVgwWpVPg@mail.gmail.com>
References: <52664607.2090807@oracle.com>	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>	<527AB743.8050106@oracle.com>	<527ACC42.6060001@oracle.com>
	<CAFvQSYTCjm0xRhA_Wpz=BP4ROWgSzEd0fNdgja6fkqVgwWpVPg@mail.gmail.com>
Message-ID: <527AE384.7020108@oracle.com>

On 07.11.2013 4:05, Clemens Eisserer wrote:
> getScaledImage() returns a scaled "reference" (not a copy) of the
> original image.
> So when the original image is changed, the scaled instance has to change too.
> When this is overriden like you suggest, this changes semantics of the API.
>
> In case getScaledInstance() is not overridden, the user is stuck with
> non-accelerated blits.
No If it is not overriden it will be noop and return the same image.
> Chris has written a nice blog post about getScaledImage() and why it
> should be avoided:
> https://today.java.net/pub/a/today/2007/04/03/perils-of-image-getscaledinstance.html
>
> Regards, Clemens


-- 
Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Thu Nov  7 01:20:32 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 07 Nov 2013 05:20:32 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527ADA57.3020803@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>
	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>
	<527AB743.8050106@oracle.com> <527ACC42.6060001@oracle.com>
	<527ADA57.3020803@oracle.com>
Message-ID: <527AEAE0.9000907@oracle.com>

On 07.11.2013 4:09, Jim Graham wrote:
> On 11/6/13 3:09 PM, Sergey Bylokhov wrote:
>> Hi , Jim.
>> On 07.11.2013 1:40, Jim Graham wrote:
>>> On 11/6/13 5:19 AM, Alexander Scherbatiy wrote:
>>>> On 11/6/2013 5:39 AM, Jim Graham wrote:
>>>>> Why is getScaledInstance() being consulted here?  It seems a 
>>>>> misuse of
>>>>> that method.
>>>>      We need to introduce a new API that allows developers to return
>>>> scaled images for HiDPI displays.
>>>
>>> Then we should introduce new API.
>> Well during draw of the image we should request appropriate scale image
>> from the user, who possible know better how its image can be scaled.
>> What can be better, than a method which "Creates a scaled version of
>> this image."?
>
> That method "returns a scaled version of *this* image".  It 
> specifically refers to recombining the pixels of the image you would 
> normally get into a new image that, by default, renders at the 
> requested size.
>
> The method has parameters to control the pixel replication/elimination 
> *algorithm*.
Custom hint can be renamed to the BEST_EVER_QUALITY_AS_IMAGE_CANhint and 
write in doc that it is nop by default..
>
> This is a pixel manipulation method pure and simple.  It is also not 
> anywhere documented that it is used by drawImage(), in fact it is 
> documented that the developer call this method and then the result is 
> for the developer to use when they call drawImage().
>
> drawImage() should *NOT* be using this method on its own, and the 
> method should not be involved in choosing alternate designs.  It is 
> for manually resampling an image into a new permanent image.
Why not? We can document that. It is something related to 
|RenderingHints.KEY_INTERPOLATION| which was added as an alternate of 
image hints. But this new hints do not provide possibility to customize 
scaling by the user.
> But it can be used independently, if the graphics is scaled in one
>> direction. And to allow the user to decide how to scale the picture
>> depending on how it will be expanded. And there is no direct
>> relationship with retina and its scale factor.
>
> Currently we only have one case of HiDPI displays (retina) and they 
> have the same pixel scaling in both directions.  It is true that a 
> more complete API would allow for having different resolutions in X 
> and Y, though I'm not sure that will ever be a case needed in practice.
>
>> We can move deeper and request here the actual size of the image
>> including transform of the graphics (<=TRANSFORM_TRANSLATESCALE). So the
>> user can apply IMAGE_SCALING hint to the transformed sg2d and all images
>> will have a chance to use custom scale instead of  some scaling from the
>> sg2d.
>
> I see no reason for this.  We are trying to solve image fidelity for 
> retina displays here, (and hopefully whatever Windows comes up with 
> for similar purposes).  The graphics object already has plenty of 
> information at its disposal to determine how to scale images.
>
> I also don't think we want to take the transform into consideration.  
> We are either "on a hi res display" or we are not on such a display 
> and we should use the variant of the image that is appropriate for 
> that display, even if they are scaled up or down by 2x or more - we 
> don't want an image to suddenly change its look just because they are 
> animating its size (though we could offer a hint in the future that 
> might indicate that they would like us to do that, I don't think it 
> should be the standard or default behavior and I am not sure anyone 
> would ever actually want it in the first place as it creates a visual 
> discontinuity in what should be a smooth seamless process).
>
>>> And there are 10 years of potential overrides that developers could
>>> have created that could be even worse than the default implementation
>>> from a performance perspective.  "Whether or not the method is
>>> overridden" is a bad heuristic from the get go and it is much, much
>>> more inappropriate to apply to a legacy method that has been in the
>>> wild for over a decade.
>> If user overrides this method and provides some specific scale algorithm
>> is not what we want from the beginning?
>
> No, that method is provided for developers to call to get "scaled 
> versions" of an image.  If they've provided some custom code - of 
> unknown performance capability - in their libraries and apps then they 
> have probably not expected this to ever be used in any automatic sense 
> by drawImage().
>
>> "Whether or not the method is overridden" come in to play because
>> default scale operation in SG2D and the results of default
>> implementation of getScaledInstance is quite similar, but performance is
>> extremely different.
>> So it can be rephrased as "Whether or not the default scale algorithm is
>> use", so in the fix we use default from the S2G2 not Image.
> Fact: getScaledInstance() *MUST ALWAYS* return an image that is the 
> requested WxH.  It has no other option.  you can't override that *API 
> REQUIREMENT* in the documentation of a hint.  Read the documentation 
> for it: "A new Image object is returned which will render the image at 
> the specified width and height by default." 
Yes, I see. The image should be "new" and it does not say it should be 
the same object. And content of this "new" image depends from the hint 
which was passed to the method.
> In other words, if you call g.drawImage(thenewscaledinstance, x, y) 
> (i.e. the version with no w,h parameters in the drawImage() signature) 
> then it will draw at the size requested when "thenewscaledinstance" 
> was created.
>
>> In general an idea of the fix is: The image know better how it could be
>> scaled
>>   - It could use some pixel replicate scale filters
>>   - it could use different files images
>>   - it could redraw itself from scratch if it use vectors graphics.
>> The only parameters it needed is width and height.
>
> You are not understanding that it is a new scaled version of *THIS* 
> image.  The pixels from the original image must be used. This is about 
> pixel replication algorithms, not about redesigning a representation.
The user know what pixels contains in its image, and he know how to 
scale its better.
>
>> The CUSTOM hint is used for two reasons
>>   - to use default scale from graphics and to skip default in image
>>   - to explicitly document new usage of getScaledInstance().
>>
>> And additionally about compatibility you can compare this version of the
>> fix and version of jdk7(where demos was rewritten). If I understand it
>> correctly nothing should be changed in demos in the current version of
>> the fix(except new x2 images.)
>> http://closedjdk.us.oracle.com/jdk7u/jdk7u-dev/jdk/src/closed/rev/335cba03699d 
>>
>
> I am not suggesting that we change the demos.  I am suggesting that we 
> handle this internally for now with an option to provide a developer 
> to inspect and/or intercept the process when we can create new API.
>
> In other words:
>
> package sun.awt.image;
>
> public interface MultiResImage {
>     public Image getResolutionVariant(float resolution);
> }
>
> public class MacImage extends Image implements MultiResImage {
>     public Image getResolutionVariant(float resolution) {
>         if (resolution >= 2f && ImageAt2x != null) {
>             return ImageAt2x;
>         }
>         return this;
>     }
> }
>
> SG2D.drawImage() {
>     if (img instanceof MultiResImage && dest.pixelscale != 1) {
>         img = ((MultiResImage) 
> img).getResolutionVariant(dest.pixelscale);
>     }
> }
In this example there is a problem. For example we have 2 
BufferedImages/ToolkiImagest A and B; Both wants be scaled perfectly.
  - Image A draws to the image B
  - Image B draws to the window.

When window is moving from the screen x1 to the screen x2 and back. How 
to handle this situation?
In this case getResolutionVariant() can return


Related  discussion:
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005580.html
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005581.html
>
>             ...jim
>
>>>>> The @2x mechanism should be based on different API.  I guess it would
>>>>> have to be internal-only for 8.0 and could be exposed to allow
>>>>> developers to call it and possibly to be a provider for it in JDK9...
>>>>>
>>>>>             ...jim
>>>>>
>>>>> On 10/31/13 9:19 AM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>   Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.04/
>>>>>>
>>>>>>     The reflection is used to skip the Image.getScaledInstance()
>>>>>> method
>>>>>> call if it is not overridden by a user.
>>>>>>
>>>>>> On 10/29/2013 11:08 PM, Sergey Bylokhov wrote:
>>>>>>> Hi, Alexander.
>>>>>>> The fix looks fine to me in general. But there is at least one 
>>>>>>> issue.
>>>>>>> I build you fix and test it:
>>>>>>>  - Consuming of cpu increased by 500 times Java2Demo on images tab.
>>>>>>>  - FPS is dropped from 220(jdk8)/35(jdk7u40) to 15 in guimark2. 
>>>>>>> Note
>>>>>>> that jdk6 has the same FPS(15) on my system.
>>>>>>
>>>>>>     The main problem is that the Image.SCALE_DEFAULT hint is used to
>>>>>> retrieve a scaled image from Image.getScaledInstance() method.
>>>>>>     It always uses the ReplicateScaleFilter for images which
>>>>>> getScaledInstance() method has not been overridden.
>>>>>>     The ReplicateScaleFilter creates a lot of arrays and consumes 
>>>>>> the
>>>>>> CPU during the image parsing.
>>>>>>
>>>>>>     The better fix would be to introduce the new Image.SCALE_CUSTOM
>>>>>> hint
>>>>>> which could be used to get a scaled image and does not use 
>>>>>> filters by
>>>>>> default.
>>>>>>     But it should be a separated bug with a new CCC request.
>>>>>>
>>>>>>    Thanks,
>>>>>>    Alexandr.
>>>>>>
>>>>>>>
>>>>>>> On 29.10.2013 20:45, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>>   Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.03
>>>>>>>>
>>>>>>>> On 10/28/2013 2:33 PM, Artem Ananiev wrote:
>>>>>>>>> Hi, Alexander,
>>>>>>>>>
>>>>>>>>> a few comments:
>>>>>>>>>
>>>>>>>>> 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here?
>>>>>>>>      The isHiDPIImage() method is used to check that the
>>>>>>>> drawHiDPIImage should be called like:
>>>>>>>>         if (isHiDPIImage(img)) {
>>>>>>>>             return drawHiDPIImage(...);
>>>>>>>>         }
>>>>>>>>
>>>>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>>>>> implementation in ScalableToolkitImage works perfectly for URLs
>>>>>>>>> like
>>>>>>>>> this:
>>>>>>>>>
>>>>>>>>> http://www.exampmle.com/dir/image
>>>>>>>>>
>>>>>>>>> In this case it will try to find 2x image here:
>>>>>>>>>
>>>>>>>>> http://www.example at 2x.com/dir/image
>>>>>>>>>
>>>>>>>>> which doesn't look correct.
>>>>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>>>>>
>>>>>>>>> 3. RenderingHints spec references Retina or non-Retina displays,
>>>>>>>>> which should be removed.
>>>>>>>>        Fixed.
>>>>>>>>
>>>>>>>>     - devScale is used instead of transform parsing in the
>>>>>>>> drawHiDPIImage() method just to not have performance regression 
>>>>>>>> more
>>>>>>>> than 2 times on HiDPI displays
>>>>>>>>     - LWCToolkit.ScalableToolkitImage is made public for the fix
>>>>>>>> 8024926 [macosx] AquaIcon HiDPI support.
>>>>>>>>
>>>>>>>>     Thanks,
>>>>>>>>     Alexandr.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Artem
>>>>>>>>>
>>>>>>>>> On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>>    Could you review the updated fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/
>>>>>>>>>>
>>>>>>>>>>    - Scaled image width and height are transformed according to
>>>>>>>>>> the
>>>>>>>>>> AffineTransform type.
>>>>>>>>>>    - ToolkitImage subclass is used to hold @2x image instance.
>>>>>>>>>>
>>>>>>>>>>   Thanks,
>>>>>>>>>>   Alexandr.
>>>>>>>>>>
>>>>>>>>>> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>
>>>>>>>>>>>   Could you review the updated fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>>   The JCK failures has been resolved:
>>>>>>>>>>>     - Some tests tries to draw an image with Integer.MAX_VALUE
>>>>>>>>>>> width
>>>>>>>>>>> or height. Passing large values to image.getScaledImage(width,
>>>>>>>>>>> height,
>>>>>>>>>>> hints).
>>>>>>>>>>>        leads that an Image filter is not able to create 
>>>>>>>>>>> necessary
>>>>>>>>>>> arrays.  The fix uses the original image if width or height are
>>>>>>>>>>> equal
>>>>>>>>>>> to Integer.MAX_VALUE.
>>>>>>>>>>>     - Using Image.SCALE_DEFAULT hint for the
>>>>>>>>>>> getScaledImage(width,
>>>>>>>>>>> height, hints) method to get the high resolution image 
>>>>>>>>>>> interferes
>>>>>>>>>>> with
>>>>>>>>>>>        JCK tests that expect that the scaled image by certain
>>>>>>>>>>> algorithm is returned. This is fixed by invoking the
>>>>>>>>>>> super.getScaledImage(width, height, hints)
>>>>>>>>>>>        method in ToolkitImage in case if a high resolution
>>>>>>>>>>> image is
>>>>>>>>>>> not set.
>>>>>>>>>>>
>>>>>>>>>>>     Thanks,
>>>>>>>>>>>     Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>
>>>>>>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8011059
>>>>>>>>>>>>   webrev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.00
>>>>>>>>>>>>
>>>>>>>>>>>>   The IMAGE_SCALING rendering hint is added to the
>>>>>>>>>>>> RenderingHints
>>>>>>>>>>>> class.
>>>>>>>>>>>>   Enabling the image scaling rendering hint forces the
>>>>>>>>>>>> SunGraphics2D
>>>>>>>>>>>> to use getScaledInstance(width, height, hints) method
>>>>>>>>>>>>   from Image class with SCALE_DEFAULT hint.
>>>>>>>>>>>>
>>>>>>>>>>>>   By default the image scaling rendering hint is enabled on
>>>>>>>>>>>> HiDPI
>>>>>>>>>>>> display and disabled for standard displays.
>>>>>>>>>>>>
>>>>>>>>>>>>   User can override the getScaledInstance(width, height, 
>>>>>>>>>>>> hints)
>>>>>>>>>>>> method and return necessary high resolution image
>>>>>>>>>>>>   according to the given image width and height.
>>>>>>>>>>>>
>>>>>>>>>>>>   For example:
>>>>>>>>>>>>   ---------------------
>>>>>>>>>>>>         final Image highResolutionImage =
>>>>>>>>>>>>                 new BufferedImage(2 * WIDTH, 2 * HEIGHT,
>>>>>>>>>>>> BufferedImage.TYPE_INT_RGB);
>>>>>>>>>>>>         Image image = new BufferedImage(WIDTH, HEIGHT,
>>>>>>>>>>>> BufferedImage.TYPE_INT_RGB) {
>>>>>>>>>>>>
>>>>>>>>>>>>             @Override
>>>>>>>>>>>>             public Image getScaledInstance(int width, int
>>>>>>>>>>>> height,
>>>>>>>>>>>> int
>>>>>>>>>>>> hints) {
>>>>>>>>>>>>                 if ((hints & Image.SCALE_DEFAULT) != 0) {
>>>>>>>>>>>>                     return (width <= WIDTH && height <= 
>>>>>>>>>>>> HEIGHT)
>>>>>>>>>>>>                             ? this : highResolutionImage;
>>>>>>>>>>>>                 }
>>>>>>>>>>>>                 return super.getScaledInstance(width, height,
>>>>>>>>>>>> hints);
>>>>>>>>>>>>             }
>>>>>>>>>>>>         };
>>>>>>>>>>>>   ---------------------
>>>>>>>>>>>>
>>>>>>>>>>>>   The LWCToolkit and ToolkitImage classes are patched to
>>>>>>>>>>>> automatically get provided image at 2x.ext images on MacOSX.
>>>>>>>>>>>>
>>>>>>>>>>>>   There are no significant changes in the Java2D demo to 
>>>>>>>>>>>> make it
>>>>>>>>>>>> look
>>>>>>>>>>>> perfect on Retina displays.
>>>>>>>>>>>>   It needs only to put necessary images with the @2x 
>>>>>>>>>>>> postfix and
>>>>>>>>>>>> they
>>>>>>>>>>>> will be automatically drawn.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131107/ad75e5d0/attachment.html>

From james.graham at oracle.com  Thu Nov  7 01:59:20 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 06 Nov 2013 17:59:20 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527AEAE0.9000907@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>
	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>
	<527AB743.8050106@oracle.com> <527ACC42.6060001@oracle.com>
	<527ADA57.3020803@oracle.com> <527AEAE0.9000907@oracle.com>
Message-ID: <527AF3F8.4030107@oracle.com>

Hi Sergey,

On 11/6/13 5:20 PM, Sergey Bylokhov wrote:
> On 07.11.2013 4:09, Jim Graham wrote:
>> On 11/6/13 3:09 PM, Sergey Bylokhov wrote:
>> That method "returns a scaled version of *this* image".  It
>> specifically refers to recombining the pixels of the image you would
>> normally get into a new image that, by default, renders at the
>> requested size.
>>
>> The method has parameters to control the pixel replication/elimination
>> *algorithm*.
> Custom hint can be renamed to the BEST_EVER_QUALITY_AS_IMAGE_CANhint and
> write in doc that it is nop by default..

No hint can be a nop because the returned image *MUST* render at the 
requested size when passed to drawImage(img, x, y).

All of the hints refer to pixel resampling algorithms, there is no 
history of the hints or that method ever doing anything but pixel 
resampling.  Any ambiguity was left in order to support other pixel 
resampling algorithms in the future and for no other reason.

>> drawImage() should *NOT* be using this method on its own, and the
>> method should not be involved in choosing alternate designs.  It is
>> for manually resampling an image into a new permanent image.
> Why not? We can document that. It is something related to
> |RenderingHints.KEY_INTERPOLATION| which was added as an alternate of
> image hints. But this new hints do not provide possibility to customize
> scaling by the user.

Because it never has.  Because it's operation is specified to be 
asynchronous and so drawImage cannot depend on being able to produce a 
result if it uses that method.  Because it was created to solve a 
different purpose that has nothing to do with on-the-fly source image 
replacement.  Because developers have been free to create their own 
implementations that could do any number of things that would be 
inappropriate inside a drawImage call.  Because you've already 
discovered that, in fact, the default implementation was never anything 
that should ever be done inside a drawImage and you think that providing 
a workaround for that single issue is the answer rather than the fact 
that it should have been a huge wake up call that you barked up the 
wrong tree.

>> Fact: getScaledInstance() *MUST ALWAYS* return an image that is the
>> requested WxH.  It has no other option.  you can't override that *API
>> REQUIREMENT* in the documentation of a hint.  Read the documentation
>> for it: "A new Image object is returned which will render the image at
>> the specified width and height by default."
> Yes, I see. The image should be "new" and it does not say it should be
> the same object. And content of this "new" image depends from the hint
> which was passed to the method.

And, the image must be the indicated WxH - not a different WxH that 
might be somehow compatible with a request to draw at the requested WxH, 
but getWidth() and getHeight() *MUST* return the indicated parameters 
and if you render it with no w,h specified in the drawImage() call then 
it *MUST* draw at the indicated dimensions.

>> You are not understanding that it is a new scaled version of *THIS*
>> image.  The pixels from the original image must be used. This is about
>> pixel replication algorithms, not about redesigning a representation.
> The user know what pixels contains in its image, and he know how to
> scale its better.

But, the spec of the method is specifically geared towards pixel 
resampling, not pixel re-authoring.

				...jim


From james.graham at oracle.com  Thu Nov  7 02:01:20 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 06 Nov 2013 18:01:20 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527AEAE0.9000907@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>
	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>
	<527AB743.8050106@oracle.com> <527ACC42.6060001@oracle.com>
	<527ADA57.3020803@oracle.com> <527AEAE0.9000907@oracle.com>
Message-ID: <527AF470.1050300@oracle.com>



On 11/6/13 5:20 PM, Sergey Bylokhov wrote:
>> In other words:
>>
>> package sun.awt.image;
>>
>> public interface MultiResImage {
>>     public Image getResolutionVariant(float resolution);
>> }
>>
>> public class MacImage extends Image implements MultiResImage {
>>     public Image getResolutionVariant(float resolution) {
>>         if (resolution >= 2f && ImageAt2x != null) {
>>             return ImageAt2x;
>>         }
>>         return this;
>>     }
>> }
>>
>> SG2D.drawImage() {
>>     if (img instanceof MultiResImage && dest.pixelscale != 1) {
>>         img = ((MultiResImage)
>> img).getResolutionVariant(dest.pixelscale);
>>     }
>> }
> In this example there is a problem. For example we have 2
> BufferedImages/ToolkiImagest A and B; Both wants be scaled perfectly.
>   - Image A draws to the image B
>   - Image B draws to the window.
>
> When window is moving from the screen x1 to the screen x2 and back. How
> to handle this situation?
> In this case getResolutionVariant() can return
>
>
> Related  discussion:
> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005580.html
> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005581.html

How does calling getScaledInstance() deal with that?  Note the above was 
simply to demonstrate the visibility of the interface, not to be a 
complete implementation...

			...jim


From Sergey.Bylokhov at oracle.com  Thu Nov  7 02:15:36 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 07 Nov 2013 06:15:36 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527AF470.1050300@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>
	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>
	<527AB743.8050106@oracle.com> <527ACC42.6060001@oracle.com>
	<527ADA57.3020803@oracle.com> <527AEAE0.9000907@oracle.com>
	<527AF470.1050300@oracle.com>
Message-ID: <527AF7C8.3000007@oracle.com>

On 07.11.2013 6:01, Jim Graham wrote:
>
>
> On 11/6/13 5:20 PM, Sergey Bylokhov wrote:
>>> In other words:
>>>
>>> package sun.awt.image;
>>>
>>> public interface MultiResImage {
>>>     public Image getResolutionVariant(float resolution);
>>> }
>>>
>>> public class MacImage extends Image implements MultiResImage {
>>>     public Image getResolutionVariant(float resolution) {
>>>         if (resolution >= 2f && ImageAt2x != null) {
>>>             return ImageAt2x;
>>>         }
>>>         return this;
>>>     }
>>> }
>>>
>>> SG2D.drawImage() {
>>>     if (img instanceof MultiResImage && dest.pixelscale != 1) {
>>>         img = ((MultiResImage)
>>> img).getResolutionVariant(dest.pixelscale);
>>>     }
>>> }
>> In this example there is a problem. For example we have 2
>> BufferedImages/ToolkiImagest A and B; Both wants be scaled perfectly.
>>   - Image A draws to the image B
>>   - Image B draws to the window.
>>
>> When window is moving from the screen x1 to the screen x2 and back. How
>> to handle this situation?
>> In this case getResolutionVariant() can return
>>
>>
>> Related  discussion:
>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005580.html 
>>
>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005581.html 
>>
>
> How does calling getScaledInstance() deal with that?  Note the above 
> was simply to demonstrate the visibility of the interface, not to be a 
> complete implementation...
For example:
  - getScaledInstance() will be called() when image B will be painted to 
the window with scale x2.
  - Inside B.getScaledInstance() the user can create BufferedImage C
  - get graphics from C and set new render hint to IMAGE_SCALING_ON ans 
set scalex2.
  - Apply to C absolutely the same rendering  which was used in B.
  - getScaledInstance() will be called for A.

>
>             ...jim


-- 
Best regards, Sergey.



From james.graham at oracle.com  Thu Nov  7 07:01:33 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 06 Nov 2013 23:01:33 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527AF7C8.3000007@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>
	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>
	<527AB743.8050106@oracle.com> <527ACC42.6060001@oracle.com>
	<527ADA57.3020803@oracle.com> <527AEAE0.9000907@oracle.com>
	<527AF470.1050300@oracle.com> <527AF7C8.3000007@oracle.com>
Message-ID: <527B3ACD.8070708@oracle.com>

On 11/6/13 6:15 PM, Sergey Bylokhov wrote:
>>> In this example there is a problem. For example we have 2
>>> BufferedImages/ToolkiImagest A and B; Both wants be scaled perfectly.
>>>   - Image A draws to the image B
>>>   - Image B draws to the window.
>>>
>>> When window is moving from the screen x1 to the screen x2 and back. How
>>> to handle this situation?
>>> In this case getResolutionVariant() can return
>>>
>>>
>>> Related  discussion:
>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005580.html
>>>
>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005581.html
>>>
>>
>> How does calling getScaledInstance() deal with that?  Note the above
>> was simply to demonstrate the visibility of the interface, not to be a
>> complete implementation...
> For example:
>   - getScaledInstance() will be called() when image B will be painted to
> the window with scale x2.
>   - Inside B.getScaledInstance() the user can create BufferedImage C
>   - get graphics from C and set new render hint to IMAGE_SCALING_ON ans
> set scalex2.
>   - Apply to C absolutely the same rendering  which was used in B.
>   - getScaledInstance() will be called for A.

That is a radical departure from anything we've provided before and I 
don't see the necessity of it.

In particular, drawImage() has always been a "copy some pixels and 
return *now*" API.  Even when we had asynchronous loading of images it 
returned immediately if the image wasn't loaded, it didn't fork off or 
branch to another rendering process.  I really don't think we should be 
encouraging creating a new image inside a request to draw an image.

Nothing in those related discussions pointed at this either.  What I see 
the need for is:

- Toolkit images automatically supporting loading an @2x image if one is 
associated with the image they are requested to load.  I think they 
already do this and you just need a way for drawImage() to grab that 
image if necessary.

- All images to have an associated resolution or pixel scale.  @2x 
variants of images, if we ever expose them directly, would claim either 
a pixel scale of 2 or a DPI of ?144?, i.e. double the implicit dpi of 72 
that most images claim or that we've assumed by default.

- Destination drawables having a resolution or pixel scaling parameter 
associated with them that lets G2D decide if it is going to use hiDPI 
media or not.  It would request a HiDPI version of an image if needed, 
but this should be a simple "choose this set of pixels or that set" API, 
not an "I'll make you one right now" type of API.

- (not necessarily now, but soon) A way for someone to associate a 
higher DPI version of an image with an existing image and to query any 
alternate resolutions that we've already prepared (such as any @2x 
version that we've already loaded).  This could either be 
"Image.createMultiResImage(... list of images and resolutions ...)" or 
perhaps a convention for listing alternate images in the properties.

As far as the "images for buttons" example in the macosx-port thread, if 
those images are loaded using Toolkit.getImage() and there is an 
associated @2x image and we load that internally and make it available 
via some sort of (internal for now) MultiResImage interface like I 
described, then we've solved that problem for buttons.  It seemed like 
that was all that they were asking for there and I see no reason to 
create a "solve every hypothetical resolution issue" API now to meet 
that need...

				...jim


From linuxhippy at gmail.com  Thu Nov  7 12:03:48 2013
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Thu, 7 Nov 2013 13:03:48 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <D5309280-1D48-411E-8595-6F816F3B600E@tagtraum.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com>
	<D5309280-1D48-411E-8595-6F816F3B600E@tagtraum.com>
Message-ID: <CAFvQSYRaVcybAu8R=UuC_ksgYORtFCouiNeop+C_dOB-NU=GdA@mail.gmail.com>

Hi,

> PLEASE, PLEASE don't make us wait until JDK9 for something that worked really well in Apple's JDK6.

An internal API doesn't mean you can't use it with JDK8, only that it
is not part of the default API (which is more or less the same as with
Apple's JDK6).
However wouldn't it better to wait for an early JDK8 fetaure update,
instead of breaking the Image interface with an un-sound design
forever?

- Clemens


From Sergey.Bylokhov at oracle.com  Thu Nov  7 14:18:32 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 07 Nov 2013 18:18:32 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527B3ACD.8070708@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>
	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>
	<527AB743.8050106@oracle.com> <527ACC42.6060001@oracle.com>
	<527ADA57.3020803@oracle.com> <527AEAE0.9000907@oracle.com>
	<527AF470.1050300@oracle.com> <527AF7C8.3000007@oracle.com>
	<527B3ACD.8070708@oracle.com>
Message-ID: <527BA138.4030604@oracle.com>

On 07.11.2013 11:01, Jim Graham wrote:
> On 11/6/13 6:15 PM, Sergey Bylokhov wrote:
>>>> In this example there is a problem. For example we have 2
>>>> BufferedImages/ToolkiImagest A and B; Both wants be scaled perfectly.
>>>>   - Image A draws to the image B
>>>>   - Image B draws to the window.
>>>>
>>>> When window is moving from the screen x1 to the screen x2 and back. 
>>>> How
>>>> to handle this situation?
>>>> In this case getResolutionVariant() can return
>>>>
>>>>
>>>> Related  discussion:
>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005580.html 
>>>>
>>>>
>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005581.html 
>>>>
>>>>
>>>
>>> How does calling getScaledInstance() deal with that?  Note the above
>>> was simply to demonstrate the visibility of the interface, not to be a
>>> complete implementation...
>> For example:
>>   - getScaledInstance() will be called() when image B will be painted to
>> the window with scale x2.
>>   - Inside B.getScaledInstance() the user can create BufferedImage C
>>   - get graphics from C and set new render hint to IMAGE_SCALING_ON ans
>> set scalex2.
>>   - Apply to C absolutely the same rendering  which was used in B.
>>   - getScaledInstance() will be called for A.
>
> In particular, drawImage() has always been a "copy some pixels and 
> return *now*" API.  Even when we had asynchronous loading of images it 
> returned immediately if the image wasn't loaded, it didn't fork off or 
> branch to another rendering process.  I really don't think we should 
> be encouraging creating a new image inside a request to draw an image.
That's not true we already do some kind of of new image creation inside 
DrawImage.makeBufferedImage() for example;
>
> Nothing in those related discussions pointed at this either.  What I 
> see the need for is:
>
> - Toolkit images automatically supporting loading an @2x image if one 
> is associated with the image they are requested to load.  I think they 
> already do this and you just need a way for drawImage() to grab that 
> image if necessary.
I think no. They do not support.
>
> - All images to have an associated resolution or pixel scale.  @2x 
> variants of images, if we ever expose them directly, would claim 
> either a pixel scale of 2 or a DPI of ?144?, i.e. double the implicit 
> dpi of 72 that most images claim or that we've assumed by default.
That's why all related information: DPI,Scale, etc are not mentioned in 
the fix and api. just width and height are used, which is general and 
simple.
>
> - Destination drawables having a resolution or pixel scaling parameter 
> associated with them that lets G2D decide if it is going to use hiDPI 
> media or not.  It would request a HiDPI version of an image if needed, 
> but this should be a simple "choose this set of pixels or that set" 
> API, not an "I'll make you one right now" type of API.
It is already in the current version of the fix.
>
> - (not necessarily now, but soon) A way for someone to associate a 
> higher DPI version of an image with an existing image and to query any 
> alternate resolutions that we've already prepared (such as any @2x 
> version that we've already loaded).  This could either be 
> "Image.createMultiResImage(... list of images and resolutions ...)" or 
> perhaps a convention for listing alternate images in the properties.
It was intended to do not provide any mapping from some scale to the 
image, and leave it up to the user. So loading of the images will be 
lazily. Only if the image really needed it will be created and cached  
by the user.
>
> As far as the "images for buttons" example in the macosx-port thread, 
> if those images are loaded using Toolkit.getImage() and there is an 
> associated @2x image and we load that internally and make it available 
> via some sort of (internal for now) MultiResImage interface like I 
> described, then we've solved that problem for buttons.  It seemed like 
> that was all that they were asking for there and I see no reason to 
> create a "solve every hypothetical resolution issue" API now to meet 
> that need...
But we do not create any new API except two hints in Image and SG2D. 
Note that if compatibility is a problem from your point of view, we can 
control new hint in SG2D by some desktop property, and disable it by 
default. I think it can be useful to disable all hidpi support in this case.
>
>                 ...jim


-- 
Best regards, Sergey.



From james.graham at oracle.com  Thu Nov  7 20:30:58 2013
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 07 Nov 2013 12:30:58 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <D5309280-1D48-411E-8595-6F816F3B600E@tagtraum.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com>
	<D5309280-1D48-411E-8595-6F816F3B600E@tagtraum.com>
Message-ID: <527BF882.7030604@oracle.com>

How did Apple expose this in their JDK6?

For the record, I'm saying that getImage("myimage.[fmt]") can load the 
@2x image and drawImage() could use that when needed - all of that can 
happen without any public API.

But, for a developer to query a Toolkit Image loaded via getImage("...") 
to find out if it has an @2x variant, we can't do that via the existing 
getScaledInstance() method.  Also, if a developer programmatically 
develops a set of multi-res images, then getScaledInstance() is not the 
mechanism that should be used to supply those to drawImage().

What did Apple provide beyond getImage()/drawImage() support for @2x 
file/URL resources?

			...jim

On 11/7/13 2:46 AM, Hendrik Schreiber wrote:
>>
>>>
>>> The @2x mechanism should be based on different API.  I guess it would have to be internal-only for 8.0 and could be exposed to allow developers to call it and possibly to be a provider for it in JDK9...
>
>
> PLEASE, PLEASE don't make us wait until JDK9 for something that worked really well in Apple's JDK6.
>
> -hendrik
>


From james.graham at oracle.com  Thu Nov  7 21:01:20 2013
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 07 Nov 2013 13:01:20 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527BA138.4030604@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<527007AE.6000401@oracle.com>	<52728302.406@oracle.com>
	<52799DE1.8080906@oracle.com>	<527A41E1.9020103@oracle.com>
	<527AB743.8050106@oracle.com> <527ACC42.6060001@oracle.com>
	<527ADA57.3020803@oracle.com> <527AEAE0.9000907@oracle.com>
	<527AF470.1050300@oracle.com> <527AF7C8.3000007@oracle.com>
	<527B3ACD.8070708@oracle.com> <527BA138.4030604@oracle.com>
Message-ID: <527BFFA0.10406@oracle.com>

On 11/7/13 6:18 AM, Sergey Bylokhov wrote:
> On 07.11.2013 11:01, Jim Graham wrote:
>> On 11/6/13 6:15 PM, Sergey Bylokhov wrote:
>>>>> In this example there is a problem. For example we have 2
>>>>> BufferedImages/ToolkiImagest A and B; Both wants be scaled perfectly.
>>>>>   - Image A draws to the image B
>>>>>   - Image B draws to the window.
>>>>>
>>>>> When window is moving from the screen x1 to the screen x2 and back.
>>>>> How
>>>>> to handle this situation?
>>>>> In this case getResolutionVariant() can return
>>>>>
>>>>>
>>>>> Related  discussion:
>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005580.html
>>>>>
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005581.html
>>>>>
>>>>>
>>>>
>>>> How does calling getScaledInstance() deal with that?  Note the above
>>>> was simply to demonstrate the visibility of the interface, not to be a
>>>> complete implementation...
>>> For example:
>>>   - getScaledInstance() will be called() when image B will be painted to
>>> the window with scale x2.
>>>   - Inside B.getScaledInstance() the user can create BufferedImage C
>>>   - get graphics from C and set new render hint to IMAGE_SCALING_ON ans
>>> set scalex2.
>>>   - Apply to C absolutely the same rendering  which was used in B.
>>>   - getScaledInstance() will be called for A.
>>
>> In particular, drawImage() has always been a "copy some pixels and
>> return *now*" API.  Even when we had asynchronous loading of images it
>> returned immediately if the image wasn't loaded, it didn't fork off or
>> branch to another rendering process.  I really don't think we should
>> be encouraging creating a new image inside a request to draw an image.
> That's not true we already do some kind of of new image creation inside
> DrawImage.makeBufferedImage() for example;

That is pure pixel copying and uses only internal interfaces to move the 
pixels into a location that we can access from more code modules, we 
don't do callbacks and we don't publish anything there as 
developer-accessible public API.

>> Nothing in those related discussions pointed at this either.  What I
>> see the need for is:
>>
>> - Toolkit images automatically supporting loading an @2x image if one
>> is associated with the image they are requested to load.  I think they
>> already do this and you just need a way for drawImage() to grab that
>> image if necessary.
> I think no. They do not support.

Apologies.  I was confusing code I saw in this current fix with stuff 
that was already integrated.  What I'm getting at is that we already 
have a reasonable fix for that aspect of this list of action items, but 
it is exposed via the getScaledInstance() method here and that is not an 
acceptable way to convey that information to drawImage().

(While I haven't done an in depth code review of the toolkit image part 
of the current fix, the main issue I'm addressing here is just the part 
where those images are obtained by calling getScaledInstance()...)

>> - All images to have an associated resolution or pixel scale.  @2x
>> variants of images, if we ever expose them directly, would claim
>> either a pixel scale of 2 or a DPI of ?144?, i.e. double the implicit
>> dpi of 72 that most images claim or that we've assumed by default.
> That's why all related information: DPI,Scale, etc are not mentioned in
> the fix and api. just width and height are used, which is general and
> simple.

I've already mentioned issues with width and height, but the main point 
here is that they describe that they were intended to be used with a 
different resolution in some manner.  If it's just internal interface 
for now then the exact specification doesn't matter, but if and when we 
find a way to expose that, then we need to talk about what type of 
specifier we want to lock in at that point.

>> - Destination drawables having a resolution or pixel scaling parameter
>> associated with them that lets G2D decide if it is going to use hiDPI
>> media or not.  It would request a HiDPI version of an image if needed,
>> but this should be a simple "choose this set of pixels or that set"
>> API, not an "I'll make you one right now" type of API.
> It is already in the current version of the fix.

I realize that, I'm just outlining the parts of what is needed in the 
short term here.  Also, the API in the current fix that is used to 
request the HiDPI version of an image (getScaledInstance()) is not an 
acceptable implementation of this bullet item.

>> - (not necessarily now, but soon) A way for someone to associate a
>> higher DPI version of an image with an existing image and to query any
>> alternate resolutions that we've already prepared (such as any @2x
>> version that we've already loaded).  This could either be
>> "Image.createMultiResImage(... list of images and resolutions ...)" or
>> perhaps a convention for listing alternate images in the properties.
> It was intended to do not provide any mapping from some scale to the
> image, and leave it up to the user. So loading of the images will be
> lazily. Only if the image really needed it will be created and cached by
> the user.

Have the user's requested this flexibility?  All I've seen is that they 
want to supply retina-resolution images for buttons, which simply 
requires us to recognize and use @2x media files when we find them.

If such a mechanism has any laziness about it, then that laziness has to 
be done asynchronously wrt drawImage().  The drawImage method is 
specified to only use currently available pixels and return immediately 
(which is why it has the Observer parameter).  If a factory interface is 
needed (and currently I have not seen any requests specifically for that 
kind of functionality) then it would have to be something that is 
triggered/notified by the actions drawImage(), but drawImage() will not 
wait for it to complete its work.  Personally, I don't think this is 
really necessary.

>> As far as the "images for buttons" example in the macosx-port thread,
>> if those images are loaded using Toolkit.getImage() and there is an
>> associated @2x image and we load that internally and make it available
>> via some sort of (internal for now) MultiResImage interface like I
>> described, then we've solved that problem for buttons.  It seemed like
>> that was all that they were asking for there and I see no reason to
>> create a "solve every hypothetical resolution issue" API now to meet
>> that need...
> But we do not create any new API except two hints in Image and SG2D.
> Note that if compatibility is a problem from your point of view, we can
> control new hint in SG2D by some desktop property, and disable it by
> default. I think it can be useful to disable all hidpi support in this
> case.

The use of getScaledInstance() in this case far exceeded its original 
goals and created an interaction with those new hints.  Also drawImage 
has never called that method and should never call that method and if it 
is to be used as you describe here then we'd have to document that it 
will call a method that it never should have called in the first place 
and we'd have to document that overriding that method has new 
capabilities.  All of that documentation of new uses and interactions is 
public API.

Also, while the fix being proposed here was simply a way to get the 
internal toolkit images to return their @2x variants, the discussion 
clearly indicated that the getScaledInstance() method was intended to be 
the global solution I was referring to there.  I was saying that API to 
solve the issue of loading from multiple related media of different 
resolutions does not need to be constrained by the requirement that it 
also supports arbitrary creation of synthetic images at a variety of 
resolutions.  The former is needed now and is simple to provide, whereas 
I haven't seen any requests for the latter and it would need a fairly 
serious formal review about how it affects all aspects of our 
architecture...

			...jim


From james.graham at oracle.com  Thu Nov  7 21:05:38 2013
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 07 Nov 2013 13:05:38 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <9196D32E-5878-42DE-89AC-35D8A875FDFC@tagtraum.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com>
	<D5309280-1D48-411E-8595-6F816F3B600E@tagtraum.com>
	<527BF882.7030604@oracle.com>
	<9196D32E-5878-42DE-89AC-35D8A875FDFC@tagtraum.com>
Message-ID: <527C00A2.10309@oracle.com>

Thanks Hendrik, no apologies necessary.

I haven't been involved much in the MacOS port so my question was 
actually a legitimate call for information and not meant to criticize 
anyone's input.  I actually searched for a developer page that mentioned 
the MacOS port's retina handling and all I could find were references to 
setting the flag in your plist to enable retina - I didn't even find an 
official announcement that they would load the @2x for you, but I 
assumed that they would...

			...jim

On 11/7/13 12:41 PM, Hendrik Schreiber wrote:
>
> On Nov 7, 2013, at 9:30 PM, Jim Graham wrote:
>
>> How did Apple expose this in their JDK6?
>>
>> For the record, I'm saying that getImage("myimage.[fmt]") can load the @2x image and drawImage() could use that when needed - all of that can happen without any public API.
>>
>> But, for a developer to query a Toolkit Image loaded via getImage("...") to find out if it has an @2x variant, we can't do that via the existing getScaledInstance() method.  Also, if a developer programmatically develops a set of multi-res images, then getScaledInstance() is not the mechanism that should be used to supply those to drawImage().
>>
>> What did Apple provide beyond getImage()/drawImage() support for @2x file/URL resources?
>>
>> 			...jim
>
>
> Sorry guys, to cause confusion. I really should have read the whole thread - I haven't (also see http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-November/006209.html). Apple didn't have any public APIs beyond the Toolkit.getImage(...); method. It loaded the appropriate image, i.e. a @2x version if available.
>
> There wasn't anything else (not without hacking the private APIs -> http://blog.beatunes.com/2013/04/creating-retina-capable-images-with.html)
>
> So - Jim - again sorry,
>
> -hendrik
>


From james.graham at oracle.com  Thu Nov  7 21:19:28 2013
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 07 Nov 2013 13:19:28 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <52728302.406@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com>
Message-ID: <527C03E0.80609@oracle.com>



On 10/31/13 9:19 AM, Alexander Scherbatiy wrote:
>
>   Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8011059/webrev.04/

I'd like to point out a potential issue here with respect to ImageObserver.

Typically, when the ImageObserver is notified that the image loading is 
complete then it becomes irrelevant.  I'm not sure if we've documented 
this anywhere, and I've not done a code survey to see if anyone has ever 
created code based on that assumption, but it is true.  complete means 
the bits are all there and all calls to drawImage() forever-more will 
succeed without any problems.

The way that the scaled images are introduced here, there will be 
separate image loading for both the regular and @2x versions of the 
image.  A developer could render the image on one resolution display 
which would trigger the loading of that version of the image until it 
says it is complete, but the first time they load the image on a new 
display of a different resolution, then suddenly a new version of the 
image is needed and will not have been loaded - but that has never been 
possible before and so the developer could be caught off guard by this.

There would ideally be some way to make the status of the image only 
complete when all resolution variants of an image are loaded.

This gets more complicated with the MediaTracker object which is 
supposed to be used to load an image completely.  We don't explicitly 
say that if a MediaTracker says an image is complete that they can then 
ignore their observers, and there is already an issue with animated GIFs 
where we document that the tracker will claim they are done after their 
first frame is loaded, but I don't doubt that many programmers have 
written code to funnel all images through MT and then assume they don't 
need observers after that.  In fact, I believe that Swing has done 
things like that internally.  The question then is, what happens with MT 
and @2x images?

			...jim


From ebakke at MIT.EDU  Thu Nov  7 16:23:11 2013
From: ebakke at MIT.EDU (Eirik Bakke)
Date: Thu, 7 Nov 2013 16:23:11 +0000
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5278D385.2000205@oracle.com>
Message-ID: <52CAC6A8CE5503408F3482C89035832809C4B16E@OC11EXPO27.exchange.mit.edu>

Just passing by...

Will retina-enabled Image objects work with Toolkit.createCustomCursor [1]
under this patch?

(I have a spreadsheet application that requires an Excel-style "plus"
cursor when the user hovers over it, and I'd like to supply a
retina-enabled cursor image as well.)

-- Eirik

[1] 
http://docs.oracle.com/javase/6/docs/api/java/awt/Toolkit.html#createCustom
Cursor(java.awt.Image, java.awt.Point, java.lang.String)

On 11/5/13, 6:16 AM, "Alexander Scherbatiy"
<alexandr.scherbatiy at oracle.com> wrote:

>
>    Thank you for the review.
>
>   Could you look at the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>
>   - URL is parsed to protocol, host, port, and path parts in the
>LWCToolkit class.
>      I checked that URL(protocol, host, port, file) constructor
>correctly handles -1 port value.
>   - Only last file name after last '/' in the URL path  is converted to
>@2x name
>   - Tests that check correct URL and path translation to @2x names are
>added to the ScalableImageTest
>
>   Thanks,
>   Alexandr.
>
>
>On 11/1/2013 12:46 AM, Peter Levart wrote:
>>
>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>> implementation in ScalableToolkitImage works perfectly for URLs like
>>>> this:
>>>>
>>>> http://www.exampmle.com/dir/image
>>>>
>>>> In this case it will try to find 2x image here:
>>>>
>>>> http://www.example at 2x.com/dir/image
>>>>
>>>> which doesn't look correct.
>>>        Fixed. Only path part of a URL is converted to path2x.
>>
>> Hi Alexander,
>>
>> URLs like this:
>>
>> http://www.example.com/dir.ext/image
>>
>> will still be translated to:
>>
>> http://www.example.com/dir at 2x.ext/image
>>
>>
>> I think you need to search for last '.' after the last  '/' in the
>> getScaledImageName();
>>
>>
>> Also the following code has some additional bugs:
>>
>>   853         static Image toScalableImage(Image image, URL url) {
>>   854
>>   855             if (url != null && !url.toString().contains("@2x")
>>   856                     && !(image instanceof ScalableToolkitImage)) {
>>   857                 String protocol = url.getProtocol();
>>   858                 String host = url.getHost();
>>   859                 String file = url.getPath();
>>   860                 String file2x =*host +*getScaledImageName(file);
>>   861                 try {
>>   862                     URL url2x = new URL(protocol, host, file2x);
>>   863                     url2x.openStream();
>>   864                     return new ScalableToolkitImage(image,
>>getDefaultToolkit().getImage(url2x));
>>   865                 } catch (Exception ignore) {
>>   866                 }
>>   867             }
>>   868             return image;
>>   869         }
>>
>> Why are you prepending *host* to getScaledImageName(file) in line 860?
>> Let's take the following URL for example:
>>
>> http://www.example.com/dir/image.jpg
>>
>> protocol = "http"
>> host = "www.example.com"
>> file = "/dir/image.jpg"
>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>> url2x = URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>
>>
>> You are missing a part in URL (de)construction - the optional port!
>> For example in the following URL:
>>
>> http://www.example.com:8080/dir/image.jpg
>>
>> You should extract the port from original URL and use it in new URL
>> construction if present (!= -1).
>>
>>
>> I would also close the stream explicitly after probing for existence
>> of resource rather than delegating to GC which might not be promptly
>> and can cause resource exhaustion (think of MAX. # of open file
>> descriptors):
>>
>>         try (InputStream probe = url.openStream()) {}
>>
>>
>>
>> Regards, Peter
>>
>>
>



From hs at tagtraum.com  Thu Nov  7 10:46:34 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 7 Nov 2013 11:46:34 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
	[macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527A41E1.9020103@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com>
Message-ID: <D5309280-1D48-411E-8595-6F816F3B600E@tagtraum.com>

> 
>> 
>> The @2x mechanism should be based on different API.  I guess it would have to be internal-only for 8.0 and could be exposed to allow developers to call it and possibly to be a provider for it in JDK9...


PLEASE, PLEASE don't make us wait until JDK9 for something that worked really well in Apple's JDK6.

-hendrik

From hs at tagtraum.com  Thu Nov  7 12:37:17 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 7 Nov 2013 13:37:17 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
	[macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <CAFvQSYRaVcybAu8R=UuC_ksgYORtFCouiNeop+C_dOB-NU=GdA@mail.gmail.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com>
	<D5309280-1D48-411E-8595-6F816F3B600E@tagtraum.com>
	<CAFvQSYRaVcybAu8R=UuC_ksgYORtFCouiNeop+C_dOB-NU=GdA@mail.gmail.com>
Message-ID: <EC8D7C7D-6A51-4E21-9D68-0ADF04220B52@tagtraum.com>

On Nov 7, 2013, at 1:03 PM, Clemens Eisserer wrote:

>> PLEASE, PLEASE don't make us wait until JDK9 for something that worked really well in Apple's JDK6.
> 
> An internal API doesn't mean you can't use it with JDK8, only that it
> is not part of the default API (which is more or less the same as with
> Apple's JDK6).

Admittedly, I didn't read through the whole thread ? moving the @2x naming to JDK9 just caught my eye.

> However wouldn't it better to wait for an early JDK8 fetaure update,
> instead of breaking the Image interface with an un-sound design
> forever?

Right, I forgot, Java is like Windows 32. Things stick around forever. ;-)

No, but seriously, proper Retina support is essential for the desktop. You can't ship a consumer application these days that does not support it.
To me it's one of the biggest obstacles for Java7 adoption on OS X.

As long as I have a way to create or load HiDPI images that I can use throughout my application (say e.g. in a JLabel) in Java8 or better Java7, I'm happy. If it's compatible with the Apple Java6 way of doing things (i.e. @2x), I'm even happier.

That's pretty much all I intended to convey with my plea above.

Cheers,

-hendrik

From hs at tagtraum.com  Thu Nov  7 20:41:30 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 7 Nov 2013 21:41:30 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
	[macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527BF882.7030604@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com>
	<D5309280-1D48-411E-8595-6F816F3B600E@tagtraum.com>
	<527BF882.7030604@oracle.com>
Message-ID: <9196D32E-5878-42DE-89AC-35D8A875FDFC@tagtraum.com>


On Nov 7, 2013, at 9:30 PM, Jim Graham wrote:

> How did Apple expose this in their JDK6?
> 
> For the record, I'm saying that getImage("myimage.[fmt]") can load the @2x image and drawImage() could use that when needed - all of that can happen without any public API.
> 
> But, for a developer to query a Toolkit Image loaded via getImage("...") to find out if it has an @2x variant, we can't do that via the existing getScaledInstance() method.  Also, if a developer programmatically develops a set of multi-res images, then getScaledInstance() is not the mechanism that should be used to supply those to drawImage().
> 
> What did Apple provide beyond getImage()/drawImage() support for @2x file/URL resources?
> 
> 			...jim


Sorry guys, to cause confusion. I really should have read the whole thread - I haven't (also see http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-November/006209.html). Apple didn't have any public APIs beyond the Toolkit.getImage(...); method. It loaded the appropriate image, i.e. a @2x version if available.

There wasn't anything else (not without hacking the private APIs -> http://blog.beatunes.com/2013/04/creating-retina-capable-images-with.html)

So - Jim - again sorry,

-hendrik

From hs at tagtraum.com  Thu Nov  7 21:11:36 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 7 Nov 2013 22:11:36 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
	[macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <527C00A2.10309@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com>
	<52728302.406@oracle.com> <52799DE1.8080906@oracle.com>
	<527A41E1.9020103@oracle.com>
	<D5309280-1D48-411E-8595-6F816F3B600E@tagtraum.com>
	<527BF882.7030604@oracle.com>
	<9196D32E-5878-42DE-89AC-35D8A875FDFC@tagtraum.com>
	<527C00A2.10309@oracle.com>
Message-ID: <01085110-6540-4D1A-B16A-478029245AAF@tagtraum.com>


On Nov 7, 2013, at 10:05 PM, Jim Graham wrote:

> Thanks Hendrik, no apologies necessary.
> 
> I haven't been involved much in the MacOS port so my question was actually a legitimate call for information and not meant to criticize anyone's input.  I actually searched for a developer page that mentioned the MacOS port's retina handling and all I could find were references to setting the flag in your plist to enable retina - I didn't even find an official announcement that they would load the @2x for you, but I assumed that they would...


This http://lists.apple.com/archives/java-dev/2012/Jun/msg00069.html is probably the closest Apple ever came to an announcement/documentation of Retina support.

-hendrik



From dmitry.x.ginzburg at oracle.com  Fri Nov  8 08:40:09 2013
From: dmitry.x.ginzburg at oracle.com (Dmitry Ginzburg)
Date: Fri, 08 Nov 2013 12:40:09 +0400
Subject: [OpenJDK 2D-Dev] <2D Dev> [8] Review Request: JDK-8025235
 [javadoc] fix some errors in 2D
In-Reply-To: <52713614.1050408@oracle.com>
References: <52713614.1050408@oracle.com>
Message-ID: <527CA369.6000806@oracle.com>

Colleagues,

friendly reminder.
Back in early October I did all proposed changes; could you please
review this third version of doclint fix?

Thanks,
-Dmitry

30.10.2013 20:38, Dmitry Ginzburg wrote:
> Hi guys
> I haven't got any review from you on this issue. Can you please review it?
> For some issue, my e-mail have changed todmitry.x.ginzburg at oracle.com
> Thanks, Dmitry
> *
> Dmitry Ginzburg*  dmitry.ginzburg at oracle.com    <mailto:2d-dev%40openjdk.java.net?Subject=%5BOpenJDK%202D-Dev%5D%20%3C2D%20Dev%3E%20%5B8%5D%20Review%20Request%3A%20JDK-8025235%0A%20%5Bjavadoc%5D%20fix%20some%20errors%20in%202D&In-Reply-To=524EE4DB.8010602%40oracle.com>
> /Tue Oct 15 06:02:58 PDT 2013/
>
> See new webrev:http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.02/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.02/>  
> <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.02/>
> Some changes are deleted, because they're fixed by someone but me
>
> 04.10.2013 19:55, Phil Race wrote:
> >/  Hi,
> />/
> />/  A few places you used {@code that is not code} : ie PageAttributes for
> />/  the &
> />/  and Line2D.Float() constructor and  in MultipleMaster are the ones I
> />/  spotted
> />/  probably aren't appropriate as they aren't code, and the {@code ..}
> />/  will use
> />/  a fixed width font. So one char will be in a different font.
> />/  As I suggested in PageAttributes just use "and", there's no reason it
> />/  has to
> />/  be an ampersand.
> />/
> />/  -phil.
> />/
> />/  On 10/4/2013 5:59 AM, Dmitry Ginzburg wrote:
> />>/  Hi, Phil
> />>/
> />>/  I renewed webrev against your issues:
> />>/  http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.01/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.01/>  
> />>/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.01/>
> />>/
> />>/  Thanks,
> />>/  -Dmitry
> />>/
> />>/  03.10.2013 08:41, Phil Race wrote:
> />>>/  1. This webrev is not against the 2D forest. Please re-generate
> />>>/  against 2D.
> />>>/
> />>>/  2.
> />>>/  /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/GraphicsConfiguration.java:84:
> />>>/  error: malformed HTML
> />>>/     When you have < & > chars in code the preferred solution uses
> />>>/  {@code .. }  like this :
> />>>/  http://cr.openjdk.java.net/~prr/8022175/src/share/classes/javax/print/ServiceUI.java.sdiff.html  <http://cr.openjdk.java.net/%7Eprr/8022175/src/share/classes/javax/print/ServiceUI.java.sdiff.html>  
> />>>/
> />>>/
> />>>/  3. Same as above for GraphicsDevice
> />>>/
> />>>/  4. Same as above for MediaTracker (it'll fix all 3 issues)
> />>>/
> />>>/  5. I think we should change all 12 or so of these to the word "and"
> />>>/
> />>>/  6. Rectangle : same as 2
> />>>/
> />>>/  7. LineBreakMeasurer : same again in all locations
> />>>/
> />>>/  8. {@code .. } should fix this too
> />>>/
> />>>/  9. LIne2D 626: {@code true} would be better here too
> />>>/
> />>>/  10. PrinterJob: {@code .. } again
> />>>/
> />>>/  Make sure you verify by re-running doclint on the fixed repo.
> />>>/
> />>>/  That's all.
> />>>/
> />>>/  -phil.
> />>>/
> />>>/  On 9/26/13 7:21 AM, Dmitry Ginzburg wrote:
> />>>>/  Hello, 2D Team.
> />>>>/
> />>>>/  Please review the fix for the following issue:
> />>>>/  https://bugs.openjdk.java.net/browse/JDK-8025235
> />>>>/  The fix is available at:
> />>>>/  http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.00/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.00/>
> />>>>/
> />>>>/  This is the fix for javadoc errors, on which doclint was showing
> />>>>/  some issues.
> />>>>/
> />>>>/  The patch contains only simple markup fixes; no changes/fixes in
> />>>>/  documentation text; the specification itself wasn't changed.
> />>>>/
> />>>>/  Thanks,
> />>>>/  -Dmitry
> />>>/
> />>/
> />>/
> />>/  --
> />>/  Dmitry Ginzburg, FXSQE team member
> />/
> /

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131108/8ef61075/attachment.html>

From philip.race at oracle.com  Fri Nov  8 22:29:27 2013
From: philip.race at oracle.com (Phil Race)
Date: Fri, 08 Nov 2013 14:29:27 -0800
Subject: [OpenJDK 2D-Dev] RFR: Fix for 8027541: Fully transparent jframe
	becomes black.
Message-ID: <527D65C7.9070707@oracle.com>

http://cr.openjdk.java.net/~prr/8027541/

In the case where there is an alpha color on the window, the
X11 pipeline looks at the color model of the GraphicsConfiguration
and upgrades the surface to one with alpha. This makes the Xrender
pipeline do the same. SQE test failure, so no regression test needed
in this case.

-phil.


From lana.steuck at oracle.com  Sat Nov  9 07:04:24 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 09 Nov 2013 07:04:24 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jaxws: 2 new changesets
Message-ID: <20131109070435.B7018624AD@hg.openjdk.java.net>

Changeset: e126d8eca69b
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxws/rev/e126d8eca69b

Added tag jdk8-b114 for changeset 9ad289610fc6

! .hgtags

Changeset: 587560c222a2
Author:    cl
Date:      2013-11-07 08:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxws/rev/587560c222a2

Added tag jdk8-b115 for changeset e126d8eca69b

! .hgtags



From lana.steuck at oracle.com  Sat Nov  9 07:04:24 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 09 Nov 2013 07:04:24 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/nashorn: 30 new changesets
Message-ID: <20131109070500.D625D624AF@hg.openjdk.java.net>

Changeset: f109bb255b80
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/f109bb255b80

Added tag jdk8-b114 for changeset 79f7b79bf97b

! .hgtags

Changeset: b01a10c7c7c2
Author:    attila
Date:      2013-10-17 12:38 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/b01a10c7c7c2

8026161: Don't narrow floating-point literals in the lexer
Reviewed-by: hannesw, jlaskey

! src/jdk/nashorn/internal/parser/Lexer.java
! src/jdk/nashorn/internal/runtime/JSType.java
+ test/script/basic/JDK-8026161.js
+ test/script/basic/JDK-8026161.js.EXPECTED
! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java

Changeset: a2065f67857c
Author:    hannesw
Date:      2013-10-17 17:33 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/a2065f67857c

8026701: Array.prototype.splice is slow on dense arrays
Reviewed-by: lagergren, sundar, jlaskey

! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java
! test/examples/array-micro.js
+ test/script/basic/JDK-8026701.js
+ test/script/basic/JDK-8026701.js.EXPECTED

Changeset: 66d27c77b455
Author:    hannesw
Date:      2013-10-18 12:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/66d27c77b455

8026805: Array.prototype.length doesn't work as expected
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeJSAdapter.java
+ test/script/basic/JDK-8026805.js

Changeset: b5b4c98b072b
Author:    sundar
Date:      2013-10-18 18:26 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/b5b4c98b072b

Merge


Changeset: d8aa87d292eb
Author:    hannesw
Date:      2013-10-18 22:42 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/d8aa87d292eb

8026858: Array length does not handle defined properties correctly
Reviewed-by: jlaskey

! src/jdk/nashorn/internal/codegen/Lower.java
! src/jdk/nashorn/internal/runtime/PropertyMap.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
+ test/script/basic/JDK-8026858.js

Changeset: 612886fe324d
Author:    sundar
Date:      2013-10-21 10:09 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/612886fe324d

Merge


Changeset: f22742d5daa3
Author:    kshefov
Date:      2013-10-21 13:31 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/f22742d5daa3

8026871: NASHORN TEST: Enable possibility to test Nashorn use of JavaFX canvas.
Reviewed-by: jlaskey, sundar

! make/build.xml
! make/project.properties
+ test/script/jfx.js
+ test/script/jfx/flyingimage.js
+ test/script/jfx/flyingimage/flyingimage.png
+ test/script/jfx/flyingimage/golden/linux.png
+ test/script/jfx/flyingimage/golden/macosx.png
+ test/script/jfx/flyingimage/golden/windows.png
+ test/script/jfx/kaleidoscope.js
+ test/script/jfx/kaleidoscope/golden/linux.png
+ test/script/jfx/kaleidoscope/golden/macosx.png
+ test/script/jfx/kaleidoscope/golden/windows.png

Changeset: d8d5b7919c57
Author:    sundar
Date:      2013-10-22 14:27 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/d8d5b7919c57

8027016: Array.prototype.indexOf should return -1 when array is of length zero
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8027016.js

Changeset: 6d339d98074e
Author:    hannesw
Date:      2013-10-22 11:12 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/6d339d98074e

8027015: AutoCloseable no longer implements @FunctionalInterface
Reviewed-by: lagergren, sundar

! test/script/basic/NASHORN-397.js

Changeset: d24a4fabdce1
Author:    hannesw
Date:      2013-10-22 11:31 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/d24a4fabdce1

8026955: for-in should convert primitive values to object
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
+ test/script/basic/JDK-8026955.js
+ test/script/basic/JDK-8026955.js.EXPECTED

Changeset: 360761288b38
Author:    sundar
Date:      2013-10-22 17:38 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/360761288b38

8027024: String.prototype.charAt and charCodeAt do not evaluate 'self' and 'pos' arguments in right order
Reviewed-by: jlaskey, attila, lagergren

! src/jdk/nashorn/internal/objects/NativeString.java
! src/overview.html
+ test/script/basic/JDK-8027024.js
+ test/script/basic/JDK-8027024.js.EXPECTED

Changeset: d04028e6b624
Author:    sundar
Date:      2013-10-22 17:47 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/d04028e6b624

Merge


Changeset: 0ecbc0188b64
Author:    attila
Date:      2013-10-22 16:43 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/0ecbc0188b64

8027031: complete merging of loads and converts
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/codegen/BranchOptimizer.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java

Changeset: 6f19eb443a47
Author:    attila
Date:      2013-10-22 17:52 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/6f19eb443a47

8027037: Make ScriptObjectMirror conversions work for any JSObject
Reviewed-by: jlaskey, lagergren, sundar

! src/jdk/nashorn/api/scripting/JSObject.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java

Changeset: eae4e4c1f613
Author:    sundar
Date:      2013-10-22 22:04 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/eae4e4c1f613

8027020: [regression] java.lang.VerifyError: Bad type on operand stack
Reviewed-by: jlaskey, attila

! src/jdk/nashorn/internal/runtime/ScriptLoader.java

Changeset: 734f71f8a2c3
Author:    sundar
Date:      2013-10-22 22:12 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/734f71f8a2c3

Merge


Changeset: 5df55690fd5b
Author:    sundar
Date:      2013-10-23 17:30 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/5df55690fd5b

8027128: jdk.nashorn.api.scripting.JSObject should be an interface
Reviewed-by: hannesw, attila, jlaskey

+ src/jdk/nashorn/api/scripting/AbstractJSObject.java
! src/jdk/nashorn/api/scripting/JSObject.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java
! test/script/basic/JDK-8024847.js
! test/script/basic/JDK-8024847.js.EXPECTED
! test/src/jdk/nashorn/api/scripting/PluggableJSObjectTest.java
! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java

Changeset: f31ee3a2847d
Author:    sundar
Date:      2013-10-23 20:15 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/f31ee3a2847d

8027150: ScriptObjectListAdapter won't work as expected
Reviewed-by: jlaskey, attila

! src/jdk/nashorn/internal/runtime/ListAdapter.java
- src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java

Changeset: 640c1854f742
Author:    sundar
Date:      2013-10-23 20:21 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/640c1854f742

Merge

- src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java

Changeset: 767e85d2a1b3
Author:    lana
Date:      2013-10-28 12:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/767e85d2a1b3

Merge


Changeset: 7985ec3782b5
Author:    hannesw
Date:      2013-10-25 10:20 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/7985ec3782b5

8027042: Evaluation order for binary operators can be improved
Reviewed-by: lagergren, jlaskey, attila

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/types/Type.java
! src/jdk/nashorn/internal/ir/BinaryNode.java
! src/jdk/nashorn/internal/ir/Expression.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/ir/LiteralNode.java
! src/jdk/nashorn/internal/ir/TernaryNode.java
! src/jdk/nashorn/internal/ir/UnaryNode.java
+ test/script/basic/JDK-8027042.js
+ test/script/basic/JDK-8027042.js.EXPECTED

Changeset: 71cfb21c68dc
Author:    hannesw
Date:      2013-10-25 15:21 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/71cfb21c68dc

8027301: Optimizations for Function.prototype.apply
Reviewed-by: jlaskey

! src/jdk/nashorn/internal/runtime/CompiledFunctions.java
! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java

Changeset: 406f2b672937
Author:    jlaskey
Date:      2013-10-29 10:40 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/406f2b672937

Merge


Changeset: adab2c628923
Author:    jlaskey
Date:      2013-10-29 14:22 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/adab2c628923

8027447: The wrong string buffer is specified for stderr in $EXEC
Reviewed-by: lagergren, sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java

Changeset: 645197151cc3
Author:    jlaskey
Date:      2013-10-30 11:28 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/645197151cc3

8027532: nashorn should only use jdk8 apis in the compact1 profile
Reviewed-by: sundar, lagergren, hannesw
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java

Changeset: a002c1bb88f9
Author:    sundar
Date:      2013-10-30 20:09 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/a002c1bb88f9

8027562: eval should load second and subsequent arguments for side effect
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
+ test/script/basic/JDK-8027562.js
+ test/script/basic/JDK-8027562.js.EXPECTED

Changeset: 5ce78473d6c3
Author:    sundar
Date:      2013-10-31 12:50 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/5ce78473d6c3

Merge


Changeset: f0d3ac2474ee
Author:    lana
Date:      2013-10-31 16:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/f0d3ac2474ee

Merge

- src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java

Changeset: 0fb1a427fbf6
Author:    cl
Date:      2013-11-07 08:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/0fb1a427fbf6

Added tag jdk8-b115 for changeset f0d3ac2474ee

! .hgtags



From lana.steuck at oracle.com  Sat Nov  9 07:04:24 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 09 Nov 2013 07:04:24 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jaxp: 7 new changesets
Message-ID: <20131109070450.ECCA1624AE@hg.openjdk.java.net>

Changeset: d3b6da1b3e25
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/d3b6da1b3e25

Added tag jdk8-b114 for changeset 1b1e12117fe2

! .hgtags

Changeset: 390e94b9a852
Author:    joehw
Date:      2013-10-24 13:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/390e94b9a852

8004476: XSLT Extension Functions Don't Work in WebStart
Reviewed-by: dfuchs, lancea, alanb

! src/com/sun/org/apache/xalan/internal/XalanConstants.java
+ src/com/sun/org/apache/xalan/internal/utils/FeatureManager.java
+ src/com/sun/org/apache/xalan/internal/utils/FeaturePropertyBase.java
! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java
! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java
! src/com/sun/org/apache/xalan/internal/xsltc/cmdline/Compile.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java
! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java
! src/com/sun/org/apache/xpath/internal/jaxp/JAXPExtensionsProvider.java
! src/com/sun/org/apache/xpath/internal/jaxp/XPathExpressionImpl.java
! src/com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java
! src/com/sun/org/apache/xpath/internal/jaxp/XPathImpl.java

Changeset: 96562bf197f2
Author:    lana
Date:      2013-10-28 12:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/96562bf197f2

Merge


Changeset: 1af33ab1bc58
Author:    joehw
Date:      2013-10-29 14:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/1af33ab1bc58

8027484: Implementation error in SAX2DOM.java
Reviewed-by: alanb, lancea

! src/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2DOM.java

Changeset: 04778b00286a
Author:    joehw
Date:      2013-10-30 08:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/04778b00286a

8024378: StAX parser shall support JAXP properties
Reviewed-by: dfuchs, lancea

! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java
! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java

Changeset: f610fd46463e
Author:    lana
Date:      2013-10-31 16:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/f610fd46463e

Merge


Changeset: e757eb9aee3d
Author:    cl
Date:      2013-11-07 08:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/e757eb9aee3d

Added tag jdk8-b115 for changeset f610fd46463e

! .hgtags



From lana.steuck at oracle.com  Sat Nov  9 07:04:38 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 09 Nov 2013 07:04:38 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/langtools: 33 new changesets
Message-ID: <20131109070629.7EB21624B0@hg.openjdk.java.net>

Changeset: fea486d30d41
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/fea486d30d41

Added tag jdk8-b114 for changeset 850d2602ae98

! .hgtags

Changeset: 7af634b1fc5b
Author:    darcy
Date:      2013-10-17 19:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/7af634b1fc5b

8026838: Fix new doclint issues in javax.annotation.processing
Reviewed-by: jjg

! src/share/classes/javax/annotation/processing/Processor.java

Changeset: 7de97abc4a5c
Author:    jjg
Date:      2013-10-18 15:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/7de97abc4a5c

8026749: Missing LV table in lambda bodies
Reviewed-by: vromero, jlahoda

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/lambda/LocalVariableTable.java

Changeset: 130b8c0e570e
Author:    bpatel
Date:      2013-10-18 16:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/130b8c0e570e

8026567: Use meaningful style names for strong and italic styles.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeFieldWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
! test/com/sun/javadoc/AuthorDD/AuthorDD.java
! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java
! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java
! test/com/sun/javadoc/testClassTree/TestClassTree.java
! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java
! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java
! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java
! test/com/sun/javadoc/testHref/TestHref.java
! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java
! test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java
! test/com/sun/javadoc/testIndex/TestIndex.java
! test/com/sun/javadoc/testInterface/TestInterface.java
! test/com/sun/javadoc/testJavaFX/TestJavaFX.java
! test/com/sun/javadoc/testLegacyTaglet/Check.java
! test/com/sun/javadoc/testLinkOption/TestLinkOption.java
! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java
! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java
! test/com/sun/javadoc/testNavigation/TestNavigation.java
! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java
! test/com/sun/javadoc/testPackageDeprecation/TestPackageDeprecation.java
! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java
! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java
! test/com/sun/javadoc/testProfiles/TestProfiles.java
! test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java
! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java
! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java
! test/com/sun/javadoc/testSimpleTagInherit/TestSimpleTagInherit.java
! test/com/sun/javadoc/testSinceTag/TestSinceTag.java
! test/com/sun/javadoc/testTagOutput/TestTagOutput.java
! test/com/sun/javadoc/testTaglets/TestTaglets.java
! test/com/sun/javadoc/testTaglets/taglets/Foo.java
! test/com/sun/javadoc/testThrowsHead/TestThrowsHead.java
! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java
! test/com/sun/javadoc/testValueTag/TestValueTag.java

Changeset: c4292590fc70
Author:    vromero
Date:      2013-10-19 17:43 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/c4292590fc70

8024809: javac, some lambda programs are rejected by flow analysis
Reviewed-by: jjg, dlsmith

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! test/tools/javac/lambda/8016081/T8016081.java
! test/tools/javac/lambda/LambdaExpr13.java
+ test/tools/javac/lambda/T8024809/SelfInitializerInLambdaTesta.java
+ test/tools/javac/lambda/T8024809/SelfInitializerInLambdaTesta.out
+ test/tools/javac/lambda/T8024809/SelfInitializerInLambdaTestb.java
+ test/tools/javac/lambda/T8024809/SelfInitializerInLambdaTestb.out
! test/tools/javac/lambda/TestSelfRef.java

Changeset: e5d3cd43c85e
Author:    jjg
Date:      2013-10-20 12:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/e5d3cd43c85e

8025109: Better encapsulation for AnnotatedType
Reviewed-by: jjg
Contributed-by: wdietl at gmail.com

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java

Changeset: ae4f5cb78ebd
Author:    jjg
Date:      2013-10-20 12:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/ae4f5cb78ebd

8026791: wrong type_path encoded for method_return on an inner class constructor
Reviewed-by: jjg
Contributed-by: wdietl at gmail.com

! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java

Changeset: 399c738e5103
Author:    ksrini
Date:      2013-10-20 12:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/399c738e5103

8026931: MethodParameters tests failing on Windows
Reviewed-by: jjg, vromero

! test/tools/javac/MethodParameters/Tester.java

Changeset: 9f876bd43f55
Author:    vromero
Date:      2013-10-21 15:55 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/9f876bd43f55

8026956: test tools/javac/lambda/TargetType58.java is failing after a libs change
Reviewed-by: jfranck

! test/tools/javac/lambda/TargetType58.java

Changeset: b82982ac3ca2
Author:    darcy
Date:      2013-10-21 15:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/b82982ac3ca2

8026984: Clarity intended use of jdk.Exported
Reviewed-by: psandoz, mr, alanb

! src/share/classes/jdk/Exported.java

Changeset: ac839d6f4953
Author:    jfranck
Date:      2013-10-22 03:36 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/ac839d6f4953

8026855: AnnoConstruct.getAnnotationsByType includes inherited indirectly present annotations even when containee type is not inheritable
Summary: In AnnoConstruct.getAnnotationByType() check that the annotation sought after is inherited before looking on supertypes.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/AnnoConstruct.java
+ test/tools/javac/processing/model/element/TestNonInherited.java

Changeset: 87c950ea88be
Author:    ksrini
Date:      2013-10-21 20:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/87c950ea88be

8026758: Inefficient code in LambdaToMethod
Reviewed-by: jjg, jlahoda, rfield

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java

Changeset: f003f09144ff
Author:    jfranck
Date:      2013-10-22 10:08 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/f003f09144ff

8026857: AnnoConstruct.getAnnotationsByType does not search supertype for inherited annotations if @SomeContainer({}) is present
Summary: An empty container should not stop javac from looking at supertypes for inherited repeating annotations
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/AnnoConstruct.java
+ test/tools/javac/processing/model/element/TestEmptyContainer.java

Changeset: 963c57175e40
Author:    vromero
Date:      2013-10-22 13:54 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/963c57175e40

8025290: javac implicit versus explicit lambda compilation error
Reviewed-by: jjg, dlsmith

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/util/JavacMessages.java
+ test/tools/javac/lambda/T8025290/ExplicitVSImplicitLambdaTest.java

Changeset: 6cd16d8ed2b9
Author:    rfield
Date:      2013-10-22 16:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/6cd16d8ed2b9

8023668: Desugar serializable lambda bodies using more robust naming scheme
Summary: lambda / bridged method-reference naming overhaul
Reviewed-by: ksrini, briangoetz

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! test/tools/javac/MethodParameters/LambdaTest.out
! test/tools/javac/T8019486/WrongLVTForLambdaTest.java
+ test/tools/javac/lambda/lambdaNaming/TestSerializedLambdaNameStability.java
+ test/tools/javac/lambda/lambdaNaming/after/TESTNameOfCapturedArgs.java
+ test/tools/javac/lambda/lambdaNaming/after/TESTOrderOfCapturedArgs.java
+ test/tools/javac/lambda/lambdaNaming/after/TESTTargetName.java
+ test/tools/javac/lambda/lambdaNaming/after/TESTTargetType.java
+ test/tools/javac/lambda/lambdaNaming/after/TESTTypesOfCapturedArgs.java
+ test/tools/javac/lambda/lambdaNaming/after/TESTVariableAssignmentTarget.java
+ test/tools/javac/lambda/lambdaNaming/before/TESTNameOfCapturedArgs.java
+ test/tools/javac/lambda/lambdaNaming/before/TESTOrderOfCapturedArgs.java
+ test/tools/javac/lambda/lambdaNaming/before/TESTTargetName.java
+ test/tools/javac/lambda/lambdaNaming/before/TESTTargetType.java
+ test/tools/javac/lambda/lambdaNaming/before/TESTTypesOfCapturedArgs.java
+ test/tools/javac/lambda/lambdaNaming/before/TESTVariableAssignmentTarget.java

Changeset: 351d6808c1a5
Author:    jjg
Date:      2013-10-22 17:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/351d6808c1a5

8027119: Cleanup javadoc comments for taglet API
Reviewed-by: mduigou

! src/share/classes/com/sun/javadoc/Tag.java

Changeset: 41d3ffca22ff
Author:    jjg
Date:      2013-10-22 17:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/41d3ffca22ff

Merge


Changeset: b05db8c815e8
Author:    jlahoda
Date:      2013-10-23 07:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/b05db8c815e8

8026508: Invokedynamic instructions don't get line number table entries
Summary: Setting or correcting positions for many trees produced by LambdaToMethod.
Reviewed-by: vromero, rfield

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/T8019486/WrongLNTForLambdaTest.java
- test/tools/javac/T8019486/WrongLVTForLambdaTest.java

Changeset: 32ea6ccb7607
Author:    rfield
Date:      2013-10-23 10:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/32ea6ccb7607

8022720: Method refeerences - private method should be accessible (nested classes)
Reviewed-by: jjg, ksrini

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/privateMethodReferences/MethodInvoker.java
+ test/tools/javac/lambda/privateMethodReferences/MethodSupplier.java
+ test/tools/javac/lambda/privateMethodReferences/ThirdClass.java

Changeset: 8746caa5cf80
Author:    bpatel
Date:      2013-10-23 13:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/8746caa5cf80

8026770: javadoc creates invalid HTML in profile summary pages
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java
! test/com/sun/javadoc/testProfiles/TestProfiles.java

Changeset: abc3eaccba73
Author:    jlahoda
Date:      2013-10-23 23:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/abc3eaccba73

8027191: Fix for JDK-8026861 refers to an incorrect bug number
Summary: Reverting changeset b05db8c815e8, so that it can be applied again with a correct bug number
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
- test/tools/javac/T8019486/WrongLNTForLambdaTest.java
+ test/tools/javac/T8019486/WrongLVTForLambdaTest.java

Changeset: 864dafc5ab7a
Author:    jlahoda
Date:      2013-10-23 07:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/864dafc5ab7a

8026861: Wrong LineNumberTable for variable declarations in lambdas
Summary: Setting or correcting positions for many trees produced by LambdaToMethod.
Reviewed-by: vromero, rfield

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/T8019486/WrongLNTForLambdaTest.java
- test/tools/javac/T8019486/WrongLVTForLambdaTest.java

Changeset: 31fe30e2deac
Author:    ksrini
Date:      2013-10-23 15:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/31fe30e2deac

8026936: Initialize LamdbaToMethod lazily and as required
Reviewed-by: jjg, rfield
Contributed-by: jan.lahoda at oracle.com

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java

Changeset: d2fa3f7e964e
Author:    emc
Date:      2013-10-23 23:20 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/d2fa3f7e964e

8006732: support correct bytecode storage of type annotations in multicatch
Summary: Fix issue with annotations being added before attribution, which causes multicatch not to work right and several tests to fail.
Reviewed-by: jfranck, jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.java
! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.out
! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java

Changeset: 119747cd9f25
Author:    emc
Date:      2013-10-24 01:27 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/119747cd9f25

8023682: Incorrect attributes emitted for anonymous class declaration
Summary: Cause javac to emit type annotations on new instruction as well as anonymous class supertype for annotated anonymous classes.
Reviewed-by: jjg, jfranck

! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/annotations/typeAnnotations/failures/TypeOnAnonClass.java
+ test/tools/javac/annotations/typeAnnotations/failures/TypeOnAnonClass.out
! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.out
! test/tools/javac/annotations/typeAnnotations/newlocations/AnonymousClass.java

Changeset: 667843bd2193
Author:    bpatel
Date:      2013-10-24 11:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/667843bd2193

8006248: Since addition of -Xdoclint, javadoc ignores unknown tags
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/doclint/Env.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java
+ test/com/sun/javadoc/testCustomTag/TagTestClass.java
+ test/com/sun/javadoc/testCustomTag/TestCustomTag.java
+ test/com/sun/javadoc/testCustomTag/taglets/CustomTag.java
+ test/tools/doclint/CustomTagTest.java
+ test/tools/doclint/CustomTagTest.out
+ test/tools/doclint/CustomTagTestWithOption.out
! test/tools/doclint/DocLintTester.java

Changeset: 860f1d21763a
Author:    rfield
Date:      2013-10-24 16:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/860f1d21763a

8027220: DefaultMethodsTest: Change test to match spec
Reviewed-by: ksrini

! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java

Changeset: 44e3ba40e00c
Author:    lana
Date:      2013-10-28 12:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/44e3ba40e00c

Merge


Changeset: aa91bc6e8480
Author:    mchung
Date:      2013-10-30 08:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/aa91bc6e8480

8027481: jdeps to handle classes with the same package name and correct profile for javax.crypto.*
Reviewed-by: alanb, dfuchs

! src/share/classes/com/sun/tools/jdeps/Analyzer.java
! src/share/classes/com/sun/tools/jdeps/Archive.java
! src/share/classes/com/sun/tools/jdeps/JdepsTask.java
! src/share/classes/com/sun/tools/jdeps/Profile.java
! test/tools/jdeps/Basic.java
! test/tools/jdeps/Test.java
+ test/tools/jdeps/javax/activity/NotCompactProfile.java
+ test/tools/jdeps/p/Bar.java

Changeset: 537fa895fd74
Author:    vromero
Date:      2013-10-30 18:09 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/537fa895fd74

8027327: jar files related to test test/tools/javac/ExtDirs/ExtDirTest.java should be removed from the repo
Reviewed-by: ksrini

! test/tools/javac/ExtDirs/ExtDirTest.java
- test/tools/javac/ExtDirs/ext1/pkg1.jar
- test/tools/javac/ExtDirs/ext2/pkg2.jar
- test/tools/javac/ExtDirs/ext3/pkg1.jar
- test/tools/javac/ExtDirs/ext3/pkg2.jar

Changeset: 62a67e0875ff
Author:    briangoetz
Date:      2013-10-30 14:12 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/62a67e0875ff

8024930: Re-enable disabled bridging tests
Reviewed-by: psandoz, rfield

! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java

Changeset: 6b4d6205366c
Author:    lana
Date:      2013-10-31 16:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/6b4d6205366c

Merge

- test/tools/javac/ExtDirs/ext1/pkg1.jar
- test/tools/javac/ExtDirs/ext2/pkg2.jar
- test/tools/javac/ExtDirs/ext3/pkg1.jar
- test/tools/javac/ExtDirs/ext3/pkg2.jar
- test/tools/javac/T8019486/WrongLVTForLambdaTest.java

Changeset: 3c040b04af05
Author:    cl
Date:      2013-11-07 08:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/3c040b04af05

Added tag jdk8-b115 for changeset 6b4d6205366c

! .hgtags



From lana.steuck at oracle.com  Sat Nov  9 07:05:14 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 09 Nov 2013 07:05:14 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/hotspot: 106 new changesets
Message-ID: <20131109070906.97FFC624B1@hg.openjdk.java.net>

Changeset: d6d8aeb2c2d4
Author:    amurillo
Date:      2013-10-19 08:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/d6d8aeb2c2d4

8026928: new hotspot build - hs25-b56
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 384c92148c68
Author:    amurillo
Date:      2013-10-21 14:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/384c92148c68

8023496: [jprt] build and test solaris 64-bits only
Reviewed-by: tbell, jcoomes

! make/jprt.properties

Changeset: f9d4ed6c88dd
Author:    dholmes
Date:      2013-10-21 20:51 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/f9d4ed6c88dd

8026872: [TESTBUG] Classes OOMCrashClass4000_1.class and OOMCrashClass1960_2.class from runtime/ClassFile/ tests won't run on compact profiles
Reviewed-by: sla, sspitsyn

! test/TEST.groups

Changeset: 8cd1abf3ecab
Author:    dholmes
Date:      2013-10-21 21:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/8cd1abf3ecab

Merge

- src/share/vm/memory/metablock.cpp
- src/share/vm/memory/metablock.hpp
! test/TEST.groups
- test/compiler/8013496/Test8013496.sh
- test/gc/7168848/HumongousAlloc.java

Changeset: 2036c97e3af0
Author:    dholmes
Date:      2013-10-21 22:36 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/2036c97e3af0

Merge


Changeset: 7fe6ef09d242
Author:    farvidsson
Date:      2013-10-16 09:20 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/7fe6ef09d242

8025638: jmap returns 0 instead of 1 when it fails.
Summary: Re-factored some code handling return values and fails/errors during tool execution.
Reviewed-by: sla, kevinw
Contributed-by: fredrik.arvidsson at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java
! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java
! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java
! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java
! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java
! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java
! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java
! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java
! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java
! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java
! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java
! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java
! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java
! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java
! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java
! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java

Changeset: 042cf42c72bd
Author:    simonis
Date:      2013-10-16 15:06 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/042cf42c72bd

8026703: Wrongly placed <xsl:import> element in Event-Based JVM Tracing .xsl files
Reviewed-by: sla, kamg

! src/share/vm/trace/traceEventClasses.xsl
! src/share/vm/trace/traceEventIds.xsl
! src/share/vm/trace/traceTypes.xsl

Changeset: d248425bcfe8
Author:    hseigel
Date:      2013-10-16 14:32 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/d248425bcfe8

8024804: Crash when InterfaceMethodref resolves to Object.registerNatives
Summary: Added check for NULL prior to continuation of method look up to avoid runtime crash during look up of Object's superclass' methods.
Reviewed-by: coleenp, hseigel
Contributed-by: lois.foltan at oracle.com

! src/share/vm/interpreter/linkResolver.cpp
+ test/runtime/8024804/RegisterNatives.java

Changeset: 9e0ef3f02648
Author:    hseigel
Date:      2013-10-16 15:26 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/9e0ef3f02648

Merge


Changeset: 1bee3014cf2a
Author:    dsamersoff
Date:      2013-10-17 16:08 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1bee3014cf2a

8025812: tmtools/jmap/heap_config tests fail on Linux-ia32 because it Cant attach to the core file
Summary: Coredump store memsz elf field rounded up to page
Reviewed-by: dholmes, sla

! agent/src/os/linux/ps_core.c

Changeset: ffb471203842
Author:    erikj
Date:      2013-10-17 16:11 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/ffb471203842

8026792: HOTSPOT: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated.
Reviewed-by: dholmes, sla

! make/windows/makefiles/trace.make

Changeset: ad8e901ca2e1
Author:    sla
Date:      2013-10-17 12:15 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/ad8e901ca2e1

Merge


Changeset: d2db09f281ca
Author:    dsamersoff
Date:      2013-10-17 16:45 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/d2db09f281ca

8005810: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data
Summary: Hotspot was updated to store method parameter reflection and generic type signature data at runtime.  Serviceability agent support was updated for this data
Reviewed-by: coleenp, minqi, sla
Contributed-by: eric.mccorkle at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java
! src/share/vm/runtime/vmStructs.cpp

Changeset: b942ac65ac86
Author:    dsamersoff
Date:      2013-10-17 17:01 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b942ac65ac86

Merge


Changeset: d0453d2fd045
Author:    dsamersoff
Date:      2013-10-18 10:37 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/d0453d2fd045

Merge


Changeset: ee99e1a7c5fb
Author:    ccheung
Date:      2013-10-18 19:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/ee99e1a7c5fb

Merge

! src/share/vm/interpreter/linkResolver.cpp
- src/share/vm/memory/metablock.cpp
- src/share/vm/memory/metablock.hpp
! src/share/vm/runtime/vmStructs.cpp
- test/compiler/8013496/Test8013496.sh
- test/gc/7168848/HumongousAlloc.java

Changeset: 996d1f2f056f
Author:    dsamersoff
Date:      2013-10-19 21:29 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/996d1f2f056f

8026930: In ManagementAgent.start it should be possible to set the jdp.name parameter (hotspot part)
Summary: Pass one more property from Agent to JdpController
Reviewed-by: jbachorik, sla

! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp

Changeset: 1327b7f85503
Author:    ccheung
Date:      2013-10-21 17:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1327b7f85503

Merge


Changeset: 662c154d2749
Author:    hseigel
Date:      2013-10-22 14:47 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/662c154d2749

8026394: Eclipse fails with JDK8 build 111
Summary: If the resolved interface does not itself contain "clone" or "finalize" methods, the method/interface method resolution looks to the interface's super class, java.lang.Object.  With the JDK 8 interface method accessability check requirement, since these two methods are declared within Object as protected, they must be special cased in LinkResolver::check_method_accessability() in order to avoid an IAE.
Reviewed-by: acorn, dholmes
Contributed-by: lois.foltan at oracle.com

! src/share/vm/interpreter/linkResolver.cpp
+ test/runtime/8026394/InterfaceObjectTest.java

Changeset: b8860472c377
Author:    iklam
Date:      2013-10-22 14:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b8860472c377

8014910: deadlock between JVM/TI ClassPrepare event handler and CompilerThread
Summary: Revert changes in JDK-8008962
Reviewed-by: coleenp, sspitsyn

! src/share/vm/ci/ciEnv.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/prims/jvmtiEnv.cpp

Changeset: 28be4c586b70
Author:    iklam
Date:      2013-10-22 16:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/28be4c586b70

Merge


Changeset: a997d762fa20
Author:    hseigel
Date:      2013-10-22 15:54 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a997d762fa20

8026809: [TESTBUG] Create regression test for JDK-8026041
Summary: Created simple regression test for the bug
Reviewed-by: hseigel, lfoltan, zgu
Contributed-by: mikhailo.seledtsov at oracle.com

+ test/runtime/CommandLine/PrintGCApplicationConcurrentTime.java

Changeset: c183576a2dd1
Author:    hseigel
Date:      2013-10-22 22:14 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/c183576a2dd1

Merge


Changeset: b658cfe35857
Author:    farvidsson
Date:      2013-10-23 10:24 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b658cfe35857

8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value
Summary: Fixes a bug with vmArgs when using JDKToolLauncher
Reviewed-by: sla, dholmes

! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java

Changeset: b3a4d4279fa3
Author:    ccheung
Date:      2013-10-24 17:20 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b3a4d4279fa3

Merge


Changeset: 74e00b98d5dd
Author:    anoll
Date:      2013-10-17 19:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/74e00b98d5dd

8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation
Summary: Increase size for the template interpreter accordingly
Reviewed-by: kvn, twisti

! src/cpu/x86/vm/templateInterpreter_x86.hpp

Changeset: 1856ea98184a
Author:    adlertz
Date:      2013-10-18 10:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1856ea98184a

8022783: Nashorn test fails with: assert(!def_outside->member(r))
Summary: Enables private copies of inputs for recent spill copies as well
Reviewed-by: kvn, twisti

! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/reg_split.cpp

Changeset: e3b736cf4fa3
Author:    adlertz
Date:      2013-10-18 09:36 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e3b736cf4fa3

Merge


Changeset: 252d541466ea
Author:    morris
Date:      2013-10-18 12:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/252d541466ea

8008242: VerifyOops is broken on SPARC
Summary: Fixed displacement issues in SPARC macroassembler and ensure that getClass intrinsic temporary result is T_METADATA
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp

Changeset: 3213ba4d3dff
Author:    roland
Date:      2013-10-19 12:16 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3213ba4d3dff

8024069: replace_in_map() should operate on parent maps
Summary: type information gets lost because replace_in_map() doesn't update parent maps
Reviewed-by: kvn, twisti

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/ifnode.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopPredicate.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/multnode.cpp
! src/share/vm/opto/multnode.hpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse1.cpp

Changeset: 19c5a042b0b3
Author:    iignatyev
Date:      2013-10-19 21:54 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/19c5a042b0b3

8026414: [TESTBUG] Tests for Tiered/NonTiered levels
Reviewed-by: twisti, iveresov

+ test/compiler/tiered/CompLevelsTest.java
+ test/compiler/tiered/NonTieredLevelsTest.java
+ test/compiler/tiered/TieredLevelsTest.java

Changeset: 600c83f8e6a5
Author:    iignatyev
Date:      2013-10-19 21:54 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/600c83f8e6a5

8023318: compiler/whitebox tests timeout with enabled TieredCompilation
Reviewed-by: kvn, twisti

! test/compiler/whitebox/CompilerWhiteBoxTest.java

Changeset: e842cc2d2dfb
Author:    iveresov
Date:      2013-10-19 22:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e842cc2d2dfb

Merge


Changeset: 52575a17a36c
Author:    iignatyev
Date:      2013-10-21 09:21 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/52575a17a36c

8026865: [TESTBUG] 'compiler/print/PrintInlining.java' should specify -XX:+UnlockDiagnosticVMOptions
Reviewed-by: twisti, iveresov

! test/compiler/print/PrintInlining.java

Changeset: 4748b3308cda
Author:    iveresov
Date:      2013-10-21 17:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/4748b3308cda

Merge


Changeset: 5ccbab1c69f3
Author:    roland
Date:      2013-10-22 09:51 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/5ccbab1c69f3

8026251: New type profiling points: parameters to methods
Summary: x86 interpreter and c1 type profiling for parameters on method entries
Reviewed-by: kvn, twisti

! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp
! src/cpu/x86/vm/globals_x86.hpp
+ src/cpu/x86/vm/interp_masm_x86.cpp
+ src/cpu/x86/vm/interp_masm_x86.hpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/interp_masm_x86_64.hpp
! src/cpu/x86/vm/register_definitions_x86.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/vtableStubs_x86_32.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/ci/ciMethodData.cpp
! src/share/vm/ci/ciMethodData.hpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/templateTable.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp

Changeset: 435c7b4577cd
Author:    rbackman
Date:      2013-10-21 15:31 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/435c7b4577cd

8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here
Reviewed-by: iveresov, roland

! src/share/vm/opto/compile.cpp

Changeset: 36e17466dd39
Author:    rbackman
Date:      2013-10-22 14:02 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/36e17466dd39

Merge


Changeset: 8b4bbba322d3
Author:    anoll
Date:      2013-10-23 10:00 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/8b4bbba322d3

8026407: VM crashes on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified
Summary: Ensure currently required generation of AdapterHandlerLibrary::create_native_wrapper()
Reviewed-by: roland, iveresov

! src/share/vm/compiler/compileBroker.cpp

Changeset: b2ee5dc63353
Author:    roland
Date:      2013-10-23 12:40 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b2ee5dc63353

8024070: C2 needs some form of type speculation
Summary: record unused type profile information with type system, propagate and use it.
Reviewed-by: kvn, twisti

! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/ci/ciMethodData.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/phaseX.hpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
! src/share/vm/runtime/arguments.cpp
+ test/compiler/types/TypeSpeculation.java

Changeset: 4c9115774c8e
Author:    adlertz
Date:      2013-10-23 10:44 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/4c9115774c8e

8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL
Summary: We can reach this state from phi input rematerialization, so pass in the Reaches of the predecessor
Reviewed-by: roland, twisti

! src/share/vm/opto/reg_split.cpp

Changeset: 97d400662426
Author:    adlertz
Date:      2013-10-23 19:22 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/97d400662426

Merge


Changeset: 9acbfe04b5c3
Author:    iveresov
Date:      2013-10-23 11:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/9acbfe04b5c3

8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64
Summary: Fix wrong calling convention in LIR_Assembler::emit_unwind_handler(), T_METADATA support in calling convention generator, C1 register allocator
Reviewed-by: twisti, jrose

! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp
! src/cpu/x86/vm/c1_FrameMap_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LinearScan.cpp

Changeset: 1c90f0072f0d
Author:    twisti
Date:      2013-10-23 15:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1c90f0072f0d

8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms
Reviewed-by: iveresov, jrose

! src/share/vm/classfile/systemDictionary.cpp

Changeset: 3a04e444da6d
Author:    iveresov
Date:      2013-10-23 16:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3a04e444da6d

Merge


Changeset: 59e8ad757e19
Author:    rbackman
Date:      2013-10-18 10:41 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/59e8ad757e19

8026844: Various Math functions needs intrinsification
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/archDesc.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/mathexactnode.cpp
! src/share/vm/opto/mathexactnode.hpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
! src/share/vm/runtime/vmStructs.cpp
+ test/compiler/intrinsics/mathexact/AddExactICondTest.java
+ test/compiler/intrinsics/mathexact/AddExactIConstantTest.java
+ test/compiler/intrinsics/mathexact/AddExactILoadTest.java
+ test/compiler/intrinsics/mathexact/AddExactILoopDependentTest.java
+ test/compiler/intrinsics/mathexact/AddExactINonConstantTest.java
+ test/compiler/intrinsics/mathexact/AddExactIRepeatTest.java
+ test/compiler/intrinsics/mathexact/AddExactLConstantTest.java
+ test/compiler/intrinsics/mathexact/AddExactLNonConstantTest.java
- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
+ test/compiler/intrinsics/mathexact/DecExactITest.java
+ test/compiler/intrinsics/mathexact/DecExactLTest.java
+ test/compiler/intrinsics/mathexact/IncExactITest.java
+ test/compiler/intrinsics/mathexact/IncExactLTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
+ test/compiler/intrinsics/mathexact/MulExactICondTest.java
+ test/compiler/intrinsics/mathexact/MulExactIConstantTest.java
+ test/compiler/intrinsics/mathexact/MulExactILoadTest.java
+ test/compiler/intrinsics/mathexact/MulExactILoopDependentTest.java
+ test/compiler/intrinsics/mathexact/MulExactINonConstantTest.java
+ test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java
+ test/compiler/intrinsics/mathexact/MulExactLConstantTest.java
+ test/compiler/intrinsics/mathexact/MulExactLNonConstantTest.java
+ test/compiler/intrinsics/mathexact/NegExactIConstantTest.java
+ test/compiler/intrinsics/mathexact/NegExactILoadTest.java
+ test/compiler/intrinsics/mathexact/NegExactILoopDependentTest.java
+ test/compiler/intrinsics/mathexact/NegExactINonConstantTest.java
+ test/compiler/intrinsics/mathexact/NegExactLConstantTest.java
+ test/compiler/intrinsics/mathexact/NegExactLNonConstantTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java
+ test/compiler/intrinsics/mathexact/SubExactICondTest.java
+ test/compiler/intrinsics/mathexact/SubExactIConstantTest.java
+ test/compiler/intrinsics/mathexact/SubExactILoadTest.java
+ test/compiler/intrinsics/mathexact/SubExactILoopDependentTest.java
+ test/compiler/intrinsics/mathexact/SubExactINonConstantTest.java
+ test/compiler/intrinsics/mathexact/SubExactIRepeatTest.java
+ test/compiler/intrinsics/mathexact/SubExactLConstantTest.java
+ test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java
! test/compiler/intrinsics/mathexact/Verify.java

Changeset: 68f07c29521b
Author:    anoll
Date:      2013-10-15 08:38 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/68f07c29521b

8025740: Typo. Error line for wrong ReservedCodeCacheSize value is printed twice
Summary: Remove duplicate print
Reviewed-by: kvn, twisti

! src/share/vm/runtime/arguments.cpp

Changeset: d95eca175eff
Author:    sspitsyn
Date:      2013-10-23 20:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/d95eca175eff

8023004: JSR 292: java.lang.RuntimeException: Original target method was called.
Reviewed-by: jrose

! src/share/vm/prims/methodHandles.cpp

Changeset: 0d1661d63d70
Author:    vlivanov
Date:      2013-10-23 20:20 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/0d1661d63d70

8012941: JSR 292: too deep inlining might crash compiler because of stack overflow
Reviewed-by: kvn, twisti

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_globals.hpp

Changeset: f7d928a3181c
Author:    roland
Date:      2013-10-24 19:32 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/f7d928a3181c

8026978: JSR292: fatal error: Type profiling not implemented on this platform
Summary: force TypeProfileLevel to 0 on non x86
Reviewed-by: twisti

! src/share/vm/runtime/arguments.cpp

Changeset: 395499125cb0
Author:    iveresov
Date:      2013-10-24 16:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/395499125cb0

Merge

- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java

Changeset: 6b32b911d723
Author:    iveresov
Date:      2013-10-24 16:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/6b32b911d723

Merge

! src/share/vm/runtime/vmStructs.cpp
- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java

Changeset: 1d1ea10fe09f
Author:    mgerdin
Date:      2013-10-15 13:56 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1d1ea10fe09f

8015255: NPG: Don't waste fragment at the end of a VirtualSpaceNode before retiring it.
Summary: Chunk up the last piece of committed memory in a VSN when getting a new one.
Reviewed-by: stefank, jmasa

! src/share/vm/memory/metaspace.cpp
! src/share/vm/prims/jni.cpp

Changeset: 91a88c8450f4
Author:    mgerdin
Date:      2013-10-18 09:31 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/91a88c8450f4

8026698: Incorrect error handling in Metaspace::allocate
Reviewed-by: stefank, jwilhelm

! src/share/vm/memory/metaspace.cpp

Changeset: a1b05d4a6fd0
Author:    stefank
Date:      2013-10-21 09:34 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a1b05d4a6fd0

8026781: Add missing test to exercise -XX:+UseLargePagesInMetaspace
Reviewed-by: mgerdin, brutisso

+ test/gc/TestSystemGC.java

Changeset: 3dd24766da44
Author:    stefank
Date:      2013-10-21 01:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3dd24766da44

Merge


Changeset: 2fab5b7e6140
Author:    ehelin
Date:      2013-10-21 14:20 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/2fab5b7e6140

8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops
Reviewed-by: coleenp, mgerdin, sspitsyn

! src/share/vm/prims/jvmtiImpl.cpp

Changeset: c7f403b05168
Author:    sjohanss
Date:      2013-10-22 11:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/c7f403b05168

8026848: -XX:+G1SummarizeRSetStats can result in wrong exit code and crash
Summary: Changed the use of %d to SIZE_FORMAT macro in format string when printing size_t values.
Reviewed-by: stefank, ehelin

! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp

Changeset: 0823c8bac468
Author:    jcoomes
Date:      2013-10-22 12:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/0823c8bac468

Merge


Changeset: 1b422ef5288a
Author:    tschatzl
Date:      2013-10-23 10:23 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1b422ef5288a

8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region
Summary: The field G1AllocRegion::_alloc_region needs to be declared volatile as it is used with that intention. Otherwise the compiler may generate the code that reloads the value which might have changed in the meantime, leading to spurious crashes.
Reviewed-by: iveresov, simonis, tschatzl
Contributed-by: Axel Siebenborn <axel.siebenborn at sap.com>

! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp

Changeset: 0dcdec729cda
Author:    jcoomes
Date:      2013-10-25 08:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/0dcdec729cda

Merge


Changeset: 82a9cdbf683e
Author:    amurillo
Date:      2013-10-25 13:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/82a9cdbf683e

Merge

! src/share/vm/services/diagnosticCommand.cpp
- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java

Changeset: bde83ddf920c
Author:    amurillo
Date:      2013-10-25 13:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/bde83ddf920c

Added tag hs25-b56 for changeset 82a9cdbf683e

! .hgtags

Changeset: e006d2e25bc7
Author:    dholmes
Date:      2013-10-24 20:47 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e006d2e25bc7

8025673: [macosx] Disable X11 AWT toolkit
Summary: Disable but not completely remove the XAWT and headless toolkits on Mac OS X
Reviewed-by: dholmes
Contributed-by: david.dehaven at oracle.com

! src/os/bsd/vm/os_bsd.cpp

Changeset: 913a35723a0a
Author:    katleman
Date:      2013-10-28 16:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/913a35723a0a

Merge


Changeset: 7fd913010dbb
Author:    katleman
Date:      2013-10-29 14:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/7fd913010dbb

Merge


Changeset: ddc3758f68db
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/ddc3758f68db

Added tag jdk8-b114 for changeset 7fd913010dbb

! .hgtags

Changeset: e39b138b2518
Author:    acorn
Date:      2013-10-19 18:32 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e39b138b2518

8026893: Push 8026365 to TL early and add test
Reviewed-by: dcubed, kamg

! src/share/vm/classfile/verifier.cpp
! test/TEST.groups
+ test/runtime/8026365/InvokeSpecialAnonTest.java

Changeset: 0e55a181cb08
Author:    lana
Date:      2013-10-28 12:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/0e55a181cb08

Merge

- src/share/vm/memory/metablock.cpp
- src/share/vm/memory/metablock.hpp
- test/compiler/8013496/Test8013496.sh
- test/gc/7168848/HumongousAlloc.java

Changeset: ea1b8c643fc8
Author:    lana
Date:      2013-10-30 13:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/ea1b8c643fc8

Merge

- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java

Changeset: 205834867346
Author:    lana
Date:      2013-10-31 16:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/205834867346

Merge


Changeset: f94a9f0746d8
Author:    amurillo
Date:      2013-10-25 13:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/f94a9f0746d8

8027173: new hotspot build - hs25-b57
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: e64f1fe9756b
Author:    farvidsson
Date:      2013-10-24 10:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e64f1fe9756b

8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes
Summary: Rewrite of the getLoadedClasses() method implementation to include anonymous classes.
Reviewed-by: coleenp, sspitsyn

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/prims/jvmtiGetLoadedClasses.cpp

Changeset: d70a665e25d7
Author:    iklam
Date:      2013-10-24 22:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/d70a665e25d7

8020753: JNI_CreateJavaVM on Mac OSX 10.9 Mavericks corrupts the callers stack size
Summary: Use hard-coded DEFAULT_MAIN_THREAD_STACK_PAGES = 2048 for 10.9
Reviewed-by: dcubed, iveresov
Contributed-by: gerard.ziemski at oracle.com

! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp

Changeset: e4f478e7781b
Author:    jbachorik
Date:      2013-10-25 09:07 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e4f478e7781b

8027294: Prepare hotspot for non TOD based uptime counter
Summary: Use HR timer when available for os::elapsed_counter() on linux/bsd. Add a new counter for the JVM uptime.
Reviewed-by: dholmes, sla

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/share/vm/services/jmm.h
! src/share/vm/services/management.cpp

Changeset: a6177f601c64
Author:    hseigel
Date:      2013-10-25 11:05 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a6177f601c64

8026822: metaspace/flags/maxMetaspaceSize throws OOM of unexpected type.java.lang.OutOfMemoryError: Compressed class space
Summary: Incorporate chunk size when seeing if OutOfMemoryError was caused by Metaspace or Compressed class space.
Reviewed-by: stefank, coleenp

! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/universe.cpp

Changeset: 634715d59d9e
Author:    hseigel
Date:      2013-10-25 11:13 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/634715d59d9e

Merge


Changeset: 209aa13ab8c0
Author:    coleenp
Date:      2013-10-25 15:19 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/209aa13ab8c0

8024927: Nashorn performance regression with CompressedOops
Summary: Allocate compressed class space at end of Java heap.  For small heap sizes, without CDS, save some space so compressed classes can have the same favorable compression as oops
Reviewed-by: stefank, hseigel, goetz

! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/utilities/globalDefinitions.hpp
+ test/runtime/CompressedOops/CompressedClassPointers.java

Changeset: b4aa8fc5d0d5
Author:    ccheung
Date:      2013-10-25 22:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b4aa8fc5d0d5

Merge

! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/share/vm/memory/metaspace.cpp
- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java

Changeset: 1a04de1aaedb
Author:    dsamersoff
Date:      2013-10-28 21:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1a04de1aaedb

8026950: Nits in agent ps_proc.c file breaks compilation of open hotspot
Summary: Fixed two compilation-breaking nits
Reviewed-by: sla, dholmes

! agent/src/os/bsd/ps_proc.c

Changeset: 85730a185147
Author:    ccheung
Date:      2013-10-30 14:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/85730a185147

Merge


Changeset: 292050e5d5ea
Author:    dholmes
Date:      2013-10-24 00:33 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/292050e5d5ea

8026877: Error in opening JAR file when invalid jar specified with -Xbootclasspath/a on OpenJDK build
Reviewed-by: coleenp, twisti

! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/runtime/thread.cpp

Changeset: 066778844ed9
Author:    jprovino
Date:      2013-10-27 14:11 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/066778844ed9

Merge


Changeset: f2f9139ccde9
Author:    jprovino
Date:      2013-10-30 16:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/f2f9139ccde9

Merge


Changeset: a007575ea726
Author:    vladidan
Date:      2013-10-30 16:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a007575ea726

Merge


Changeset: 3b3133d93fb6
Author:    brutisso
Date:      2013-10-28 13:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3b3133d93fb6

8027132: Print deprecation warning message for the flags controlling the CMS foreground collector
Reviewed-by: stefank, ehelin, ysr, tschatzl

! src/share/vm/runtime/arguments.cpp
+ test/gc/startup_warnings/TestCMSForegroundFlags.java

Changeset: 6d965678f21e
Author:    ehelin
Date:      2013-10-31 21:20 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/6d965678f21e

Merge


Changeset: bd3237e0e18d
Author:    twisti
Date:      2013-10-24 16:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/bd3237e0e18d

8026328: Setting a breakpoint on invokedynamic crashes the JVM
Reviewed-by: jrose, roland

! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/cpu/zero/vm/globals_zero.hpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/cppInterpreter.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/interpreter/templateInterpreter.hpp
! src/share/vm/interpreter/templateInterpreterGenerator.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/runtime/handles.cpp

Changeset: cbe8ba0fb8fc
Author:    twisti
Date:      2013-10-24 16:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/cbe8ba0fb8fc

Merge

- test/compiler/intrinsics/mathexact/CondTest.java
- test/compiler/intrinsics/mathexact/ConstantTest.java
- test/compiler/intrinsics/mathexact/LoadTest.java
- test/compiler/intrinsics/mathexact/LoopDependentTest.java
- test/compiler/intrinsics/mathexact/NonConstantTest.java
- test/compiler/intrinsics/mathexact/RepeatTest.java

Changeset: f01788f13696
Author:    adlertz
Date:      2013-10-25 10:13 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/f01788f13696

8026940: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc
Summary: Remove input to junk phi if they also become dead during post_allocate_copy_removal
Reviewed-by: roland

! src/share/vm/opto/postaloc.cpp

Changeset: 7ae254fd0b3c
Author:    adlertz
Date:      2013-10-25 12:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/7ae254fd0b3c

Merge


Changeset: 6c2f07d1495f
Author:    roland
Date:      2013-10-28 09:58 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/6c2f07d1495f

8027140: Assertion in compiler when running bigapps/Kitchensink/stability
Summary: filter() code for TypeKlassPtr not moved when permgen removal was introduced
Reviewed-by: twisti, iveresov

! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp

Changeset: bfdb530cdffa
Author:    roland
Date:      2013-10-28 12:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/bfdb530cdffa

Merge


Changeset: a196f1aaec86
Author:    anoll
Date:      2013-10-25 22:57 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a196f1aaec86

8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers)
Summary: Exit compiler threads early during startup so that wrong error message is not printed
Reviewed-by: iveresov, twisti

! src/share/vm/compiler/compileBroker.cpp
+ test/compiler/startup/StartupOutput.java

Changeset: 8c16f426dbb2
Author:    iveresov
Date:      2013-10-28 15:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/8c16f426dbb2

Merge


Changeset: fc1632f5021a
Author:    iveresov
Date:      2013-10-28 17:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/fc1632f5021a

Merge


Changeset: a57a165b8296
Author:    rbackman
Date:      2013-10-28 08:34 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a57a165b8296

8027353: Exact intrinsics: assert(n != NULL) failed: must not be null
Reviewed-by: kvn, roland

! src/share/vm/opto/library_call.cpp
! test/compiler/intrinsics/mathexact/SubExactLConstantTest.java
! test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java

Changeset: 60a32bb8ff99
Author:    rbackman
Date:      2013-10-30 13:14 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/60a32bb8ff99

8027444: mathExact: assert(i < _max) failed: oob: i=1, _max=1
Reviewed-by: duke

! src/share/vm/opto/loopTransform.cpp
+ test/compiler/intrinsics/mathexact/NestedMathExactTest.java

Changeset: 4d3575d37a07
Author:    iveresov
Date:      2013-10-30 22:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/4d3575d37a07

8026735: Stream tests throw java.lang.IncompatibleClassChangeError
Summary: Put a band-aid to disable CHA-based inlining for interfaces with default methods in C1
Reviewed-by: kvn, twisti

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/ci/ciInstanceKlass.hpp
+ test/compiler/inlining/InlineDefaultMethod.java

Changeset: 946a8294ab15
Author:    iveresov
Date:      2013-10-31 04:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/946a8294ab15

8024919: G1: SPECjbb2013 crashes due to a broken object reference
Summary: Pass correct new value to post_barrer() in Unsafe.getAndSetObject() C1 intrinsic
Reviewed-by: kvn, roland

! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp

Changeset: 2dcd0bd2920d
Author:    iveresov
Date:      2013-10-31 14:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/2dcd0bd2920d

Merge


Changeset: 0836a3c28c6a
Author:    iveresov
Date:      2013-10-31 15:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/0836a3c28c6a

Merge


Changeset: 3b32d287da89
Author:    amurillo
Date:      2013-11-01 08:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3b32d287da89

Merge

! src/os/bsd/vm/os_bsd.cpp

Changeset: afd012c940e4
Author:    amurillo
Date:      2013-11-01 08:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/afd012c940e4

Added tag hs25-b57 for changeset 3b32d287da89

! .hgtags

Changeset: 9ebaac78a8a0
Author:    amurillo
Date:      2013-11-05 14:06 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/9ebaac78a8a0

Merge


Changeset: 842b6ce4dfb4
Author:    cl
Date:      2013-11-07 08:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/842b6ce4dfb4

Added tag jdk8-b115 for changeset 9ebaac78a8a0

! .hgtags



From lana.steuck at oracle.com  Sat Nov  9 07:04:24 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 09 Nov 2013 07:04:24 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/corba: 6 new changesets
Message-ID: <20131109070431.304F4624AB@hg.openjdk.java.net>

Changeset: d425685e0b74
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/d425685e0b74

Added tag jdk8-b114 for changeset 0bbccf77c23e

! .hgtags

Changeset: 52ad44f9a3ec
Author:    alanb
Date:      2013-10-22 11:40 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/52ad44f9a3ec

8021257: com.sun.corba.se.** should be on restricted package list
Reviewed-by: chegar, coffeys, smarks
Contributed-by: alan.bateman at oralce.com, mark.sheppard at oracle.com

! src/share/classes/javax/rmi/CORBA/Stub.java
! src/share/classes/javax/rmi/CORBA/Util.java
! src/share/classes/javax/rmi/PortableRemoteObject.java
! src/share/classes/org/omg/CORBA/ORB.java

Changeset: a90e9efa4264
Author:    coffeys
Date:      2013-10-23 16:45 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/a90e9efa4264

5036554: unmarshal error on CORBA alias type in CORBA any
Reviewed-by: chegar, smarks

! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java

Changeset: 219e616a6a4f
Author:    lana
Date:      2013-10-28 12:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/219e616a6a4f

Merge


Changeset: 8d07115924b7
Author:    lana
Date:      2013-10-31 16:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/8d07115924b7

Merge


Changeset: 5fdc44652089
Author:    cl
Date:      2013-11-07 08:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/5fdc44652089

Added tag jdk8-b115 for changeset 8d07115924b7

! .hgtags



From lana.steuck at oracle.com  Sat Nov  9 07:04:24 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 09 Nov 2013 07:04:24 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d: 36 new changesets
Message-ID: <20131109070427.D89A7624A9@hg.openjdk.java.net>

Changeset: b098ee22aa97
Author:    erikj
Date:      2013-10-24 10:43 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/b098ee22aa97

8009280: JCE jurisdiction policy files not copied into jdk/lib/security
Reviewed-by: tbell, ihse

! common/makefiles/JavaCompilation.gmk

Changeset: 3c48e11c3901
Author:    dholmes
Date:      2013-10-24 20:45 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/3c48e11c3901

8016096: [macosx] jawt_md.h shipped with jdk is outdated
Summary: Revised build system and added platform specific headers for Mac OS X
Reviewed-by: ihse, erikj
Contributed-by: david.dehaven at oracle.com

! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4

Changeset: 72ef61df77e5
Author:    ihse
Date:      2013-10-25 13:58 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/72ef61df77e5

8027300: configure should use LIBS instead of LDFLAGS when testing freetype
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/libraries.m4

Changeset: dfbc93f26f38
Author:    dcubed
Date:      2013-10-25 10:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/dfbc93f26f38

8027117: adapt JDK-7165611 to new build-infra whitespace/indent policy
Summary: Fix whitespace/indent issues.
Reviewed-by: hseigel, coleenp, erikj, ihse

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4
! common/makefiles/NativeCompilation.gmk

Changeset: 4f2011496393
Author:    katleman
Date:      2013-10-28 16:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/4f2011496393

Merge


Changeset: b65d48f6938a
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/b65d48f6938a

Added tag jdk8-b114 for changeset 4f2011496393

! .hgtags

Changeset: 3dc55f0c1b6f
Author:    jlaskey
Date:      2013-01-28 16:29 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/3dc55f0c1b6f

8006676: Integrate Nashorn into new build system
Reviewed-by: jlaskey
Contributed-by: james.laskey at oracle.com

! common/autoconf/generated-configure.sh
! common/autoconf/source-dirs.m4
! common/autoconf/spec.gmk.in
! common/bin/compare.sh
! common/makefiles/Main.gmk
! common/makefiles/MakeBase.gmk
+ make/nashorn-rules.gmk
! make/scripts/hgforest.sh

Changeset: ecd447139a39
Author:    jlaskey
Date:      2013-02-04 17:30 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/ecd447139a39

Merge

! common/autoconf/generated-configure.sh

Changeset: 9ed388a04fa7
Author:    jlaskey
Date:      2013-02-06 13:37 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/9ed388a04fa7

8007666: nashorn missing from hgforest.sh
Reviewed-by: jlaskey
Contributed-by: james.laskey at oracle.com

! common/bin/hgforest.sh

Changeset: 8b19b55f695d
Author:    jlaskey
Date:      2013-02-18 19:01 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/8b19b55f695d

8008420: Fix Nashorn forest to build with NEWBUILD=false
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! Makefile
! make/nashorn-rules.gmk

Changeset: f9a1cb245484
Author:    jlaskey
Date:      2013-02-19 10:02 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/f9a1cb245484

8008446: Tweaks to make all NEWBUILD=false round 2
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! make/Defs-internal.gmk

Changeset: 887fde71977e
Author:    jlaskey
Date:      2013-02-21 15:25 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/887fde71977e

8008447: Tweaks to make all NEWBUILD=false round 3
Reviewed-by: jjh, sundar
Contributed-by: james.laskey at oracle.com

! make/jdk-rules.gmk
! make/sanity-rules.gmk

Changeset: e877cb3eb4d6
Author:    jlaskey
Date:      2013-02-22 13:09 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/e877cb3eb4d6

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/bin/hgforest.sh
! common/makefiles/Main.gmk

Changeset: 528a9984198f
Author:    jlaskey
Date:      2013-02-22 22:58 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/528a9984198f

8008774: nashorn missing from dependencies after merge with tl
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! common/makefiles/Main.gmk

Changeset: 13ddc5c3ebfc
Author:    jlaskey
Date:      2013-03-02 10:28 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/13ddc5c3ebfc

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/bin/hgforest.sh
! common/makefiles/Main.gmk
! make/nashorn-rules.gmk

Changeset: 1d38d30196be
Author:    jlaskey
Date:      2013-03-08 14:44 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/1d38d30196be

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: b938d5ee29c3
Author:    jlaskey
Date:      2013-03-15 11:50 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/b938d5ee29c3

Merge


Changeset: fe5a388bf8fe
Author:    jlaskey
Date:      2013-03-26 09:13 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/fe5a388bf8fe

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: 1378ccca1c79
Author:    jlaskey
Date:      2013-04-09 08:35 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/1378ccca1c79

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/bin/hgforest.sh
! common/makefiles/Main.gmk

Changeset: 8a7e97848471
Author:    jlaskey
Date:      2013-04-15 08:06 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/8a7e97848471

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: 6316aefcf716
Author:    jlaskey
Date:      2013-04-17 08:47 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/6316aefcf716

Merge


Changeset: dd81e9b5fb38
Author:    jlaskey
Date:      2013-04-22 13:59 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/dd81e9b5fb38

Merge


Changeset: 431d16ddfcd9
Author:    jlaskey
Date:      2013-04-29 21:37 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/431d16ddfcd9

Merge


Changeset: 1fca390200c1
Author:    jlaskey
Date:      2013-05-14 09:04 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/1fca390200c1

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: 67b5cbe55744
Author:    jlaskey
Date:      2013-05-23 09:48 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/67b5cbe55744

Merge


Changeset: de886178f8e6
Author:    jlaskey
Date:      2013-06-05 13:08 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/de886178f8e6

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in

Changeset: 520fd54a7c43
Author:    jlaskey
Date:      2013-07-16 09:08 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/520fd54a7c43

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: 67dc3d7d5b5f
Author:    jlaskey
Date:      2013-07-24 08:23 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/67dc3d7d5b5f

Merge

! common/autoconf/generated-configure.sh

Changeset: 96f207364e46
Author:    jlaskey
Date:      2013-08-27 16:05 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/96f207364e46

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/Main.gmk

Changeset: ddf76977d04a
Author:    jlaskey
Date:      2013-09-13 10:14 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/ddf76977d04a

Merge

! common/autoconf/generated-configure.sh
! common/bin/hgforest.sh
! common/makefiles/Main.gmk

Changeset: 8b92b08993a8
Author:    jlaskey
Date:      2013-09-30 10:23 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/8b92b08993a8

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in

Changeset: d832f6171acd
Author:    jlaskey
Date:      2013-10-29 11:48 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/d832f6171acd

Merge

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/bin/hgforest.sh
! common/makefiles/Main.gmk

Changeset: 067355edfbf8
Author:    vinnie
Date:      2013-10-30 17:31 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/067355edfbf8

8027567: JDK 8 build failure: the correct version of GNU make is being rejected
Reviewed-by: chegar, erikj

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh

Changeset: 37d2736caf46
Author:    lana
Date:      2013-10-30 13:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/37d2736caf46

Merge

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in

Changeset: 763ada2a1d8c
Author:    lana
Date:      2013-10-31 16:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/763ada2a1d8c

Merge


Changeset: 40e892e2a4f2
Author:    cl
Date:      2013-11-07 08:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/40e892e2a4f2

Added tag jdk8-b115 for changeset 763ada2a1d8c

! .hgtags



From linuxhippy at gmail.com  Mon Nov 11 08:21:25 2013
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Mon, 11 Nov 2013 09:21:25 +0100
Subject: [OpenJDK 2D-Dev] Resurrecting Lauren'ts work on speeding up
	Pisces
In-Reply-To: <CA+nxMTtgCtvfUQTE=MYoTdEgwGfexhrZRJ6PfV3fug0wL85Tzw@mail.gmail.com>
References: <CA+nxMTv6-dfyAQ4HhSi-avEJ-tNaBYagi7Je-A7eMg_pdHdNQg@mail.gmail.com>
	<CAKjRUT69uEU5jCXPEWwVa+vOz2dLUFBFrj_4S9Tt4g9Ro4YmOw@mail.gmail.com>
	<CAFvQSYR0uroS2QQ_rUC+O5zsXn71OEHG9B=tKyJ9EFvV6EgJ5w@mail.gmail.com>
	<CA+nxMTtgCtvfUQTE=MYoTdEgwGfexhrZRJ6PfV3fug0wL85Tzw@mail.gmail.com>
Message-ID: <CAFvQSYSubHt8q2crGYHSnQD0U9uFPUEPSx1uBX8JgPyK1Z_Hiw@mail.gmail.com>

Hi,

One wish regarding pisces came into my mind:

Currently all AA tile generators feed  32x32 coverage tiles to the pipelines.
While this might be a good idea for software-only pipelines due to
good cache locality, it is a huge issue for at least the xrender
pipeline.
Each tile has to be uploaded seperately, which causes context switches
and GPU stalls - and I can't make use of the shared memory image
extension which should be quite benefitial for larger coverage
uploads,

It would be great if this fixed size could be made more dynamically -
this is an area where I could contribute.

Regards, Clemens


From andrea.aime at geo-solutions.it  Mon Nov 11 08:33:17 2013
From: andrea.aime at geo-solutions.it (Andrea Aime)
Date: Mon, 11 Nov 2013 09:33:17 +0100
Subject: [OpenJDK 2D-Dev] Resurrecting Lauren'ts work on speeding up
	Pisces
In-Reply-To: <CAFvQSYSubHt8q2crGYHSnQD0U9uFPUEPSx1uBX8JgPyK1Z_Hiw@mail.gmail.com>
References: <CA+nxMTv6-dfyAQ4HhSi-avEJ-tNaBYagi7Je-A7eMg_pdHdNQg@mail.gmail.com>
	<CAKjRUT69uEU5jCXPEWwVa+vOz2dLUFBFrj_4S9Tt4g9Ro4YmOw@mail.gmail.com>
	<CAFvQSYR0uroS2QQ_rUC+O5zsXn71OEHG9B=tKyJ9EFvV6EgJ5w@mail.gmail.com>
	<CA+nxMTtgCtvfUQTE=MYoTdEgwGfexhrZRJ6PfV3fug0wL85Tzw@mail.gmail.com>
	<CAFvQSYSubHt8q2crGYHSnQD0U9uFPUEPSx1uBX8JgPyK1Z_Hiw@mail.gmail.com>
Message-ID: <CA+nxMTt_Fq7PkRMEDKpoOiCCh8-t6NJCrhxT=aWePawGJqturQ@mail.gmail.com>

On Mon, Nov 11, 2013 at 9:21 AM, Clemens Eisserer <linuxhippy at gmail.com>wrote:

> Hi,
>
> One wish regarding pisces came into my mind:
>
> Currently all AA tile generators feed  32x32 coverage tiles to the
> pipelines.
> While this might be a good idea for software-only pipelines due to
> good cache locality, it is a huge issue for at least the xrender
> pipeline.
> Each tile has to be uploaded seperately, which causes context switches
> and GPU stalls - and I can't make use of the shared memory image
> extension which should be quite benefitial for larger coverage
> uploads,
>
> It would be great if this fixed size could be made more dynamically -
> this is an area where I could contribute.
>

Hi Clemens,
personally I'm on board with this and other changes, yet, the complete
lack of any response from Oracle people is a cold shower.

As far as I know it's impossible to get the code in without any support
from them, so it seems like even if we started the work again, it would
be destined to failure.

I still haven't looked in detail, but another approach I was considering
is to develop a improved rasterizer completely outside OpenJDK,
and just add in OpenJDK the bits needed to allow it being plugged in
(e.g., for example, by dropping a JAR and leveraging the usual SPI
mechanism)

This I hope would break the tension between our desire to improve things
in software rendering, and the need to get Oracle support at every step of
the way

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131111/30b2fa95/attachment.html>

From neugens.limasoftware at gmail.com  Mon Nov 11 10:21:25 2013
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Mon, 11 Nov 2013 11:21:25 +0100
Subject: [OpenJDK 2D-Dev] Resurrecting Lauren'ts work on speeding up
	Pisces
In-Reply-To: <CA+nxMTt_Fq7PkRMEDKpoOiCCh8-t6NJCrhxT=aWePawGJqturQ@mail.gmail.com>
References: <CA+nxMTv6-dfyAQ4HhSi-avEJ-tNaBYagi7Je-A7eMg_pdHdNQg@mail.gmail.com>
	<CAKjRUT69uEU5jCXPEWwVa+vOz2dLUFBFrj_4S9Tt4g9Ro4YmOw@mail.gmail.com>
	<CAFvQSYR0uroS2QQ_rUC+O5zsXn71OEHG9B=tKyJ9EFvV6EgJ5w@mail.gmail.com>
	<CA+nxMTtgCtvfUQTE=MYoTdEgwGfexhrZRJ6PfV3fug0wL85Tzw@mail.gmail.com>
	<CAFvQSYSubHt8q2crGYHSnQD0U9uFPUEPSx1uBX8JgPyK1Z_Hiw@mail.gmail.com>
	<CA+nxMTt_Fq7PkRMEDKpoOiCCh8-t6NJCrhxT=aWePawGJqturQ@mail.gmail.com>
Message-ID: <CAGUMyaT27i2YGiQwO2B591i4UTqWJYytBEdGmNW2jiixj1xjnA@mail.gmail.com>

Hello Andrea,

Unfortunately this is a known problem, and is especially difficult in your
case because you're tweaking an area that doesn't have many experts around
that can offer a careful review.

The idea to go on with a separate project pluggable in OpenJDK is good,
perhaps you could consider hosting it within IcedTea to be closer to
OpenJDK and/or starting a JEP?

I suggest though to not give up yet, I can assure you that there is a lot
of interest in what you are doing, even if there's currently a terrible
failure in communicating this to you.

Cheers,
Mario
Il 11/nov/2013 09:34 "Andrea Aime" <andrea.aime at geo-solutions.it> ha
scritto:

> On Mon, Nov 11, 2013 at 9:21 AM, Clemens Eisserer <linuxhippy at gmail.com>wrote:
>
>> Hi,
>>
>> One wish regarding pisces came into my mind:
>>
>> Currently all AA tile generators feed  32x32 coverage tiles to the
>> pipelines.
>> While this might be a good idea for software-only pipelines due to
>> good cache locality, it is a huge issue for at least the xrender
>> pipeline.
>> Each tile has to be uploaded seperately, which causes context switches
>> and GPU stalls - and I can't make use of the shared memory image
>> extension which should be quite benefitial for larger coverage
>> uploads,
>>
>> It would be great if this fixed size could be made more dynamically -
>> this is an area where I could contribute.
>>
>
> Hi Clemens,
> personally I'm on board with this and other changes, yet, the complete
> lack of any response from Oracle people is a cold shower.
>
> As far as I know it's impossible to get the code in without any support
> from them, so it seems like even if we started the work again, it would
> be destined to failure.
>
> I still haven't looked in detail, but another approach I was considering
> is to develop a improved rasterizer completely outside OpenJDK,
> and just add in OpenJDK the bits needed to allow it being plugged in
> (e.g., for example, by dropping a JAR and leveraging the usual SPI
> mechanism)
>
> This I hope would break the tension between our desire to improve things
> in software rendering, and the need to get Oracle support at every step of
> the way
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131111/295b0c6e/attachment.html>

From alexandr.scherbatiy at oracle.com  Mon Nov 11 15:59:22 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 11 Nov 2013 19:59:22 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5278D385.2000205@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com>
Message-ID: <5280FEDA.20202@oracle.com>


  Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8011059/webrev.06/

   Only internal API is exposed:
   - MultiResolutionImage interface with method 
"getResolutionVariant(int width, int height)" is added to the 
com.sun.awt package
   - Hints to switch on/off the resolution variant usage are added to 
SunHints class
   - Test is updated to use the  MultiResolutionImage interface

  Thanks,
  Alexandr.

On 11/5/2013 3:16 PM, Alexander Scherbatiy wrote:
>
>    Thank you for the review.
>
>   Could you look at the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>
>   - URL is parsed to protocol, host, port, and path parts in the 
> LWCToolkit class.
>      I checked that URL(protocol, host, port, file) constructor 
> correctly handles -1 port value.
>   - Only last file name after last '/' in the URL path  is converted 
> to @2x name
>   - Tests that check correct URL and path translation to @2x names are 
> added to the ScalableImageTest
>
>   Thanks,
>   Alexandr.
>
>
> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>
>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>> 2. I'm not sure that the proposed getScaledImageName() 
>>>> implementation in ScalableToolkitImage works perfectly for URLs 
>>>> like this:
>>>>
>>>> http://www.exampmle.com/dir/image
>>>>
>>>> In this case it will try to find 2x image here:
>>>>
>>>> http://www.example at 2x.com/dir/image
>>>>
>>>> which doesn't look correct.
>>>        Fixed. Only path part of a URL is converted to path2x. 
>>
>> Hi Alexander,
>>
>> URLs like this:
>>
>> http://www.example.com/dir.ext/image
>>
>> will still be translated to:
>>
>> http://www.example.com/dir at 2x.ext/image
>>
>>
>> I think you need to search for last '.' after the last  '/' in the 
>> getScaledImageName();
>>
>>
>> Also the following code has some additional bugs:
>>
>>   853         static Image toScalableImage(Image image, URL url) {
>>   854
>>   855             if (url != null && !url.toString().contains("@2x")
>>   856                     && !(image instanceof ScalableToolkitImage)) {
>>   857                 String protocol = url.getProtocol();
>>   858                 String host = url.getHost();
>>   859                 String file = url.getPath();
>>   860                 String file2x =*host +*getScaledImageName(file);
>>   861                 try {
>>   862                     URL url2x = new URL(protocol, host, file2x);
>>   863                     url2x.openStream();
>>   864                     return new ScalableToolkitImage(image, 
>> getDefaultToolkit().getImage(url2x));
>>   865                 } catch (Exception ignore) {
>>   866                 }
>>   867             }
>>   868             return image;
>>   869         }
>>
>> Why are you prepending *host* to getScaledImageName(file) in line 
>> 860? Let's take the following URL for example:
>>
>> http://www.example.com/dir/image.jpg
>>
>> protocol = "http"
>> host = "www.example.com"
>> file = "/dir/image.jpg"
>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>> url2x = URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>
>>
>> You are missing a part in URL (de)construction - the optional port! 
>> For example in the following URL:
>>
>> http://www.example.com:8080/dir/image.jpg
>>
>> You should extract the port from original URL and use it in new URL 
>> construction if present (!= -1).
>>
>>
>> I would also close the stream explicitly after probing for existence 
>> of resource rather than delegating to GC which might not be promptly 
>> and can cause resource exhaustion (think of MAX. # of open file 
>> descriptors):
>>
>>         try (InputStream probe = url.openStream()) {}
>>
>>
>>
>> Regards, Peter
>>
>>
>



From alexandr.scherbatiy at oracle.com  Tue Nov 12 15:05:29 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 12 Nov 2013 19:05:29 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <52CAC6A8CE5503408F3482C89035832809C4B16E@OC11EXPO27.exchange.mit.edu>
References: <52CAC6A8CE5503408F3482C89035832809C4B16E@OC11EXPO27.exchange.mit.edu>
Message-ID: <528243B9.20704@oracle.com>

On 11/7/2013 8:23 PM, Eirik Bakke wrote:
> Just passing by...
>
> Will retina-enabled Image objects work with Toolkit.createCustomCursor [1]
> under this patch?

    This patch allows to create an image with different resolutions that 
can be used for the custom cursor as well.
    To make it work with custom cursor it needs to properly  pass these 
images to the native system.

    I have created an issue to track this: JDK-8028212 Custom cursor 
HiDPI support
       https://bugs.openjdk.java.net/browse/JDK-8028212

   Thanks,
   Alexandr.

>
> (I have a spreadsheet application that requires an Excel-style "plus"
> cursor when the user hovers over it, and I'd like to supply a
> retina-enabled cursor image as well.)
>
> -- Eirik
>
> [1]
> http://docs.oracle.com/javase/6/docs/api/java/awt/Toolkit.html#createCustom
> Cursor(java.awt.Image, java.awt.Point, java.lang.String)
>
> On 11/5/13, 6:16 AM, "Alexander Scherbatiy"
> <alexandr.scherbatiy at oracle.com> wrote:
>
>>     Thank you for the review.
>>
>>    Could you look at the updated fix:
>>       http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>>
>>    - URL is parsed to protocol, host, port, and path parts in the
>> LWCToolkit class.
>>       I checked that URL(protocol, host, port, file) constructor
>> correctly handles -1 port value.
>>    - Only last file name after last '/' in the URL path  is converted to
>> @2x name
>>    - Tests that check correct URL and path translation to @2x names are
>> added to the ScalableImageTest
>>
>>    Thanks,
>>    Alexandr.
>>
>>
>> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>> implementation in ScalableToolkitImage works perfectly for URLs like
>>>>> this:
>>>>>
>>>>> http://www.exampmle.com/dir/image
>>>>>
>>>>> In this case it will try to find 2x image here:
>>>>>
>>>>> http://www.example at 2x.com/dir/image
>>>>>
>>>>> which doesn't look correct.
>>>>         Fixed. Only path part of a URL is converted to path2x.
>>> Hi Alexander,
>>>
>>> URLs like this:
>>>
>>> http://www.example.com/dir.ext/image
>>>
>>> will still be translated to:
>>>
>>> http://www.example.com/dir at 2x.ext/image
>>>
>>>
>>> I think you need to search for last '.' after the last  '/' in the
>>> getScaledImageName();
>>>
>>>
>>> Also the following code has some additional bugs:
>>>
>>>    853         static Image toScalableImage(Image image, URL url) {
>>>    854
>>>    855             if (url != null && !url.toString().contains("@2x")
>>>    856                     && !(image instanceof ScalableToolkitImage)) {
>>>    857                 String protocol = url.getProtocol();
>>>    858                 String host = url.getHost();
>>>    859                 String file = url.getPath();
>>>    860                 String file2x =*host +*getScaledImageName(file);
>>>    861                 try {
>>>    862                     URL url2x = new URL(protocol, host, file2x);
>>>    863                     url2x.openStream();
>>>    864                     return new ScalableToolkitImage(image,
>>> getDefaultToolkit().getImage(url2x));
>>>    865                 } catch (Exception ignore) {
>>>    866                 }
>>>    867             }
>>>    868             return image;
>>>    869         }
>>>
>>> Why are you prepending *host* to getScaledImageName(file) in line 860?
>>> Let's take the following URL for example:
>>>
>>> http://www.example.com/dir/image.jpg
>>>
>>> protocol = "http"
>>> host = "www.example.com"
>>> file = "/dir/image.jpg"
>>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>>> url2x = URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>>
>>>
>>> You are missing a part in URL (de)construction - the optional port!
>>> For example in the following URL:
>>>
>>> http://www.example.com:8080/dir/image.jpg
>>>
>>> You should extract the port from original URL and use it in new URL
>>> construction if present (!= -1).
>>>
>>>
>>> I would also close the stream explicitly after probing for existence
>>> of resource rather than delegating to GC which might not be promptly
>>> and can cause resource exhaustion (think of MAX. # of open file
>>> descriptors):
>>>
>>>          try (InputStream probe = url.openStream()) {}
>>>
>>>
>>>
>>> Regards, Peter
>>>
>>>



From james.graham at oracle.com  Tue Nov 12 19:43:59 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 12 Nov 2013 11:43:59 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5280FEDA.20202@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
Message-ID: <528284FF.3080007@oracle.com>

Hi Alexander,

Some minor issues with this fix:

- All RenderingHints have a default setting where the system can choose 
for you.  The primary thing that the default settings allow is for the 
answer to be based off of another hint.  Often the QUALITY hint provides 
the swing vote if an individual hint is left "DEFAULT".  That should 
probably also be the setting used for SG2D, and would hinge off of the 
devScale, for example, as the deciding factor.

- Descriptions for "on" and "off" should be something like "Use 
resolution variants of images" and "Use only default resolution variants 
of images" (and "Default resolution variant usage").  Most of the other 
descriptions on hints are statements of what is going to happen or what 
is going to be used rather than a simple 'the X state is Y'.

- It looks like the transform is used in SG2D to decide if the hiDPI 
image should be used.  I'm not familiar with the Mac's native use of 
@2x, but I thought that they hinged the decision off of the "retina 
scale" of the display, not off of the current transform.  That way, if 
you scale down an icon it doesn't change its look when it reaches .5x 
scale (or .75x depending on the cutoff).  Personally, I think it is 
better to not use the transform to keep animations smooth, but I'm not 
sure what Apple did.

- The logic in using the transform is also a bit murky.  I think if you 
set the scale on a retina display to exactly 1/2 it would use the HiDPI 
version even though the scale was 1:1.  Since I support not examining 
the transform there, I'm going to present this as another reason why we 
should just base it on devScale, but the logic could be fixed if we 
really plan to use the transform here.

- The new logic in "isHiDPIImage()" is confusing because you line up 
logic operations from 2 different levels of parentheses.  I believe that 
one version of our style guidelines included a rule that allowed 
"indenting to parentheses level" and I would think that would be a good 
rule to apply here.  Or do something else to make the logic flow there 
less tricky to read.

- Eventually we are going to need this support in more pipelines.  I 
believe that Win8 already has parameters that affect choices of images, 
but they are only currently deployed on the Surface tablets (i.e. there 
are no supported high DPI displays for desktop that I'm aware of, but 
some of the Surface tablets ship with high DPI screens).  What would the 
impact be if we moved this into a more general class in src/share?  I 
suppose we might spend extra time looking for variants of images that we 
don't need?

- Has any thought been given to the issues that someone raised with cursors?

- Has any thought been given to my comments about MediaTracker and image 
observer states for multi-res images?  I don't see any attempt here to 
preload the @2x image.  The problem would probably only be seen on 
multi-headed systems where one display is retina and one is not - you 
would find the images suddenly reloading when you move the window to the 
other screen and the application might not expect that to happen.  Which 
image is the Observer registered on?  Since the image is handed to the 
Observer, will an application be surprised when their observer gets a 
handle to an image they've never seen?  Is it an issue if one of the 
"alternate resolution variant" images leaks into an application's 
"hands" via the observer callbacks?

			...jim

On 11/11/13 7:59 AM, Alexander Scherbatiy wrote:
>
>   Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.06/
>
>    Only internal API is exposed:
>    - MultiResolutionImage interface with method
> "getResolutionVariant(int width, int height)" is added to the
> com.sun.awt package
>    - Hints to switch on/off the resolution variant usage are added to
> SunHints class
>    - Test is updated to use the  MultiResolutionImage interface
>
>   Thanks,
>   Alexandr.
>
> On 11/5/2013 3:16 PM, Alexander Scherbatiy wrote:
>>
>>    Thank you for the review.
>>
>>   Could you look at the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>>
>>   - URL is parsed to protocol, host, port, and path parts in the
>> LWCToolkit class.
>>      I checked that URL(protocol, host, port, file) constructor
>> correctly handles -1 port value.
>>   - Only last file name after last '/' in the URL path  is converted
>> to @2x name
>>   - Tests that check correct URL and path translation to @2x names are
>> added to the ScalableImageTest
>>
>>   Thanks,
>>   Alexandr.
>>
>>
>> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>>
>>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>> implementation in ScalableToolkitImage works perfectly for URLs
>>>>> like this:
>>>>>
>>>>> http://www.exampmle.com/dir/image
>>>>>
>>>>> In this case it will try to find 2x image here:
>>>>>
>>>>> http://www.example at 2x.com/dir/image
>>>>>
>>>>> which doesn't look correct.
>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>
>>> Hi Alexander,
>>>
>>> URLs like this:
>>>
>>> http://www.example.com/dir.ext/image
>>>
>>> will still be translated to:
>>>
>>> http://www.example.com/dir at 2x.ext/image
>>>
>>>
>>> I think you need to search for last '.' after the last  '/' in the
>>> getScaledImageName();
>>>
>>>
>>> Also the following code has some additional bugs:
>>>
>>>   853         static Image toScalableImage(Image image, URL url) {
>>>   854
>>>   855             if (url != null && !url.toString().contains("@2x")
>>>   856                     && !(image instanceof ScalableToolkitImage)) {
>>>   857                 String protocol = url.getProtocol();
>>>   858                 String host = url.getHost();
>>>   859                 String file = url.getPath();
>>>   860                 String file2x =*host +*getScaledImageName(file);
>>>   861                 try {
>>>   862                     URL url2x = new URL(protocol, host, file2x);
>>>   863                     url2x.openStream();
>>>   864                     return new ScalableToolkitImage(image,
>>> getDefaultToolkit().getImage(url2x));
>>>   865                 } catch (Exception ignore) {
>>>   866                 }
>>>   867             }
>>>   868             return image;
>>>   869         }
>>>
>>> Why are you prepending *host* to getScaledImageName(file) in line
>>> 860? Let's take the following URL for example:
>>>
>>> http://www.example.com/dir/image.jpg
>>>
>>> protocol = "http"
>>> host = "www.example.com"
>>> file = "/dir/image.jpg"
>>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>>> url2x = URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>>
>>>
>>> You are missing a part in URL (de)construction - the optional port!
>>> For example in the following URL:
>>>
>>> http://www.example.com:8080/dir/image.jpg
>>>
>>> You should extract the port from original URL and use it in new URL
>>> construction if present (!= -1).
>>>
>>>
>>> I would also close the stream explicitly after probing for existence
>>> of resource rather than delegating to GC which might not be promptly
>>> and can cause resource exhaustion (think of MAX. # of open file
>>> descriptors):
>>>
>>>         try (InputStream probe = url.openStream()) {}
>>>
>>>
>>>
>>> Regards, Peter
>>>
>>>
>>
>


From james.graham at oracle.com  Tue Nov 12 19:49:37 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 12 Nov 2013 11:49:37 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <528284FF.3080007@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com>
Message-ID: <52828651.50706@oracle.com>

That last bullet item (or 2) is actually a bigger issue because I think 
we've been ignoring it in coming up with the implementation, but it 
could have a simple fix...

			...jim

On 11/12/13 11:43 AM, Jim Graham wrote:
> Hi Alexander,
>
> Some minor issues with this fix:
>
> - All RenderingHints have a default setting where the system can choose
> for you.  The primary thing that the default settings allow is for the
> answer to be based off of another hint.  Often the QUALITY hint provides
> the swing vote if an individual hint is left "DEFAULT".  That should
> probably also be the setting used for SG2D, and would hinge off of the
> devScale, for example, as the deciding factor.
>
> - Descriptions for "on" and "off" should be something like "Use
> resolution variants of images" and "Use only default resolution variants
> of images" (and "Default resolution variant usage").  Most of the other
> descriptions on hints are statements of what is going to happen or what
> is going to be used rather than a simple 'the X state is Y'.
>
> - It looks like the transform is used in SG2D to decide if the hiDPI
> image should be used.  I'm not familiar with the Mac's native use of
> @2x, but I thought that they hinged the decision off of the "retina
> scale" of the display, not off of the current transform.  That way, if
> you scale down an icon it doesn't change its look when it reaches .5x
> scale (or .75x depending on the cutoff).  Personally, I think it is
> better to not use the transform to keep animations smooth, but I'm not
> sure what Apple did.
>
> - The logic in using the transform is also a bit murky.  I think if you
> set the scale on a retina display to exactly 1/2 it would use the HiDPI
> version even though the scale was 1:1.  Since I support not examining
> the transform there, I'm going to present this as another reason why we
> should just base it on devScale, but the logic could be fixed if we
> really plan to use the transform here.
>
> - The new logic in "isHiDPIImage()" is confusing because you line up
> logic operations from 2 different levels of parentheses.  I believe that
> one version of our style guidelines included a rule that allowed
> "indenting to parentheses level" and I would think that would be a good
> rule to apply here.  Or do something else to make the logic flow there
> less tricky to read.
>
> - Eventually we are going to need this support in more pipelines.  I
> believe that Win8 already has parameters that affect choices of images,
> but they are only currently deployed on the Surface tablets (i.e. there
> are no supported high DPI displays for desktop that I'm aware of, but
> some of the Surface tablets ship with high DPI screens).  What would the
> impact be if we moved this into a more general class in src/share?  I
> suppose we might spend extra time looking for variants of images that we
> don't need?
>
> - Has any thought been given to the issues that someone raised with
> cursors?
>
> - Has any thought been given to my comments about MediaTracker and image
> observer states for multi-res images?  I don't see any attempt here to
> preload the @2x image.  The problem would probably only be seen on
> multi-headed systems where one display is retina and one is not - you
> would find the images suddenly reloading when you move the window to the
> other screen and the application might not expect that to happen.  Which
> image is the Observer registered on?  Since the image is handed to the
> Observer, will an application be surprised when their observer gets a
> handle to an image they've never seen?  Is it an issue if one of the
> "alternate resolution variant" images leaks into an application's
> "hands" via the observer callbacks?
>
>              ...jim
>
> On 11/11/13 7:59 AM, Alexander Scherbatiy wrote:
>>
>>   Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.06/
>>
>>    Only internal API is exposed:
>>    - MultiResolutionImage interface with method
>> "getResolutionVariant(int width, int height)" is added to the
>> com.sun.awt package
>>    - Hints to switch on/off the resolution variant usage are added to
>> SunHints class
>>    - Test is updated to use the  MultiResolutionImage interface
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 11/5/2013 3:16 PM, Alexander Scherbatiy wrote:
>>>
>>>    Thank you for the review.
>>>
>>>   Could you look at the updated fix:
>>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>>>
>>>   - URL is parsed to protocol, host, port, and path parts in the
>>> LWCToolkit class.
>>>      I checked that URL(protocol, host, port, file) constructor
>>> correctly handles -1 port value.
>>>   - Only last file name after last '/' in the URL path  is converted
>>> to @2x name
>>>   - Tests that check correct URL and path translation to @2x names are
>>> added to the ScalableImageTest
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>
>>> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>>>
>>>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>> implementation in ScalableToolkitImage works perfectly for URLs
>>>>>> like this:
>>>>>>
>>>>>> http://www.exampmle.com/dir/image
>>>>>>
>>>>>> In this case it will try to find 2x image here:
>>>>>>
>>>>>> http://www.example at 2x.com/dir/image
>>>>>>
>>>>>> which doesn't look correct.
>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>
>>>> Hi Alexander,
>>>>
>>>> URLs like this:
>>>>
>>>> http://www.example.com/dir.ext/image
>>>>
>>>> will still be translated to:
>>>>
>>>> http://www.example.com/dir at 2x.ext/image
>>>>
>>>>
>>>> I think you need to search for last '.' after the last  '/' in the
>>>> getScaledImageName();
>>>>
>>>>
>>>> Also the following code has some additional bugs:
>>>>
>>>>   853         static Image toScalableImage(Image image, URL url) {
>>>>   854
>>>>   855             if (url != null && !url.toString().contains("@2x")
>>>>   856                     && !(image instanceof
>>>> ScalableToolkitImage)) {
>>>>   857                 String protocol = url.getProtocol();
>>>>   858                 String host = url.getHost();
>>>>   859                 String file = url.getPath();
>>>>   860                 String file2x =*host +*getScaledImageName(file);
>>>>   861                 try {
>>>>   862                     URL url2x = new URL(protocol, host, file2x);
>>>>   863                     url2x.openStream();
>>>>   864                     return new ScalableToolkitImage(image,
>>>> getDefaultToolkit().getImage(url2x));
>>>>   865                 } catch (Exception ignore) {
>>>>   866                 }
>>>>   867             }
>>>>   868             return image;
>>>>   869         }
>>>>
>>>> Why are you prepending *host* to getScaledImageName(file) in line
>>>> 860? Let's take the following URL for example:
>>>>
>>>> http://www.example.com/dir/image.jpg
>>>>
>>>> protocol = "http"
>>>> host = "www.example.com"
>>>> file = "/dir/image.jpg"
>>>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>>>> url2x = URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>>>
>>>>
>>>> You are missing a part in URL (de)construction - the optional port!
>>>> For example in the following URL:
>>>>
>>>> http://www.example.com:8080/dir/image.jpg
>>>>
>>>> You should extract the port from original URL and use it in new URL
>>>> construction if present (!= -1).
>>>>
>>>>
>>>> I would also close the stream explicitly after probing for existence
>>>> of resource rather than delegating to GC which might not be promptly
>>>> and can cause resource exhaustion (think of MAX. # of open file
>>>> descriptors):
>>>>
>>>>         try (InputStream probe = url.openStream()) {}
>>>>
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>
>>>
>>


From linuxhippy at gmail.com  Tue Nov 12 20:20:41 2013
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Tue, 12 Nov 2013 15:20:41 -0500
Subject: [OpenJDK 2D-Dev] RFR: Fix for 8027541: Fully transparent jframe
	becomes black.
In-Reply-To: <527D65C7.9070707@oracle.com>
References: <527D65C7.9070707@oracle.com>
Message-ID: <CAFvQSYS2qME232u9=Pjp9oMhEDgjMQPpHZTOQbc18-DXuKZVtg@mail.gmail.com>

Hi Phil,

> http://cr.openjdk.java.net/~prr/8027541/
>
> In the case where there is an alpha color on the window, the
> X11 pipeline looks at the color model of the GraphicsConfiguration
> and upgrades the surface to one with alpha. This makes the Xrender
> pipeline do the same. SQE test failure, so no regression test needed
> in this case.

Thanks for taking care of this one.
The fix looks fine to me.

Regards, Clemens


From james.graham at oracle.com  Tue Nov 12 21:09:03 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 12 Nov 2013 13:09:03 -0800
Subject: [OpenJDK 2D-Dev] Resurrecting Lauren'ts work on speeding up
	Pisces
In-Reply-To: <CA+nxMTt_Fq7PkRMEDKpoOiCCh8-t6NJCrhxT=aWePawGJqturQ@mail.gmail.com>
References: <CA+nxMTv6-dfyAQ4HhSi-avEJ-tNaBYagi7Je-A7eMg_pdHdNQg@mail.gmail.com>
	<CAKjRUT69uEU5jCXPEWwVa+vOz2dLUFBFrj_4S9Tt4g9Ro4YmOw@mail.gmail.com>
	<CAFvQSYR0uroS2QQ_rUC+O5zsXn71OEHG9B=tKyJ9EFvV6EgJ5w@mail.gmail.com>
	<CA+nxMTtgCtvfUQTE=MYoTdEgwGfexhrZRJ6PfV3fug0wL85Tzw@mail.gmail.com>
	<CAFvQSYSubHt8q2crGYHSnQD0U9uFPUEPSx1uBX8JgPyK1Z_Hiw@mail.gmail.com>
	<CA+nxMTt_Fq7PkRMEDKpoOiCCh8-t6NJCrhxT=aWePawGJqturQ@mail.gmail.com>
Message-ID: <528298EF.4080807@oracle.com>

Hi Andrea,

I think the problem is that there really aren't a lot of people working 
directly on the JDK any more with direct experience with rasterizers. 
For my day to day responsibilities, I have been officially working on 
JavaFX for a couple of years, but I am also the engineer with the most 
knowledge about the rasterizer in the JDK, either the Open version or 
the Oracle version.  As such, I don't always pay attention to 
discussions here which only occasionally bring up areas that I am 
familiar with, but I've worked with Laurent in the past to provide 
feedback on improving the rasterizer.

I've also wanted to drop the proprietary rasterizer in the JDK for a 
long time, if we can get the OpenJDK rasterizer up to the same speed in 
the same situations.  I think Laurent was pretty much there which means 
if we can get that work in then we might be able to delete one last 
proprietary plug / difference between the two JDK versions.

Now that I'm aware of your efforts to continue that work, I'll keep an 
eye out for this discussion more, but please feel free to ping me 
directly if your questions aren't getting answered (note that addressing 
me directly on the forum doesn't necessarily catch my attention due to 
mail filtering unfortunately).

JDK 8 is currently only accepting work that solves critical blocking 
bugs at this point, so any work submitted now would have to go into JDK 
9.  Getting it in to 9 early means lots of time to find bugs and have 
more developers testing it by using it...

			...jim

On 11/11/13 12:33 AM, Andrea Aime wrote:
> On Mon, Nov 11, 2013 at 9:21 AM, Clemens Eisserer <linuxhippy at gmail.com
> <mailto:linuxhippy at gmail.com>> wrote:
>
>     Hi,
>
>     One wish regarding pisces came into my mind:
>
>     Currently all AA tile generators feed  32x32 coverage tiles to the
>     pipelines.
>     While this might be a good idea for software-only pipelines due to
>     good cache locality, it is a huge issue for at least the xrender
>     pipeline.
>     Each tile has to be uploaded seperately, which causes context switches
>     and GPU stalls - and I can't make use of the shared memory image
>     extension which should be quite benefitial for larger coverage
>     uploads,
>
>     It would be great if this fixed size could be made more dynamically -
>     this is an area where I could contribute.
>
>
> Hi Clemens,
> personally I'm on board with this and other changes, yet, the complete
> lack of any response from Oracle people is a cold shower.
>
> As far as I know it's impossible to get the code in without any support
> from them, so it seems like even if we started the work again, it would
> be destined to failure.
>
> I still haven't looked in detail, but another approach I was considering
> is to develop a improved rasterizer completely outside OpenJDK,
> and just add in OpenJDK the bits needed to allow it being plugged in
> (e.g., for example, by dropping a JAR and leveraging the usual SPI
> mechanism)
>
> This I hope would break the tension between our desire to improve things
> in software rendering, and the need to get Oracle support at every step
> of the way
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
> more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------


From james.graham at oracle.com  Tue Nov 12 21:14:11 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 12 Nov 2013 13:14:11 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <52828651.50706@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <52828651.50706@oracle.com>
Message-ID: <52829A23.5030101@oracle.com>



On 11/12/13 11:49 AM, Jim Graham wrote:
> On 11/12/13 11:43 AM, Jim Graham wrote:
>> Hi Alexander,
>>
>> Some minor issues with this fix:
>>
>> - Descriptions for "on" and "off" should be something like "Use
>> resolution variants of images" and "Use only default resolution variants
>> of images" (and "Default resolution variant usage").  Most of the other
>> descriptions on hints are statements of what is going to happen or what
>> is going to be used rather than a simple 'the X state is Y'.

Reading this after the fact I realize that the word "default" is being 
used in two different ways in the descriptions I proposed.  Perhaps:

ON - Always use resolution-specific variants of images
OFF - Use only the standard resolution of an image
DEFAULT - Choose image resolutions based on a default heuristic

(perhaps add "(when available)" to ON?)

			...jim


From swingler at apple.com  Wed Nov 13 01:48:41 2013
From: swingler at apple.com (Mike Swingler)
Date: Tue, 12 Nov 2013 17:48:41 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <528284FF.3080007@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com>
Message-ID: <71FAFA92-CEDB-4E37-BA54-92DA3B3DE8CA@apple.com>

On Nov 12, 2013, at 11:43 AM, Jim Graham <james.graham at oracle.com> wrote:

> - It looks like the transform is used in SG2D to decide if the hiDPI image should be used.  I'm not familiar with the Mac's native use of @2x, but I thought that they hinged the decision off of the "retina scale" of the display, not off of the current transform.  That way, if you scale down an icon it doesn't change its look when it reaches .5x scale (or .75x depending on the cutoff). Personally, I think it is better to not use the transform to keep animations smooth, but I'm not sure what Apple did.

The -[NSWindow backingScaleFactor] is the basic primitive that other forms of coordinate translation key off of. Keep in mind that this value will dynamically change as the window moves from display to display.

Regards,
Mike Swingler
Apple Inc.



From james.graham at oracle.com  Wed Nov 13 01:52:22 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 12 Nov 2013 17:52:22 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <71FAFA92-CEDB-4E37-BA54-92DA3B3DE8CA@apple.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com>
	<71FAFA92-CEDB-4E37-BA54-92DA3B3DE8CA@apple.com>
Message-ID: <5282DB56.7090306@oracle.com>

Hi Mike,

Just to confirm and be explicit, the Mac will choose the @2x version of an image if that call returns 2.0 even if the user is rendering with a transform that scales by .001?

		...jim

On 11/12/2013 5:48 PM, Mike Swingler wrote:
> On Nov 12, 2013, at 11:43 AM, Jim Graham <james.graham at oracle.com> wrote:
>
>> - It looks like the transform is used in SG2D to decide if the hiDPI image should be used.  I'm not familiar with the Mac's native use of @2x, but I thought that they hinged the decision off of the "retina scale" of the display, not off of the current transform.  That way, if you scale down an icon it doesn't change its look when it reaches .5x scale (or .75x depending on the cutoff). Personally, I think it is better to not use the transform to keep animations smooth, but I'm not sure what Apple did.
>
> The -[NSWindow backingScaleFactor] is the basic primitive that other forms of coordinate translation key off of. Keep in mind that this value will dynamically change as the window moves from display to display.
>
> Regards,
> Mike Swingler
> Apple Inc.
>


From swingler at apple.com  Wed Nov 13 02:46:46 2013
From: swingler at apple.com (Mike Swingler)
Date: Tue, 12 Nov 2013 18:46:46 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5282DB56.7090306@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com>
	<71FAFA92-CEDB-4E37-BA54-92DA3B3DE8CA@apple.com>
	<5282DB56.7090306@oracle.com>
Message-ID: <1495A1F8-8D5B-403A-9292-6BCF27518254@apple.com>

The story is a little more complicated: NSImage always picks the "best" representation based on the computed size of the backing pixel rect taking all graphics transforms into account. For icons, which usually have dozens of representations, there isn't a single "@2x" representation.

This means that by switching screens, an icon can flip from a cartoonish 16x16 rep to a photo-realistic 128x128 scaled down to 32x32 if those are the only reps available. The multi-rep support in NSImage can also defer to a PDF representation if available when it can't find an exact dimension and bit-depth match for raster representations.

This does mean that an icon with 12 or so representations will visually glitch when smooth scaled as bits of detail come and go...but in the general case, most images tend to only have 2 reps and developers don't animate between them.

So to be explicit: no, NSImage Cocoa drawing will not choose the @2x version if the transform causes the rect in the pixel backing store to be the same size or smaller than the @1x.

I'll privately send along a little app that demonstrates this.

Regards,
Mike Swingler
Apple Inc.

On Nov 12, 2013, at 5:52 PM, Jim Graham <james.graham at oracle.com> wrote:

> Hi Mike,
> 
> Just to confirm and be explicit, the Mac will choose the @2x version of an image if that call returns 2.0 even if the user is rendering with a transform that scales by .001?
> 
> 		...jim
> 
> On 11/12/2013 5:48 PM, Mike Swingler wrote:
>> On Nov 12, 2013, at 11:43 AM, Jim Graham <james.graham at oracle.com> wrote:
>> 
>>> - It looks like the transform is used in SG2D to decide if the hiDPI image should be used.  I'm not familiar with the Mac's native use of @2x, but I thought that they hinged the decision off of the "retina scale" of the display, not off of the current transform.  That way, if you scale down an icon it doesn't change its look when it reaches .5x scale (or .75x depending on the cutoff). Personally, I think it is better to not use the transform to keep animations smooth, but I'm not sure what Apple did.
>> 
>> The -[NSWindow backingScaleFactor] is the basic primitive that other forms of coordinate translation key off of. Keep in mind that this value will dynamically change as the window moves from display to display.
>> 
>> Regards,
>> Mike Swingler
>> Apple Inc.
>> 



From james.graham at oracle.com  Wed Nov 13 03:10:23 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 12 Nov 2013 19:10:23 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <1495A1F8-8D5B-403A-9292-6BCF27518254@apple.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com>
	<71FAFA92-CEDB-4E37-BA54-92DA3B3DE8CA@apple.com>
	<5282DB56.7090306@oracle.com>
	<1495A1F8-8D5B-403A-9292-6BCF27518254@apple.com>
Message-ID: <5282ED9F.805@oracle.com>

So, then, it sounds like on the Mac the "default heuristic" should be to 
take the transform into account and choose @2x based on that.  We don't 
yet know if that matches the default Windows 8 heuristics, but we only 
have 1 platform that has this enabled so far.

One last question (OK 2) for Mike - I want to be sure that we get the 
algorithm right, you said "if the backing store would be the same size 
or smaller than the @1x" which implies that the code in the fix "if (w 
<= imgw && h <= imgh) regular : @2x" matches the heuristics in Cocoa? 
(i.e. && and <= are the correct comparison and logic?)

And question #2, if they are running on a display with pixel scale of 
1.0, does the @2x get chosen when they scale up?  Or do the @2x media 
only even get considered on pixel scaled displays?

Given that, I'd recommend:

- Add the DEFAULT setting for the SunHint which will basically say "do 
as Mac does when on a Mac"  (and eventually as Win8 does while on Win8, 
etc.)

- the current fix has the choice in the macosx code, which is good

- the current API provides the scaled dimensions, which is good for the 
mac code, but we may need to make more data available once we learn how 
other platforms solve this problem

- we may want to beef up the hints later with "choose based on Screen" 
vs "choose based on pixel size", but for now this API is sun.* private 
so lets just leave it with ON/OFF/DEFAULT.

- Hopefully the answers to the above 2 questions for Mike won't be 
surprising...

			...jim

On 11/12/13 6:46 PM, Mike Swingler wrote:
> The story is a little more complicated: NSImage always picks the "best" representation based on the computed size of the backing pixel rect taking all graphics transforms into account. For icons, which usually have dozens of representations, there isn't a single "@2x" representation.
>
> This means that by switching screens, an icon can flip from a cartoonish 16x16 rep to a photo-realistic 128x128 scaled down to 32x32 if those are the only reps available. The multi-rep support in NSImage can also defer to a PDF representation if available when it can't find an exact dimension and bit-depth match for raster representations.
>
> This does mean that an icon with 12 or so representations will visually glitch when smooth scaled as bits of detail come and go...but in the general case, most images tend to only have 2 reps and developers don't animate between them.
>
> So to be explicit: no, NSImage Cocoa drawing will not choose the @2x version if the transform causes the rect in the pixel backing store to be the same size or smaller than the @1x.
>
> I'll privately send along a little app that demonstrates this.
>
> Regards,
> Mike Swingler
> Apple Inc.
>
> On Nov 12, 2013, at 5:52 PM, Jim Graham <james.graham at oracle.com> wrote:
>
>> Hi Mike,
>>
>> Just to confirm and be explicit, the Mac will choose the @2x version of an image if that call returns 2.0 even if the user is rendering with a transform that scales by .001?
>>
>> 		...jim
>>
>> On 11/12/2013 5:48 PM, Mike Swingler wrote:
>>> On Nov 12, 2013, at 11:43 AM, Jim Graham <james.graham at oracle.com> wrote:
>>>
>>>> - It looks like the transform is used in SG2D to decide if the hiDPI image should be used.  I'm not familiar with the Mac's native use of @2x, but I thought that they hinged the decision off of the "retina scale" of the display, not off of the current transform.  That way, if you scale down an icon it doesn't change its look when it reaches .5x scale (or .75x depending on the cutoff). Personally, I think it is better to not use the transform to keep animations smooth, but I'm not sure what Apple did.
>>>
>>> The -[NSWindow backingScaleFactor] is the basic primitive that other forms of coordinate translation key off of. Keep in mind that this value will dynamically change as the window moves from display to display.
>>>
>>> Regards,
>>> Mike Swingler
>>> Apple Inc.
>>>
>


From Sergey.Bylokhov at oracle.com  Wed Nov 13 12:33:35 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Nov 2013 16:33:35 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <528284FF.3080007@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com>
Message-ID: <5283719F.1030700@oracle.com>

On 12.11.2013 23:43, Jim Graham wrote:
> Hi Alexander,
>
> Some minor issues with this fix:
>
> - It looks like the transform is used in SG2D to decide if the hiDPI 
> image should be used.  I'm not familiar with the Mac's native use of 
> @2x, but I thought that they hinged the decision off of the "retina 
> scale" of the display, not off of the current transform.  That way, if 
> you scale down an icon it doesn't change its look when it reaches .5x 
> scale (or .75x depending on the cutoff).  Personally, I think it is 
> better to not use the transform to keep animations smooth, but I'm not 
> sure what Apple did.
>
> - The logic in using the transform is also a bit murky.  I think if 
> you set the scale on a retina display to exactly 1/2 it would use the 
> HiDPI version even though the scale was 1:1.  Since I support not 
> examining the transform there, I'm going to present this as another 
> reason why we should just base it on devScale, but the logic could be 
> fixed if we really plan to use the transform here.
It also allow to the user to use a transform and a hint and force the 
images to draw the scaled version even to the BufferedImage fo ex. Which 
can be useful in case of sequential drawing of BI-> BI->retina.
> - Has any thought been given to my comments about MediaTracker and 
> image observer states for multi-res images?  I don't see any attempt 
> here to preload the @2x image.  The problem would probably only be 
> seen on multi-headed systems where one display is retina and one is 
> not - you would find the images suddenly reloading when you move the 
> window to the other screen and the application might not expect that 
> to happen.  Which image is the Observer registered on?  Since the 
> image is handed to the Observer, will an application be surprised when 
> their observer gets a handle to an image they've never seen?  Is it an 
> issue if one of the "alternate resolution variant" images leaks into 
> an application's "hands" via the observer callbacks?
That's could be a problem. Is it possible to wrap imageObserver, which 
was passed to the drawImage, and replace one image to another in the 
WrapperImageObserver.imageUpdate()?
>
>             ...jim
>
> On 11/11/13 7:59 AM, Alexander Scherbatiy wrote:
>>
>>   Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.06/
>>
>>    Only internal API is exposed:
>>    - MultiResolutionImage interface with method
>> "getResolutionVariant(int width, int height)" is added to the
>> com.sun.awt package
>>    - Hints to switch on/off the resolution variant usage are added to
>> SunHints class
>>    - Test is updated to use the  MultiResolutionImage interface
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 11/5/2013 3:16 PM, Alexander Scherbatiy wrote:
>>>
>>>    Thank you for the review.
>>>
>>>   Could you look at the updated fix:
>>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>>>
>>>   - URL is parsed to protocol, host, port, and path parts in the
>>> LWCToolkit class.
>>>      I checked that URL(protocol, host, port, file) constructor
>>> correctly handles -1 port value.
>>>   - Only last file name after last '/' in the URL path  is converted
>>> to @2x name
>>>   - Tests that check correct URL and path translation to @2x names are
>>> added to the ScalableImageTest
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>
>>> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>>>
>>>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>> implementation in ScalableToolkitImage works perfectly for URLs
>>>>>> like this:
>>>>>>
>>>>>> http://www.exampmle.com/dir/image
>>>>>>
>>>>>> In this case it will try to find 2x image here:
>>>>>>
>>>>>> http://www.example at 2x.com/dir/image
>>>>>>
>>>>>> which doesn't look correct.
>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>
>>>> Hi Alexander,
>>>>
>>>> URLs like this:
>>>>
>>>> http://www.example.com/dir.ext/image
>>>>
>>>> will still be translated to:
>>>>
>>>> http://www.example.com/dir at 2x.ext/image
>>>>
>>>>
>>>> I think you need to search for last '.' after the last  '/' in the
>>>> getScaledImageName();
>>>>
>>>>
>>>> Also the following code has some additional bugs:
>>>>
>>>>   853         static Image toScalableImage(Image image, URL url) {
>>>>   854
>>>>   855             if (url != null && !url.toString().contains("@2x")
>>>>   856                     && !(image instanceof 
>>>> ScalableToolkitImage)) {
>>>>   857                 String protocol = url.getProtocol();
>>>>   858                 String host = url.getHost();
>>>>   859                 String file = url.getPath();
>>>>   860                 String file2x =*host +*getScaledImageName(file);
>>>>   861                 try {
>>>>   862                     URL url2x = new URL(protocol, host, file2x);
>>>>   863                     url2x.openStream();
>>>>   864                     return new ScalableToolkitImage(image,
>>>> getDefaultToolkit().getImage(url2x));
>>>>   865                 } catch (Exception ignore) {
>>>>   866                 }
>>>>   867             }
>>>>   868             return image;
>>>>   869         }
>>>>
>>>> Why are you prepending *host* to getScaledImageName(file) in line
>>>> 860? Let's take the following URL for example:
>>>>
>>>> http://www.example.com/dir/image.jpg
>>>>
>>>> protocol = "http"
>>>> host = "www.example.com"
>>>> file = "/dir/image.jpg"
>>>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>>>> url2x = 
>>>> URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>>>
>>>>
>>>> You are missing a part in URL (de)construction - the optional port!
>>>> For example in the following URL:
>>>>
>>>> http://www.example.com:8080/dir/image.jpg
>>>>
>>>> You should extract the port from original URL and use it in new URL
>>>> construction if present (!= -1).
>>>>
>>>>
>>>> I would also close the stream explicitly after probing for existence
>>>> of resource rather than delegating to GC which might not be promptly
>>>> and can cause resource exhaustion (think of MAX. # of open file
>>>> descriptors):
>>>>
>>>>         try (InputStream probe = url.openStream()) {}
>>>>
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>
>>>
>>


-- 
Best regards, Sergey.



From alexandr.scherbatiy at oracle.com  Wed Nov 13 16:11:16 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 13 Nov 2013 20:11:16 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <528284FF.3080007@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com>
Message-ID: <5283A4A4.60007@oracle.com>


   Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8011059/webrev.07/

   -  The default sun hint is added.
      However, it looks the same as the resolution variant ON hint right 
now. It would better to leave the behavior on the non HiDPI displays the 
same as it was before.
      So the resolution variant hint is disabled by default for non 
HiDPI displays.
   - Resolution variant hints description is updated.
   - The logic operator in the  isHiDPIImage() method is formatted.

    The @2x images are not preloaded in the LWCToolkit. It really can 
cause image reloading after moving a window from a display from one 
resolution to another.
    However, it is not clear during the MultiResolutionImage creation 
will the images be used on HiDPI displays or not.
    May be there should be a flag that enables the high resolution 
images preloading.

   The original image can be replaced by the high resolution one in the 
paint() method. It causes that the observer could get an image which is 
different from the original one.
   May be there is no any issue?  If a MultiResolutionImage is not used 
then all works as before. If a user implements MultiResolutionImage may 
be he needs to have an information
   about the actual drawn image in the observer even it is different 
from the original.

   Thanks,
   Alexandr.


On 11/12/2013 11:43 PM, Jim Graham wrote:
> Hi Alexander,
>
> Some minor issues with this fix:
>
> - All RenderingHints have a default setting where the system can 
> choose for you.  The primary thing that the default settings allow is 
> for the answer to be based off of another hint.  Often the QUALITY 
> hint provides the swing vote if an individual hint is left "DEFAULT".  
> That should probably also be the setting used for SG2D, and would 
> hinge off of the devScale, for example, as the deciding factor.
>
> - Descriptions for "on" and "off" should be something like "Use 
> resolution variants of images" and "Use only default resolution 
> variants of images" (and "Default resolution variant usage"). Most of 
> the other descriptions on hints are statements of what is going to 
> happen or what is going to be used rather than a simple 'the X state 
> is Y'.
>
> - It looks like the transform is used in SG2D to decide if the hiDPI 
> image should be used.  I'm not familiar with the Mac's native use of 
> @2x, but I thought that they hinged the decision off of the "retina 
> scale" of the display, not off of the current transform.  That way, if 
> you scale down an icon it doesn't change its look when it reaches .5x 
> scale (or .75x depending on the cutoff).  Personally, I think it is 
> better to not use the transform to keep animations smooth, but I'm not 
> sure what Apple did.
>
> - The logic in using the transform is also a bit murky.  I think if 
> you set the scale on a retina display to exactly 1/2 it would use the 
> HiDPI version even though the scale was 1:1.  Since I support not 
> examining the transform there, I'm going to present this as another 
> reason why we should just base it on devScale, but the logic could be 
> fixed if we really plan to use the transform here.
>
> - The new logic in "isHiDPIImage()" is confusing because you line up 
> logic operations from 2 different levels of parentheses.  I believe 
> that one version of our style guidelines included a rule that allowed 
> "indenting to parentheses level" and I would think that would be a 
> good rule to apply here.  Or do something else to make the logic flow 
> there less tricky to read.
>
> - Eventually we are going to need this support in more pipelines. I 
> believe that Win8 already has parameters that affect choices of 
> images, but they are only currently deployed on the Surface tablets 
> (i.e. there are no supported high DPI displays for desktop that I'm 
> aware of, but some of the Surface tablets ship with high DPI 
> screens).  What would the impact be if we moved this into a more 
> general class in src/share?  I suppose we might spend extra time 
> looking for variants of images that we don't need?
>
> - Has any thought been given to the issues that someone raised with 
> cursors?
>
> - Has any thought been given to my comments about MediaTracker and 
> image observer states for multi-res images?  I don't see any attempt 
> here to preload the @2x image.  The problem would probably only be 
> seen on multi-headed systems where one display is retina and one is 
> not - you would find the images suddenly reloading when you move the 
> window to the other screen and the application might not expect that 
> to happen.  Which image is the Observer registered on?  Since the 
> image is handed to the Observer, will an application be surprised when 
> their observer gets a handle to an image they've never seen?  Is it an 
> issue if one of the "alternate resolution variant" images leaks into 
> an application's "hands" via the observer callbacks?
>
>             ...jim
>
> On 11/11/13 7:59 AM, Alexander Scherbatiy wrote:
>>
>>   Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.06/
>>
>>    Only internal API is exposed:
>>    - MultiResolutionImage interface with method
>> "getResolutionVariant(int width, int height)" is added to the
>> com.sun.awt package
>>    - Hints to switch on/off the resolution variant usage are added to
>> SunHints class
>>    - Test is updated to use the  MultiResolutionImage interface
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 11/5/2013 3:16 PM, Alexander Scherbatiy wrote:
>>>
>>>    Thank you for the review.
>>>
>>>   Could you look at the updated fix:
>>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>>>
>>>   - URL is parsed to protocol, host, port, and path parts in the
>>> LWCToolkit class.
>>>      I checked that URL(protocol, host, port, file) constructor
>>> correctly handles -1 port value.
>>>   - Only last file name after last '/' in the URL path  is converted
>>> to @2x name
>>>   - Tests that check correct URL and path translation to @2x names are
>>> added to the ScalableImageTest
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>
>>> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>>>
>>>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>> implementation in ScalableToolkitImage works perfectly for URLs
>>>>>> like this:
>>>>>>
>>>>>> http://www.exampmle.com/dir/image
>>>>>>
>>>>>> In this case it will try to find 2x image here:
>>>>>>
>>>>>> http://www.example at 2x.com/dir/image
>>>>>>
>>>>>> which doesn't look correct.
>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>
>>>> Hi Alexander,
>>>>
>>>> URLs like this:
>>>>
>>>> http://www.example.com/dir.ext/image
>>>>
>>>> will still be translated to:
>>>>
>>>> http://www.example.com/dir at 2x.ext/image
>>>>
>>>>
>>>> I think you need to search for last '.' after the last  '/' in the
>>>> getScaledImageName();
>>>>
>>>>
>>>> Also the following code has some additional bugs:
>>>>
>>>>   853         static Image toScalableImage(Image image, URL url) {
>>>>   854
>>>>   855             if (url != null && !url.toString().contains("@2x")
>>>>   856                     && !(image instanceof 
>>>> ScalableToolkitImage)) {
>>>>   857                 String protocol = url.getProtocol();
>>>>   858                 String host = url.getHost();
>>>>   859                 String file = url.getPath();
>>>>   860                 String file2x =*host +*getScaledImageName(file);
>>>>   861                 try {
>>>>   862                     URL url2x = new URL(protocol, host, file2x);
>>>>   863                     url2x.openStream();
>>>>   864                     return new ScalableToolkitImage(image,
>>>> getDefaultToolkit().getImage(url2x));
>>>>   865                 } catch (Exception ignore) {
>>>>   866                 }
>>>>   867             }
>>>>   868             return image;
>>>>   869         }
>>>>
>>>> Why are you prepending *host* to getScaledImageName(file) in line
>>>> 860? Let's take the following URL for example:
>>>>
>>>> http://www.example.com/dir/image.jpg
>>>>
>>>> protocol = "http"
>>>> host = "www.example.com"
>>>> file = "/dir/image.jpg"
>>>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>>>> url2x = 
>>>> URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>>>
>>>>
>>>> You are missing a part in URL (de)construction - the optional port!
>>>> For example in the following URL:
>>>>
>>>> http://www.example.com:8080/dir/image.jpg
>>>>
>>>> You should extract the port from original URL and use it in new URL
>>>> construction if present (!= -1).
>>>>
>>>>
>>>> I would also close the stream explicitly after probing for existence
>>>> of resource rather than delegating to GC which might not be promptly
>>>> and can cause resource exhaustion (think of MAX. # of open file
>>>> descriptors):
>>>>
>>>>         try (InputStream probe = url.openStream()) {}
>>>>
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>
>>>
>>



From swingler at apple.com  Wed Nov 13 17:21:01 2013
From: swingler at apple.com (Mike Swingler)
Date: Wed, 13 Nov 2013 09:21:01 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5282ED9F.805@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com>
	<71FAFA92-CEDB-4E37-BA54-92DA3B3DE8CA@apple.com>
	<5282DB56.7090306@oracle.com>
	<1495A1F8-8D5B-403A-9292-6BCF27518254@apple.com>
	<5282ED9F.805@oracle.com>
Message-ID: <3F1315D7-D09F-46F2-8A72-4C43F9CE5D8F@apple.com>

On Nov 12, 2013, at 7:10 PM, Jim Graham <james.graham at oracle.com> wrote:

> So, then, it sounds like on the Mac the "default heuristic" should be to take the transform into account and choose @2x based on that.  We don't yet know if that matches the default Windows 8 heuristics, but we only have 1 platform that has this enabled so far.
> 
> One last question (OK 2) for Mike - I want to be sure that we get the algorithm right, you said "if the backing store would be the same size or smaller than the @1x" which implies that the code in the fix "if (w <= imgw && h <= imgh) regular : @2x" matches the heuristics in Cocoa? (i.e. && and <= are the correct comparison and logic?)

This check seems correct to me. If either the w or h of the destination rect needs more pixels than is available from w or h of a given representation, the logic should choose the next representation, or fall back to scaling up the available pixels in the largest representation (insert caveats about bit depth, color space, and vector drawing resources like PDF).

> And question #2, if they are running on a display with pixel scale of 1.0, does the @2x get chosen when they scale up?  Or do the @2x media only even get considered on pixel scaled displays?

In the demo that I sent you ? the @2x gets chosen when displaying a scaled up image on a non-Retina display. The @2x is nothing special; it's just another representation. This is how NSImage has always worked long before Retina, since Mac OS X 10.0, AFAIK.

> Given that, I'd recommend:
> 
> - Add the DEFAULT setting for the SunHint which will basically say "do as Mac does when on a Mac"  (and eventually as Win8 does while on Win8, etc.)
> 
> - the current fix has the choice in the macosx code, which is good
> 
> - the current API provides the scaled dimensions, which is good for the mac code, but we may need to make more data available once we learn how other platforms solve this problem
> 
> - we may want to beef up the hints later with "choose based on Screen" vs "choose based on pixel size", but for now this API is sun.* private so lets just leave it with ON/OFF/DEFAULT.
> 
> - Hopefully the answers to the above 2 questions for Mike won't be surprising...
> 
> 			...jim

I hope I haven't surprised anyone. :-)

Regards,
Mike Swingler
Apple Inc.

> On 11/12/13 6:46 PM, Mike Swingler wrote:
>> The story is a little more complicated: NSImage always picks the "best" representation based on the computed size of the backing pixel rect taking all graphics transforms into account. For icons, which usually have dozens of representations, there isn't a single "@2x" representation.
>> 
>> This means that by switching screens, an icon can flip from a cartoonish 16x16 rep to a photo-realistic 128x128 scaled down to 32x32 if those are the only reps available. The multi-rep support in NSImage can also defer to a PDF representation if available when it can't find an exact dimension and bit-depth match for raster representations.
>> 
>> This does mean that an icon with 12 or so representations will visually glitch when smooth scaled as bits of detail come and go...but in the general case, most images tend to only have 2 reps and developers don't animate between them.
>> 
>> So to be explicit: no, NSImage Cocoa drawing will not choose the @2x version if the transform causes the rect in the pixel backing store to be the same size or smaller than the @1x.
>> 
>> I'll privately send along a little app that demonstrates this.
>> 
>> Regards,
>> Mike Swingler
>> Apple Inc.
>> 
>> On Nov 12, 2013, at 5:52 PM, Jim Graham <james.graham at oracle.com> wrote:
>> 
>>> Hi Mike,
>>> 
>>> Just to confirm and be explicit, the Mac will choose the @2x version of an image if that call returns 2.0 even if the user is rendering with a transform that scales by .001?
>>> 
>>> 		...jim
>>> 
>>> On 11/12/2013 5:48 PM, Mike Swingler wrote:
>>>> On Nov 12, 2013, at 11:43 AM, Jim Graham <james.graham at oracle.com> wrote:
>>>> 
>>>>> - It looks like the transform is used in SG2D to decide if the hiDPI image should be used.  I'm not familiar with the Mac's native use of @2x, but I thought that they hinged the decision off of the "retina scale" of the display, not off of the current transform.  That way, if you scale down an icon it doesn't change its look when it reaches .5x scale (or .75x depending on the cutoff). Personally, I think it is better to not use the transform to keep animations smooth, but I'm not sure what Apple did.
>>>> 
>>>> The -[NSWindow backingScaleFactor] is the basic primitive that other forms of coordinate translation key off of. Keep in mind that this value will dynamically change as the window moves from display to display.
>>>> 
>>>> Regards,
>>>> Mike Swingler
>>>> Apple Inc.
>>>> 
>> 



From james.graham at oracle.com  Wed Nov 13 18:49:57 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 13 Nov 2013 10:49:57 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5283719F.1030700@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283719F.1030700@oracle.com>
Message-ID: <5283C9D5.30602@oracle.com>



On 11/13/13 4:33 AM, Sergey Bylokhov wrote:
> On 12.11.2013 23:43, Jim Graham wrote:
>> - The logic in using the transform is also a bit murky.  I think if
>> you set the scale on a retina display to exactly 1/2 it would use the
>> HiDPI version even though the scale was 1:1.  Since I support not
>> examining the transform there, I'm going to present this as another
>> reason why we should just base it on devScale, but the logic could be
>> fixed if we really plan to use the transform here.
> It also allow to the user to use a transform and a hint and force the
> images to draw the scaled version even to the BufferedImage fo ex. Which
> can be useful in case of sequential drawing of BI-> BI->retina.

I think you misunderstood me here.  I'm not saying anything about the 
BI->BI->retina case.  I'm saying that even on pure retina your logic 
chooses the wrong scale because of mistakes made in examining the 
transform state type.

If devScale is 2, but the transform is a scale then the scales used to 
compute the resolution image will be based solely on the transform.  If 
devScale is 2, but the transform is identity, then the scales used to 
compute the resolution image should be 1.0 because that is the actual 
scale being applied to the image, but the logic will use 2 (i.e. the 
devScale) instead because of bad handling of the transformState.

Also, in the case of TRANSFORM_GENERIC just the devScale is used even if 
they scale it down to .001.

You probably need to only use the transform if you are going to use it 
at all and you need to use it for all transformState values (there may 
be optimizations based on the transformState, but the most complete 
transform type should not fall through to a default, neither should the 
translate-only states).

>> - Has any thought been given to my comments about MediaTracker and
>> image observer states for multi-res images?  I don't see any attempt
>> here to preload the @2x image.  The problem would probably only be
>> seen on multi-headed systems where one display is retina and one is
>> not - you would find the images suddenly reloading when you move the
>> window to the other screen and the application might not expect that
>> to happen.  Which image is the Observer registered on?  Since the
>> image is handed to the Observer, will an application be surprised when
>> their observer gets a handle to an image they've never seen?  Is it an
>> issue if one of the "alternate resolution variant" images leaks into
>> an application's "hands" via the observer callbacks?
> That's could be a problem. Is it possible to wrap imageObserver, which
> was passed to the drawImage, and replace one image to another in the
> WrapperImageObserver.imageUpdate()?

It's possible - the things to watch out for:

- they could hand the same IO in for multiple drawImage calls to 
multiple images

- they could hand the same IO in repeatedly for the same image while it 
is loading if the loading takes a while or the image is animated; you 
don't want to necessarily create an infinite number of wrappers for the 
same observer and register them all with the image loading mechanism

- the image that you report to them should probably be the original 
image, not the resolution-specific underlying images

- we need to deal with making sure that the information flowing to the 
IO does not report complete until all resolution variants that we plan 
to load are done

- given Mike's answer to my previous questions, it looks like @2x is not 
a retina-specific issue, all images do that even non non-retina 
apparently so maybe we do want to load all variants up front?

- we don't want to pass ERROR conditions to the IO unless all resolution 
variants are errored, we should silently swallow any ERROR conditions 
for just some of the resolution variants and make do with what we have

			...jim


From dmitry.x.ginzburg at oracle.com  Wed Nov 13 15:07:47 2013
From: dmitry.x.ginzburg at oracle.com (Dmitry Ginzburg)
Date: Wed, 13 Nov 2013 19:07:47 +0400
Subject: [OpenJDK 2D-Dev] <2D Dev> [8] Review Request: JDK-8025235
 [javadoc] fix some errors in 2D
In-Reply-To: <527CA369.6000806@oracle.com>
References: <52713614.1050408@oracle.com> <527CA369.6000806@oracle.com>
Message-ID: <528395C3.6030607@oracle.com>

Hi Phil, Guys ,


This one is stuck waiting for review for quite long time.
Please review so we can push this change.

Thanks,
-Dmitry

08.11.2013 12:40, Dmitry Ginzburg wrote:
> Colleagues,
>
> friendly reminder.
> Back in early October I did all proposed changes; could you please
> review this third version of doclint fix?
>
> Thanks,
> -Dmitry
>
> 30.10.2013 20:38, Dmitry Ginzburg wrote:
>> Hi guys
>> I haven't got any review from you on this issue. Can you please review it?
>> For some issue, my e-mail have changed todmitry.x.ginzburg at oracle.com
>> Thanks, Dmitry
>> *
>> Dmitry Ginzburg*  dmitry.ginzburg at oracle.com    <mailto:2d-dev%40openjdk.java.net?Subject=%5BOpenJDK%202D-Dev%5D%20%3C2D%20Dev%3E%20%5B8%5D%20Review%20Request%3A%20JDK-8025235%0A%20%5Bjavadoc%5D%20fix%20some%20errors%20in%202D&In-Reply-To=524EE4DB.8010602%40oracle.com>
>> /Tue Oct 15 06:02:58 PDT 2013/
>>
>> See new webrev:http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.02/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.02/>  
>> <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.02/>
>> Some changes are deleted, because they're fixed by someone but me
>>
>> 04.10.2013 19:55, Phil Race wrote:
>> >/  Hi,
>> />/
>> />/  A few places you used {@code that is not code} : ie PageAttributes for
>> />/  the &
>> />/  and Line2D.Float() constructor and  in MultipleMaster are the ones I
>> />/  spotted
>> />/  probably aren't appropriate as they aren't code, and the {@code ..}
>> />/  will use
>> />/  a fixed width font. So one char will be in a different font.
>> />/  As I suggested in PageAttributes just use "and", there's no reason it
>> />/  has to
>> />/  be an ampersand.
>> />/
>> />/  -phil.
>> />/
>> />/  On 10/4/2013 5:59 AM, Dmitry Ginzburg wrote:
>> />>/  Hi, Phil
>> />>/
>> />>/  I renewed webrev against your issues:
>> />>/  http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.01/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.01/>  
>> />>/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.01/>
>> />>/
>> />>/  Thanks,
>> />>/  -Dmitry
>> />>/
>> />>/  03.10.2013 08:41, Phil Race wrote:
>> />>>/  1. This webrev is not against the 2D forest. Please re-generate
>> />>>/  against 2D.
>> />>>/
>> />>>/  2.
>> />>>/  /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/GraphicsConfiguration.java:84:
>> />>>/  error: malformed HTML
>> />>>/     When you have < & > chars in code the preferred solution uses
>> />>>/  {@code .. }  like this :
>> />>>/  http://cr.openjdk.java.net/~prr/8022175/src/share/classes/javax/print/ServiceUI.java.sdiff.html  <http://cr.openjdk.java.net/%7Eprr/8022175/src/share/classes/javax/print/ServiceUI.java.sdiff.html>  
>> />>>/
>> />>>/
>> />>>/  3. Same as above for GraphicsDevice
>> />>>/
>> />>>/  4. Same as above for MediaTracker (it'll fix all 3 issues)
>> />>>/
>> />>>/  5. I think we should change all 12 or so of these to the word "and"
>> />>>/
>> />>>/  6. Rectangle : same as 2
>> />>>/
>> />>>/  7. LineBreakMeasurer : same again in all locations
>> />>>/
>> />>>/  8. {@code .. } should fix this too
>> />>>/
>> />>>/  9. LIne2D 626: {@code true} would be better here too
>> />>>/
>> />>>/  10. PrinterJob: {@code .. } again
>> />>>/
>> />>>/  Make sure you verify by re-running doclint on the fixed repo.
>> />>>/
>> />>>/  That's all.
>> />>>/
>> />>>/  -phil.
>> />>>/
>> />>>/  On 9/26/13 7:21 AM, Dmitry Ginzburg wrote:
>> />>>>/  Hello, 2D Team.
>> />>>>/
>> />>>>/  Please review the fix for the following issue:
>> />>>>/  https://bugs.openjdk.java.net/browse/JDK-8025235
>> />>>>/  The fix is available at:
>> />>>>/  http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.00/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.00/>
>> />>>>/
>> />>>>/  This is the fix for javadoc errors, on which doclint was showing
>> />>>>/  some issues.
>> />>>>/
>> />>>>/  The patch contains only simple markup fixes; no changes/fixes in
>> />>>>/  documentation text; the specification itself wasn't changed.
>> />>>>/
>> />>>>/  Thanks,
>> />>>>/  -Dmitry
>> />>>/
>> />>/
>> />>/
>> />>/  --
>> />>/  Dmitry Ginzburg, FXSQE team member
>> />/
>> /
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131113/99718b0c/attachment.html>

From lana.steuck at oracle.com  Sat Nov  9 07:12:52 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 09 Nov 2013 07:12:52 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 199 new changesets
Message-ID: <20131109075229.0F6A7624B2@hg.openjdk.java.net>

Changeset: 110c4fe4c354
Author:    erikj
Date:      2013-10-24 10:43 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/110c4fe4c354

8009280: JCE jurisdiction policy files not copied into jdk/lib/security
Reviewed-by: tbell, ihse

! makefiles/BuildJdk.gmk
! makefiles/CompileJavaClasses.gmk
! makefiles/CreateJars.gmk
+ makefiles/CreateSecurityJars.gmk
! makefiles/SignJars.gmk

Changeset: f40f639e1f52
Author:    dholmes
Date:      2013-10-24 20:46 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f40f639e1f52

8016096: [macosx] jawt_md.h shipped with jdk is outdated
Summary: Revised build system and added platform specific headers for Mac OS X
Reviewed-by: anthony, art, ihse, erikj
Contributed-by: david.dehaven at oracle.com

! makefiles/CopyFiles.gmk
! makefiles/gensrc/GensrcX11Wrappers.gmk
+ src/macosx/javavm/export/jawt_md.h
+ src/macosx/javavm/export/jni_md.h
+ src/macosx/javavm/export/jvm_md.h
! src/macosx/native/sun/awt/AWTSurfaceLayers.h
! src/macosx/native/sun/awt/CMenuComponent.h
! src/macosx/native/sun/awt/jawt.m
! src/macosx/native/sun/font/CoreTextSupport.h
! src/share/javavm/export/jawt.h

Changeset: f3c95d961557
Author:    dholmes
Date:      2013-10-24 20:47 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f3c95d961557

8025673: [macosx] Disable X11 AWT toolkit
Summary: Disable but not completely remove the XAWT and headless toolkits on Mac OS X
Reviewed-by: anthony, art, ihse, erikj
Contributed-by: david.dehaven at oracle.com

! makefiles/CompileJavaClasses.gmk
! makefiles/GenerateSources.gmk
! makefiles/Tools.gmk
! makefiles/lib/Awt2dLibraries.gmk
! src/share/native/java/lang/System.c
! src/share/native/java/lang/java_props.h
! src/solaris/native/java/lang/java_props_macosx.c
! src/solaris/native/java/lang/java_props_macosx.h
! src/solaris/native/java/lang/java_props_md.c
! src/solaris/native/sun/awt/fontpath.c
! test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh

Changeset: 5813af4c02e4
Author:    dcubed
Date:      2013-10-25 10:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5813af4c02e4

8027117: adapt JDK-7165611 to new build-infra whitespace/indent policy
Summary: Fix whitespace/indent issues.
Reviewed-by: hseigel, coleenp, erikj, ihse

! makefiles/Import.gmk

Changeset: 1628a137edca
Author:    katleman
Date:      2013-10-28 16:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/1628a137edca

Merge


Changeset: f26a0c8071bd
Author:    erikj
Date:      2013-10-29 15:44 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f26a0c8071bd

8027298: broken link in jdk8b113 macosx binaries
Reviewed-by: dcubed, ihse

! makefiles/Import.gmk

Changeset: 62982664dc72
Author:    cl
Date:      2013-10-31 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/62982664dc72

Added tag jdk8-b114 for changeset f26a0c8071bd

! .hgtags

Changeset: 3371047f56f3
Author:    lana
Date:      2013-10-31 15:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3371047f56f3

Merge


Changeset: 2e59014ef38f
Author:    alexsch
Date:      2013-10-09 13:40 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/2e59014ef38f

8025649: need test to cover JDK-8000423
Reviewed-by: anthony, serb
Contributed-by: Alexander Stepanov <alexander.v.stepanov at oracle.com>

+ test/java/awt/InputMethods/DiacriticsTest/DiacriticsTest.html
+ test/java/awt/InputMethods/DiacriticsTest/DiacriticsTest.java

Changeset: 84c766f6796b
Author:    bagiras
Date:      2013-10-09 14:12 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/84c766f6796b

8016356: Any swing frame resizes ugly.
Reviewed-by: art, anthony

! src/windows/native/sun/windows/awt_Window.cpp

Changeset: 929dc0915f8c
Author:    anthony
Date:      2013-10-09 15:34 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/929dc0915f8c

7159266: [macosx] ApplicationDelegate should not be set in the headless mode
Summary: Don't install ApplicationDelegate in headless mode
Reviewed-by: art, serb

! src/macosx/native/sun/awt/awt.m

Changeset: 976e5f580124
Author:    leonidr
Date:      2013-10-09 20:59 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/976e5f580124

8019623: Lack of synchronization in AppContext.getAppContext()
Reviewed-by: anthony, art

! src/share/classes/sun/awt/AppContext.java
+ test/sun/awt/AppContext/MultiThread/MultiThreadTest.java

Changeset: fba62451d705
Author:    leonidr
Date:      2013-10-09 21:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/fba62451d705

8016551: JMenuItem in WindowsLookAndFeel can't paint default icons
Reviewed-by: alexsch, serb

! src/share/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java
+ test/com/sun/java/swing/plaf/windows/8016551/bug8016551.java

Changeset: cea6ca16142e
Author:    cl
Date:      2013-10-09 14:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/cea6ca16142e

8026021: more fix of javadoc errors and warnings reported by doclint, see the description
Reviewed-by: anthony, serb

! src/share/classes/java/awt/GraphicsDevice.java
! src/share/classes/java/awt/GridBagLayout.java
! src/share/classes/java/awt/LinearGradientPaint.java
! src/share/classes/java/awt/RadialGradientPaint.java
! src/share/classes/java/awt/font/LineBreakMeasurer.java
! src/share/classes/java/awt/font/MultipleMaster.java
! src/share/classes/java/awt/font/NumericShaper.java
! src/share/classes/java/awt/font/OpenType.java
! src/share/classes/java/awt/geom/AffineTransform.java
! src/share/classes/java/awt/im/InputContext.java
! src/share/classes/javax/swing/Action.java
! src/share/classes/javax/swing/GroupLayout.java
! src/share/classes/javax/swing/text/JTextComponent.java
! src/share/classes/javax/swing/text/StyleConstants.java
! src/share/classes/javax/swing/text/html/HTMLDocument.java
! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java

Changeset: 81ea6299230a
Author:    serb
Date:      2013-10-10 02:35 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/81ea6299230a

7058662: AiffFileReader throws java.lang.ArithmeticException: division by zero when frame size is zero
7058666: Unexpected exception in AU parser code
7058672: Unexpected exceptions and freezes in WAV parser code
Reviewed-by: prr

! src/share/classes/com/sun/media/sound/AiffFileReader.java
! src/share/classes/com/sun/media/sound/AuFileReader.java
! src/share/classes/com/sun/media/sound/WaveFileReader.java
+ test/javax/sound/sampled/FileReader/ReadersExceptions.java

Changeset: 857d6f78f241
Author:    pchelko
Date:      2013-10-10 11:40 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/857d6f78f241

8025588: [macosx] Frozen AppKit thread in 7u40
Reviewed-by: anthony, art, serb

! src/macosx/classes/sun/lwawt/macosx/CInputMethod.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/event/InvocationEvent.java
! src/share/classes/sun/awt/AWTAccessor.java

Changeset: 31a156bae7cb
Author:    pchelko
Date:      2013-10-10 19:27 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/31a156bae7cb

8024864: [macosx] Problems with rendering of controls
Reviewed-by: serb, leonidr

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
+ test/java/awt/Paint/bug8024864.java

Changeset: de36486eadd2
Author:    pchelko
Date:      2013-10-11 11:48 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/de36486eadd2

8026143: [macosx] Maximized state could be inconsistent between peer and frame
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTWindow.m
+ test/java/awt/Frame/MaximizedByPlatform/MaximizedByPlatform.java

Changeset: d96f9a8cf89a
Author:    kshefov
Date:      2013-10-11 15:39 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d96f9a8cf89a

7124338: [macosx] Selection lost if a selected item removed from a java.awt.List
Reviewed-by: serb, anthony

+ test/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.html
+ test/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.java

Changeset: 2e04843f1c1d
Author:    art
Date:      2013-10-11 16:44 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/2e04843f1c1d

8022185: Fix Raw and unchecked warnings in classes belonging to java.awt.datatransfer
Reviewed-by: art, pchelko
Contributed-by: Srikalyan Chandrashekar <srikalyan.chandrashekar at oracle.com>

! src/share/classes/java/awt/datatransfer/DataFlavor.java
! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java

Changeset: 2f7f6995fa64
Author:    pchelko
Date:      2013-10-11 17:57 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/2f7f6995fa64

8026262: NPE in SystemFlavorMap.getAllNativesForType - regression in jdk8 b110 by fix of #JDK-8024987
Reviewed-by: art, serb

! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java

Changeset: af273c9b564a
Author:    pchelko
Date:      2013-10-11 18:04 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/af273c9b564a

8024329: [macosx] JRadioButtonMenuItem behaves like a checkbox when using the ScreenMenuBar
Reviewed-by: anthony, serb

! src/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java

Changeset: f65895a2959e
Author:    lana
Date:      2013-10-11 14:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f65895a2959e

Merge

- src/share/classes/java/lang/invoke/InvokeGeneric.java
- src/share/classes/java/time/chrono/ChronoDateImpl.java
- test/com/sun/jdi/Solaris32AndSolaris64Test.sh
- test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so
- test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so
- test/java/time/tck/java/time/chrono/TCKChronologySerialization.java
- test/java/util/regex/PatternTest.java

Changeset: d874963706dc
Author:    yan
Date:      2013-10-14 11:47 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d874963706dc

8025824: [cleanup] Fix tidy errors and warnings in preformatted HTML files related to 2d/awt/swing
Reviewed-by: anthony, alexsch

! src/macosx/classes/com/apple/eawt/event/package.html
! src/macosx/classes/com/apple/eawt/package.html
! src/share/classes/java/awt/color/package.html
! src/share/classes/java/awt/datatransfer/package.html
! src/share/classes/java/awt/dnd/package.html
! src/share/classes/java/awt/doc-files/AWTThreadIssues.html
! src/share/classes/java/awt/doc-files/DesktopProperties.html
! src/share/classes/java/awt/doc-files/FocusSpec.html
! src/share/classes/java/awt/doc-files/Modality.html
! src/share/classes/java/awt/event/package.html
! src/share/classes/java/awt/font/package.html
! src/share/classes/java/awt/geom/package.html
! src/share/classes/java/awt/image/package.html
! src/share/classes/java/awt/image/renderable/package.html
! src/share/classes/java/awt/package.html
! src/share/classes/java/awt/print/package.html
! src/share/classes/javax/print/attribute/package.html
! src/share/classes/javax/print/attribute/standard/package.html
! src/share/classes/javax/print/event/package.html
! src/share/classes/javax/print/package.html
! src/share/classes/javax/swing/border/package.html
! src/share/classes/javax/swing/colorchooser/package.html
! src/share/classes/javax/swing/event/package.html
! src/share/classes/javax/swing/filechooser/package.html
! src/share/classes/javax/swing/plaf/basic/package.html
! src/share/classes/javax/swing/plaf/metal/package.html
! src/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html
! src/share/classes/javax/swing/plaf/multi/package.html
! src/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html
! src/share/classes/javax/swing/plaf/nimbus/package.html
! src/share/classes/javax/swing/plaf/package.html
! src/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html
! src/share/classes/javax/swing/plaf/synth/package.html
! src/share/classes/javax/swing/table/package.html
! src/share/classes/javax/swing/text/html/package.html
! src/share/classes/javax/swing/text/html/parser/package.html
! src/share/classes/javax/swing/text/package.html
! src/share/classes/javax/swing/text/rtf/package.html
! src/share/classes/javax/swing/tree/package.html
! src/share/classes/javax/swing/undo/package.html

Changeset: 69a17384fe22
Author:    malenkov
Date:      2013-10-14 13:22 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/69a17384fe22

7165112: Incomprehensible garbage in doc for RootPaneContainer
Reviewed-by: alexsch

! src/share/classes/javax/swing/JApplet.java
! src/share/classes/javax/swing/JDialog.java
! src/share/classes/javax/swing/JFrame.java
! src/share/classes/javax/swing/JInternalFrame.java
! src/share/classes/javax/swing/JWindow.java
! src/share/classes/javax/swing/RootPaneContainer.java

Changeset: 9f49b055e983
Author:    malenkov
Date:      2013-10-14 13:59 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9f49b055e983

7016396: (spec) JCK test mentioned in 6735293 is still failing
Reviewed-by: alexsch

! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java
! src/share/classes/javax/swing/text/AsyncBoxView.java
! src/share/classes/javax/swing/text/CompositeView.java
! src/share/classes/javax/swing/text/GlyphView.java
! src/share/classes/javax/swing/text/View.java

Changeset: 54a6e22b749c
Author:    malenkov
Date:      2013-10-14 14:13 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/54a6e22b749c

7035495: javax.swing.ImageIcon spec should  be clarified
Reviewed-by: alexsch

! src/share/classes/javax/swing/ImageIcon.java

Changeset: 5e0ed469c36a
Author:    alexsch
Date:      2013-10-14 18:19 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5e0ed469c36a

8005391: Floating behavior of HTMLEditorKit parser
Reviewed-by: malenkov, leonidr
Contributed-by: Alexander Shusherov <alexander.shusherov at oracle.com>

! src/share/classes/javax/swing/text/SimpleAttributeSet.java
+ test/javax/swing/text/html/8005391/bug8005391.java

Changeset: 24fd0716d8d6
Author:    alexsch
Date:      2013-10-14 18:52 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/24fd0716d8d6

8020708: NLS mnemonics missing in SwingSet2/JInternalFrame demo
Reviewed-by: malenkov, leonidr

! src/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java
! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java
+ test/javax/swing/JInternalFrame/8020708/bug8020708.java

Changeset: 9546631f14ca
Author:    serb
Date:      2013-10-14 20:11 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9546631f14ca

8019591: JCK: testICSEthrowing_fullScreen fails: no ICSE thrown
Reviewed-by: art, anthony

! src/share/classes/java/awt/GraphicsDevice.java
+ test/java/awt/Window/WindowGCInFullScreen/WindowGCInFullScreen.java

Changeset: f9548641d699
Author:    serb
Date:      2013-10-15 20:37 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f9548641d699

7059886: 6 JCK manual awt/Desktop tests fail with GTKLookAndFeel - GTK intialization issue
Reviewed-by: anthony, art
Contributed-by: alexander.zvegintsev at oracle.com

+ src/solaris/classes/sun/misc/GThreadHelper.java
! src/solaris/native/sun/awt/awt_UNIXToolkit.c
! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h
! src/solaris/native/sun/xawt/awt_Desktop.c

Changeset: 89546b9be510
Author:    serb
Date:      2013-10-15 20:40 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/89546b9be510

8025225: Window.setAlwaysOnTop documentation should be updated
Reviewed-by: anthony, art
Contributed-by: alexander.zvegintsev at oracle.com

! src/share/classes/java/awt/Window.java

Changeset: 229b10e97bd2
Author:    bagiras
Date:      2013-10-16 19:02 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/229b10e97bd2

2228674: Fix failed for CR 7162144
Reviewed-by: art, anthony

! src/share/classes/java/awt/EventDispatchThread.java
! src/share/classes/java/awt/EventQueue.java

Changeset: 70242d821c66
Author:    serb
Date:      2013-10-17 20:54 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/70242d821c66

8022657: Add FunctionalInterface annotation to awt interfaces
Reviewed-by: anthony, art

! src/share/classes/java/awt/KeyEventDispatcher.java
! src/share/classes/java/awt/KeyEventPostProcessor.java

Changeset: 3c2d4569a6a3
Author:    serb
Date:      2013-10-17 21:22 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3c2d4569a6a3

8026356: [macosx] Found one Java-level deadlock:"AWT-EventQueue-0" && main
Reviewed-by: anthony, art

! src/share/classes/java/awt/Component.java

Changeset: 5334c651c7ba
Author:    yan
Date:      2013-10-18 15:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5334c651c7ba

7002846: Fix for 6989505 may be incomplete
Reviewed-by: anthony, art
Contributed-by: Andrei Eremeev <andrei.eremeev at oracle.com>

! src/windows/classes/sun/awt/windows/WRobotPeer.java
! src/windows/native/sun/windows/awt_Robot.cpp
! src/windows/native/sun/windows/awt_Robot.h

Changeset: 84ae644933b6
Author:    serb
Date:      2013-10-18 20:35 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/84ae644933b6

8026476: Choice does not get mouse events if it does not have enough place for popup menu
Reviewed-by: anthony, serb
Contributed-by: alexander.zvegintsev at oracle.com

! src/solaris/classes/sun/awt/X11/XChoicePeer.java

Changeset: d72ca6dac444
Author:    leonidr
Date:      2013-10-22 16:45 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d72ca6dac444

8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS"
Reviewed-by: anthony, serb

! src/macosx/native/sun/awt/AWTView.m
! src/macosx/native/sun/osxapp/NSApplicationAWT.m
+ test/java/awt/event/KeyEvent/8020209/bug8020209.java
! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java

Changeset: 4ad826a08e6f
Author:    serb
Date:      2013-10-23 16:24 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4ad826a08e6f

8020851: java.awt.event.WindowEvent spec should state that WINDOW_CLOSED event may not be delivered under certain circumstances
Reviewed-by: anthony, art

! src/share/classes/java/awt/event/WindowEvent.java

Changeset: cd2e3c63ee42
Author:    serb
Date:      2013-10-24 14:32 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/cd2e3c63ee42

7090424: TestGlyphVectorLayout failed automately with java.lang.StackOverflowError
Reviewed-by: anthony, art

! src/solaris/classes/sun/awt/X11/XButtonPeer.java
! src/solaris/classes/sun/awt/X11/XCanvasPeer.java
! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/awt/X11/XContentWindow.java
! src/solaris/classes/sun/awt/X11/XLabelPeer.java
! src/solaris/classes/sun/awt/X11/XListPeer.java
! src/solaris/classes/sun/awt/X11/XWindow.java
+ test/java/awt/Paint/ButtonRepaint.java
+ test/java/awt/Paint/CheckboxRepaint.java
+ test/java/awt/Paint/ExposeOnEDT.java
+ test/java/awt/Paint/LabelRepaint.java
+ test/java/awt/Paint/ListRepaint.java

Changeset: 7c84aff91033
Author:    pchelko
Date:      2013-10-24 19:23 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7c84aff91033

8027030: AWT Multiple JVM DnD Test Failing on Linux (OEL and Ubuntu) and Solaris (Sparc and x64)
Reviewed-by: anthony, serb

! src/share/classes/sun/awt/datatransfer/DataTransferer.java

Changeset: c561db53a24c
Author:    pchelko
Date:      2013-10-24 19:50 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c561db53a24c

8027025: [macosx] getLocationOnScreen returns 0 if parent invisible
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
+ test/java/awt/Window/8027025/Test8027025.java

Changeset: 6fe5443c3dde
Author:    alitvinov
Date:      2013-10-25 13:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6fe5443c3dde

8027066: XMLDecoder in java 7 cannot properly deserialize object arrays
Reviewed-by: alexsch, malenkov
Contributed-by: anton.nashatyrev at oracle.com

! src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java
+ test/java/beans/XMLEncoder/Test8027066.java

Changeset: 75ae2a980db5
Author:    malenkov
Date:      2013-10-25 16:42 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/75ae2a980db5

8026705: [TEST_BUG] java/beans/Introspector/TestTypeResolver.java failed
Reviewed-by: art, jfranck

! test/java/beans/Introspector/TestTypeResolver.java

Changeset: dab1d3798016
Author:    serb
Date:      2013-10-25 19:51 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/dab1d3798016

7172770: Default Toolkit implementation return null value for property "awt.dynamicLayoutSupported"
Reviewed-by: anthony, art

! src/share/classes/java/awt/Toolkit.java

Changeset: 162c57b874d4
Author:    lana
Date:      2013-10-25 10:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/162c57b874d4

Merge

- make/sun/awt/FILES_c_macosx.gmk
- make/sun/awt/FILES_export_macosx.gmk
- makefiles/GendataBreakIterator.gmk
- makefiles/GendataFontConfig.gmk
- makefiles/GendataHtml32dtd.gmk
- makefiles/GendataTZDB.gmk
- makefiles/GendataTimeZone.gmk
- makefiles/GenerateJavaSources.gmk
- makefiles/GensrcBuffer.gmk
- makefiles/GensrcCLDR.gmk
- makefiles/GensrcCharacterData.gmk
- makefiles/GensrcCharsetCoder.gmk
- makefiles/GensrcCharsetMapping.gmk
- makefiles/GensrcExceptions.gmk
- makefiles/GensrcIcons.gmk
- makefiles/GensrcJDWP.gmk
- makefiles/GensrcJObjC.gmk
- makefiles/GensrcLocaleDataMetaInfo.gmk
- makefiles/GensrcMisc.gmk
- makefiles/GensrcProperties.gmk
- makefiles/GensrcSwing.gmk
- makefiles/GensrcX11Wrappers.gmk
- src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java
- src/macosx/native/com/apple/resources/MacOSXResourceBundle.m
- src/share/classes/com/sun/jdi/connect/package.html
- src/share/classes/com/sun/jdi/connect/spi/package.html
- src/share/classes/com/sun/jdi/event/package.html
- src/share/classes/com/sun/jdi/package.html
- src/share/classes/com/sun/jdi/request/package.html
- src/share/classes/com/sun/management/package.html
- src/share/classes/com/sun/tools/attach/package.html
- src/share/classes/com/sun/tools/attach/spi/package.html
- src/share/classes/com/sun/tools/jconsole/package.html
! src/share/classes/java/awt/datatransfer/DataFlavor.java
- src/share/classes/java/net/HttpURLPermission.java
! src/share/classes/sun/awt/AppContext.java
- src/solaris/doc/sun/man/man1/ja/javaws.1
- src/solaris/doc/sun/man/man1/javaws.1
- test/com/oracle/security/ucrypto/TestAES.java
- test/com/oracle/security/ucrypto/TestDigest.java
- test/com/oracle/security/ucrypto/TestRSA.java
- test/com/oracle/security/ucrypto/UcryptoTest.java
- test/java/net/HttpURLPermission/HttpURLPermissionTest.java
- test/java/net/HttpURLPermission/URLTest.java
- test/java/net/HttpURLPermission/policy.1
- test/java/net/HttpURLPermission/policy.2
- test/java/net/HttpURLPermission/policy.3

Changeset: 55cab2211ae9
Author:    ant
Date:      2013-10-29 16:35 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/55cab2211ae9

8027157: [SwingNode] needs explicit expose for JWindow
Reviewed-by: art, anthony

! src/windows/classes/sun/awt/windows/WComponentPeer.java
! src/windows/classes/sun/awt/windows/WLightweightFramePeer.java
! src/windows/classes/sun/awt/windows/WWindowPeer.java

Changeset: bedc29a6d074
Author:    malenkov
Date:      2013-10-29 17:01 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/bedc29a6d074

8022746: List of spelling errors in API doc
Reviewed-by: alexsch, smarks

! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m
! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java
! src/macosx/classes/com/apple/laf/AquaMenuPainter.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java
! src/macosx/classes/com/apple/laf/AquaTreeUI.java
! src/macosx/classes/java/net/DefaultInterface.java
! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java
! src/macosx/classes/sun/font/CFontManager.java
! src/macosx/native/sun/awt/AWTView.m
! src/macosx/native/sun/awt/CTextPipe.m
! src/share/back/commonRef.c
! src/share/back/eventFilter.c
! src/share/back/util.c
! src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java
! src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java
! src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java
! src/share/classes/com/sun/beans/decoder/ByteElementHandler.java
! src/share/classes/com/sun/beans/decoder/CharElementHandler.java
! src/share/classes/com/sun/beans/decoder/ClassElementHandler.java
! src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java
! src/share/classes/com/sun/beans/decoder/ElementHandler.java
! src/share/classes/com/sun/beans/decoder/FalseElementHandler.java
! src/share/classes/com/sun/beans/decoder/FieldElementHandler.java
! src/share/classes/com/sun/beans/decoder/FloatElementHandler.java
! src/share/classes/com/sun/beans/decoder/IntElementHandler.java
! src/share/classes/com/sun/beans/decoder/JavaElementHandler.java
! src/share/classes/com/sun/beans/decoder/LongElementHandler.java
! src/share/classes/com/sun/beans/decoder/MethodElementHandler.java
! src/share/classes/com/sun/beans/decoder/NewElementHandler.java
! src/share/classes/com/sun/beans/decoder/NullElementHandler.java
! src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java
! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java
! src/share/classes/com/sun/beans/decoder/ShortElementHandler.java
! src/share/classes/com/sun/beans/decoder/StringElementHandler.java
! src/share/classes/com/sun/beans/decoder/TrueElementHandler.java
! src/share/classes/com/sun/beans/decoder/VarElementHandler.java
! src/share/classes/com/sun/beans/decoder/VoidElementHandler.java
! src/share/classes/com/sun/crypto/provider/PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/PBES1Core.java
! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java
! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java
! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormat.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextFieldUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextUI.java
! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java
! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java
! src/share/classes/com/sun/jdi/connect/ListeningConnector.java
! src/share/classes/com/sun/jdi/connect/spi/TransportService.java
! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/TokenMgrError.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgentMBean.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.java
! src/share/classes/com/sun/jndi/ldap/Connection.java
! src/share/classes/com/sun/jndi/ldap/Filter.java
! src/share/classes/com/sun/jndi/ldap/LdapCtx.java
! src/share/classes/com/sun/jndi/ldap/LdapName.java
! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java
! src/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java
! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java
! src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java
! src/share/classes/com/sun/media/sound/DirectAudioDevice.java
! src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java
! src/share/classes/com/sun/net/httpserver/Headers.java
! src/share/classes/com/sun/net/httpserver/HttpExchange.java
! src/share/classes/com/sun/net/ssl/internal/ssl/Provider.java
! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java
! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/com/sun/rowset/WebRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java
! src/share/classes/com/sun/rowset/package.html
! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java
! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java
! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java
! src/share/classes/com/sun/tools/hat/resources/hat.js
! src/share/classes/com/sun/tools/jdi/SocketAttachingConnector.java
! src/share/classes/com/sun/tools/jdi/SocketListeningConnector.java
! src/share/classes/com/sun/tools/jdi/ThreadListener.java
! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java
! src/share/classes/java/awt/AWTEventMulticaster.java
! src/share/classes/java/awt/AlphaComposite.java
! src/share/classes/java/awt/BasicStroke.java
! src/share/classes/java/awt/BorderLayout.java
! src/share/classes/java/awt/CheckboxMenuItem.java
! src/share/classes/java/awt/Choice.java
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Container.java
! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/Event.java
! src/share/classes/java/awt/Font.java
! src/share/classes/java/awt/Graphics.java
! src/share/classes/java/awt/Graphics2D.java
! src/share/classes/java/awt/GraphicsEnvironment.java
! src/share/classes/java/awt/GridBagLayout.java
! src/share/classes/java/awt/KeyboardFocusManager.java
! src/share/classes/java/awt/List.java
! src/share/classes/java/awt/MediaTracker.java
! src/share/classes/java/awt/MenuComponent.java
! src/share/classes/java/awt/MultipleGradientPaintContext.java
! src/share/classes/java/awt/Polygon.java
! src/share/classes/java/awt/PopupMenu.java
! src/share/classes/java/awt/RenderingHints.java
! src/share/classes/java/awt/ScrollPane.java
! src/share/classes/java/awt/ScrollPaneAdjustable.java
! src/share/classes/java/awt/Shape.java
! src/share/classes/java/awt/TextComponent.java
! src/share/classes/java/awt/TextField.java
! src/share/classes/java/awt/Toolkit.java
! src/share/classes/java/awt/Window.java
! src/share/classes/java/awt/datatransfer/FlavorMap.java
! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java
! src/share/classes/java/awt/dnd/DragGestureListener.java
! src/share/classes/java/awt/dnd/DragGestureRecognizer.java
! src/share/classes/java/awt/dnd/DragSourceContext.java
! src/share/classes/java/awt/dnd/DragSourceEvent.java
! src/share/classes/java/awt/dnd/DropTarget.java
! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java
! src/share/classes/java/awt/event/ActionEvent.java
! src/share/classes/java/awt/event/KeyEvent.java
! src/share/classes/java/awt/font/FontRenderContext.java
! src/share/classes/java/awt/font/GlyphMetrics.java
! src/share/classes/java/awt/font/GlyphVector.java
! src/share/classes/java/awt/font/OpenType.java
! src/share/classes/java/awt/font/TextLayout.java
! src/share/classes/java/awt/font/TransformAttribute.java
! src/share/classes/java/awt/geom/AffineTransform.java
! src/share/classes/java/awt/geom/Line2D.java
! src/share/classes/java/awt/geom/Path2D.java
! src/share/classes/java/awt/geom/QuadCurve2D.java
! src/share/classes/java/awt/im/InputMethodRequests.java
! src/share/classes/java/awt/image/BandedSampleModel.java
! src/share/classes/java/awt/image/BufferStrategy.java
! src/share/classes/java/awt/image/BufferedImage.java
! src/share/classes/java/awt/image/ComponentColorModel.java
! src/share/classes/java/awt/image/ComponentSampleModel.java
! src/share/classes/java/awt/image/ImageConsumer.java
! src/share/classes/java/awt/image/IndexColorModel.java
! src/share/classes/java/awt/image/PixelInterleavedSampleModel.java
! src/share/classes/java/awt/image/renderable/RenderableImage.java
! src/share/classes/java/awt/image/renderable/RenderableImageOp.java
! src/share/classes/java/beans/AppletInitializer.java
! src/share/classes/java/beans/DefaultPersistenceDelegate.java
! src/share/classes/java/beans/EventHandler.java
! src/share/classes/java/beans/MethodDescriptor.java
! src/share/classes/java/beans/PropertyDescriptor.java
! src/share/classes/java/beans/PropertyEditorSupport.java
! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java
! src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java
! src/share/classes/java/beans/beancontext/BeanContextServicesSupport.java
! src/share/classes/java/beans/beancontext/BeanContextSupport.java
! src/share/classes/java/io/File.java
! src/share/classes/java/io/ObjectStreamConstants.java
! src/share/classes/java/io/PrintStream.java
! src/share/classes/java/lang/invoke/MethodType.java
! src/share/classes/java/lang/management/CompilationMXBean.java
! src/share/classes/java/lang/management/MemoryPoolMXBean.java
! src/share/classes/java/lang/management/ThreadInfo.java
! src/share/classes/java/lang/management/ThreadMXBean.java
! src/share/classes/java/net/Authenticator.java
! src/share/classes/java/net/CookieManager.java
! src/share/classes/java/net/CookieStore.java
! src/share/classes/java/net/DatagramSocket.java
! src/share/classes/java/net/InetSocketAddress.java
! src/share/classes/java/net/InterfaceAddress.java
! src/share/classes/java/net/JarURLConnection.java
! src/share/classes/java/net/ServerSocket.java
! src/share/classes/java/net/SocksSocketImpl.java
! src/share/classes/java/net/StandardSocketOptions.java
! src/share/classes/java/net/URL.java
! src/share/classes/java/net/URLConnection.java
! src/share/classes/java/net/URLDecoder.java
! src/share/classes/java/net/URLEncoder.java
! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java
! src/share/classes/java/nio/channels/DatagramChannel.java
! src/share/classes/java/nio/channels/MembershipKey.java
! src/share/classes/java/nio/channels/package-info.java
! src/share/classes/java/nio/charset/Charset.java
! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java
! src/share/classes/java/rmi/MarshalledObject.java
! src/share/classes/java/security/AccessControlException.java
! src/share/classes/java/security/DigestOutputStream.java
! src/share/classes/java/security/KeyStore.java
! src/share/classes/java/security/ProtectionDomain.java
! src/share/classes/java/security/Security.java
! src/share/classes/java/security/UnresolvedPermission.java
! src/share/classes/java/security/cert/CertificateRevokedException.java
! src/share/classes/java/security/spec/ECFieldF2m.java
! src/share/classes/java/sql/Array.java
! src/share/classes/java/sql/BatchUpdateException.java
! src/share/classes/java/sql/Blob.java
! src/share/classes/java/sql/CallableStatement.java
! src/share/classes/java/sql/Clob.java
! src/share/classes/java/sql/Connection.java
! src/share/classes/java/sql/DataTruncation.java
! src/share/classes/java/sql/DatabaseMetaData.java
! src/share/classes/java/sql/DriverManager.java
! src/share/classes/java/sql/DriverPropertyInfo.java
! src/share/classes/java/sql/PreparedStatement.java
! src/share/classes/java/sql/ResultSet.java
! src/share/classes/java/sql/SQLException.java
! src/share/classes/java/sql/SQLFeatureNotSupportedException.java
! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java
! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java
! src/share/classes/java/sql/SQLNonTransientConnectionException.java
! src/share/classes/java/sql/SQLNonTransientException.java
! src/share/classes/java/sql/SQLRecoverableException.java
! src/share/classes/java/sql/SQLSyntaxErrorException.java
! src/share/classes/java/sql/SQLTimeoutException.java
! src/share/classes/java/sql/SQLTransactionRollbackException.java
! src/share/classes/java/sql/SQLTransientConnectionException.java
! src/share/classes/java/sql/SQLTransientException.java
! src/share/classes/java/sql/SQLWarning.java
! src/share/classes/java/sql/SQLXML.java
! src/share/classes/java/sql/Statement.java
! src/share/classes/java/sql/Struct.java
! src/share/classes/java/sql/package.html
! src/share/classes/java/text/BreakIterator.java
! src/share/classes/java/text/ChoiceFormat.java
! src/share/classes/java/text/DigitList.java
! src/share/classes/java/text/FieldPosition.java
! src/share/classes/java/text/Format.java
! src/share/classes/java/text/RuleBasedCollator.java
! src/share/classes/java/time/chrono/ChronoZonedDateTime.java
! src/share/classes/java/time/zone/ZoneRules.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/MissingFormatWidthException.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ExecutorCompletionService.java
! src/share/classes/java/util/jar/Manifest.java
! src/share/classes/java/util/regex/Pattern.java
! src/share/classes/javax/accessibility/AccessibleContext.java
! src/share/classes/javax/accessibility/AccessibleText.java
! src/share/classes/javax/crypto/NullCipher.java
! src/share/classes/javax/crypto/NullCipherSpi.java
! src/share/classes/javax/imageio/IIOParam.java
! src/share/classes/javax/imageio/ImageIO.java
! src/share/classes/javax/imageio/ImageReader.java
! src/share/classes/javax/imageio/ImageWriteParam.java
! src/share/classes/javax/imageio/ImageWriter.java
! src/share/classes/javax/imageio/event/IIOReadProgressListener.java
! src/share/classes/javax/imageio/event/IIOReadUpdateListener.java
! src/share/classes/javax/imageio/event/IIOReadWarningListener.java
! src/share/classes/javax/imageio/event/IIOWriteWarningListener.java
! src/share/classes/javax/imageio/metadata/IIOMetadata.java
! src/share/classes/javax/imageio/metadata/IIOMetadataFormat.java
! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java
! src/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html
! src/share/classes/javax/imageio/spi/ImageReaderSpi.java
! src/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java
! src/share/classes/javax/imageio/stream/ImageInputStream.java
! src/share/classes/javax/management/relation/RelationService.java
! src/share/classes/javax/management/relation/RelationServiceMBean.java
! src/share/classes/javax/management/remote/rmi/package.html
! src/share/classes/javax/naming/Binding.java
! src/share/classes/javax/naming/InsufficientResourcesException.java
! src/share/classes/javax/naming/ldap/LdapName.java
! src/share/classes/javax/naming/ldap/Rdn.java
! src/share/classes/javax/net/ssl/SSLPeerUnverifiedException.java
! src/share/classes/javax/net/ssl/SSLSocket.java
! src/share/classes/javax/print/CancelablePrintJob.java
! src/share/classes/javax/print/DocFlavor.java
! src/share/classes/javax/print/DocPrintJob.java
! src/share/classes/javax/print/MultiDoc.java
! src/share/classes/javax/print/PrintService.java
! src/share/classes/javax/print/attribute/standard/MediaTray.java
! src/share/classes/javax/print/attribute/standard/PresentationDirection.java
! src/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java
! src/share/classes/javax/print/attribute/standard/PrinterStateReason.java
! src/share/classes/javax/print/package.html
! src/share/classes/javax/script/AbstractScriptEngine.java
! src/share/classes/javax/script/CompiledScript.java
! src/share/classes/javax/script/Invocable.java
! src/share/classes/javax/script/ScriptEngine.java
! src/share/classes/javax/script/ScriptEngineFactory.java
! src/share/classes/javax/security/sasl/RealmChoiceCallback.java
! src/share/classes/javax/security/sasl/Sasl.java
! src/share/classes/javax/security/sasl/SaslClient.java
! src/share/classes/javax/security/sasl/SaslException.java
! src/share/classes/javax/smartcardio/CardChannel.java
! src/share/classes/javax/smartcardio/CardTerminal.java
! src/share/classes/javax/sound/midi/MidiDevice.java
! src/share/classes/javax/sound/midi/MidiMessage.java
! src/share/classes/javax/sound/midi/MidiSystem.java
! src/share/classes/javax/sound/midi/ShortMessage.java
! src/share/classes/javax/sound/midi/Soundbank.java
! src/share/classes/javax/sound/midi/Synthesizer.java
! src/share/classes/javax/sound/sampled/AudioFormat.java
! src/share/classes/javax/sound/sampled/AudioSystem.java
! src/share/classes/javax/sound/sampled/ReverbType.java
! src/share/classes/javax/sql/PooledConnection.java
! src/share/classes/javax/sql/RowSet.java
! src/share/classes/javax/sql/StatementEvent.java
! src/share/classes/javax/sql/rowset/BaseRowSet.java
! src/share/classes/javax/sql/rowset/CachedRowSet.java
! src/share/classes/javax/sql/rowset/JoinRowSet.java
! src/share/classes/javax/sql/rowset/Joinable.java
! src/share/classes/javax/sql/rowset/Predicate.java
! src/share/classes/javax/sql/rowset/package.html
! src/share/classes/javax/sql/rowset/spi/SyncFactory.java
! src/share/classes/javax/sql/rowset/spi/SyncResolver.java
! src/share/classes/javax/sql/rowset/spi/TransactionalWriter.java
! src/share/classes/javax/sql/rowset/spi/XmlReader.java
! src/share/classes/javax/sql/rowset/spi/XmlWriter.java
! src/share/classes/javax/swing/AbstractButton.java
! src/share/classes/javax/swing/BoxLayout.java
! src/share/classes/javax/swing/DefaultListSelectionModel.java
! src/share/classes/javax/swing/DefaultRowSorter.java
! src/share/classes/javax/swing/GroupLayout.java
! src/share/classes/javax/swing/JApplet.java
! src/share/classes/javax/swing/JComboBox.java
! src/share/classes/javax/swing/JComponent.java
! src/share/classes/javax/swing/JDialog.java
! src/share/classes/javax/swing/JFileChooser.java
! src/share/classes/javax/swing/JFormattedTextField.java
! src/share/classes/javax/swing/JFrame.java
! src/share/classes/javax/swing/JInternalFrame.java
! src/share/classes/javax/swing/JLabel.java
! src/share/classes/javax/swing/JLayeredPane.java
! src/share/classes/javax/swing/JMenu.java
! src/share/classes/javax/swing/JPasswordField.java
! src/share/classes/javax/swing/JPopupMenu.java
! src/share/classes/javax/swing/JRootPane.java
! src/share/classes/javax/swing/JSlider.java
! src/share/classes/javax/swing/JSpinner.java
! src/share/classes/javax/swing/JSplitPane.java
! src/share/classes/javax/swing/JTable.java
! src/share/classes/javax/swing/JViewport.java
! src/share/classes/javax/swing/JWindow.java
! src/share/classes/javax/swing/LookAndFeel.java
! src/share/classes/javax/swing/ProgressMonitor.java
! src/share/classes/javax/swing/RepaintManager.java
! src/share/classes/javax/swing/ScrollPaneConstants.java
! src/share/classes/javax/swing/SpinnerDateModel.java
! src/share/classes/javax/swing/SpinnerModel.java
! src/share/classes/javax/swing/SpinnerNumberModel.java
! src/share/classes/javax/swing/SpringLayout.java
! src/share/classes/javax/swing/SwingUtilities.java
! src/share/classes/javax/swing/ToolTipManager.java
! src/share/classes/javax/swing/TransferHandler.java
! src/share/classes/javax/swing/UIManager.java
! src/share/classes/javax/swing/border/TitledBorder.java
! src/share/classes/javax/swing/event/DocumentEvent.java
! src/share/classes/javax/swing/event/HyperlinkEvent.java
! src/share/classes/javax/swing/event/TableModelEvent.java
! src/share/classes/javax/swing/event/TreeModelEvent.java
! src/share/classes/javax/swing/filechooser/FileSystemView.java
! src/share/classes/javax/swing/plaf/ComboBoxUI.java
! src/share/classes/javax/swing/plaf/basic/BasicBorders.java
! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java
! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java
! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java
! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java
! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java
! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java
! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java
! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java
! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java
! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java
! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java
! src/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java
! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java
! src/share/classes/javax/swing/plaf/metal/MetalToolBarUI.java
! src/share/classes/javax/swing/plaf/metal/MetalTreeUI.java
! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
! src/share/classes/javax/swing/plaf/nimbus/LoweredBorder.java
! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java
! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java
! src/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html
! src/share/classes/javax/swing/table/DefaultTableColumnModel.java
! src/share/classes/javax/swing/table/JTableHeader.java
! src/share/classes/javax/swing/table/TableColumn.java
! src/share/classes/javax/swing/table/TableColumnModel.java
! src/share/classes/javax/swing/text/AbstractDocument.java
! src/share/classes/javax/swing/text/AbstractWriter.java
! src/share/classes/javax/swing/text/AsyncBoxView.java
! src/share/classes/javax/swing/text/BoxView.java
! src/share/classes/javax/swing/text/DefaultFormatter.java
! src/share/classes/javax/swing/text/DefaultHighlighter.java
! src/share/classes/javax/swing/text/DefaultStyledDocument.java
! src/share/classes/javax/swing/text/Document.java
! src/share/classes/javax/swing/text/DocumentFilter.java
! src/share/classes/javax/swing/text/ElementIterator.java
! src/share/classes/javax/swing/text/FlowView.java
! src/share/classes/javax/swing/text/GapContent.java
! src/share/classes/javax/swing/text/GapVector.java
! src/share/classes/javax/swing/text/InternationalFormatter.java
! src/share/classes/javax/swing/text/JTextComponent.java
! src/share/classes/javax/swing/text/NumberFormatter.java
! src/share/classes/javax/swing/text/ParagraphView.java
! src/share/classes/javax/swing/text/StyleConstants.java
! src/share/classes/javax/swing/text/StyleContext.java
! src/share/classes/javax/swing/text/TableView.java
! src/share/classes/javax/swing/text/View.java
! src/share/classes/javax/swing/text/WrappedPlainView.java
! src/share/classes/javax/swing/text/ZoneView.java
! src/share/classes/javax/swing/text/html/AccessibleHTML.java
! src/share/classes/javax/swing/text/html/BlockView.java
! src/share/classes/javax/swing/text/html/CSS.java
! src/share/classes/javax/swing/text/html/CSSParser.java
! src/share/classes/javax/swing/text/html/FormSubmitEvent.java
! src/share/classes/javax/swing/text/html/FormView.java
! src/share/classes/javax/swing/text/html/FrameSetView.java
! src/share/classes/javax/swing/text/html/HTML.java
! src/share/classes/javax/swing/text/html/HTMLDocument.java
! src/share/classes/javax/swing/text/html/HTMLEditorKit.java
! src/share/classes/javax/swing/text/html/HTMLFrameHyperlinkEvent.java
! src/share/classes/javax/swing/text/html/HTMLWriter.java
! src/share/classes/javax/swing/text/html/OptionListModel.java
! src/share/classes/javax/swing/text/html/ParagraphView.java
! src/share/classes/javax/swing/text/html/StyleSheet.java
! src/share/classes/javax/swing/text/html/TableView.java
! src/share/classes/javax/swing/text/html/parser/ContentModel.java
! src/share/classes/javax/swing/text/html/parser/DocumentParser.java
! src/share/classes/javax/swing/text/html/parser/Element.java
! src/share/classes/javax/swing/text/html/parser/Parser.java
! src/share/classes/javax/swing/tree/AbstractLayoutCache.java
! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java
! src/share/classes/javax/swing/tree/DefaultTreeModel.java
! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java
! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
! src/share/classes/javax/swing/tree/TreeModel.java
! src/share/classes/javax/swing/tree/TreeSelectionModel.java
! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java
! src/share/classes/javax/xml/crypto/KeySelector.java
! src/share/classes/javax/xml/crypto/MarshalException.java
! src/share/classes/javax/xml/crypto/dsig/TransformException.java
! src/share/classes/javax/xml/crypto/dsig/XMLSignatureException.java
! src/share/classes/jdi-overview.html
! src/share/classes/jdk/internal/org/objectweb/asm/Frame.java
! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java
! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java
! src/share/classes/jdk/internal/org/xml/sax/EntityResolver.java
! src/share/classes/jdk/internal/util/xml/XMLStreamException.java
! src/share/classes/jdk/internal/util/xml/impl/Parser.java
! src/share/classes/org/ietf/jgss/GSSContext.java
! src/share/classes/org/ietf/jgss/GSSCredential.java
! src/share/classes/org/ietf/jgss/GSSException.java
! src/share/classes/org/ietf/jgss/GSSManager.java
! src/share/classes/org/ietf/jgss/GSSName.java
! src/share/classes/org/ietf/jgss/package.html
! src/share/classes/sun/applet/AppletSecurity.java
! src/share/classes/sun/awt/FontConfiguration.java
! src/share/classes/sun/awt/GlobalCursorManager.java
! src/share/classes/sun/awt/shell/ShellFolderManager.java
! src/share/classes/sun/dc/DuctusRenderingEngine.java
! src/share/classes/sun/font/ExtendedTextSourceLabel.java
! src/share/classes/sun/font/FileFontStrike.java
! src/share/classes/sun/font/FontManager.java
! src/share/classes/sun/font/FontRunIterator.java
! src/share/classes/sun/font/LayoutPathImpl.java
! src/share/classes/sun/font/ScriptRun.java
! src/share/classes/sun/font/StrikeCache.java
! src/share/classes/sun/font/SunFontManager.java
! src/share/classes/sun/font/TrueTypeFont.java
! src/share/classes/sun/font/Type1Font.java
! src/share/classes/sun/java2d/SurfaceDataProxy.java
! src/share/classes/sun/java2d/loops/ProcessPath.java
! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java
! src/share/classes/sun/java2d/pipe/BufferedMaskFill.java
! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java
! src/share/classes/sun/java2d/pipe/BufferedTextPipe.java
! src/share/classes/sun/java2d/pipe/DrawImage.java
! src/share/classes/sun/java2d/pipe/RenderingEngine.java
! src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java
! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java
! src/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java
! src/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java
! src/share/classes/sun/management/counter/perf/InstrumentationException.java
! src/share/classes/sun/management/counter/perf/PerfDataType.java
! src/share/classes/sun/misc/CRC16.java
! src/share/classes/sun/misc/CharacterDecoder.java
! src/share/classes/sun/misc/PerformanceLogger.java
! src/share/classes/sun/net/NetworkClient.java
! src/share/classes/sun/net/TelnetOutputStream.java
! src/share/classes/sun/net/ftp/FtpClient.java
! src/share/classes/sun/net/ftp/impl/FtpClient.java
! src/share/classes/sun/net/httpserver/Request.java
! src/share/classes/sun/net/idn/StringPrep.java
! src/share/classes/sun/net/smtp/SmtpProtocolException.java
! src/share/classes/sun/net/www/http/ChunkedInputStream.java
! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/http/PosterOutputStream.java
! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java
! src/share/classes/sun/print/PSPathGraphics.java
! src/share/classes/sun/print/PSPrinterJob.java
! src/share/classes/sun/print/PathGraphics.java
! src/share/classes/sun/print/PrintJob2D.java
! src/share/classes/sun/print/RasterPrinterJob.java
! src/share/classes/sun/rmi/rmic/RemoteClass.java
! src/share/classes/sun/rmi/rmic/Util.java
! src/share/classes/sun/rmi/rmic/newrmic/jrmp/StubSkeletonWriter.java
! src/share/classes/sun/rmi/runtime/Log.java
! src/share/classes/sun/rmi/server/Activation.java
! src/share/classes/sun/rmi/transport/ObjectTable.java
! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java
! src/share/classes/sun/rmi/transport/tcp/MultiplexOutputStream.java
! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java
! src/share/classes/sun/security/jca/GetInstance.java
! src/share/classes/sun/security/jgss/krb5/Krb5Context.java
! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java
! src/share/classes/sun/security/jgss/krb5/MessageToken.java
! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java
! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/KdcComm.java
! src/share/classes/sun/security/krb5/Realm.java
! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java
! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java
! src/share/classes/sun/security/krb5/internal/crypto/DesCbcEType.java
! src/share/classes/sun/security/pkcs11/P11DHKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java
! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java
! src/share/classes/sun/security/provider/DSA.java
! src/share/classes/sun/security/provider/certpath/AdjacencyList.java
! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java
! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java
! src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java
! src/share/classes/sun/security/ssl/HandshakeOutStream.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/RSASignature.java
! src/share/classes/sun/security/ssl/Record.java
! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
! src/share/classes/sun/security/ssl/SunJSSE.java
! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java
! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
! src/share/classes/sun/security/tools/jarsigner/Main.java
! src/share/classes/sun/security/util/HostnameChecker.java
! src/share/classes/sun/security/x509/AlgIdDSA.java
! src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java
! src/share/classes/sun/swing/plaf/synth/Paint9Painter.java
! src/share/classes/sun/text/normalizer/ReplaceableUCharacterIterator.java
! src/share/classes/sun/text/resources/th/CollationData_th.java
! src/share/classes/sun/tools/jar/Main.java
! src/share/classes/sun/tools/jconsole/BorderedComponent.java
! src/share/classes/sun/tools/jconsole/inspector/XTextField.java
! src/share/classes/sun/tools/jinfo/JInfo.java
! src/share/classes/sun/tools/jmap/JMap.java
! src/share/classes/sun/tools/jstat/ColumnFormat.java
! src/share/classes/sun/tools/jstat/resources/jstat_options
! src/share/classes/sun/tools/tree/ExprExpression.java
! src/share/classes/sun/tools/tree/FieldExpression.java
! src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java
! src/share/classes/sun/util/logging/PlatformLogger.java
! src/share/demo/jfc/Font2DTest/FontPanel.java
! src/share/demo/jfc/TableExample/TableExample4.java
! src/share/demo/jvmti/hprof/debug_malloc.c
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
! src/share/javavm/export/jvm.h
! src/share/native/com/sun/java/util/jar/pack/zip.cpp
! src/share/native/com/sun/media/sound/PlatformMidi.h
! src/share/native/common/jni_util.h
! src/share/native/java/lang/fdlibm/src/k_rem_pio2.c
! src/share/native/java/util/zip/zip_util.c
! src/share/native/sun/awt/image/cvutils/img_dcm.h
! src/share/native/sun/awt/image/cvutils/img_replscale.h
! src/share/native/sun/awt/image/jpeg/imageioJPEG.c
! src/share/native/sun/awt/image/jpeg/jpegdecoder.c
! src/share/native/sun/awt/libpng/CHANGES
! src/share/native/sun/awt/libpng/png.h
! src/share/native/sun/awt/libpng/pngconf.h
! src/share/native/sun/awt/libpng/pngpriv.h
! src/share/native/sun/awt/libpng/pngrutil.c
! src/share/native/sun/font/layout/ArabicLayoutEngine.h
! src/share/native/sun/font/layout/IndicReordering.h
! src/share/native/sun/font/layout/KhmerReordering.cpp
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h
! src/share/native/sun/font/layout/TibetanReordering.cpp
! src/share/native/sun/java2d/cmm/lcms/cmsio0.c
! src/share/native/sun/java2d/cmm/lcms/cmslut.c
! src/share/native/sun/java2d/loops/ProcessPath.c
! src/share/native/sun/java2d/opengl/OGLTextRenderer.c
! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c
! src/share/sample/jmx/jmx-scandir/index.html
! src/share/sample/nio/chatserver/ClientReader.java
! src/share/sample/scripting/scriptpad/src/resources/gui.js
! src/solaris/classes/java/net/DefaultInterface.java
! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java
! src/solaris/classes/sun/awt/X11/XChoicePeer.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/awt/X11/XDragSourceProtocol.java
! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java
! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java
! src/solaris/classes/sun/awt/X11/XScrollbar.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11GraphicsConfig.java
! src/solaris/classes/sun/font/XMap.java
! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
! src/solaris/classes/sun/nio/fs/SolarisWatchService.java
! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/solaris/classes/sun/nio/fs/UnixUriUtils.java
! src/solaris/classes/sun/print/UnixPrintServiceLookup.java
! src/solaris/demo/jni/Poller/Poller.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_Ports.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_PCM.c
! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_Utils.h
! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/multiVis.c
! src/solaris/native/sun/security/smartcardio/MUSCLE/pcsclite.h
! src/windows/classes/com/sun/tools/jdi/SharedMemoryAttachingConnector.java
! src/windows/classes/com/sun/tools/jdi/SharedMemoryListeningConnector.java
! src/windows/classes/java/net/DefaultInterface.java
! src/windows/classes/sun/awt/windows/WPathGraphics.java
! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java
! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
! src/windows/classes/sun/nio/fs/WindowsPath.java
! src/windows/classes/sun/security/krb5/internal/tools/Klist.java
! src/windows/native/java/io/canonicalize_md.c
! src/windows/native/java/net/DualStackPlainSocketImpl.c
! src/windows/native/java/net/icmp.h
! src/windows/native/sun/font/fontpath.c
! src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp
! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp
! src/windows/native/sun/java2d/windows/GDIRenderer.cpp
! src/windows/native/sun/nio/ch/SocketChannelImpl.c
! src/windows/native/sun/security/krb5/NativeCreds.c
! src/windows/native/sun/windows/ThemeReader.cpp
! src/windows/native/sun/windows/awt_BitmapUtil.cpp
! src/windows/native/sun/windows/awt_Choice.cpp
! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Dialog.h
! src/windows/native/sun/windows/awt_DnDDS.cpp
! src/windows/native/sun/windows/awt_Font.h
! src/windows/native/sun/windows/awt_InputTextInfor.cpp
! src/windows/native/sun/windows/awt_PrintJob.cpp
! src/windows/native/sun/windows/awt_TextComponent.cpp

Changeset: d4eb25382baf
Author:    malenkov
Date:      2013-10-29 19:01 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d4eb25382baf

8027442: JDK compilation fails on MacOS
Reviewed-by: alexsch, pchelko

! src/share/classes/java/awt/Component.java

Changeset: a2b42e558211
Author:    bagiras
Date:      2013-10-29 21:46 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a2b42e558211

8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine
Reviewed-by: anthony, pchelko

! src/share/classes/sun/awt/datatransfer/DataTransferer.java
! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java

Changeset: db2838f25a85
Author:    pchelko
Date:      2013-10-30 12:00 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/db2838f25a85

8027152: Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112
Reviewed-by: art, serb

! src/share/classes/java/awt/Window.java
+ test/java/awt/Window/OwnedWindowsSerialization/OwnedWindowsSerialization.java

Changeset: 05f04b1c5bd0
Author:    leonidr
Date:      2013-10-30 20:54 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/05f04b1c5bd0

8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/CWrapper.java
! src/macosx/native/sun/awt/AWTWindow.h
! src/macosx/native/sun/awt/AWTWindow.m
! src/macosx/native/sun/awt/CWrapper.m
+ test/java/awt/FullScreen/8013581/bug8013581.java

Changeset: 6f436140049d
Author:    lana
Date:      2013-10-31 16:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6f436140049d

Merge

! src/share/classes/java/awt/image/ComponentSampleModel.java
! src/share/classes/sun/print/RasterPrinterJob.java
! src/solaris/classes/sun/print/UnixPrintServiceLookup.java

Changeset: 042a473535aa
Author:    mchung
Date:      2013-10-17 19:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/042a473535aa

8025799: Restore sun.reflect.Reflection.getCallerClass(int) until a replacement API is provided
Reviewed-by: alanb, forax, dholmes, twisti

! makefiles/mapfiles/libjava/mapfile-vers
! makefiles/mapfiles/libjava/reorder-sparc
! makefiles/mapfiles/libjava/reorder-sparcv9
! makefiles/mapfiles/libjava/reorder-x86
! src/share/classes/sun/reflect/Reflection.java
! src/share/javavm/export/jvm.h
! src/share/native/sun/reflect/Reflection.c
+ test/sun/reflect/Reflection/GetCallerClassWithDepth.java

Changeset: 8a7b1b615100
Author:    darcy
Date:      2013-10-17 22:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/8a7b1b615100

8026840: Fix new doclint issues in javax.naming
Reviewed-by: mchung

! src/share/classes/javax/naming/CompositeName.java
! src/share/classes/javax/naming/CompoundName.java
! src/share/classes/javax/naming/Context.java
! src/share/classes/javax/naming/InitialContext.java
! src/share/classes/javax/naming/ReferralException.java
! src/share/classes/javax/naming/directory/DirContext.java
! src/share/classes/javax/naming/event/EventContext.java
! src/share/classes/javax/naming/ldap/LdapContext.java
! src/share/classes/javax/naming/ldap/Rdn.java

Changeset: 658e121bda42
Author:    sherman
Date:      2013-10-17 23:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/658e121bda42

8025971: Remove ZoneId.OLD_SHORT_IDS
8026197: Slow reading tzdb.dat if the JRE is on a high-latency, remote file system
Summary: removed the compatiblity old short-ids mapping
Reviewed-by: okutsu

! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/zone/TzdbZoneRulesProvider.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/sun/util/calendar/ZoneInfoFile.java
! test/java/time/tck/java/time/TCKZoneId.java
! test/java/util/Calendar/JavatimeTest.java

Changeset: 8479a48d9fd4
Author:    sla
Date:      2013-10-18 11:52 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/8479a48d9fd4

8021897: EXCEPTION_ACCESS_VIOLATION on debugging String.contentEquals()
Reviewed-by: alanb, sspitsyn

! src/share/back/outStream.c
+ test/com/sun/jdi/GetUninitializedStringValue.java

Changeset: da695008417f
Author:    alanb
Date:      2013-10-18 13:45 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/da695008417f

8026859: (fs) test/java/nio/file/Files/StreamTest.java fails to compile intermittently
Reviewed-by: psandoz

! test/java/nio/file/Files/StreamTest.java

Changeset: 4e065f5b4a16
Author:    igerasim
Date:      2013-10-18 16:06 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4e065f5b4a16

8026756: Test java/util/zip/GZIP/GZIPInZip.java failed
Reviewed-by: alanb

! test/java/util/zip/GZIP/GZIPInZip.java

Changeset: 329cf77821e8
Author:    alanb
Date:      2013-10-18 13:51 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/329cf77821e8

7050570: (fs) FileSysteProvider fails to initializes if run with file.encoding set to Cp037
Reviewed-by: sherman, ulfzibis

! src/share/classes/sun/nio/fs/Util.java
! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java
! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java
! src/solaris/classes/sun/nio/fs/LinuxFileStore.java
! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java
! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java
! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java
! src/solaris/classes/sun/nio/fs/UnixException.java
! src/solaris/classes/sun/nio/fs/UnixFileStore.java
! src/solaris/classes/sun/nio/fs/UnixFileSystem.java
! src/solaris/classes/sun/nio/fs/UnixMountEntry.java
! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/solaris/classes/sun/nio/fs/UnixUserPrincipals.java

Changeset: 4161f17dfe2b
Author:    sjiang
Date:      2013-10-18 16:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4161f17dfe2b

8026028: [findbugs] findbugs report some issue in com.sun.jmx.snmp package
Reviewed-by: psandoz, dfuchs

! src/share/classes/com/sun/jmx/snmp/SnmpString.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java
! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java
+ test/com/sun/jmx/snmp/NoInfoLeakTest.java

Changeset: 602aa6fa46c6
Author:    alanb
Date:      2013-10-18 15:51 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/602aa6fa46c6

8026876: (fs) Build issue with src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java
Reviewed-by: psandoz

! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java

Changeset: 93f4f012deaf
Author:    alanb
Date:      2013-10-18 16:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/93f4f012deaf

Merge


Changeset: 8d1d5a5aeb41
Author:    robm
Date:      2013-10-18 16:28 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/8d1d5a5aeb41

8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds
Reviewed-by: alanb
Contributed-by: pavel.punegov at oracle.com

! test/java/lang/ProcessBuilder/InheritIOEHandle.java
! test/java/lang/ProcessBuilder/SiblingIOEHandle.java

Changeset: 88436832cfd0
Author:    dsamersoff
Date:      2013-10-19 00:05 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/88436832cfd0

8004213: JDP packet needs pid, broadcast interval and rmi server hostname fields
Summary: Add some extra fileds to jdp packet
Reviewed-by: allwin, sla, hirt

! src/share/classes/sun/management/jdp/JdpController.java
! src/share/classes/sun/management/jdp/JdpJmxPacket.java
! test/sun/management/jdp/JdpClient.java
! test/sun/management/jdp/JdpDoSomething.java
! test/sun/management/jdp/JdpTest.sh

Changeset: 7a947daa8f51
Author:    rriggs
Date:      2013-10-18 16:37 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7a947daa8f51

8025828: Late binding of Chronology to appendValueReduced
Summary: Add a listener to the parseContext called when the Chronology changes
Reviewed-by: sherman

! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! src/share/classes/java/time/format/DateTimeParseContext.java
! test/java/time/test/java/time/format/TestReducedParser.java

Changeset: fbb7510f788d
Author:    vromero
Date:      2013-10-19 17:53 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/fbb7510f788d

8026854: java.time.temporal.TemporalQueries doesn't compile after javac modification to lambda flow analysis
Reviewed-by: psandoz

! src/share/classes/java/time/temporal/TemporalQueries.java

Changeset: 392acefef659
Author:    dsamersoff
Date:      2013-10-19 20:59 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/392acefef659

8024071: In ManagementAgent.start it should be possible to set the jdp.name parameter.
Summary: Pass one more property from Agent to JdpController
Reviewed-by: jbachorik, sla

! src/share/classes/sun/management/Agent.java
! test/sun/management/jdp/JdpTest.sh
! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh

Changeset: ede89a97e80a
Author:    ksrini
Date:      2013-10-19 15:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ede89a97e80a

8026794: Test tools/pack200/TimeStamp.java fails while opening golden.jar.native.IST on linux-ppc(v2)
Reviewed-by: dholmes

! src/share/native/com/sun/java/util/jar/pack/zip.cpp

Changeset: 71ecbde5e5e4
Author:    rfield
Date:      2013-10-20 18:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/71ecbde5e5e4

8025631: Enhance Lambda construction
Reviewed-by: ksrini, ahgross

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
- src/share/classes/java/lang/invoke/MagicLambdaImpl.java

Changeset: 30c46debdf0f
Author:    jbachorik
Date:      2013-10-21 10:40 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/30c46debdf0f

7197919: java/lang/management/ThreadMXBean/ThreadBlockedCount.java has concurency issues
Reviewed-by: sla, mchung

! test/java/lang/management/ThreadMXBean/ThreadBlockedCount.java

Changeset: d8694ad1ed2d
Author:    jbachorik
Date:      2013-10-21 10:54 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d8694ad1ed2d

8024613: javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently
Summary: RMID needs a varying amount of time to start its socket server. We need to cater for it.
Reviewed-by: sjiang, dfuchs, sla

! test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java

Changeset: 567d47fd3fe2
Author:    dfuchs
Date:      2013-10-21 11:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/567d47fd3fe2

8016344: (props) Properties.storeToXML behaviour has changed from JDK 6 to 7
Summary: When storing Properties to XML only locally defined properties must be saved.
Reviewed-by: psandoz, mchung, alanb

! src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java
! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java
+ test/java/util/Properties/LoadAndStoreXMLWithDefaults.java

Changeset: c81125493ca6
Author:    dfuchs
Date:      2013-10-21 12:00 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c81125493ca6

8026499: Root Logger level can be reset unexpectedly
Summary: This fix prevents the logger's level to be re-initialized if it has already been initialized.
Reviewed-by: mchung

! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/logging/Logger.java
+ test/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java

Changeset: 698baf22e081
Author:    jbachorik
Date:      2013-10-21 13:57 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/698baf22e081

7140929: NotSerializableNotifTest.java fails intermittently
Reviewed-by: sjiang, alanb

! test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java

Changeset: f0c18a5e3ae5
Author:    sherman
Date:      2013-10-21 11:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f0c18a5e3ae5

8026842: Remove Time-Zone IDs HST/EST/MST
Summary: removed these ids from ZoneId's zid list, supported via short_ids list
Reviewed-by: okutsu

! make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java
! src/share/classes/sun/util/calendar/ZoneInfoFile.java
! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java

Changeset: c1700125d041
Author:    darcy
Date:      2013-10-21 12:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c1700125d041

8022658: Revisit FunctionalInterface on some core libs types
Reviewed-by: briangoetz, mduigou, mr

! src/share/classes/java/io/Closeable.java
! src/share/classes/java/io/Flushable.java
! src/share/classes/java/lang/AutoCloseable.java
! src/share/classes/java/lang/Comparable.java
! src/share/classes/java/lang/Iterable.java
! src/share/classes/java/lang/Readable.java

Changeset: e8683d5b2b0a
Author:    peytoia
Date:      2013-10-22 06:13 +0900
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e8683d5b2b0a

8020037: String.toLowerCase incorrectly increases length, if string contains \u0130 char
Reviewed-by: naoto

! src/share/classes/java/lang/ConditionalSpecialCasing.java
! src/share/classes/java/lang/String.java
! test/java/lang/String/ToLowerCase.java

Changeset: 3b00bf85a6f5
Author:    sherman
Date:      2013-10-21 18:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3b00bf85a6f5

8008386: (cs) Unmappable leading should be decoded to replacement.
Summary: updated the unmappable/malformed detecting handling for db charsets
Reviewed-by: naoto

! src/share/classes/sun/nio/cs/ext/DoubleByte.java
! test/sun/nio/cs/TestIBMBugs.java
+ test/sun/nio/cs/TestUnmappable.java

Changeset: f581b72e3715
Author:    sla
Date:      2013-10-21 23:32 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f581b72e3715

8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV
Summary: Redefined class in stack trace may not be found by method_idnum so handle null.
Reviewed-by: coleenp, dcubed, sspitsyn

! test/java/lang/instrument/RedefineMethodInBacktrace.sh
! test/java/lang/instrument/RedefineMethodInBacktraceApp.java
+ test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java
+ test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java

Changeset: 975e3a89814e
Author:    darcy
Date:      2013-10-21 13:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/975e3a89814e

8024603: Turn on javac lint checking for auxiliaryclass, empty, and try in jdk build
Reviewed-by: erikj, ihse, chegar

! makefiles/Setup.gmk

Changeset: f443d9b863cf
Author:    juh
Date:      2013-10-21 22:05 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f443d9b863cf

Merge


Changeset: d0882a1deeb5
Author:    juh
Date:      2013-10-22 03:49 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d0882a1deeb5

Merge


Changeset: 04ba97b7c2f9
Author:    jfranck
Date:      2013-10-22 10:34 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/04ba97b7c2f9

8009411: (reflect) Class.getMethods should not include static methods from interfaces
Summary: Update getMethods() and getMethod() to filter out interface statics
Reviewed-by: darcy
Contributed-by: joel.franck at oracle.com, andreas.lundblad at oracle.com, amy.lu at oracle.com, peter.levart at gmail.com

! src/share/classes/java/lang/Class.java
! test/java/lang/reflect/DefaultStaticTest/DefaultStaticInvokeTest.java
! test/java/lang/reflect/DefaultStaticTest/DefaultStaticTestData.java
+ test/java/lang/reflect/Method/InterfaceStatic/StaticInterfaceMethodInWayOfDefault.java

Changeset: bb2fb6be8b2a
Author:    ykantser
Date:      2013-10-22 10:57 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/bb2fb6be8b2a

8026962: Put java/lang/management/ClassLoadingMXBean/LoadCounts.java into ProblemList.txt
Reviewed-by: sla, jbachorik

! test/ProblemList.txt

Changeset: b07856d0de34
Author:    alundblad
Date:      2013-10-22 12:35 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b07856d0de34

8004912: Repeating annotations - getAnnotationsByType(Class<T>) is not working as expected for few inheritance scenarios
8019420: Repeatable non-inheritable annotation types are mishandled by Core Reflection
Reviewed-by: jfranck

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Parameter.java
! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java
! src/share/classes/sun/reflect/annotation/AnnotationSupport.java
! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java
+ test/java/lang/annotation/repeatingAnnotations/NonInheritableContainee.java
+ test/java/lang/annotation/repeatingAnnotations/OrderUnitTest.java
! test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java

Changeset: 6f9515a9519f
Author:    alanb
Date:      2013-10-22 11:43 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6f9515a9519f

8021257: com.sun.corba.se.** should be on restricted package list
Reviewed-by: chegar, coffeys, smarks, mullan
Contributed-by: alan.bateman at oralce.com, mark.sheppard at oracle.com

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/java/lang/SecurityManager/CheckPackageAccess.java

Changeset: f15ad52cffed
Author:    alanb
Date:      2013-10-22 12:04 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f15ad52cffed

8024833: (fc) FileChannel.map does not handle async close/interrupt correctly
Reviewed-by: alanb
Contributed-by: chris.w.dennis at gmail.com

! src/share/classes/sun/nio/ch/FileChannelImpl.java
+ test/java/nio/channels/FileChannel/InterruptMapDeadlock.java

Changeset: 6a1989dc302d
Author:    igerasim
Date:      2013-10-15 18:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6a1989dc302d

8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the latest jdk8 build
Summary: Removing the test as it is unreliable and fails intermittently
Reviewed-by: chegar

- test/java/net/NetworkInterface/MemLeakTest.java

Changeset: 7cafbb397683
Author:    chegar
Date:      2013-10-22 14:00 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7cafbb397683

8017779: java/net/Authenticator/B4769350.java fails
Reviewed-by: chegar
Contributed-by: Tristan Yan <tristan.yan at oracle.com>, Kurchi Subhra Hazra <kurchisubhra at gmail.com>

! test/java/net/Authenticator/B4769350.java

Changeset: 5f4aecd73caa
Author:    mullan
Date:      2013-10-22 08:03 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5f4aecd73caa

8021191: Add isAuthorized check to limited doPrivileged methods
Reviewed-by: weijun, xuelei

! src/share/classes/java/security/AccessControlContext.java
! src/share/classes/java/security/AccessController.java

Changeset: 948b390b6952
Author:    mullan
Date:      2013-10-22 08:17 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/948b390b6952

Merge

- make/sun/awt/FILES_c_macosx.gmk
- make/sun/awt/FILES_export_macosx.gmk
- makefiles/GendataBreakIterator.gmk
- makefiles/GendataFontConfig.gmk
- makefiles/GendataHtml32dtd.gmk
- makefiles/GendataTZDB.gmk
- makefiles/GendataTimeZone.gmk
- makefiles/GenerateJavaSources.gmk
- makefiles/GensrcBuffer.gmk
- makefiles/GensrcCLDR.gmk
- makefiles/GensrcCharacterData.gmk
- makefiles/GensrcCharsetCoder.gmk
- makefiles/GensrcCharsetMapping.gmk
- makefiles/GensrcExceptions.gmk
- makefiles/GensrcIcons.gmk
- makefiles/GensrcJDWP.gmk
- makefiles/GensrcJObjC.gmk
- makefiles/GensrcLocaleDataMetaInfo.gmk
- makefiles/GensrcMisc.gmk
- makefiles/GensrcProperties.gmk
- makefiles/GensrcSwing.gmk
- makefiles/GensrcX11Wrappers.gmk
- src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java
- src/macosx/native/com/apple/resources/MacOSXResourceBundle.m
- src/share/classes/java/lang/invoke/MagicLambdaImpl.java
- src/share/classes/java/net/HttpURLPermission.java
- src/solaris/doc/sun/man/man1/ja/javaws.1
- src/solaris/doc/sun/man/man1/javaws.1
- test/java/net/HttpURLPermission/HttpURLPermissionTest.java
- test/java/net/HttpURLPermission/URLTest.java
- test/java/net/HttpURLPermission/policy.1
- test/java/net/HttpURLPermission/policy.2
- test/java/net/HttpURLPermission/policy.3

Changeset: 3ea9af449b36
Author:    mullan
Date:      2013-10-22 09:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3ea9af449b36

Merge

- test/java/net/NetworkInterface/MemLeakTest.java

Changeset: 54869853c06c
Author:    alanb
Date:      2013-10-22 14:13 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/54869853c06c

7074436: (sc) SocketChannel can do short gathering writes when channel configured blocking (win)
Reviewed-by: chegar

! src/windows/native/sun/nio/ch/SocketDispatcher.c
! test/java/nio/channels/SocketChannel/ShortWrite.java

Changeset: 9758edb6976f
Author:    bpb
Date:      2013-10-22 10:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9758edb6976f

8026806: Incomplete test of getaddrinfo() return value could lead to incorrect exception for Windows Inet 6
Summary: Check getaddrinfo return value before calling WSAGetLastError.
Reviewed-by: alanb, dsamersoff

! src/windows/native/java/net/Inet6AddressImpl.c

Changeset: 23b124cbf242
Author:    drchase
Date:      2013-10-22 12:57 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/23b124cbf242

8026818: Defmeth failures with -mode invoke
Summary: Added test for IllegalAccessException -> IllegalAccessError path to check if root cause was AbstractMethodError
Reviewed-by: jrose

! src/share/classes/java/lang/invoke/MethodHandleNatives.java

Changeset: 72c0f289a8cb
Author:    kizune
Date:      2013-10-22 22:18 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/72c0f289a8cb

8026873: tools/launcher/VersionCheck.java fails in jprt because of jmc.ini
Reviewed-by: ksrini

! test/tools/launcher/VersionCheck.java

Changeset: 2be08cdd1ced
Author:    bpb
Date:      2013-10-22 11:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/2be08cdd1ced

7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE
6445180: URLClassLoader does not describe the behavior of several methods with respect to null arguments
Summary: Document when a NPE will be thrown by URLClassLoader constructors, newInstance(), findClass(), and getPermissions().
Reviewed-by: alanb, mduigou, chegar, dholmes, jrose

! src/share/classes/java/net/URLClassLoader.java
! src/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java
! src/share/classes/sun/applet/AppletClassLoader.java
+ test/java/net/URLClassLoader/NullURLTest.java

Changeset: c956a5d0618f
Author:    juh
Date:      2013-10-22 11:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c956a5d0618f

8025287: NPE in api/java_security/cert/PKIXRevocationChecker/GeneralTests_GeneralTests
Reviewed-by: mullan

! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! test/java/security/cert/PKIXRevocationChecker/UnitTest.java

Changeset: 9a32af82bd1e
Author:    darcy
Date:      2013-10-22 12:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9a32af82bd1e

8027062: Fix lint and doclint issues in java.lang.{ClassLoader, ClassValue, SecurityManager}
Reviewed-by: chegar, forax, alanb, mduigou

! src/share/classes/java/lang/ClassLoader.java
! src/share/classes/java/lang/ClassValue.java
! src/share/classes/java/lang/SecurityManager.java

Changeset: e2b814e68956
Author:    rriggs
Date:      2013-10-22 15:03 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e2b814e68956

8024686: Cleanup of java.time serialization source
Summary: optimize serialized form of OffsetTime, OffsetDateTime; correct order of modifiers
Reviewed-by: sherman

! src/share/classes/java/time/Duration.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/chrono/ChronoPeriodImpl.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/temporal/WeekFields.java
! src/share/classes/java/time/zone/Ser.java
! src/share/classes/java/time/zone/ZoneOffsetTransition.java
! test/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java
! test/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java

Changeset: d5c2b125ed0f
Author:    rriggs
Date:      2013-10-22 15:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d5c2b125ed0f

Merge


Changeset: cd60848c87b2
Author:    rriggs
Date:      2013-10-22 15:11 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/cd60848c87b2

Merge


Changeset: 4bb758a77fd7
Author:    rriggs
Date:      2013-10-22 17:02 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4bb758a77fd7

8026982: javadoc errors in core libs
Summary: Cleanup of javadoc -Xlint errors
Reviewed-by: lancea, mduigou, darcy, mullan, mchung

! src/share/classes/java/io/ByteArrayInputStream.java
! src/share/classes/java/io/ByteArrayOutputStream.java
! src/share/classes/java/io/DataInput.java
! src/share/classes/java/io/DataOutput.java
! src/share/classes/java/io/FilePermission.java
! src/share/classes/java/io/InputStream.java
! src/share/classes/java/io/ObjectInputStream.java
! src/share/classes/java/io/PipedInputStream.java
! src/share/classes/java/io/PipedReader.java
! src/share/classes/java/io/RandomAccessFile.java
! src/share/classes/java/io/Serializable.java
! src/share/classes/java/io/SerializablePermission.java
! src/share/classes/java/lang/AbstractStringBuilder.java
! src/share/classes/java/lang/ArrayStoreException.java
! src/share/classes/java/lang/Byte.java
! src/share/classes/java/lang/Character.java
! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/ClassCastException.java
! src/share/classes/java/lang/Double.java
! src/share/classes/java/lang/Float.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Iterable.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/lang/RuntimePermission.java
! src/share/classes/java/lang/Short.java
! src/share/classes/java/lang/String.java
! src/share/classes/java/lang/Thread.java
! src/share/classes/java/lang/management/ManagementFactory.java
! src/share/classes/java/lang/management/ManagementPermission.java
! src/share/classes/java/lang/management/MemoryUsage.java
! src/share/classes/java/lang/management/package.html
! src/share/classes/java/lang/reflect/ReflectPermission.java
! src/share/classes/java/net/DatagramSocket.java
! src/share/classes/java/net/Inet6Address.java
! src/share/classes/java/net/MulticastSocket.java
! src/share/classes/java/net/NetPermission.java
! src/share/classes/java/net/Proxy.java
! src/share/classes/java/net/Socket.java
! src/share/classes/java/net/SocketOptions.java
! src/share/classes/java/net/SocketPermission.java
! src/share/classes/java/net/URI.java
! src/share/classes/java/net/URLConnection.java
! src/share/classes/java/net/URLDecoder.java
! src/share/classes/java/net/URLEncoder.java
! src/share/classes/java/net/URLPermission.java
! src/share/classes/java/net/package-info.java
! src/share/classes/java/nio/X-Buffer.java.template
! src/share/classes/java/nio/file/FileSystem.java
! src/share/classes/java/rmi/activation/ActivationGroup.java
! src/share/classes/java/rmi/dgc/VMID.java
! src/share/classes/java/rmi/server/UnicastRemoteObject.java
! src/share/classes/java/security/AccessController.java
! src/share/classes/java/security/AlgorithmParameterGenerator.java
! src/share/classes/java/security/BasicPermission.java
! src/share/classes/java/security/CodeSource.java
! src/share/classes/java/security/Key.java
! src/share/classes/java/security/KeyPairGenerator.java
! src/share/classes/java/security/KeyStore.java
! src/share/classes/java/security/MessageDigest.java
! src/share/classes/java/security/Permission.java
! src/share/classes/java/security/PermissionCollection.java
! src/share/classes/java/security/SecurityPermission.java
! src/share/classes/java/security/Signature.java
! src/share/classes/java/security/SignedObject.java
! src/share/classes/java/security/acl/Acl.java
! src/share/classes/java/security/cert/CertificateFactory.java
! src/share/classes/java/security/cert/PKIXRevocationChecker.java
! src/share/classes/java/security/cert/PolicyQualifierInfo.java
! src/share/classes/java/security/cert/TrustAnchor.java
! src/share/classes/java/security/cert/X509CertSelector.java
! src/share/classes/java/security/interfaces/DSAKeyPairGenerator.java
! src/share/classes/java/text/MessageFormat.java
! src/share/classes/java/text/Normalizer.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/util/Base64.java
! src/share/classes/java/util/BitSet.java
! src/share/classes/java/util/Deque.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/Properties.java
! src/share/classes/java/util/PropertyPermission.java
! src/share/classes/java/util/Queue.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/Scanner.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/java/util/UUID.java
! src/share/classes/java/util/concurrent/BlockingDeque.java
! src/share/classes/java/util/concurrent/BlockingQueue.java
! src/share/classes/java/util/concurrent/Future.java
! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
! src/share/classes/java/util/jar/Pack200.java
! src/share/classes/java/util/logging/Logger.java
! src/share/classes/java/util/regex/Pattern.java
! src/share/classes/java/util/spi/LocaleServiceProvider.java

Changeset: e84413f066e0
Author:    mfang
Date:      2013-10-22 14:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e84413f066e0

8026109: [ja] overtranslation of  jarsigner in command line output
Reviewed-by: naoto

! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java

Changeset: 25ebb8b61371
Author:    mfang
Date:      2013-10-22 14:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/25ebb8b61371

6607048: clear extra l10n resource files in demo
Reviewed-by: naoto, yhuang

- src/share/demo/jfc/Notepad/resources/Notepad_fr.properties
- src/share/demo/jfc/Notepad/resources/Notepad_sv.properties

Changeset: f2ddffb4b165
Author:    mfang
Date:      2013-10-22 14:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f2ddffb4b165

Merge


Changeset: 9fbf35589211
Author:    smarks
Date:      2013-10-22 14:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9fbf35589211

8026427: deprecate obsolete APIs from java.rmi
Reviewed-by: alanb, dfuchs

! src/share/classes/java/rmi/RMISecurityManager.java
! src/share/classes/java/rmi/activation/ActivationGroup.java
! src/share/classes/java/rmi/server/ServerRef.java
! src/share/classes/java/rmi/server/SocketSecurityException.java

Changeset: 0913c3bab168
Author:    henryjen
Date:      2013-10-22 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0913c3bab168

8025909: Lambda Library Spec Updates
8024179: Document limitations and performance characteristics of stream sources and operations
8024138: (Spec clarification) Lambda Metafacory spec should state DMH constraint on implMethod
Reviewed-by: mduigou
Contributed-by: brian.goetz at oracle.com, paul.sandoz at oracle.com

! src/share/classes/java/lang/Iterable.java
! src/share/classes/java/lang/invoke/LambdaMetafactory.java
! src/share/classes/java/lang/invoke/SerializedLambda.java
! src/share/classes/java/util/DoubleSummaryStatistics.java
! src/share/classes/java/util/Iterator.java
! src/share/classes/java/util/List.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/PrimitiveIterator.java
! src/share/classes/java/util/Spliterator.java
! src/share/classes/java/util/function/package-info.java
! src/share/classes/java/util/stream/BaseStream.java
! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/StreamSupport.java
! src/share/classes/java/util/stream/package-info.java

Changeset: fc7a6fa3589a
Author:    ascarpino
Date:      2013-10-22 19:37 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/fc7a6fa3589a

8025763: Provider does not override new Hashtable methods
Reviewed-by: mullan

! src/share/classes/java/security/Provider.java

Changeset: b065de1700d3
Author:    mullan
Date:      2013-10-22 19:43 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b065de1700d3

Merge

- src/share/demo/jfc/Notepad/resources/Notepad_fr.properties
- src/share/demo/jfc/Notepad/resources/Notepad_sv.properties

Changeset: d545d67e2f68
Author:    weijun
Date:      2013-10-23 08:32 +0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d545d67e2f68

8027026: Change keytool -genkeypair to use -keyalg RSA
Reviewed-by: alanb, chegar, mullan

! test/ProblemList.txt
! test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh
! test/java/util/jar/JarInputStream/ExtraFileInMetaInf.java
! test/sun/security/pkcs12/PKCS12SameKeyId.java
! test/sun/security/tools/jarsigner/TimestampCheck.java
! test/sun/security/tools/jarsigner/checkusage.sh
! test/sun/security/tools/jarsigner/collator.sh
! test/sun/security/tools/jarsigner/crl.sh
! test/sun/security/tools/jarsigner/jvindex.sh
! test/sun/security/tools/jarsigner/newsize7.sh
! test/sun/security/tools/jarsigner/onlymanifest.sh
! test/sun/security/tools/jarsigner/passtype.sh
! test/sun/security/tools/jarsigner/samename.sh
! test/sun/security/tools/jarsigner/ts.sh
! test/sun/security/tools/keytool/CloseFile.java
! test/sun/security/tools/keytool/ListKeychainStore.sh
! test/sun/security/tools/keytool/StartDateTest.java
! test/sun/security/tools/keytool/UnknownAndUnparseable.java
! test/sun/security/tools/keytool/emptysubject.sh
! test/sun/security/tools/keytool/importreadall.sh
! test/sun/security/tools/keytool/p12importks.sh
! test/sun/security/tools/keytool/readjar.sh
! test/sun/security/tools/keytool/selfissued.sh
! test/sun/security/tools/keytool/trystore.sh
! test/sun/security/validator/certreplace.sh
! test/sun/security/validator/samedn.sh

Changeset: c077a2810782
Author:    egahlin
Date:      2013-10-23 10:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c077a2810782

7105883: JDWP: agent crash if there exists a ThreadGroup with null name
Reviewed-by: sla, jbachorik

! src/share/back/ThreadGroupReferenceImpl.c
+ test/com/sun/jdi/NullThreadGroupNameTest.java

Changeset: 1b0dfa631b6f
Author:    michaelm
Date:      2013-10-23 11:00 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/1b0dfa631b6f

8025734: Use literal IP address where possible in SocketPermission generated by HttpURLPermission
Reviewed-by: chegar

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/java/net/URLPermission/nstest/LookupTest.java
+ test/java/net/URLPermission/nstest/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor
+ test/java/net/URLPermission/nstest/SimpleNameService.java
+ test/java/net/URLPermission/nstest/SimpleNameServiceDescriptor.java
+ test/java/net/URLPermission/nstest/policy

Changeset: f4970c7abe93
Author:    jbachorik
Date:      2013-10-23 15:03 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f4970c7abe93

7112404: 2 tests in java/lang/management/ManagementFactory fails with G1 because expect non-zero pools
Reviewed-by: mchung, sjiang

! test/java/lang/management/ManagementFactory/ProxyTypeMapping.java
! test/java/lang/management/ManagementFactory/ValidateOpenTypes.java

Changeset: f120672b91ef
Author:    chegar
Date:      2013-10-23 14:38 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f120672b91ef

8020758: HttpCookie constructor does not throw IAE when name contains a space
Reviewed-by: michaelm, msheppar

! src/share/classes/java/net/HttpCookie.java
! test/java/net/CookieHandler/TestHttpCookie.java

Changeset: 8c20e9ef8709
Author:    sla
Date:      2013-10-23 15:55 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/8c20e9ef8709

8026789: Update test/java/lang/instrument/Re(transform|define)BigClass.sh test to use NMT for memory leak detection
Reviewed-by: dcubed

! test/ProblemList.txt
+ test/java/lang/instrument/NMTHelper.java
! test/java/lang/instrument/RedefineBigClass.sh
! test/java/lang/instrument/RedefineBigClassApp.java
! test/java/lang/instrument/RetransformBigClass.sh
! test/java/lang/instrument/RetransformBigClassApp.java

Changeset: 3cdf6ca3ef47
Author:    kizune
Date:      2013-10-23 18:35 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3cdf6ca3ef47

8020802: Need an ability to create jar files that are invariant to the pack200 packing/unpacking
Reviewed-by: alanb, ksrini

! src/share/classes/sun/tools/jar/Main.java
! src/share/classes/sun/tools/jar/resources/jar.properties
+ test/tools/jar/normalize/TestNormal.java

Changeset: 2af3f5a61322
Author:    coffeys
Date:      2013-10-23 16:53 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/2af3f5a61322

5036554: unmarshal error on CORBA alias type in CORBA any
Reviewed-by: chegar, smarks

+ test/com/sun/corba/5036554/JavaBug.java
+ test/com/sun/corba/5036554/README
+ test/com/sun/corba/5036554/TestCorbaBug.sh
+ test/com/sun/corba/5036554/bug.idl

Changeset: 88acc99132e2
Author:    rfield
Date:      2013-10-23 11:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/88acc99132e2

8027176: Remove redundant jdk/lambda/vm/DefaultMethodsTest.java
Reviewed-by: ksrini

- test/jdk/lambda/vm/DefaultMethodsTest.java

Changeset: ee7f1c78bec7
Author:    coffeys
Date:      2013-10-23 20:51 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ee7f1c78bec7

8026405: javax/xml/ws/clientjar/TestWsImport.java failing on JDK 8 nightly aurora test runs
Reviewed-by: chegar

! test/javax/xml/ws/clientjar/TestWsImport.java

Changeset: f4129fcfacdc
Author:    mduigou
Date:      2013-10-23 14:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f4129fcfacdc

8024688: further split Map and ConcurrentMap defaults eliminating looping from Map defaults, Map.merge fixes and doc fixes.
Reviewed-by: psandoz, dholmes

! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/concurrent/ConcurrentMap.java
! test/java/util/Map/Defaults.java

Changeset: d9d3705a992f
Author:    rfield
Date:      2013-10-23 15:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d9d3705a992f

8025868: Several lang/LMBD JCK tests fail with java.lang.BootstrapMethodError
Summary: Wildcard marker interfaces can cause duplicate implemented interfaces in generated lambda class
Reviewed-by: briangoetz

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
+ test/java/lang/invoke/lambda/DupIntf.java

Changeset: c9562ac9b812
Author:    dxu
Date:      2013-10-23 22:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c9562ac9b812

7122887: JDK ignores Gnome3 proxy settings
Summary: Fix GConf and add to use GProxyResolver to handle network proxy resolution
Reviewed-by: chegar

! src/solaris/native/sun/net/spi/DefaultProxySelector.c
! test/java/net/ProxySelector/SystemProxies.java

Changeset: e6bc0dca294b
Author:    sla
Date:      2013-10-15 12:53 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e6bc0dca294b

8009681: TEST_BUG: MethodExitReturnValuesTest.java may fail when there are unexpected background threads
Reviewed-by: sla, allwin
Contributed-by: mikael.auno at oracle.com

! test/com/sun/jdi/MethodEntryExitEvents.java
! test/com/sun/jdi/MethodExitReturnValuesTest.java

Changeset: 700d62b8d9cc
Author:    alanb
Date:      2013-10-24 13:24 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/700d62b8d9cc

8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable
Reviewed-by: rriggs, psandoz, chegar
Contributed-by: dl at cs.oswego.edu, alan.bateman at oracle.com

! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java
! src/share/classes/java/util/concurrent/atomic/DoubleAdder.java
! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java
! src/share/classes/java/util/concurrent/atomic/LongAdder.java
+ test/java/util/concurrent/atomic/Serial.java

Changeset: e2ec05b2ed94
Author:    igerasim
Date:      2013-10-23 15:37 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e2ec05b2ed94

8024521: (process) Async close issues with Process InputStream
Reviewed-by: psandoz, martin, alanb, robm

! src/solaris/classes/java/lang/UNIXProcess.java.bsd
! src/solaris/classes/java/lang/UNIXProcess.java.linux
+ test/java/lang/Runtime/exec/CloseRace.java

Changeset: b8927cbfb893
Author:    alundblad
Date:      2013-10-24 18:52 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b8927cbfb893

8027170: Annotations declared on super-super-class should be overridden by super-class.
Reviewed-by: jfranck
Contributed-by: andreas.lundblad at oracle.com, peter.levart at gmail.com

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/System.java
! src/share/classes/sun/misc/JavaLangAccess.java
! src/share/classes/sun/reflect/annotation/AnnotationSupport.java
+ test/java/lang/annotation/repeatingAnnotations/InheritedAssociatedAnnotations.java

Changeset: 808b9ef4f667
Author:    smarks
Date:      2013-10-24 10:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/808b9ef4f667

8023862: deprecate HTTP proxying from RMI
Reviewed-by: mchung

! src/share/classes/java/rmi/server/RMISocketFactory.java
! src/share/classes/java/rmi/server/package.html
! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java
+ test/sun/rmi/transport/proxy/DisableHttpDefaultValue.java

Changeset: 5fa2fd782993
Author:    briangoetz
Date:      2013-10-24 13:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5fa2fd782993

8019646: Clarify javadoc contract of LambdaMetafactory
Reviewed-by: briangoetz, rfield
Contributed-by: dan.smith at oracle.com

! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/java/lang/invoke/LambdaMetafactory.java

Changeset: 93e696ba5923
Author:    jfranck
Date:      2013-10-24 19:04 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/93e696ba5923

8023651: j.l.r.Constructor.getAnnotatedReceiverType() and j.l.r.Constructor.getAnnotatedReturnType() for inner classes return incorrect result
Reviewed-by: darcy

! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java
! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java
+ test/java/lang/annotation/typeAnnotations/ConstructorReceiverTest.java

Changeset: 66884b270b44
Author:    twisti
Date:      2013-10-24 10:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/66884b270b44

8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms
Reviewed-by: iveresov, jrose

! src/share/classes/java/lang/invoke/MethodHandles.java

Changeset: e7bdb2fcc7bc
Author:    sherman
Date:      2013-10-24 11:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e7bdb2fcc7bc

8025003: Base64 should be less strict with padding
Summary: updated spec and implementation of mime decoder to be lenient for padding
Reviewed-by: alanb

! src/share/classes/java/util/Base64.java
! test/java/util/Base64/Base64GetEncoderTest.java
! test/java/util/Base64/TestBase64.java
! test/java/util/Base64/TestBase64Golden.java

Changeset: 05dbf105e70f
Author:    joehw
Date:      2013-10-24 14:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/05dbf105e70f

8004476: XSLT Extension Functions Don't Work in WebStart
Reviewed-by: dfuchs, lancea, alanb

+ test/javax/xml/jaxp/transform/jdk8004476/SecureProcessingTest.xml
+ test/javax/xml/jaxp/transform/jdk8004476/TestBase.java
+ test/javax/xml/jaxp/transform/jdk8004476/XPathExFuncTest.java
+ test/javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java
+ test/javax/xml/jaxp/transform/jdk8004476/tokenize.xml
+ test/javax/xml/jaxp/transform/jdk8004476/tokenize.xsl

Changeset: e9ec0ca5bab1
Author:    weijun
Date:      2013-10-25 08:38 +0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e9ec0ca5bab1

8026929: remove accelerators from policytool resources
Reviewed-by: alexp, weijun
Contributed-by: Leif Samuelsson <leif.samuelsson at oracle.com>

! src/share/classes/sun/security/tools/policytool/PolicyTool.java
! src/share/classes/sun/security/tools/policytool/Resources.java

Changeset: d126301ad372
Author:    ewang
Date:      2013-10-25 11:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d126301ad372

7079145: Remove java/net/ipv6tests/UdpTest.java from the ProblemList.txt
Reviewed-by: alanb, chegar

! test/ProblemList.txt

Changeset: 1153022c0a45
Author:    jbachorik
Date:      2013-10-25 13:01 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/1153022c0a45

8004926: sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out
Summary: Improve reliability by converting the test to Java
Reviewed-by: dsamersoff, dholmes

! test/TEST.groups
! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java
! test/lib/testlibrary/jdk/testlibrary/StreamPumper.java
+ test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java
- test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
+ test/sun/management/jmxremote/bootstrap/LocalManagementTest.java
- test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh
! test/sun/management/jmxremote/bootstrap/TestApplication.java
! test/sun/management/jmxremote/bootstrap/TestManager.java
+ test/sun/management/jmxremote/bootstrap/linux-amd64/launcher

Changeset: 8ea272253285
Author:    smarks
Date:      2013-10-25 14:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/8ea272253285

5063500: Formatter spec says "char" is not an integral type
7126305: Wrong Unicode value specified for format conversion character 'd'
8027287: incorrect example in Formatter javadoc
Reviewed-by: rriggs, darcy, lancea

! src/share/classes/java/util/Formatter.java

Changeset: af4dd45bc7f7
Author:    dfuchs
Date:      2013-10-28 10:52 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/af4dd45bc7f7

8026863: regression in anonymous Logger.setParent method
Summary: restore behaviour of setParent in anonymous logger and clarifies the spec with respect to security permissions.
Reviewed-by: mchung, prr

! src/share/classes/java/util/logging/Logger.java
+ test/java/util/logging/AnonymousLogger/TestAnonymousLogger.java

Changeset: e7639b856256
Author:    lana
Date:      2013-10-28 12:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e7639b856256

Merge


Changeset: ecba02f6be31
Author:    sla
Date:      2013-10-29 08:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ecba02f6be31

8027371: Add JDI tests for breakpointing and stepping in lambda code
Reviewed-by: mchung, sspitsyn

+ test/com/sun/jdi/LambdaBreakpointTest.java
+ test/com/sun/jdi/LambdaStepTest.java

Changeset: d34c5e860d5f
Author:    aefimov
Date:      2013-10-24 17:23 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d34c5e860d5f

8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing
Reviewed-by: okutsu, mfang, alanb

! test/ProblemList.txt
! test/sun/util/resources/TimeZone/Bug6317929.java

Changeset: a8bbd962f34a
Author:    jlaskey
Date:      2013-01-28 16:29 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a8bbd962f34a

8006676: Integrate Nashorn into new build system
Reviewed-by: jlaskey
Contributed-by: james.laskey at oracle.com

! THIRD_PARTY_README
! make/launchers/Makefile
! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk
! test/tools/launcher/VersionCheck.java

Changeset: 41654275896d
Author:    jlaskey
Date:      2013-02-04 17:29 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/41654275896d

Merge

! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk
- src/share/classes/java/lang/annotation/ContainedBy.java
- src/share/classes/java/lang/annotation/ContainerFor.java
- test/java/net/URL/abnormal_http_urls
- test/java/net/URL/ftp_urls
- test/java/net/URL/jar_urls
- test/java/net/URL/normal_http_urls
- test/java/net/URL/runconstructor.sh
- test/java/net/URL/share_file_urls
- test/java/net/URL/win32_file_urls
- test/sun/net/www/EncDec.doc
- test/sun/net/www/MarkResetTest.java
- test/sun/net/www/MarkResetTest.sh
- test/sun/security/util/Oid/S11N.sh
- test/sun/security/util/Oid/SerialTest.java
! test/tools/launcher/VersionCheck.java

Changeset: a174944b0c00
Author:    jlaskey
Date:      2013-02-21 15:25 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a174944b0c00

8008447: Tweaks to make all NEWBUILD=false round 3
Reviewed-by: jjh, sundar
Contributed-by: james.laskey at oracle.com

! make/launchers/Makefile

Changeset: 25db7658a063
Author:    jlaskey
Date:      2013-02-22 10:23 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/25db7658a063

8008721: Tweaks to make all NEWBUILD=false round 4
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! make/launchers/Makefile

Changeset: ea22045ce09b
Author:    jlaskey
Date:      2013-02-22 14:05 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ea22045ce09b

Merge

! makefiles/CreateJars.gmk

Changeset: ff68fafd6302
Author:    jlaskey
Date:      2013-02-22 17:45 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ff68fafd6302

8008756: THIRD_PARTY_README contains Unicode
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! THIRD_PARTY_README

Changeset: ce82a0ee7735
Author:    jlaskey
Date:      2013-02-22 18:03 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ce82a0ee7735

8008757: NEWBUILD=true has separate launcher code for jjs
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! makefiles/CompileLaunchers.gmk

Changeset: 20a827b22a2e
Author:    jlaskey
Date:      2013-02-22 23:36 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/20a827b22a2e

8008775: Remove non-ascii from jdk/THIRD_PARTY_README
Reviewed-by: jjh
Contributed-by: james.laskey at oracle.com

! THIRD_PARTY_README

Changeset: 364e0871f7a3
Author:    jlaskey
Date:      2013-03-02 11:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/364e0871f7a3

Merge

! make/launchers/Makefile
! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk
- src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java
- test/javax/script/RhinoExceptionTest.java
! test/tools/launcher/VersionCheck.java

Changeset: 3565c755c49f
Author:    jlaskey
Date:      2013-03-15 11:51 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3565c755c49f

Merge

! makefiles/CreateJars.gmk

Changeset: 8c223a4f906a
Author:    jlaskey
Date:      2013-03-26 09:12 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/8c223a4f906a

Merge

! makefiles/CreateJars.gmk

Changeset: efbbcd5848cf
Author:    jlaskey
Date:      2013-04-01 10:09 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/efbbcd5848cf

Merge


Changeset: 39ce82dad57d
Author:    jlaskey
Date:      2013-04-09 08:36 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/39ce82dad57d

Merge


Changeset: ff9683b6854c
Author:    jlaskey
Date:      2013-04-15 08:27 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ff9683b6854c

Merge

! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk

Changeset: 1cdf20da340b
Author:    jlaskey
Date:      2013-04-17 08:47 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/1cdf20da340b

Merge


Changeset: 72fa581a83a4
Author:    jlaskey
Date:      2013-04-22 14:00 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/72fa581a83a4

Merge


Changeset: ead9944bbb3b
Author:    jlaskey
Date:      2013-04-29 21:37 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ead9944bbb3b

Merge


Changeset: 5bde43b1e463
Author:    jlaskey
Date:      2013-05-14 09:04 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5bde43b1e463

Merge


Changeset: efd620f8963f
Author:    jlaskey
Date:      2013-05-23 09:48 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/efd620f8963f

Merge

! makefiles/CreateJars.gmk

Changeset: 193652dff077
Author:    jlaskey
Date:      2013-05-29 13:22 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/193652dff077

Merge


Changeset: 733713d7517c
Author:    jlaskey
Date:      2013-06-05 13:10 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/733713d7517c

Merge

! makefiles/CompileLaunchers.gmk

Changeset: 3b464e13a776
Author:    jlaskey
Date:      2013-07-16 09:09 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3b464e13a776

Merge

! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk
! test/tools/launcher/VersionCheck.java

Changeset: c0a2094aaafd
Author:    jlaskey
Date:      2013-07-24 08:22 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c0a2094aaafd

Merge

- src/share/classes/javax/security/auth/callback/package.html
- src/share/classes/javax/security/auth/kerberos/package.html
- src/share/classes/javax/security/auth/login/package.html
- src/share/classes/javax/security/auth/package.html
- src/share/classes/javax/security/auth/spi/package.html
- src/share/classes/javax/security/auth/x500/package.html
- src/share/classes/javax/security/cert/package.html
- src/share/classes/javax/security/sasl/package.html

Changeset: 528fc8f4281b
Author:    jlaskey
Date:      2013-08-27 16:06 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/528fc8f4281b

Merge

! makefiles/CompileLaunchers.gmk

Changeset: be6ca7197e0e
Author:    jlaskey
Date:      2013-09-13 10:15 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/be6ca7197e0e

Merge

! makefiles/CreateJars.gmk
- src/share/classes/java/util/stream/CloseableStream.java
- src/share/classes/java/util/stream/DelegatingStream.java
- test/java/util/Map/CheckRandomHashSeed.java
- test/java/util/Map/TreeBinSplitBackToEntries.java
- test/sun/tools/jconsole/ImmutableResourceTest.java
- test/sun/tools/jconsole/ImmutableResourceTest.sh

Changeset: 74b1eb493407
Author:    jlaskey
Date:      2013-09-30 10:24 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/74b1eb493407

Merge

! makefiles/CreateJars.gmk

Changeset: f5c9333b6129
Author:    jlaskey
Date:      2013-10-29 10:40 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f5c9333b6129

Merge

! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk
! test/tools/launcher/VersionCheck.java

Changeset: 121c34517841
Author:    chegar
Date:      2013-10-29 17:21 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/121c34517841

8027466: Revert jdk/THIRD_PARTY_README to known good version
Reviewed-by: alanb

! THIRD_PARTY_README

Changeset: 6fc2889fe7d0
Author:    mfang
Date:      2013-10-29 11:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6fc2889fe7d0

8026108: [it, ja, zh_CN] wrong translation in jar example.
Reviewed-by: okutsu, yhuang

! src/share/classes/sun/tools/jar/resources/jar_it.properties
! src/share/classes/sun/tools/jar/resources/jar_ja.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties

Changeset: 0cc9bdb22911
Author:    mfang
Date:      2013-10-29 11:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0cc9bdb22911

8008437: [sv] over-translation in java command line outputs
Reviewed-by: okutsu, yhuang

! src/share/classes/sun/tools/jar/resources/jar_sv.properties

Changeset: 331d8ced56dc
Author:    mfang
Date:      2013-10-29 11:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/331d8ced56dc

8025646: [pt_BR] overtranslation of option in java command line output
Reviewed-by: naoto, yhuang

! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties

Changeset: a3ac9c0b19a9
Author:    jbachorik
Date:      2013-10-29 21:49 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a3ac9c0b19a9

8027358: sun/management/jmxremote/bootstrap/LocalManagementTest.java failing since JDK-8004926
Reviewed-by: alanb, egahlin

! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java
! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java

Changeset: 8cfc73ad9f31
Author:    mfang
Date:      2013-10-29 15:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/8cfc73ad9f31

8008647: [es] minor cosmetic issues in translated java command line outputs
Reviewed-by: naoto

! src/share/classes/sun/tools/jar/resources/jar_es.properties

Changeset: 4071c853edff
Author:    mfang
Date:      2013-10-29 15:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4071c853edff

Merge


Changeset: bede752d1e3c
Author:    mfang
Date:      2013-10-29 16:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/bede752d1e3c

8025521: [de] mnemonic conflict in FileChooser for GTK Style feel&look
Reviewed-by: naoto

! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties

Changeset: 5d1bda6c1fe3
Author:    jbachorik
Date:      2013-10-30 14:50 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5d1bda6c1fe3

8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector
Summary: Dynamically discover the first available port instead of hard-coding one
Reviewed-by: sla, chegar, dfuchs

! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java

Changeset: 9a5048dc7c0d
Author:    chegar
Date:      2013-10-30 14:41 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9a5048dc7c0d

8026880: NetworkInterface native initializing code should check fieldID values
Reviewed-by: alanb

! src/solaris/native/java/net/NetworkInterface.c
! src/windows/native/java/net/NetworkInterface.c

Changeset: b04b124418d8
Author:    ykantser
Date:      2013-10-30 13:44 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b04b124418d8

8022229: Intermittent test failures in sun/tools/jstatd
Reviewed-by: sla, egahlin, jbachorik, allwin

+ test/lib/testlibrary/jdk/testlibrary/Asserts.java
+ test/lib/testlibrary/jdk/testlibrary/JDKToolFinder.java
+ test/lib/testlibrary/jdk/testlibrary/JDKToolLauncher.java
+ test/lib/testlibrary/jdk/testlibrary/Platform.java
+ test/lib/testlibrary/jdk/testlibrary/ProcessThread.java
+ test/lib/testlibrary/jdk/testlibrary/TestThread.java
+ test/lib/testlibrary/jdk/testlibrary/Utils.java
+ test/lib/testlibrary/jdk/testlibrary/XRun.java
+ test/sun/tools/jstatd/JstatGCUtilParser.java
+ test/sun/tools/jstatd/JstatdTest.java
+ test/sun/tools/jstatd/TestJstatdDefaults.java
+ test/sun/tools/jstatd/TestJstatdExternalRegistry.java
+ test/sun/tools/jstatd/TestJstatdPort.java
+ test/sun/tools/jstatd/TestJstatdPortAndServer.java
+ test/sun/tools/jstatd/TestJstatdServer.java
+ test/sun/tools/jstatd/TestJstatdUsage.java
- test/sun/tools/jstatd/jpsOutput1.awk
- test/sun/tools/jstatd/jstatGcutilOutput1.awk
- test/sun/tools/jstatd/jstatdDefaults.sh
- test/sun/tools/jstatd/jstatdExternalRegistry.sh
- test/sun/tools/jstatd/jstatdPort.sh
- test/sun/tools/jstatd/jstatdServerName.sh
- test/sun/tools/jstatd/jstatdUsage1.sh
- test/sun/tools/jstatd/usage.out

Changeset: 550244957351
Author:    mfang
Date:      2013-10-30 09:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/550244957351

6192407: s10_70, ko, s1/dvd, minor misspelling under "Select Software Localizations"
Reviewed-by: yhuang

! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: e45b48874ba9
Author:    mfang
Date:      2013-10-30 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e45b48874ba9

6931564: Incorrect display name of Locale for south africa
Reviewed-by: yhuang

! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: 2a714dabb624
Author:    jbachorik
Date:      2013-10-30 17:54 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/2a714dabb624

8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool
Reviewed-by: mchung, brutisso

! test/java/lang/management/MemoryPoolMXBean/ThresholdTest.java

Changeset: 7bc67bed3c14
Author:    michaelm
Date:      2013-10-30 18:37 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7bc67bed3c14

8027570: NullPointerException in URLPermission.hashCode()
Reviewed-by: chegar

! src/share/classes/java/net/URLPermission.java
! test/java/net/URLPermission/URLPermissionTest.java

Changeset: 281e26d7f325
Author:    michaelm
Date:      2013-10-30 18:38 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/281e26d7f325

Merge

- make/sun/awt/FILES_c_macosx.gmk
- make/sun/awt/FILES_export_macosx.gmk
- makefiles/GendataBreakIterator.gmk
- makefiles/GendataFontConfig.gmk
- makefiles/GendataHtml32dtd.gmk
- makefiles/GendataTZDB.gmk
- makefiles/GendataTimeZone.gmk
- makefiles/GenerateJavaSources.gmk
- makefiles/GensrcBuffer.gmk
- makefiles/GensrcCLDR.gmk
- makefiles/GensrcCharacterData.gmk
- makefiles/GensrcCharsetCoder.gmk
- makefiles/GensrcCharsetMapping.gmk
- makefiles/GensrcExceptions.gmk
- makefiles/GensrcIcons.gmk
- makefiles/GensrcJDWP.gmk
- makefiles/GensrcJObjC.gmk
- makefiles/GensrcLocaleDataMetaInfo.gmk
- makefiles/GensrcMisc.gmk
- makefiles/GensrcProperties.gmk
- makefiles/GensrcSwing.gmk
- makefiles/GensrcX11Wrappers.gmk
- src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java
- src/macosx/native/com/apple/resources/MacOSXResourceBundle.m
- src/share/classes/java/lang/invoke/MagicLambdaImpl.java
! src/share/classes/java/net/URLPermission.java
- src/share/demo/jfc/Notepad/resources/Notepad_fr.properties
- src/share/demo/jfc/Notepad/resources/Notepad_sv.properties
- src/solaris/doc/sun/man/man1/ja/javaws.1
- src/solaris/doc/sun/man/man1/javaws.1
- test/java/net/NetworkInterface/MemLeakTest.java
- test/jdk/lambda/vm/DefaultMethodsTest.java
- test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
- test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh
- test/sun/tools/jstatd/jpsOutput1.awk
- test/sun/tools/jstatd/jstatGcutilOutput1.awk
- test/sun/tools/jstatd/jstatdDefaults.sh
- test/sun/tools/jstatd/jstatdExternalRegistry.sh
- test/sun/tools/jstatd/jstatdPort.sh
- test/sun/tools/jstatd/jstatdServerName.sh
- test/sun/tools/jstatd/jstatdUsage1.sh
- test/sun/tools/jstatd/usage.out

Changeset: 348ffbd19feb
Author:    lana
Date:      2013-10-30 13:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/348ffbd19feb

Merge

! makefiles/CreateJars.gmk
+ makefiles/CreateSecurityJars.gmk

Changeset: ddb0b681654a
Author:    briangoetz
Date:      2013-10-29 12:31 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ddb0b681654a

8027318: Lambda Metafactory: generate serialization-hostile read/writeObject methods for non-serializable lambdas
Reviewed-by: rfield, psandoz

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java

Changeset: f731d096530f
Author:    wetmore
Date:      2013-10-30 16:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f731d096530f

8027526: CheckTipsAndVersions.java failing occasionally
Reviewed-by: mullan, mchung

! test/java/security/Signature/SignatureGetAlgorithm.java

Changeset: e8894e3224d9
Author:    darcy
Date:      2013-10-30 17:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e8894e3224d9

8005294: Consider default methods for additions to AnnotatedElement
Reviewed-by: jfranck, plevart, mchung, abuckley, sogoel

! src/share/classes/java/lang/reflect/AnnotatedElement.java
+ test/java/lang/reflect/AnnotatedElement/TestAnnotatedElementDefaults.java

Changeset: 0734e1584d9d
Author:    bpb
Date:      2013-10-30 17:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0734e1584d9d

6910473: java.math.BigInteger.bitLength() may return negative "int" on large numbers
8021203: BigInteger.doubleValue/floatValue returns 0.0 instead of Infinity
8021204: Constructor BigInteger(String val, int radix) doesn't detect overflow
8022780: Incorrect BigInteger division because of MutableBigInteger.bitLength() overflow
Summary: Prevent construction of overflowed BigIntegers.
Reviewed-by: bpb, darcy, psandoz
Contributed-by: Dmitry Nadezhin <dmitry.nadezhin at oracle.com>

! src/share/classes/java/math/BigInteger.java
! src/share/classes/java/math/MutableBigInteger.java
+ test/java/math/BigInteger/BitLengthOverflow.java
+ test/java/math/BigInteger/DivisionOverflow.java
+ test/java/math/BigInteger/DoubleValueOverflow.java
! test/java/math/BigInteger/ExtremeShiftingTests.java
+ test/java/math/BigInteger/StringConstructorOverflow.java
+ test/java/math/BigInteger/SymmetricRangeTests.java

Changeset: 1ea1b24c1a04
Author:    smarks
Date:      2013-10-30 18:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/1ea1b24c1a04

8023863: deprecate support for statically-generated stubs from RMI (JRMP)
4449028: exportObject() javadoc should specify behavior for null socket factories
Reviewed-by: dfuchs, darcy

! src/share/classes/java/rmi/server/RemoteStub.java
! src/share/classes/java/rmi/server/UnicastRemoteObject.java
! src/share/classes/java/rmi/server/package.html

Changeset: 18c111c17231
Author:    psandoz
Date:      2013-10-31 11:59 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/18c111c17231

8027316: Distinct operation on an unordered stream should not be a barrier
Reviewed-by: henryjen, mduigou, briangoetz

! src/share/classes/java/util/stream/DistinctOps.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java

Changeset: bb4b1e1e390d
Author:    jbachorik
Date:      2013-10-31 11:59 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/bb4b1e1e390d

7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled
Summary: Make the test less stringent by not requiring the number of loaded classes to increase by a specific number
Reviewed-by: sla

! test/ProblemList.txt
! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java

Changeset: 82ee370c3d7e
Author:    briangoetz
Date:      2013-10-31 10:37 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/82ee370c3d7e

8024637: Lambda linkage performance - use reflection instead of ASM to manipulate parameter types
8023984: Lambda linkage performance - use a method ref to a static factory instead of a ctor ref
Reviewed-by: briangoetz, rfield
Contributed-by: sergey.kuksenko at oracle.com

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java

Changeset: 9732816c9d17
Author:    briangoetz
Date:      2013-10-29 12:45 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9732816c9d17

8024633: Lambda linkage performance - initialize generated class earlier
Reviewed-by: briangoetz, rfield
Contributed-by: sergey.kuksenko at oracle.com

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java

Changeset: e93de88661ab
Author:    dxu
Date:      2013-10-31 11:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e93de88661ab

8027155: test/java/io/File/NulFile.java failing when test run in othervm mode
Reviewed-by: mchung, alanb

! test/java/io/File/NulFile.java

Changeset: c4bbd5963f9c
Author:    joehw
Date:      2013-10-31 13:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c4bbd5963f9c

8024876: [TEST_BUG] javax/xml/jaxp/parsers/8022548/XOMParserTest.java failed when testbase dir has read only permissions
Reviewed-by: chegar

! test/javax/xml/jaxp/parsers/8022548/XOMParserTest.java

Changeset: f82b730c798b
Author:    lana
Date:      2013-10-31 16:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f82b730c798b

Merge

- src/share/classes/java/lang/invoke/MagicLambdaImpl.java
! src/share/classes/java/net/DatagramSocket.java
! src/share/classes/java/net/URLConnection.java
! src/share/classes/java/net/URLDecoder.java
! src/share/classes/java/net/URLEncoder.java
! src/share/classes/java/security/KeyStore.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/regex/Pattern.java
! src/share/classes/javax/naming/ldap/Rdn.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/share/classes/sun/tools/jar/Main.java
- src/share/demo/jfc/Notepad/resources/Notepad_fr.properties
- src/share/demo/jfc/Notepad/resources/Notepad_sv.properties
! src/share/javavm/export/jvm.h
! src/share/native/com/sun/java/util/jar/pack/zip.cpp
! src/solaris/classes/sun/nio/fs/UnixPath.java
- test/java/net/NetworkInterface/MemLeakTest.java
- test/jdk/lambda/vm/DefaultMethodsTest.java
- test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
- test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh
- test/sun/tools/jstatd/jpsOutput1.awk
- test/sun/tools/jstatd/jstatGcutilOutput1.awk
- test/sun/tools/jstatd/jstatdDefaults.sh
- test/sun/tools/jstatd/jstatdExternalRegistry.sh
- test/sun/tools/jstatd/jstatdPort.sh
- test/sun/tools/jstatd/jstatdServerName.sh
- test/sun/tools/jstatd/jstatdUsage1.sh
- test/sun/tools/jstatd/usage.out

Changeset: a389b4f5723f
Author:    cl
Date:      2013-11-07 08:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a389b4f5723f

Added tag jdk8-b115 for changeset f82b730c798b

! .hgtags



From Sergey.Bylokhov at oracle.com  Wed Nov 13 19:25:47 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Nov 2013 23:25:47 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5283C9D5.30602@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283719F.1030700@oracle.com>
	<5283C9D5.30602@oracle.com>
Message-ID: <5283D23B.6070505@oracle.com>

On 13.11.2013 22:49, Jim Graham wrote:
>
>
> On 11/13/13 4:33 AM, Sergey Bylokhov wrote:
>> On 12.11.2013 23:43, Jim Graham wrote:
>>> - The logic in using the transform is also a bit murky.  I think if
>>> you set the scale on a retina display to exactly 1/2 it would use the
>>> HiDPI version even though the scale was 1:1.  Since I support not
>>> examining the transform there, I'm going to present this as another
>>> reason why we should just base it on devScale, but the logic could be
>>> fixed if we really plan to use the transform here.
>> It also allow to the user to use a transform and a hint and force the
>> images to draw the scaled version even to the BufferedImage fo ex. Which
>> can be useful in case of sequential drawing of BI-> BI->retina.
>
> I think you misunderstood me here.  I'm not saying anything about the 
> BI->BI->retina case.  I'm saying that even on pure retina your logic 
> chooses the wrong scale because of mistakes made in examining the 
> transform state type.
No I understood. But a transform of the sg2d already include devScale.
This part of the fix was changed from version to version. We could use 
devScale only, or a transform if it is scaled, or an any transform. If 
nobody objects, we could use any type of transform.
My point about BI1-BI2-retina is that the user cannot control devScale, 
and so cannot force BI1 to use scaled version. But if we take into 
account current transform of the SG2D, then user can control that via 
transform and hint.

>
> If devScale is 2, but the transform is a scale then the scales used to 
> compute the resolution image will be based solely on the transform.  
> If devScale is 2, but the transform is identity, then the scales used 
> to compute the resolution image should be 1.0 because that is the 
> actual scale being applied to the image, but the logic will use 2 
> (i.e. the devScale) instead because of bad handling of the 
> transformState.
>
> Also, in the case of TRANSFORM_GENERIC just the devScale is used even 
> if they scale it down to .001.
>
> You probably need to only use the transform if you are going to use it 
> at all and you need to use it for all transformState values (there may 
> be optimizations based on the transformState, but the most complete 
> transform type should not fall through to a default, neither should 
> the translate-only states).

>
>             ...jim


-- 
Best regards, Sergey.



From james.graham at oracle.com  Wed Nov 13 19:28:57 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 13 Nov 2013 11:28:57 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5283A4A4.60007@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
Message-ID: <5283D2F9.6010100@oracle.com>

Hi Alexander,

Please read my followup message on the wording for the SunHint 
descriptions.  The version you used in this webrev contains multiple 
conflicting uses of the word "default".

The default value for the hint should be DEFAULT.  Note that Mike has 
already stated that NSImage uses @2x even on non-retina displays so it 
is not clear that the default should be different depending on devScale.

Mike's latest response raises the question - if someone creates an 
application with embedded @2x images, then they will get @2x on Macs 
even if they have a non-retina display (if they use Cocoa).  If we 
follow the same principles here, then a developer developing a Java app 
on a non-retina Mac would see the @2x images when they scale up and 
might get the impression that the @2x images will be used on any display 
with a transform, but the code to deal with them is only in the Mac 
platform code.  Should this support be more universal than that?

The logic for choosing the image scale is incorrect per my previous 
email.  You special case only TRANSLATESCALE which ignores cases where 
the transform was "scaled down to identity" on a retina display (i.e. 
those cases should not default to devScale), and ignores any transform 
with any non-scale components (i.e. g.scale(100,100); g.rotate(.001); 
will use the default resolution even though they scaled it up a lot).

The parameter passed to the getResVariant method is based on the 
subimage size, but the method treats it as if it were based on the full 
image size.  Either compute the scaled size of the full image, or inform 
the method of the sub-image being scaled, or simply pass in the scales, 
otherwise you will get the default image for any sub-image renderings of 
less than half of the original image even if they are rendered at retina 
scales.

The code in LWCToolkit.getImage() is not thread safe.  You do lock 
around the cache in the putImage() method, but you could end up 
replacing the image twice with 2 different scalable versions of the 
image since the code in LWCToolkit decided whether to make the image 
outside of any synchronization.

The File/URL code in LWCToolkit is not protected by security permission 
checks like the code in SunToolkit.

The fixes to LWCToolkit require a network connection for every image 
created to see if the @2x version exists.  Originally I thought that 
would be an immense performance hit, but I see that a 
url.openConnection() is done in SunToolkit to verify permissions.  This 
would, however, double the amount of network traffic for every image. 
Also, I'm not sure if url.openConnection() is less overhead than the 
openStream() method used in SunToolkit...?

			...jim

On 11/13/13 8:11 AM, Alexander Scherbatiy wrote:
>
>    Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.07/
>
>    -  The default sun hint is added.
>       However, it looks the same as the resolution variant ON hint right
> now. It would better to leave the behavior on the non HiDPI displays the
> same as it was before.
>       So the resolution variant hint is disabled by default for non
> HiDPI displays.
>    - Resolution variant hints description is updated.
>    - The logic operator in the  isHiDPIImage() method is formatted.
>
>     The @2x images are not preloaded in the LWCToolkit. It really can
> cause image reloading after moving a window from a display from one
> resolution to another.
>     However, it is not clear during the MultiResolutionImage creation
> will the images be used on HiDPI displays or not.
>     May be there should be a flag that enables the high resolution
> images preloading.
>
>    The original image can be replaced by the high resolution one in the
> paint() method. It causes that the observer could get an image which is
> different from the original one.
>    May be there is no any issue?  If a MultiResolutionImage is not used
> then all works as before. If a user implements MultiResolutionImage may
> be he needs to have an information
>    about the actual drawn image in the observer even it is different
> from the original.
>
>    Thanks,
>    Alexandr.
>
>
> On 11/12/2013 11:43 PM, Jim Graham wrote:
>> Hi Alexander,
>>
>> Some minor issues with this fix:
>>
>> - All RenderingHints have a default setting where the system can
>> choose for you.  The primary thing that the default settings allow is
>> for the answer to be based off of another hint.  Often the QUALITY
>> hint provides the swing vote if an individual hint is left "DEFAULT".
>> That should probably also be the setting used for SG2D, and would
>> hinge off of the devScale, for example, as the deciding factor.
>>
>> - Descriptions for "on" and "off" should be something like "Use
>> resolution variants of images" and "Use only default resolution
>> variants of images" (and "Default resolution variant usage"). Most of
>> the other descriptions on hints are statements of what is going to
>> happen or what is going to be used rather than a simple 'the X state
>> is Y'.
>>
>> - It looks like the transform is used in SG2D to decide if the hiDPI
>> image should be used.  I'm not familiar with the Mac's native use of
>> @2x, but I thought that they hinged the decision off of the "retina
>> scale" of the display, not off of the current transform.  That way, if
>> you scale down an icon it doesn't change its look when it reaches .5x
>> scale (or .75x depending on the cutoff).  Personally, I think it is
>> better to not use the transform to keep animations smooth, but I'm not
>> sure what Apple did.
>>
>> - The logic in using the transform is also a bit murky.  I think if
>> you set the scale on a retina display to exactly 1/2 it would use the
>> HiDPI version even though the scale was 1:1.  Since I support not
>> examining the transform there, I'm going to present this as another
>> reason why we should just base it on devScale, but the logic could be
>> fixed if we really plan to use the transform here.
>>
>> - The new logic in "isHiDPIImage()" is confusing because you line up
>> logic operations from 2 different levels of parentheses.  I believe
>> that one version of our style guidelines included a rule that allowed
>> "indenting to parentheses level" and I would think that would be a
>> good rule to apply here.  Or do something else to make the logic flow
>> there less tricky to read.
>>
>> - Eventually we are going to need this support in more pipelines. I
>> believe that Win8 already has parameters that affect choices of
>> images, but they are only currently deployed on the Surface tablets
>> (i.e. there are no supported high DPI displays for desktop that I'm
>> aware of, but some of the Surface tablets ship with high DPI
>> screens).  What would the impact be if we moved this into a more
>> general class in src/share?  I suppose we might spend extra time
>> looking for variants of images that we don't need?
>>
>> - Has any thought been given to the issues that someone raised with
>> cursors?
>>
>> - Has any thought been given to my comments about MediaTracker and
>> image observer states for multi-res images?  I don't see any attempt
>> here to preload the @2x image.  The problem would probably only be
>> seen on multi-headed systems where one display is retina and one is
>> not - you would find the images suddenly reloading when you move the
>> window to the other screen and the application might not expect that
>> to happen.  Which image is the Observer registered on?  Since the
>> image is handed to the Observer, will an application be surprised when
>> their observer gets a handle to an image they've never seen?  Is it an
>> issue if one of the "alternate resolution variant" images leaks into
>> an application's "hands" via the observer callbacks?
>>
>>             ...jim
>>
>> On 11/11/13 7:59 AM, Alexander Scherbatiy wrote:
>>>
>>>   Could you review the updated fix:
>>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.06/
>>>
>>>    Only internal API is exposed:
>>>    - MultiResolutionImage interface with method
>>> "getResolutionVariant(int width, int height)" is added to the
>>> com.sun.awt package
>>>    - Hints to switch on/off the resolution variant usage are added to
>>> SunHints class
>>>    - Test is updated to use the  MultiResolutionImage interface
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>> On 11/5/2013 3:16 PM, Alexander Scherbatiy wrote:
>>>>
>>>>    Thank you for the review.
>>>>
>>>>   Could you look at the updated fix:
>>>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>>>>
>>>>   - URL is parsed to protocol, host, port, and path parts in the
>>>> LWCToolkit class.
>>>>      I checked that URL(protocol, host, port, file) constructor
>>>> correctly handles -1 port value.
>>>>   - Only last file name after last '/' in the URL path  is converted
>>>> to @2x name
>>>>   - Tests that check correct URL and path translation to @2x names are
>>>> added to the ScalableImageTest
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>
>>>> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>>>>
>>>>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>>> implementation in ScalableToolkitImage works perfectly for URLs
>>>>>>> like this:
>>>>>>>
>>>>>>> http://www.exampmle.com/dir/image
>>>>>>>
>>>>>>> In this case it will try to find 2x image here:
>>>>>>>
>>>>>>> http://www.example at 2x.com/dir/image
>>>>>>>
>>>>>>> which doesn't look correct.
>>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>>
>>>>> Hi Alexander,
>>>>>
>>>>> URLs like this:
>>>>>
>>>>> http://www.example.com/dir.ext/image
>>>>>
>>>>> will still be translated to:
>>>>>
>>>>> http://www.example.com/dir at 2x.ext/image
>>>>>
>>>>>
>>>>> I think you need to search for last '.' after the last  '/' in the
>>>>> getScaledImageName();
>>>>>
>>>>>
>>>>> Also the following code has some additional bugs:
>>>>>
>>>>>   853         static Image toScalableImage(Image image, URL url) {
>>>>>   854
>>>>>   855             if (url != null && !url.toString().contains("@2x")
>>>>>   856                     && !(image instanceof
>>>>> ScalableToolkitImage)) {
>>>>>   857                 String protocol = url.getProtocol();
>>>>>   858                 String host = url.getHost();
>>>>>   859                 String file = url.getPath();
>>>>>   860                 String file2x =*host +*getScaledImageName(file);
>>>>>   861                 try {
>>>>>   862                     URL url2x = new URL(protocol, host, file2x);
>>>>>   863                     url2x.openStream();
>>>>>   864                     return new ScalableToolkitImage(image,
>>>>> getDefaultToolkit().getImage(url2x));
>>>>>   865                 } catch (Exception ignore) {
>>>>>   866                 }
>>>>>   867             }
>>>>>   868             return image;
>>>>>   869         }
>>>>>
>>>>> Why are you prepending *host* to getScaledImageName(file) in line
>>>>> 860? Let's take the following URL for example:
>>>>>
>>>>> http://www.example.com/dir/image.jpg
>>>>>
>>>>> protocol = "http"
>>>>> host = "www.example.com"
>>>>> file = "/dir/image.jpg"
>>>>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>>>>> url2x =
>>>>> URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>>>>
>>>>>
>>>>> You are missing a part in URL (de)construction - the optional port!
>>>>> For example in the following URL:
>>>>>
>>>>> http://www.example.com:8080/dir/image.jpg
>>>>>
>>>>> You should extract the port from original URL and use it in new URL
>>>>> construction if present (!= -1).
>>>>>
>>>>>
>>>>> I would also close the stream explicitly after probing for existence
>>>>> of resource rather than delegating to GC which might not be promptly
>>>>> and can cause resource exhaustion (think of MAX. # of open file
>>>>> descriptors):
>>>>>
>>>>>         try (InputStream probe = url.openStream()) {}
>>>>>
>>>>>
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>>
>>>>
>>>
>


From james.graham at oracle.com  Wed Nov 13 19:31:06 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 13 Nov 2013 11:31:06 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <3F1315D7-D09F-46F2-8A72-4C43F9CE5D8F@apple.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com>
	<71FAFA92-CEDB-4E37-BA54-92DA3B3DE8CA@apple.com>
	<5282DB56.7090306@oracle.com>
	<1495A1F8-8D5B-403A-9292-6BCF27518254@apple.com>
	<5282ED9F.805@oracle.com>
	<3F1315D7-D09F-46F2-8A72-4C43F9CE5D8F@apple.com>
Message-ID: <5283D37A.3040101@oracle.com>



On 11/13/13 9:21 AM, Mike Swingler wrote:
>> - Hopefully the answers to the above 2 questions for Mike won't be surprising...
>>
>> 			...jim
>
> I hope I haven't surprised anyone. :-)
>
> Regards,
> Mike Swingler
> Apple Inc.

Only that if the images are used on non-retina Macs then we might want 
to use the images on all platforms otherwise a developer creating a Java 
app on a non-retina Mac would be surprised when the app doesn't use them 
if it is run on Windows/Linux ... "but it used them on my Mac and it 
wasn't a retina display?"...

			...jim


From Sergey.Bylokhov at oracle.com  Wed Nov 13 19:44:39 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Nov 2013 23:44:39 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5283D23B.6070505@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283719F.1030700@oracle.com>
	<5283C9D5.30602@oracle.com> <5283D23B.6070505@oracle.com>
Message-ID: <5283D6A7.4040506@oracle.com>

On 13.11.2013 23:25, Sergey Bylokhov wrote:
>>>> - The logic in using the transform is also a bit murky.  I think if
>>>> you set the scale on a retina display to exactly 1/2 it would use the
>>>> HiDPI version even though the scale was 1:1.  Since I support not
>>>> examining the transform there, I'm going to present this as another
>>>> reason why we should just base it on devScale, but the logic could be
>>>> fixed if we really plan to use the transform here.
>>> It also allow to the user to use a transform and a hint and force the
>>> images to draw the scaled version even to the BufferedImage fo ex. 
>>> Which
>>> can be useful in case of sequential drawing of BI-> BI->retina.
>>
>> I think you misunderstood me here.  I'm not saying anything about the 
>> BI->BI->retina case.  I'm saying that even on pure retina your logic 
>> chooses the wrong scale because of mistakes made in examining the 
>> transform state type.
> No I understood. But a transform of the sg2d already include devScale.
> This part of the fix was changed from version to version. We could use 
> devScale only, or a transform if it is scaled, or an any transform. If 
> nobody objects, we could use any type of transform.
> My point about BI1-BI2-retina is that the user cannot control 
> devScale, and so cannot force BI1 to use scaled version. But if we 
> take into account current transform of the SG2D, then user can control 
> that via transform and hint.
I just realize that hint is not necessary now and can be skip it, 
because we use instanceof anyway(img instanceof MultiResolutionImage).
>
>>
>> If devScale is 2, but the transform is a scale then the scales used 
>> to compute the resolution image will be based solely on the 
>> transform.  If devScale is 2, but the transform is identity, then the 
>> scales used to compute the resolution image should be 1.0 because 
>> that is the actual scale being applied to the image, but the logic 
>> will use 2 (i.e. the devScale) instead because of bad handling of the 
>> transformState.
>>
>> Also, in the case of TRANSFORM_GENERIC just the devScale is used even 
>> if they scale it down to .001.
>>
>> You probably need to only use the transform if you are going to use 
>> it at all and you need to use it for all transformState values (there 
>> may be optimizations based on the transformState, but the most 
>> complete transform type should not fall through to a default, neither 
>> should the translate-only states).
>
>>
>>             ...jim
>
>


-- 
Best regards, Sergey.



From philip.race at oracle.com  Wed Nov 13 20:05:17 2013
From: philip.race at oracle.com (philip.race at oracle.com)
Date: Wed, 13 Nov 2013 20:05:17 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 8028206:
	sun/java2d/cmm/ProfileOp/SetDataTest.java	fails
Message-ID: <20131113200615.9254B62588@hg.openjdk.java.net>

Changeset: f2ae86dba4bc
Author:    prr
Date:      2013-11-13 11:59 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f2ae86dba4bc

8028206: sun/java2d/cmm/ProfileOp/SetDataTest.java fails
Reviewed-by: bae, jchen

! src/share/native/sun/java2d/cmm/lcms/cmsio0.c
! test/sun/java2d/cmm/ProfileOp/SetDataTest.java



From james.graham at oracle.com  Wed Nov 13 20:15:13 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 13 Nov 2013 12:15:13 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5283D23B.6070505@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283719F.1030700@oracle.com>
	<5283C9D5.30602@oracle.com> <5283D23B.6070505@oracle.com>
Message-ID: <5283DDD1.2080206@oracle.com>

Hi Sergey,

On 11/13/13 11:25 AM, Sergey Bylokhov wrote:
> On 13.11.2013 22:49, Jim Graham wrote:
>>
>>
>> On 11/13/13 4:33 AM, Sergey Bylokhov wrote:
>>> On 12.11.2013 23:43, Jim Graham wrote:
>>>> - The logic in using the transform is also a bit murky.  I think if
>>>> you set the scale on a retina display to exactly 1/2 it would use the
>>>> HiDPI version even though the scale was 1:1.  Since I support not
>>>> examining the transform there, I'm going to present this as another
>>>> reason why we should just base it on devScale, but the logic could be
>>>> fixed if we really plan to use the transform here.
>>> It also allow to the user to use a transform and a hint and force the
>>> images to draw the scaled version even to the BufferedImage fo ex. Which
>>> can be useful in case of sequential drawing of BI-> BI->retina.
>>
>> I think you misunderstood me here.  I'm not saying anything about the
>> BI->BI->retina case.  I'm saying that even on pure retina your logic
>> chooses the wrong scale because of mistakes made in examining the
>> transform state type.
> No I understood. But a transform of the sg2d already include devScale.

I fully realize that.  I am pointing out a problem that actually 
involves understanding that.  Please read more closely.

> This part of the fix was changed from version to version. We could use
> devScale only, or a transform if it is scaled, or an any transform. If
> nobody objects, we could use any type of transform.

But, you are only referencing the transform under certain conditions and 
the conditions in which you ignore it are important.  I'm not trying to 
question your goals here, I understand what they are - I am trying to 
point out that you implemented *your* goals wrong.

It would be great if you only used devScale, or if you only used the 
transform, or if the logic you wrote had some sane combination of the 
two, but the code that was written has logic errors that cause it to 
make inaccurate assumptions about the relationship of devScale to the 
current transform and that leads to inconsistent behaviors that don't 
match anyone's expectations.  devScale may indeed be an optimization for 
"what is in the transform", but your logic doesn't really detect that 
case correctly.

Note that the current code has the following behaviors some of which are 
inconsistent:

- If I am on a devScale=2 display and I am rendering the image with the 
default transform of 2x then I will get the @2x image.  This is good.

- If I am on a devScale=1 display and I am rendering the image with a 
scaled transform of 2x (the identical transform to the above), then I 
get the @2x image.  This is consistent with Mike Swingler's recent 
clarifications and is good.

- If I am on a devScale=1 display and I am rendering the image with a 
scaled transform of 2x, but rotated by 90 degrees, then I get the 
regular version of the image despite the fact that it is the same "size" 
as the previous case.  The image shouldn't suddenly shift like that if I 
just apply a rotation.  This is inconsistent.

- If I am on a devScale=1 display and I am rendering the image with an 
identity transform, then I get the regular image.  This is good.

- If I am on a devScale=2 display and I render with an identity 
transform (note that I would have to supply a downscale of 0.5 to get 
this, I have the same transform as above, but I get the @2x image, in 
contrast with the exact same sizing in the previous example.  This is 
inconsistent.

- If I am on a devScale=2 display and I downsize to < 0.5, then the 
current code will detect that I should get the regular image because the 
resulting scale when composited with devScale is <1.0 and is registered 
as a SCALE type.  This is good.

- If I am on a devScale=2 display and I downsize to <0.5, but I also 
rotate slightly, then I will get the @2x image downscaled even though I 
would have gotten the regular image had I not rotated.  This is 
inconsistent.

Basically, you've ignored all transformState values other than 
TRANSLATESCALE and the holes in that logic will create many 
inconsistencies only some of which I've outlined above.

> My point about BI1-BI2-retina is that the user cannot control devScale,
> and so cannot force BI1 to use scaled version. But if we take into
> account current transform of the SG2D, then user can control that via
> transform and hint.

I understand that you want to take the transform into account.

I understand that this is consistent with Mike Swingler's latest 
clarifications.

I am trying to help you actually do that, because your current code only 
does it in the most simplistic, but naive way that is full of 
inconsistencies.  I am trying to help you do that *consistently*...

Also, in case you don't know how to extract a scale accurately from a 
GENERAL transform, the code is simple.  You want to figure out how much 
each image pixel is stretched.  That involves delta-transforming unit 
vectors in x and y:

double coords[] = { 1, 0, 0, 1 };
tx.deltaTransform(coords, 0, coords, 0, 2);
xScale = Math.hypot(coords[0], coords[1]);
yScale = Math.hypot(coords[2], coords[3]);

Obviously, for TRANSLATE_ONLY or IDENTITY then xscale/yscale are 1 
(regardless of devScale since if the transform has devolved to a 
translate then the programmer scaled the devScale out of it already). 
You can avoid the calculation in that case (but don't default to devScale).

And for simple scales, the above simplifies to the tx.getScaleX() and 
tx.getScaleY() values as you coded (also ignoring devScale).

And even for the case of GENERAL transform, the above can be simplified. 
  The tx.deltaTransform method in that case simply loads the array with:

{ m00, m10, m01, m11 }

and so the hypot methods are simply:

xScale = Math.hypot(tx.getScaleX(), tx.getShearY());
yScale = Math.hypot(tx.getShearX(), tx.getScaleY());

It might be possible to create an optimization for quadrant-rotated 
images, but that is rare enough and the savings over the general code 
above is not enough to worry about.  If we are really worried about 
performance in the general transform case then we could bake the above 
logic into the invalidateTransform() method at the cost of adding 2 new 
fields to SG2D.  I think the above formula are fine given the complexity 
of rendering with rotated/sheared transforms.

Note that I didn't have any optimizations that use the value in devScale 
as that would only come into play if we had some way to detect "the 
transform is the default transform that was created from the devScale", 
but the transform is immediately classified as "TRANSLATESCALE" on a 
retina drawable and that could mean anything.

The inconsistencies in the current patch are that the devScale is used 
even in the case of an identity transform, but the fact that it is 
identity means that they already reduced the default devScale scale out 
of it so you shouldn't be using devScale there.  The other inconsistency 
is that you don't attempt to compute the pixel scale when the transform 
is "more than just a scale".

			...jim


From james.graham at oracle.com  Wed Nov 13 20:18:35 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 13 Nov 2013 12:18:35 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5283D6A7.4040506@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283719F.1030700@oracle.com>
	<5283C9D5.30602@oracle.com> <5283D23B.6070505@oracle.com>
	<5283D6A7.4040506@oracle.com>
Message-ID: <5283DE9B.6090700@oracle.com>

On 11/13/13 11:44 AM, Sergey Bylokhov wrote:
> On 13.11.2013 23:25, Sergey Bylokhov wrote:
>>>>> - The logic in using the transform is also a bit murky.  I think if
>>>>> you set the scale on a retina display to exactly 1/2 it would use the
>>>>> HiDPI version even though the scale was 1:1.  Since I support not
>>>>> examining the transform there, I'm going to present this as another
>>>>> reason why we should just base it on devScale, but the logic could be
>>>>> fixed if we really plan to use the transform here.
>>>> It also allow to the user to use a transform and a hint and force the
>>>> images to draw the scaled version even to the BufferedImage fo ex.
>>>> Which
>>>> can be useful in case of sequential drawing of BI-> BI->retina.
>>>
>>> I think you misunderstood me here.  I'm not saying anything about the
>>> BI->BI->retina case.  I'm saying that even on pure retina your logic
>>> chooses the wrong scale because of mistakes made in examining the
>>> transform state type.
>> No I understood. But a transform of the sg2d already include devScale.
>> This part of the fix was changed from version to version. We could use
>> devScale only, or a transform if it is scaled, or an any transform. If
>> nobody objects, we could use any type of transform.
>> My point about BI1-BI2-retina is that the user cannot control
>> devScale, and so cannot force BI1 to use scaled version. But if we
>> take into account current transform of the SG2D, then user can control
>> that via transform and hint.
> I just realize that hint is not necessary now and can be skip it,
> because we use instanceof anyway(img instanceof MultiResolutionImage).

I'm not sure what hint you are referring to under which conditions?

If you are referring to SunHint and its new values, I agree that it is 
mostly redundant now to get the default behavior that developers are 
looking for.  I thought it was being created to provide a non-public API 
for being able to turn off the behavior?  (i.e. a "use at your own risk 
since this is in sun.*" API)

I think we will support @2x images just fine without it, though...

			...jim


From Sergey.Bylokhov at oracle.com  Wed Nov 13 21:55:37 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 14 Nov 2013 01:55:37 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5283C9D5.30602@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283719F.1030700@oracle.com>
	<5283C9D5.30602@oracle.com>
Message-ID: <5283F559.2020007@oracle.com>

Hello, Jim.
On 13.11.2013 22:49, Jim Graham wrote:
> That's could be a problem. Is it possible to wrap imageObserver, which
>> was passed to the drawImage, and replace one image to another in the
>> WrapperImageObserver.imageUpdate()?
>
> It's possible - the things to watch out for:
>
> - they could hand the same IO in for multiple drawImage calls to 
> multiple images
>
> - they could hand the same IO in repeatedly for the same image while 
> it is loading if the loading takes a while or the image is animated; 
> you don't want to necessarily create an infinite number of wrappers 
> for the same observer and register them all with the image loading 
> mechanism
>
> - the image that you report to them should probably be the original 
> image, not the resolution-specific underlying images
>
> - we need to deal with making sure that the information flowing to the 
> IO does not report complete until all resolution variants that we plan 
> to load are done
>
> - given Mike's answer to my previous questions, it looks like @2x is 
> not a retina-specific issue, all images do that even non non-retina 
> apparently so maybe we do want to load all variants up front?
>
> - we don't want to pass ERROR conditions to the IO unless all 
> resolution variants are errored, we should silently swallow any ERROR 
> conditions for just some of the resolution variants and make do with 
> what we have
Well, it is necessary to decide that it is simpler to bypass all these 
problems or to move them to the user. As ScalableToolkitImage 
implementation is trivial.
>
>             ...jim


-- 
Best regards, Sergey.



From james.graham at oracle.com  Wed Nov 13 22:08:40 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 13 Nov 2013 14:08:40 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5283F559.2020007@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283719F.1030700@oracle.com>
	<5283C9D5.30602@oracle.com> <5283F559.2020007@oracle.com>
Message-ID: <5283F868.9060300@oracle.com>

If, by bypass, you mean that we would simply punt, then I think we need 
to test the behavior with MediaTracker minimally.  I get the impression 
that MT will not work with these new wrappers for a couple of reasons 
(needing to track the indicated image instance, and it would only track 
the original size so that the first render to a retina scale would 
fail).  As to the other issues, I worry about them, but I have no direct 
data of how much headache they will cause our developers...

			...jim

On 11/13/13 1:55 PM, Sergey Bylokhov wrote:
> Hello, Jim.
> On 13.11.2013 22:49, Jim Graham wrote:
>> That's could be a problem. Is it possible to wrap imageObserver, which
>>> was passed to the drawImage, and replace one image to another in the
>>> WrapperImageObserver.imageUpdate()?
>>
>> It's possible - the things to watch out for:
>>
>> - they could hand the same IO in for multiple drawImage calls to
>> multiple images
>>
>> - they could hand the same IO in repeatedly for the same image while
>> it is loading if the loading takes a while or the image is animated;
>> you don't want to necessarily create an infinite number of wrappers
>> for the same observer and register them all with the image loading
>> mechanism
>>
>> - the image that you report to them should probably be the original
>> image, not the resolution-specific underlying images
>>
>> - we need to deal with making sure that the information flowing to the
>> IO does not report complete until all resolution variants that we plan
>> to load are done
>>
>> - given Mike's answer to my previous questions, it looks like @2x is
>> not a retina-specific issue, all images do that even non non-retina
>> apparently so maybe we do want to load all variants up front?
>>
>> - we don't want to pass ERROR conditions to the IO unless all
>> resolution variants are errored, we should silently swallow any ERROR
>> conditions for just some of the resolution variants and make do with
>> what we have
> Well, it is necessary to decide that it is simpler to bypass all these
> problems or to move them to the user. As ScalableToolkitImage
> implementation is trivial.
>>
>>             ...jim
>
>


From andrew.brygin at oracle.com  Mon Nov 18 07:34:55 2013
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Mon, 18 Nov 2013 11:34:55 +0400
Subject: [OpenJDK 2D-Dev] RFR: Fix for 8027541: Fully transparent jframe
 becomes black.
In-Reply-To: <527D65C7.9070707@oracle.com>
References: <527D65C7.9070707@oracle.com>
Message-ID: <5289C31F.8030208@oracle.com>

Hello Phil,

  the change looks fine to me.

Thanks,
Andrew

On 11/9/2013 2:29 AM, Phil Race wrote:
> http://cr.openjdk.java.net/~prr/8027541/
>
> In the case where there is an alpha color on the window, the
> X11 pipeline looks at the color model of the GraphicsConfiguration
> and upgrades the surface to one with alpha. This makes the Xrender
> pipeline do the same. SQE test failure, so no regression test needed
> in this case.
>
> -phil.



From alexandr.scherbatiy at oracle.com  Tue Nov 19 13:06:37 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 19 Nov 2013 17:06:37 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5283D2F9.6010100@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
	<5283D2F9.6010100@oracle.com>
Message-ID: <528B625D.7060406@oracle.com>


   Could you review the updated fix:
      http://cr.openjdk.java.net/~alexsch/8011059/webrev.08/
      - Some related to the ToolkitImage staff is moved from SunToolkit 
to ToolkitImageUtil
      - MultiResolutionToolkitImage is moved from the LWCToolkit to 
sun.awt.image package
      - Preloading for the resolution variants is added
      - Algorithm for the retrieving resolution variants in 
g.drawImage() method is updated
      - The test is updated

    See more comments inline:

On 11/13/2013 11:28 PM, Jim Graham wrote:
> Hi Alexander,
>
> Please read my followup message on the wording for the SunHint 
> descriptions.  The version you used in this webrev contains multiple 
> conflicting uses of the word "default".
>
> The default value for the hint should be DEFAULT.  Note that Mike has 
> already stated that NSImage uses @2x even on non-retina displays so it 
> is not clear that the default should be different depending on devScale.
      The fix sets the resolution variant hint to default on Mac OS X 
and to off for other platforms now.
>
> Mike's latest response raises the question - if someone creates an 
> application with embedded @2x images, then they will get @2x on Macs 
> even if they have a non-retina display (if they use Cocoa). If we 
> follow the same principles here, then a developer developing a Java 
> app on a non-retina Mac would see the @2x images when they scale up 
> and might get the impression that the @2x images will be used on any 
> display with a transform, but the code to deal with them is only in 
> the Mac platform code.  Should this support be more universal than that?
>
> The logic for choosing the image scale is incorrect per my previous 
> email.  You special case only TRANSLATESCALE which ignores cases where 
> the transform was "scaled down to identity" on a retina display (i.e. 
> those cases should not default to devScale), and ignores any transform 
> with any non-scale components (i.e. g.scale(100,100); g.rotate(.001); 
> will use the default resolution even though they scaled it up a lot).
      The new logic uses the transform to get the destination image 
width and height.
      There is the trick question about the general transform type 
because image sides are not equal after the transformation in this case. 
So we could use only one side,
      or maximum value from opposite sides or may be an average value.

> The parameter passed to the getResVariant method is based on the 
> subimage size, but the method treats it as if it were based on the 
> full image size.  Either compute the scaled size of the full image, or 
> inform the method of the sub-image being scaled, or simply pass in the 
> scales, otherwise you will get the default image for any sub-image 
> renderings of less than half of the original image even if they are 
> rendered at retina scales.
    This is my fault. I really missed this part.  It is updated in the fix.

> The code in LWCToolkit.getImage() is not thread safe.  You do lock 
> around the cache in the putImage() method, but you could end up 
> replacing the image twice with 2 different scalable versions of the 
> image since the code in LWCToolkit decided whether to make the image 
> outside of any synchronization.
     Fixed.
>
> The File/URL code in LWCToolkit is not protected by security 
> permission checks like the code in SunToolkit.
    Fixed.
> The fixes to LWCToolkit require a network connection for every image 
> created to see if the @2x version exists.  Originally I thought that 
> would be an immense performance hit, but I see that a 
> url.openConnection() is done in SunToolkit to verify permissions. This 
> would, however, double the amount of network traffic for every image. 
> Also, I'm not sure if url.openConnection() is less overhead than the 
> openStream() method used in SunToolkit...?

     The algorithm that gets the scaled image size is based on the width 
and height of both images original and scaled. That means that both 
images should be already preloaded.
     In other case we need to draw the original image (because it is not 
possible to know the destination image size)  and wait for more 
drawImage(Image ) calls to try to load the scaled image.

     It seems that multi-resolution image preloading fixes image drawing 
issue as well as issue with the image observers. An image observer is 
not called from the g.drawImage()
     method in case if both images images are preloded and the original 
image does not have errors.

     The fix does not use url.openConnection() now. It tries to preload 
the @2x image and if it is successful it preloads the original image as 
well.

    I also look at the custom cursor part of the HiDPI issues. A user 
needs to prepare the MultiResolutionImage and we can use 
CImage.createFromImages(List<Image> images)
    method to create necessary NSImage. This means that it should be 
possible to obtain all resolution variants from the MultiResolutionImage.
    I have included the "List<Image> getResolutionVariants()" method to 
the MultiResolutionImage for that.

   Thanks,
   Alexandr.

>
>             ...jim
>
> On 11/13/13 8:11 AM, Alexander Scherbatiy wrote:
>>
>>    Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.07/
>>
>>    -  The default sun hint is added.
>>       However, it looks the same as the resolution variant ON hint right
>> now. It would better to leave the behavior on the non HiDPI displays the
>> same as it was before.
>>       So the resolution variant hint is disabled by default for non
>> HiDPI displays.
>>    - Resolution variant hints description is updated.
>>    - The logic operator in the  isHiDPIImage() method is formatted.
>>
>>     The @2x images are not preloaded in the LWCToolkit. It really can
>> cause image reloading after moving a window from a display from one
>> resolution to another.
>>     However, it is not clear during the MultiResolutionImage creation
>> will the images be used on HiDPI displays or not.
>>     May be there should be a flag that enables the high resolution
>> images preloading.
>>
>>    The original image can be replaced by the high resolution one in the
>> paint() method. It causes that the observer could get an image which is
>> different from the original one.
>>    May be there is no any issue?  If a MultiResolutionImage is not used
>> then all works as before. If a user implements MultiResolutionImage may
>> be he needs to have an information
>>    about the actual drawn image in the observer even it is different
>> from the original.
>>
>>    Thanks,
>>    Alexandr.
>>
>>
>> On 11/12/2013 11:43 PM, Jim Graham wrote:
>>> Hi Alexander,
>>>
>>> Some minor issues with this fix:
>>>
>>> - All RenderingHints have a default setting where the system can
>>> choose for you.  The primary thing that the default settings allow is
>>> for the answer to be based off of another hint.  Often the QUALITY
>>> hint provides the swing vote if an individual hint is left "DEFAULT".
>>> That should probably also be the setting used for SG2D, and would
>>> hinge off of the devScale, for example, as the deciding factor.
>>>
>>> - Descriptions for "on" and "off" should be something like "Use
>>> resolution variants of images" and "Use only default resolution
>>> variants of images" (and "Default resolution variant usage"). Most of
>>> the other descriptions on hints are statements of what is going to
>>> happen or what is going to be used rather than a simple 'the X state
>>> is Y'.
>>>
>>> - It looks like the transform is used in SG2D to decide if the hiDPI
>>> image should be used.  I'm not familiar with the Mac's native use of
>>> @2x, but I thought that they hinged the decision off of the "retina
>>> scale" of the display, not off of the current transform.  That way, if
>>> you scale down an icon it doesn't change its look when it reaches .5x
>>> scale (or .75x depending on the cutoff).  Personally, I think it is
>>> better to not use the transform to keep animations smooth, but I'm not
>>> sure what Apple did.
>>>
>>> - The logic in using the transform is also a bit murky.  I think if
>>> you set the scale on a retina display to exactly 1/2 it would use the
>>> HiDPI version even though the scale was 1:1.  Since I support not
>>> examining the transform there, I'm going to present this as another
>>> reason why we should just base it on devScale, but the logic could be
>>> fixed if we really plan to use the transform here.
>>>
>>> - The new logic in "isHiDPIImage()" is confusing because you line up
>>> logic operations from 2 different levels of parentheses.  I believe
>>> that one version of our style guidelines included a rule that allowed
>>> "indenting to parentheses level" and I would think that would be a
>>> good rule to apply here.  Or do something else to make the logic flow
>>> there less tricky to read.
>>>
>>> - Eventually we are going to need this support in more pipelines. I
>>> believe that Win8 already has parameters that affect choices of
>>> images, but they are only currently deployed on the Surface tablets
>>> (i.e. there are no supported high DPI displays for desktop that I'm
>>> aware of, but some of the Surface tablets ship with high DPI
>>> screens).  What would the impact be if we moved this into a more
>>> general class in src/share?  I suppose we might spend extra time
>>> looking for variants of images that we don't need?
>>>
>>> - Has any thought been given to the issues that someone raised with
>>> cursors?
>>>
>>> - Has any thought been given to my comments about MediaTracker and
>>> image observer states for multi-res images?  I don't see any attempt
>>> here to preload the @2x image.  The problem would probably only be
>>> seen on multi-headed systems where one display is retina and one is
>>> not - you would find the images suddenly reloading when you move the
>>> window to the other screen and the application might not expect that
>>> to happen.  Which image is the Observer registered on?  Since the
>>> image is handed to the Observer, will an application be surprised when
>>> their observer gets a handle to an image they've never seen? Is it an
>>> issue if one of the "alternate resolution variant" images leaks into
>>> an application's "hands" via the observer callbacks?
>>>
>>>             ...jim
>>>
>>> On 11/11/13 7:59 AM, Alexander Scherbatiy wrote:
>>>>
>>>>   Could you review the updated fix:
>>>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.06/
>>>>
>>>>    Only internal API is exposed:
>>>>    - MultiResolutionImage interface with method
>>>> "getResolutionVariant(int width, int height)" is added to the
>>>> com.sun.awt package
>>>>    - Hints to switch on/off the resolution variant usage are added to
>>>> SunHints class
>>>>    - Test is updated to use the  MultiResolutionImage interface
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>> On 11/5/2013 3:16 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>>    Thank you for the review.
>>>>>
>>>>>   Could you look at the updated fix:
>>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.05/
>>>>>
>>>>>   - URL is parsed to protocol, host, port, and path parts in the
>>>>> LWCToolkit class.
>>>>>      I checked that URL(protocol, host, port, file) constructor
>>>>> correctly handles -1 port value.
>>>>>   - Only last file name after last '/' in the URL path  is converted
>>>>> to @2x name
>>>>>   - Tests that check correct URL and path translation to @2x names 
>>>>> are
>>>>> added to the ScalableImageTest
>>>>>
>>>>>   Thanks,
>>>>>   Alexandr.
>>>>>
>>>>>
>>>>> On 11/1/2013 12:46 AM, Peter Levart wrote:
>>>>>>
>>>>>> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote:
>>>>>>>> 2. I'm not sure that the proposed getScaledImageName()
>>>>>>>> implementation in ScalableToolkitImage works perfectly for URLs
>>>>>>>> like this:
>>>>>>>>
>>>>>>>> http://www.exampmle.com/dir/image
>>>>>>>>
>>>>>>>> In this case it will try to find 2x image here:
>>>>>>>>
>>>>>>>> http://www.example at 2x.com/dir/image
>>>>>>>>
>>>>>>>> which doesn't look correct.
>>>>>>>        Fixed. Only path part of a URL is converted to path2x.
>>>>>>
>>>>>> Hi Alexander,
>>>>>>
>>>>>> URLs like this:
>>>>>>
>>>>>> http://www.example.com/dir.ext/image
>>>>>>
>>>>>> will still be translated to:
>>>>>>
>>>>>> http://www.example.com/dir at 2x.ext/image
>>>>>>
>>>>>>
>>>>>> I think you need to search for last '.' after the last '/' in the
>>>>>> getScaledImageName();
>>>>>>
>>>>>>
>>>>>> Also the following code has some additional bugs:
>>>>>>
>>>>>>   853         static Image toScalableImage(Image image, URL url) {
>>>>>>   854
>>>>>>   855             if (url != null && !url.toString().contains("@2x")
>>>>>>   856                     && !(image instanceof
>>>>>> ScalableToolkitImage)) {
>>>>>>   857                 String protocol = url.getProtocol();
>>>>>>   858                 String host = url.getHost();
>>>>>>   859                 String file = url.getPath();
>>>>>>   860                 String file2x =*host 
>>>>>> +*getScaledImageName(file);
>>>>>>   861                 try {
>>>>>>   862                     URL url2x = new URL(protocol, host, 
>>>>>> file2x);
>>>>>>   863                     url2x.openStream();
>>>>>>   864                     return new ScalableToolkitImage(image,
>>>>>> getDefaultToolkit().getImage(url2x));
>>>>>>   865                 } catch (Exception ignore) {
>>>>>>   866                 }
>>>>>>   867             }
>>>>>>   868             return image;
>>>>>>   869         }
>>>>>>
>>>>>> Why are you prepending *host* to getScaledImageName(file) in line
>>>>>> 860? Let's take the following URL for example:
>>>>>>
>>>>>> http://www.example.com/dir/image.jpg
>>>>>>
>>>>>> protocol = "http"
>>>>>> host = "www.example.com"
>>>>>> file = "/dir/image.jpg"
>>>>>> file2x = "*www.example.com*/dir/image at 2x.jpg"
>>>>>> url2x =
>>>>>> URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg")
>>>>>>
>>>>>>
>>>>>> You are missing a part in URL (de)construction - the optional port!
>>>>>> For example in the following URL:
>>>>>>
>>>>>> http://www.example.com:8080/dir/image.jpg
>>>>>>
>>>>>> You should extract the port from original URL and use it in new URL
>>>>>> construction if present (!= -1).
>>>>>>
>>>>>>
>>>>>> I would also close the stream explicitly after probing for existence
>>>>>> of resource rather than delegating to GC which might not be promptly
>>>>>> and can cause resource exhaustion (think of MAX. # of open file
>>>>>> descriptors):
>>>>>>
>>>>>>         try (InputStream probe = url.openStream()) {}
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards, Peter
>>>>>>
>>>>>>
>>>>>
>>>>
>>



From philip.race at oracle.com  Tue Nov 19 18:41:27 2013
From: philip.race at oracle.com (philip.race at oracle.com)
Date: Tue, 19 Nov 2013 18:41:27 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 8027541: ully transparent jframe
	becomes black.
Message-ID: <20131119184224.A1FD4626BF@hg.openjdk.java.net>

Changeset: e5eb65043d31
Author:    prr
Date:      2013-11-19 10:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e5eb65043d31

8027541: ully transparent jframe becomes black.
Reviewed-by: bae, ceisserer

! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java



From philip.race at oracle.com  Tue Nov 19 18:57:59 2013
From: philip.race at oracle.com (Phil Race)
Date: Tue, 19 Nov 2013 10:57:59 -0800
Subject: [OpenJDK 2D-Dev] <2D Dev> [8] Review Request: JDK-8025235
 [javadoc] fix some errors in 2D
In-Reply-To: <528B827A.3000507@oracle.com>
References: <52713614.1050408@oracle.com> <527CA369.6000806@oracle.com>
	<528395C3.6030607@oracle.com> <528B827A.3000507@oracle.com>
Message-ID: <528BB4B7.9040609@oracle.com>

Approved.

-phil.

On 11/19/2013 7:23 AM, Dmitry Ginzburg wrote:
> Hi guys,
>
> ?ould you please approve this 4-th version of doclint errors cleanup 
> change in 2d code: 
> http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.03/ ?
> The changes are against 2d team repository of jdk8.
>
> The patch contains only simple markup fixes; no changes/fixes in 
> documentation text; the specification itself wasn't changed.
>
> Thanks,
> -Dmitry
>
> 13.11.2013 19:07, Dmitry Ginzburg wrote:
>> Hi Phil, Guys ,
>>
>>
>> This one is stuck waiting for review for quite long time.
>> Please review so we can push this change.
>>
>> Thanks,
>> -Dmitry
>>
>> 08.11.2013 12:40, Dmitry Ginzburg wrote:
>>> Colleagues,
>>>
>>> friendly reminder.
>>> Back in early October I did all proposed changes; could you please
>>> review this third version of doclint fix?
>>>
>>> Thanks,
>>> -Dmitry
>>>
>>> 30.10.2013 20:38, Dmitry Ginzburg wrote:
>>>> Hi guys
>>>> I haven't got any review from you on this issue. Can you please review it?
>>>> For some issue, my e-mail have changed todmitry.x.ginzburg at oracle.com
>>>> Thanks, Dmitry
>>>> *
>>>> Dmitry Ginzburg*  dmitry.ginzburg at oracle.com    <mailto:2d-dev%40openjdk.java.net?Subject=%5BOpenJDK%202D-Dev%5D%20%3C2D%20Dev%3E%20%5B8%5D%20Review%20Request%3A%20JDK-8025235%0A%20%5Bjavadoc%5D%20fix%20some%20errors%20in%202D&In-Reply-To=524EE4DB.8010602%40oracle.com>
>>>> /Tue Oct 15 06:02:58 PDT 2013/
>>>>
>>>> See new webrev:http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.02/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.02/>  
>>>> <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.02/>
>>>> Some changes are deleted, because they're fixed by someone but me
>>>>
>>>> 04.10.2013 19:55, Phil Race wrote:
>>>> >/  Hi,
>>>> />/
>>>> />/  A few places you used {@code that is not code} : ie PageAttributes for
>>>> />/  the &
>>>> />/  and Line2D.Float() constructor and  in MultipleMaster are the ones I
>>>> />/  spotted
>>>> />/  probably aren't appropriate as they aren't code, and the {@code ..}
>>>> />/  will use
>>>> />/  a fixed width font. So one char will be in a different font.
>>>> />/  As I suggested in PageAttributes just use "and", there's no reason it
>>>> />/  has to
>>>> />/  be an ampersand.
>>>> />/
>>>> />/  -phil.
>>>> />/
>>>> />/  On 10/4/2013 5:59 AM, Dmitry Ginzburg wrote:
>>>> />>/  Hi, Phil
>>>> />>/
>>>> />>/  I renewed webrev against your issues:
>>>> />>/  http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.01/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.01/>  
>>>> />>/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.01/>
>>>> />>/
>>>> />>/  Thanks,
>>>> />>/  -Dmitry
>>>> />>/
>>>> />>/  03.10.2013 08:41, Phil Race wrote:
>>>> />>>/  1. This webrev is not against the 2D forest. Please re-generate
>>>> />>>/  against 2D.
>>>> />>>/
>>>> />>>/  2.
>>>> />>>/  /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/GraphicsConfiguration.java:84:
>>>> />>>/  error: malformed HTML
>>>> />>>/     When you have < & > chars in code the preferred solution uses
>>>> />>>/  {@code .. }  like this :
>>>> />>>/  http://cr.openjdk.java.net/~prr/8022175/src/share/classes/javax/print/ServiceUI.java.sdiff.html  <http://cr.openjdk.java.net/%7Eprr/8022175/src/share/classes/javax/print/ServiceUI.java.sdiff.html>  
>>>> />>>/
>>>> />>>/
>>>> />>>/  3. Same as above for GraphicsDevice
>>>> />>>/
>>>> />>>/  4. Same as above for MediaTracker (it'll fix all 3 issues)
>>>> />>>/
>>>> />>>/  5. I think we should change all 12 or so of these to the word "and"
>>>> />>>/
>>>> />>>/  6. Rectangle : same as 2
>>>> />>>/
>>>> />>>/  7. LineBreakMeasurer : same again in all locations
>>>> />>>/
>>>> />>>/  8. {@code .. } should fix this too
>>>> />>>/
>>>> />>>/  9. LIne2D 626: {@code true} would be better here too
>>>> />>>/
>>>> />>>/  10. PrinterJob: {@code .. } again
>>>> />>>/
>>>> />>>/  Make sure you verify by re-running doclint on the fixed repo.
>>>> />>>/
>>>> />>>/  That's all.
>>>> />>>/
>>>> />>>/  -phil.
>>>> />>>/
>>>> />>>/  On 9/26/13 7:21 AM, Dmitry Ginzburg wrote:
>>>> />>>>/  Hello, 2D Team.
>>>> />>>>/
>>>> />>>>/  Please review the fix for the following issue:
>>>> />>>>/  https://bugs.openjdk.java.net/browse/JDK-8025235
>>>> />>>>/  The fix is available at:
>>>> />>>>/  http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.00/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.00/>
>>>> />>>>/
>>>> />>>>/  This is the fix for javadoc errors, on which doclint was showing
>>>> />>>>/  some issues.
>>>> />>>>/
>>>> />>>>/  The patch contains only simple markup fixes; no changes/fixes in
>>>> />>>>/  documentation text; the specification itself wasn't changed.
>>>> />>>>/
>>>> />>>>/  Thanks,
>>>> />>>>/  -Dmitry
>>>> />>>/
>>>> />>/
>>>> />>/
>>>> />>/  --
>>>> />>/  Dmitry Ginzburg, FXSQE team member
>>>> />/
>>>> /
>>>
>>
>



From james.graham at oracle.com  Tue Nov 19 23:55:18 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 19 Nov 2013 15:55:18 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <528B625D.7060406@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
	<5283D2F9.6010100@oracle.com> <528B625D.7060406@oracle.com>
Message-ID: <528BFA66.7040307@oracle.com>

Hi Alexander:

SunHints:

The text for the descriptions on the hints is still not updated to the text I asked for in a previous message.  Since there were multiple messages on that I thought I would paste the particular comment I was referring to:

>>> - Descriptions for "on" and "off" should be something like "Use
>>> resolution variants of images" and "Use only default resolution variants
>>> of images" (and "Default resolution variant usage").  Most of the other
>>> descriptions on hints are statements of what is going to happen or what
>>> is going to be used rather than a simple 'the X state is Y'.
>
> Reading this after the fact I realize that the word "default" is being used in two different ways in the descriptions I proposed.  Perhaps:
>
> ON - Always use resolution-specific variants of images
> OFF - Use only the standard resolution of an image
> DEFAULT - Choose image resolutions based on a default heuristic
>
> (perhaps add "(when available)" to ON?)

Note that I think you are still using the descriptions I asked for in the first quotation which I then revised because they were confusing.  Please use the latter descriptions (ON, OFF, DEFAULT above).

SG2D:

- If you rewrite getTransformedDestImageSize() to return the resolution variant instead of a Dimension then you avoid having to create a Dimension object that gets immediately tested for null again and/or consumed by the caller.  Just move the call to getResolutionVariant() inside the helper method and rename it.

- In getTransformedDestImageSize - dx,dy,sx,sy - should be named dw,dh,sw,sh?

- Also in getTransformedDestImageSize - the array of Point objects is problematic because they are used for the return values and that means early truncation/rounding, the methods that take arrays of doubles are generally less problematic in terms of garbage generation.  Also, you can use deltaTransform() because you don't need to worry about translation components since you only want the distance.  Finally, why not use the optimization I gave to just grab the matrix elements directly and do the calculations on them instead of 3 separate point transforms which have predictable outcomes?  Here is the recommendation again:

> And even for the case of GENERAL transform, the above can be simplified.  The tx.deltaTransform method in that case simply loads the array with:
>
> { m00, m10, m01, m11 }
>
> and so the hypot methods are simply:
>
> xScale = Math.hypot(tx.getScaleX(), tx.getShearY());
> yScale = Math.hypot(tx.getShearX(), tx.getScaleY());

Multiply those values with dw,dh and you have your answer.  Another way to look at this is that your 3 transformed points were basically:

     { dx1 * m00 + dy1 * m01 + tx,  dx1 * m10 + dy1 * m11 + ty }
     { dx2 * m00 + dy1 * m01 + tx,  dx2 * m10 + dy1 * m11 + ty }
     { dx1 * m00 + dy2 * m01 + tx,  dx1 * m10 + dy2 * m11 + ty }

Subtracting [1] - [0] for the distance calculation eliminates a lot of terms and gives you:

     Math.hypot((dx2 - dx1) * m00, (dx2 - dx1) * m10)
==  (dx2 - dx1) * Math.hypot(m00, m10);
==  (dx2 - dx1) * Math.hypot(tx.getScaleX(), tx.getShearY());

Subtracting [2] - [0] also reduces:

     Math.hypot((dy2 - dy1) * m01, (dy2 - dy1) * m11);
==  (dy2 - dy1) * Math.hypot(m01, m11);
==  (dy2 - dy1) * Math.hypot(tx.getShearX(), tx.getScaleY());

- Also in getTransformeDestImageSize - the usage of the transform.getType() is off, some of the values are bitmasks so a <= comparison isn't the right comparison to use.  I'd use the following structure:

To check if it is "identity-ish", I'd use:
     ((type & ~(TYPE_TRANSLATION | TYPE_FLIP)) == 0)
To check for scale, use:
     ((type & ~(TYPE_TRANSLATION | TYPE_FLIP | TYPE_SCALE_MASK)) == 0)
and then the distance/hypot equations are in the final else as they are now.

- In calculating scaledWidth/width and the cast to float - even though I think the precedence order is on your side, I usually add extra parentheses to highlight the order so that people reading the code and/or modifying it don't mess it up.  My cutoff on what is obvious to a casual reader is usually "additive vs. multiplicative" and anything more subtle than that I use parentheses just in case someone comes along who is less familiar with the order and decides to interpose some additional operations that get in the way of the proper calculation.  I would have written "((float) sW) / w" just to make it obvious.

In LWCToolkit.java:

- there is a lot of string manipulation going on for every image fetch.  I guess this would only hurt those who use the Toolkit as their image storage (getting the image every time they need it), so I'm not going to worry about it, but it would be good to eventually get this integrated into the caching mechanism better so that a quick lookup of a previously loaded image could return faster.

One thing I did not examine very closely was the transfer of hash lookup and security code to the new utility class.  You should get a double-check from another engineer on that code.

Some more inline comments:

On 11/19/2013 5:06 AM, Alexander Scherbatiy wrote:
>
>    Could you review the updated fix:
>       http://cr.openjdk.java.net/~alexsch/8011059/webrev.08/
>       - Some related to the ToolkitImage staff is moved from SunToolkit to ToolkitImageUtil

I'm not sure why this was done - it added a bunch of busy-work for approving the webrev that I don't have time for.  Hopefully someone else can verify the cut/paste and refactoring.

>       - Preloading for the resolution variants is added

I'm not familiar with the ImageIcon, but it looks like the use of it for the resolution variant causes the resolution variant images to be aggressively kicked off immediately rather than as the image is used.  For an application that loads 1000 images and then only renders 10 of them, it will get 1000 4xsized images (@2x have 4x pixels) loaded for 990 images that would never have been loaded previously.  Am I misreading how the ImageIcon is used there?

>       The fix sets the resolution variant hint to default on Mac OS X and to off for other platforms now.

I'm still not sure why it isn't just left as DEFAULT on all platforms.  The other platforms don't even create resolution images anyway so their default is to just use the existing image which is fine.  We should not have platform issues affecting the default values for hints.

>       The new logic uses the transform to get the destination image width and height.
>       There is the trick question about the general transform type because image sides are not equal after the transformation in this case. So we could use only one side,
>       or maximum value from opposite sides or may be an average value.

It looks like you are supplying the independent w,h and the default implementation of getResolutionVariant() is using "dispw <= imgw && disph <= imgh" which I think I asked Mike about and he said that was correct.  Is there another issue I'm missing?

>> The parameter passed to the getResVariant method is based on the subimage size, but the method treats it as if it were based on the full image size.  Either compute the scaled size of the full image, or inform the method of the sub-image being scaled, or simply pass in the scales, otherwise you will get the default image for any sub-image renderings of less than half of the original image even if they are rendered at retina scales.
>     This is my fault. I really missed this part.  It is updated in the fix.

I think this is done in a fairly reasonable first approximation.  It works for the only case we have currently which is @2x images where the incoming integers translate into outgoing integers, but we'll have to revisit these exact calculations if we ever want to support non-integer-scale resolution variants (I think Win8 might have a number of non-integer scales).

>      The algorithm that gets the scaled image size is based on the width and height of both images original and scaled. That means that both images should be already preloaded.
>      In other case we need to draw the original image (because it is not possible to know the destination image size)  and wait for more drawImage(Image ) calls to try to load the scaled image.

I don't like preloading them because we never preloaded the images previously and this will be a huge memory concern, not to mention the fact that we used to return nearly immediately from getImage() and now we have to load an entire (4x pixels) image to just return from that method.  This all needs to be done asynchronously.

Also, the code in getImageWithResolutionVariants() appears to wrap the image afresh every time it is called.  If you call it twice with a given string then the first time will make a regular image and store it there, then make a scaled image and replace it with the scaled image.  The second call will retrieve the scaled image left by the first call and then combine it with a second instance of the scaled image to make a new doubly-nested scaled image and store that in the hash.

>      It seems that multi-resolution image preloading fixes image drawing issue as well as issue with the image observers. An image observer is not called from the g.drawImage()
>      method in case if both images images are preloded and the original image does not have errors.

What about the other cases of errors?  What if they switch back and forth between the resolutions?  What image is reported in the callback for the non-scaled image?

What happens for MediaTracker?

>      The fix does not use url.openConnection() now. It tries to preload the @2x image and if it is successful it preloads the original image as well.

getImage() is not supposed to preload anything.  Also, I didn't see where it preloads the original image, just the resolution variant.

>     I also look at the custom cursor part of the HiDPI issues. A user needs to prepare the MultiResolutionImage and we can use CImage.createFromImages(List<Image> images)
>     method to create necessary NSImage. This means that it should be possible to obtain all resolution variants from the MultiResolutionImage.
>     I have included the "List<Image> getResolutionVariants()" method to the MultiResolutionImage for that.

I was going to ask about that new method.  Why does the developer need to manually intercede here?  They should be able to grab an image that has an @2x variant, use MediaTracker or some other mechanism to make sure it is loaded, then create the cursor and the code that creates the cursor should notice the resolution variations and deal with it on its own...

			...jim


From dmitry.x.ginzburg at oracle.com  Tue Nov 19 15:23:38 2013
From: dmitry.x.ginzburg at oracle.com (Dmitry Ginzburg)
Date: Tue, 19 Nov 2013 19:23:38 +0400
Subject: [OpenJDK 2D-Dev] <2D Dev> [8] Review Request: JDK-8025235
 [javadoc] fix some errors in 2D
In-Reply-To: <528395C3.6030607@oracle.com>
References: <52713614.1050408@oracle.com> <527CA369.6000806@oracle.com>
	<528395C3.6030607@oracle.com>
Message-ID: <528B827A.3000507@oracle.com>

Hi guys,

?ould you please approve this 4-th version of doclint errors cleanup 
change in 2d code: http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.03/ ?
The changes are against 2d team repository of jdk8.

The patch contains only simple markup fixes; no changes/fixes in 
documentation text; the specification itself wasn't changed.

Thanks,
-Dmitry

13.11.2013 19:07, Dmitry Ginzburg wrote:
> Hi Phil, Guys ,
>
>
> This one is stuck waiting for review for quite long time.
> Please review so we can push this change.
>
> Thanks,
> -Dmitry
>
> 08.11.2013 12:40, Dmitry Ginzburg wrote:
>> Colleagues,
>>
>> friendly reminder.
>> Back in early October I did all proposed changes; could you please
>> review this third version of doclint fix?
>>
>> Thanks,
>> -Dmitry
>>
>> 30.10.2013 20:38, Dmitry Ginzburg wrote:
>>> Hi guys
>>> I haven't got any review from you on this issue. Can you please review it?
>>> For some issue, my e-mail have changed todmitry.x.ginzburg at oracle.com
>>> Thanks, Dmitry
>>> *
>>> Dmitry Ginzburg*  dmitry.ginzburg at oracle.com    <mailto:2d-dev%40openjdk.java.net?Subject=%5BOpenJDK%202D-Dev%5D%20%3C2D%20Dev%3E%20%5B8%5D%20Review%20Request%3A%20JDK-8025235%0A%20%5Bjavadoc%5D%20fix%20some%20errors%20in%202D&In-Reply-To=524EE4DB.8010602%40oracle.com>
>>> /Tue Oct 15 06:02:58 PDT 2013/
>>>
>>> See new webrev:http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.02/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.02/>  
>>> <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.02/>
>>> Some changes are deleted, because they're fixed by someone but me
>>>
>>> 04.10.2013 19:55, Phil Race wrote:
>>> >/  Hi,
>>> />/
>>> />/  A few places you used {@code that is not code} : ie PageAttributes for
>>> />/  the &
>>> />/  and Line2D.Float() constructor and  in MultipleMaster are the ones I
>>> />/  spotted
>>> />/  probably aren't appropriate as they aren't code, and the {@code ..}
>>> />/  will use
>>> />/  a fixed width font. So one char will be in a different font.
>>> />/  As I suggested in PageAttributes just use "and", there's no reason it
>>> />/  has to
>>> />/  be an ampersand.
>>> />/
>>> />/  -phil.
>>> />/
>>> />/  On 10/4/2013 5:59 AM, Dmitry Ginzburg wrote:
>>> />>/  Hi, Phil
>>> />>/
>>> />>/  I renewed webrev against your issues:
>>> />>/  http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.01/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.01/>  
>>> />>/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.01/>
>>> />>/
>>> />>/  Thanks,
>>> />>/  -Dmitry
>>> />>/
>>> />>/  03.10.2013 08:41, Phil Race wrote:
>>> />>>/  1. This webrev is not against the 2D forest. Please re-generate
>>> />>>/  against 2D.
>>> />>>/
>>> />>>/  2.
>>> />>>/  /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/GraphicsConfiguration.java:84:
>>> />>>/  error: malformed HTML
>>> />>>/     When you have < & > chars in code the preferred solution uses
>>> />>>/  {@code .. }  like this :
>>> />>>/  http://cr.openjdk.java.net/~prr/8022175/src/share/classes/javax/print/ServiceUI.java.sdiff.html  <http://cr.openjdk.java.net/%7Eprr/8022175/src/share/classes/javax/print/ServiceUI.java.sdiff.html>  
>>> />>>/
>>> />>>/
>>> />>>/  3. Same as above for GraphicsDevice
>>> />>>/
>>> />>>/  4. Same as above for MediaTracker (it'll fix all 3 issues)
>>> />>>/
>>> />>>/  5. I think we should change all 12 or so of these to the word "and"
>>> />>>/
>>> />>>/  6. Rectangle : same as 2
>>> />>>/
>>> />>>/  7. LineBreakMeasurer : same again in all locations
>>> />>>/
>>> />>>/  8. {@code .. } should fix this too
>>> />>>/
>>> />>>/  9. LIne2D 626: {@code true} would be better here too
>>> />>>/
>>> />>>/  10. PrinterJob: {@code .. } again
>>> />>>/
>>> />>>/  Make sure you verify by re-running doclint on the fixed repo.
>>> />>>/
>>> />>>/  That's all.
>>> />>>/
>>> />>>/  -phil.
>>> />>>/
>>> />>>/  On 9/26/13 7:21 AM, Dmitry Ginzburg wrote:
>>> />>>>/  Hello, 2D Team.
>>> />>>>/
>>> />>>>/  Please review the fix for the following issue:
>>> />>>>/  https://bugs.openjdk.java.net/browse/JDK-8025235
>>> />>>>/  The fix is available at:
>>> />>>>/  http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.00/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.00/>
>>> />>>>/
>>> />>>>/  This is the fix for javadoc errors, on which doclint was showing
>>> />>>>/  some issues.
>>> />>>>/
>>> />>>>/  The patch contains only simple markup fixes; no changes/fixes in
>>> />>>>/  documentation text; the specification itself wasn't changed.
>>> />>>>/
>>> />>>>/  Thanks,
>>> />>>>/  -Dmitry
>>> />>>/
>>> />>/
>>> />>/
>>> />>/  --
>>> />>/  Dmitry Ginzburg, FXSQE team member
>>> />/
>>> /
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131119/e37d73ca/attachment.html>

From james.graham at oracle.com  Wed Nov 20 03:01:17 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 19 Nov 2013 19:01:17 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <528BFA66.7040307@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
	<5283D2F9.6010100@oracle.com> <528B625D.7060406@oracle.com>
	<528BFA66.7040307@oracle.com>
Message-ID: <528C25FD.3020707@oracle.com>

I did some more reading about the various ways in which the ImageObserver is used and noticed the following points, some of which may be to our advantage.

Many of the drawImage() calls mention that they will notify the observer as the image is "scaled or converted for the output device".  I believe in the world before 2D, we would often have to load or convert the image asynchronously for various changes in the output.  When we created the 2D interface and added some on-the-fly image scaling code, we mentioned that scaling was no longer asynchronous, but technically the API is still designed for asynchronous operations when the rendering parameters change.

However, the drawImage() call that takes 8 parameters dxy12, sxy12 - specifically includes the words:

      * This method always uses the unscaled version of the image
      * to render the scaled rectangle and performs the required
      * scaling on the fly. It does not use a cached, scaled version
      * of the image for this operation. Scaling of the image from source
      * to destination is performed such that the first coordinate
      * of the source rectangle is mapped to the first coordinate of
      * the destination rectangle, and the second source coordinate is
      * mapped to the second destination coordinate. The subimage is
      * scaled and flipped as needed to preserve those mappings.
     public abstract boolean drawImage(Image img,
                                       int dx1, int dy1, int dx2, int dy2,
                                       int sx1, int sy1, int sx2, int sy2,
                                       ImageObserver observer);

which basically, at the time it was created in 1.1, was an opt "out" of the asynchronous operations that might happen when you scaled an image with drawImage(xywh).  As worded, this would suggest that this method does not use the @2x version and always uses the default resolution version, but those words were not put there for this particular intent, they were put there to indicate that we weren't going to do an off-line scaling of the pixels which sometimes happened in 1.0.x and possibly 1.1 (for the other calls that predated 1.1 until Java2D).

I also found the Component.prepareImage() and Component.checkImage() methods which also take an ImageObserver.  Those methods imply that they will possibly start the process and return information on a particular version of an image appropriate for the current output device.  There is even a prepareImage(w,h) method that gets an image ready to render at the indicated size.  Given that these methods are on component, it probably makes sense to have that code look up which representation would be used for those indicated dimensions on the indicated output device that the Component is displayed on.

			...jim



From james.graham at oracle.com  Wed Nov 20 03:58:07 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 19 Nov 2013 19:58:07 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <528C25FD.3020707@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
	<5283D2F9.6010100@oracle.com> <528B625D.7060406@oracle.com>
	<528BFA66.7040307@oracle.com> <528C25FD.3020707@oracle.com>
Message-ID: <528C334F.4000608@oracle.com>

Based on the information below, I have the following suggestions...

We should probably allow asynchronous loading of the scaled resolution variants.  This is a minor variation of what the ImageObserver was originally designed for, but technically might violate some developer's expectations if they have only dealt with a post-Java2D version of Java.  Some education might be helpful here.

The wording on drawImage(dxy12, sxy12) should probably be reworded to indicate that asynchronous scaling would not happen, but alternate versions of the image may be accessed.

In all cases, if the version of the image that we would ideally want to show hasn't been loaded, but the standard version has (or if @2x was loaded, but we want the regular version too?) then we should probably go with the version that was loaded, but still trigger the loading of the alternate version and notify their Observer as it is loaded.

I also examined the places in the code where we notify the ImageObserver.  A search for the observer method should show all places we call it, but the primary ones look like they are fairly few places.  If we tag the resolution variant images with the composite image from which they came, then we can have those few places do something like:

Image obsimg = (img instanceof SunToolkitImage) ? (() img).getObservedImage() : img;

I think in most cases the img is already known to be our internal SunToolkit image and so we don't even need to check instanceof...

			...jim

On 11/19/2013 7:01 PM, Jim Graham wrote:
> I did some more reading about the various ways in which the ImageObserver is used and noticed the following points, some of which may be to our advantage.
>
> Many of the drawImage() calls mention that they will notify the observer as the image is "scaled or converted for the output device".  I believe in the world before 2D, we would often have to load or convert the image asynchronously for various changes in the output.  When we created the 2D interface and added some on-the-fly image scaling code, we mentioned that scaling was no longer asynchronous, but technically the API is still designed for asynchronous operations when the rendering parameters change.
>
> However, the drawImage() call that takes 8 parameters dxy12, sxy12 - specifically includes the words:
>
>       * This method always uses the unscaled version of the image
>       * to render the scaled rectangle and performs the required
>       * scaling on the fly. It does not use a cached, scaled version
>       * of the image for this operation. Scaling of the image from source
>       * to destination is performed such that the first coordinate
>       * of the source rectangle is mapped to the first coordinate of
>       * the destination rectangle, and the second source coordinate is
>       * mapped to the second destination coordinate. The subimage is
>       * scaled and flipped as needed to preserve those mappings.
>      public abstract boolean drawImage(Image img,
>                                        int dx1, int dy1, int dx2, int dy2,
>                                        int sx1, int sy1, int sx2, int sy2,
>                                        ImageObserver observer);
>
> which basically, at the time it was created in 1.1, was an opt "out" of the asynchronous operations that might happen when you scaled an image with drawImage(xywh).  As worded, this would suggest that this method does not use the @2x version and always uses the default resolution version, but those words were not put there for this particular intent, they were put there to indicate that we weren't going to do an off-line scaling of the pixels which sometimes happened in 1.0.x and possibly 1.1 (for the other calls that predated 1.1 until Java2D).
>
> I also found the Component.prepareImage() and Component.checkImage() methods which also take an ImageObserver.  Those methods imply that they will possibly start the process and return information on a particular version of an image appropriate for the current output device.  There is even a prepareImage(w,h) method that gets an image ready to render at the indicated size.  Given that these methods are on component, it probably makes sense to have that code look up which representation would be used for those indicated dimensions on the indicated output device that the Component is displayed on.
>
>              ...jim
>


From yuri.nesterenko at oracle.com  Wed Nov 20 06:53:04 2013
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Wed, 20 Nov 2013 10:53:04 +0400
Subject: [OpenJDK 2D-Dev] <2D Dev> [8] Review Request: JDK-8025235
 [javadoc] fix some errors in 2D
In-Reply-To: <528B827A.3000507@oracle.com>
References: <52713614.1050408@oracle.com> <527CA369.6000806@oracle.com>
	<528395C3.6030607@oracle.com> <528B827A.3000507@oracle.com>
Message-ID: <528C5C50.5070100@oracle.com>

Formally, I can approve this fix, I think, and I do,
taking (not so huge) responsibility for it.
Essentially, Phil has it approved and other properly 2d people have
the previous versions scanned. So, I'm pushing it.

Thanks,
-yan

On 11/19/2013 07:23 PM, Dmitry Ginzburg wrote:
> Hi guys,
>
> ?ould you please approve this 4-th version of doclint errors cleanup
> change in 2d code: http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.03/ ?
> The changes are against 2d team repository of jdk8.
>
> The patch contains only simple markup fixes; no changes/fixes in
> documentation text; the specification itself wasn't changed.
>
> Thanks,
> -Dmitry
>
> 13.11.2013 19:07, Dmitry Ginzburg wrote:
>> Hi Phil, Guys ,
>>
>>
>> This one is stuck waiting for review for quite long time.
>> Please review so we can push this change.
>>
>> Thanks,
>> -Dmitry
>>
>> 08.11.2013 12:40, Dmitry Ginzburg wrote:
>>> Colleagues,
>>>
>>> friendly reminder.
>>> Back in early October I did all proposed changes; could you please
>>> review this third version of doclint fix?
>>>
>>> Thanks,
>>> -Dmitry
>>>
>>> 30.10.2013 20:38, Dmitry Ginzburg wrote:
>>>> Hi guys
>>>> I haven't got any review from you on this issue. Can you please review it?
>>>> For some issue, my e-mail have changed todmitry.x.ginzburg at oracle.com
>>>> Thanks, Dmitry
>>>> *
>>>> Dmitry Ginzburg*  dmitry.ginzburg at oracle.com    <mailto:2d-dev%40openjdk.java.net?Subject=%5BOpenJDK%202D-Dev%5D%20%3C2D%20Dev%3E%20%5B8%5D%20Review%20Request%3A%20JDK-8025235%0A%20%5Bjavadoc%5D%20fix%20some%20errors%20in%202D&In-Reply-To=524EE4DB.8010602%40oracle.com>
>>>> /Tue Oct 15 06:02:58 PDT 2013/
>>>>
>>>> See new webrev:http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.02/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.02/>
>>>> <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.02/>
>>>> Some changes are deleted, because they're fixed by someone but me
>>>>
>>>> 04.10.2013 19:55, Phil Race wrote:
>>>> >/  Hi,
>>>> />/
>>>> />/  A few places you used {@code that is not code} : ie PageAttributes for
>>>> />/  the &
>>>> />/  and Line2D.Float() constructor and  in MultipleMaster are the ones I
>>>> />/  spotted
>>>> />/  probably aren't appropriate as they aren't code, and the {@code ..}
>>>> />/  will use
>>>> />/  a fixed width font. So one char will be in a different font.
>>>> />/  As I suggested in PageAttributes just use "and", there's no reason it
>>>> />/  has to
>>>> />/  be an ampersand.
>>>> />/
>>>> />/  -phil.
>>>> />/
>>>> />/  On 10/4/2013 5:59 AM, Dmitry Ginzburg wrote:
>>>> />>/  Hi, Phil
>>>> />>/
>>>> />>/  I renewed webrev against your issues:
>>>> />>/  http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.01/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.01/>
>>>> />>/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.01/>
>>>> />>/
>>>> />>/  Thanks,
>>>> />>/  -Dmitry
>>>> />>/
>>>> />>/  03.10.2013 08:41, Phil Race wrote:
>>>> />>>/  1. This webrev is not against the 2D forest. Please re-generate
>>>> />>>/  against 2D.
>>>> />>>/
>>>> />>>/  2.
>>>> />>>/  /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/GraphicsConfiguration.java:84:
>>>> />>>/  error: malformed HTML
>>>> />>>/     When you have < & > chars in code the preferred solution uses
>>>> />>>/  {@code .. }  like this :
>>>> />>>/  http://cr.openjdk.java.net/~prr/8022175/src/share/classes/javax/print/ServiceUI.java.sdiff.html  <http://cr.openjdk.java.net/%7Eprr/8022175/src/share/classes/javax/print/ServiceUI.java.sdiff.html>
>>>> />>>/
>>>> />>>/
>>>> />>>/  3. Same as above for GraphicsDevice
>>>> />>>/
>>>> />>>/  4. Same as above for MediaTracker (it'll fix all 3 issues)
>>>> />>>/
>>>> />>>/  5. I think we should change all 12 or so of these to the word "and"
>>>> />>>/
>>>> />>>/  6. Rectangle : same as 2
>>>> />>>/
>>>> />>>/  7. LineBreakMeasurer : same again in all locations
>>>> />>>/
>>>> />>>/  8. {@code .. } should fix this too
>>>> />>>/
>>>> />>>/  9. LIne2D 626: {@code true} would be better here too
>>>> />>>/
>>>> />>>/  10. PrinterJob: {@code .. } again
>>>> />>>/
>>>> />>>/  Make sure you verify by re-running doclint on the fixed repo.
>>>> />>>/
>>>> />>>/  That's all.
>>>> />>>/
>>>> />>>/  -phil.
>>>> />>>/
>>>> />>>/  On 9/26/13 7:21 AM, Dmitry Ginzburg wrote:
>>>> />>>>/  Hello, 2D Team.
>>>> />>>>/
>>>> />>>>/  Please review the fix for the following issue:
>>>> />>>>/  https://bugs.openjdk.java.net/browse/JDK-8025235
>>>> />>>>/  The fix is available at:
>>>> />>>>/  http://cr.openjdk.java.net/~yan/jdk-8025235/webrev.00/  <http://cr.openjdk.java.net/%7Eyan/jdk-8025235/webrev.00/>
>>>> />>>>/
>>>> />>>>/  This is the fix for javadoc errors, on which doclint was showing
>>>> />>>>/  some issues.
>>>> />>>>/
>>>> />>>>/  The patch contains only simple markup fixes; no changes/fixes in
>>>> />>>>/  documentation text; the specification itself wasn't changed.
>>>> />>>>/
>>>> />>>>/  Thanks,
>>>> />>>>/  -Dmitry
>>>> />>>/
>>>> />>/
>>>> />>/
>>>> />>/  --
>>>> />>/  Dmitry Ginzburg, FXSQE team member
>>>> />/
>>>> /
>>>
>>
>



From yuri.nesterenko at oracle.com  Wed Nov 20 08:26:12 2013
From: yuri.nesterenko at oracle.com (yuri.nesterenko at oracle.com)
Date: Wed, 20 Nov 2013 08:26:12 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 8025235: [javadoc] fix some
	errors in 2D
Message-ID: <20131120082645.79404626E6@hg.openjdk.java.net>

Changeset: 4592f0985e78
Author:    yan
Date:      2013-11-20 12:23 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4592f0985e78

8025235: [javadoc] fix some errors in 2D
Reviewed-by: prr, yan
Contributed-by: Dmitry Ginzburg <dmitry.x.ginzburg at oracle.com>

! src/share/classes/java/awt/Font.java
! src/share/classes/java/awt/Graphics2D.java
! src/share/classes/java/awt/GraphicsConfiguration.java
! src/share/classes/java/awt/GraphicsDevice.java
! src/share/classes/java/awt/Image.java
! src/share/classes/java/awt/MediaTracker.java
! src/share/classes/java/awt/PageAttributes.java
! src/share/classes/java/awt/Rectangle.java
! src/share/classes/java/awt/RenderingHints.java
! src/share/classes/java/awt/font/NumericShaper.java
! src/share/classes/java/awt/font/TextAttribute.java
! src/share/classes/java/awt/geom/FlatteningPathIterator.java
! src/share/classes/java/awt/geom/Path2D.java
! src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java
! src/share/classes/java/awt/print/Book.java
! src/share/classes/java/awt/print/PageFormat.java
! src/share/classes/java/awt/print/Printable.java
! src/share/classes/java/awt/print/PrinterJob.java



From sergey.lugovoy at oracle.com  Wed Nov 20 09:47:27 2013
From: sergey.lugovoy at oracle.com (Sergey Lugovoy)
Date: Wed, 20 Nov 2013 13:47:27 +0400
Subject: [OpenJDK 2D-Dev] [2d dev] [8] Review request for JDK-8028272 : Tidy
	warnings cleanup for javax.print package
Message-ID: <2926438.yTqgPxlqRx@workland>

Hi all,
please review the fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8028272
webrev : http://cr.openjdk.java.net/~yan/8028272/webrev.00/

This patch cleanup tidy warnings for generated html documentation for 
javax.print package, and do not affect the appearance of the documentation.
The patch is created against jdk8/tl team repository according to requirements
of this cleanup project.


Best regards,
Serge V. Lugovoy


From james.graham at oracle.com  Wed Nov 20 11:17:59 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 20 Nov 2013 03:17:59 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <528C334F.4000608@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
	<5283D2F9.6010100@oracle.com> <528B625D.7060406@oracle.com>
	<528BFA66.7040307@oracle.com> <528C25FD.3020707@oracle.com>
	<528C334F.4000608@oracle.com>
Message-ID: <528C9A67.3000109@oracle.com>

In looking through the ToolkitImage code some more it occurs to me that it was already designed (moreso in a previous life) to hold onto multiple representations of the image anyway.  In a prior life in 1.0 and 1.1 it held separate ImageRepresentation objects for each size it was scaled to (via drawImage(w,h)), but that was simplified to a single ImageRep when we converted to Java2D and started doing scaling on the fly for all drawImage() operations.  Still, the concept of an alternate resolution version of the image is probably more in line with the ImageRepresentation object within the ToolkitImage than in having multiple ToolkitImage objects and a wrapper for them.

This would also deal more naturally with the ImageObserver issue since there really would be only one Image and SG2D would not deal with the sub-representations, it would be dealt with in the DrawImage pipeline code when it queries the ToolkitImage for the ImageRepresentation object.

In the end, I think that design would be simpler overall, would it be possible to shift those gears for this fix?  If not, we should consider it for a near-term future cleanup task perhaps...

			...jim

On 11/19/2013 7:58 PM, Jim Graham wrote:
> Based on the information below, I have the following suggestions...
>
> We should probably allow asynchronous loading of the scaled resolution variants.  This is a minor variation of what the ImageObserver was originally designed for, but technically might violate some developer's expectations if they have only dealt with a post-Java2D version of Java.  Some education might be helpful here.
>
> The wording on drawImage(dxy12, sxy12) should probably be reworded to indicate that asynchronous scaling would not happen, but alternate versions of the image may be accessed.
>
> In all cases, if the version of the image that we would ideally want to show hasn't been loaded, but the standard version has (or if @2x was loaded, but we want the regular version too?) then we should probably go with the version that was loaded, but still trigger the loading of the alternate version and notify their Observer as it is loaded.
>
> I also examined the places in the code where we notify the ImageObserver.  A search for the observer method should show all places we call it, but the primary ones look like they are fairly few places.  If we tag the resolution variant images with the composite image from which they came, then we can have those few places do something like:
>
> Image obsimg = (img instanceof SunToolkitImage) ? (() img).getObservedImage() : img;
>
> I think in most cases the img is already known to be our internal SunToolkit image and so we don't even need to check instanceof...
>
>              ...jim
>
> On 11/19/2013 7:01 PM, Jim Graham wrote:
>> I did some more reading about the various ways in which the ImageObserver is used and noticed the following points, some of which may be to our advantage.
>>
>> Many of the drawImage() calls mention that they will notify the observer as the image is "scaled or converted for the output device".  I believe in the world before 2D, we would often have to load or convert the image asynchronously for various changes in the output.  When we created the 2D interface and added some on-the-fly image scaling code, we mentioned that scaling was no longer asynchronous, but technically the API is still designed for asynchronous operations when the rendering parameters change.
>>
>> However, the drawImage() call that takes 8 parameters dxy12, sxy12 - specifically includes the words:
>>
>>       * This method always uses the unscaled version of the image
>>       * to render the scaled rectangle and performs the required
>>       * scaling on the fly. It does not use a cached, scaled version
>>       * of the image for this operation. Scaling of the image from source
>>       * to destination is performed such that the first coordinate
>>       * of the source rectangle is mapped to the first coordinate of
>>       * the destination rectangle, and the second source coordinate is
>>       * mapped to the second destination coordinate. The subimage is
>>       * scaled and flipped as needed to preserve those mappings.
>>      public abstract boolean drawImage(Image img,
>>                                        int dx1, int dy1, int dx2, int dy2,
>>                                        int sx1, int sy1, int sx2, int sy2,
>>                                        ImageObserver observer);
>>
>> which basically, at the time it was created in 1.1, was an opt "out" of the asynchronous operations that might happen when you scaled an image with drawImage(xywh).  As worded, this would suggest that this method does not use the @2x version and always uses the default resolution version, but those words were not put there for this particular intent, they were put there to indicate that we weren't going to do an off-line scaling of the pixels which sometimes happened in 1.0.x and possibly 1.1 (for the other calls that predated 1.1 until Java2D).
>>
>> I also found the Component.prepareImage() and Component.checkImage() methods which also take an ImageObserver.  Those methods imply that they will possibly start the process and return information on a particular version of an image appropriate for the current output device.  There is even a prepareImage(w,h) method that gets an image ready to render at the indicated size.  Given that these methods are on component, it probably makes sense to have that code look up which representation would be used for those indicated dimensions on the indicated output device that the Component is displayed on.
>>
>>              ...jim
>>


From linuxhippy at gmail.com  Wed Nov 20 15:38:58 2013
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 20 Nov 2013 10:38:58 -0500
Subject: [OpenJDK 2D-Dev] request for review: JDK-8028722: XRender: Drawing
 strings with exactly 254 glyphs causes hangs
Message-ID: <CAFvQSYRQNBHYRjkz2sw_XAc0PdFgPDnd=N6hfVxbokGi9hzs1w@mail.gmail.com>

Hi,

Please review my fix for JDK-8028722: "XRender: Drawing strings with
exactly 254 glyphs causes hangs" available at
http://cr.openjdk.java.net/~ceisserer/8028722/webrev.00/
A test is available at:
http://cr.openjdk.java.net/~ceisserer/8028722/XRenderElt254TextTest.java

Problem description:
When drawing strings with a length that is a multiple of 254
characters, the xrender pipeline hangs.
This is caused by a bug in libXrender/XRenderCompositeText32 which
calculates a wrong request length in this case and passes garbage
bytes to the xserver.

Fix description:
As a workarround, this fix forces a new elt to be used after 253
characters, doing the split exactly two characters before libXrender
would do it internally anyway.
A patch for libXrender is awaiting review currently.

Thank you in advance, Clemens


From volker.simonis at gmail.com  Wed Nov 20 18:26:35 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 20 Nov 2013 19:26:35 +0100
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
Message-ID: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>

Hi,

this is the second review round for "8024854: Basic changes and files to
build the class library on
AIX<https://bugs.openjdk.java.net/browse/JDK-8024854>".
The previous reviews can be found at the end of this mail in the references
section.

I've tried to address all the comments and suggestions from the first round
and to further streamline the patch (it perfectly builds on Linux/x86_64,
Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The biggest change
compared to the first review round is the new "aix/" subdirectory which
I've now created under "jdk/src" and which contains AIX-only code.

The webrev is against our
http://hg.openjdk.java.net/ppc-aix-port/stagerepository which has been
recently synchronised with the jdk8 master:

http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/

Below (and in the webrev) you can find some comments which explain the
changes to each file. In order to be able to push this big change, I need
the approval of reviewers from the lib, net, svc, 2d, awt and sec groups.
So please don't hesitate to jump at it - there are enough changes for
everybody:)

Thank you and best regards,
Volker

*References:*

The following reviews have been posted so far (thanks Iris for collecting
them :)

- Alan Bateman (lib): Initial comments (16 Sep [2])
- Chris Hegarty (lib/net): Initial comments (20 Sep [3])
- Michael McMahon (net): Initial comments (20 Sept [4])
- Steffan Larsen (svc): APPROVED (20 Sept [5])
- Phil Race (2d): Initial comments  (18 Sept [6]); Additional comments (15
Oct [7])
- Sean Mullan (sec): Initial comments (26 Sept [8])

[2]:
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html
[3]:
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html
[4]:
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html
[5]:
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html
[6]:
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html
[7]: http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html
[8]:
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html


*Detailed change description:*

The new "jdk/src/aix" subdirectory contains the following new and
AIX-specific files for now:

 src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
 src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java
 src/aix/classes/sun/nio/ch/AixPollPort.java
 src/aix/classes/sun/nio/fs/AixFileStore.java
 src/aix/classes/sun/nio/fs/AixFileSystem.java
 src/aix/classes/sun/nio/fs/AixFileSystemProvider.java
 src/aix/classes/sun/nio/fs/AixNativeDispatcher.java
 src/aix/classes/sun/tools/attach/AixAttachProvider.java
 src/aix/classes/sun/tools/attach/AixVirtualMachine.java
 src/aix/native/java/net/aix_close.c
 src/aix/native/sun/nio/ch/AixPollPort.c
 src/aix/native/sun/nio/fs/AixNativeDispatcher.c
 src/aix/native/sun/tools/attach/AixVirtualMachine.c
 src/aix/porting/porting_aix.c
 src/aix/porting/porting_aix.h

src/aix/porting/porting_aix.c
src/aix/porting/porting_aix.h

   - Added these two files for AIX relevant utility code.
   - Currently these files only contain an implementation of dladdr which
   is not available on AIX.
   - In the first review round the existing dladdr users in the code either
   called the version from the HotSpot on AIX (
   src/solaris/native/sun/awt/awt_LoadLibrary.c) or had a private copy of
   the whole implementation (src/solaris/demo/jvmti/hprof/hprof_md.c). This
   is now not necessary any more.

 The new file layout required some small changes to the makefiles to make
them aware of the new directory locations:

makefiles/CompileDemos.gmk

   - Add an extra argument to SetupJVMTIDemo which can be used to pass
   additional source locations.
   - Currently this is only used on AIX for the AIX porting utilities which
   are required by hprof.

makefiles/lib/Awt2dLibraries.gmk
makefiles/lib/ServiceabilityLibraries.gmk

   - On AIX add the sources of the AIX porting utilities to the build. They
   are required by src/solaris/native/sun/awt/awt_LoadLibrary.c and
   src/solaris/demo/jvmti/hprof/hprof_md.c because dladdr is not available
   on AIX.

makefiles/lib/NioLibraries.gmk

   - Make the AIX-build aware of the new NIO source locations under
   src/aix/native/sun/nio/.

makefiles/lib/NetworkingLibraries.gmk

   - Make the AIX-build aware of the new aix_close.c source location under
   src/aix/native/java/net/.

src/share/bin/jli_util.h

   - Define JLI_Lseek on AIX.

src/share/lib/security/java.security-aix

   - Provide default java.security-aix for AIX based on the latest Linux
   version as suggested by Sean Mullan.

src/share/native/common/check_code.c

   - On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is
   legal, but the code in check_code.c does not handles this properly. So
   we wrap the two methods on AIX and return a non-NULL pointer even if we
   allocate 0 bytes.

src/share/native/sun/awt/medialib/mlib_sys.c

   - malloc always returns 8-byte aligned pointers on AIX as well.

src/share/native/sun/awt/medialib/mlib_types.h

   - Add AIX to the list of known platforms.

src/share/native/sun/font/layout/KernTable.cpp

   - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too common
   and may be defined in other headers as well as on the command line and
   xlc bails out on macro redefinitions with a different value.

src/share/native/sun/security/ec/impl/ecc_impl.h

   - Define required types and macros on AIX.

src/solaris/back/exec_md.c

   - AIX behaves like Linux in this case so check for it in the Linux
   branch.

src/solaris/bin/java_md_solinux.c,
src/solaris/bin/java_md_solinux.h

   - On AIX LD_LIBRARY_PATH is called LIBPATH
   - Always use LD_LIBRARY_PATH macro instead of using the string "
   LD_LIBRARY_PATH" directly to cope with different library path names.
   - Add jre/lib/<arch>/jli to the standard library search path on AIX
   because the AIX linker doesn't support the -rpath option.
   - Replace #ifdef __linux__ by #ifndef __solaris__ because in this case,
   AIX behaves like Linux.
   - Removed the definition of JVM_DLL, JAVA_DLL and LD_LIBRARY_PATH from
   java_md_solinux.h because the macros are redefined in the corresponding
   .c files anyway.

src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties

   - Provide basic fontconfig.propertiesfor AIX.

src/solaris/classes/java/lang/UNIXProcess.java.aix,
src/aix/classes/sun/tools/attach/AixAttachProvider.java,
src/aix/classes/sun/tools/attach/AixVirtualMachine.java,
src/aix/native/sun/tools/attach/AixVirtualMachine.c

   - Provide AIX specific Java versions, mostly based on the corresponding
   Linux versions.

src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java
src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java

   - Detect AIX operating system and return the corresponding channel and
   file system providers.

src/solaris/classes/sun/nio/ch/Port.java

   - Add a callback function unregisterImpl(int fd) for implementations
   that need special handling when fd is removed and call it from
unregister(int
   fd). By default the implementation of unregisterImpl(int fd) is empty
   except for the derived AixPollPort class on AIX.

src/solaris/demo/jvmti/hprof/hprof_md.c

   - Add AIX support. AIX mostly behaves like Linux, with the one exception
   that it has no dladdr functionality.
   - Use the dladdr implementation from porting_aix.{c,h} on AIX.

src/solaris/native/com/sun/management/UnixOperatingSystem_md.c

   - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory).

src/solaris/native/common/jdk_util_md.h

   - Add AIX definitions of the ISNANF and ISNAND macros.

src/solaris/native/java/io/io_util_md.c

   - AIX behaves like Linux in this case so check for it in the Linux
   branch.

src/solaris/native/java/lang/UNIXProcess_md.c

   - AIX behaves mostly like Solraris in this case so adjust the ifdefs
   accordingly.

src/solaris/native/java/lang/childproc.c

   - AIX does not understand '/proc/self' - it requires the real process ID
   to query the proc file system for the current process.

src/solaris/native/java/net/NetworkInterface.c

   - Add AIX support into the Linux branch because AIX mostly behaves like
   AIX for IPv4.
   - AIX needs a special function to enumerate IPv6 interfaces and to query
   the MAC address.
   - Moved the declaration of siocgifconfRequest to the beginning a the
   function (as recommend by Michael McMahon) to remain C89 compatible.

src/solaris/native/java/net/PlainSocketImpl.c

   - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the
   socket is closed. The default error message is then confusing.

src/aix/native/java/net/aix_close.c,
src/share/native/java/net/net_util.c

   - As recommended by Michael McMahon and Alan Bateman I've move an
   adapted version of linux_close.c to
src/aix/native/java/net/aix_close.cbecause we also need the file and
socket wrappers on AIX.
   - Compared to the Linux version, we've added the initialization of some
   previously uninitialized data structures.
   - Also, on AIX we don't have __attribute((constructor)) so we need to
   initialize manually (from JNI_OnLoad() in
   src/share/native/java/net/net_util.c.

src/solaris/native/java/net/net_util_md.h

   - AIX needs the same workaround for I/O cancellation like Linux and
   MacOSX.

src/solaris/native/java/net/net_util_md.c

   - SO_REUSEADDR is called SO_REUSEPORT on AIX.
   - On AIX we have to ignore failures due to ENOBUFS when setting the
   SO_SNDBUF/SO_RCVBUF socket options.

src/solaris/native/java/util/TimeZone_md.c

   - Currently on AIX the only way to get the platform time zone is to read
   it from the TZ environment variable.

src/solaris/native/sun/awt/awt_LoadLibrary.c

   - Use the dladdr from porting_aix.{c,h} on AIX.

src/solaris/native/sun/awt/fontpath.c

   - Changed some macros from if !defined(__linux__) to if
   defined(__solaris__) because that's their real meaning.
   - Add AIX specific fontpath settings and library search paths for
   libfontconfig.so.

src/solaris/native/sun/java2d/x11/X11SurfaceData.c

   - Rename the MIN and MAX macros to XSD_MIN and XSD_MAX to avoid name
   clashes (MIN and MAX are much too common and thexy are already defined
   in some AIX system headers).

src/solaris/native/sun/java2d/x11/XRBackendNative.c

   - Handle AIX like Solaris.

src/solaris/native/sun/nio/ch/Net.c

   - Add AIX-specific includes and constant definitions.
   - On AIX "socket extensions for multicast source filters" support
   depends on the OS version. Check for this and throw appropriate exceptions
   if it is requested but not supported. This is needed to pass
   JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast

src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c

   - On AIX strerror() is not thread-safe so we have to use strerror_r()instead.
   - On AIX readdir_r() returns EBADF (i.e. '9') and sets 'result' to NULL
   for the directory stream end. Otherwise, 'errno' will contain the error
   code.
   - Handle some AIX corner cases for the results of the statvfs64() call.
   - On AIX getgrgid_r() returns ESRCH if group does not exist.

src/solaris/native/sun/security/pkcs11/j2secmod_md.c

   - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX.

test/java/lang/ProcessBuilder/Basic.java
test/java/lang/ProcessBuilder/DestroyTest.java

   - Port this test to AIX and make it more robust (i.e. recognize the "C"
   locale as isEnglish(), ignore VM-warnings in the output, make sure the
   "grandchild" processes created by the test don't run too long (60s vs.
   6666s) because in the case of test problems these processes will pollute
   the process space, make sure the test fails with an error and doesn't hang
   indefinitley in the case of a problem).

 *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this
intended?

Well, _AIX is defined in some system headers while AIX is defined by the
build system. This is already used inconsistently (i.e. __linux__ vs. LINUX)
and in general I try to be consistent with the style of the file where I
the changes are. That said, I changes most of the occurences of AIX to _AIX.


*Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are
they supposed to be there?

We currently don't support OS/400 (later renamed into i5/OS and currently
called IBM i) in our OpenJDK port but we do support it in our internel, SAP
JVM build. We stripped out all the extra OS/400 functionality from the port
but in some places where there is common functionality needd by both, AIX
and OS/400 the OS/400 support may still be visible in the OpenJDK port. I
don't think this is a real problem and it helps us to keep our internel
sources in sync with the OpenJDK port. That said, I think I've removed all
the references to OS/400 now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131120/95330cdb/attachment.html>

From joe.darcy at oracle.com  Thu Nov 21 00:46:59 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 20 Nov 2013 16:46:59 -0800
Subject: [OpenJDK 2D-Dev] [2d dev] [8] Review request for JDK-8028272 :
 Tidy warnings cleanup for javax.print package
In-Reply-To: <2926438.yTqgPxlqRx@workland>
References: <2926438.yTqgPxlqRx@workland>
Message-ID: <528D5803.3070906@oracle.com>

Hello,

I'm not an HTML expert, but it seems preferable to me to just remove an 
unnecessary "<p>" tag rather than replacing it with "<br/>".

Is there a reason to prefer "<br/>"?

Otherwise the changes look fine.

Thanks,

-Joe

On 11/20/2013 1:47 AM, Sergey Lugovoy wrote:
> Hi all,
> please review the fix.
> bug: https://bugs.openjdk.java.net/browse/JDK-8028272
> webrev : http://cr.openjdk.java.net/~yan/8028272/webrev.00/
>
> This patch cleanup tidy warnings for generated html documentation for
> javax.print package, and do not affect the appearance of the documentation.
> The patch is created against jdk8/tl team repository according to requirements
> of this cleanup project.
>
>
> Best regards,
> Serge V. Lugovoy



From Sergey.Bylokhov at oracle.com  Thu Nov 21 02:13:24 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 Nov 2013 06:13:24 +0400
Subject: [OpenJDK 2D-Dev] [2d dev] [8] Review request for JDK-8028272 :
 Tidy warnings cleanup for javax.print package
In-Reply-To: <2926438.yTqgPxlqRx@workland>
References: <2926438.yTqgPxlqRx@workland>
Message-ID: <528D6C44.9000508@oracle.com>

Hi, Sergey.
Looks like in some cases, it is possible to replace "<p>" to the "</p>" 
and close previous "<p>" tag.

And I had a question to a 2D team. Is duplication in the header of [1] 
intended?

[1] 
http://download.java.net/jdk8/docs/api/javax/print/attribute/standard/Sides.html
Like:
SINGLE_DOCUMENT -- All the input docs will be combined together into one 
output document. Each media sheet will consist of /n/ impressions from 
the output document.
........
SINGLE_DOCUMENT -- All the input docs will be combined together into one 
output document. Each media sheet will consist of /n_i / impressions 
from the output document, where /i/ is the number of the input doc 
corresponding to that point in the output document. When the next input 
doc has a different sides value from the previous input doc, the first 
print-stream page of the next input doc goes at the start of the next 
media sheet, possibly leaving only one impression on the previous media 
sheet.

etc.

On 20.11.2013 13:47, Sergey Lugovoy wrote:
> Hi all,
> please review the fix.
> bug: https://bugs.openjdk.java.net/browse/JDK-8028272
> webrev : http://cr.openjdk.java.net/~yan/8028272/webrev.00/
>
> This patch cleanup tidy warnings for generated html documentation for
> javax.print package, and do not affect the appearance of the documentation.
> The patch is created against jdk8/tl team repository according to requirements
> of this cleanup project.
>
>
> Best regards,
> Serge V. Lugovoy


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131121/76e9c3e3/attachment.html>

From philip.race at oracle.com  Thu Nov 21 04:43:30 2013
From: philip.race at oracle.com (Phil Race)
Date: Wed, 20 Nov 2013 20:43:30 -0800
Subject: [OpenJDK 2D-Dev] request for review: JDK-8028722: XRender:
 Drawing strings with exactly 254 glyphs causes hangs
In-Reply-To: <CAFvQSYRQNBHYRjkz2sw_XAc0PdFgPDnd=N6hfVxbokGi9hzs1w@mail.gmail.com>
References: <CAFvQSYRQNBHYRjkz2sw_XAc0PdFgPDnd=N6hfVxbokGi9hzs1w@mail.gmail.com>
Message-ID: <528D8F72.9060603@oracle.com>

Hi,

Looks good and is a simple work around.

Not that it impacts us now but I think the tricky question is can we 
ever remove the workaround?
ie how will we ever know when we are using a fixed xrender lib.
I'd like to see core Xrender add a "GetVersion()" API  so we can figure 
this stuff out at runtime.

-phil.

On 11/20/13 7:38 AM, Clemens Eisserer wrote:
> Hi,
>
> Please review my fix for JDK-8028722: "XRender: Drawing strings with
> exactly 254 glyphs causes hangs" available at
> http://cr.openjdk.java.net/~ceisserer/8028722/webrev.00/
> A test is available at:
> http://cr.openjdk.java.net/~ceisserer/8028722/XRenderElt254TextTest.java
>
> Problem description:
> When drawing strings with a length that is a multiple of 254
> characters, the xrender pipeline hangs.
> This is caused by a bug in libXrender/XRenderCompositeText32 which
> calculates a wrong request length in this case and passes garbage
> bytes to the xserver.
>
> Fix description:
> As a workarround, this fix forces a new elt to be used after 253
> characters, doing the split exactly two characters before libXrender
> would do it internally anyway.
> A patch for libXrender is awaiting review currently.
>
> Thank you in advance, Clemens



From yuri.nesterenko at oracle.com  Thu Nov 21 07:30:08 2013
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 21 Nov 2013 11:30:08 +0400
Subject: [OpenJDK 2D-Dev] [2d dev] [8] Review request for JDK-8028272 :
 Tidy warnings cleanup for javax.print package
In-Reply-To: <528D5803.3070906@oracle.com>
References: <2926438.yTqgPxlqRx@workland> <528D5803.3070906@oracle.com>
Message-ID: <528DB680.8020801@oracle.com>

Hi Joe,

there seems to be several reasons:

-- in some cases this <p> just adds an extra line between items in
successive <ul> construction. Remove the <p>, and these <li>s will
stay as close to each other as regular lines in the document.
Which means too close, or did mean for original author of the doc.
See for instance
build/$CONF/docs/api/javax/print/Doc.html, <ul> started with
" Determine the format, or "doc flavor" " line.
In this case <br> does keep visual formatting almost intact, and
at the same time doesn't introduce block element in <li>.

-- again, in cases like
build/$CONF/docs/api/javax/print/package-summary.html
(which is made of src/share/classes/javax/print/attribute/package.html)
at the very end, this <p> adds an extra line, in this case
before <b>Since:</b>. Here, <br> retains visual formatting and keeps
watchdogs like doclint and tidy happy.

Sergey B. in a separate message suggests to close <p> by </p>:
that should work, too, at least in some cases.
For me, however, it seems not better and not worse than <br>
(read, more review work for all of us for nothing:-).

Thanks,
-yan

On 11/21/2013 04:46 AM, Joe Darcy wrote:
> Hello,
>
> I'm not an HTML expert, but it seems preferable to me to just remove an
> unnecessary "<p>" tag rather than replacing it with "<br/>".
>
> Is there a reason to prefer "<br/>"?
>
> Otherwise the changes look fine.
>
> Thanks,
>
> -Joe
>
> On 11/20/2013 1:47 AM, Sergey Lugovoy wrote:
>> Hi all,
>> please review the fix.
>> bug: https://bugs.openjdk.java.net/browse/JDK-8028272
>> webrev : http://cr.openjdk.java.net/~yan/8028272/webrev.00/
>>
>> This patch cleanup tidy warnings for generated html documentation for
>> javax.print package, and do not affect the appearance of the
>> documentation.
>> The patch is created against jdk8/tl team repository according to
>> requirements
>> of this cleanup project.
>>
>>
>> Best regards,
>> Serge V. Lugovoy
>



From andrew.brygin at oracle.com  Thu Nov 21 07:50:50 2013
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Thu, 21 Nov 2013 11:50:50 +0400
Subject: [OpenJDK 2D-Dev] request for review: JDK-8028722: XRender:
 Drawing strings with exactly 254 glyphs causes hangs
In-Reply-To: <CAFvQSYRQNBHYRjkz2sw_XAc0PdFgPDnd=N6hfVxbokGi9hzs1w@mail.gmail.com>
References: <CAFvQSYRQNBHYRjkz2sw_XAc0PdFgPDnd=N6hfVxbokGi9hzs1w@mail.gmail.com>
Message-ID: <528DBB5A.2060800@oracle.com>

Hello Clemens,

  the fix looks fine to me.

Thanks,
Andrew

On 11/20/2013 7:38 PM, Clemens Eisserer wrote:
> Hi,
>
> Please review my fix for JDK-8028722: "XRender: Drawing strings with
> exactly 254 glyphs causes hangs" available at
> http://cr.openjdk.java.net/~ceisserer/8028722/webrev.00/
> A test is available at:
> http://cr.openjdk.java.net/~ceisserer/8028722/XRenderElt254TextTest.java
>
> Problem description:
> When drawing strings with a length that is a multiple of 254
> characters, the xrender pipeline hangs.
> This is caused by a bug in libXrender/XRenderCompositeText32 which
> calculates a wrong request length in this case and passes garbage
> bytes to the xserver.
>
> Fix description:
> As a workarround, this fix forces a new elt to be used after 253
> characters, doing the split exactly two characters before libXrender
> would do it internally anyway.
> A patch for libXrender is awaiting review currently.
>
> Thank you in advance, Clemens



From Alan.Bateman at oracle.com  Thu Nov 21 12:01:31 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 21 Nov 2013 12:01:31 +0000
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
Message-ID: <528DF61B.6060403@oracle.com>

On 20/11/2013 18:26, Volker Simonis wrote:
> Hi,
>
> this is the second review round for "8024854: Basic changes and files 
> to build the class library on AIX 
> <https://bugs.openjdk.java.net/browse/JDK-8024854>". The previous 
> reviews can be found at the end of this mail in the references section.
>
> I've tried to address all the comments and suggestions from the first 
> round and to further streamline the patch (it perfectly builds on 
> Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). 
> The biggest change compared to the first review round is the new 
> "aix/" subdirectory which I've now created under "jdk/src" and which 
> contains AIX-only code.
Thanks for the update and addressing all the original comments and 
suggestions. In particular, moving most of the AIX specific files to 
src/aix and including an implementation of dladdr, make a big difference 
and makes this much easier to review.

I've skimmed through all the non-client files in the webrev and just 
have a few comments:

NetworkLibraries.gmk - is the exclude of bsd_close.c right? It looks 
like it will add this to LIBNET_EXCLUDE_FILES even when building on Mac.

In the old verifier code (check_code.c) then it's not clear to me that 
the caller wrapper is needed but in any case the change suggests to me 
that we should look at the malloc usages so that they better handle the 
size==0 case. I realize the wrappers are to avoid changing too much and 
it should be okay to handle this via a separate bug.

In net_util.c then it's a bit ugly to be calling aix_close_init. 
Michael/Chris - what you would think about the JNI_OnLoad calling into a 
platform specific function to do platform specific initialization?

The changes to java_md_solinux.c look okay to me but it makes me wonder 
if this should be renamed as it no longer exclusively Solaris + Linux.

Port.java - one suggestion for unregisterImpl is to rename it to 
preUnregister and change it to protected so that it's more obvious that 
it supposed to be overridden.

UnixNativeDispatcher.c - this looks okay (must reduced since the first 
round), I just wonder if the changes to *_getpwuid and *_getgrgid are 
really needed as this just impacts the error message. Also might be good 
to indent the #ifdef to be consistent with the other usages in these 
functions.

That's mostly it. I notice that only a small number of tests have been 
updated. Are there more test updates to come? I'm pretty sure we have a 
lot more tests that may require update (searching for SunOS might give 
some hints).

-Alan.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131121/62f03fbc/attachment.html>

From sergey.lugovoy at oracle.com  Thu Nov 21 08:50:55 2013
From: sergey.lugovoy at oracle.com (Sergey Lugovoy)
Date: Thu, 21 Nov 2013 12:50:55 +0400
Subject: [OpenJDK 2D-Dev] [2d dev] [8] Review request for JDK-8028272 :
	Tidy warnings cleanup for javax.print package
In-Reply-To: <528D6C44.9000508@oracle.com>
References: <2926438.yTqgPxlqRx@workland> <528D6C44.9000508@oracle.com>
Message-ID: <10916518.qBFopZ3Zqj@workland>

Sergey, you are right, in some cases (i.e.
at the end of package-summary.html)
the closing tag "/p" works exactly like "br".
I can submit another change; note however, that "/p" is not
mandatory for "p"; "br" works exactly like "/p" here;
and line break was the intention of the author.
Should I make new version?

Thanks


On Thursday, November 21, 2013 06:13:24 AM Sergey Bylokhov wrote:


Hi, Sergey.Looks like in some cases, it is possible to replace "<p>" to the "</p>" and close 
previous "<p>" tag.

And I had a question to a 2D team. Is duplication in the header of [1] intended?

[1] 
http://download.java.net/jdk8/docs/api/javax/print/attribute/standard/Sides.html[1]
/n/ impressions from the output document. ........SINGLE_DOCUMENT -- All the input 
docs will be combined together into one output document. Each media sheet will 
consist of /n_{i}/ impressions from the output document, where /i/ is the number of 
the input doc corresponding to that point in the output document. When the next 
input doc has a different sides value from the previous input doc, the first print-
stream page of the next input doc goes at the start of the next media sheet, possibly 
leaving only one impression on the previous media sheet. 

etc.

On 20.11.2013 13:47, Sergey Lugovoy wrote:


Hi all,
please review the fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8028272[2]
webrev : http://cr.openjdk.java.net/~yan/8028272/webrev.00/[3]

This patch cleanup tidy warnings for generated html documentation for 
javax.print package, and do not affect the appearance of the documentation.
The patch is created against jdk8/tl team repository according to requirements
of this cleanup project.


Best regards,
Serge V. Lugovoy 



-- 
Best regards, Sergey.  



--------
[1] http://download.java.net/jdk8/docs/api/javax/print/attribute/standard/Sides.html
[2] https://bugs.openjdk.java.net/browse/JDK-8028272
[3] http://cr.openjdk.java.net/~yan/8028272/webrev.00/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131121/a281bf31/attachment.html>

From sergey.lugovoy at oracle.com  Thu Nov 21 12:54:01 2013
From: sergey.lugovoy at oracle.com (Sergey Lugovoy)
Date: Thu, 21 Nov 2013 16:54:01 +0400
Subject: [OpenJDK 2D-Dev] [2d dev] [8] Review request for JDK-8028272 :
	Tidy warnings cleanup for javax.print package
In-Reply-To: <528D5803.3070906@oracle.com>
References: <2926438.yTqgPxlqRx@workland> <528D5803.3070906@oracle.com>
Message-ID: <2292505.lVMcb8oIEU@workland>

Hi Joe.

In most cases the author used this stray "<p>" as a line break.
A line break is necessary indeed but if it is followed by a block 
element, it is  considered erroneous by tidy.
So adding <br> does, in fact, better correspond to the author original
idea.


On Wednesday, November 20, 2013 04:46:59 PM Joe Darcy wrote:
> Hello,
> 
> I'm not an HTML expert, but it seems preferable to me to just remove an
> unnecessary "<p>" tag rather than replacing it with "<br/>".
> 
> Is there a reason to prefer "<br/>"?
> 
> Otherwise the changes look fine.
> 
> Thanks,
> 
> -Joe
> 
> On 11/20/2013 1:47 AM, Sergey Lugovoy wrote:
> > Hi all,
> > please review the fix.
> > bug: https://bugs.openjdk.java.net/browse/JDK-8028272
> > webrev : http://cr.openjdk.java.net/~yan/8028272/webrev.00/
> > 
> > This patch cleanup tidy warnings for generated html documentation for
> > javax.print package, and do not affect the appearance of the
> > documentation.
> > The patch is created against jdk8/tl team repository according to
> > requirements of this cleanup project.
> > 
> > 
> > Best regards,
> > Serge V. Lugovoy


From alexandr.scherbatiy at oracle.com  Thu Nov 21 13:41:59 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 21 Nov 2013 17:41:59 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <528C9A67.3000109@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
	<5283D2F9.6010100@oracle.com> <528B625D.7060406@oracle.com>
	<528BFA66.7040307@oracle.com> <528C25FD.3020707@oracle.com>
	<528C334F.4000608@oracle.com> <528C9A67.3000109@oracle.com>
Message-ID: <528E0DA7.5090301@oracle.com>

On 11/20/2013 3:17 PM, Jim Graham wrote:
> In looking through the ToolkitImage code some more it occurs to me 
> that it was already designed (moreso in a previous life) to hold onto 
> multiple representations of the image anyway.  In a prior life in 1.0 
> and 1.1 it held separate ImageRepresentation objects for each size it 
> was scaled to (via drawImage(w,h)), but that was simplified to a 
> single ImageRep when we converted to Java2D and started doing scaling 
> on the fly for all drawImage() operations. Still, the concept of an 
> alternate resolution version of the image is probably more in line 
> with the ImageRepresentation object within the ToolkitImage than in 
> having multiple ToolkitImage objects and a wrapper for them.
>
> This would also deal more naturally with the ImageObserver issue since 
> there really would be only one Image and SG2D would not deal with the 
> sub-representations, it would be dealt with in the DrawImage pipeline 
> code when it queries the ToolkitImage for the ImageRepresentation object.
>
> In the end, I think that design would be simpler overall, would it be 
> possible to shift those gears for this fix?  If not, we should 
> consider it for a near-term future cleanup task perhaps...

     I think that it would be better to postpone this cleanup to a 
near-term future task.

    Thanks,
    Alexandr.


>
>             ...jim
>
> On 11/19/2013 7:58 PM, Jim Graham wrote:
>> Based on the information below, I have the following suggestions...
>>
>> We should probably allow asynchronous loading of the scaled 
>> resolution variants.  This is a minor variation of what the 
>> ImageObserver was originally designed for, but technically might 
>> violate some developer's expectations if they have only dealt with a 
>> post-Java2D version of Java.  Some education might be helpful here.
>>
>> The wording on drawImage(dxy12, sxy12) should probably be reworded to 
>> indicate that asynchronous scaling would not happen, but alternate 
>> versions of the image may be accessed.
>>
>> In all cases, if the version of the image that we would ideally want 
>> to show hasn't been loaded, but the standard version has (or if @2x 
>> was loaded, but we want the regular version too?) then we should 
>> probably go with the version that was loaded, but still trigger the 
>> loading of the alternate version and notify their Observer as it is 
>> loaded.
>>
>> I also examined the places in the code where we notify the 
>> ImageObserver.  A search for the observer method should show all 
>> places we call it, but the primary ones look like they are fairly few 
>> places.  If we tag the resolution variant images with the composite 
>> image from which they came, then we can have those few places do 
>> something like:
>>
>> Image obsimg = (img instanceof SunToolkitImage) ? (() 
>> img).getObservedImage() : img;
>>
>> I think in most cases the img is already known to be our internal 
>> SunToolkit image and so we don't even need to check instanceof...
>>
>>              ...jim
>>
>> On 11/19/2013 7:01 PM, Jim Graham wrote:
>>> I did some more reading about the various ways in which the 
>>> ImageObserver is used and noticed the following points, some of 
>>> which may be to our advantage.
>>>
>>> Many of the drawImage() calls mention that they will notify the 
>>> observer as the image is "scaled or converted for the output 
>>> device".  I believe in the world before 2D, we would often have to 
>>> load or convert the image asynchronously for various changes in the 
>>> output.  When we created the 2D interface and added some on-the-fly 
>>> image scaling code, we mentioned that scaling was no longer 
>>> asynchronous, but technically the API is still designed for 
>>> asynchronous operations when the rendering parameters change.
>>>
>>> However, the drawImage() call that takes 8 parameters dxy12, sxy12 - 
>>> specifically includes the words:
>>>
>>>       * This method always uses the unscaled version of the image
>>>       * to render the scaled rectangle and performs the required
>>>       * scaling on the fly. It does not use a cached, scaled version
>>>       * of the image for this operation. Scaling of the image from 
>>> source
>>>       * to destination is performed such that the first coordinate
>>>       * of the source rectangle is mapped to the first coordinate of
>>>       * the destination rectangle, and the second source coordinate is
>>>       * mapped to the second destination coordinate. The subimage is
>>>       * scaled and flipped as needed to preserve those mappings.
>>>      public abstract boolean drawImage(Image img,
>>>                                        int dx1, int dy1, int dx2, 
>>> int dy2,
>>>                                        int sx1, int sy1, int sx2, 
>>> int sy2,
>>>                                        ImageObserver observer);
>>>
>>> which basically, at the time it was created in 1.1, was an opt "out" 
>>> of the asynchronous operations that might happen when you scaled an 
>>> image with drawImage(xywh).  As worded, this would suggest that this 
>>> method does not use the @2x version and always uses the default 
>>> resolution version, but those words were not put there for this 
>>> particular intent, they were put there to indicate that we weren't 
>>> going to do an off-line scaling of the pixels which sometimes 
>>> happened in 1.0.x and possibly 1.1 (for the other calls that 
>>> predated 1.1 until Java2D).
>>>
>>> I also found the Component.prepareImage() and Component.checkImage() 
>>> methods which also take an ImageObserver.  Those methods imply that 
>>> they will possibly start the process and return information on a 
>>> particular version of an image appropriate for the current output 
>>> device.  There is even a prepareImage(w,h) method that gets an image 
>>> ready to render at the indicated size.  Given that these methods are 
>>> on component, it probably makes sense to have that code look up 
>>> which representation would be used for those indicated dimensions on 
>>> the indicated output device that the Component is displayed on.
>>>
>>>              ...jim
>>>



From alexandr.scherbatiy at oracle.com  Thu Nov 21 14:15:45 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 21 Nov 2013 18:15:45 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <528BFA66.7040307@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
	<5283D2F9.6010100@oracle.com> <528B625D.7060406@oracle.com>
	<528BFA66.7040307@oracle.com>
Message-ID: <528E1591.90309@oracle.com>


    Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8011059/webrev.09/

On 11/20/2013 3:55 AM, Jim Graham wrote:
> Hi Alexander:
>
> SunHints:
>> ON - Always use resolution-specific variants of images
>> OFF - Use only the standard resolution of an image
>> DEFAULT - Choose image resolutions based on a default heuristic
>>
>> (perhaps add "(when available)" to ON?)
>
> Note that I think you are still using the descriptions I asked for in 
> the first quotation which I then revised because they were confusing.  
> Please use the latter descriptions (ON, OFF, DEFAULT above).
     Updated.

>
> SG2D:
>
> - If you rewrite getTransformedDestImageSize() to return the 
> resolution variant instead of a Dimension then you avoid having to 
> create a Dimension object that gets immediately tested for null again 
> and/or consumed by the caller.  Just move the call to 
> getResolutionVariant() inside the helper method and rename it.
     Updated.
>
> - In getTransformedDestImageSize - dx,dy,sx,sy - should be named 
> dw,dh,sw,sh?
     Updated.
>
> - Also in getTransformedDestImageSize - the array of Point objects is 
> problematic because they are used for the return values and that means 
> early truncation/rounding, the methods that take arrays of doubles are 
> generally less problematic in terms of garbage generation.  Also, you 
> can use deltaTransform() because you don't need to worry about 
> translation components since you only want the distance.  Finally, why 
> not use the optimization I gave to just grab the matrix elements 
> directly and do the calculations on them instead of 3 separate point 
> transforms which have predictable outcomes?  Here is the 
> recommendation again:
>
>> And even for the case of GENERAL transform, the above can be 
>> simplified.  The tx.deltaTransform method in that case simply loads 
>> the array with:
>>
>> { m00, m10, m01, m11 }
>>
>> and so the hypot methods are simply:
>>
>> xScale = Math.hypot(tx.getScaleX(), tx.getShearY());
>> yScale = Math.hypot(tx.getShearX(), tx.getScaleY());
>
> Multiply those values with dw,dh and you have your answer. Another way 
> to look at this is that your 3 transformed points were basically:
>
>     { dx1 * m00 + dy1 * m01 + tx,  dx1 * m10 + dy1 * m11 + ty }
>     { dx2 * m00 + dy1 * m01 + tx,  dx2 * m10 + dy1 * m11 + ty }
>     { dx1 * m00 + dy2 * m01 + tx,  dx1 * m10 + dy2 * m11 + ty }
>
> Subtracting [1] - [0] for the distance calculation eliminates a lot of 
> terms and gives you:
>
>     Math.hypot((dx2 - dx1) * m00, (dx2 - dx1) * m10)
> ==  (dx2 - dx1) * Math.hypot(m00, m10);
> ==  (dx2 - dx1) * Math.hypot(tx.getScaleX(), tx.getShearY());
>
> Subtracting [2] - [0] also reduces:
>
>     Math.hypot((dy2 - dy1) * m01, (dy2 - dy1) * m11);
> ==  (dy2 - dy1) * Math.hypot(m01, m11);
> ==  (dy2 - dy1) * Math.hypot(tx.getShearX(), tx.getScaleY());
>
> - Also in getTransformeDestImageSize - the usage of the 
> transform.getType() is off, some of the values are bitmasks so a <= 
> comparison isn't the right comparison to use.  I'd use the following 
> structure:
     Updated.

>
> To check if it is "identity-ish", I'd use:
>     ((type & ~(TYPE_TRANSLATION | TYPE_FLIP)) == 0)
> To check for scale, use:
>     ((type & ~(TYPE_TRANSLATION | TYPE_FLIP | TYPE_SCALE_MASK)) == 0)
> and then the distance/hypot equations are in the final else as they 
> are now.
     Updated.
>
> - In calculating scaledWidth/width and the cast to float - even though 
> I think the precedence order is on your side, I usually add extra 
> parentheses to highlight the order so that people reading the code 
> and/or modifying it don't mess it up.  My cutoff on what is obvious to 
> a casual reader is usually "additive vs. multiplicative" and anything 
> more subtle than that I use parentheses just in case someone comes 
> along who is less familiar with the order and decides to interpose 
> some additional operations that get in the way of the proper 
> calculation.  I would have written "((float) sW) / w" 
      Updated.
> just to make it obvious.
>
> In LWCToolkit.java:
>
> - there is a lot of string manipulation going on for every image 
> fetch.  I guess this would only hurt those who use the Toolkit as 
> their image storage (getting the image every time they need it), so 
> I'm not going to worry about it, but it would be good to eventually 
> get this integrated into the caching mechanism better so that a quick 
> lookup of a previously loaded image could return faster.
>
> One thing I did not examine very closely was the transfer of hash 
> lookup and security code to the new utility class.  You should get a 
> double-check from another engineer on that code.
>
> Some more inline comments:
>
> On 11/19/2013 5:06 AM, Alexander Scherbatiy wrote:
>>
>>    Could you review the updated fix:
>>       http://cr.openjdk.java.net/~alexsch/8011059/webrev.08/
>>       - Some related to the ToolkitImage staff is moved from 
>> SunToolkit to ToolkitImageUtil
>
> I'm not sure why this was done - it added a bunch of busy-work for 
> approving the webrev that I don't have time for.  Hopefully someone 
> else can verify the cut/paste and refactoring.
     I have reverted it back.
>
>>       - Preloading for the resolution variants is added
>
> I'm not familiar with the ImageIcon, but it looks like the use of it 
> for the resolution variant causes the resolution variant images to be 
> aggressively kicked off immediately rather than as the image is used.  
> For an application that loads 1000 images and then only renders 10 of 
> them, it will get 1000 4xsized images (@2x have 4x pixels) loaded for 
> 990 images that would never have been loaded previously.  Am I 
> misreading how the ImageIcon is used there?
>
>>       The fix sets the resolution variant hint to default on Mac OS X 
>> and to off for other platforms now.
>
> I'm still not sure why it isn't just left as DEFAULT on all 
> platforms.  The other platforms don't even create resolution images 
> anyway so their default is to just use the existing image which is 
> fine.  We should not have platform issues affecting the default values 
> for hints.

     A user can create custom MultiResolution image.  If our target is 
to show the resolution variant according to the current transform on all 
platforms then it is ok.
>
>>       The new logic uses the transform to get the destination image 
>> width and height.
>>       There is the trick question about the general transform type 
>> because image sides are not equal after the transformation in this 
>> case. So we could use only one side,
>>       or maximum value from opposite sides or may be an average value.
>
> It looks like you are supplying the independent w,h and the default 
> implementation of getResolutionVariant() is using "dispw <= imgw && 
> disph <= imgh" which I think I asked Mike about and he said that was 
> correct.  Is there another issue I'm missing?
>
>>> The parameter passed to the getResVariant method is based on the 
>>> subimage size, but the method treats it as if it were based on the 
>>> full image size. Either compute the scaled size of the full image, 
>>> or inform the method of the sub-image being scaled, or simply pass 
>>> in the scales, otherwise you will get the default image for any 
>>> sub-image renderings of less than half of the original image even if 
>>> they are rendered at retina scales.
>>     This is my fault. I really missed this part.  It is updated in 
>> the fix.
>
> I think this is done in a fairly reasonable first approximation. It 
> works for the only case we have currently which is @2x images where 
> the incoming integers translate into outgoing integers, but we'll have 
> to revisit these exact calculations if we ever want to support 
> non-integer-scale resolution variants (I think Win8 might have a 
> number of non-integer scales).
>
>>      The algorithm that gets the scaled image size is based on the 
>> width and height of both images original and scaled. That means that 
>> both images should be already preloaded.
>>      In other case we need to draw the original image (because it is 
>> not possible to know the destination image size)  and wait for more 
>> drawImage(Image ) calls to try to load the scaled image.
>
> I don't like preloading them because we never preloaded the images 
> previously and this will be a huge memory concern, not to mention the 
> fact that we used to return nearly immediately from getImage() and now 
> we have to load an entire (4x pixels) image to just return from that 
> method.  This all needs to be done asynchronously.
      I reverted it back.
>
> Also, the code in getImageWithResolutionVariants() appears to wrap the 
> image afresh every time it is called.  If you call it twice with a 
> given string then the first time will make a regular image and store 
> it there, then make a scaled image and replace it with the scaled 
> image.  The second call will retrieve the scaled image left by the 
> first call and then combine it with a second instance of the scaled 
> image to make a new doubly-nested scaled image and store that in the 
> hash.
    fixed.
>
>>      It seems that multi-resolution image preloading fixes image 
>> drawing issue as well as issue with the image observers. An image 
>> observer is not called from the g.drawImage()
>>      method in case if both images images are preloded and the 
>> original image does not have errors.
>
> What about the other cases of errors?  What if they switch back and 
> forth between the resolutions?  What image is reported in the callback 
> for the non-scaled image?
       If an image is preloaded and the base image does not have errors 
than the image observer is not called. That was a point for the image 
preloading.
>
> What happens for MediaTracker?
>
>>      The fix does not use url.openConnection() now. It tries to 
>> preload the @2x image and if it is successful it preloads the 
>> original image as well.
>
> getImage() is not supposed to preload anything.  Also, I didn't see 
> where it preloads the original image, just the resolution variant.
      We do not need to preload the original image. The 
MultiResolutionImage which is based on the original image should be 
preloaded instead.

    In the last fix the images are not preloaded. I read the previous 
message there it is suggested to keep the original image in the 
ToolkitImage.
    However, a user can create it's own MultiResolutionImage 
implementation. So I added the static containsResolutionVariant() method 
and updated
    necessary observers in our code. Usually the code "image!= img" is 
changed to "MultiResolutionImage.containsResolutionVariant(image, img)"
    and x, y, width, and height values are recalculated.  The same 
should be done in a user's code.

>>     I also look at the custom cursor part of the HiDPI issues. A user 
>> needs to prepare the MultiResolutionImage and we can use 
>> CImage.createFromImages(List<Image> images)
>>     method to create necessary NSImage. This means that it should be 
>> possible to obtain all resolution variants from the 
>> MultiResolutionImage.
>>     I have included the "List<Image> getResolutionVariants()" method 
>> to the MultiResolutionImage for that.
>
> I was going to ask about that new method.  Why does the developer need 
> to manually intercede here?  They should be able to grab an image that 
> has an @2x variant, use MediaTracker or some other mechanism to make 
> sure it is loaded, then create the cursor and the code that creates 
> the cursor should notice the resolution variations and deal with it on 
> its own...
      Mac OS X gets a necessary image based on the current transform. A 
user can create its own MultiResolutionImage that contains images for 
the scales, for example, 0.5, 0.7, 1, 3.2.
      We need to know a list of all images to create the NSImage.

   Thanks,
   Alexandr.

>
>             ...jim



From volker.simonis at gmail.com  Thu Nov 21 15:54:07 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 21 Nov 2013 16:54:07 +0100
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <528DF61B.6060403@oracle.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
	<528DF61B.6060403@oracle.com>
Message-ID: <CA+3eh105jG=-g3czKvamJnnA_1vw5XAWM7puBKa-6caR3KAGVw@mail.gmail.com>

Hi Alan,

thanks a lot for the fast review and your valuable comments. Please find my
answers inline:


On Thu, Nov 21, 2013 at 1:01 PM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

>  On 20/11/2013 18:26, Volker Simonis wrote:
>
>  Hi,
>
> this is the second review round for "8024854: Basic changes and files to
> build the class library on AIX<https://bugs.openjdk.java.net/browse/JDK-8024854>".
> The previous reviews can be found at the end of this mail in the references
> section.
>
> I've tried to address all the comments and suggestions from the first
> round and to further streamline the patch (it perfectly builds on
> Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The
> biggest change compared to the first review round is the new "aix/"
> subdirectory which I've now created under "jdk/src" and which contains
> AIX-only code.
>
> Thanks for the update and addressing all the original comments and
> suggestions. In particular, moving most of the AIX specific files to
> src/aix and including an implementation of dladdr, make a big difference
> and makes this much easier to review.
>
> I've skimmed through all the non-client files in the webrev and just have
> a few comments:
>
> NetworkLibraries.gmk - is the exclude of bsd_close.c right? It looks like
> it will add this to LIBNET_EXCLUDE_FILES even when building on Mac.
>
>
You're right, that's a typo. That should have read:

  48 ifneq ($(OPENJDK_TARGET_OS), aix)  49   LIBNET_EXCLUDE_FILES +=
aix_close.c  50 else  51   LIBNET_SRC_DIRS +=
$(JDK_TOPDIR)/src/aix/native/java/net/
  52 endif

But actually I've just realized that it is not need at all, because
'aix_close.c' isn't in the PATH for any other OS than AIX (that could be
probably called a feature of the new file layout:) So I'll simply change it
to:

  48 ifeq ($(OPENJDK_TARGET_OS), aix)  49   LIBNET_SRC_DIRS +=
$(JDK_TOPDIR)/src/aix/native/java/net/
  50 endif

In the old verifier code (check_code.c) then it's not clear to me that the
> caller wrapper is needed but in any case the change suggests to me that we
> should look at the malloc usages so that they better handle the size==0
> case. I realize the wrappers are to avoid changing too much and it should
> be okay to handle this via a separate bug.
>
>
Yes, exactly. I didn't wanted to change too much code. But as the
C-Standard states (
http://pubs.opengroup.org/onlinepubs/000095399/functions/malloc.html)
"...If size is 0, either a null pointer or a unique pointer that can be
successfully passed to free() shall be returned..." it is perfectly legal
that malloc/calloc return a NULL pointer if called with a zero argument.
This case is currently not handled (i.e. it's handled as an 'out of memory'
error) in check_code.c and I agree that this should be fixed via a separate
bug.


> In net_util.c then it's a bit ugly to be calling aix_close_init.
> Michael/Chris - what you would think about the JNI_OnLoad calling into a
> platform specific function to do platform specific initialization?
>
>
What about renaming 'initLocalAddrTable()' into something like
'platformInit()' and moving the call to 'aix_close_init' to a AIX-specific
version of 'platformInit()' in net_util_md.c?


> The changes to java_md_solinux.c look okay to me but it makes me wonder if
> this should be renamed as it no longer exclusively Solaris + Linux.
>
>
You're right - we could rename it to something like 'java_md_unix.c'. But
no matter how fancy the name would be, the file would still be in the
'src/solaris/bin' subdirectory:( So I think we'd better leave this for a
later change when we completely factor  out the Linux/Mac code from the
'solaris/' directory.


> Port.java - one suggestion for unregisterImpl is to rename it to
> preUnregister and change it to protected so that it's more obvious that it
> supposed to be overridden.
>
>
Done. Also changed the comment to JavaDoc style to be more consistent with
the other comments in that file.


> UnixNativeDispatcher.c - this looks okay (must reduced since the first
> round), I just wonder if the changes to *_getpwuid and *_getgrgid are
> really needed as this just impacts the error message. Also might be good to
> indent the #ifdef to be consistent with the other usages in these functions.
>
>
You're right. This change was done before you fixed "7043788: (fs)
PosixFileAttributes.owner() or group() throws NPE if owner/group not in
passwd/group database" (
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f91c799f7bfb). After you're
fix it was  "automatically" adapted. I've removed the special AIX handling
as suggested because I think as well that another error message in the
exception won't have any impact.


> That's mostly it. I notice that only a small number of tests have been
> updated. Are there more test updates to come? I'm pretty sure we have a lot
> more tests that may require update (searching for SunOS might give some
> hints).
>
>
I'm currently working on it and created "8028537: PPC64: Updated jdk/test
scripts to understand the AIX os and environment" for it because I didn't
wanted to blow up this change unnecessarily.

-Alan.
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131121/c32891cb/attachment.html>

From james.graham at oracle.com  Thu Nov 21 16:13:57 2013
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 21 Nov 2013 08:13:57 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <528E1591.90309@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
	<5283D2F9.6010100@oracle.com> <528B625D.7060406@oracle.com>
	<528BFA66.7040307@oracle.com> <528E1591.90309@oracle.com>
Message-ID: <528E3145.1020105@oracle.com>

Hi Alexander,

I just noticed that the new interface was created in com.sun.  I also note that you discuss a number of issues below that relate to a developer creating one of their own Multi-Resolution images.  We should not be exporting an interface at this point for a developer to do any of that.  Any use of these interfaces beyond our own internal use to support @2x images will be unsupported in JDK8 as we do not have time to properly test and expose an interface with the remaining time in the JDK8 release schedule.  This interface should be moved to the internal sun.* hierarchy until we have time to vet it.

All of the places that call containsResolutionVariant() are pointing out a bug with this implementation.  The resolution variants are internal implementation details and should never be leaked through any current interfaces.  It looks like most of the cases involve imageUpdate() methods that should be receiving a reference to the original image, not the resolution variant.  These pieces of could should not be changing and the fact that you had to change them points out that you've created a huge compatibility issue that blocks this solution.

On 11/21/2013 6:15 AM, Alexander Scherbatiy wrote:
>>
>> To check if it is "identity-ish", I'd use:
>>     ((type & ~(TYPE_TRANSLATION | TYPE_FLIP)) == 0)
>> To check for scale, use:
>>     ((type & ~(TYPE_TRANSLATION | TYPE_FLIP | TYPE_SCALE_MASK)) == 0)
>> and then the distance/hypot equations are in the final else as they are now.
>      Updated.

The test at line 3152 is sub-optimal.  If the transform includes both a SCALE and a TRANSLATE then this optimization will fail to trigger and the code will fall through to the default case (which produces the correct output, but misses the optimization).  Note above that I include the FLIP and TRANSLATE flags in with the SCALE mask to take care of this in my pseudo-code above.

>>>       - Some related to the ToolkitImage staff is moved from SunToolkit to ToolkitImageUtil
>>
>> I'm not sure why this was done - it added a bunch of busy-work for approving the webrev that I don't have time for.  Hopefully someone else can verify the cut/paste and refactoring.
>      I have reverted it back.

Thanks, it is much easier to verify what was modified now.

>> I'm still not sure why it isn't just left as DEFAULT on all platforms.  The other platforms don't even create resolution images anyway so their default is to just use the existing image which is fine.  We should not have platform issues affecting the default values for hints.
>
>      A user can create custom MultiResolution image.  If our target is to show the resolution variant according to the current transform on all platforms then it is ok.

If and when we expose the ability to create these images then the developer would want them to be used on all platforms if they are going to the trouble of manually creating them.  Until then the @2x images are only created on MacOS anyway so the value of the hint is irrelevant on other platforms.  Arguably, we might want to start loading the @2x images on other platforms too, but I think we can go into the 8.0 release with just MacOS support and worry about using it on other platforms in an 8 update release.  In either case, the default hint value should be DEFAULT.

>     However, a user can create it's own MultiResolutionImage implementation. So I added the static containsResolutionVariant() method and updated
>     necessary observers in our code. Usually the code "image!= img" is changed to "MultiResolutionImage.containsResolutionVariant(image, img)"

We should not be catering to custom uses at this point until a later release.

If any of this code requires changes to ImageObservers then that is a bug as I mentioned above.

>     and x, y, width, and height values are recalculated.  The same should be done in a user's code.

We should not require changes to developer's ImageObserver code to support @2x.

>> I was going to ask about that new method.  Why does the developer need to manually intercede here?  They should be able to grab an image that has an @2x variant, use MediaTracker or some other mechanism to make sure it is loaded, then create the cursor and the code that creates the cursor should notice the resolution variations and deal with it on its own...
>       Mac OS X gets a necessary image based on the current transform. A user can create its own MultiResolutionImage that contains images for the scales, for example, 0.5, 0.7, 1, 3.2.
>       We need to know a list of all images to create the NSImage.

Any code that triggers an image to load and then looks for that same reference in its imageUpdate() method (which is the case in the MediaTracker code) should continue to work.  That was the point I was trying to make and I've reiterated this above.  MediaTracker (which should support @2x images without any code changes) simply makes a good test case that we've handled the compatibility issues here...

			...jim


From linuxhippy at gmail.com  Thu Nov 21 21:30:20 2013
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Thu, 21 Nov 2013 16:30:20 -0500
Subject: [OpenJDK 2D-Dev] request for review: JDK-8028722: XRender:
 Drawing strings with exactly 254 glyphs causes hangs
In-Reply-To: <528D8F72.9060603@oracle.com>
References: <CAFvQSYRQNBHYRjkz2sw_XAc0PdFgPDnd=N6hfVxbokGi9hzs1w@mail.gmail.com>
	<528D8F72.9060603@oracle.com>
Message-ID: <CAFvQSYT0=G-qMWFm_7Pc4JQgsDihYOYHwO7gdABLPvCMnNUZYA@mail.gmail.com>

Hi Phil,

Thanks for the review.

> Not that it impacts us now but I think the tricky question is can we ever
> remove the workaround?
> ie how will we ever know when we are using a fixed xrender lib.
> I'd like to see core Xrender add a "GetVersion()" API  so we can figure this
> stuff out at runtime.

In this case the decision to leave the workarround in forever is easy
- it only causes minimal protocol overhead for larger strings (0.05
extra bytes per 253 characters).
In other areas an API to detect the driver / xorg and library versions
would have saved a lot of headache.

However with wayland/mir/... on the horizon, there is still hope for
better opengl drivers in mid-term future :)

Thanks, Clemens


From patrick at reini.net  Thu Nov 21 21:34:27 2013
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 21 Nov 2013 22:34:27 +0100
Subject: [OpenJDK 2D-Dev] JDK-7107175 - Paper tray handling
Message-ID: <27AA49C8-B6A9-4B22-853D-4B8DC65339E0@reini.net>

Hi everybody,

I would like to look into this defect as one of our customer has reported the same problem. I also have seen that there is no way to specify a media size name and a output tray neither thru the PrintRequestAttributeSet nor the DocAttributeSet even-though it's possible to do so within the print dialog. 

As in the in the defect described, media size and tray can be specified for a CUPS printer. Unfortunately the Attribute type for MediaTray and MediaSizeName can not be mixed...

What would be the correct solution for this problem?

Cheers Patrick

From philip.race at oracle.com  Thu Nov 21 22:08:42 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 21 Nov 2013 14:08:42 -0800
Subject: [OpenJDK 2D-Dev] JDK-7107175 - Paper tray handling
In-Reply-To: <27AA49C8-B6A9-4B22-853D-4B8DC65339E0@reini.net>
References: <27AA49C8-B6A9-4B22-853D-4B8DC65339E0@reini.net>
Message-ID: <528E846A.1020001@oracle.com>

> What would be the correct solution for this problem?

Which problem ?

7107175  sounds like a bug in the parameters we pass to lpr

The other problem you mention is largely if not entirely because IPP lumped
trays along with papers as being "Media".

See http://tools.ietf.org/html/rfc2566#section-4.2.11

    If a Printer object supports a medium name as a value of this
    attribute, such a medium name implicitly selects an input-tray that
    contains the specified medium.  If a Printer object supports a medium
    size as a value of this attribute, such a medium size implicitly
    selects a medium name that in turn implicitly selects an input-tray
    that contains the medium with the specified size.  If a Printer
    object supports an input-tray as the value of this attribute, such an
    input-tray implicitly selects the medium that is in that input-tray
    at the time the job prints.

I can see no way around this other than defining an new attribute class 
that doesn't
subclass Media and duplicates MediaTray .. but then you'd also need to 
say what happens
if someone specifies two different trays, one by each means.

That's an API solution that doesn't seem likely any time soon.

Plus, providing a way to specify both simultaneously at an API level 
wouldn't
be enough to resolve 7107175  .

-phil.

On 11/21/2013 1:34 PM, Patrick Reinhart wrote:
> Hi everybody,
>
> I would like to look into this defect as one of our customer has reported the same problem. I also have seen that there is no way to specify a media size name and a output tray neither thru the PrintRequestAttributeSet nor the DocAttributeSet even-though it's possible to do so within the print dialog.
>
> As in the in the defect described, media size and tray can be specified for a CUPS printer. Unfortunately the Attribute type for MediaTray and MediaSizeName can not be mixed...
>
> What would be the correct solution for this problem?
>
> Cheers Patrick



From patrick at reini.net  Thu Nov 21 22:52:10 2013
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 21 Nov 2013 23:52:10 +0100
Subject: [OpenJDK 2D-Dev] JDK-7107175 - Paper tray handling
In-Reply-To: <528E846A.1020001@oracle.com>
References: <27AA49C8-B6A9-4B22-853D-4B8DC65339E0@reini.net>
	<528E846A.1020001@oracle.com>
Message-ID: <C133212A-4896-4836-87A1-7CFC7399D9A5@reini.net>

Hi Phil,

Am 21.11.2013 um 23:08 schrieb Phil Race <philip.race at oracle.com>:

>> What would be the correct solution for this problem?
> 
> Which problem ?
> 
> 7107175  sounds like a bug in the parameters we pass to lpr
> 
> The other problem you mention is largely if not entirely because IPP lumped
> trays along with papers as being "Media".
> 
> See http://tools.ietf.org/html/rfc2566#section-4.2.11
> 
>   If a Printer object supports a medium name as a value of this
>   attribute, such a medium name implicitly selects an input-tray that
>   contains the specified medium.  If a Printer object supports a medium
>   size as a value of this attribute, such a medium size implicitly
>   selects a medium name that in turn implicitly selects an input-tray
>   that contains the medium with the specified size.  If a Printer
>   object supports an input-tray as the value of this attribute, such an
>   input-tray implicitly selects the medium that is in that input-tray
>   at the time the job prints.
> 

If I understand this correct, that means it should be possible to just define a MediaTray without a MediaSizeName then right? But in my environment the default MediaSizeName is set to Letter even though the current PrintService would define A4 as the default.

If I compare the basic behavior in comparison to the Windows implementation. The are some differences in setting the default MediaSize and MediaSizeName. Those will be not initialized in the Windows world and taken from the current PrintService in case it's not set via PrintRequestAttributeSet.


> I can see no way around this other than defining an new attribute class that doesn't
> subclass Media and duplicates MediaTray .. but then you'd also need to say what happens
> if someone specifies two different trays, one by each means.
> 

I do not completely understand what you mean. Do you mean the use case if one specifies A4,Tray2 but Tray2 contains Letter?

Patrick


> That's an API solution that doesn't seem likely any time soon.
> 
> Plus, providing a way to specify both simultaneously at an API level wouldn't
> be enough to resolve 7107175  .
> 
> -phil.
> 
> On 11/21/2013 1:34 PM, Patrick Reinhart wrote:
>> Hi everybody,
>> 
>> I would like to look into this defect as one of our customer has reported the same problem. I also have seen that there is no way to specify a media size name and a output tray neither thru the PrintRequestAttributeSet nor the DocAttributeSet even-though it's possible to do so within the print dialog.
>> 
>> As in the in the defect described, media size and tray can be specified for a CUPS printer. Unfortunately the Attribute type for MediaTray and MediaSizeName can not be mixed...
>> 
>> What would be the correct solution for this problem?
>> 
>> Cheers Patrick
> 



From philip.race at oracle.com  Thu Nov 21 23:15:06 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 21 Nov 2013 15:15:06 -0800
Subject: [OpenJDK 2D-Dev] JDK-7107175 - Paper tray handling
In-Reply-To: <C133212A-4896-4836-87A1-7CFC7399D9A5@reini.net>
References: <27AA49C8-B6A9-4B22-853D-4B8DC65339E0@reini.net>
	<528E846A.1020001@oracle.com>
	<C133212A-4896-4836-87A1-7CFC7399D9A5@reini.net>
Message-ID: <528E93FA.4010900@oracle.com>

On 11/21/2013 2:52 PM, Patrick Reinhart wrote:
> Hi Phil,
>
> Am 21.11.2013 um 23:08 schrieb Phil Race <philip.race at oracle.com>:
>
>>> What would be the correct solution for this problem?
>> Which problem ?
>>
>> 7107175  sounds like a bug in the parameters we pass to lpr
>>
>> The other problem you mention is largely if not entirely because IPP lumped
>> trays along with papers as being "Media".
>>
>> See http://tools.ietf.org/html/rfc2566#section-4.2.11
>>
>>    If a Printer object supports a medium name as a value of this
>>    attribute, such a medium name implicitly selects an input-tray that
>>    contains the specified medium.  If a Printer object supports a medium
>>    size as a value of this attribute, such a medium size implicitly
>>    selects a medium name that in turn implicitly selects an input-tray
>>    that contains the medium with the specified size.  If a Printer
>>    object supports an input-tray as the value of this attribute, such an
>>    input-tray implicitly selects the medium that is in that input-tray
>>    at the time the job prints.
>>
> If I understand this correct, that means it should be possible to just define a MediaTray without a MediaSizeName then right? But in my environment the default MediaSizeName is set to Letter even though the current PrintService would define A4 as the default.

I see a line in RasterPrinterJob.java which might cause that to happen 
if you specify
a tray and no paper but that seems like its a bug. It should always be 
the default for the current
printer unless I'm forgetting something we had to do for backwards 
compatibility.


>
> If I compare the basic behavior in comparison to the Windows implementation. The are some differences in setting the default MediaSize and MediaSizeName. Those will be not initialized in the Windows world and taken from the current PrintService in case it's not set via PrintRequestAttributeSet.
>
>
>> I can see no way around this other than defining an new attribute class that doesn't
>> subclass Media and duplicates MediaTray .. but then you'd also need to say what happens
>> if someone specifies two different trays, one by each means.
>>
> I do not completely understand what you mean. Do you mean the use case if one specifies A4,Tray2 but Tray2 contains Letter?

I meant that if we provided a new class "MediaSource" you could specify 
MediaSource.TRAY1
whilst still specifying for "Media" an instance of the subclass 
MediaTray that corresponded
to TRAY2.

-phil.

> Patrick
>
>
>> That's an API solution that doesn't seem likely any time soon.
>>
>> Plus, providing a way to specify both simultaneously at an API level wouldn't
>> be enough to resolve 7107175  .
>>
>> -phil.
>>
>> On 11/21/2013 1:34 PM, Patrick Reinhart wrote:
>>> Hi everybody,
>>>
>>> I would like to look into this defect as one of our customer has reported the same problem. I also have seen that there is no way to specify a media size name and a output tray neither thru the PrintRequestAttributeSet nor the DocAttributeSet even-though it's possible to do so within the print dialog.
>>>
>>> As in the in the defect described, media size and tray can be specified for a CUPS printer. Unfortunately the Attribute type for MediaTray and MediaSizeName can not be mixed...
>>>
>>> What would be the correct solution for this problem?
>>>
>>> Cheers Patrick



From volker.simonis at gmail.com  Fri Nov 22 10:45:25 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 22 Nov 2013 11:45:25 +0100
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
Message-ID: <CA+3eh10HtfV5pJ68Wc1z=AjHVD_Eb152m_EjPHbVS=iiL46tuw@mail.gmail.com>

We've synced our staging repository yesterday with the latest jdk8-b117 and
I noticed that change "8025985: com.sun.management.OSMBeanFactory should
not be public" moved the file src/solaris/native/com/sun/
management/UnixOperatingSystem_md.c to
src/solaris/native/sun/management/OperatingSystemImpl.c. Fortunately, my
changes to UnixOperatingSystem_md.c described in the webrev apply cleanly
to the new file (I've tested this locally).

I'll update the webrev accordingly once I've collected some more feedback.

Thank you and best regards,
Volker


On Wed, Nov 20, 2013 at 7:26 PM, Volker Simonis <volker.simonis at gmail.com>wrote:

> Hi,
>
> this is the second review round for "8024854: Basic changes and files to
> build the class library on AIX<https://bugs.openjdk.java.net/browse/JDK-8024854>".
> The previous reviews can be found at the end of this mail in the references
> section.
>
> I've tried to address all the comments and suggestions from the first
> round and to further streamline the patch (it perfectly builds on
> Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The
> biggest change compared to the first review round is the new "aix/"
> subdirectory which I've now created under "jdk/src" and which contains
> AIX-only code.
>
> The webrev is against our http://hg.openjdk.java.net/ppc-aix-port/stagerepository which has been recently synchronised with the jdk8 master:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/
>
> Below (and in the webrev) you can find some comments which explain the
> changes to each file. In order to be able to push this big change, I need
> the approval of reviewers from the lib, net, svc, 2d, awt and sec groups.
> So please don't hesitate to jump at it - there are enough changes for
> everybody:)
>
> Thank you and best regards,
> Volker
>
> *References:*
>
> The following reviews have been posted so far (thanks Iris for collecting
> them :)
>
> - Alan Bateman (lib): Initial comments (16 Sep [2])
> - Chris Hegarty (lib/net): Initial comments (20 Sep [3])
> - Michael McMahon (net): Initial comments (20 Sept [4])
> - Steffan Larsen (svc): APPROVED (20 Sept [5])
> - Phil Race (2d): Initial comments  (18 Sept [6]); Additional comments
> (15 Oct [7])
> - Sean Mullan (sec): Initial comments (26 Sept [8])
>
> [2]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html
> [3]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html
> [4]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html
> [5]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html
> [6]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html
> [7]:
> http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html
> [8]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html
>
>
> *Detailed change description:*
>
> The new "jdk/src/aix" subdirectory contains the following new and
> AIX-specific files for now:
>
>  src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>  src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java
>  src/aix/classes/sun/nio/ch/AixPollPort.java
>  src/aix/classes/sun/nio/fs/AixFileStore.java
>  src/aix/classes/sun/nio/fs/AixFileSystem.java
>  src/aix/classes/sun/nio/fs/AixFileSystemProvider.java
>  src/aix/classes/sun/nio/fs/AixNativeDispatcher.java
>  src/aix/classes/sun/tools/attach/AixAttachProvider.java
>  src/aix/classes/sun/tools/attach/AixVirtualMachine.java
>  src/aix/native/java/net/aix_close.c
>  src/aix/native/sun/nio/ch/AixPollPort.c
>  src/aix/native/sun/nio/fs/AixNativeDispatcher.c
>  src/aix/native/sun/tools/attach/AixVirtualMachine.c
>  src/aix/porting/porting_aix.c
>  src/aix/porting/porting_aix.h
>
> src/aix/porting/porting_aix.c
> src/aix/porting/porting_aix.h
>
>    - Added these two files for AIX relevant utility code.
>    - Currently these files only contain an implementation of dladdr which
>    is not available on AIX.
>    - In the first review round the existing dladdr users in the code
>    either called the version from the HotSpot on AIX (
>    src/solaris/native/sun/awt/awt_LoadLibrary.c) or had a private copy of
>    the whole implementation (src/solaris/demo/jvmti/hprof/hprof_md.c).
>    This is now not necessary any more.
>
>  The new file layout required some small changes to the makefiles to make
> them aware of the new directory locations:
>
> makefiles/CompileDemos.gmk
>
>    - Add an extra argument to SetupJVMTIDemo which can be used to pass
>    additional source locations.
>    - Currently this is only used on AIX for the AIX porting utilities
>    which are required by hprof.
>
> makefiles/lib/Awt2dLibraries.gmk
> makefiles/lib/ServiceabilityLibraries.gmk
>
>    - On AIX add the sources of the AIX porting utilities to the build.
>    They are required by src/solaris/native/sun/awt/awt_LoadLibrary.c and
>    src/solaris/demo/jvmti/hprof/hprof_md.c because dladdr is not
>    available on AIX.
>
> makefiles/lib/NioLibraries.gmk
>
>    - Make the AIX-build aware of the new NIO source locations under
>    src/aix/native/sun/nio/.
>
> makefiles/lib/NetworkingLibraries.gmk
>
>    - Make the AIX-build aware of the new aix_close.c source location
>    under src/aix/native/java/net/.
>
> src/share/bin/jli_util.h
>
>    - Define JLI_Lseek on AIX.
>
> src/share/lib/security/java.security-aix
>
>    - Provide default java.security-aix for AIX based on the latest Linux
>    version as suggested by Sean Mullan.
>
> src/share/native/common/check_code.c
>
>    - On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is
>    legal, but the code in check_code.c does not handles this properly. So
>    we wrap the two methods on AIX and return a non-NULL pointer even if we
>    allocate 0 bytes.
>
> src/share/native/sun/awt/medialib/mlib_sys.c
>
>    - malloc always returns 8-byte aligned pointers on AIX as well.
>
> src/share/native/sun/awt/medialib/mlib_types.h
>
>    - Add AIX to the list of known platforms.
>
> src/share/native/sun/font/layout/KernTable.cpp
>
>    - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too
>    common and may be defined in other headers as well as on the command line
>    and xlc bails out on macro redefinitions with a different value.
>
> src/share/native/sun/security/ec/impl/ecc_impl.h
>
>    - Define required types and macros on AIX.
>
> src/solaris/back/exec_md.c
>
>    - AIX behaves like Linux in this case so check for it in the Linux
>    branch.
>
> src/solaris/bin/java_md_solinux.c,
> src/solaris/bin/java_md_solinux.h
>
>    - On AIX LD_LIBRARY_PATH is called LIBPATH
>    - Always use LD_LIBRARY_PATH macro instead of using the string "
>    LD_LIBRARY_PATH" directly to cope with different library path names.
>    - Add jre/lib/<arch>/jli to the standard library search path on AIX
>    because the AIX linker doesn't support the -rpath option.
>    - Replace #ifdef __linux__ by #ifndef __solaris__ because in this
>    case, AIX behaves like Linux.
>    - Removed the definition of JVM_DLL, JAVA_DLL and LD_LIBRARY_PATH from
>    java_md_solinux.h because the macros are redefined in the
>    corresponding .c files anyway.
>
> src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>
>    - Provide basic fontconfig.propertiesfor AIX.
>
> src/solaris/classes/java/lang/UNIXProcess.java.aix,
> src/aix/classes/sun/tools/attach/AixAttachProvider.java,
> src/aix/classes/sun/tools/attach/AixVirtualMachine.java,
> src/aix/native/sun/tools/attach/AixVirtualMachine.c
>
>    - Provide AIX specific Java versions, mostly based on the
>    corresponding Linux versions.
>
> src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java
> src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java
>
>    - Detect AIX operating system and return the corresponding channel and
>    file system providers.
>
> src/solaris/classes/sun/nio/ch/Port.java
>
>    - Add a callback function unregisterImpl(int fd) for implementations
>    that need special handling when fd is removed and call it from unregister(int
>    fd). By default the implementation of unregisterImpl(int fd) is empty
>    except for the derived AixPollPort class on AIX.
>
> src/solaris/demo/jvmti/hprof/hprof_md.c
>
>    - Add AIX support. AIX mostly behaves like Linux, with the one
>    exception that it has no dladdr functionality.
>    - Use the dladdr implementation from porting_aix.{c,h} on AIX.
>
> src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>
>    - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory).
>
> src/solaris/native/common/jdk_util_md.h
>
>    - Add AIX definitions of the ISNANF and ISNAND macros.
>
> src/solaris/native/java/io/io_util_md.c
>
>    - AIX behaves like Linux in this case so check for it in the Linux
>    branch.
>
> src/solaris/native/java/lang/UNIXProcess_md.c
>
>    - AIX behaves mostly like Solraris in this case so adjust the ifdefs
>    accordingly.
>
> src/solaris/native/java/lang/childproc.c
>
>    - AIX does not understand '/proc/self' - it requires the real process
>    ID to query the proc file system for the current process.
>
> src/solaris/native/java/net/NetworkInterface.c
>
>    - Add AIX support into the Linux branch because AIX mostly behaves
>    like AIX for IPv4.
>    - AIX needs a special function to enumerate IPv6 interfaces and to
>    query the MAC address.
>    - Moved the declaration of siocgifconfRequest to the beginning a the
>    function (as recommend by Michael McMahon) to remain C89 compatible.
>
> src/solaris/native/java/net/PlainSocketImpl.c
>
>    - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the
>    socket is closed. The default error message is then confusing.
>
> src/aix/native/java/net/aix_close.c,
> src/share/native/java/net/net_util.c
>
>    - As recommended by Michael McMahon and Alan Bateman I've move an
>    adapted version of linux_close.c to src/aix/native/java/net/aix_close.cbecause we also need the file and socket wrappers on AIX.
>    - Compared to the Linux version, we've added the initialization of
>    some previously uninitialized data structures.
>    - Also, on AIX we don't have __attribute((constructor)) so we need to
>    initialize manually (from JNI_OnLoad() in
>    src/share/native/java/net/net_util.c.
>
> src/solaris/native/java/net/net_util_md.h
>
>    - AIX needs the same workaround for I/O cancellation like Linux and
>    MacOSX.
>
> src/solaris/native/java/net/net_util_md.c
>
>    - SO_REUSEADDR is called SO_REUSEPORT on AIX.
>    - On AIX we have to ignore failures due to ENOBUFS when setting the
>    SO_SNDBUF/SO_RCVBUF socket options.
>
> src/solaris/native/java/util/TimeZone_md.c
>
>    - Currently on AIX the only way to get the platform time zone is to
>    read it from the TZ environment variable.
>
> src/solaris/native/sun/awt/awt_LoadLibrary.c
>
>    - Use the dladdr from porting_aix.{c,h} on AIX.
>
> src/solaris/native/sun/awt/fontpath.c
>
>    - Changed some macros from if !defined(__linux__) to if
>    defined(__solaris__) because that's their real meaning.
>    - Add AIX specific fontpath settings and library search paths for
>    libfontconfig.so.
>
> src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>
>    - Rename the MIN and MAX macros to XSD_MIN and XSD_MAX to avoid name
>    clashes (MIN and MAX are much too common and thexy are already defined
>    in some AIX system headers).
>
> src/solaris/native/sun/java2d/x11/XRBackendNative.c
>
>    - Handle AIX like Solaris.
>
> src/solaris/native/sun/nio/ch/Net.c
>
>    - Add AIX-specific includes and constant definitions.
>    - On AIX "socket extensions for multicast source filters" support
>    depends on the OS version. Check for this and throw appropriate exceptions
>    if it is requested but not supported. This is needed to pass
>    JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast
>
> src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
>
>    - On AIX strerror() is not thread-safe so we have to use strerror_r()instead.
>    - On AIX readdir_r() returns EBADF (i.e. '9') and sets 'result' to
>    NULL for the directory stream end. Otherwise, 'errno' will contain the
>    error code.
>    - Handle some AIX corner cases for the results of the statvfs64() call.
>    - On AIX getgrgid_r() returns ESRCH if group does not exist.
>
> src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>
>    - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX.
>
> test/java/lang/ProcessBuilder/Basic.java
> test/java/lang/ProcessBuilder/DestroyTest.java
>
>    - Port this test to AIX and make it more robust (i.e. recognize the
>    "C" locale as isEnglish(), ignore VM-warnings in the output, make sure
>    the "grandchild" processes created by the test don't run too long (60s vs.
>    6666s) because in the case of test problems these processes will pollute
>    the process space, make sure the test fails with an error and doesn't hang
>    indefinitley in the case of a problem).
>
>  *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this
> intended?
>
> Well, _AIX is defined in some system headers while AIX is defined by the
> build system. This is already used inconsistently (i.e. __linux__ vs.
> LINUX) and in general I try to be consistent with the style of the file
> where I the changes are. That said, I changes most of the occurences of
> AIX to _AIX.
>
> *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are
> they supposed to be there?
>
> We currently don't support OS/400 (later renamed into i5/OS and currently
> called IBM i) in our OpenJDK port but we do support it in our internel, SAP
> JVM build. We stripped out all the extra OS/400 functionality from the port
> but in some places where there is common functionality needd by both, AIX
> and OS/400 the OS/400 support may still be visible in the OpenJDK port. I
> don't think this is a real problem and it helps us to keep our internel
> sources in sync with the OpenJDK port. That said, I think I've removed all
> the references to OS/400 now.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131122/c71b0541/attachment.html>

From alexandr.scherbatiy at oracle.com  Fri Nov 22 10:53:54 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 22 Nov 2013 14:53:54 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <528E3145.1020105@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
	<5283D2F9.6010100@oracle.com> <528B625D.7060406@oracle.com>
	<528BFA66.7040307@oracle.com> <528E1591.90309@oracle.com>
	<528E3145.1020105@oracle.com>
Message-ID: <528F37C2.8050907@oracle.com>

On 11/21/2013 8:13 PM, Jim Graham wrote:
> Hi Alexander,
>
> I just noticed that the new interface was created in com.sun.  I also 
> note that you discuss a number of issues below that relate to a 
> developer creating one of their own Multi-Resolution images.  We 
> should not be exporting an interface at this point for a developer to 
> do any of that.  Any use of these interfaces beyond our own internal 
> use to support @2x images will be unsupported in JDK8 as we do not 
> have time to properly test and expose an interface with the remaining 
> time in the JDK8 release schedule.  This interface should be moved to 
> the internal sun.* hierarchy until we have time to vet it.

    I see that NSImage on Mac OS X has API to work with representations 
and has methods like 
addRepresentation/removeRepresentation/bestRepresentationForRect.

    Does it mean that it is possible to use not only @2x images in an 
application but create NSImage with different images resolutions as well?
    Should we support the same thing in Java? For example, a user wants 
to provide images with resolutions 0.5, 1, 2, and 3. According to the 
current transform the best resolution variant should be chosen.

   The MultiResolutionImage is in com.sun* package and it still means 
that it can be changed or removed. It can require the CCC request, though.
   Putting it to sun.com prevents using this feature in applets.

   I do not see any compatibility risks with the current fix. If a user 
does not provide @2x images or explicitly overrides the 
MultiResolutionImage nothing should be changed in his code.

   The time testing of this API is the same as testing TollkitImages 
that can hold @2x images.
   We also will have the feedback about these API earlier.  It is better 
than introducing a public API in next release that will be difficult to 
change.

>
> All of the places that call containsResolutionVariant() are pointing 
> out a bug with this implementation.  The resolution variants are 
> internal implementation details and should never be leaked through any 
> current interfaces.  It looks like most of the cases involve 
> imageUpdate() methods that should be receiving a reference to the 
> original image, not the resolution variant. These pieces of could 
> should not be changing and the fact that you had to change them points 
> out that you've created a huge compatibility issue that blocks this 
> solution.

     If someone uses the API with multi-resolution images he needs also 
update his code according to this image usage.
     It should be up to a user to preload all resolutions or only part 
of them using the MediaTracker.

     The only place where an image is replaced to a resolution variant 
and the image observer is invoked is the drawImage(Image,..,ImageObserver).

    There are 3 solutions how it can be handled:
      - Preload an image with all resolution variants. The image 
observer is not invoked in this case.
      - Using the original image in the image observer for the 
resolution variant (x,y,w,h should be rescaled).
      - Using the resolution variant in the observer

    The first one is not good solution for the ToolkitImage because it 
is designed to load asynchronously.
    The second one still  can be surprising for a user because he has 
notification that the original image has been already preloaded. Note 
that a user can do something with this image so his actions will be 
based on the image with another resolution.
    The third one provides the actual information to the user. However, 
it requires that the user update his code in the image observer.  There 
are no compatibility problems. If multi-resolution images are not used 
nothing should be changed. If they used, image observers should be 
updated accordingly.

    Thanks,
    Alexandr.

>
> On 11/21/2013 6:15 AM, Alexander Scherbatiy wrote:
>>>
>>> To check if it is "identity-ish", I'd use:
>>>     ((type & ~(TYPE_TRANSLATION | TYPE_FLIP)) == 0)
>>> To check for scale, use:
>>>     ((type & ~(TYPE_TRANSLATION | TYPE_FLIP | TYPE_SCALE_MASK)) == 0)
>>> and then the distance/hypot equations are in the final else as they 
>>> are now.
>>      Updated.
>
> The test at line 3152 is sub-optimal.  If the transform includes both 
> a SCALE and a TRANSLATE then this optimization will fail to trigger 
> and the code will fall through to the default case (which produces the 
> correct output, but misses the optimization).  Note above that I 
> include the FLIP and TRANSLATE flags in with the SCALE mask to take 
> care of this in my pseudo-code above.
>
>>>>       - Some related to the ToolkitImage staff is moved from 
>>>> SunToolkit to ToolkitImageUtil
>>>
>>> I'm not sure why this was done - it added a bunch of busy-work for 
>>> approving the webrev that I don't have time for. Hopefully someone 
>>> else can verify the cut/paste and refactoring.
>>      I have reverted it back.
>
> Thanks, it is much easier to verify what was modified now.
>
>>> I'm still not sure why it isn't just left as DEFAULT on all 
>>> platforms.  The other platforms don't even create resolution images 
>>> anyway so their default is to just use the existing image which is 
>>> fine.  We should not have platform issues affecting the default 
>>> values for hints.
>>
>>      A user can create custom MultiResolution image.  If our target 
>> is to show the resolution variant according to the current transform 
>> on all platforms then it is ok.
>
> If and when we expose the ability to create these images then the 
> developer would want them to be used on all platforms if they are 
> going to the trouble of manually creating them.  Until then the @2x 
> images are only created on MacOS anyway so the value of the hint is 
> irrelevant on other platforms.  Arguably, we might want to start 
> loading the @2x images on other platforms too, but I think we can go 
> into the 8.0 release with just MacOS support and worry about using it 
> on other platforms in an 8 update release.  In either case, the 
> default hint value should be DEFAULT.
>
>>     However, a user can create it's own MultiResolutionImage 
>> implementation. So I added the static containsResolutionVariant() 
>> method and updated
>>     necessary observers in our code. Usually the code "image!= img" 
>> is changed to "MultiResolutionImage.containsResolutionVariant(image, 
>> img)"
>
> We should not be catering to custom uses at this point until a later 
> release.
>
> If any of this code requires changes to ImageObservers then that is a 
> bug as I mentioned above.
>
>>     and x, y, width, and height values are recalculated.  The same 
>> should be done in a user's code.
>
> We should not require changes to developer's ImageObserver code to 
> support @2x.
>
>>> I was going to ask about that new method.  Why does the developer 
>>> need to manually intercede here?  They should be able to grab an 
>>> image that has an @2x variant, use MediaTracker or some other 
>>> mechanism to make sure it is loaded, then create the cursor and the 
>>> code that creates the cursor should notice the resolution variations 
>>> and deal with it on its own...
>>       Mac OS X gets a necessary image based on the current transform. 
>> A user can create its own MultiResolutionImage that contains images 
>> for the scales, for example, 0.5, 0.7, 1, 3.2.
>>       We need to know a list of all images to create the NSImage.
>
> Any code that triggers an image to load and then looks for that same 
> reference in its imageUpdate() method (which is the case in the 
> MediaTracker code) should continue to work.  That was the point I was 
> trying to make and I've reiterated this above. MediaTracker (which 
> should support @2x images without any code changes) simply makes a 
> good test case that we've handled the compatibility issues here...
>
>             ...jim



From Alan.Bateman at oracle.com  Fri Nov 22 13:24:56 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 22 Nov 2013 13:24:56 +0000
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <CA+3eh105jG=-g3czKvamJnnA_1vw5XAWM7puBKa-6caR3KAGVw@mail.gmail.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
	<528DF61B.6060403@oracle.com>
	<CA+3eh105jG=-g3czKvamJnnA_1vw5XAWM7puBKa-6caR3KAGVw@mail.gmail.com>
Message-ID: <528F5B28.7000404@oracle.com>

On 21/11/2013 15:54, Volker Simonis wrote:
> :
> But actually I've just realized that it is not need at all, because 
> 'aix_close.c' isn't in the PATH for any other OS than AIX (that could 
> be probably called a feature of the new file layout:) So I'll simply 
> change it to:
>    48 ifeq ($(OPENJDK_TARGET_OS), aix)
>    49   LIBNET_SRC_DIRS += $(JDK_TOPDIR)/src/aix/native/java/net/
>    50 endif
This make sense.


>
> Yes, exactly. I didn't wanted to change too much code. But as the 
> C-Standard states 
> (http://pubs.opengroup.org/onlinepubs/000095399/functions/malloc.html) 
> "...If size is 0, either a null pointer or a unique pointer that can 
> be successfully passed to free() shall be returned..." it is perfectly 
> legal that malloc/calloc return a NULL pointer if called with a zero 
> argument. This case is currently not handled (i.e. it's handled as an 
> 'out of memory' error) in check_code.c and I agree that this should be 
> fixed via a separate bug.
Yes, let's use a separate bug for this.



>     In net_util.c then it's a bit ugly to be calling aix_close_init.
>     Michael/Chris - what you would think about the JNI_OnLoad calling
>     into a platform specific function to do platform specific
>     initialization?
>
>
> What about renaming 'initLocalAddrTable()' into something like 
> 'platformInit()' and moving the call to 'aix_close_init' to a 
> AIX-specific version of 'platformInit()' in net_util_md.c?
I don't have a strong opinion on the name of the function, platformInit 
is fine for now.


> :
>
>
> You're right - we could rename it to something like 'java_md_unix.c'. 
> But no matter how fancy the name would be, the file would still be in 
> the 'src/solaris/bin' subdirectory:( So I think we'd better leave this 
> for a later change when we completely factor  out the Linux/Mac code 
> from the 'solaris/' directory.
I think JDK 9 is a good time to finally tackle this issue (as you 
probably know, this is something that I've brought up on porters-dev or 
build-dev a few times).


>     Port.java - one suggestion for unregisterImpl is to rename it to
>     preUnregister and change it to protected so that it's more obvious
>     that it supposed to be overridden.
>
>
> Done. Also changed the comment to JavaDoc style to be more consistent 
> with the other comments in that file.
Thanks.

>     UnixNativeDispatcher.c - this looks okay (must reduced since the
>     first round), I just wonder if the changes to *_getpwuid and
>     *_getgrgid are really needed as this just impacts the error
>     message. Also might be good to indent the #ifdef to be consistent
>     with the other usages in these functions.
>
>
> You're right. This change was done before you fixed "7043788: (fs) 
> PosixFileAttributes.owner() or group() throws NPE if owner/group not 
> in passwd/group database" 
> (http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f91c799f7bfb). After 
> you're fix it was  "automatically" adapted. I've removed the special 
> AIX handling as suggested because I think as well that another error 
> message in the exception won't have any impact.
Thanks.


> :
>
>
> I'm currently working on it and created "8028537: PPC64: Updated 
> jdk/test scripts to understand the AIX os and environment" for it 
> because I didn't wanted to blow up this change unnecessarily.
Okay.

So overall I think this patch is in good shape (I have not reviewed the 
AWT/2D/client changes in any detail) and I don't see any blocking issues 
to this going in.

-Alan



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131122/30623543/attachment.html>

From anton.nashatyrev at oracle.com  Fri Nov 22 15:24:47 2013
From: anton.nashatyrev at oracle.com (anton nashatyrev)
Date: Fri, 22 Nov 2013 19:24:47 +0400
Subject: [OpenJDK 2D-Dev] [8] Review request for 8023990: regression :
 postscript file size increase from 6u17
Message-ID: <528F773F.10104@oracle.com>

Hello,

     this is a duplicate request:

     could you please review the following fix:

fix: http://cr.openjdk.java.net/~alitvinov/8023990/webrev.00 
<http://cr.openjdk.java.net/%7Ealitvinov/8023990/webrev.00>
bug: https://bugs.openjdk.java.net/browse/JDK-8023990

      When the FcFontConfiguration was added for using fontconfig on a 
set of Linux platforms (as well as OpenSolaris) (the corresponding rfe 
is here <https://bugs.openjdk.java.net/browse/JDK-8023990>), the 
implementation of the method FcFontConfiguration.getFontDescriptors() 
returned just an empty array. This functionality is actually not used by 
anyone except of the PSPrinterJob which tries to find out whether the 
string could be represented using PS embedded font. If this procedure 
fails then the PSPrinterJob falls back to glyphs outline printing. As I 
understand this normally happened for strings containing non-ASCII 
characters. For ASCII strings PSPrinterJob usually selected the PS 
embedded font. With the addition of FcFontConfiguration even ASCII 
strings output starts to fall back to outlines.

     The fix is some basic implementation of the getFontDescriptors() 
functionality. The returned FontDecriptors don't contain missing glyph 
information. Though it might be queried from the fontconfig library 
(with some additional effort) this doesn't change the behavior of 
PSPrinterJob, since all the fonts has the ISO 10646 encoding (UTF-8), 
and the PSPrinterJob will still be falling back to outlines for any 
non-ASCII strings.

Thanks!
Anton.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131122/dd33c399/attachment.html>

From volker.simonis at gmail.com  Fri Nov 22 16:37:55 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 22 Nov 2013 17:37:55 +0100
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <528F5B28.7000404@oracle.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
	<528DF61B.6060403@oracle.com>
	<CA+3eh105jG=-g3czKvamJnnA_1vw5XAWM7puBKa-6caR3KAGVw@mail.gmail.com>
	<528F5B28.7000404@oracle.com>
Message-ID: <CA+3eh10w7sdRRpd0VjCkd7xrHLhWay+BLVhmzHmNmBT9nGVOEg@mail.gmail.com>

Hi Alan,

so I'll rename 'initLocalAddrTable()' into 'platformInit()' and move
the call to 'aix_close_init' to a AIX-specific version of
'platformInit()' in net_util_md.c as discussed.

I'll post a final webrev once I got the comments from the AWT/2D guys.

As far as I understood, you've now reviewed the 'core-lib'/'net' parts right?

That would mean that I'll still need a review from the AWT/2D and the
Security group - any volunteers:).

Once again thanks a lot for your help,
Volker


On Fri, Nov 22, 2013 at 2:24 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 21/11/2013 15:54, Volker Simonis wrote:
>
> :
> But actually I've just realized that it is not need at all, because
> 'aix_close.c' isn't in the PATH for any other OS than AIX (that could be
> probably called a feature of the new file layout:) So I'll simply change it
> to:
>
>   48 ifeq ($(OPENJDK_TARGET_OS), aix)
>   49   LIBNET_SRC_DIRS += $(JDK_TOPDIR)/src/aix/native/java/net/
>   50 endif
>
> This make sense.
>
>
>
>
> Yes, exactly. I didn't wanted to change too much code. But as the C-Standard
> states
> (http://pubs.opengroup.org/onlinepubs/000095399/functions/malloc.html)
> "...If size is 0, either a null pointer or a unique pointer that can be
> successfully passed to free() shall be returned..." it is perfectly legal
> that malloc/calloc return a NULL pointer if called with a zero argument.
> This case is currently not handled (i.e. it's handled as an 'out of memory'
> error) in check_code.c and I agree that this should be fixed via a separate
> bug.
>
> Yes, let's use a separate bug for this.
>
>
>
>
>
>>
>> In net_util.c then it's a bit ugly to be calling aix_close_init.
>> Michael/Chris - what you would think about the JNI_OnLoad calling into a
>> platform specific function to do platform specific initialization?
>>
>
> What about renaming 'initLocalAddrTable()' into something like
> 'platformInit()' and moving the call to 'aix_close_init' to a AIX-specific
> version of 'platformInit()' in net_util_md.c?
>
> I don't have a strong opinion on the name of the function, platformInit is
> fine for now.
>
>
>
> :
>
>
> You're right - we could rename it to something like 'java_md_unix.c'. But no
> matter how fancy the name would be, the file would still be in the
> 'src/solaris/bin' subdirectory:( So I think we'd better leave this for a
> later change when we completely factor  out the Linux/Mac code from the
> 'solaris/' directory.
>
> I think JDK 9 is a good time to finally tackle this issue (as you probably
> know, this is something that I've brought up on porters-dev or build-dev a
> few times).
>
>
>
>
>>
>> Port.java - one suggestion for unregisterImpl is to rename it to
>> preUnregister and change it to protected so that it's more obvious that it
>> supposed to be overridden.
>>
>
> Done. Also changed the comment to JavaDoc style to be more consistent with
> the other comments in that file.
>
> Thanks.
>
>
>
>>
>> UnixNativeDispatcher.c - this looks okay (must reduced since the first
>> round), I just wonder if the changes to *_getpwuid and *_getgrgid are really
>> needed as this just impacts the error message. Also might be good to indent
>> the #ifdef to be consistent with the other usages in these functions.
>>
>
> You're right. This change was done before you fixed "7043788: (fs)
> PosixFileAttributes.owner() or group() throws NPE if owner/group not in
> passwd/group database"
> (http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f91c799f7bfb). After you're
> fix it was  "automatically" adapted. I've removed the special AIX handling
> as suggested because I think as well that another error message in the
> exception won't have any impact.
>
> Thanks.
>
>
>
> :
>
>
> I'm currently working on it and created "8028537: PPC64: Updated jdk/test
> scripts to understand the AIX os and environment" for it because I didn't
> wanted to blow up this change unnecessarily.
>
> Okay.
>
> So overall I think this patch is in good shape (I have not reviewed the
> AWT/2D/client changes in any detail) and I don't see any blocking issues to
> this going in.
>
> -Alan
>
>
>


From james.graham at oracle.com  Sat Nov 23 01:11:16 2013
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 22 Nov 2013 17:11:16 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <528F37C2.8050907@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
	<5283D2F9.6010100@oracle.com> <528B625D.7060406@oracle.com>
	<528BFA66.7040307@oracle.com> <528E1591.90309@oracle.com>
	<528E3145.1020105@oracle.com> <528F37C2.8050907@oracle.com>
Message-ID: <529000B4.6070503@oracle.com>

Hi Alexander,

On 11/22/2013 2:53 AM, Alexander Scherbatiy wrote:
> On 11/21/2013 8:13 PM, Jim Graham wrote:
>> Hi Alexander,
>>
>> I just noticed that the new interface was created in com.sun.  I also note that you discuss a number of issues below that relate to a developer creating one of their own Multi-Resolution images.  We should not be exporting an interface at this point for a developer to do any of that.  Any use of these interfaces beyond our own internal use to support @2x images will be unsupported in JDK8 as we do not have time to properly test and expose an interface with the remaining time in the JDK8 release schedule.  This interface should be moved to the internal sun.* hierarchy until we have time to vet it.
>
>     I see that NSImage on Mac OS X has API to work with representations and has methods like addRepresentation/removeRepresentation/bestRepresentationForRect.
>
>     Does it mean that it is possible to use not only @2x images in an application but create NSImage with different images resolutions as well?
>     Should we support the same thing in Java? For example, a user wants to provide images with resolutions 0.5, 1, 2, and 3. According to the current transform the best resolution variant should be chosen.

I think we could provide that eventually, but I believe that the requests had to do with automatic support for @2x and we should focus on that.

>    The MultiResolutionImage is in com.sun* package and it still means that it can be changed or removed. It can require the CCC request, though.
>    Putting it to sun.com prevents using this feature in applets.

It doesn't prevent supplying an @2x image for an applet, but it would prevent arbitrary resolution variants through custom developer code.  I think that is OK for the late time we are at in the 8.0 release cycle.

If we are going to be advertising it as something that developers use in production code then we would need to file this via CCC.  With the current implementation, any user that has their own ImageObservers must use this API and so it becomes not only public, at a time when there is a lockdown on new public API in 8.0, but it also means that we are tied to its implementation and we can't rely on "it was experimental and so we can change it at any point" - you can't say that about an API that is necessary to correctly use a touted feature.

>    I do not see any compatibility risks with the current fix. If a user does not provide @2x images or explicitly overrides the MultiResolutionImage nothing should be changed in his code.

If a developer uses a stock Java module in their app and they hand it some @2x-enabled images then that code could fail.

If a developer creates an app and then later a graphic artist replaces its media with a new set of media that includes @2x images then the app could fail.

If an applet is deployed that uses stock imagery from its own web site and someone on the web team for that same company/organization decides to start introducing @2x media for a better web experience, then that code could fail.

And, the changes introduced represent not "new functionality" but existing behaviors that we've specified that are being violated - and violated for reasons external to that code (i.e. whether or not a particular file is found in the file system or on a web site).

Also, even if it could be attributed to something that was also fully complicit amongst all parties involved, this feature can be deployed without requiring code changes and we should do that.  The current issues with the image being returned in imageUpdate are avoidable, inconvenient, and in violation of the existing drawImage/ImageObserver contract.

>    The time testing of this API is the same as testing TollkitImages that can hold @2x images.
>    We also will have the feedback about these API earlier.  It is better than introducing a public API in next release that will be difficult to change.

Release cycles have vetting of new public API built in to their scheduling in a responsible manner.  An 11th hour sudden introduction of a new API, especially one that is necessary for some developers to use a new feature, is a lot more irresponsible.

>> All of the places that call containsResolutionVariant() are pointing out a bug with this implementation.  The resolution variants are internal implementation details and should never be leaked through any current interfaces.  It looks like most of the cases involve imageUpdate() methods that should be receiving a reference to the original image, not the resolution variant. These pieces of could should not be changing and the fact that you had to change them points out that you've created a huge compatibility issue that blocks this solution.
>
>      If someone uses the API with multi-resolution images he needs also update his code according to this image usage.

First, their "use" of the new feature is not a code change, it is the appearance of a new file in their deployment, or on a web site that they tried to access.  There isn't as much explicit intent there as you are making it out to be.

>      It should be up to a user to preload all resolutions or only part of them using the MediaTracker.

(And, btw, I didn't see MediaTracker on the list of places that were changed to be aware of the new images.  Also, the prepareImage/checkImage methods that MT uses to trigger loading weren't necessarily up to the task of preloading the necessary image variants.)

>      The only place where an image is replaced to a resolution variant and the image observer is invoked is the drawImage(Image,..,ImageObserver).

Component.prepareImage() and Component.checkImage() are also intended to trigger and track the loading of the required representation of an image for the indicated Component.

>     There are 3 solutions how it can be handled:
>       - Preload an image with all resolution variants. The image observer is not invoked in this case.
>       - Using the original image in the image observer for the resolution variant (x,y,w,h should be rescaled).
>       - Using the resolution variant in the observer
>
>     The first one is not good solution for the ToolkitImage because it is designed to load asynchronously.

Agreed.

>     The second one still  can be surprising for a user because he has notification that the original image has been already preloaded. Note that a user can do something with this image so his actions will be based on the image with another resolution.

It would be far less surprising than the third option which starts to mention an image that he never interacted with.

It would also be similar to the behavior in 1.0 where we could asynchronously reload the image in order to perform simple scaling on it.  In other words, this may be outdated behavior, but it is not new behavior.

>     The third one provides the actual information to the user. However, it requires that the user update his code in the image observer.  There are no compatibility problems. If multi-resolution images are not used nothing should be changed. If they used, image observers should be updated accordingly.

The fact that it requires the user to update his code to avoid bugs is a non-starter.  It means that they have work to do to use @2x images, they can't just install the new files into their deployment.  It means that they will experience all sorts of "left hand didn't coordinate with right hand" issues in their deployment and testing as often media is managed by a different team than the code.  It also means we are exposing an internal implementation detail rather than making it "just work".  It also means that we are explicitly violating a long-standing API contract in a way that directly impacts them.

The added information is not required for them to use the image and is of questionable value given that the interactions they make with the image are based on the design space of the unscaled variant - information relative to a scaled variant then requires a bit of work for them to use.  We may want to provide this information at some point, but for now we should not be introducing new behavior to a really old API contract...

			...jim


From alexandr.scherbatiy at oracle.com  Mon Nov 25 13:51:44 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 25 Nov 2013 17:51:44 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529000B4.6070503@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
	<5283D2F9.6010100@oracle.com> <528B625D.7060406@oracle.com>
	<528BFA66.7040307@oracle.com> <528E1591.90309@oracle.com>
	<528E3145.1020105@oracle.com> <528F37C2.8050907@oracle.com>
	<529000B4.6070503@oracle.com>
Message-ID: <529355F0.4040506@oracle.com>



   Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8011059/webrev.10/

  - FLIP and TRANSLATE bit masks are also included for the SCALE 
transform checking

  - LWCToolkit checks an image in cache before requesting 
multi-resolution image creation to prevent excessive string manipulation.
    It needs to make imgCache accessible from the LWCToolkit or move 
image2x staff calculation to the SunToolkit to use the right 
synchronization.
    imgCache is not created per Application context so there can be 
issues to make it protected. The image2x staff does not relate to 
SunToolkit.
    That is why all staff related to ToolkitImage creation used to move 
into ToolkitImageUtil in some previous fix. I just skipped the 
synchronization for this particular case.

  - The containsResolutionVariant method is removed from the 
MultiResolutionImage

  - The image observer is nullified in drawImage(Image,..ImageObserver) 
method for the resolution variant.
    The original image is always loaded because it needs to know the 
image width and height for the resolution variant size calculation.
     Only the original image sends notifications that an image is 
loaded. The resolution variant is drawn silently so it does not break 
existed image observer implementation.

On 11/23/2013 5:11 AM, Jim Graham wrote:
> Hi Alexander,
>
> If we are going to be advertising it as something that developers use 
> in production code then we would need to file this via CCC. With the 
> current implementation, any user that has their own ImageObservers 
> must use this API and so it becomes not only public, at a time when 
> there is a lockdown on new public API in 8.0, but it also means that 
> we are tied to its implementation and we can't rely on "it was 
> experimental and so we can change it at any point" - you can't say 
> that about an API that is necessary to correctly use a touted feature.

     This issue has its own history.  It has been already fixed for the 
JDK 7u for the Java2D demo. It was decided to not bring new API for the 
HiDPI support in the JDK 7.
     It was suggested to using code like below to create a ScalableImage.
------------------------------
/**
  * Class that loads and returns images according to
  * scale factor of graphic device
  *
  *  <pre> {@code
  *    Image image = new ScalableImage() {
  *
  *        public Image createScaledImage(float scaleFactor) {
  *            return (scaleFactor <= 1) ? loadImage("image.png")
  *                : loadImage("image at 2x.png");
  *        }
  *
  *        Image loadImage(String name){
  *            // load image
  *        }
  *    };}</pre>
  */
------------------------------

  It was based on the display scale factor. The scale factor should be 
manually retrieved from the Graphics2D and was not a part of the public API:
  g2d.drawImage(scalbleImage.getScaledImage(scaleFactor),..).

  From that time it was clear that there should be 2 basic operations 
for the HiDPI images support:
   - retrieve an image with necessary resolution
   - retrieve images with all resolutions

   The second one is useful when it is necessary to create one set of 
images using the given one (for example, to draw a shape on all images).

   The JDK 7 solution has been revisited for the JDK 8 and the neccesary 
CCC request 8011059  has been created and approved.

   Both the JDK-8011059 issue description and the approved CCC request says:
   -----------------------
   A user should have a unified way to provide high resolution images 
that can be drawn on HIDPI displays according to the user provided 
algorithm.
   -----------------------

   The 8011059 fix consists of two parts:
   - Provide a way for a custom image creation that holds images with 
different resolutions
   - Load @2x images on Mac OS X

   The first one of the fix can be used without the second. it is not 
difficult to crate just a class which loads @2x images using the given 
file path/url.

   Now it is suggested to implement the given MultiResolutionImage 
interface  and override two methods:
    - Image getResolutionVariant(int width, int height)
    - List<Image> getResolutionVariants()

    An image with necessary resolution should be drawn automatically in 
SunGraphics2D.

   What we need is to focus on the first part of the fix.
   From this point of view it up to the user' code to load all or some 
resolution variants by MediaTracker and using 
Component.prepareImage/checkImage methods.

   Thanks,
   Alexandr.


>
>>    I do not see any compatibility risks with the current fix. If a 
>> user does not provide @2x images or explicitly overrides the 
>> MultiResolutionImage nothing should be changed in his code.
>
> If a developer uses a stock Java module in their app and they hand it 
> some @2x-enabled images then that code could fail.
>
> If a developer creates an app and then later a graphic artist replaces 
> its media with a new set of media that includes @2x images then the 
> app could fail.
>
> If an applet is deployed that uses stock imagery from its own web site 
> and someone on the web team for that same company/organization decides 
> to start introducing @2x media for a better web experience, then that 
> code could fail.
>
> And, the changes introduced represent not "new functionality" but 
> existing behaviors that we've specified that are being violated - and 
> violated for reasons external to that code (i.e. whether or not a 
> particular file is found in the file system or on a web site).
>
> Also, even if it could be attributed to something that was also fully 
> complicit amongst all parties involved, this feature can be deployed 
> without requiring code changes and we should do that. The current 
> issues with the image being returned in imageUpdate are avoidable, 
> inconvenient, and in violation of the existing drawImage/ImageObserver 
> contract.
>
>>    The time testing of this API is the same as testing TollkitImages 
>> that can hold @2x images.
>>    We also will have the feedback about these API earlier.  It is 
>> better than introducing a public API in next release that will be 
>> difficult to change.
>
> Release cycles have vetting of new public API built in to their 
> scheduling in a responsible manner.  An 11th hour sudden introduction 
> of a new API, especially one that is necessary for some developers to 
> use a new feature, is a lot more irresponsible.
>
>>> All of the places that call containsResolutionVariant() are pointing 
>>> out a bug with this implementation.  The resolution variants are 
>>> internal implementation details and should never be leaked through 
>>> any current interfaces.  It looks like most of the cases involve 
>>> imageUpdate() methods that should be receiving a reference to the 
>>> original image, not the resolution variant. These pieces of could 
>>> should not be changing and the fact that you had to change them 
>>> points out that you've created a huge compatibility issue that 
>>> blocks this solution.
>>
>>      If someone uses the API with multi-resolution images he needs 
>> also update his code according to this image usage.
>
> First, their "use" of the new feature is not a code change, it is the 
> appearance of a new file in their deployment, or on a web site that 
> they tried to access.  There isn't as much explicit intent there as 
> you are making it out to be.
>
>>      It should be up to a user to preload all resolutions or only 
>> part of them using the MediaTracker.
>
> (And, btw, I didn't see MediaTracker on the list of places that were 
> changed to be aware of the new images.  Also, the 
> prepareImage/checkImage methods that MT uses to trigger loading 
> weren't necessarily up to the task of preloading the necessary image 
> variants.)
>
>>      The only place where an image is replaced to a resolution 
>> variant and the image observer is invoked is the 
>> drawImage(Image,..,ImageObserver).
>
> Component.prepareImage() and Component.checkImage() are also intended 
> to trigger and track the loading of the required representation of an 
> image for the indicated Component.
>
>>     There are 3 solutions how it can be handled:
>>       - Preload an image with all resolution variants. The image 
>> observer is not invoked in this case.
>>       - Using the original image in the image observer for the 
>> resolution variant (x,y,w,h should be rescaled).
>>       - Using the resolution variant in the observer
>>
>>     The first one is not good solution for the ToolkitImage because 
>> it is designed to load asynchronously.
>
> Agreed.
>
>>     The second one still  can be surprising for a user because he has 
>> notification that the original image has been already preloaded. Note 
>> that a user can do something with this image so his actions will be 
>> based on the image with another resolution.
>
> It would be far less surprising than the third option which starts to 
> mention an image that he never interacted with.
>
> It would also be similar to the behavior in 1.0 where we could 
> asynchronously reload the image in order to perform simple scaling on 
> it.  In other words, this may be outdated behavior, but it is not new 
> behavior.
>
>>     The third one provides the actual information to the user. 
>> However, it requires that the user update his code in the image 
>> observer.  There are no compatibility problems. If multi-resolution 
>> images are not used nothing should be changed. If they used, image 
>> observers should be updated accordingly.
>
> The fact that it requires the user to update his code to avoid bugs is 
> a non-starter.  It means that they have work to do to use @2x images, 
> they can't just install the new files into their deployment.  It means 
> that they will experience all sorts of "left hand didn't coordinate 
> with right hand" issues in their deployment and testing as often media 
> is managed by a different team than the code.  It also means we are 
> exposing an internal implementation detail rather than making it "just 
> work".  It also means that we are explicitly violating a long-standing 
> API contract in a way that directly impacts them.
>
> The added information is not required for them to use the image and is 
> of questionable value given that the interactions they make with the 
> image are based on the design space of the unscaled variant - 
> information relative to a scaled variant then requires a bit of work 
> for them to use.  We may want to provide this information at some 
> point, but for now we should not be introducing new behavior to a 
> really old API contract...
>
>             ...jim



From patrick at reini.net  Mon Nov 25 14:48:28 2013
From: patrick at reini.net (Patrick Reinhart)
Date: Mon, 25 Nov 2013 15:48:28 +0100
Subject: [OpenJDK 2D-Dev] JDK-7107175 - Paper tray handling
In-Reply-To: <528E93FA.4010900@oracle.com>
References: <27AA49C8-B6A9-4B22-853D-4B8DC65339E0@reini.net>
	<528E846A.1020001@oracle.com>
	<C133212A-4896-4836-87A1-7CFC7399D9A5@reini.net>
	<528E93FA.4010900@oracle.com>
Message-ID: <5293633C.2090205@reini.net>

On 22.11.2013 00:15, Phil Race wrote:
> The other problem you mention is largely if not entirely because IPP 
> lumped
>>> trays along with papers as being "Media".
>>>
>>> See http://tools.ietf.org/html/rfc2566#section-4.2.11
>>>
>>>    If a Printer object supports a medium name as a value of this
>>>    attribute, such a medium name implicitly selects an input-tray that
>>>    contains the specified medium.  If a Printer object supports a 
>>> medium
>>>    size as a value of this attribute, such a medium size implicitly
>>>    selects a medium name that in turn implicitly selects an input-tray
>>>    that contains the medium with the specified size.  If a Printer
>>>    object supports an input-tray as the value of this attribute, 
>>> such an
>>>    input-tray implicitly selects the medium that is in that input-tray
>>>    at the time the job prints.
>>>
>> If I understand this correct, that means it should be possible to 
>> just define a MediaTray without a MediaSizeName then right? But in my 
>> environment the default MediaSizeName is set to Letter even though 
>> the current PrintService would define A4 as the default.
>
> I see a line in RasterPrinterJob.java which might cause that to happen 
> if you specify
> a tray and no paper but that seems like its a bug. It should always be 
> the default for the current
> printer unless I'm forgetting something we had to do for backwards 
> compatibility.
>
Do you mean this lines starting at 562:

         Media media = (Media)attSet.get(Media.class);
         if (media == null) {
             media =
(Media)service.getDefaultAttributeValue(Media.class);
         }
         if (!(media instanceof MediaSizeName)) {
             media = MediaSizeName.NA_LETTER;
         }

This would replace a set MediaTray from the attribute set with the 
MediaSizeName.NA_LETTER right? A would sugest to change the lines to 
something like this:

         Media media = (Media)attSet.get(Media.class);
         if (media == null) {
             media =
(Media)service.getDefaultAttributeValue(Media.class);
             if (media == null) {
                 media = MediaSizeName.NA_LETTER;
             }
         }

This would fall back to letter in case of a non default definition of a 
media size name and no such is defined within the request attributes...

>> If I compare the basic behavior in comparison to the Windows 
>> implementation. The are some differences in setting the default 
>> MediaSize and MediaSizeName. Those will be not initialized in the 
>> Windows world and taken from the current PrintService in case it's 
>> not set via PrintRequestAttributeSet.
>>
>>
>>> I can see no way around this other than defining an new attribute 
>>> class that doesn't
>>> subclass Media and duplicates MediaTray .. but then you'd also need 
>>> to say what happens
>>> if someone specifies two different trays, one by each means.
>>>
>> I do not completely understand what you mean. Do you mean the use 
>> case if one specifies A4,Tray2 but Tray2 contains Letter?
>
> I meant that if we provided a new class "MediaSource" you could 
> specify MediaSource.TRAY1
> whilst still specifying for "Media" an instance of the subclass 
> MediaTray that corresponded
> to TRAY2. That's an API solution that doesn't seem likely any time soon.
I always thought that the MediaTray does specify the source already as 
it says in the JavaDoc:

"*IPP Compatibility:* MediaTray is a representation class for values of 
the IPP "media" attribute which name paper trays. "

In newer Printer there is also the possibility to specify the output 
tray as well but for this there is no specific definition within the spec.

Cheers

Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131125/f3eed92d/attachment.html>

From artem.ananiev at oracle.com  Mon Nov 25 15:52:03 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 25 Nov 2013 19:52:03 +0400
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
Message-ID: <52937223.408@oracle.com>

Hi, Volker,

just a few very minor comments about the client changes:

1. mlib_sys.c: the change is fine, but it makes the following comment 
obsolete.

2. XRBackendNative.c: the same comment here.

3. Awt2dLibraries.gmk: $(JDK_TOPDIR)/src/aix/porting/porting_aix.c would 
be better than just porting_aix.c

Thanks,

Artem

On 11/20/2013 10:26 PM, Volker Simonis wrote:
> Hi,
>
> this is the second review round for "8024854: Basic changes and files to
> build the class library on AIX
> <https://bugs.openjdk.java.net/browse/JDK-8024854>". The previous
> reviews can be found at the end of this mail in the references section.
>
> I've tried to address all the comments and suggestions from the first
> round and to further streamline the patch (it perfectly builds on
> Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The
> biggest change compared to the first review round is the new "aix/"
> subdirectory which I've now created under "jdk/src" and which contains
> AIX-only code.
>
> The webrev is against our http://hg.openjdk.java.net/ppc-aix-port/stage
> repository which has been recently synchronised with the jdk8 master:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/
>
> Below (and in the webrev) you can find some comments which explain the
> changes to each file. In order to be able to push this big change, I
> need the approval of reviewers from the lib, net, svc, 2d, awt and sec
> groups. So please don't hesitate to jump at it - there are enough
> changes for everybody:)
>
> Thank you and best regards,
> Volker
>
> *References:*
>
> The following reviews have been posted so far (thanks Iris for
> collecting them :)
>
> - Alan Bateman (lib): Initial comments (16 Sep [2])
> - Chris Hegarty (lib/net): Initial comments (20 Sep [3])
> - Michael McMahon (net): Initial comments (20 Sept [4])
> - Steffan Larsen (svc): APPROVED (20 Sept [5])
> - Phil Race (2d): Initial comments  (18 Sept [6]); Additional comments
> (15 Oct [7])
> - Sean Mullan (sec): Initial comments (26 Sept [8])
>
> [2]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html
> [3]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html
> [4]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html
> [5]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html
> [6]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html
> [7]: http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html
> [8]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html
>
>
> *Detailed change description:*
>
> The new "jdk/src/aix" subdirectory contains the following new and
> AIX-specific files for now:
>
>   src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>   src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java
>   src/aix/classes/sun/nio/ch/AixPollPort.java
>   src/aix/classes/sun/nio/fs/AixFileStore.java
>   src/aix/classes/sun/nio/fs/AixFileSystem.java
>   src/aix/classes/sun/nio/fs/AixFileSystemProvider.java
>   src/aix/classes/sun/nio/fs/AixNativeDispatcher.java
>   src/aix/classes/sun/tools/attach/AixAttachProvider.java
>   src/aix/classes/sun/tools/attach/AixVirtualMachine.java
>   src/aix/native/java/net/aix_close.c
>   src/aix/native/sun/nio/ch/AixPollPort.c
>   src/aix/native/sun/nio/fs/AixNativeDispatcher.c
>   src/aix/native/sun/tools/attach/AixVirtualMachine.c
>   src/aix/porting/porting_aix.c
>   src/aix/porting/porting_aix.h
>
>
>         src/aix/porting/porting_aix.c
>         src/aix/porting/porting_aix.h
>
>   * Added these two files for AIX relevant utility code.
>   * Currently these files only contain an implementation of |dladdr|
>     which is not available on AIX.
>   * In the first review round the existing |dladdr| users in the code
>     either called the version from the HotSpot on AIX
>     (|src/solaris/native/sun/awt/awt_LoadLibrary.c|) or had a private
>     copy of the whole implementation
>     (|src/solaris/demo/jvmti/hprof/hprof_md.c|). This is now not
>     necessary any more.
>
> The new file layout required some small changes to the makefiles to make
> them aware of the new directory locations:
>
>
>         makefiles/CompileDemos.gmk
>
>   * Add an extra argument to |SetupJVMTIDemo| which can be used to pass
>     additional source locations.
>   * Currently this is only used on AIX for the AIX porting utilities
>     which are required by hprof.
>
>
>         makefiles/lib/Awt2dLibraries.gmk
>         makefiles/lib/ServiceabilityLibraries.gmk
>
>   * On AIX add the sources of the AIX porting utilities to the build.
>     They are required by |src/solaris/native/sun/awt/awt_LoadLibrary.c|
>     and |src/solaris/demo/jvmti/hprof/hprof_md.c| because |dladdr| is
>     not available on AIX.
>
>
>         makefiles/lib/NioLibraries.gmk
>
>   * Make the AIX-build aware of the new NIO source locations under
>     |src/aix/native/sun/nio/|.
>
>
>         makefiles/lib/NetworkingLibraries.gmk
>
>   * Make the AIX-build aware of the new |aix_close.c| source location
>     under |src/aix/native/java/net/|.
>
>
>         src/share/bin/jli_util.h
>
>   * Define |JLI_Lseek| on AIX.
>
>
>         src/share/lib/security/java.security-aix
>
>   * Provide default |java.security-aix| for AIX based on the latest
>     Linux version as suggested by Sean Mullan.
>
>
>         src/share/native/common/check_code.c
>
>   * On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is
>     legal, but the code in |check_code.c| does not handles this
>     properly. So we wrap the two methods on AIX and return a non-NULL
>     pointer even if we allocate 0 bytes.
>
>
>         src/share/native/sun/awt/medialib/mlib_sys.c
>
>   * |malloc| always returns 8-byte aligned pointers on AIX as well.
>
>
>         src/share/native/sun/awt/medialib/mlib_types.h
>
>   * Add AIX to the list of known platforms.
>
>
>         src/share/native/sun/font/layout/KernTable.cpp
>
>   * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| is
>     too common and may be defined in other headers as well as on the
>     command line and |xlc| bails out on macro redefinitions with a
>     different value.
>
>
>         src/share/native/sun/security/ec/impl/ecc_impl.h
>
>   * Define required types and macros on AIX.
>
>
>         src/solaris/back/exec_md.c
>
>   * AIX behaves like Linux in this case so check for it in the Linux branch.
>
>
>         src/solaris/bin/java_md_solinux.c,
>         src/solaris/bin/java_md_solinux.h
>
>   * On AIX |LD_LIBRARY_PATH| is called |LIBPATH|
>   * Always use |LD_LIBRARY_PATH| macro instead of using the string
>     "|LD_LIBRARY_PATH|" directly to cope with different library path names.
>   * Add |jre/lib/<arch>/jli| to the standard library search path on AIX
>     because the AIX linker doesn't support the |-rpath| option.
>   * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in this
>     case, AIX behaves like Linux.
>   * Removed the definition of |JVM_DLL|, |JAVA_DLL| and
>     |LD_LIBRARY_PATH| from |java_md_solinux.h| because the macros are
>     redefined in the corresponding |.c| files anyway.
>
>
>         src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>
>   * Provide basic |fontconfig.properties|for AIX.
>
>
>         src/solaris/classes/java/lang/UNIXProcess.java.aix,
>         src/aix/classes/sun/tools/attach/AixAttachProvider.java,
>         src/aix/classes/sun/tools/attach/AixVirtualMachine.java,
>         src/aix/native/sun/tools/attach/AixVirtualMachine.c
>
>   * Provide AIX specific Java versions, mostly based on the
>     corresponding Linux versions.
>
>
>         src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java
>         src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java
>
>   * Detect AIX operating system and return the corresponding channel and
>     file system providers.
>
>
>         src/solaris/classes/sun/nio/ch/Port.java
>
>   * Add a callback function |unregisterImpl(int fd)| for implementations
>     that need special handling when |fd| is removed and call it from
>     |unregister(int fd)|. By default the implementation of
>     |unregisterImpl(int fd)| is empty except for the derived
>     |AixPollPort| class on AIX.
>
>
>         src/solaris/demo/jvmti/hprof/hprof_md.c
>
>   * Add AIX support. AIX mostly behaves like Linux, with the one
>     exception that it has no |dladdr| functionality.
>   * Use the |dladdr| implementation from |porting_aix.{c,h}| on AIX.
>
>
>         src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>
>   * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory).
>
>
>         src/solaris/native/common/jdk_util_md.h
>
>   * Add AIX definitions of the |ISNANF| and |ISNAND| macros.
>
>
>         src/solaris/native/java/io/io_util_md.c
>
>   * AIX behaves like Linux in this case so check for it in the Linux branch.
>
>
>         src/solaris/native/java/lang/UNIXProcess_md.c
>
>   * AIX behaves mostly like Solraris in this case so adjust the ifdefs
>     accordingly.
>
>
>         src/solaris/native/java/lang/childproc.c
>
>   * AIX does not understand '/proc/self' - it requires the real process
>     ID to query the proc file system for the current process.
>
>
>         src/solaris/native/java/net/NetworkInterface.c
>
>   * Add AIX support into the Linux branch because AIX mostly behaves
>     like AIX for IPv4.
>   * AIX needs a special function to enumerate IPv6 interfaces and to
>     query the MAC address.
>   * Moved the declaration of |siocgifconfRequest| to the beginning a the
>     function (as recommend by Michael McMahon) to remain C89 compatible.
>
>
>         src/solaris/native/java/net/PlainSocketImpl.c
>
>   * On AIX (like on Solaris) |setsockopt| will set errno to |EINVAL| if
>     the socket is closed. The default error message is then confusing.
>
>
>         src/aix/native/java/net/aix_close.c,
>         src/share/native/java/net/net_util.c
>
>   * As recommended by Michael McMahon and Alan Bateman I've move an
>     adapted version of |linux_close.c| to
>     |src/aix/native/java/net/aix_close.c| because we also need the file
>     and socket wrappers on AIX.
>   * Compared to the Linux version, we've added the initialization of
>     some previously uninitialized data structures.
>   * Also, on AIX we don't have |__attribute((constructor))| so we need
>     to initialize manually (from |JNI_OnLoad()| in
>     |src/share/native/java/net/net_util.c|.
>
>
>         src/solaris/native/java/net/net_util_md.h
>
>   * AIX needs the same workaround for I/O cancellation like Linux and
>     MacOSX.
>
>
>         src/solaris/native/java/net/net_util_md.c
>
>   * |SO_REUSEADDR| is called |SO_REUSEPORT| on AIX.
>   * On AIX we have to ignore failures due to |ENOBUFS| when setting the
>     |SO_SNDBUF|/|SO_RCVBUF| socket options.
>
>
>         src/solaris/native/java/util/TimeZone_md.c
>
>   * Currently on AIX the only way to get the platform time zone is to
>     read it from the |TZ| environment variable.
>
>
>         src/solaris/native/sun/awt/awt_LoadLibrary.c
>
>   * Use the |dladdr| from |porting_aix.{c,h}| on AIX.
>
>
>         src/solaris/native/sun/awt/fontpath.c
>
>   * Changed some macros from |if !defined(__linux__)| to |if
>     defined(__solaris__)| because that's their real meaning.
>   * Add AIX specific fontpath settings and library search paths for
>     |libfontconfig.so|.
>
>
>         src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>
>   * Rename the |MIN| and |MAX| macros to |XSD_MIN| and |XSD_MAX| to
>     avoid name clashes (|MIN| and |MAX| are much too common and thexy
>     are already defined in some AIX system headers).
>
>
>         src/solaris/native/sun/java2d/x11/XRBackendNative.c
>
>   * Handle AIX like Solaris.
>
>
>         src/solaris/native/sun/nio/ch/Net.c
>
>   * Add AIX-specific includes and constant definitions.
>   * On AIX "socket extensions for multicast source filters" support
>     depends on the OS version. Check for this and throw appropriate
>     exceptions if it is requested but not supported. This is needed to
>     pass
>     JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast
>
>
>         src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
>
>   * On AIX |strerror()| is not thread-safe so we have to use
>     |strerror_r()| instead.
>   * On AIX |readdir_r()| returns EBADF (i.e. '9') and sets 'result' to
>     NULL for the directory stream end. Otherwise, 'errno' will contain
>     the error code.
>   * Handle some AIX corner cases for the results of the |statvfs64()| call.
>   * On AIX |getgrgid_r()| returns ESRCH if group does not exist.
>
>
>         src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>
>   * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX.
>
>
>         test/java/lang/ProcessBuilder/Basic.java
>         test/java/lang/ProcessBuilder/DestroyTest.java
>
>   * Port this test to AIX and make it more robust (i.e. recognize the
>     "C" locale as |isEnglish()|, ignore VM-warnings in the output, make
>     sure the "grandchild" processes created by the test don't run too
>     long (60s vs. 6666s) because in the case of test problems these
>     processes will pollute the process space, make sure the test fails
>     with an error and doesn't hang indefinitley in the case of a problem).
>
> *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this
> intended?
>
> Well, |_AIX| is defined in some system headers while |AIX| is defined by
> the build system. This is already used inconsistently (i.e. |__linux__|
> vs. |LINUX|) and in general I try to be consistent with the style of the
> file where I the changes are. That said, I changes most of the
> occurences of |AIX| to |_AIX|.
>
> *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are
> they supposed to be there?
>
> We currently don't support OS/400 (later renamed into i5/OS and
> currently called IBM i) in our OpenJDK port but we do support it in our
> internel, SAP JVM build. We stripped out all the extra OS/400
> functionality from the port but in some places where there is common
> functionality needd by both, AIX and OS/400 the OS/400 support may still
> be visible in the OpenJDK port. I don't think this is a real problem and
> it helps us to keep our internel sources in sync with the OpenJDK port.
> That said, I think I've removed all the references to OS/400 now.
>
>


From philip.race at oracle.com  Mon Nov 25 17:16:41 2013
From: philip.race at oracle.com (Phil Race)
Date: Mon, 25 Nov 2013 09:16:41 -0800
Subject: [OpenJDK 2D-Dev] JDK-7107175 - Paper tray handling
In-Reply-To: <5293633C.2090205@reini.net>
References: <27AA49C8-B6A9-4B22-853D-4B8DC65339E0@reini.net>
	<528E846A.1020001@oracle.com>
	<C133212A-4896-4836-87A1-7CFC7399D9A5@reini.net>
	<528E93FA.4010900@oracle.com> <5293633C.2090205@reini.net>
Message-ID: <529385F9.1000106@oracle.com>

On 11/25/2013 6:48 AM, Patrick Reinhart wrote:
> If I understand this correct, that means it should be possible to just 
> define a MediaTray without a MediaSizeName then right? But in my 
> environment the default MediaSizeName is set to Letter even though the 
> current PrintService would define A4 as the default.
>>
>> I see a line in RasterPrinterJob.java which might cause that to 
>> happen if you specify
>> a tray and no paper but that seems like its a bug. It should always 
>> be the default for the current
>> printer unless I'm forgetting something we had to do for backwards 
>> compatibility.
>>
> Do you mean this lines starting at 562:

Yes. That's what I saw from a very quick (< 1 min) look at the sources.
>
>         Media media = (Media)attSet.get(Media.class);
>         if (media == null) {
>             media =
> (Media)service.getDefaultAttributeValue(Media.class);
>         }
>         if (!(media instanceof MediaSizeName)) {
>             media = MediaSizeName.NA_LETTER;
>         }
>
> This would replace a set MediaTray from the attribute set with the 
> MediaSizeName.NA_LETTER right? 

Yes, looks like a bug to me.

> A would sugest to change the lines to something like this:
>
>         Media media = (Media)attSet.get(Media.class);
>         if (media == null) {
>             media =
> (Media)service.getDefaultAttributeValue(Media.class);
>             if (media == null) {
>                 media = MediaSizeName.NA_LETTER;
>             }
>         }
>
> This would fall back to letter in case of a non default definition of 
> a media size name and no such is defined within the request attributes...

Not sure. Need to look at the wider context. The code here seems to be 
expecting MediaSizeName.
I'd need to look deeper and I don't have time.

>
>>> If I compare the basic behavior in comparison to the Windows 
>>> implementation. The are some differences in setting the default 
>>> MediaSize and MediaSizeName. Those will be not initialized in the 
>>> Windows world and taken from the current PrintService in case it's 
>>> not set via PrintRequestAttributeSet.
>>>
>>>
>>>> I can see no way around this other than defining an new attribute 
>>>> class that doesn't
>>>> subclass Media and duplicates MediaTray .. but then you'd also need 
>>>> to say what happens
>>>> if someone specifies two different trays, one by each means.
>>>>
>>> I do not completely understand what you mean. Do you mean the use 
>>> case if one specifies A4,Tray2 but Tray2 contains Letter?
>>
>> I meant that if we provided a new class "MediaSource" you could 
>> specify MediaSource.TRAY1
>> whilst still specifying for "Media" an instance of the subclass 
>> MediaTray that corresponded
>> to TRAY2. That's an API solution that doesn't seem likely any time soon.
> I always thought that the MediaTray does specify the source already as 
> it says in the JavaDoc:

It does specify the source, but as I've already twice tried to make 
clear, with present API
you cannot simultaneously specify the size which is what I thought you 
were raising as
the main issue.

I am guessing that IPP took the view that if you specify the tray that 
implied a paper size,
and if you could specify both, you could over-constrain the requirements,
eg requesting a paper size from a tray that didn't support that paper size.

-phil.

>
> "*IPP Compatibility:* MediaTray is a representation class for values 
> of the IPP "media" attribute which name paper trays. "
>
> In newer Printer there is also the possibility to specify the output 
> tray as well but for this there is no specific definition within the spec.
>
> Cheers
>
> Patrick 



From philip.race at oracle.com  Mon Nov 25 17:44:45 2013
From: philip.race at oracle.com (philip.race at oracle.com)
Date: Mon, 25 Nov 2013 17:44:45 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 8028722: Render: Drawing strings
	with exactly 254	glyphs causes hangs
Message-ID: <20131125174557.D6C246281D@hg.openjdk.java.net>

Changeset: c7b0f01e2268
Author:    ceisserer
Date:      2013-11-25 09:38 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c7b0f01e2268

8028722: Render: Drawing strings with exactly 254 glyphs causes hangs
Reviewed-by: prr, bae

! src/solaris/classes/sun/font/XRTextRenderer.java
+ test/java/awt/Graphics2D/DrawString/XRenderElt254TextTest.java



From jennifer.godinez at oracle.com  Mon Nov 25 20:43:18 2013
From: jennifer.godinez at oracle.com (Jennifer Godinez)
Date: Mon, 25 Nov 2013 12:43:18 -0800
Subject: [OpenJDK 2D-Dev] Please review JDK-8028584
Message-ID: <5293B666.4020407@oracle.com>

http://cr.openjdk.java.net/~jgodinez/8028584/webrev.00/

ClassCastException occurs when device uri is a file.  Added a check for 
file and additional safeguard against cast exception.

Jennifer


From patrick at reini.net  Mon Nov 25 21:27:49 2013
From: patrick at reini.net (Patrick Reinhart)
Date: Mon, 25 Nov 2013 22:27:49 +0100
Subject: [OpenJDK 2D-Dev] JDK-7107175 - Paper tray handling
In-Reply-To: <529385F9.1000106@oracle.com>
References: <27AA49C8-B6A9-4B22-853D-4B8DC65339E0@reini.net>
	<528E846A.1020001@oracle.com>
	<C133212A-4896-4836-87A1-7CFC7399D9A5@reini.net>
	<528E93FA.4010900@oracle.com> <5293633C.2090205@reini.net>
	<529385F9.1000106@oracle.com>
Message-ID: <7385180E-1888-4A4A-8633-76F20ECD7CC2@reini.net>


Am 25.11.2013 um 18:16 schrieb Phil Race <philip.race at oracle.com>:

> On 11/25/2013 6:48 AM, Patrick Reinhart wrote:
>> If I understand this correct, that means it should be possible to just define a MediaTray without a MediaSizeName then right? But in my environment the default MediaSizeName is set to Letter even though the current PrintService would define A4 as the default.
>>> 
>>> I see a line in RasterPrinterJob.java which might cause that to happen if you specify
>>> a tray and no paper but that seems like its a bug. It should always be the default for the current
>>> printer unless I'm forgetting something we had to do for backwards compatibility.
>>> 
>> Do you mean this lines starting at 562:
> 
> Yes. That's what I saw from a very quick (< 1 min) look at the sources.
>> 
>>        Media media = (Media)attSet.get(Media.class);
>>        if (media == null) {
>>            media =
>> (Media)service.getDefaultAttributeValue(Media.class);
>>        }
>>        if (!(media instanceof MediaSizeName)) {
>>            media = MediaSizeName.NA_LETTER;
>>        }
>> 
>> This would replace a set MediaTray from the attribute set with the MediaSizeName.NA_LETTER right? 
> 
> Yes, looks like a bug to me.
> 
>> A would sugest to change the lines to something like this:
>> 
>>        Media media = (Media)attSet.get(Media.class);
>>        if (media == null) {
>>            media =
>> (Media)service.getDefaultAttributeValue(Media.class);
>>            if (media == null) {
>>                media = MediaSizeName.NA_LETTER;
>>            }
>>        }
>> 
>> This would fall back to letter in case of a non default definition of a media size name and no such is defined within the request attributes...
> 
> Not sure. Need to look at the wider context. The code here seems to be expecting MediaSizeName.
> I'd need to look deeper and I don't have time.

I will take a closer look into that and do some more investigations. As I saw already that it seems that the MediaSizeName is mainly needed to setup to correct paper size.  I thank you anyway for your help so far.

>>>> If I compare the basic behavior in comparison to the Windows implementation. The are some differences in setting the default MediaSize and MediaSizeName. Those will be not initialized in the Windows world and taken from the current PrintService in case it's not set via PrintRequestAttributeSet.
>>>> 
>>>> 
>>>>> I can see no way around this other than defining an new attribute class that doesn't
>>>>> subclass Media and duplicates MediaTray .. but then you'd also need to say what happens
>>>>> if someone specifies two different trays, one by each means.
>>>>> 
>>>> I do not completely understand what you mean. Do you mean the use case if one specifies A4,Tray2 but Tray2 contains Letter?
>>> 
>>> I meant that if we provided a new class "MediaSource" you could specify MediaSource.TRAY1
>>> whilst still specifying for "Media" an instance of the subclass MediaTray that corresponded
>>> to TRAY2. That's an API solution that doesn't seem likely any time soon.
>> I always thought that the MediaTray does specify the source already as it says in the JavaDoc:
> 
> It does specify the source, but as I've already twice tried to make clear, with present API
> you cannot simultaneously specify the size which is what I thought you were raising as
> the main issue.

I do not want to specify both size and input tray. I may have made myself not clear enough in that point. I do not see how there can be found out, what media size is set on e certain MediaTray to construct the correct paper size on line 575.

> I am guessing that IPP took the view that if you specify the tray that implied a paper size,
> and if you could specify both, you could over-constrain the requirements,
> eg requesting a paper size from a tray that didn't support that paper size.

I see, but this would not be needed if the specified tray within the attribute set would be taken correctly and there is some way to get the media size configured for that tray.

Cheers

Patrick



From philip.race at oracle.com  Mon Nov 25 21:34:19 2013
From: philip.race at oracle.com (Phil Race)
Date: Mon, 25 Nov 2013 13:34:19 -0800
Subject: [OpenJDK 2D-Dev] Please review JDK-8028584
In-Reply-To: <5293B666.4020407@oracle.com>
References: <5293B666.4020407@oracle.com>
Message-ID: <5293C25B.8000308@oracle.com>

Looks OK.
I don't think there's anything direct you need to do to "close"
the connection before returning at line 1617.
Be sure to wait for a 2nd reviewer.

-phil.

On 11/25/2013 12:43 PM, Jennifer Godinez wrote:
> http://cr.openjdk.java.net/~jgodinez/8028584/webrev.00/
>
> ClassCastException occurs when device uri is a file.  Added a check 
> for file and additional safeguard against cast exception.
>
> Jennifer



From sean.mullan at oracle.com  Mon Nov 25 21:06:43 2013
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 25 Nov 2013 16:06:43 -0500
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
Message-ID: <5293BBE3.7040709@oracle.com>

Hi Volker,

The security changes look fine. I'm not crazy that we now have to 
maintain one additional java.security file which is the exact same as 
java.security-linux, but this is really an existing issue with 
duplicated content across the java.security files which I will try to 
fix early in JDK 9: https://bugs.openjdk.java.net/browse/JDK-6997010

Thanks,
Sean

On 11/20/2013 01:26 PM, Volker Simonis wrote:
> Hi,
>
> this is the second review round for "8024854: Basic changes and files to
> build the class library on
> AIX<https://bugs.openjdk.java.net/browse/JDK-8024854>".
> The previous reviews can be found at the end of this mail in the references
> section.
>
> I've tried to address all the comments and suggestions from the first round
> and to further streamline the patch (it perfectly builds on Linux/x86_64,
> Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The biggest change
> compared to the first review round is the new "aix/" subdirectory which
> I've now created under "jdk/src" and which contains AIX-only code.
>
> The webrev is against our
> http://hg.openjdk.java.net/ppc-aix-port/stagerepository which has been
> recently synchronised with the jdk8 master:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/
>
> Below (and in the webrev) you can find some comments which explain the
> changes to each file. In order to be able to push this big change, I need
> the approval of reviewers from the lib, net, svc, 2d, awt and sec groups.
> So please don't hesitate to jump at it - there are enough changes for
> everybody:)
>
> Thank you and best regards,
> Volker
>
> *References:*
>
> The following reviews have been posted so far (thanks Iris for collecting
> them :)
>
> - Alan Bateman (lib): Initial comments (16 Sep [2])
> - Chris Hegarty (lib/net): Initial comments (20 Sep [3])
> - Michael McMahon (net): Initial comments (20 Sept [4])
> - Steffan Larsen (svc): APPROVED (20 Sept [5])
> - Phil Race (2d): Initial comments  (18 Sept [6]); Additional comments (15
> Oct [7])
> - Sean Mullan (sec): Initial comments (26 Sept [8])
>
> [2]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html
> [3]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html
> [4]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html
> [5]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html
> [6]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html
> [7]: http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html
> [8]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html
>
>
> *Detailed change description:*
>
> The new "jdk/src/aix" subdirectory contains the following new and
> AIX-specific files for now:
>
>   src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>   src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java
>   src/aix/classes/sun/nio/ch/AixPollPort.java
>   src/aix/classes/sun/nio/fs/AixFileStore.java
>   src/aix/classes/sun/nio/fs/AixFileSystem.java
>   src/aix/classes/sun/nio/fs/AixFileSystemProvider.java
>   src/aix/classes/sun/nio/fs/AixNativeDispatcher.java
>   src/aix/classes/sun/tools/attach/AixAttachProvider.java
>   src/aix/classes/sun/tools/attach/AixVirtualMachine.java
>   src/aix/native/java/net/aix_close.c
>   src/aix/native/sun/nio/ch/AixPollPort.c
>   src/aix/native/sun/nio/fs/AixNativeDispatcher.c
>   src/aix/native/sun/tools/attach/AixVirtualMachine.c
>   src/aix/porting/porting_aix.c
>   src/aix/porting/porting_aix.h
>
> src/aix/porting/porting_aix.c
> src/aix/porting/porting_aix.h
>
>     - Added these two files for AIX relevant utility code.
>     - Currently these files only contain an implementation of dladdr which
>     is not available on AIX.
>     - In the first review round the existing dladdr users in the code either
>     called the version from the HotSpot on AIX (
>     src/solaris/native/sun/awt/awt_LoadLibrary.c) or had a private copy of
>     the whole implementation (src/solaris/demo/jvmti/hprof/hprof_md.c). This
>     is now not necessary any more.
>
>   The new file layout required some small changes to the makefiles to make
> them aware of the new directory locations:
>
> makefiles/CompileDemos.gmk
>
>     - Add an extra argument to SetupJVMTIDemo which can be used to pass
>     additional source locations.
>     - Currently this is only used on AIX for the AIX porting utilities which
>     are required by hprof.
>
> makefiles/lib/Awt2dLibraries.gmk
> makefiles/lib/ServiceabilityLibraries.gmk
>
>     - On AIX add the sources of the AIX porting utilities to the build. They
>     are required by src/solaris/native/sun/awt/awt_LoadLibrary.c and
>     src/solaris/demo/jvmti/hprof/hprof_md.c because dladdr is not available
>     on AIX.
>
> makefiles/lib/NioLibraries.gmk
>
>     - Make the AIX-build aware of the new NIO source locations under
>     src/aix/native/sun/nio/.
>
> makefiles/lib/NetworkingLibraries.gmk
>
>     - Make the AIX-build aware of the new aix_close.c source location under
>     src/aix/native/java/net/.
>
> src/share/bin/jli_util.h
>
>     - Define JLI_Lseek on AIX.
>
> src/share/lib/security/java.security-aix
>
>     - Provide default java.security-aix for AIX based on the latest Linux
>     version as suggested by Sean Mullan.
>
> src/share/native/common/check_code.c
>
>     - On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is
>     legal, but the code in check_code.c does not handles this properly. So
>     we wrap the two methods on AIX and return a non-NULL pointer even if we
>     allocate 0 bytes.
>
> src/share/native/sun/awt/medialib/mlib_sys.c
>
>     - malloc always returns 8-byte aligned pointers on AIX as well.
>
> src/share/native/sun/awt/medialib/mlib_types.h
>
>     - Add AIX to the list of known platforms.
>
> src/share/native/sun/font/layout/KernTable.cpp
>
>     - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too common
>     and may be defined in other headers as well as on the command line and
>     xlc bails out on macro redefinitions with a different value.
>
> src/share/native/sun/security/ec/impl/ecc_impl.h
>
>     - Define required types and macros on AIX.
>
> src/solaris/back/exec_md.c
>
>     - AIX behaves like Linux in this case so check for it in the Linux
>     branch.
>
> src/solaris/bin/java_md_solinux.c,
> src/solaris/bin/java_md_solinux.h
>
>     - On AIX LD_LIBRARY_PATH is called LIBPATH
>     - Always use LD_LIBRARY_PATH macro instead of using the string "
>     LD_LIBRARY_PATH" directly to cope with different library path names.
>     - Add jre/lib/<arch>/jli to the standard library search path on AIX
>     because the AIX linker doesn't support the -rpath option.
>     - Replace #ifdef __linux__ by #ifndef __solaris__ because in this case,
>     AIX behaves like Linux.
>     - Removed the definition of JVM_DLL, JAVA_DLL and LD_LIBRARY_PATH from
>     java_md_solinux.h because the macros are redefined in the corresponding
>     .c files anyway.
>
> src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>
>     - Provide basic fontconfig.propertiesfor AIX.
>
> src/solaris/classes/java/lang/UNIXProcess.java.aix,
> src/aix/classes/sun/tools/attach/AixAttachProvider.java,
> src/aix/classes/sun/tools/attach/AixVirtualMachine.java,
> src/aix/native/sun/tools/attach/AixVirtualMachine.c
>
>     - Provide AIX specific Java versions, mostly based on the corresponding
>     Linux versions.
>
> src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java
> src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java
>
>     - Detect AIX operating system and return the corresponding channel and
>     file system providers.
>
> src/solaris/classes/sun/nio/ch/Port.java
>
>     - Add a callback function unregisterImpl(int fd) for implementations
>     that need special handling when fd is removed and call it from
> unregister(int
>     fd). By default the implementation of unregisterImpl(int fd) is empty
>     except for the derived AixPollPort class on AIX.
>
> src/solaris/demo/jvmti/hprof/hprof_md.c
>
>     - Add AIX support. AIX mostly behaves like Linux, with the one exception
>     that it has no dladdr functionality.
>     - Use the dladdr implementation from porting_aix.{c,h} on AIX.
>
> src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>
>     - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory).
>
> src/solaris/native/common/jdk_util_md.h
>
>     - Add AIX definitions of the ISNANF and ISNAND macros.
>
> src/solaris/native/java/io/io_util_md.c
>
>     - AIX behaves like Linux in this case so check for it in the Linux
>     branch.
>
> src/solaris/native/java/lang/UNIXProcess_md.c
>
>     - AIX behaves mostly like Solraris in this case so adjust the ifdefs
>     accordingly.
>
> src/solaris/native/java/lang/childproc.c
>
>     - AIX does not understand '/proc/self' - it requires the real process ID
>     to query the proc file system for the current process.
>
> src/solaris/native/java/net/NetworkInterface.c
>
>     - Add AIX support into the Linux branch because AIX mostly behaves like
>     AIX for IPv4.
>     - AIX needs a special function to enumerate IPv6 interfaces and to query
>     the MAC address.
>     - Moved the declaration of siocgifconfRequest to the beginning a the
>     function (as recommend by Michael McMahon) to remain C89 compatible.
>
> src/solaris/native/java/net/PlainSocketImpl.c
>
>     - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the
>     socket is closed. The default error message is then confusing.
>
> src/aix/native/java/net/aix_close.c,
> src/share/native/java/net/net_util.c
>
>     - As recommended by Michael McMahon and Alan Bateman I've move an
>     adapted version of linux_close.c to
> src/aix/native/java/net/aix_close.cbecause we also need the file and
> socket wrappers on AIX.
>     - Compared to the Linux version, we've added the initialization of some
>     previously uninitialized data structures.
>     - Also, on AIX we don't have __attribute((constructor)) so we need to
>     initialize manually (from JNI_OnLoad() in
>     src/share/native/java/net/net_util.c.
>
> src/solaris/native/java/net/net_util_md.h
>
>     - AIX needs the same workaround for I/O cancellation like Linux and
>     MacOSX.
>
> src/solaris/native/java/net/net_util_md.c
>
>     - SO_REUSEADDR is called SO_REUSEPORT on AIX.
>     - On AIX we have to ignore failures due to ENOBUFS when setting the
>     SO_SNDBUF/SO_RCVBUF socket options.
>
> src/solaris/native/java/util/TimeZone_md.c
>
>     - Currently on AIX the only way to get the platform time zone is to read
>     it from the TZ environment variable.
>
> src/solaris/native/sun/awt/awt_LoadLibrary.c
>
>     - Use the dladdr from porting_aix.{c,h} on AIX.
>
> src/solaris/native/sun/awt/fontpath.c
>
>     - Changed some macros from if !defined(__linux__) to if
>     defined(__solaris__) because that's their real meaning.
>     - Add AIX specific fontpath settings and library search paths for
>     libfontconfig.so.
>
> src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>
>     - Rename the MIN and MAX macros to XSD_MIN and XSD_MAX to avoid name
>     clashes (MIN and MAX are much too common and thexy are already defined
>     in some AIX system headers).
>
> src/solaris/native/sun/java2d/x11/XRBackendNative.c
>
>     - Handle AIX like Solaris.
>
> src/solaris/native/sun/nio/ch/Net.c
>
>     - Add AIX-specific includes and constant definitions.
>     - On AIX "socket extensions for multicast source filters" support
>     depends on the OS version. Check for this and throw appropriate exceptions
>     if it is requested but not supported. This is needed to pass
>     JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast
>
> src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
>
>     - On AIX strerror() is not thread-safe so we have to use strerror_r()instead.
>     - On AIX readdir_r() returns EBADF (i.e. '9') and sets 'result' to NULL
>     for the directory stream end. Otherwise, 'errno' will contain the error
>     code.
>     - Handle some AIX corner cases for the results of the statvfs64() call.
>     - On AIX getgrgid_r() returns ESRCH if group does not exist.
>
> src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>
>     - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX.
>
> test/java/lang/ProcessBuilder/Basic.java
> test/java/lang/ProcessBuilder/DestroyTest.java
>
>     - Port this test to AIX and make it more robust (i.e. recognize the "C"
>     locale as isEnglish(), ignore VM-warnings in the output, make sure the
>     "grandchild" processes created by the test don't run too long (60s vs.
>     6666s) because in the case of test problems these processes will pollute
>     the process space, make sure the test fails with an error and doesn't hang
>     indefinitley in the case of a problem).
>
>   *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this
> intended?
>
> Well, _AIX is defined in some system headers while AIX is defined by the
> build system. This is already used inconsistently (i.e. __linux__ vs. LINUX)
> and in general I try to be consistent with the style of the file where I
> the changes are. That said, I changes most of the occurences of AIX to _AIX.
>
>
> *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are
> they supposed to be there?
>
> We currently don't support OS/400 (later renamed into i5/OS and currently
> called IBM i) in our OpenJDK port but we do support it in our internel, SAP
> JVM build. We stripped out all the extra OS/400 functionality from the port
> but in some places where there is common functionality needd by both, AIX
> and OS/400 the OS/400 support may still be visible in the OpenJDK port. I
> don't think this is a real problem and it helps us to keep our internel
> sources in sync with the OpenJDK port. That said, I think I've removed all
> the references to OS/400 now.
>



From james.graham at oracle.com  Mon Nov 25 22:12:45 2013
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 25 Nov 2013 14:12:45 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529355F0.4040506@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
	<5283D2F9.6010100@oracle.com> <528B625D.7060406@oracle.com>
	<528BFA66.7040307@oracle.com> <528E1591.90309@oracle.com>
	<528E3145.1020105@oracle.com> <528F37C2.8050907@oracle.com>
	<529000B4.6070503@oracle.com> <529355F0.4040506@oracle.com>
Message-ID: <5293CB5D.8070802@oracle.com>

Hi Alexander,

On 11/25/13 5:51 AM, Alexander Scherbatiy wrote:
>    Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.10/
>
>   - FLIP and TRANSLATE bit masks are also included for the SCALE
> transform checking

Looks good.

>   - LWCToolkit checks an image in cache before requesting
> multi-resolution image creation to prevent excessive string manipulation.
>     It needs to make imgCache accessible from the LWCToolkit or move
> image2x staff calculation to the SunToolkit to use the right
> synchronization.

Eventually we will probably want to make @2x supported on all platforms 
for cross-platform compatibility (not so much the behavior on retina 
displays that only exist on Mac for now, but since it is invoked by 
scaled rendering, then other platforms also run into the conditions for 
these images).

I think it's OK to release this as Mac-only for now, but I think we 
should eventually strive for a more unified HiDPI support on all platforms.

>     imgCache is not created per Application context so there can be
> issues to make it protected. The image2x staff does not relate to
> SunToolkit.
>     That is why all staff related to ToolkitImage creation used to move
> into ToolkitImageUtil in some previous fix. I just skipped the
> synchronization for this particular case.

We can probably take care of that later when we unify the HiDPI media 
handling?

>   - The containsResolutionVariant method is removed from the
> MultiResolutionImage

OK.  The main thing was that we not require its use for @2x to "just work".

>   - The image observer is nullified in drawImage(Image,..ImageObserver)
> method for the resolution variant.
>     The original image is always loaded because it needs to know the
> image width and height for the resolution variant size calculation.
>      Only the original image sends notifications that an image is
> loaded. The resolution variant is drawn silently so it does not break
> existed image observer implementation.

If they only ever use the image on a retina display (or some scaled 
context) then I don't think we ever send any notifications the way the 
current fix is written.  Also, if you don't send notifications for the 
scaled variant, but load the original and expect its notifications to 
suffice, then we have a race condition - if the original variant is 
fully constructed before the scaled version is done then the final "OK 
to draw everything" notice would not happen and they'd be left with a 
partial image.

I think it should be easy to pass along the observer and simply have 
ImageRep translate the image variant into the base image in its newInfo 
method (and there are a couple of other locations that imageUpdate is 
called that could do the same).  All it takes is adding 
"ToolkitImage.set/getBaseImage()" to ToolkitImage, defaulting to "this", 
but the Multi-Res image will set the base image on both of its variants 
to the Multi-Res instance.

Then we get full notices of all resolution variants.

It would be best to scale the xywh supplied there as well.  That should 
be fairly easy, but if it is a big problem then that is lower priority 
than getting the "ALLBITS" notification right, as that is the main 
trigger for so many uses.

(In the future we can add ImageObserver2 (or MultiResObserver?) which 
has support for receiving notifications of variants without translation.)

I'll need some time to read the other information about what was done in 
7 and respond in a separate email.  And, again, my apologies for not 
having been in the loop for that part of the process...

			...jim


From volker.simonis at gmail.com  Mon Nov 25 22:30:26 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 25 Nov 2013 23:30:26 +0100
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <52937223.408@oracle.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
	<52937223.408@oracle.com>
Message-ID: <CA+3eh10c9PWGH0nAmdC6G9+s7NruLHGekunSYTmPVT07JZQWAA@mail.gmail.com>

Hi Artem,

thanks a lot for your review. Please find my comments inline:

On Monday, November 25, 2013, Artem Ananiev wrote:

> Hi, Volker,
>
> just a few very minor comments about the client changes:
>
> 1. mlib_sys.c: the change is fine, but it makes the following comment
> obsolete.


You're right. I'll update the comment and try to find a
corresponding  reference for the AIX compiler.


> 2. XRBackendNative.c: the same comment here.


Again, I'll update the comment accordingly.


> 3. Awt2dLibraries.gmk: $(JDK_TOPDIR)/src/aix/porting/porting_aix.c would
> be better than just porting_aix.c


Good catch! I think the right solution would be to add
$(JDK_TOPDIR)/src/aix/porting to LIBAWT_DIRS. This will also add the
directory automatically to LIBAWT_CFLAGS.

I'll prepare a final webrev with all the proposed changes tomorrow.

Thanks once again,
Volker


>
> Thanks,
>
> Artem
>
> On 11/20/2013 10:26 PM, Volker Simonis wrote:
>
>> Hi,
>>
>> this is the second review round for "8024854: Basic changes and files to
>> build the class library on AIX
>> <https://bugs.openjdk.java.net/browse/JDK-8024854>". The previous
>> reviews can be found at the end of this mail in the references section.
>>
>> I've tried to address all the comments and suggestions from the first
>> round and to further streamline the patch (it perfectly builds on
>> Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The
>> biggest change compared to the first review round is the new "aix/"
>> subdirectory which I've now created under "jdk/src" and which contains
>> AIX-only code.
>>
>> The webrev is against our http://hg.openjdk.java.net/ppc-aix-port/stage
>> repository which has been recently synchronised with the jdk8 master:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/
>>
>> Below (and in the webrev) you can find some comments which explain the
>> changes to each file. In order to be able to push this big change, I
>> need the approval of reviewers from the lib, net, svc, 2d, awt and sec
>> groups. So please don't hesitate to jump at it - there are enough
>> changes for everybody:)
>>
>> Thank you and best regards,
>> Volker
>>
>> *References:*
>>
>> The following reviews have been posted so far (thanks Iris for
>> collecting them :)
>>
>> - Alan Bateman (lib): Initial comments (16 Sep [2])
>> - Chris Hegarty (lib/net): Initial comments (20 Sep [3])
>> - Michael McMahon (net): Initial comments (20 Sept [4])
>> - Steffan Larsen (svc): APPROVED (20 Sept [5])
>> - Phil Race (2d): Initial comments  (18 Sept [6]); Additional comments
>> (15 Oct [7])
>> - Sean Mullan (sec): Initial comments (26 Sept [8])
>>
>> [2]:
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001045.html
>> [3]:
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001078.html
>> [4]:
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001079.html
>> [5]:
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001077.html
>> [6]:
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001069.html
>> [7]: http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/
>> 003826.html
>> [8]:
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001081.html
>>
>>
>> *Detailed change description:*
>>
>> The new "jdk/src/aix" subdirectory contains the following new and
>> AIX-specific files for now:
>>
>>   src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>>   src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java
>>   src/aix/classes/sun/nio/ch/AixPollPort.java
>>   src/aix/classes/sun/nio/fs/AixFileStore.java
>>   src/aix/classes/sun/nio/fs/AixFileSystem.java
>>   src/aix/classes/sun/nio/fs/AixFileSystemProvider.java
>>   src/aix/classes/sun/nio/fs/AixNativeDispatcher.java
>>   src/aix/classes/sun/tools/attach/AixAttachProvider.java
>>   src/aix/classes/sun/tools/attach/AixVirtualMachine.java
>>   src/aix/native/java/net/aix_close.c
>>   src/aix/native/sun/nio/ch/AixPollPort.c
>>   src/aix/native/sun/nio/fs/AixNativeDispatcher.c
>>   src/aix/native/sun/tools/attach/AixVirtualMachine.c
>>   src/aix/porting/porting_aix.c
>>   src/aix/porting/porting_aix.h
>>
>>
>>         src/aix/porting/porting_aix.c
>>         src/aix/porting/porting_aix.h
>>
>>   * Added these two files for AIX relevant utility code.
>>   * Currently these files only contain an implementation of |dladdr|
>>     which is not available on AIX.
>>   * In the first review round the existing |dladdr| users in the code
>>     either called the version from the HotSpot on AIX
>>     (|src/solaris/native/sun/awt/awt_LoadLibrary.c|) or had a private
>>     copy of the whole implementation
>>     (|src/solaris/demo/jvmti/hprof/hprof_md.c|). This is now not
>>     necessary any more.
>>
>> The new file layout required some small changes to the makefiles to make
>> them aware of the new directory locations:
>>
>>
>>         makefiles/CompileDemos.gmk
>>
>>   * Add an extra argument to |SetupJVMTIDemo| which can be used to pass
>>     additional source locations.
>>   * Currently this is only used on AIX for the AIX porting utilities
>>     which are required by hprof.
>>
>>
>>         makefiles/lib/Awt2dLibraries.gmk
>>         makefiles/lib/ServiceabilityLibraries.gmk
>>
>>   * On AIX add the sources of the AIX porting utilities to the build.
>>     They are required by |src/solaris/native/sun/awt/awt_LoadLibrary.c|
>>     and |src/solaris/demo/jvmti/hprof/hprof_md.c| because |dladdr| is
>>     not available on AIX.
>>
>>
>>         makefiles/lib/NioLibraries.gmk
>>
>>   * Make the AIX-build aware of the new NIO source locations under
>>     |src/aix/native/sun/nio/|.
>>
>>
>>         makefiles/lib/NetworkingLibraries.gmk
>>
>>   * Make the AIX-build aware of the new |aix_close.c| source location
>>     under |src/aix/native/java/net/|.
>>
>>
>>         src/share/bin/jli_util.h
>>
>>   * Define |JLI_Lseek| on AIX.
>>
>>
>>         src/share/lib/security/java.security-aix
>>
>>   * Provide default |java.security-aix| for AIX based on the latest
>>     Linux version as suggested by Sean Mullan.
>>
>>
>>         src/share/native/common/check_code.c
>>
>>   * On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is
>>     legal, but the code in |check_code.c| does not handles this
>>     properly. So we wrap the two methods on AIX and return a non-NULL
>>     pointer even if we allocate 0 bytes.
>>
>>
>>         src/share/native/sun/awt/medialib/mlib_sys.c
>>
>>   * |malloc| always returns 8-byte aligned pointers on AIX as well.
>>
>>
>>         src/share/native/sun/awt/medialib/mlib_types.h
>>
>>   * Add AIX to the list of known platforms.
>>
>>
>>         src/share/native/sun/font/layout/KernTable.cpp
>>
>>   * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| is
>>     too common and may be defined in other headers as well as on the
>>     command line and |xlc| bails out on macro redefinitions with a
>>     different value.
>>
>>
>>         src/share/native/sun/security/ec/impl/ecc_impl.h
>>
>>   * Define required types and macros on AIX.
>>
>>
>>         src/solaris/back/exec_md.c
>>
>>   * AIX behaves like Linux in this case so check for it in the Linux
>> branch.
>>
>>
>>         src/solaris/bin/java_md_solinux.c,
>>         src/solaris/bin/java_md_solinux.h
>>
>>   * On AIX |LD_LIBRARY_PATH| is called |LIBPATH|
>>   * Always use |LD_LIBRARY_PATH| macro instead of using the string
>>     "|LD_LIBRARY_PATH|" directly to cope with different library path
>> names.
>>   * Add |jre/lib/<arch>/jli| to the standard library search path on AIX
>>     because the AIX linker doesn't support the |-rpath| option.
>>   * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in this
>>     case, AIX behaves like Linux.
>>   * Removed the definition of |JVM_DLL|, |JAVA_DLL| and
>>     |LD_LIBRARY_PATH| from |java_md_solinux.h| because the macros are
>>     redefined in the corresponding |.c| files anyway.
>>
>>
>>         src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>>
>>   * Provide basic |fontconfig.properties|for AIX.
>>
>>
>>         src/solaris/classes/java/lang/UNIXProcess.java.aix,
>>         src/aix/classes/sun/tools/attach/AixAttachProvider.java,
>>         src/aix/classes/sun/tools/attach/AixVirtualMachine.java,
>>         src/aix/native/sun/tools/attach/AixVirtualMachine.c
>>
>>   * Provide AIX specific Java versions, mostly based on the
>>     corresponding Linux versions.
>>
>>
>>         src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProv
>> ider.java
>>         src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java
>>
>>   * Detect AIX operating system and return the corresponding channel and
>>     file system providers.
>>
>>
>>         src/solaris/classes/sun/nio/ch/Port.java
>>
>>   * Add a callback function |unregisterImpl(int fd)| for implementations
>>     that need special handling when |fd| is removed and call it from
>>     |unregister(int fd)|. By default the implementation of
>>     |unregisterImpl(int fd)| is empty except for the derived
>>     |AixPollPort| class on AIX.
>>
>>
>>         src/solaris/demo/jvmti/hprof/hprof_md.c
>>
>>   * Add AIX support. AIX mostly behaves like Linux, with the one
>>     exception that it has no |dladdr| functionality.
>>   * Use the |dladdr| implementation from |porting_aix.{c,h}| on AIX.
>>
>>
>>         src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>>
>>   * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory).
>>
>>
>>         src/solaris/native/common/jdk_util_md.h
>>
>>   * Add AIX definitions of the |ISNANF| and |ISNAND| macros.
>>
>>
>>         src/solaris/native/java/io/io_util_md.c
>>
>>   * AIX behaves like Linux in this case so check for it in the Linux
>> branch.
>>
>>
>>         src/solaris/native/java/lang/UNIXProcess_md.c
>>
>>   * AIX behaves mostly like Solraris in this case so adjust the ifdefs
>>     accordingly.
>>
>>
>>         src/solaris/native/java/lang/childproc.c
>>
>>   * AIX does not understand '/proc/self' - it requires the real process
>>     ID to query the proc file system for the current process.
>>
>>
>>         src/solaris/native/java/net/NetworkInterface.c
>>
>>   * Add AIX support into the Linux branch because AIX mostly behaves
>>     like AIX for IPv4.
>>   * AIX needs a special function to enumerate IPv6 interfaces and to
>>     query the MAC address.
>>   * Moved the declaration of |siocgifconfRequest| to the beginning a the
>>     function (as recommend by Michael McMahon) to remain C89 compatible.
>>
>>
>>         src/solaris/native/java/net/PlainSocketImpl.c
>>
>>   * On AIX (like on Solaris) |setsockopt| will set errno to |EINVAL| if
>>     the socket is closed. The default error message is then confusing.
>>
>>
>>         src/aix/native/java/net/aix_close.c,
>>         src/share/native/java/net/net_util.c
>>
>>   * As recommended by Michael McMahon and Alan Bateman I've move an
>>     adapted version of |linux_close.c| to
>>     |src/aix/native/java/net/aix_close.c| because we also need the file
>>     and socket wrappers on AIX.
>>   * Compared to the Linux version, we've added the initialization of
>>     some previously uninitialized data structures.
>>   * Also, on AIX we don't have |__attribute((constructor))| so we need
>>     to initialize manually (from |JNI_OnLoad()| in
>>     |src/share/native/java/net/net_util.c|.
>>
>>
>>         src/solaris/native/java/net/net_util_md.h
>>
>>   * AIX needs the same workaround for I/O cancellation like Linux and
>>     MacOSX.
>>
>>
>>         src/solaris/native/java/net/net_util_md.c
>>
>>   * |SO_REUSEADDR| is called |SO_REUSEPORT| on AIX.
>>   * On AIX we have to ignore failures due to |ENOBUFS| when setting the
>>     |SO_SNDBUF|/|SO_RCVBUF| socket options.
>>
>>
>>         src/solaris/native/java/util/TimeZone_md.c
>>
>>   * Currently on AIX the only way to get the platform time zone is to
>>     read it from the |TZ| environment variable.
>>
>>
>>         src/solaris/native/sun/awt/awt_LoadLibrary.c
>>
>>   * Use the |dladdr| from |porting_aix.{c,h}| on AIX.
>>
>>
>>         src/solaris/native/sun/awt/fontpath.c
>>
>>   * Changed some macros from |if !defined(__linux__)| to |if
>>     defined(__solaris__)| because that's their real meaning.
>>   * Add AIX specific fontpath settings and library search paths for
>>     |libfontconfig.so|.
>>
>>
>>         src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>>
>>   * Rename the |MIN| and |MAX| macros to |XSD_MIN| and |XSD_MAX| to
>>     avoid name clashes (|MIN| and |MAX| are much too common and thexy
>>     are already defined in some AIX system headers).
>>
>>
>>         src/solaris/native/sun/java2d/x11/XRBackendNative.c
>>
>>   * Handle AIX like Solaris.
>>
>>
>>         src/solaris/native/sun/nio/ch/Net.c
>>
>>   * Add AIX-specific includes and constant definitions.
>>   * On AIX "socket extensions for multicast source filters" support
>>     depends on the OS version. Check for this and throw appropriate
>>     exceptions if it is requested but not supported. This is needed to
>>     pass
>>     JCK-api/java_nio/channels/DatagramChannel/
>> DatagramChannel.html#Multicast
>>
>>
>>         src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
>>
>>   * On AIX |strerror()| is not thread-safe so we have to use
>>     |strerror_r()| instead.
>>   * On AIX |readdir_r()| returns EBADF (i.e. '9') and sets 'result' to
>>     NULL for the directory stream end. Otherwise, 'errno' will contain
>>     the error code.
>>   * Handle some AIX corner cases for the results of the |statvfs64()|
>> call.
>>   * On AIX |getgrgid_r()| returns ESRCH if group does not exist.
>>
>>
>>         src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>>
>>   * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX.
>>
>>
>>         test/java/lang/ProcessBuilder/Basic.java
>>         test/java/lang/ProcessBuilder/DestroyTest.java
>>
>>   * Port this test to AIX and make it more robust (i.e. recognize the
>>     "C" locale as |isEnglish()|, ignore VM-warnings in the output, make
>>     sure the "grandchild" processes created by the test don't run too
>>     long (60s vs. 6666s) because in the case of test problems these
>>     processes will pollute the process space, make sure the test fails
>>     with an error and doesn't hang indefinitley in the case of a problem).
>>
>> *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this
>> intended?
>>
>> Well, |_AIX| is defined in some system headers while |AIX| is defined by
>> the build system. This is already used inconsistently (i.e. |__linux__|
>> vs. |LINUX|) and in general I try to be consistent with the style of the
>> file where I the changes are. That said, I changes most of the
>> occurences of |AIX| to |_AIX|.
>>
>> *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are
>> they supposed to be there?
>>
>> We currently don't support OS/400 (later renamed into i5/OS and
>> currently called IBM i) in our OpenJDK port but we do support it in our
>> internel, SAP JVM build. We stripped out all the extra OS/400
>> functionality from the port but in some places where there is common
>> functionality needd by both, AIX and OS/400 the OS/400 support may still
>> be visible in the OpenJDK port. I don't think this is a real problem and
>> it helps us to keep our internel sources in sync with the OpenJDK port.
>> That said, I think I've removed all the references to OS/400 now.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131125/dfce4466/attachment.html>

From james.graham at oracle.com  Mon Nov 25 22:31:22 2013
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 25 Nov 2013 14:31:22 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529355F0.4040506@oracle.com>
References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com>
	<526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com>
	<526FE63C.1020408@oracle.com> <5272C1AB.9030202@gmail.com>
	<5278D385.2000205@oracle.com> <5280FEDA.20202@oracle.com>
	<528284FF.3080007@oracle.com> <5283A4A4.60007@oracle.com>
	<5283D2F9.6010100@oracle.com> <528B625D.7060406@oracle.com>
	<528BFA66.7040307@oracle.com> <528E1591.90309@oracle.com>
	<528E3145.1020105@oracle.com> <528F37C2.8050907@oracle.com>
	<529000B4.6070503@oracle.com> <529355F0.4040506@oracle.com>
Message-ID: <5293CFBA.6010209@oracle.com>



On 11/25/13 5:51 AM, Alexander Scherbatiy wrote:
> On 11/23/2013 5:11 AM, Jim Graham wrote:
>> Hi Alexander,
>>
>> If we are going to be advertising it as something that developers use
>> in production code then we would need to file this via CCC. With the
>> current implementation, any user that has their own ImageObservers
>> must use this API and so it becomes not only public, at a time when
>> there is a lockdown on new public API in 8.0, but it also means that
>> we are tied to its implementation and we can't rely on "it was
>> experimental and so we can change it at any point" - you can't say
>> that about an API that is necessary to correctly use a touted feature.
>
>      This issue has its own history.  It has been already fixed for the
> JDK 7u for the Java2D demo. It was decided to not bring new API for the
> HiDPI support in the JDK 7.
>      It was suggested to using code like below to create a ScalableImage.
> ------------------------------
> /**
>   * Class that loads and returns images according to
>   * scale factor of graphic device
>   *
>   *  <pre> {@code
>   *    Image image = new ScalableImage() {
>   *
>   *        public Image createScaledImage(float scaleFactor) {
>   *            return (scaleFactor <= 1) ? loadImage("image.png")
>   *                : loadImage("image at 2x.png");
>   *        }
>   *
>   *        Image loadImage(String name){
>   *            // load image
>   *        }
>   *    };}</pre>
>   */
> ------------------------------
>
>   It was based on the display scale factor. The scale factor should be
> manually retrieved from the Graphics2D and was not a part of the public
> API:
>   g2d.drawImage(scalbleImage.getScaledImage(scaleFactor),..).
>
>   From that time it was clear that there should be 2 basic operations
> for the HiDPI images support:
>    - retrieve an image with necessary resolution
>    - retrieve images with all resolutions
>
>    The second one is useful when it is necessary to create one set of
> images using the given one (for example, to draw a shape on all images).

For now, these are just ToolkitImages and you can't draw on them, so 
this is moot for the case of @2x support in getImage().

>    The JDK 7 solution has been revisited for the JDK 8 and the neccesary
> CCC request 8011059  has been created and approved.
>
>    Both the JDK-8011059 issue description and the approved CCC request
> says:
>    -----------------------
>    A user should have a unified way to provide high resolution images
> that can be drawn on HIDPI displays according to the user provided
> algorithm.
>    -----------------------

We've implemented the Hint part of that solution, but the mechanism for 
creating custom multi-res images was not workable.  I no longer sit as 
the client rep on the CCC or I would have pointed that out, my apologies.

>    The 8011059 fix consists of two parts:
>    - Provide a way for a custom image creation that holds images with
> different resolutions
>    - Load @2x images on Mac OS X
>
>    The first one of the fix can be used without the second. it is not
> difficult to crate just a class which loads @2x images using the given
> file path/url.

If we support @2x transparently behind the scenes as we are doing now, 
who is the requester for the way to create a custom set of resolution 
variants?  I think the most important customer-driven request was to 
support @2x for the Mac developers, wasn't it?

>    Now it is suggested to implement the given MultiResolutionImage
> interface  and override two methods:
>     - Image getResolutionVariant(int width, int height)
>     - List<Image> getResolutionVariants()
>
>     An image with necessary resolution should be drawn automatically in
> SunGraphics2D.
>
>    What we need is to focus on the first part of the fix.
>    From this point of view it up to the user' code to load all or some
> resolution variants by MediaTracker and using
> Component.prepareImage/checkImage methods.

This is all an interesting goal, but I'm not sure it is as high a 
priority if we support a convention (based on platform conventions) for 
high resolution variants behind the scenes.  I do agree that we need 
something like this before too long, but I don't think it was workable 
to target the getScaledInstance() method as the mechanism to implement 
it.  That was the only convention that was approved in that CCC request, 
so a more complete API based on another mechanism is not covered there.

Also, Win8 has its own conventions as well which come into play on the 
new high resolution Surface tablets and we should consider those to 
guide the API we develop.

All, in all, though, I think if we get @2x support in with no code 
changes needed for apps then we have taken care of the primary use case. 
  We can probably even handle the Win8 conventions behind the scenes in 
an 8u release...

			...jim


From volker.simonis at gmail.com  Mon Nov 25 22:35:33 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 25 Nov 2013 23:35:33 +0100
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <5293BBE3.7040709@oracle.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
	<5293BBE3.7040709@oracle.com>
Message-ID: <CA+3eh11CATdrwd444KtP6H2HgOwDcCPYQ6=8W5d7YAjVXAFEmw@mail.gmail.com>

Hi Sean,

thanks a lot for you review.

Please let me know once you start working on 6997010 so I can update the
corresponding AIX file accordingly.

Regards,
Volker

On Monday, November 25, 2013, Sean Mullan wrote:

> Hi Volker,
>
> The security changes look fine. I'm not crazy that we now have to maintain
> one additional java.security file which is the exact same as
> java.security-linux, but this is really an existing issue with duplicated
> content across the java.security files which I will try to fix early in JDK
> 9: https://bugs.openjdk.java.net/browse/JDK-6997010
>
> Thanks,
> Sean
>
> On 11/20/2013 01:26 PM, Volker Simonis wrote:
>
>> Hi,
>>
>> this is the second review round for "8024854: Basic changes and files to
>> build the class library on
>> AIX<https://bugs.openjdk.java.net/browse/JDK-8024854>".
>> The previous reviews can be found at the end of this mail in the
>> references
>> section.
>>
>> I've tried to address all the comments and suggestions from the first
>> round
>> and to further streamline the patch (it perfectly builds on Linux/x86_64,
>> Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The biggest change
>> compared to the first review round is the new "aix/" subdirectory which
>> I've now created under "jdk/src" and which contains AIX-only code.
>>
>> The webrev is against our
>> http://hg.openjdk.java.net/ppc-aix-port/stagerepository which has been
>> recently synchronised with the jdk8 master:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/
>>
>> Below (and in the webrev) you can find some comments which explain the
>> changes to each file. In order to be able to push this big change, I need
>> the approval of reviewers from the lib, net, svc, 2d, awt and sec groups.
>> So please don't hesitate to jump at it - there are enough changes for
>> everybody:)
>>
>> Thank you and best regards,
>> Volker
>>
>> *References:*
>>
>> The following reviews have been posted so far (thanks Iris for collecting
>> them :)
>>
>> - Alan Bateman (lib): Initial comments (16 Sep [2])
>> - Chris Hegarty (lib/net): Initial comments (20 Sep [3])
>> - Michael McMahon (net): Initial comments (20 Sept [4])
>> - Steffan Larsen (svc): APPROVED (20 Sept [5])
>> - Phil Race (2d): Initial comments  (18 Sept [6]); Additional comments (15
>> Oct [7])
>> - Sean Mullan (sec): Initial comments (26 Sept [8])
>>
>> [2]:
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001045.html
>> [3]:
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001078.html
>> [4]:
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001079.html
>> [5]:
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001077.html
>> [6]:
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001069.html
>> [7]: http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/
>> 003826.html
>> [8]:
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001081.html
>>
>>
>> *Detailed change description:*
>>
>> The new "jdk/src/aix" subdirectory contains the following new and
>> AIX-specific files for now:
>>
>>   src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>>   src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java
>>   src/aix/classes/sun/nio/ch/AixPollPort.java
>>   src/aix/classes/sun/nio/fs/AixFileStore.java
>>   src/aix/classes/sun/nio/fs/AixFileSystem.java
>>   src/aix/classes/sun/nio/fs/AixFileSystemProvider.java
>>   src/aix/classes/sun/nio/fs/AixNativeDispatcher.java
>>   src/aix/classes/sun/tools/attach/AixAttachProvider.java
>>   src/aix/classes/sun/tools/attach/AixVirtualMachine.java
>>   src/aix/native/java/net/aix_close.c
>>   src/aix/native/sun/nio/ch/AixPollPort.c
>>   src/aix/native/sun/nio/fs/AixNativeDispatcher.c
>>   src/aix/native/sun/tools/attach/AixVirtualMachine.c
>>   src/aix/porting/porting_aix.c
>>   src/aix/porting/porting_aix.h
>>
>> src/aix/porting/porting_aix.c
>> src/aix/porting/porting_aix.h
>>
>>     - Added these two files for AIX relevant utility code.
>>     - Currently these files only contain an implementation of dladdr which
>>     is not available on AIX.
>>     - In the first review round the existing dladdr users in the code
>> either
>>     called the version from the HotSpot on AIX (
>>     src/solaris/native/sun/awt/awt_LoadLibrary.c) or had a private copy
>> of
>>     the whole implementation (src/solaris/demo/jvmti/hprof/hprof_md.c).
>> This
>>     is now not necessary any more.
>>
>>   The new file layout required some small changes to the makefiles to make
>> them aware of the new directory locations:
>>
>> makefiles/CompileDemos.gmk
>>
>>     - Add an extra argument to SetupJVMTIDemo which can be used to pass
>>     additional source locations.
>>     - Currently this is only used on AIX for the AIX porting utilities
>> which
>>     are required by hprof.
>>
>> makefiles/lib/Awt2dLibraries.gmk
>> makefiles/lib/ServiceabilityLibraries.gmk
>>
>>     - On AIX add the sources of the AIX porting utilities to the build.
>> They
>>     are required by src/solaris/native/sun/awt/awt_LoadLibrary.c and
>>     src/solaris/demo/jvmti/hprof/hprof_md.c because dladdr is not
>> available
>>     on AIX.
>>
>> makefiles/lib/NioLibraries.gmk
>>
>>     - Make the AIX-build aware of the new NIO source locations under
>>     src/aix/native/sun/nio/.
>>
>> makefiles/lib/NetworkingLibraries.gmk
>>
>>     - Make the AIX-build aware of the new aix_close.c source location
>> under
>>     src/aix/native/java/net/.
>>
>> src/share/bin/jli_util.h
>>
>>     - Define JLI_Lseek on AIX.
>>
>> src/share/lib/security/java.security-aix
>>
>>     - Provide default java.security-aix for AIX based on the latest Linux
>>     version as suggested by Sean Mullan.
>>
>> src/share/native/common/check_code.c
>>
>>     - On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is
>>     legal, but the code in check_code.c does not handles this properly. So
>>     we wrap the two methods on AIX and return a non-NULL pointer even if
>> we
>>     allocate 0 bytes.
>>
>> src/share/native/sun/awt/medialib/mlib_sys.c
>>
>>     - malloc always returns 8-byte aligned pointers on AIX as well.
>>
>> src/share/native/sun/awt/medialib/mlib_types.h
>>
>>     - Add AIX to the list of known platforms.
>>
>> src/share/native/sun/font/layout/KernTable.cpp
>>
>>     - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too
>> common
>>     and may be defined in other headers as well as on the command line and
>>     xlc bails out on macro redefinitions with a different value.
>>
>> src/share/native/sun/security/ec/impl/ecc_impl.h
>>
>>     - Define required types and macros on AIX.
>>
>> src/solaris/back/exec_md.c
>>
>>     - AIX behaves like Linux in this case so check for it in the Linux
>>     branch.
>>
>> src/solaris/bin/java_md_solinux.c,
>> src/solaris/bin/java_md_solinux.h
>>
>>     - On AIX LD_LIBRARY_PATH is called LIBPATH
>>     - Always use LD_LIBRARY_PATH macro instead of using the string "
>>     LD_LIBRARY_PATH" directly to cope with different library path names.
>>     - Add jre/lib/<arch>/jli to the standard library search path on AIX
>>     because the AIX linker doesn't support the -rpath option.
>>     - Replace #ifdef __linux__ by #ifndef __solaris__ because in this
>> case,
>>     AIX behaves like Linux.
>>     - Removed the definition of JVM_DLL, JAVA_DLL and LD_LIBRARY_PATH from
>>     java_md_solinux.h because the macros are redefined in the
>> corresponding
>>     .c files anyway.
>>
>> src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>>
>>     - Provide basic fontconfig.propertiesfor AIX.
>>
>> src/solaris/classes/java/lang/UNIXProcess.java.aix,
>> src/aix/classes/sun/tools/attach/AixAttachProvider.java,
>> src/aix/classes/sun/tools/attach/AixVirtualMachine.java,
>> src/aix/native/sun/tools/attach/AixVirtualMachine.c
>>
>>     - Provide AIX specific Java versions, mostly based on the
>> corresponding
>>     Linux versions.
>>
>> src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java
>> src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java
>>
>>     - Detect AIX operating system and return the corresponding channel and
>>     file system providers.
>>
>> src/solaris/classes/sun/nio/ch/Port.java
>>
>>     - Add a callback function unregisterImpl(int fd) for implementations
>>     that need special handling when fd is removed and call it from
>> unregister(int
>>     fd). By default the implementation of unregisterImpl(int fd) is empty
>>     except for the derived AixPollPort class on AIX.
>>
>> src/solaris/demo/jvmti/hprof/hprof_md.c
>>
>>     - Add AIX support. AIX mostly behaves like Linux, with the one
>> exception
>>     that it has no dladdr functionality.
>>     - Use the dladdr implementation from porting_aix.{c,h} on AIX.
>>
>> src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>>
>>     - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory).
>>
>> src/solaris/native/common/jdk_util_md.h
>>
>>     - Add AIX definitions of the ISNANF and ISNAND macros.
>>
>> src/solaris/native/java/io/io_util_md.c
>>
>>     - AIX behaves like Linux in this case so check for it in the Linux
>>     branch.
>>
>> src/solaris/native/java/lang/UNIXProcess_md.c
>>
>>     - AIX behaves mostly like Solraris in this case so adjust the ifdefs
>>     accordingly.
>>
>> src/solaris/native/java/lang/childproc.c
>>
>>     - AIX does not understand '/proc/self' - it requires the real process
>> ID
>>     to query the proc file system for the current process.
>>
>> src/solaris/native/java/net/NetworkInterface.c
>>
>>     - Add AIX support into the Linux branch because AIX mostly behaves
>> like
>>     AIX for IPv4.
>>     - AIX needs a special function to enumerate IPv6 interfaces and to
>> query
>>     the MAC address.
>>     - Moved the declaration of siocgifconfRequest to the beginning a the
>>     function (as recommend by Michael McMahon) to remain C89 compatible.
>>
>> src/solaris/native/java/net/PlainSocketImpl.c
>>
>>     - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the
>>     socket is closed. The default error message is then confusing.
>>
>> src/aix/native/java/net/aix_close.c,
>> src/share/native/java/net/net_util.c
>>
>>     - As recommended by Michael McMahon and Alan Bateman I've move an
>>     adapted version of linux_close.c to
>> src/aix/native/java/net/aix_close.cbecause we also need the file and
>> socket wrappers on AIX.
>>     - Compared to the Linux version, we've added the initialization of
>> some
>>     previously uninitialized data structures.
>>     - Also, on AIX we don't have __attribute((constructor)) so we need to
>>     initialize manually (from JNI_OnLoad() in
>>     src/share/native/java/net/net_util.c.
>>
>> src/solaris/native/java/net/net_util_md.h
>>
>>     - AIX needs the same workaround for I/O cancellation like Linux and
>>     MacOSX.
>>
>> src/solaris/native/java/net/net_util_md.c
>>
>>     - SO_REUSEADDR is called SO_REUSEPORT on AIX.
>>     - On AIX we have to ignore failures due to ENOBUFS when setting the
>>     SO_SNDBUF/SO_RCVBUF socket options.
>>
>> src/solaris/native/java/util/TimeZone_md.c
>>
>>     - Currently on AIX the only way to get the platform time zone is to
>> read
>>     it from the TZ environment variable.
>>
>> src/solaris/native/sun/awt/awt_LoadLibrary.c
>>
>>     - Use the dladdr from porting_aix.{c,h} on AIX.
>>
>> src/solaris/native/sun/awt/fontpath.c
>>
>>     - Changed some macros from if !defined(__linux__) to if
>>     defined(__solaris__) because that's their real meaning.
>>     - Add AIX specific fontpath settings and library search paths for
>>     libfontconfig.so.
>>
>> src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>>
>>     - Rename the MIN and MAX macros to XSD_MIN and XSD_MAX to avoid name
>>     clashes (MIN and MAX are much too common and thexy are already defined
>>     in some AIX system headers).
>>
>> src/solaris/native/sun/java2d/x11/XRBackendNative.c
>>
>>     - Handle AIX like Solaris.
>>
>> src/solaris/native/sun/nio/ch/Net.c
>>
>>     - Add AIX-specific includes and constant definitions.
>>     - On AIX "socket extensions for multicast source filters" support
>>     depends on the OS version. Check for this and throw appropriate
>> exceptions
>>     if it is requested but not supported. This is needed to pass
>>     JCK-api/java_nio/channels/DatagramChannel/
>> DatagramChannel.html#Multicast
>>
>> src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
>>
>>     - On AIX strerror() is not thread-safe so we have to use
>> strerror_r()instead.
>>     - On AIX readdir_r() returns EBADF (i.e. '9') and sets 'result' to
>> NULL
>>     for the directory stream end. Otherwise, 'errno' will contain the
>> error
>>     code.
>>     - Handle some AIX corner cases for the results of the statvfs64()
>> call.
>>     - On AIX getgrgid_r() returns ESRCH if group does not exist.
>>
>> src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>>
>>     - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX.
>>
>> test/java/lang/ProcessBuilder/Basic.java
>> test/java/lang/ProcessBuilder/DestroyTest.java
>>
>>     - Port this test to AIX and make it more robust (i.e. recognize the
>> "C"
>>     locale as isEnglish(), ignore VM-warnings in the output, make sure the
>>     "grandchild" processes created by the test don't run too long (60s vs.
>>     6666s) because in the case of test problems these processes will
>> pollute
>>     the process space, make sure the test fails with an error and doesn't
>> hang
>>     indefinitley in the case of a problem).
>>
>>   *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this
>> intended?
>>
>> Well, _AIX is defined in some system headers while AIX is defined by the
>> build system. This is already used inconsistently (i.e. __linux__ vs.
>> LINUX)
>> and in general I try to be consistent with the style of the file where I
>> the changes are. That said, I changes most of the occurences of AIX to
>> _AIX.
>>
>>
>> *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are
>> they supposed to be there?
>>
>> We currently don't support OS/400 (later renamed into i5/OS and currently
>> called IBM i) in our OpenJDK port but we do support it in our internel,
>> SAP
>> JVM build. We stripped out all the extra OS/400 functionality from the
>> port
>> but in some places where there is common functionality needd by both, AIX
>> and OS/400 the OS/400 support may still be visible in the OpenJDK port. I
>> don't think this is a real problem and it helps us to keep our internel
>> sources in sync with the OpenJDK port. That said, I think I've removed all
>> the references to OS/400 now.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131125/bd221e42/attachment.html>

From lana.steuck at oracle.com  Mon Nov 25 22:35:46 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 25 Nov 2013 22:35:46 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d: 4 new changesets
Message-ID: <20131125223547.E12F162831@hg.openjdk.java.net>

Changeset: c1029b02ca87
Author:    ihse
Date:      2013-11-08 09:36 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/c1029b02ca87

8027836: Webrev should handle files that has been moved from a directory which now is removed.
Reviewed-by: mduigou, tbell

! make/scripts/webrev.ksh

Changeset: cbfe5da942c6
Author:    katleman
Date:      2013-11-11 15:06 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/cbfe5da942c6

Merge


Changeset: a4afb0a8d55e
Author:    cl
Date:      2013-11-14 09:04 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/a4afb0a8d55e

Added tag jdk8-b116 for changeset cbfe5da942c6

! .hgtags

Changeset: 0a6db1aac998
Author:    cl
Date:      2013-11-21 09:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/0a6db1aac998

Added tag jdk8-b117 for changeset a4afb0a8d55e

! .hgtags



From lana.steuck at oracle.com  Mon Nov 25 22:35:47 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 25 Nov 2013 22:35:47 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jaxp: 2 new changesets
Message-ID: <20131125223613.7E04462835@hg.openjdk.java.net>

Changeset: c1d234d4f164
Author:    cl
Date:      2013-11-14 09:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/c1d234d4f164

Added tag jdk8-b116 for changeset e757eb9aee3d

! .hgtags

Changeset: e4e5069250e7
Author:    cl
Date:      2013-11-21 09:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/e4e5069250e7

Added tag jdk8-b117 for changeset c1d234d4f164

! .hgtags



From lana.steuck at oracle.com  Mon Nov 25 22:35:47 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 25 Nov 2013 22:35:47 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jaxws: 2 new changesets
Message-ID: <20131125223612.0795962834@hg.openjdk.java.net>

Changeset: fe56ba456fd3
Author:    cl
Date:      2013-11-14 09:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxws/rev/fe56ba456fd3

Added tag jdk8-b116 for changeset 587560c222a2

! .hgtags

Changeset: 76a598cf50c4
Author:    cl
Date:      2013-11-21 09:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxws/rev/76a598cf50c4

Added tag jdk8-b117 for changeset fe56ba456fd3

! .hgtags



From lana.steuck at oracle.com  Mon Nov 25 22:36:04 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 25 Nov 2013 22:36:04 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/langtools: 19 new changesets
Message-ID: <20131125223727.91A6D62837@hg.openjdk.java.net>

Changeset: 64d119680f0a
Author:    cl
Date:      2013-11-14 09:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/64d119680f0a

Added tag jdk8-b116 for changeset 3c040b04af05

! .hgtags

Changeset: cc80c03c41e4
Author:    vromero
Date:      2013-11-01 19:08 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/cc80c03c41e4

8027660: javac crash while creating LVT entry for a local variable defined in an inner block
Reviewed-by: jjg
Contributed-by: vicente.romero at oracle.com, jan.lahoda at oracle.com

! src/share/classes/com/sun/tools/javac/jvm/Code.java
! test/tools/javac/flow/LVTHarness.java
+ test/tools/javac/flow/tests/TestCaseLocalInInnerBlock.java

Changeset: 8b4e1421a9b7
Author:    jlahoda
Date:      2013-11-01 21:43 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/8b4e1421a9b7

8027310: Annotation Processor crashes with NPE
Summary: JCAnnotation.attribute is null when annotation type is unavailable
Reviewed-by: jjg, jfranck

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/processing/errors/CrashOnNonExistingAnnotation/Processor.java
+ test/tools/javac/processing/errors/CrashOnNonExistingAnnotation/Source.java

Changeset: 106b8fa32d71
Author:    cl
Date:      2013-11-04 17:38 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/106b8fa32d71

8025844: Need test to provide coverage for new DocumentationTool.Location enum
Reviewed-by: jjg

+ test/tools/javadoc/api/basic/DocumentationToolLocationTest.java

Changeset: 658861d1b36e
Author:    cl
Date:      2013-11-04 18:04 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/658861d1b36e

8027411: javap tonga tests cleanup: write a java program to test invalid options -h and -b
Reviewed-by: jjg

+ test/tools/javap/InvalidOptions.java

Changeset: 126dc007ba3f
Author:    cl
Date:      2013-11-04 18:51 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/126dc007ba3f

8027530: javap tonga tests cleanup: test -public, -protected, -package, -private options
Reviewed-by: jjg

+ test/tools/javap/AccessModifiers.java

Changeset: 75c8cde12ab6
Author:    jlahoda
Date:      2013-11-06 17:48 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/75c8cde12ab6

8027281: Incorrect invokespecial generated for JCK lang EXPR/expr636/expr63602m* tests
Summary: When invoking interface default method via a superclass, use the direct superclass in the reference.
Reviewed-by: vromero, dlsmith, jjg

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/defaultMethods/super/TestDirectSuperInterfaceInvoke.java

Changeset: e39bd9401ea5
Author:    darcy
Date:      2013-11-07 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/e39bd9401ea5

8027730: Fix release-8 type visitors to support intersection types
Reviewed-by: jjg, jlahoda, sogoel

! src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java
! src/share/classes/javax/lang/model/util/TypeKindVisitor8.java
+ test/tools/javac/processing/model/util/TestIntersectionTypeVisitors.java

Changeset: 21294feaf311
Author:    lana
Date:      2013-11-08 17:39 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/21294feaf311

Merge


Changeset: 6e0f31d61e56
Author:    jlahoda
Date:      2013-11-09 15:24 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/6e0f31d61e56

8027142: Invokedynamic instructions don't get line number table entries
Summary: When emitting invokedynamic instruction, write pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself does not set the pendingStatPos.
Reviewed-by: jjg, jrose, ksrini, vromero

! src/share/classes/com/sun/tools/javac/jvm/Code.java
! test/tools/javac/T8019486/WrongLNTForLambdaTest.java
! test/tools/javac/lambda/TestInvokeDynamic.java

Changeset: 4788eb38cac5
Author:    emc
Date:      2013-11-11 09:47 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/4788eb38cac5

8027439: Compile-time error in the case of ((Integer[] & Serializable)new Integer[1]).getClass()
8027253: javac illegally accepts array as bound
Summary: backing out change allowing arrays in intersection types
Reviewed-by: vromero

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
- test/tools/javac/ArraysInIntersections.java
- test/tools/javac/InferArraysInIntersections.java
- test/tools/javac/diags/examples/InterfaceOrArrayExpected.java
! test/tools/javac/generics/typevars/6680106/T6680106.out

Changeset: f3ca12d680f3
Author:    jfranck
Date:      2013-11-11 17:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/f3ca12d680f3

8027375: javac asserts on nested erroneous annotations
Summary: make sure JCAnnotation trees have type != null before annotation processing
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Annotate.java
+ test/tools/javac/annotations/testCrashNestedAnnos/TestCrashNestedAnnos.java
+ test/tools/javac/annotations/testCrashNestedAnnos/TestCrashNestedAnnos.out

Changeset: f90d88913c5f
Author:    sogoel
Date:      2013-11-13 16:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/f90d88913c5f

8025113: Convert 7 tools TryWithResources tests to jtreg format
Reviewed-by: darcy, jjg

+ test/tools/javac/TryWithResources/ResDeclOutsideTry.java
+ test/tools/javac/TryWithResources/ResDeclOutsideTry.out
+ test/tools/javac/TryWithResources/ResInNestedExpr.java
+ test/tools/javac/TryWithResources/ResourceNameConflict.java
+ test/tools/javac/TryWithResources/ResourceNameConflict.out
+ test/tools/javac/TryWithResources/ResourceRedecl.java
+ test/tools/javac/TryWithResources/ResourceRedecl.out
+ test/tools/javac/TryWithResources/ResourceShadow.java
+ test/tools/javac/TryWithResources/TestTwr09.java

Changeset: 24eaf41a3974
Author:    emc
Date:      2013-11-14 12:32 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/24eaf41a3974

8028282: Remove @ignore from test langtools/test/tools/javac/T7042623.java
Summary: Remove @ignore from test
Reviewed-by: jjg

! test/tools/javac/T7042623.java

Changeset: e79d6425f1c4
Author:    vromero
Date:      2013-11-14 19:28 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/e79d6425f1c4

8026963: type annotations code crashes for code with erroneous trees
Reviewed-by: jjg, jlahoda

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/T8026963/TypeAnnotationsCrashWithErroneousTreeTest.java
+ test/tools/javac/T8026963/TypeAnnotationsCrashWithErroneousTreeTest.out

Changeset: 5ae66d372d57
Author:    bpatel
Date:      2013-11-14 13:47 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/5ae66d372d57

8025524: javadoc does not correctly locate constructors for nested classes
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java
! test/com/sun/javadoc/testAnchorNames/TestAnchorNames.java
+ test/com/sun/javadoc/testConstructors/TestConstructors.java
+ test/com/sun/javadoc/testConstructors/pkg1/Outer.java
! test/tools/javadoc/generics/genericInnerAndOuter/expected.out

Changeset: d4cbb671de1c
Author:    vromero
Date:      2013-11-15 11:08 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/d4cbb671de1c

8026231: Look at 'static' flag when checking method references
Reviewed-by: jjg, dlsmith

! src/share/classes/com/sun/tools/javac/code/Kinds.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! test/tools/javac/lambda/MethodReference22.java
! test/tools/javac/lambda/MethodReference22.out
! test/tools/javac/lambda/MethodReference51.java
! test/tools/javac/lambda/MethodReference68.out
+ test/tools/javac/lambda/MethodReference73.java
+ test/tools/javac/lambda/MethodReference73.out
! test/tools/javac/lambda/TargetType60.java
! test/tools/javac/lambda/TargetType60.out

Changeset: 19de039a03a6
Author:    lana
Date:      2013-11-15 07:15 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/19de039a03a6

Merge

- test/tools/javac/ArraysInIntersections.java
- test/tools/javac/InferArraysInIntersections.java
- test/tools/javac/diags/examples/InterfaceOrArrayExpected.java

Changeset: 4fd6a7ff8c06
Author:    cl
Date:      2013-11-21 09:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/4fd6a7ff8c06

Added tag jdk8-b117 for changeset 19de039a03a6

! .hgtags



From lana.steuck at oracle.com  Mon Nov 25 22:36:32 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 25 Nov 2013 22:36:32 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/hotspot: 54 new changesets
Message-ID: <20131125223841.8FFC162838@hg.openjdk.java.net>

Changeset: 5b84039ca739
Author:    amurillo
Date:      2013-11-01 08:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/5b84039ca739

8027580: new hotspot build - hs25-b58
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: ea79ab313e98
Author:    mgerdin
Date:      2013-10-30 15:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/ea79ab313e98

8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes
Summary: Use 2-byte loads to load indexes from the byte code stream to avoid out of bounds reads.
Reviewed-by: coleenp, sspitsyn

! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp

Changeset: fdd464c8d62e
Author:    acorn
Date:      2013-10-30 09:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/fdd464c8d62e

8027304: Lambda: inheriting abstract + 1 default -> default, not ICCE
Reviewed-by: hseigel, zgu

! src/share/vm/classfile/defaultMethods.cpp

Changeset: 4fe7815b04f5
Author:    acorn
Date:      2013-10-30 09:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/4fe7815b04f5

Merge


Changeset: c8fc12209830
Author:    coleenp
Date:      2013-10-31 14:11 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/c8fc12209830

8027616: Off by one error in putback for compressed oops nashorn performance improvement
Summary: Should compare bounds greater than or equal 4G when deciding if shift is needed or CDS area + compressed class space are within 4G of each other.
Reviewed-by: stefank, hseigel, zgu

! src/share/vm/memory/metaspace.cpp

Changeset: 910026b800b8
Author:    coleenp
Date:      2013-11-01 10:32 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/910026b800b8

8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use MethodHandle
8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might not work with anonymous classes
Summary: Walk methods in breakpoints for marking on stack so they aren't deallocated by redefine classes.  Use class_holder rather than class_loader to keep GC from reclaiming class owning the method.
Reviewed-by: sspitsyn, ehelin, sla

! src/share/vm/classfile/metadataOnStackMark.cpp
! src/share/vm/prims/jvmtiImpl.cpp
! src/share/vm/prims/jvmtiImpl.hpp

Changeset: 42790b7e4d48
Author:    mgronlun
Date:      2013-11-01 15:56 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/42790b7e4d48

Merge

! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp

Changeset: f8b56489e455
Author:    mgronlun
Date:      2013-11-01 17:10 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/f8b56489e455

Merge


Changeset: 04df110c8655
Author:    mgronlun
Date:      2013-11-02 20:56 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/04df110c8655

Merge


Changeset: 208ebea980f8
Author:    roland
Date:      2013-11-04 21:59 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/208ebea980f8

8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I
Summary: String.equals() intrinsic shouldn't use integer length input in pointer arithmetic without an i2l.
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/sparc.ad
+ test/compiler/intrinsics/stringequals/TestStringEqualsBadLength.java

Changeset: e428d5e768e3
Author:    rbackman
Date:      2013-11-04 10:44 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e428d5e768e3

8027622: java.time.Instant.create failing since hs25-b56
Reviewed-by: kvn, iveresov

! src/share/vm/opto/compile.cpp
+ test/compiler/intrinsics/mathexact/CompareTest.java

Changeset: a905d33ce13a
Author:    iveresov
Date:      2013-11-05 00:59 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a905d33ce13a

8027751: C1 crashes in Weblogic with G1 enabled
Summary: Keep T_OBJECT operands in registers for logical operations on x64
Reviewed-by: kvn, roland

! src/share/vm/c1/c1_LinearScan.cpp
+ test/compiler/regalloc/C1ObjectSpillInLogicOp.java

Changeset: 94a83e0f9ce1
Author:    iveresov
Date:      2013-11-05 01:57 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/94a83e0f9ce1

8017065: C2 allows safepoint checks to leak into G1 pre-barriers
Summary: Make all raw loads strictly respect control dependencies, make sure RCE doesn't move raw loads, add verification of G1 pre-barriers.
Reviewed-by: kvn, roland

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/memnode.hpp

Changeset: 613e6a6fc328
Author:    iveresov
Date:      2013-11-05 02:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/613e6a6fc328

Merge

! src/share/vm/opto/compile.cpp

Changeset: be525e91f65b
Author:    mikael
Date:      2013-11-06 06:51 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/be525e91f65b

8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION
Summary: Uncommon trap blob did not bang all the stack shadow pages
Reviewed-by: kvn, twisti, iveresov, jrose

! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/share/vm/asm/assembler.cpp
+ test/compiler/uncommontrap/UncommonTrapStackBang.java

Changeset: 53662b2f1d68
Author:    drchase
Date:      2013-11-07 10:02 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/53662b2f1d68

Merge


Changeset: e510dfdec6dd
Author:    amurillo
Date:      2013-11-08 07:02 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e510dfdec6dd

Merge


Changeset: 52b076e6ffae
Author:    amurillo
Date:      2013-11-08 07:02 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/52b076e6ffae

Added tag hs25-b58 for changeset e510dfdec6dd

! .hgtags

Changeset: aec3226be72d
Author:    cl
Date:      2013-11-14 09:04 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/aec3226be72d

Added tag jdk8-b116 for changeset 52b076e6ffae

! .hgtags

Changeset: 20c72bec2707
Author:    amurillo
Date:      2013-11-08 07:13 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/20c72bec2707

8028061: new hotspot build - hs25-b59
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 9d8b29a0548c
Author:    mgerdin
Date:      2013-11-08 16:48 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/9d8b29a0548c

8027237: New tests on ReservedSpace/VirtualSpace classes
Summary: Three tests added: 1) test stressing VirtualSpace by resizing it constantly 2) test running unit tests in several threads 3) test checking protected area in ReservedHeapSpace class
Reviewed-by: stefank, zgu
Contributed-by: aleksey.timofeev at oracle.com

! src/share/vm/prims/whitebox.cpp
+ test/runtime/memory/ReadFromNoaccessArea.java
+ test/runtime/memory/RunUnitTestsConcurrently.java
+ test/runtime/memory/StressVirtualSpaceResize.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 19f8a5d7600b
Author:    mgerdin
Date:      2013-11-08 23:49 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/19f8a5d7600b

Merge


Changeset: fce21ac5968d
Author:    acorn
Date:      2013-11-13 07:31 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/fce21ac5968d

8027229: ICCE expected for >=2 maximally specific default methods.
Summary: Need to process defaults for interfaces for invokespecial
Reviewed-by: lfoltan, hseigel, coleenp, jrose

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/defaultMethods.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/oops/klassVtable.cpp

Changeset: 41cb10cbfb3c
Author:    coleenp
Date:      2013-11-13 16:42 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/41cb10cbfb3c

8025937: assert(existing_f1 == NULL || existing_f1 == f1) failed: illegal field change
Summary: Create extra constant pool cache entries for invokespecial/InterfaceMethodref to hold the alternate resolution.
Reviewed-by: jrose, lfoltan, hseigel

! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/interpreter/rewriter.hpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/cpCache.hpp

Changeset: 4288e54fd145
Author:    jwilhelm
Date:      2013-10-21 18:51 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/4288e54fd145

8026851: Remove unnecessary code in GenRemSet
Summary: Removed the GenRemSet::rem_set_name() since we only have one remset.
Reviewed-by: stefank, mgerdin, tschatzl

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.hpp

Changeset: 3aee6bc29547
Author:    jwilhelm
Date:      2013-10-21 18:52 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3aee6bc29547

8026852: Use restricted_align_down in collector policy code
Summary: Moved restricted_align_down to globalDefinitions and renamed it align_size_down_bounded
Reviewed-by: stefank, mgerdin, tschatzl

! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 46d7652b223c
Author:    jwilhelm
Date:      2013-10-21 18:56 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/46d7652b223c

8026853: Prepare GC code for collector policy regression fix
Summary: Cleanup related to the NewSize and MaxNewSize bugs
Reviewed-by: tschatzl, jcoomes, ehelin

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp
! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 8f07aa079343
Author:    jwilhelm
Date:      2013-11-01 17:09 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/8f07aa079343

8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking
7057939: jmap shows MaxNewSize=4GB when Java is using parallel collector
Summary: Major cleanup of the collectorpolicy classes
Reviewed-by: tschatzl, jcoomes

! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp
! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp
! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp
! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp
+ src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp
! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp
! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/arguments.cpp
! test/gc/arguments/TestMaxHeapSizeTools.java
+ test/gc/arguments/TestMaxNewSize.java

Changeset: 610be0309a79
Author:    amurillo
Date:      2013-11-02 13:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/610be0309a79

Merge

! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 28674af341ac
Author:    tschatzl
Date:      2013-11-07 15:17 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/28674af341ac

8027756: assert(!hr->isHumongous()) failed: code root in humongous region?
Summary: Change checks for isHumongous() to continuesHumongous() as installing a code root for a humongous object is valid, but not for continuations of humongous objects. Cleaned up asserts.
Reviewed-by: jmasa, tamao

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
+ test/gc/g1/TestHumongousCodeCacheRoots.java

Changeset: 40b8c6bad703
Author:    jmasa
Date:      2013-10-16 15:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/40b8c6bad703

8024954: CMS: CMSClassUnloadingMaxInterval is not implemented correctly. This change is also part of the fix for 8024483.
Reviewed-by: mgerdin, brutisso, tschatzl
Contributed-by: jwha at google.com

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp

Changeset: 592d8b01fedd
Author:    jmasa
Date:      2013-11-08 06:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/592d8b01fedd

8024483: assertion failure: (!mirror_alive || loader_alive) failed:
Reviewed-by: brutisso, tschatzl, mgerdin

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp

Changeset: 3ad2b68d107e
Author:    jwilhelm
Date:      2013-11-10 00:07 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3ad2b68d107e

8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java
Summary: Update NewSize when _initial_gen0_size is changed
Reviewed-by: tschatzl, brutisso

! src/share/vm/memory/collectorPolicy.cpp

Changeset: 236cecd9ec97
Author:    jwilhelm
Date:      2013-11-11 13:50 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/236cecd9ec97

8028093: Initial young size is smaller than minimum young size
Summary: Remove min_gen1_size argument from adjust_gen0_sizes()
Reviewed-by: tschatzl, brutisso

! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.hpp

Changeset: bde526e3667e
Author:    jwilhelm
Date:      2013-11-11 05:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/bde526e3667e

Merge


Changeset: 11b116661830
Author:    mgerdin
Date:      2013-11-11 16:20 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/11b116661830

Merge

! src/share/vm/memory/metaspace.cpp

Changeset: ee527493b36d
Author:    sjohanss
Date:      2013-11-08 17:46 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/ee527493b36d

8027960: Assertion assert(end >= start) failed during nightly testing on solaris
Summary: Needed to update _space_alignment in generation sizer to ensure correct sizing of spaces.
Reviewed-by: jmasa, tschatzl

! src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp

Changeset: 755c423791ab
Author:    ehelin
Date:      2013-11-14 21:05 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/755c423791ab

Merge

! src/share/vm/prims/whitebox.cpp

Changeset: e2509677809c
Author:    vlivanov
Date:      2013-11-08 01:13 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e2509677809c

8023037: Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie
Reviewed-by: kvn, iveresov

! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 83c8f6f4ab09
Author:    drchase
Date:      2013-11-08 14:19 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/83c8f6f4ab09

Merge


Changeset: 1dcea64e9f00
Author:    kvn
Date:      2013-11-11 11:53 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1dcea64e9f00

8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get
Summary: Exclude last input argument's stack slots from vector's spilling masks.
Reviewed-by: iveresov

! src/share/vm/opto/matcher.cpp

Changeset: 78da3894b86f
Author:    anoll
Date:      2013-11-12 09:32 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/78da3894b86f

8027593: performance drop with constrained codecache starting with hs25 b111
Summary: Fixed proper sweeping of small code cache sizes
Reviewed-by: kvn, iveresov

! src/share/vm/code/nmethod.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/sweeper.hpp

Changeset: 144b23411b51
Author:    roland
Date:      2013-11-12 13:58 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/144b23411b51

8027632: assert(xtype->klass_is_exact()) failed: Should be exact at graphKit.cpp
Summary: receiver type collected by profiling for default method may be interface
Reviewed-by: kvn, iveresov

! src/share/vm/c1/c1_GraphBuilder.cpp

Changeset: f675976a61e7
Author:    rbackman
Date:      2013-11-12 13:47 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/f675976a61e7

8028198: SIGSEGV in PhaseIdealLoop::build_loop_late_post
Reviewed-by: iveresov, kvn

! src/share/vm/opto/loopopts.cpp
+ test/compiler/intrinsics/mathexact/SplitThruPhiTest.java

Changeset: b957c650babb
Author:    rbackman
Date:      2013-11-12 14:52 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b957c650babb

8028207: assert(_outcnt==1) failed: not unique in compile.cpp
Reviewed-by: iveresov, kvn

! src/share/vm/opto/mathexactnode.hpp
+ test/compiler/intrinsics/mathexact/GVNTest.java

Changeset: e6ba215af802
Author:    roland
Date:      2013-11-13 09:45 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e6ba215af802

8027631: "unexpected profiling mismatch" error with new type profiling
Summary: inlined method handle calls can call methods with different signatures
Reviewed-by: kvn, iveresov

! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
+ test/compiler/profiling/TestUnexpectedProfilingMismatch.java

Changeset: 924c32982a12
Author:    roland
Date:      2013-11-13 01:50 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/924c32982a12

Merge


Changeset: 6e1826d5c23e
Author:    roland
Date:      2013-11-13 13:45 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/6e1826d5c23e

8027572: assert(r != 0) failed: invalid
Summary: null classes should be expected in profiles with conflicts
Reviewed-by: kvn, iveresov

! src/share/vm/ci/ciMethodData.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/methodData.hpp
+ test/compiler/profiling/unloadingconflict/B.java
+ test/compiler/profiling/unloadingconflict/TestProfileConflictClassUnloading.java

Changeset: e74074c34312
Author:    vlivanov
Date:      2013-11-14 09:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e74074c34312

8028159: C2: compiler stack overflow during inlining of @ForceInline methods
Reviewed-by: roland, kvn

! src/share/vm/c1/c1_globals.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/runtime/globals.hpp

Changeset: df0df745224c
Author:    drchase
Date:      2013-11-14 15:58 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/df0df745224c

Merge


Changeset: 6f206b5d258f
Author:    drchase
Date:      2013-11-14 13:38 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/6f206b5d258f

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: c78d517c7ea4
Author:    amurillo
Date:      2013-11-15 07:50 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/c78d517c7ea4

Merge


Changeset: f573d00213b7
Author:    amurillo
Date:      2013-11-15 07:50 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/f573d00213b7

Added tag hs25-b59 for changeset c78d517c7ea4

! .hgtags

Changeset: 55be5aac78e2
Author:    cl
Date:      2013-11-21 09:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/55be5aac78e2

Added tag jdk8-b117 for changeset f573d00213b7

! .hgtags



From lana.steuck at oracle.com  Mon Nov 25 22:36:02 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 25 Nov 2013 22:36:02 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/nashorn: 14 new changesets
Message-ID: <20131125223636.1012662836@hg.openjdk.java.net>

Changeset: 774c63629870
Author:    cl
Date:      2013-11-14 09:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/774c63629870

Added tag jdk8-b116 for changeset 0fb1a427fbf6

! .hgtags

Changeset: ae5f2130c3b9
Author:    sundar
Date:      2013-11-01 19:54 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/ae5f2130c3b9

8027700: function redeclaration checks missing for declaration binding instantiation
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/codegen/MapCreator.java
! src/jdk/nashorn/internal/ir/Symbol.java
! src/jdk/nashorn/internal/runtime/Property.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! test/script/basic/JDK-8015355.js
+ test/script/basic/JDK-8027700.js

Changeset: 98bab0cdd7bf
Author:    attila
Date:      2013-11-01 15:36 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/98bab0cdd7bf

8027236: Ensure ScriptObject and ConsString aren't visible to Java
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk/nashorn/internal/runtime/ConsString.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java
! src/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
+ src/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
+ test/script/basic/JDK-8027236.js
+ test/script/basic/JDK-8027236.js.EXPECTED
+ test/src/jdk/nashorn/api/javaaccess/ConsStringTest.java

Changeset: 144861e24260
Author:    sundar
Date:      2013-11-04 09:29 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/144861e24260

Merge


Changeset: dcedc753fd09
Author:    sundar
Date:      2013-11-04 18:52 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/dcedc753fd09

8027753: Support ScriptObject to JSObject, ScriptObjectMirror, Map, Bindings auto-conversion as well as explicit wrap, unwrap
Reviewed-by: jlaskey, hannesw, attila

! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/api/scripting/ScriptUtils.java
! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java
+ test/script/basic/JDK-8027753.js
+ test/script/basic/JDK-8027753.js.EXPECTED
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java
! test/src/jdk/nashorn/api/scripting/Window.java

Changeset: b0d4ef6fb2db
Author:    sundar
Date:      2013-11-05 09:13 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/b0d4ef6fb2db

Merge


Changeset: bda654c6d59c
Author:    kshefov
Date:      2013-11-05 13:09 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/bda654c6d59c

8027708: NASHORN TEST: Create Nashorn test that draws image step-by-step using JavaFX canvas.
Reviewed-by: jlaskey, lagergren

! make/build.xml
! make/project.properties
! test/script/jfx.js
! test/script/jfx/flyingimage.js
! test/script/jfx/flyingimage/flyingimage.png
! test/script/jfx/flyingimage/golden/linux.png
! test/script/jfx/flyingimage/golden/macosx.png
! test/script/jfx/flyingimage/golden/windows.png
! test/script/jfx/kaleidoscope.js
! test/script/jfx/kaleidoscope/golden/linux.png
! test/script/jfx/kaleidoscope/golden/macosx.png
! test/script/jfx/kaleidoscope/golden/windows.png
+ test/script/jfx/spread.js
+ test/script/jfx/spread/golden/linux.png
+ test/script/jfx/spread/golden/macosx.png
+ test/script/jfx/spread/golden/windows.png

Changeset: 2f07b4234451
Author:    sundar
Date:      2013-11-07 17:26 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/2f07b4234451

8027828: ClassCastException when converting return value of a Java method to boolean
Reviewed-by: jlaskey, attila

! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/api/scripting/ScriptUtils.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java
+ test/script/basic/JDK-8027828.js
+ test/script/basic/JDK-8027828.js.EXPECTED
+ test/script/basic/convert.js
+ test/script/basic/convert.js.EXPECTED
! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java

Changeset: 3b794f364c77
Author:    sundar
Date:      2013-11-07 18:11 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/3b794f364c77

Merge


Changeset: d091499d67fc
Author:    lana
Date:      2013-11-08 17:39 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/d091499d67fc

Merge


Changeset: e65a98146b94
Author:    attila
Date:      2013-11-11 14:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/e65a98146b94

8028020: Function parameter as last expression in comma in return value causes bad type calculation
Reviewed-by: jlaskey, lagergren, sundar

! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
+ test/script/basic/JDK-8028020.js
+ test/script/basic/JDK-8028020.js.EXPECTED

Changeset: 2f0f8d1d0753
Author:    sundar
Date:      2013-11-12 10:23 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/2f0f8d1d0753

Merge


Changeset: 1db3d4e4d189
Author:    lana
Date:      2013-11-15 07:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/1db3d4e4d189

Merge


Changeset: 8d014b039b44
Author:    cl
Date:      2013-11-21 09:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/8d014b039b44

Added tag jdk8-b117 for changeset 1db3d4e4d189

! .hgtags



From lana.steuck at oracle.com  Mon Nov 25 22:40:16 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 25 Nov 2013 22:40:16 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 95 new changesets
Message-ID: <20131125225927.6B3E66283B@hg.openjdk.java.net>

Changeset: bdcba4854576
Author:    erikj
Date:      2013-11-07 10:51 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/bdcba4854576

8027698: Platform specific jars are not being signed by the sign-jars target
Reviewed-by: ihse, tbell, wetmore

! makefiles/SignJars.gmk

Changeset: 295a641fc86b
Author:    erikj
Date:      2013-11-07 14:06 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/295a641fc86b

8027406: JDK demos are missing source files
Reviewed-by: alexsch, ihse

! makefiles/CompileDemos.gmk

Changeset: 43168d403243
Author:    anthony
Date:      2013-11-08 20:07 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/43168d403243

8027912: [macosx] Provide means to force the headful mode on OS X when running via ssh
Summary: Bypass AquaSession check if AWT_FORCE_HEADFUL env. variable is set to TRUE
Reviewed-by: anthony, art
Contributed-by: David Dehaven <david.dehaven at oracle.com>

! src/solaris/native/java/lang/java_props_macosx.c

Changeset: 0dc0067f3b8e
Author:    katleman
Date:      2013-11-11 15:06 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0dc0067f3b8e

Merge


Changeset: 483148bf625e
Author:    cl
Date:      2013-11-14 09:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/483148bf625e

Added tag jdk8-b116 for changeset 0dc0067f3b8e

! .hgtags

Changeset: b691a6abf9e0
Author:    lana
Date:      2013-11-14 23:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b691a6abf9e0

Merge


Changeset: 30766f910509
Author:    malenkov
Date:      2013-11-01 21:45 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/30766f910509

8026491: Typos in string literals
Reviewed-by: alexsch, anthony

! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java
! src/macosx/classes/com/apple/laf/resources/aqua.properties
! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormatResources.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.java
! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java
! src/share/classes/com/sun/tools/script/shell/init.js
! src/share/classes/com/sun/tools/script/shell/messages.properties
! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java
! src/share/classes/javax/swing/KeyboardManager.java
! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java
! src/share/classes/javax/swing/text/AbstractDocument.java
! src/share/classes/sun/awt/AppContext.java
! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java
! src/share/classes/sun/misc/ExtensionDependency.java
! src/share/classes/sun/rmi/rmic/RMIGenerator.java
! src/share/classes/sun/security/jgss/krb5/InitialToken.java
! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java
! src/share/native/sun/security/pkcs11/wrapper/p11_util.c
! src/share/sample/nio/chatserver/ClientReader.java
! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
! src/windows/classes/sun/security/krb5/internal/tools/Klist.java
! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java

Changeset: b8eb21e93fa7
Author:    yan
Date:      2013-11-07 18:57 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b8eb21e93fa7

8025234: [javadoc] fix some errors in javax.swing.**
Reviewed-by: alexsch, malenkov
Contributed-by: Dmitry Ginzburg <dmitry.x.ginzburg at oracle.com>

! src/share/classes/javax/swing/AbstractButton.java
! src/share/classes/javax/swing/Action.java
! src/share/classes/javax/swing/Box.java
! src/share/classes/javax/swing/BoxLayout.java
! src/share/classes/javax/swing/CellRendererPane.java
! src/share/classes/javax/swing/DefaultListSelectionModel.java
! src/share/classes/javax/swing/DesktopManager.java
! src/share/classes/javax/swing/GroupLayout.java
! src/share/classes/javax/swing/JComponent.java
! src/share/classes/javax/swing/JEditorPane.java
! src/share/classes/javax/swing/JFileChooser.java
! src/share/classes/javax/swing/JLabel.java
! src/share/classes/javax/swing/JList.java
! src/share/classes/javax/swing/JMenu.java
! src/share/classes/javax/swing/JMenuBar.java
! src/share/classes/javax/swing/JTextField.java

Changeset: 29f979efbabf
Author:    malenkov
Date:      2013-11-08 14:09 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/29f979efbabf

8027648: Type of overridden property is resolved incorrectly
Reviewed-by: alexsch

! src/share/classes/java/beans/IndexedPropertyDescriptor.java
! src/share/classes/java/beans/Introspector.java
! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java
+ test/java/beans/Introspector/Test8027648.java
+ test/java/beans/Introspector/Test8027905.java

Changeset: 184f13eeed41
Author:    lana
Date:      2013-11-08 15:02 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/184f13eeed41

Merge

- src/share/classes/java/lang/invoke/MagicLambdaImpl.java
- src/share/demo/jfc/Notepad/resources/Notepad_fr.properties
- src/share/demo/jfc/Notepad/resources/Notepad_sv.properties
- test/java/net/NetworkInterface/MemLeakTest.java
- test/jdk/lambda/vm/DefaultMethodsTest.java
- test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
- test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh
- test/sun/tools/jstatd/jpsOutput1.awk
- test/sun/tools/jstatd/jstatGcutilOutput1.awk
- test/sun/tools/jstatd/jstatdDefaults.sh
- test/sun/tools/jstatd/jstatdExternalRegistry.sh
- test/sun/tools/jstatd/jstatdPort.sh
- test/sun/tools/jstatd/jstatdServerName.sh
- test/sun/tools/jstatd/jstatdUsage1.sh
- test/sun/tools/jstatd/usage.out

Changeset: 4bc2414624e2
Author:    leonidr
Date:      2013-11-12 20:02 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4bc2414624e2

8027972: [macosx] Provide a regression test for JDK-8007006
Reviewed-by: anthony

+ test/java/awt/MenuBar/8007006/bug8007006.java

Changeset: 0242fce0f717
Author:    serb
Date:      2013-11-12 20:24 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0242fce0f717

8027696: Incorrect copyright header in the tests
Reviewed-by: alanb, malenkov, mullan

! test/ProblemList.txt
! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/Client.java
! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/ConfigKey.java
! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/TestNotification.java
! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/ConfigKey.java
! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Server.java
! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Ste.java
! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/SteMBean.java
! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/TestNotification.java
! test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
! test/com/sun/jndi/cosnaming/CNNameParser.java
! test/com/sun/jndi/cosnaming/IiopUrlIPv6.java
! test/demo/zipfs/ZipFSTester.java
! test/java/awt/AlphaComposite/TestAlphaCompositeForNaN.java
! test/java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.html
! test/java/awt/Choice/NonFocusablePopupMenuTest/NonFocusablePopupMenuTest.html
! test/java/awt/Component/F10TopToplevel/F10TopToplevel.html
! test/java/awt/Component/UpdatingBootTime/UpdatingBootTime.html
! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html
! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/NextFramePositionCalculator.java
! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/SourcePanel.java
! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/TargetPanel.java
! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html
! test/java/awt/EventQueue/MainAppContext/MainAppContext.java
! test/java/awt/EventQueue/PostEventOrderingTest/PostEventOrderingTest.java
! test/java/awt/FileDialog/FileDialogReturnTest/FileDialogReturnTest.html
! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.html
! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.java
! test/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.html
! test/java/awt/FileDialog/MultipleMode/MultipleMode.html
! test/java/awt/FileDialog/RegexpFilterTest/RegexpFilterTest.html
! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.html
! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.java
! test/java/awt/Focus/6981400/Test1.java
! test/java/awt/Focus/6981400/Test2.java
! test/java/awt/Focus/6981400/Test3.java
! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.html
! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.html
! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java
! test/java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.html
! test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java
! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP.java
! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_AWT.java
! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_Swing.java
! test/java/awt/Focus/ModalBlockedStealsFocusTest/ModalBlockedStealsFocusTest.html
! test/java/awt/Focus/ToFrontFocusTest/ToFrontFocus.html
! test/java/awt/Focus/WindowInitialFocusTest/WindowInitialFocusTest.html
! test/java/awt/Frame/FrameSetSizeStressTest/FrameSetSizeStressTest.java
! test/java/awt/Frame/InitialMaximizedTest/InitialMaximizedTest.html
! test/java/awt/Frame/ShownOnPack/ShownOnPack.html
! test/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java
! test/java/awt/Graphics2D/FillTexturePaint/FillTexturePaint.java
! test/java/awt/InputMethods/InputMethodsTest/InputMethodsTest.html
! test/java/awt/JAWT/JAWT.sh
! test/java/awt/JAWT/Makefile.cygwin
! test/java/awt/JAWT/Makefile.unix
! test/java/awt/JAWT/Makefile.win
! test/java/awt/JAWT/MyCanvas.java
! test/java/awt/JAWT/myfile.c
! test/java/awt/JAWT/myfile.cpp
! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_AWT.java
! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
! test/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html
! test/java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html
! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.html
! test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html
! test/java/awt/List/SetFontTest/SetFontTest.html
! test/java/awt/Menu/NullMenuLabelTest/NullMenuLabelTest.java
! test/java/awt/Mouse/ExtraMouseClick/ExtraMouseClick.html
! test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java
! test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java
! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java
! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java
! test/java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html
! test/java/awt/Multiscreen/TranslucencyThrowsExceptionWhenFullScreen/TranslucencyThrowsExceptionWhenFullScreen.java
! test/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.html
! test/java/awt/PrintJob/Text/stringwidth.sh
! test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java
! test/java/awt/Robot/ManualInstructions/ManualInstructions.java
! test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java
! test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java
! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test.java
! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test1.java
! test/java/awt/TextArea/TextAreaCursorTest/HoveringAndDraggingTest.html
! test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java
! test/java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.html
! test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.html
! test/java/awt/Toolkit/Headless/AWTEventListener/AWTListener.java
! test/java/awt/Toolkit/Headless/ExceptionContract/ExceptionContract.java
! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJob.java
! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJobHeadless.java
! test/java/awt/Toolkit/SecurityTest/SecurityTest2.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java
! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java
! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java
! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java
! test/java/awt/Window/Grab/GrabTest.java
! test/java/awt/Window/TranslucentShapedFrameTest/TSFrame.java
! test/java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java
! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/test.html
! test/java/awt/datatransfer/DragUnicodeBetweenJVMTest/DragUnicodeBetweenJVMTest.html
! test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.html
! test/java/awt/dnd/Button2DragTest/Button2DragTest.html
! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.html
! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java
! test/java/awt/dnd/DnDFileGroupDescriptor/DnDTarget.java
! test/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.html
! test/java/awt/dnd/ImageDecoratedDnD/DnDSource.java
! test/java/awt/dnd/ImageDecoratedDnD/DnDTarget.java
! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.html
! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.java
! test/java/awt/dnd/ImageDecoratedDnD/ImageGenerator.java
! test/java/awt/dnd/ImageDecoratedDnD/MyCursor.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDSource.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDTarget.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.html
! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageGenerator.java
! test/java/awt/dnd/ImageDecoratedDnDInOut/MyCursor.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDSource.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDTarget.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.html
! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageGenerator.java
! test/java/awt/dnd/ImageDecoratedDnDNegative/MyCursor.java
! test/java/awt/dnd/URIListBetweenJVMsTest/URIListBetweenJVMsTest.html
! test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java
! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.html
! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.java
! test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.html
! test/java/awt/event/KeyEvent/KeyTyped/CtrlASCII.html
! test/java/awt/event/MouseEvent/AWTPanelSmoothWheel/AWTPanelSmoothWheel.html
! test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java
! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java
! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java
! test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java
! test/java/awt/event/MouseEvent/FrameMouseEventAbsoluteCoordsTest/FrameMouseEventAbsoluteCoordsTest.html
! test/java/awt/event/MouseEvent/MenuDragMouseEventAbsoluteCoordsTest/MenuDragMouseEventAbsoluteCoordsTest.html
! test/java/awt/event/MouseEvent/MouseClickTest/MouseClickTest.html
! test/java/awt/event/MouseEvent/MouseWheelEventAbsoluteCoordsTest/MouseWheelEventAbsoluteCoordsTest.html
! test/java/awt/event/MouseEvent/RobotLWTest/RobotLWTest.html
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.html
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.html
! test/java/awt/event/OtherEvents/UngrabID/UngrabID.java
! test/java/awt/im/4490692/bug4490692.html
! test/java/awt/im/4959409/bug4959409.html
! test/java/awt/im/JTextFieldTest.html
! test/java/awt/image/BufferedImage/TinyScale.java
! test/java/awt/image/DrawImage/EABlitTest.java
! test/java/awt/print/PrinterJob/CustomPrintService/PrintServiceStub.java
! test/java/awt/print/PrinterJob/CustomPrintService/SetPrintServiceTest.java
! test/java/awt/print/bug8023392/bug8023392.html
! test/java/awt/print/bug8023392/bug8023392.java
! test/java/beans/Introspector/6380849/beans/FirstBean.java
! test/java/beans/Introspector/6380849/beans/FirstBeanBeanInfo.java
! test/java/beans/Introspector/6380849/beans/SecondBean.java
! test/java/beans/Introspector/6380849/beans/ThirdBean.java
! test/java/beans/Introspector/6380849/infos/SecondBeanBeanInfo.java
! test/java/beans/Introspector/6380849/infos/ThirdBeanBeanInfo.java
! test/java/beans/Introspector/6976577/test/Accessor.java
! test/java/beans/Introspector/7122138/pack/Sub.java
! test/java/beans/Introspector/7122138/pack/Super.java
! test/java/beans/XMLEncoder/6380849/Bean.java
! test/java/beans/XMLEncoder/6380849/BeanPersistenceDelegate.java
! test/java/io/FileInputStream/OpsAfterClose.java
! test/java/io/FileOutputStream/OpsAfterClose.java
! test/java/io/RandomAccessFile/OpsAfterClose.java
! test/java/lang/StringBuffer/BufferForwarding.java
! test/java/lang/StringBuilder/BuilderForwarding.java
! test/java/lang/instrument/RedefineBigClassApp.java
! test/java/lang/instrument/RetransformBigClass.sh
! test/java/lang/instrument/RetransformBigClassApp.java
! test/java/lang/invoke/AccessControlTest.java
! test/java/lang/invoke/BigArityTest.java
! test/java/lang/invoke/ClassValueTest.java
! test/java/lang/invoke/InvokeGenericTest.java
! test/java/lang/invoke/JavaDocExamplesTest.java
! test/java/lang/invoke/MethodHandlesTest.java
! test/java/lang/invoke/PermuteArgsTest.java
! test/java/lang/invoke/PrivateInvokeTest.java
! test/java/lang/invoke/RevealDirectTest.java
! test/java/lang/invoke/RicochetTest.java
! test/java/lang/invoke/TestCatchExceptionWithVarargs.java
! test/java/lang/invoke/ThrowExceptionsTest.java
! test/java/lang/invoke/remote/RemoteExample.java
! test/java/lang/ref/ReferenceEnqueuePending.java
! test/java/net/URLClassLoader/closetest/build.sh
! test/java/security/cert/CertPathBuilder/selfIssued/generate.sh
! test/java/security/cert/CertPathValidator/indirectCRL/generate.sh
! test/java/security/cert/CertPathValidator/nameConstraints/generate.sh
! test/java/security/cert/CertificateRevokedException/Basic.java
! test/java/util/Calendar/CldrFormatNamesTest.java
! test/java/util/Locale/LocaleEnhanceTest.java
! test/java/util/Locale/LocaleTestFmwk.java
! test/java/util/Locale/tools/EquivMapsGenerator.java
! test/java/util/TimeZone/Bug6912560.java
! test/java/util/TimeZone/CLDRDisplayNamesTest.java
! test/java/util/TimeZone/ListTimeZones.java
! test/java/util/TimeZone/OldIDMappingTest.java
! test/java/util/TimeZone/OldIDMappingTest.sh
! test/java/util/TimeZone/SetDefaultSecurityTest.java
! test/java/util/TimeZone/TimeZoneDatePermissionCheck.java
! test/java/util/TimeZone/TzIDOldMapping.java
! test/java/util/prefs/AddNodeChangeListener.java
! test/java/util/prefs/CheckUserPrefFirst.java
! test/java/util/prefs/CheckUserPrefLater.java
! test/java/util/regex/RegExTest.java
! test/java/util/spi/ResourceBundleControlProvider/providersrc/UserControlProvider.java
! test/java/util/zip/LargeZip.java
! test/java/util/zip/TotalInOut.java
! test/javax/imageio/plugins/gif/GifTransparencyTest.java
! test/javax/management/modelmbean/LoggingExceptionTest.java
! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java
! test/javax/print/DialogMargins.java
! test/javax/print/StreamPrintingOrientation.java
! test/javax/print/applet/AppletPrintLookup.html
! test/javax/sound/midi/File/SMPTESequence.java
! test/javax/sound/midi/Gervill/AudioFloatConverter/GetFormat.java
! test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java
! test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Available.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Close.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFormat.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFrameLength.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/MarkSupported.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Read.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArray.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArrayIntInt.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Reset.java
! test/javax/sound/midi/Gervill/AudioFloatInputStream/Skip.java
! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankFile.java
! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream.java
! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream2.java
! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankUrl.java
! test/javax/sound/midi/Gervill/EmergencySoundbank/TestCreateSoundbank.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/GetInputStream.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/GetRoot.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/Load.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/LoadAll.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArray.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArrayIntInt.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFile.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFileLongLong.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Available.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Close.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkReset.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkSupported.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Read.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByte.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByteIntInt.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Skip.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLong.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLong.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLongBoolean.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/Unload.java
! test/javax/sound/midi/Gervill/ModelByteBuffer/WriteTo.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetAttenuation.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetChannels.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopLength.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopStart.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetPitchCorrection.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBuffer.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormat.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormatFloat.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferFloat.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Open.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Set8BitExtensionBuffer.java
! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/SetLoopType.java
! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestination.java
! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestinationModelIdentifier.java
! test/javax/sound/midi/Gervill/ModelDestination/SetIdentifier.java
! test/javax/sound/midi/Gervill/ModelDestination/SetTransform.java
! test/javax/sound/midi/Gervill/ModelIdentifier/EqualsObject.java
! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierString.java
! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringInt.java
! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringString.java
! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringStringInt.java
! test/javax/sound/midi/Gervill/ModelIdentifier/SetInstance.java
! test/javax/sound/midi/Gervill/ModelIdentifier/SetObject.java
! test/javax/sound/midi/Gervill/ModelIdentifier/SetVariable.java
! test/javax/sound/midi/Gervill/ModelPerformer/GetOscillators.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetConnectionBlocks.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetDefaultConnectionsEnabled.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetExclusiveClass.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyFrom.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyTo.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetName.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetSelfNonExclusive.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetVelFrom.java
! test/javax/sound/midi/Gervill/ModelPerformer/SetVelTo.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSource.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifier.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBoolean.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBoolean.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBooleanInt.java
! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierModelTransform.java
! test/javax/sound/midi/Gervill/ModelSource/SetIdentifier.java
! test/javax/sound/midi/Gervill/ModelSource/SetTransform.java
! test/javax/sound/midi/Gervill/ModelStandardIndexedDirector/ModelStandardIndexedDirectorTest.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransform.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBoolean.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBoolean.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBooleanInt.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/SetDirection.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/SetPolarity.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/SetTransform.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformAbsolute.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConcave.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConvex.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformLinear.java
! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformSwitch.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/Available.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/Close.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/GetFilePointer.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/GetSize.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/HasNextChunk.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/Read.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByte.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByteArrayIntInt.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadInt.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadLong.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadShort.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadString.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedByte.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedInt.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedShort.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/Skip.java
! test/javax/sound/midi/Gervill/RiffReaderWriter/WriteOutputStream.java
! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankFile.java
! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream.java
! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream2.java
! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankUrl.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrument.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformer.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArray.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntIntInt.java
! test/javax/sound/midi/Gervill/SimpleInstrument/Clear.java
! test/javax/sound/midi/Gervill/SimpleInstrument/SetName.java
! test/javax/sound/midi/Gervill/SimpleInstrument/SetPatch.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/AddInstrument.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/AddResource.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/GetInstrument.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/RemoveInstrument.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/SetDescription.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/SetName.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVendor.java
! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVersion.java
! test/javax/sound/midi/Gervill/SoftAudioBuffer/Array.java
! test/javax/sound/midi/Gervill/SoftAudioBuffer/Clear.java
! test/javax/sound/midi/Gervill/SoftAudioBuffer/Get.java
! test/javax/sound/midi/Gervill/SoftAudioBuffer/NewSoftAudioBuffer.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetFormat.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetPropertyInfo.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/Open.java
! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/OpenStream.java
! test/javax/sound/midi/Gervill/SoftChannel/AllNotesOff.java
! test/javax/sound/midi/Gervill/SoftChannel/AllSoundOff.java
! test/javax/sound/midi/Gervill/SoftChannel/ChannelPressure.java
! test/javax/sound/midi/Gervill/SoftChannel/Controller.java
! test/javax/sound/midi/Gervill/SoftChannel/LocalControl.java
! test/javax/sound/midi/Gervill/SoftChannel/Mono.java
! test/javax/sound/midi/Gervill/SoftChannel/Mute.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOff.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOff2.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOn.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest.java
! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest2.java
! test/javax/sound/midi/Gervill/SoftChannel/Omni.java
! test/javax/sound/midi/Gervill/SoftChannel/PitchBend.java
! test/javax/sound/midi/Gervill/SoftChannel/PolyPressure.java
! test/javax/sound/midi/Gervill/SoftChannel/ProgramAndBankChange.java
! test/javax/sound/midi/Gervill/SoftChannel/ProgramChange.java
! test/javax/sound/midi/Gervill/SoftChannel/ResetAllControllers.java
! test/javax/sound/midi/Gervill/SoftChannel/SoftTestUtils.java
! test/javax/sound/midi/Gervill/SoftChannel/Solo.java
! test/javax/sound/midi/Gervill/SoftCubicResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java
! test/javax/sound/midi/Gervill/SoftLanczosResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono_overdrive.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_overdrive.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal_mono.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive.java
! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive_mono.java
! test/javax/sound/midi/Gervill/SoftLinearResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftLinearResampler2/Interpolate.java
! test/javax/sound/midi/Gervill/SoftLowFrequencyOscillator/TestProcessControlLogic.java
! test/javax/sound/midi/Gervill/SoftPointResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftProvider/GetDevice.java
! test/javax/sound/midi/Gervill/SoftReceiver/Close.java
! test/javax/sound/midi/Gervill/SoftReceiver/GetMidiDevice.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_ActiveSense.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllNotesOff.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllSoundOff.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_ChannelPressure.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_Controller.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_Mono.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOff.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_AllChannels.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Delayed.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Multiple.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_Omni.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_PitchBend.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_PolyPressure.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_ProgramChange.java
! test/javax/sound/midi/Gervill/SoftReceiver/Send_ResetAllControllers.java
! test/javax/sound/midi/Gervill/SoftReceiver/SoftTestUtils.java
! test/javax/sound/midi/Gervill/SoftSincResampler/Interpolate.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/Close.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetChannels.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDefaultSoundbank.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDeviceInfo.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLatency.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxPolyphony.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxReceivers.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxTransmitters.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMicrosecondPosition.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver2.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceivers.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitter.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitters.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/GetVoiceStatus.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/IsOpen.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/IsSoundbankSupported.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/OpenStream.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/TestPreciseTimestampRendering.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/TestRender1.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java
! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java
! test/javax/sound/midi/Gervill/SoftTuning/GetName.java
! test/javax/sound/midi/Gervill/SoftTuning/GetTuning.java
! test/javax/sound/midi/Gervill/SoftTuning/GetTuningInt.java
! test/javax/sound/midi/Gervill/SoftTuning/Load1.java
! test/javax/sound/midi/Gervill/SoftTuning/Load2.java
! test/javax/sound/midi/Gervill/SoftTuning/Load4.java
! test/javax/sound/midi/Gervill/SoftTuning/Load5.java
! test/javax/sound/midi/Gervill/SoftTuning/Load6.java
! test/javax/sound/midi/Gervill/SoftTuning/Load7.java
! test/javax/sound/midi/Gervill/SoftTuning/Load8.java
! test/javax/sound/midi/Gervill/SoftTuning/Load9.java
! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuning.java
! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningByteArray.java
! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatch.java
! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatchByteArray.java
! test/javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java
! test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java
! test/javax/sound/midi/Sequencer/SequencerImplicitSynthOpen.java
! test/javax/sound/sampled/AudioFormat/Matches_NOT_SPECIFIED.java
! test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java
! test/javax/sound/sampled/Clip/ClipSetPos.java
! test/javax/sound/sampled/DataLine/DataLine_ArrayIndexOutOfBounds.java
! test/javax/sound/sampled/DirectAudio/bug6400879.java
! test/javax/sound/sampled/FileWriter/AlawEncoderSync.java
! test/javax/sound/sampled/FileWriter/WriterCloseInput.java
! test/javax/swing/JCheckBox/4449413/bug4449413.html
! test/javax/swing/JColorChooser/Test4222508.html
! test/javax/swing/JColorChooser/Test4759306.html
! test/javax/swing/JColorChooser/Test4759934.html
! test/javax/swing/JColorChooser/Test4887836.html
! test/javax/swing/JColorChooser/Test6348456.html
! test/javax/swing/JColorChooser/Test6977726.html
! test/javax/swing/JComponent/4337267/bug4337267.java
! test/javax/swing/JComponent/6683775/bug6683775.java
! test/javax/swing/JEditorPane/4492274/test.html
! test/javax/swing/JEditorPane/6917744/test.html
! test/javax/swing/JEditorPane/bug4714674.java
! test/javax/swing/JFileChooser/6570445/bug6570445.java
! test/javax/swing/JFileChooser/6698013/bug6698013.html
! test/javax/swing/JFileChooser/6698013/bug6698013.java
! test/javax/swing/JFileChooser/6798062/bug6798062.html
! test/javax/swing/JInternalFrame/6726866/bug6726866.html
! test/javax/swing/JInternalFrame/6726866/bug6726866.java
! test/javax/swing/JSlider/4987336/bug4987336.html
! test/javax/swing/JSlider/6524424/bug6524424.html
! test/javax/swing/JSlider/6587742/bug6587742.html
! test/javax/swing/JSlider/6742358/bug6742358.html
! test/javax/swing/JTabbedPane/4310381/bug4310381.html
! test/javax/swing/JTree/4314199/bug4314199.html
! test/javax/swing/SwingUtilities/7170657/bug7170657.java
! test/javax/swing/border/Test4129681.html
! test/javax/swing/border/Test4243289.html
! test/javax/swing/border/Test4247606.html
! test/javax/swing/border/Test4252164.html
! test/javax/swing/border/Test4760089.html
! test/javax/swing/border/Test6910490.html
! test/javax/swing/border/Test7022041.java
! test/javax/swing/text/html/TableView/7030332/bug7030332.html
! test/sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest.html
! test/sun/nio/cs/EUC_TW_OLD.java
! test/sun/nio/cs/TestStringCoding.java
! test/sun/nio/cs/X11CNS11643.java
! test/sun/nio/cs/X11CNS11643P1.java
! test/sun/nio/cs/X11CNS11643P2.java
! test/sun/nio/cs/X11CNS11643P3.java
! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.java
! test/sun/security/pkcs11/ec/TestECGenSpec.java
! test/sun/security/pkcs11/ec/TestKeyFactory.java
! test/sun/util/resources/Locale/Bug6275682.java
! test/tools/launcher/DiacriticTest.java
! test/vm/verifier/defaultMethods/DefaultMethodRegressionTests.java
! test/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java

Changeset: d6fe4e451dfb
Author:    bagiras
Date:      2013-11-13 20:16 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d6fe4e451dfb

8028283: Revert JavaDoc changes pushed for JDK-7068423
Reviewed-by: art, serb

! src/share/classes/java/awt/GraphicsDevice.java

Changeset: 535f19dd3960
Author:    pchelko
Date:      2013-11-14 10:52 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/535f19dd3960

8028230: Behavior of SystemFlavorMap.getNativesForFlavor differ from that in Java 7
Reviewed-by: anthony, serb

! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
+ test/java/awt/datatransfer/DuplicatedNativesTest/DuplicatedNativesTest.java

Changeset: 8d17ebcef958
Author:    pchelko
Date:      2013-11-14 11:42 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/8d17ebcef958

8025440: [TEST_BUG] com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java failed since jdk8b108
Reviewed-by: anthony

+ test/com/sun/awt/SecurityWarning/CustomSecurityManager.java
! test/com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java
+ test/java/awt/regtesthelpers/CopyClassFile.java

Changeset: ca0db77f6d6b
Author:    lana
Date:      2013-11-14 23:32 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ca0db77f6d6b

Merge


Changeset: c35f6df5bce9
Author:    sla
Date:      2013-11-01 10:08 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c35f6df5bce9

8027692: Remove java/lang/management/MemoryMXBean/LowMemoryTest2.sh from ProblemList.txt
Reviewed-by: stefank, alanb

! test/ProblemList.txt

Changeset: c59ccad6eb72
Author:    sla
Date:      2013-11-01 15:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c59ccad6eb72

8027705: com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events.
Reviewed-by: dcubed

! test/com/sun/jdi/JdbMethodExitTest.sh
! test/com/sun/jdi/ShellScaffold.sh

Changeset: 6a6faa00acc4
Author:    dxu
Date:      2013-11-01 14:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6a6faa00acc4

8027624: com/sun/crypto/provider/KeyFactory/TestProviderLeak.java unstable again
Reviewed-by: wetmore

! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java

Changeset: adcc01f5bc93
Author:    jrose
Date:      2013-11-02 20:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/adcc01f5bc93

8024635: Caching MethodType's descriptor string improves lambda linkage performance
Summary: Better interpreted and compiled performance of operations in MethodType important to LambdaMetafactory.
Reviewed-by: jrose, twisti, mchung
Contributed-by: sergey.kuksenko at oracle.com

! src/share/classes/java/lang/invoke/MethodType.java

Changeset: d19ab5da83cc
Author:    dholmes
Date:      2013-11-04 06:58 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d19ab5da83cc

8025198: Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java
Reviewed-by: martin, dholmes
Contributed-by: Tristan Yan <tristan.yan at oracle.com>

! makefiles/CompileLaunchers.gmk
! makefiles/lib/CoreLibraries.gmk
! src/share/bin/java.c
! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

Changeset: 23982079ad49
Author:    dholmes
Date:      2013-11-04 07:39 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/23982079ad49

8027755: Anti-delta incorrect push for 8025198
Reviewed-by: alanb

! makefiles/CompileLaunchers.gmk
! makefiles/lib/CoreLibraries.gmk
! src/share/bin/java.c

Changeset: 92fb6baaebc4
Author:    bpb
Date:      2013-11-04 08:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/92fb6baaebc4

8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to specify heap size
Summary: Add @run tag to specify heap size
Reviewed-by: alanb, dxu

! test/java/math/BigInteger/ExtremeShiftingTests.java

Changeset: 48449b5390fa
Author:    michaelm
Date:      2013-11-04 17:47 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/48449b5390fa

8027687: The constructors of URLPermission class do not behave as described in javad
Reviewed-by: chegar, mduigou

! src/share/classes/java/net/HostPortrange.java
! src/share/classes/java/net/URLPermission.java
! test/java/net/URLPermission/URLPermissionTest.java

Changeset: 51b002381b35
Author:    rfield
Date:      2013-11-04 10:12 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/51b002381b35

7194897: JSR 292: Cannot create more than 16 instances of an anonymous class
8027681: Lambda serialization fails once reflection proxy generation kicks in
Reviewed-by: ksrini, briangoetz, jfranck
Contributed-by: joel.franck at oracle.com, brian.goetz at oracle.com, robert.field at oracle.com

! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java
! src/share/classes/sun/reflect/NativeMethodAccessorImpl.java
! src/share/classes/sun/reflect/misc/ReflectUtil.java
+ test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java
! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java
+ test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java

Changeset: 78a0dcde6b67
Author:    alundblad
Date:      2013-11-04 15:21 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/78a0dcde6b67

8016725: TEST_BUG: java/lang/reflect/Method/DefaultMethodModeling.java failing intermittently
Summary: Moved DefaultMethodModeling.java to its own directory to avoid conflicts with Equals.java.
Reviewed-by: darcy

- test/java/lang/reflect/Method/DefaultMethodModeling.java
+ test/java/lang/reflect/Method/defaultMethodModeling/DefaultMethodModeling.java

Changeset: 6d1f3ba68db2
Author:    dxu
Date:      2013-11-04 15:48 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6d1f3ba68db2

8027612: java/io/File/MaxPathLength.java fails intermittently in the clean-up stage
Reviewed-by: chegar

! test/java/io/File/MaxPathLength.java

Changeset: d5b3f83ffc40
Author:    psandoz
Date:      2013-11-05 12:08 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d5b3f83ffc40

8027712: DistinctOpTest fails for unordered test
Reviewed-by: henryjen, alanb

! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java

Changeset: a8a044db575c
Author:    joehw
Date:      2013-11-05 11:18 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a8a044db575c

8027860: [TEST_BUG] File not closed in javax/xml/jaxp/parsers/8022548/XOMParserTest.java
Reviewed-by: alanb

! test/javax/xml/jaxp/parsers/8022548/XOMParserTest.java

Changeset: 85fd2ae0a845
Author:    mchung
Date:      2013-11-05 17:33 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/85fd2ae0a845

8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java
6944188: ThreadMXBean/ThreadStateTest.java fails intermittently
Reviewed-by: dholmes, chegar

+ test/java/lang/Thread/ThreadStateController.java
! test/java/lang/Thread/ThreadStateTest.java
+ test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java
- test/java/lang/management/ThreadMXBean/ThreadStateTest.java

Changeset: 9c30cbc316e9
Author:    mduigou
Date:      2013-11-05 19:44 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9c30cbc316e9

8021309: replace test/Makefile jdk_* targets with jtreg groups
8015068: Use jtreg -exclude for handling problemList.txt exclusions
Reviewed-by: jjg, smarks, chegar, alanb, dholmes

! .hgignore
! test/Makefile

Changeset: 6ea1f9d8ec78
Author:    dxu
Date:      2013-11-06 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6ea1f9d8ec78

8025698: (fs) Typo in exception thrown by encode() in UnixPath.java
Reviewed-by: dxu, mduigou, henryjen, weijun
Contributed-by: ajuckel at gmail.com

! src/solaris/classes/sun/nio/fs/UnixPath.java

Changeset: 81cbdd5876e8
Author:    ksrini
Date:      2013-11-06 11:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/81cbdd5876e8

8027227: [asm] generate CONSTANT_InterfaceMethodref for invoke{special/static) of non-abstract methods on ifaces
Reviewed-by: ksrini, lagergren
Contributed-by: ebruneton at free.fr, forax at univ-mlv.fr, john.r.rose at oracle.com, paul.sandoz at oracle.com

! src/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java
! src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java
! src/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java
! src/share/classes/jdk/internal/org/objectweb/asm/Handle.java
! src/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java
! src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java
! src/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java
! src/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java
! src/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java
! src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java
! src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java
! src/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java
! src/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java
! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java
! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java
! src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java
! src/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java
! src/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java
! src/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java
! src/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java
! src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java
! src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java
! src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java
! src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeAnnotationNode.java
! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java
! src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java
! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java
! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java
! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java
! src/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java
! src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java
! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java
! src/share/classes/jdk/internal/org/objectweb/asm/version.txt

Changeset: dbda97d6aa3a
Author:    ksrini
Date:      2013-11-06 11:31 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/dbda97d6aa3a

8027232: Update j.l.invoke code generating class files to use ASM enhancements for invocation of non-abstract methods on ifaces
Reviewed-by: ksrini, rfield
Contributed-by: john.r.rose at oracle.com, paul.sandoz at oracle.com

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java
+ test/java/lang/invoke/lambda/LambdaAsm.java

Changeset: f37d62e295c0
Author:    chegar
Date:      2013-11-07 08:04 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f37d62e295c0

8027822: ProblemList.txt Updates (11/2013)
Reviewed-by: chegar, alanb
Contributed-by: Amy Lu <amy.lu at oracle.com>

! test/ProblemList.txt

Changeset: 82b276590b85
Author:    chegar
Date:      2013-11-07 08:23 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/82b276590b85

8027961: Inet[4|6]Address native initializing code should check field/MethodID values
Reviewed-by: michaelm, rriggs

! src/share/native/java/net/Inet4Address.c
! src/share/native/java/net/Inet6Address.c
! src/share/native/java/net/InetAddress.c
! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c
! src/windows/native/java/net/Inet4AddressImpl.c
! src/windows/native/java/net/Inet6AddressImpl.c

Changeset: 88d1ed05a246
Author:    michaelm
Date:      2013-11-07 10:22 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/88d1ed05a246

8027881: test/java/net/URLPermission/nstest/LookupTest.java failing intermittently, output insufficient
Reviewed-by: chegar

! test/java/net/URLPermission/URLPermissionTest.java
! test/java/net/URLPermission/nstest/LookupTest.java
+ test/java/net/URLPermission/nstest/lookup.sh
- test/java/net/URLPermission/nstest/policy

Changeset: 44fa6bf42846
Author:    jfranck
Date:      2013-11-07 13:33 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/44fa6bf42846

8027796: Refactor Core Reflection for Type Annotations
Reviewed-by: psandoz

! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java
! src/share/classes/sun/reflect/annotation/TypeAnnotation.java
! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java

Changeset: fb7abd509bd2
Author:    naoto
Date:      2013-11-07 10:03 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/fb7abd509bd2

8027930: ResourceBundle test failures in fr locale
Reviewed-by: smarks

! test/java/util/ResourceBundle/ResourceBundleTest.java
! test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java

Changeset: 04f071a95c29
Author:    rriggs
Date:      2013-11-07 20:56 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/04f071a95c29

8024458: DataInput.readDouble refers to "readlong" instead of "readLong"
Summary: fix the typo
Reviewed-by: lancea, chegar, dxu

! src/share/classes/java/io/DataInput.java

Changeset: e10a182c973a
Author:    yhuang
Date:      2013-11-07 22:30 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e10a182c973a

8027695: There should be a space before % sign in Swedish locale
Reviewed-by: naoto

! src/share/classes/sun/text/resources/sv/FormatData_sv_SE.java
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: b5748857ef42
Author:    jbachorik
Date:      2013-11-08 08:47 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b5748857ef42

8007984: Null pointer dereference in jdk/linux-amd64/democlasses/demo/jvmti/heapTracker/src/java_crw_demo.c
Reviewed-by: dholmes

! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c

Changeset: 8a4405fb40ba
Author:    ykantser
Date:      2013-11-07 16:55 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/8a4405fb40ba

8027752: sun/tools/jstatd/TestJstatdExternalRegistry.java: java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object
Reviewed-by: sla, jbachorik

! test/sun/tools/jstatd/JstatdTest.java

Changeset: 41d7ce111bd8
Author:    mchung
Date:      2013-11-08 07:53 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/41d7ce111bd8

8027351: (ref) Private finalize method invoked in preference to protected superclass method
Reviewed-by: alanb, dholmes, mr, plevart, psandoz

! makefiles/lib/CoreLibraries.gmk
! makefiles/mapfiles/libjava/mapfile-vers
! makefiles/mapfiles/libjava/reorder-sparc
! makefiles/mapfiles/libjava/reorder-sparcv9
! makefiles/mapfiles/libjava/reorder-x86
! src/share/classes/java/lang/System.java
! src/share/classes/java/lang/ref/Finalizer.java
! src/share/classes/sun/misc/JavaLangAccess.java
! src/share/classes/sun/misc/VM.java
+ test/java/lang/ref/FinalizeOverride.java

Changeset: 3112729d6b74
Author:    tyan
Date:      2013-11-08 15:12 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3112729d6b74

8022963: java/net/NetworkInterface/Equals.java fails equality for Windows Teredo Interface
Reviewed-by: chegar

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

Changeset: 771c77b49bb6
Author:    chegar
Date:      2013-11-08 15:15 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/771c77b49bb6

8019834: InetAddress.getByName hangs for bad IPv6 literals
Reviewed-by: alanb

! src/share/classes/java/net/InetAddress.java
! test/java/net/ipv6tests/BadIPv6Addresses.java

Changeset: 1c9ba18198d5
Author:    mchung
Date:      2013-11-08 09:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/1c9ba18198d5

8028069: (ref) Finalizer.c not deleted in the changeset for JDK-8027351
Reviewed-by: alanb

- src/share/native/java/lang/ref/Finalizer.c

Changeset: 46982ca895b4
Author:    tyan
Date:      2013-11-08 18:54 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/46982ca895b4

8023462: TEST_BUG: test/com/sun/net/httpserver/bugs/B6433018.java fails on slow/single core machine
Reviewed-by: chegar

! test/com/sun/net/httpserver/bugs/B6433018.java

Changeset: 40ca9e4866de
Author:    mchung
Date:      2013-11-08 12:13 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/40ca9e4866de

8025985: com.sun.management.OSMBeanFactory should not be public
Reviewed-by: alanb, erikj, ihse, jbachorik

! makefiles/lib/ServiceabilityLibraries.gmk
! makefiles/mapfiles/libmanagement/mapfile-vers
+ src/share/classes/sun/management/BaseOperatingSystemImpl.java
! src/share/classes/sun/management/ManagementFactoryHelper.java
- src/share/classes/sun/management/OperatingSystemImpl.java
- src/solaris/classes/com/sun/management/OSMBeanFactory.java
- src/solaris/classes/com/sun/management/UnixOperatingSystem.java
+ src/solaris/classes/sun/management/OperatingSystemImpl.java
- src/solaris/native/com/sun/management/LinuxOperatingSystem.c
- src/solaris/native/com/sun/management/MacosxOperatingSystem.c
- src/solaris/native/com/sun/management/SolarisOperatingSystem.c
- src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
+ src/solaris/native/sun/management/LinuxOperatingSystem.c
+ src/solaris/native/sun/management/MacosxOperatingSystem.c
+ src/solaris/native/sun/management/OperatingSystemImpl.c
+ src/solaris/native/sun/management/SolarisOperatingSystem.c
- src/windows/classes/com/sun/management/OSMBeanFactory.java
- src/windows/classes/com/sun/management/OperatingSystem.java
+ src/windows/classes/sun/management/OperatingSystemImpl.java
- src/windows/native/com/sun/management/OperatingSystem_md.c
+ src/windows/native/sun/management/OperatingSystemImpl.c

Changeset: 11376ad23e21
Author:    darcy
Date:      2013-11-08 12:19 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/11376ad23e21

8028076: Correct raw type lint warnings in core reflection implementation classes
Reviewed-by: lancea, alanb

! src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java

Changeset: 50df04934e86
Author:    alanb
Date:      2013-11-08 21:07 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/50df04934e86

8028074: InetAddress.getByName fails with UHE "invalid IPv6 address" if host name starts with a-f
Reviewed-by: chegar

! src/share/classes/java/net/InetAddress.java

Changeset: df2f7f288353
Author:    rriggs
Date:      2013-11-08 17:50 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/df2f7f288353

8028041: Serialized Form description of j.l.String is not consistent with the implementation
Summary: Replaced incorrect description with reference to the serialization specification
Reviewed-by: alanb, smarks

! src/share/classes/java/lang/String.java

Changeset: a579e2f73bca
Author:    lana
Date:      2013-11-08 17:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a579e2f73bca

Merge

! src/share/classes/java/lang/invoke/MethodType.java
! src/solaris/classes/sun/nio/fs/UnixPath.java
! test/java/lang/Thread/ThreadStateTest.java

Changeset: 9130770fb6e3
Author:    alanb
Date:      2013-11-09 16:46 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9130770fb6e3

8028044: [TEST_BUG] Calendar shell tests do not pass TESTVMOPTS
Reviewed-by: dholmes, alanb
Contributed-by: patrick.zhang at oracle.com

! test/java/util/Calendar/GenericTimeZoneNamesTest.sh
! test/java/util/Calendar/NarrowNamesTest.sh

Changeset: 3add16c86970
Author:    rriggs
Date:      2013-11-09 14:30 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3add16c86970

8028092: Lint cleanup of java.time.format
Summary: correct declarations and add @SuppressWarnings
Reviewed-by: darcy, lancea

! src/share/classes/java/time/format/DateTimeParseContext.java
! src/share/classes/java/time/format/Parsed.java

Changeset: 0c75cc07d264
Author:    jbachorik
Date:      2013-11-10 20:05 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0c75cc07d264

6523160: RuntimeMXBean.getUptime() returns negative values
Summary: RuntimeMXBean.getUptime() should be based on HR timers rather than on the OS time
Reviewed-by: dholmes, sla

! make/java/management/mapfile-vers
! makefiles/mapfiles/libmanagement/mapfile-vers
! src/share/classes/sun/management/RuntimeImpl.java
! src/share/classes/sun/management/VMManagement.java
! src/share/classes/sun/management/VMManagementImpl.java
! src/share/javavm/export/jmm.h
! src/share/native/sun/management/VMManagementImpl.c
! test/java/lang/management/RuntimeMXBean/UpTime.java

Changeset: 2525b91ca5a6
Author:    alanb
Date:      2013-11-11 08:36 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/2525b91ca5a6

8028099: Many com/sun/management/OperatingSystemMXBean tests failing with CCE (win)
Reviewed-by: mchung

! src/windows/classes/sun/management/OperatingSystemImpl.java

Changeset: 7304b3195212
Author:    weijun
Date:      2013-11-11 16:54 +0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7304b3195212

8027991: InputStream should be closed in sun.security.tools.jarsigner.Main
Reviewed-by: xuelei

! src/share/classes/sun/security/tools/jarsigner/Main.java
+ test/sun/security/tools/jarsigner/CertChainUnclosed.java

Changeset: b48eded97dff
Author:    chegar
Date:      2013-11-11 10:33 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b48eded97dff

8028102: All test targets, jdk/test/Makefile, fail on Windows
Reviewed-by: mduigou

! test/Makefile

Changeset: 0e47462f03a0
Author:    michaelm
Date:      2013-11-11 16:06 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0e47462f03a0

8028060: test/java/net/URLPermission/nstest/lookup.sh failing (win)
Reviewed-by: alanb

! test/java/net/URLPermission/nstest/LookupTest.java
! test/java/net/URLPermission/nstest/lookup.sh

Changeset: 59ff7957c26f
Author:    lancea
Date:      2013-11-11 14:22 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/59ff7957c26f

8028149: Clean-up javac -Xlint warnings in com.sun.rowset and com.sun.rowset.internal
Reviewed-by: darcy

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/BaseRow.java

Changeset: 0cacac7f5c37
Author:    sla
Date:      2013-11-08 18:16 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0cacac7f5c37

8014506: Test of Jdp feature
Reviewed-by: sla
Contributed-by: Alex Schenkman <alex.schenkman at oracle.com>

+ test/sun/management/jdp/ClientConnection.java
+ test/sun/management/jdp/DynamicLauncher.java
! test/sun/management/jdp/JdpClient.java
+ test/sun/management/jdp/JdpDefaultsTest.java
! test/sun/management/jdp/JdpDoSomething.java
+ test/sun/management/jdp/JdpOffTest.java
+ test/sun/management/jdp/JdpOffTestCase.java
+ test/sun/management/jdp/JdpOnTestCase.java
+ test/sun/management/jdp/JdpSpecificAddressTest.java
! test/sun/management/jdp/JdpTest.sh
+ test/sun/management/jdp/JdpTestCase.java
+ test/sun/management/jdp/JdpTestUtil.java
+ test/sun/management/jdp/JdpTestUtilTest.java
! test/sun/management/jdp/JdpUnitTest.java
+ test/sun/management/jdp/PacketTest.java
+ test/sun/management/jdp/PortAlreadyInUseTest.java
+ test/sun/management/jdp/README

Changeset: 8e8e423fa3dc
Author:    sherman
Date:      2013-11-11 14:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/8e8e423fa3dc

8026330: java.util.Base64 urlEncoder should omit padding
Summary: to add Encoder.withoutPadding()
Reviewed-by: alanb

! src/share/classes/java/util/Base64.java
! test/java/util/Base64/TestBase64.java

Changeset: c04e46dbfea8
Author:    rfield
Date:      2013-11-11 16:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c04e46dbfea8

8027803: test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java fails
Summary: fix NPE in test infrastructure
Reviewed-by: ksrini, jfranck, alanb, rfield
Contributed-by: alan.bateman at oracle.com

! test/lib/testlibrary/ClassFileInstaller.java

Changeset: 9fcb07df1c92
Author:    vlivanov
Date:      2013-11-09 04:21 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9fcb07df1c92

8027823: catchException combinator fails with 9 argument target
Reviewed-by: jrose

! src/share/classes/java/lang/invoke/MethodHandleImpl.java
+ test/java/lang/invoke/MethodHandles/TestCatchException.java

Changeset: 41dcb0c2e194
Author:    egahlin
Date:      2013-11-12 14:52 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/41dcb0c2e194

8027209: javax/management/monitor/ThreadPoolAccTest.java fails intermittently
Reviewed-by: sla, jbachorik

! test/javax/management/monitor/ThreadPoolAccTest.java

Changeset: f6012ca3bdd3
Author:    smarks
Date:      2013-11-12 16:59 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f6012ca3bdd3

8028027: serialver should emit declaration with the 'private' modifier
Reviewed-by: darcy, mchung, alanb, chegar

! src/share/classes/sun/tools/serialver/SerialVer.java

Changeset: 4cff9f59644f
Author:    egahlin
Date:      2013-11-12 17:40 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4cff9f59644f

6543856: MonitorVmStartTerminate.sh fails intermittently
Reviewed-by: sla, dholmes

! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java
! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh
! test/sun/jvmstat/testlibrary/JavaProcess.java

Changeset: d9f827e4d20c
Author:    egahlin
Date:      2013-11-12 18:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d9f827e4d20c

6849945: VM Periodic Task Thread CPU time = -1ns in HotspotThreadMBean.getInternalThreadCpuTimes()
Reviewed-by: sla

! test/sun/management/HotspotThreadMBean/GetInternalThreads.java

Changeset: 0c414ac10700
Author:    alanb
Date:      2013-11-12 17:37 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0c414ac10700

8028208: (aio) Assertion in clearPendingIoMap when closing at around time file lock is acquired immediately (win)
Reviewed-by: chegar

! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
! test/ProblemList.txt

Changeset: 69432cb5bca2
Author:    darcy
Date:      2013-11-12 09:44 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/69432cb5bca2

8028229: Fix more raw types lint warning in core libraries
Reviewed-by: chegar, forax, lancea, alanb, jfranck

! src/share/classes/java/io/ObjectOutputStream.java
! src/share/classes/java/io/ObjectStreamClass.java
! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/java/nio/file/TempFileHelper.java
! src/share/classes/java/util/IdentityHashMap.java
! src/share/classes/java/util/logging/Logger.java
! src/share/classes/java/util/logging/Logging.java
! src/share/classes/sun/misc/Cleaner.java
! src/share/classes/sun/misc/ProxyGenerator.java
! src/share/classes/sun/rmi/rmic/Main.java
! src/share/classes/sun/rmi/server/LoaderHandler.java
! src/share/classes/sun/rmi/server/UnicastServerRef.java
! src/share/classes/sun/rmi/server/Util.java

Changeset: ebe27e1a2e2d
Author:    rriggs
Date:      2013-11-12 14:03 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ebe27e1a2e2d

8028014: Doclint warning/error cleanup in javax.management
Summary: Improve generated html by fixing doclint warnings
Reviewed-by: sla, jbachorik

! src/share/classes/javax/management/AttributeList.java
! src/share/classes/javax/management/BooleanValueExp.java
! src/share/classes/javax/management/Descriptor.java
! src/share/classes/javax/management/DescriptorKey.java
! src/share/classes/javax/management/ImmutableDescriptor.java
! src/share/classes/javax/management/JMX.java
! src/share/classes/javax/management/MBeanFeatureInfo.java
! src/share/classes/javax/management/MBeanInfo.java
! src/share/classes/javax/management/MBeanServer.java
! src/share/classes/javax/management/MBeanServerConnection.java
! src/share/classes/javax/management/MBeanServerNotification.java
! src/share/classes/javax/management/MXBean.java
! src/share/classes/javax/management/NumericValueExp.java
! src/share/classes/javax/management/ObjectName.java
! src/share/classes/javax/management/PersistentMBean.java
! src/share/classes/javax/management/Query.java
! src/share/classes/javax/management/loading/MLet.java
! src/share/classes/javax/management/loading/MLetParser.java
! src/share/classes/javax/management/modelmbean/DescriptorSupport.java
! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationBroadcaster.java
! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java
! src/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java
! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java
! src/share/classes/javax/management/monitor/Monitor.java
! src/share/classes/javax/management/openmbean/ArrayType.java
! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java
! src/share/classes/javax/management/openmbean/CompositeType.java
! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java
! src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java
! src/share/classes/javax/management/openmbean/SimpleType.java
! src/share/classes/javax/management/openmbean/TabularType.java
! src/share/classes/javax/management/relation/Relation.java
! src/share/classes/javax/management/relation/RelationService.java
! src/share/classes/javax/management/relation/RelationServiceMBean.java
! src/share/classes/javax/management/relation/RelationSupport.java
! src/share/classes/javax/management/remote/JMXConnectionNotification.java
! src/share/classes/javax/management/remote/JMXConnector.java
! src/share/classes/javax/management/remote/JMXConnectorProvider.java
! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
! src/share/classes/javax/management/remote/rmi/RMIConnector.java
! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java
! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java

Changeset: c4c84b5a3dfa
Author:    alanb
Date:      2013-11-13 07:43 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c4c84b5a3dfa

8028239: test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh with NoClassDefFoundError
Reviewed-by: mchung, egahlin

! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh

Changeset: 1158d504e39e
Author:    xuelei
Date:      2013-11-13 01:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/1158d504e39e

8023147: Test DisabledShortRSAKeys.java intermittent failed
Reviewed-by: mullan

! test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java

Changeset: 30a3aefc4084
Author:    dfuchs
Date:      2013-11-13 10:50 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/30a3aefc4084

8026952: Test java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java has wrong @bug id
Summary: Trivial: change @bug 8023163 into @bug 8026499
Reviewed-by: mchung, alanb

! test/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java

Changeset: 680ef14a2cc0
Author:    jbachorik
Date:      2013-11-13 13:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/680ef14a2cc0

8004126: TEST_BUG: com/sun/jdi/BadHandshakeTest.java fails intermittently
Reviewed-by: dholmes, ykantser

! test/com/sun/jdi/BadHandshakeTest.java

Changeset: ddaa9a8acaed
Author:    egahlin
Date:      2013-11-13 15:21 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ddaa9a8acaed

6959636: testcase failing on windows javax/management/loading/LibraryLoader/LibraryLoaderTest.java
Reviewed-by: sla, jbachorik

! test/ProblemList.txt
! test/javax/management/loading/LibraryLoader/LibraryLoaderTest.java

Changeset: a42a416351b8
Author:    ykantser
Date:      2013-11-13 11:46 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a42a416351b8

8015497: Take new fixes from hotspot/test/testlibrary to jdk/test/lib/testlibrary
Reviewed-by: sla

+ test/lib/testlibrary/AssertsTest.java
+ test/lib/testlibrary/OutputAnalyzerReportingTest.java
+ test/lib/testlibrary/jdk/testlibrary/InputArguments.java
! test/lib/testlibrary/jdk/testlibrary/JcmdBase.java
- test/lib/testlibrary/jdk/testlibrary/JdkFinder.java
! test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java
! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java
! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java

Changeset: 7c55fecfae65
Author:    mchung
Date:      2013-11-13 07:49 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7c55fecfae65

8028234: Remove unused methods in sun.misc.JavaAWTAccess
Reviewed-by: art, dfuchs, lancea

! src/share/classes/sun/awt/AppContext.java
! src/share/classes/sun/misc/JavaAWTAccess.java
! test/java/util/logging/TestAppletLoggerContext.java

Changeset: 70f1bed5e7fd
Author:    chegar
Date:      2013-11-13 16:44 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/70f1bed5e7fd

8022213: Intermittent test failures in java/net/URLClassLoader
Reviewed-by: dxu, alanb

! test/java/net/URLClassLoader/closetest/CloseTest.java
! test/java/net/URLClassLoader/closetest/Common.java
! test/java/net/URLClassLoader/closetest/GetResourceAsStream.java
+ test/lib/testlibrary/jdk/testlibrary/FileUtils.java

Changeset: a493871959c2
Author:    alanb
Date:      2013-11-13 16:52 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a493871959c2

8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission
Reviewed-by: mchung, martin, chegar

! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java
! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java
! test/java/nio/file/Files/CheckPermissions.java

Changeset: 256b3395346b
Author:    egahlin
Date:      2013-11-13 18:41 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/256b3395346b

6954510: TEST_BUG: Testcase failure com/sun/jdi/BreakpointWithFullGC.sh
Reviewed-by: sla, sspitsyn

! test/com/sun/jdi/BreakpointWithFullGC.sh

Changeset: e6333788b117
Author:    darcy
Date:      2013-11-13 11:06 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e6333788b117

8028300: Fix raw type lint warnings in java.util.concurrent
Reviewed-by: chegar, martin

! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java

Changeset: 9e37caf07ce0
Author:    sherman
Date:      2013-11-13 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9e37caf07ce0

8027645: Pattern.split() with positive lookahead
6559590: Pattern.compile(".*").split("") returns incorrect result
Summary: updated spec/impl for these two corner cases
Reviewed-by: alanb, psandoz

! src/share/classes/java/lang/String.java
! src/share/classes/java/util/regex/Pattern.java
! test/java/lang/String/Split.java
! test/java/util/regex/RegExTest.java

Changeset: ea91826bc2e9
Author:    emc
Date:      2013-11-13 15:48 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ea91826bc2e9

8026884: test for fix of JDK-8021398 does not have @bug tag
8028021: @since 1.8 missing for certain methods in java.lang.reflect.Method in generated api docs
Summary: two documentation fixes
Reviewed-by: darcy

! src/share/classes/java/lang/reflect/Executable.java
! test/java/lang/reflect/Parameter/GetAnnotatedTypeTest.java

Changeset: 1d790a56de4e
Author:    sherman
Date:      2013-11-13 22:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/1d790a56de4e

8028321: Fix for String.split() empty input sequence/JDK-6559590 triggers regression
Summary: to undo the change for 6559590
Reviewed-by: darcy

! src/share/classes/java/lang/String.java
! src/share/classes/java/util/regex/Pattern.java
! test/java/lang/String/Split.java
! test/java/util/regex/RegExTest.java

Changeset: ecf85f4aecf0
Author:    alanb
Date:      2013-11-14 10:40 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ecf85f4aecf0

8028343: More ProblemList.txt updates (11/2013)
Reviewed-by: chegar

! test/ProblemList.txt

Changeset: 83c768d6cb93
Author:    jfranck
Date:      2013-11-14 12:17 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/83c768d6cb93

8028055: (reflect) invoking Method/Constructor in anonymous classes breaks with -Dsun.reflect.noInflation=true
Reviewed-by: briangoetz

! src/share/classes/sun/reflect/ReflectionFactory.java
! src/share/classes/sun/reflect/misc/ReflectUtil.java
! test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java
! test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java

Changeset: 65f7b83ab477
Author:    sla
Date:      2013-11-14 19:31 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/65f7b83ab477

8027765: Make exit codes and stdout/stderr printing from jmap/jinfo/jstack/jps consistent
Reviewed-by: alanb, allwin, sspitsyn, mgronlun

! src/share/classes/sun/tools/jinfo/JInfo.java
! src/share/classes/sun/tools/jmap/JMap.java
! src/share/classes/sun/tools/jps/Jps.java
! src/share/classes/sun/tools/jstack/JStack.java

Changeset: 59f46f135584
Author:    hseigel
Date:      2013-11-14 10:44 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/59f46f135584

8023041: The CDS classlist needs to be updated for JDK 8
Summary: Generate new classlists from JDK 8 classes
Reviewed-by: alanb, coleenp, hseigel
Contributed-by: ekaterina.pavlova at oracle.com

! make/tools/sharing/classlist.linux
! make/tools/sharing/classlist.macosx
! make/tools/sharing/classlist.solaris
! make/tools/sharing/classlist.windows

Changeset: f893901ba29c
Author:    coleenp
Date:      2013-11-14 14:01 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f893901ba29c

Merge


Changeset: 40d0ccd00f87
Author:    xuelei
Date:      2013-11-14 16:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/40d0ccd00f87

8014266: regression test AsyncSSLSocketClose.java time out.
Reviewed-by: xuelei
Contributed-by: Rajan Halade <rajan.halade at oracle.com>

! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java

Changeset: fc4ac66aa657
Author:    lana
Date:      2013-11-15 07:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/fc4ac66aa657

Merge

! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java
! src/share/classes/sun/awt/AppContext.java
- src/share/classes/sun/management/OperatingSystemImpl.java
- src/share/native/java/lang/ref/Finalizer.c
- src/solaris/classes/com/sun/management/OSMBeanFactory.java
- src/solaris/classes/com/sun/management/UnixOperatingSystem.java
- src/solaris/native/com/sun/management/LinuxOperatingSystem.c
- src/solaris/native/com/sun/management/MacosxOperatingSystem.c
- src/solaris/native/com/sun/management/SolarisOperatingSystem.c
- src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
- src/windows/classes/com/sun/management/OSMBeanFactory.java
- src/windows/classes/com/sun/management/OperatingSystem.java
- src/windows/native/com/sun/management/OperatingSystem_md.c
! test/ProblemList.txt
- test/java/lang/management/ThreadMXBean/ThreadStateTest.java
- test/java/lang/reflect/Method/DefaultMethodModeling.java
- test/java/net/URLPermission/nstest/policy
! test/java/util/regex/RegExTest.java
- test/lib/testlibrary/jdk/testlibrary/JdkFinder.java

Changeset: 8bc258c021a3
Author:    cl
Date:      2013-11-21 09:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/8bc258c021a3

Added tag jdk8-b117 for changeset fc4ac66aa657

! .hgtags

Changeset: f8104b663f58
Author:    lana
Date:      2013-11-25 12:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f8104b663f58

Merge

! src/share/classes/java/awt/GraphicsDevice.java
- src/share/classes/sun/management/OperatingSystemImpl.java
- src/share/native/java/lang/ref/Finalizer.c
- src/solaris/classes/com/sun/management/OSMBeanFactory.java
- src/solaris/classes/com/sun/management/UnixOperatingSystem.java
- src/solaris/native/com/sun/management/LinuxOperatingSystem.c
- src/solaris/native/com/sun/management/MacosxOperatingSystem.c
- src/solaris/native/com/sun/management/SolarisOperatingSystem.c
- src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
- src/windows/classes/com/sun/management/OSMBeanFactory.java
- src/windows/classes/com/sun/management/OperatingSystem.java
- src/windows/native/com/sun/management/OperatingSystem_md.c
- test/java/lang/management/ThreadMXBean/ThreadStateTest.java
- test/java/lang/reflect/Method/DefaultMethodModeling.java
- test/java/net/URLPermission/nstest/policy
- test/lib/testlibrary/jdk/testlibrary/JdkFinder.java



From philip.race at oracle.com  Mon Nov 25 23:24:15 2013
From: philip.race at oracle.com (Phil Race)
Date: Mon, 25 Nov 2013 15:24:15 -0800
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
Message-ID: <5293DC1F.4060205@oracle.com>

Hi,
I see you've already received a ton of good feedback on this v2.

I have just a few  things to add.
I don't know what symlinks might exist on AIX but it seems odd to
me that you have :-

138 static char *fullAixFontPath[] = {
  139     "/usr/lpp/X11/lib/X11/fonts/Type1",
..

but the paths in the new file aix.fontconfig.properties look like this :-

/usr/lib/X11/fonts/Type1/cour.pfa


Also for the build to pick up a file called
*src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties

*it seems like you should have added a section to handle this path to
jdk/makefiles/gendata/GenDataFontConfig.gmk

That seems to be where the new build handles such files.

Are you seeing the .bfc and .src files created ?

At runtime it'll get picked up so so long as System.getProperty("os.name")
returns "aix" (all lower-case) so I think that's OK. Its the build time part
I'd expect to see but don't.

-phil.

On 11/20/2013 10:26 AM, Volker Simonis wrote:
> Hi,
>
> this is the second review round for "8024854: Basic changes and files 
> to build the class library on AIX 
> <https://bugs.openjdk.java.net/browse/JDK-8024854>". The previous 
> reviews can be found at the end of this mail in the references section.
>
> I've tried to address all the comments and suggestions from the first 
> round and to further streamline the patch (it perfectly builds on 
> Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). 
> The biggest change compared to the first review round is the new 
> "aix/" subdirectory which I've now created under "jdk/src" and which 
> contains AIX-only code.
>
> The webrev is against our 
> http://hg.openjdk.java.net/ppc-aix-port/stage repository which has 
> been recently synchronised with the jdk8 master:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ 
> <http://cr.openjdk.java.net/%7Esimonis/webrevs/8024854.v2/>
>
> Below (and in the webrev) you can find some comments which explain the 
> changes to each file. In order to be able to push this big change, I 
> need the approval of reviewers from the lib, net, svc, 2d, awt and sec 
> groups. So please don't hesitate to jump at it - there are enough 
> changes for everybody:)
>
> Thank you and best regards,
> Volker
>
> *References:*
>
> The following reviews have been posted so far (thanks Iris for 
> collecting them :)
>
> - Alan Bateman (lib): Initial comments (16 Sep [2])
> - Chris Hegarty (lib/net): Initial comments (20 Sep [3])
> - Michael McMahon (net): Initial comments (20 Sept [4])
> - Steffan Larsen (svc): APPROVED (20 Sept [5])
> - Phil Race (2d): Initial comments  (18 Sept [6]); Additional comments 
> (15 Oct [7])
> - Sean Mullan (sec): Initial comments (26 Sept [8])
>
> [2]: 
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html
> [3]: 
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html
> [4]: 
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html
> [5]: 
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html
> [6]: 
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html
> [7]: 
> http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html
> [8]: 
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html
>
>
> *Detailed change description:*
>
> The new "jdk/src/aix" subdirectory contains the following new and 
> AIX-specific files for now:
>   src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>   src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java
>   src/aix/classes/sun/nio/ch/AixPollPort.java
>   src/aix/classes/sun/nio/fs/AixFileStore.java
>   src/aix/classes/sun/nio/fs/AixFileSystem.java
>   src/aix/classes/sun/nio/fs/AixFileSystemProvider.java
>   src/aix/classes/sun/nio/fs/AixNativeDispatcher.java
>   src/aix/classes/sun/tools/attach/AixAttachProvider.java
>   src/aix/classes/sun/tools/attach/AixVirtualMachine.java
>   src/aix/native/java/net/aix_close.c
>   src/aix/native/sun/nio/ch/AixPollPort.c
>   src/aix/native/sun/nio/fs/AixNativeDispatcher.c
>   src/aix/native/sun/tools/attach/AixVirtualMachine.c
>   src/aix/porting/porting_aix.c
>   src/aix/porting/porting_aix.h
>
>
>         src/aix/porting/porting_aix.c
>         src/aix/porting/porting_aix.h
>
>   * Added these two files for AIX relevant utility code.
>   * Currently these files only contain an implementation of |dladdr|
>     which is not available on AIX.
>   * In the first review round the existing |dladdr| users in the code
>     either called the version from the HotSpot on AIX
>     (|src/solaris/native/sun/awt/awt_LoadLibrary.c|) or had a private
>     copy of the whole implementation
>     (|src/solaris/demo/jvmti/hprof/hprof_md.c|). This is now not
>     necessary any more.
>
> The new file layout required some small changes to the makefiles to 
> make them aware of the new directory locations:
>
>
>         makefiles/CompileDemos.gmk
>
>   * Add an extra argument to |SetupJVMTIDemo| which can be used to
>     pass additional source locations.
>   * Currently this is only used on AIX for the AIX porting utilities
>     which are required by hprof.
>
>
>         makefiles/lib/Awt2dLibraries.gmk
>         makefiles/lib/ServiceabilityLibraries.gmk
>
>   * On AIX add the sources of the AIX porting utilities to the build.
>     They are required by
>     |src/solaris/native/sun/awt/awt_LoadLibrary.c| and
>     |src/solaris/demo/jvmti/hprof/hprof_md.c| because |dladdr| is not
>     available on AIX.
>
>
>         makefiles/lib/NioLibraries.gmk
>
>   * Make the AIX-build aware of the new NIO source locations under
>     |src/aix/native/sun/nio/|.
>
>
>         makefiles/lib/NetworkingLibraries.gmk
>
>   * Make the AIX-build aware of the new |aix_close.c| source location
>     under |src/aix/native/java/net/|.
>
>
>         src/share/bin/jli_util.h
>
>   * Define |JLI_Lseek| on AIX.
>
>
>         src/share/lib/security/java.security-aix
>
>   * Provide default |java.security-aix| for AIX based on the latest
>     Linux version as suggested by Sean Mullan.
>
>
>         src/share/native/common/check_code.c
>
>   * On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which
>     is legal, but the code in |check_code.c| does not handles this
>     properly. So we wrap the two methods on AIX and return a non-NULL
>     pointer even if we allocate 0 bytes.
>
>
>         src/share/native/sun/awt/medialib/mlib_sys.c
>
>   * |malloc| always returns 8-byte aligned pointers on AIX as well.
>
>
>         src/share/native/sun/awt/medialib/mlib_types.h
>
>   * Add AIX to the list of known platforms.
>
>
>         src/share/native/sun/font/layout/KernTable.cpp
>
>   * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| is
>     too common and may be defined in other headers as well as on the
>     command line and |xlc| bails out on macro redefinitions with a
>     different value.
>
>
>         src/share/native/sun/security/ec/impl/ecc_impl.h
>
>   * Define required types and macros on AIX.
>
>
>         src/solaris/back/exec_md.c
>
>   * AIX behaves like Linux in this case so check for it in the Linux
>     branch.
>
>
>         src/solaris/bin/java_md_solinux.c,
>         src/solaris/bin/java_md_solinux.h
>
>   * On AIX |LD_LIBRARY_PATH| is called |LIBPATH|
>   * Always use |LD_LIBRARY_PATH| macro instead of using the string
>     "|LD_LIBRARY_PATH|" directly to cope with different library path
>     names.
>   * Add |jre/lib/<arch>/jli| to the standard library search path on
>     AIX because the AIX linker doesn't support the |-rpath| option.
>   * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in
>     this case, AIX behaves like Linux.
>   * Removed the definition of |JVM_DLL|, |JAVA_DLL| and
>     |LD_LIBRARY_PATH| from |java_md_solinux.h| because the macros are
>     redefined in the corresponding |.c| files anyway.
>
>
>         src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>
>   * Provide basic |fontconfig.properties|for AIX.
>
>
>         src/solaris/classes/java/lang/UNIXProcess.java.aix,
>         src/aix/classes/sun/tools/attach/AixAttachProvider.java,
>         src/aix/classes/sun/tools/attach/AixVirtualMachine.java,
>         src/aix/native/sun/tools/attach/AixVirtualMachine.c
>
>   * Provide AIX specific Java versions, mostly based on the
>     corresponding Linux versions.
>
>
>         src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java
>         src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java
>
>   * Detect AIX operating system and return the corresponding channel
>     and file system providers.
>
>
>         src/solaris/classes/sun/nio/ch/Port.java
>
>   * Add a callback function |unregisterImpl(int fd)| for
>     implementations that need special handling when |fd| is removed
>     and call it from |unregister(int fd)|. By default the
>     implementation of |unregisterImpl(int fd)| is empty except for the
>     derived |AixPollPort| class on AIX.
>
>
>         src/solaris/demo/jvmti/hprof/hprof_md.c
>
>   * Add AIX support. AIX mostly behaves like Linux, with the one
>     exception that it has no |dladdr| functionality.
>   * Use the |dladdr| implementation from |porting_aix.{c,h}| on AIX.
>
>
>         src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>
>   * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory).
>
>
>         src/solaris/native/common/jdk_util_md.h
>
>   * Add AIX definitions of the |ISNANF| and |ISNAND| macros.
>
>
>         src/solaris/native/java/io/io_util_md.c
>
>   * AIX behaves like Linux in this case so check for it in the Linux
>     branch.
>
>
>         src/solaris/native/java/lang/UNIXProcess_md.c
>
>   * AIX behaves mostly like Solraris in this case so adjust the ifdefs
>     accordingly.
>
>
>         src/solaris/native/java/lang/childproc.c
>
>   * AIX does not understand '/proc/self' - it requires the real
>     process ID to query the proc file system for the current process.
>
>
>         src/solaris/native/java/net/NetworkInterface.c
>
>   * Add AIX support into the Linux branch because AIX mostly behaves
>     like AIX for IPv4.
>   * AIX needs a special function to enumerate IPv6 interfaces and to
>     query the MAC address.
>   * Moved the declaration of |siocgifconfRequest| to the beginning a
>     the function (as recommend by Michael McMahon) to remain C89
>     compatible.
>
>
>         src/solaris/native/java/net/PlainSocketImpl.c
>
>   * On AIX (like on Solaris) |setsockopt| will set errno to |EINVAL|
>     if the socket is closed. The default error message is then confusing.
>
>
>         src/aix/native/java/net/aix_close.c,
>         src/share/native/java/net/net_util.c
>
>   * As recommended by Michael McMahon and Alan Bateman I've move an
>     adapted version of |linux_close.c| to
>     |src/aix/native/java/net/aix_close.c| because we also need the
>     file and socket wrappers on AIX.
>   * Compared to the Linux version, we've added the initialization of
>     some previously uninitialized data structures.
>   * Also, on AIX we don't have |__attribute((constructor))| so we need
>     to initialize manually (from |JNI_OnLoad()| in
>     |src/share/native/java/net/net_util.c|.
>
>
>         src/solaris/native/java/net/net_util_md.h
>
>   * AIX needs the same workaround for I/O cancellation like Linux and
>     MacOSX.
>
>
>         src/solaris/native/java/net/net_util_md.c
>
>   * |SO_REUSEADDR| is called |SO_REUSEPORT| on AIX.
>   * On AIX we have to ignore failures due to |ENOBUFS| when setting
>     the |SO_SNDBUF|/|SO_RCVBUF| socket options.
>
>
>         src/solaris/native/java/util/TimeZone_md.c
>
>   * Currently on AIX the only way to get the platform time zone is to
>     read it from the |TZ| environment variable.
>
>
>         src/solaris/native/sun/awt/awt_LoadLibrary.c
>
>   * Use the |dladdr| from |porting_aix.{c,h}| on AIX.
>
>
>         src/solaris/native/sun/awt/fontpath.c
>
>   * Changed some macros from |if !defined(__linux__)| to |if
>     defined(__solaris__)| because that's their real meaning.
>   * Add AIX specific fontpath settings and library search paths for
>     |libfontconfig.so|.
>
>
>         src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>
>   * Rename the |MIN| and |MAX| macros to |XSD_MIN| and |XSD_MAX| to
>     avoid name clashes (|MIN| and |MAX| are much too common and thexy
>     are already defined in some AIX system headers).
>
>
>         src/solaris/native/sun/java2d/x11/XRBackendNative.c
>
>   * Handle AIX like Solaris.
>
>
>         src/solaris/native/sun/nio/ch/Net.c
>
>   * Add AIX-specific includes and constant definitions.
>   * On AIX "socket extensions for multicast source filters" support
>     depends on the OS version. Check for this and throw appropriate
>     exceptions if it is requested but not supported. This is needed to
>     pass
>     JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast
>
>
>         src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
>
>   * On AIX |strerror()| is not thread-safe so we have to use
>     |strerror_r()| instead.
>   * On AIX |readdir_r()| returns EBADF (i.e. '9') and sets 'result' to
>     NULL for the directory stream end. Otherwise, 'errno' will contain
>     the error code.
>   * Handle some AIX corner cases for the results of the |statvfs64()|
>     call.
>   * On AIX |getgrgid_r()| returns ESRCH if group does not exist.
>
>
>         src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>
>   * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX.
>
>
>         test/java/lang/ProcessBuilder/Basic.java
>         test/java/lang/ProcessBuilder/DestroyTest.java
>
>   * Port this test to AIX and make it more robust (i.e. recognize the
>     "C" locale as |isEnglish()|, ignore VM-warnings in the output,
>     make sure the "grandchild" processes created by the test don't run
>     too long (60s vs. 6666s) because in the case of test problems
>     these processes will pollute the process space, make sure the test
>     fails with an error and doesn't hang indefinitley in the case of a
>     problem).
>
> *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this 
> intended?
>
> Well, |_AIX| is defined in some system headers while |AIX| is defined 
> by the build system. This is already used inconsistently (i.e. 
> |__linux__| vs. |LINUX|) and in general I try to be consistent with 
> the style of the file where I the changes are. That said, I changes 
> most of the occurences of |AIX| to |_AIX|.
>
> *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, 
> are they supposed to be there?
>
> We currently don't support OS/400 (later renamed into i5/OS and 
> currently called IBM i) in our OpenJDK port but we do support it in 
> our internel, SAP JVM build. We stripped out all the extra OS/400 
> functionality from the port but in some places where there is common 
> functionality needd by both, AIX and OS/400 the OS/400 support may 
> still be visible in the OpenJDK port. I don't think this is a real 
> problem and it helps us to keep our internel sources in sync with the 
> OpenJDK port. That said, I think I've removed all the references to 
> OS/400 now.
>
>



From lana.steuck at oracle.com  Mon Nov 25 22:35:46 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 25 Nov 2013 22:35:46 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/corba: 5 new changesets
Message-ID: <20131125223604.1ECFB62832@hg.openjdk.java.net>

Changeset: 7299367c8aa4
Author:    cl
Date:      2013-11-14 09:04 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/7299367c8aa4

Added tag jdk8-b116 for changeset 5fdc44652089

! .hgtags

Changeset: b99535e22efe
Author:    mchung
Date:      2013-11-07 20:48 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/b99535e22efe

8027943: serial version of com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImpl changed in 7u45
Reviewed-by: msheppar, alanb, lancea

! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java

Changeset: 4796555c4dc8
Author:    lana
Date:      2013-11-08 17:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/4796555c4dc8

Merge


Changeset: e53d1ee4d2ae
Author:    lana
Date:      2013-11-14 23:33 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/e53d1ee4d2ae

Merge


Changeset: d6820a414f18
Author:    cl
Date:      2013-11-21 09:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/d6820a414f18

Added tag jdk8-b117 for changeset e53d1ee4d2ae

! .hgtags



From andrew.brygin at oracle.com  Tue Nov 26 07:48:52 2013
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Tue, 26 Nov 2013 11:48:52 +0400
Subject: [OpenJDK 2D-Dev] Please review JDK-8028584
In-Reply-To: <5293B666.4020407@oracle.com>
References: <5293B666.4020407@oracle.com>
Message-ID: <52945264.40308@oracle.com>

Hello Jennifer,

  the fix looks fine to me.

Thanks,
Andrew

On 11/26/2013 12:43 AM, Jennifer Godinez wrote:
> http://cr.openjdk.java.net/~jgodinez/8028584/webrev.00/
>
> ClassCastException occurs when device uri is a file.  Added a check 
> for file and additional safeguard against cast exception.
>
> Jennifer



From volker.simonis at gmail.com  Tue Nov 26 09:57:17 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 26 Nov 2013 10:57:17 +0100
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <5293DC1F.4060205@oracle.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
	<5293DC1F.4060205@oracle.com>
Message-ID: <CA+3eh11EXobTJJBvXMR4N31BMyfEM1ED+eWX0uD-7B4CsaRosw@mail.gmail.com>

Hi Phil,

thanks a lot for the review. Please find my comments inline:


On Tue, Nov 26, 2013 at 12:24 AM, Phil Race <philip.race at oracle.com> wrote:

> Hi,
> I see you've already received a ton of good feedback on this v2.
>
> I have just a few  things to add.
> I don't know what symlinks might exist on AIX but it seems odd to
> me that you have :-
>
> 138 static char *fullAixFontPath[] = {
>  139     "/usr/lpp/X11/lib/X11/fonts/Type1",
> ..
>
> but the paths in the new file aix.fontconfig.properties look like this :-
>
> /usr/lib/X11/fonts/Type1/cour.pfa
>
>
You're absolutely right. I've updated 'aix.fontconfig.properties' to
contain the same absolute path like 'fontpath.c'. I've also added a comment
which describes to which AIX-package the fonts belong to and to which
locations they are sym-linked to.

Also for the build to pick up a file called
> *src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>
> *it seems like you should have added a section to handle this path to
> jdk/makefiles/gendata/GenDataFontConfig.gmk
>
> That seems to be where the new build handles such files.
>
> Are you seeing the .bfc and .src files created ?
>
>
You're right. But that was already added by the general AIX-build change
"8024900: PPC64: Enable new build on AIX (jdk part)" (
http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/diff/3ac08cd5e2e8/makefiles/GendataFontConfig.gmk
).

And yes, the .bfc and .src files are created and copied to the right places.


> At runtime it'll get picked up so so long as System.getProperty("os.name")
> returns "aix" (all lower-case) so I think that's OK. Its the build time
> part
> I'd expect to see but don't.
>
>
I did split the AIX change into several changes and the build changes have
been reviewed separately:

8024265: PPC64: Enable new build on AIX (
https://bugs.openjdk.java.net/browse/JDK-8024265)
8024900: PPC64: Enable new build on AIX (jdk part) (
https://bugs.openjdk.java.net/browse/JDK-8024900)

This change only contains the additional make changes which became
necessary after I started to move AIX-specific files into their own
jdk/src/aix/ directory. Everything else is already in place.

I'll prepare and test a finaly webrev with all the changes from this review
round today.

Thanks a lot,
Volker



> -phil.
>
>
> On 11/20/2013 10:26 AM, Volker Simonis wrote:
>
>> Hi,
>>
>> this is the second review round for "8024854: Basic changes and files to
>> build the class library on AIX <https://bugs.openjdk.java.
>> net/browse/JDK-8024854>". The previous reviews can be found at the end
>> of this mail in the references section.
>>
>>
>> I've tried to address all the comments and suggestions from the first
>> round and to further streamline the patch (it perfectly builds on
>> Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The
>> biggest change compared to the first review round is the new "aix/"
>> subdirectory which I've now created under "jdk/src" and which contains
>> AIX-only code.
>>
>> The webrev is against our http://hg.openjdk.java.net/ppc-aix-port/stagerepository which has been recently synchronised with the jdk8 master:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ <
>> http://cr.openjdk.java.net/%7Esimonis/webrevs/8024854.v2/>
>>
>>
>> Below (and in the webrev) you can find some comments which explain the
>> changes to each file. In order to be able to push this big change, I need
>> the approval of reviewers from the lib, net, svc, 2d, awt and sec groups.
>> So please don't hesitate to jump at it - there are enough changes for
>> everybody:)
>>
>> Thank you and best regards,
>> Volker
>>
>> *References:*
>>
>>
>> The following reviews have been posted so far (thanks Iris for collecting
>> them :)
>>
>> - Alan Bateman (lib): Initial comments (16 Sep [2])
>> - Chris Hegarty (lib/net): Initial comments (20 Sep [3])
>> - Michael McMahon (net): Initial comments (20 Sept [4])
>> - Steffan Larsen (svc): APPROVED (20 Sept [5])
>> - Phil Race (2d): Initial comments  (18 Sept [6]); Additional comments
>> (15 Oct [7])
>> - Sean Mullan (sec): Initial comments (26 Sept [8])
>>
>> [2]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001045.html
>> [3]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001078.html
>> [4]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001079.html
>> [5]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001077.html
>> [6]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001069.html
>> [7]: http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/
>> 003826.html
>> [8]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/
>> 2013-September/001081.html
>>
>>
>> *Detailed change description:*
>>
>>
>> The new "jdk/src/aix" subdirectory contains the following new and
>> AIX-specific files for now:
>>   src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>>   src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java
>>   src/aix/classes/sun/nio/ch/AixPollPort.java
>>   src/aix/classes/sun/nio/fs/AixFileStore.java
>>   src/aix/classes/sun/nio/fs/AixFileSystem.java
>>   src/aix/classes/sun/nio/fs/AixFileSystemProvider.java
>>   src/aix/classes/sun/nio/fs/AixNativeDispatcher.java
>>   src/aix/classes/sun/tools/attach/AixAttachProvider.java
>>   src/aix/classes/sun/tools/attach/AixVirtualMachine.java
>>   src/aix/native/java/net/aix_close.c
>>   src/aix/native/sun/nio/ch/AixPollPort.c
>>   src/aix/native/sun/nio/fs/AixNativeDispatcher.c
>>   src/aix/native/sun/tools/attach/AixVirtualMachine.c
>>   src/aix/porting/porting_aix.c
>>   src/aix/porting/porting_aix.h
>>
>>
>>         src/aix/porting/porting_aix.c
>>         src/aix/porting/porting_aix.h
>>
>>   * Added these two files for AIX relevant utility code.
>>   * Currently these files only contain an implementation of |dladdr|
>>
>>     which is not available on AIX.
>>   * In the first review round the existing |dladdr| users in the code
>>
>>     either called the version from the HotSpot on AIX
>>     (|src/solaris/native/sun/awt/awt_LoadLibrary.c|) or had a private
>>
>>     copy of the whole implementation
>>     (|src/solaris/demo/jvmti/hprof/hprof_md.c|). This is now not
>>
>>     necessary any more.
>>
>> The new file layout required some small changes to the makefiles to make
>> them aware of the new directory locations:
>>
>>
>>         makefiles/CompileDemos.gmk
>>
>>   * Add an extra argument to |SetupJVMTIDemo| which can be used to
>>     pass additional source locations.
>>   * Currently this is only used on AIX for the AIX porting utilities
>>
>>     which are required by hprof.
>>
>>
>>         makefiles/lib/Awt2dLibraries.gmk
>>         makefiles/lib/ServiceabilityLibraries.gmk
>>
>>   * On AIX add the sources of the AIX porting utilities to the build.
>>
>>     They are required by
>>     |src/solaris/native/sun/awt/awt_LoadLibrary.c| and
>>     |src/solaris/demo/jvmti/hprof/hprof_md.c| because |dladdr| is not
>>     available on AIX.
>>
>>
>>         makefiles/lib/NioLibraries.gmk
>>
>>   * Make the AIX-build aware of the new NIO source locations under
>>     |src/aix/native/sun/nio/|.
>>
>>
>>         makefiles/lib/NetworkingLibraries.gmk
>>
>>   * Make the AIX-build aware of the new |aix_close.c| source location
>>     under |src/aix/native/java/net/|.
>>
>>
>>         src/share/bin/jli_util.h
>>
>>   * Define |JLI_Lseek| on AIX.
>>
>>
>>         src/share/lib/security/java.security-aix
>>
>>   * Provide default |java.security-aix| for AIX based on the latest
>>
>>     Linux version as suggested by Sean Mullan.
>>
>>
>>         src/share/native/common/check_code.c
>>
>>   * On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which
>>
>>     is legal, but the code in |check_code.c| does not handles this
>>     properly. So we wrap the two methods on AIX and return a non-NULL
>>     pointer even if we allocate 0 bytes.
>>
>>
>>         src/share/native/sun/awt/medialib/mlib_sys.c
>>
>>   * |malloc| always returns 8-byte aligned pointers on AIX as well.
>>
>>
>>         src/share/native/sun/awt/medialib/mlib_types.h
>>
>>   * Add AIX to the list of known platforms.
>>
>>
>>         src/share/native/sun/font/layout/KernTable.cpp
>>
>>   * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| is
>>
>>     too common and may be defined in other headers as well as on the
>>     command line and |xlc| bails out on macro redefinitions with a
>>     different value.
>>
>>
>>         src/share/native/sun/security/ec/impl/ecc_impl.h
>>
>>   * Define required types and macros on AIX.
>>
>>
>>         src/solaris/back/exec_md.c
>>
>>   * AIX behaves like Linux in this case so check for it in the Linux
>>     branch.
>>
>>
>>         src/solaris/bin/java_md_solinux.c,
>>         src/solaris/bin/java_md_solinux.h
>>
>>   * On AIX |LD_LIBRARY_PATH| is called |LIBPATH|
>>   * Always use |LD_LIBRARY_PATH| macro instead of using the string
>>
>>     "|LD_LIBRARY_PATH|" directly to cope with different library path
>>     names.
>>   * Add |jre/lib/<arch>/jli| to the standard library search path on
>>
>>     AIX because the AIX linker doesn't support the |-rpath| option.
>>   * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in
>>
>>     this case, AIX behaves like Linux.
>>   * Removed the definition of |JVM_DLL|, |JAVA_DLL| and
>>
>>     |LD_LIBRARY_PATH| from |java_md_solinux.h| because the macros are
>>     redefined in the corresponding |.c| files anyway.
>>
>>
>>         src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>>
>>   * Provide basic |fontconfig.properties|for AIX.
>>
>>
>>         src/solaris/classes/java/lang/UNIXProcess.java.aix,
>>         src/aix/classes/sun/tools/attach/AixAttachProvider.java,
>>         src/aix/classes/sun/tools/attach/AixVirtualMachine.java,
>>         src/aix/native/sun/tools/attach/AixVirtualMachine.c
>>
>>   * Provide AIX specific Java versions, mostly based on the
>>
>>     corresponding Linux versions.
>>
>>
>>         src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProv
>> ider.java
>>         src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java
>>
>>   * Detect AIX operating system and return the corresponding channel
>>
>>     and file system providers.
>>
>>
>>         src/solaris/classes/sun/nio/ch/Port.java
>>
>>   * Add a callback function |unregisterImpl(int fd)| for
>>
>>     implementations that need special handling when |fd| is removed
>>     and call it from |unregister(int fd)|. By default the
>>
>>     implementation of |unregisterImpl(int fd)| is empty except for the
>>     derived |AixPollPort| class on AIX.
>>
>>
>>         src/solaris/demo/jvmti/hprof/hprof_md.c
>>
>>   * Add AIX support. AIX mostly behaves like Linux, with the one
>>
>>     exception that it has no |dladdr| functionality.
>>   * Use the |dladdr| implementation from |porting_aix.{c,h}| on AIX.
>>
>>
>>         src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>>
>>   * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory).
>>
>>
>>         src/solaris/native/common/jdk_util_md.h
>>
>>   * Add AIX definitions of the |ISNANF| and |ISNAND| macros.
>>
>>
>>         src/solaris/native/java/io/io_util_md.c
>>
>>   * AIX behaves like Linux in this case so check for it in the Linux
>>     branch.
>>
>>
>>         src/solaris/native/java/lang/UNIXProcess_md.c
>>
>>   * AIX behaves mostly like Solraris in this case so adjust the ifdefs
>>     accordingly.
>>
>>
>>         src/solaris/native/java/lang/childproc.c
>>
>>   * AIX does not understand '/proc/self' - it requires the real
>>
>>     process ID to query the proc file system for the current process.
>>
>>
>>         src/solaris/native/java/net/NetworkInterface.c
>>
>>   * Add AIX support into the Linux branch because AIX mostly behaves
>>     like AIX for IPv4.
>>   * AIX needs a special function to enumerate IPv6 interfaces and to
>>     query the MAC address.
>>   * Moved the declaration of |siocgifconfRequest| to the beginning a
>>
>>     the function (as recommend by Michael McMahon) to remain C89
>>     compatible.
>>
>>
>>         src/solaris/native/java/net/PlainSocketImpl.c
>>
>>   * On AIX (like on Solaris) |setsockopt| will set errno to |EINVAL|
>>
>>     if the socket is closed. The default error message is then confusing.
>>
>>
>>         src/aix/native/java/net/aix_close.c,
>>         src/share/native/java/net/net_util.c
>>
>>   * As recommended by Michael McMahon and Alan Bateman I've move an
>>
>>     adapted version of |linux_close.c| to
>>     |src/aix/native/java/net/aix_close.c| because we also need the
>>     file and socket wrappers on AIX.
>>   * Compared to the Linux version, we've added the initialization of
>>
>>     some previously uninitialized data structures.
>>   * Also, on AIX we don't have |__attribute((constructor))| so we need
>>
>>     to initialize manually (from |JNI_OnLoad()| in
>>     |src/share/native/java/net/net_util.c|.
>>
>>
>>         src/solaris/native/java/net/net_util_md.h
>>
>>   * AIX needs the same workaround for I/O cancellation like Linux and
>>     MacOSX.
>>
>>
>>         src/solaris/native/java/net/net_util_md.c
>>
>>   * |SO_REUSEADDR| is called |SO_REUSEPORT| on AIX.
>>   * On AIX we have to ignore failures due to |ENOBUFS| when setting
>>     the |SO_SNDBUF|/|SO_RCVBUF| socket options.
>>
>>
>>         src/solaris/native/java/util/TimeZone_md.c
>>
>>   * Currently on AIX the only way to get the platform time zone is to
>>
>>     read it from the |TZ| environment variable.
>>
>>
>>         src/solaris/native/sun/awt/awt_LoadLibrary.c
>>
>>   * Use the |dladdr| from |porting_aix.{c,h}| on AIX.
>>
>>
>>         src/solaris/native/sun/awt/fontpath.c
>>
>>   * Changed some macros from |if !defined(__linux__)| to |if
>>
>>     defined(__solaris__)| because that's their real meaning.
>>   * Add AIX specific fontpath settings and library search paths for
>>     |libfontconfig.so|.
>>
>>
>>         src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>>
>>   * Rename the |MIN| and |MAX| macros to |XSD_MIN| and |XSD_MAX| to
>>     avoid name clashes (|MIN| and |MAX| are much too common and thexy
>>
>>     are already defined in some AIX system headers).
>>
>>
>>         src/solaris/native/sun/java2d/x11/XRBackendNative.c
>>
>>   * Handle AIX like Solaris.
>>
>>
>>         src/solaris/native/sun/nio/ch/Net.c
>>
>>   * Add AIX-specific includes and constant definitions.
>>   * On AIX "socket extensions for multicast source filters" support
>>
>>     depends on the OS version. Check for this and throw appropriate
>>     exceptions if it is requested but not supported. This is needed to
>>     pass
>>     JCK-api/java_nio/channels/DatagramChannel/
>> DatagramChannel.html#Multicast
>>
>>
>>         src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
>>
>>   * On AIX |strerror()| is not thread-safe so we have to use
>>     |strerror_r()| instead.
>>   * On AIX |readdir_r()| returns EBADF (i.e. '9') and sets 'result' to
>>
>>     NULL for the directory stream end. Otherwise, 'errno' will contain
>>     the error code.
>>   * Handle some AIX corner cases for the results of the |statvfs64()|
>>     call.
>>   * On AIX |getgrgid_r()| returns ESRCH if group does not exist.
>>
>>
>>         src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>>
>>   * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX.
>>
>>
>>         test/java/lang/ProcessBuilder/Basic.java
>>         test/java/lang/ProcessBuilder/DestroyTest.java
>>
>>   * Port this test to AIX and make it more robust (i.e. recognize the
>>     "C" locale as |isEnglish()|, ignore VM-warnings in the output,
>>
>>     make sure the "grandchild" processes created by the test don't run
>>     too long (60s vs. 6666s) because in the case of test problems
>>     these processes will pollute the process space, make sure the test
>>     fails with an error and doesn't hang indefinitley in the case of a
>>     problem).
>>
>> *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this
>> intended?
>>
>> Well, |_AIX| is defined in some system headers while |AIX| is defined by
>> the build system. This is already used inconsistently (i.e. |__linux__| vs.
>> |LINUX|) and in general I try to be consistent with the style of the file
>> where I the changes are. That said, I changes most of the occurences of
>> |AIX| to |_AIX|.
>>
>> *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are
>> they supposed to be there?
>>
>>
>> We currently don't support OS/400 (later renamed into i5/OS and currently
>> called IBM i) in our OpenJDK port but we do support it in our internel, SAP
>> JVM build. We stripped out all the extra OS/400 functionality from the port
>> but in some places where there is common functionality needd by both, AIX
>> and OS/400 the OS/400 support may still be visible in the OpenJDK port. I
>> don't think this is a real problem and it helps us to keep our internel
>> sources in sync with the OpenJDK port. That said, I think I've removed all
>> the references to OS/400 now.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131126/3276cd8c/attachment.html>

From volker.simonis at gmail.com  Tue Nov 26 16:23:37 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 26 Nov 2013 17:23:37 +0100
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
Message-ID: <CA+3eh133mStOUeyoFEdN77MbuVWrMRW9fjs-j9R5RXi6k7Fn5g@mail.gmail.com>

Hi,

thanks to everybody for the prompt and helpful reviews. Here comes the
final webrev which incorporates all the corrections and suggestions from
the second review round:

http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/

I've successfully build (and run some smoke tests) with these changes on
Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, MacOSX and
AIX (5.3, 7.1).

So if nobody vetoes these changes are ready for push into our staging
repository.

@Vladimir: can I push them or do you want to run them trough JPRT?

Thank you and best regards,
Volker

PS: compared to the last webrev (
http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/), I've slightly
changed the following files:

makefiles/lib/Awt2dLibraries.gmk
makefiles/lib/NetworkingLibraries.gmk
makefiles/Setup.gmk
src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
src/aix/classes/sun/nio/ch/AixPollPort.java
src/aix/classes/sun/nio/fs/AixFileSystem.java
src/aix/native/java/net/aix_close.c
src/aix/porting/porting_aix.c
src/share/native/java/net/net_util.c
src/share/native/java/net/net_util.h
src/share/native/sun/awt/medialib/mlib_sys.c
src/solaris/bin/java_md_solinux.c
src/solaris/classes/sun/nio/ch/Port.java
src/solaris/native/java/net/net_util_md.c
src/solaris/native/sun/java2d/x11/XRBackendNative.c
src/solaris/native/sun/management/OperatingSystemImpl.c
src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
src/windows/native/java/net/net_util_md.c

Most of the changes are cosmetic, except the ones in:

src/share/native/java/net/net_util.c
src/share/native/java/net/net_util.h
src/solaris/native/java/net/net_util_md.c
src/windows/native/java/net/net_util_md.c

where I renamed 'initLocalAddrTable()' to 'platformInit()'. For AIX, this
method will now call 'aix_close_init()' as suggested by Alan.

The changes to src/solaris/native/com/sun/
management/UnixOperatingSystem_md.c are now in
src/solaris/native/sun/management/OperatingSystemImpl.c because that file
was moved by an upstream change.



On Wed, Nov 20, 2013 at 7:26 PM, Volker Simonis <volker.simonis at gmail.com>wrote:

> Hi,
>
> this is the second review round for "8024854: Basic changes and files to
> build the class library on AIX<https://bugs.openjdk.java.net/browse/JDK-8024854>".
> The previous reviews can be found at the end of this mail in the references
> section.
>
> I've tried to address all the comments and suggestions from the first
> round and to further streamline the patch (it perfectly builds on
> Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The
> biggest change compared to the first review round is the new "aix/"
> subdirectory which I've now created under "jdk/src" and which contains
> AIX-only code.
>
> The webrev is against our http://hg.openjdk.java.net/ppc-aix-port/stagerepository which has been recently synchronised with the jdk8 master:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/
>
> Below (and in the webrev) you can find some comments which explain the
> changes to each file. In order to be able to push this big change, I need
> the approval of reviewers from the lib, net, svc, 2d, awt and sec groups.
> So please don't hesitate to jump at it - there are enough changes for
> everybody:)
>
> Thank you and best regards,
> Volker
>
> *References:*
>
> The following reviews have been posted so far (thanks Iris for collecting
> them :)
>
> - Alan Bateman (lib): Initial comments (16 Sep [2])
> - Chris Hegarty (lib/net): Initial comments (20 Sep [3])
> - Michael McMahon (net): Initial comments (20 Sept [4])
> - Steffan Larsen (svc): APPROVED (20 Sept [5])
> - Phil Race (2d): Initial comments  (18 Sept [6]); Additional comments
> (15 Oct [7])
> - Sean Mullan (sec): Initial comments (26 Sept [8])
>
> [2]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html
> [3]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html
> [4]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html
> [5]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html
> [6]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html
> [7]:
> http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html
> [8]:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html
>
>
> *Detailed change description:*
>
> The new "jdk/src/aix" subdirectory contains the following new and
> AIX-specific files for now:
>
>  src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>  src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java
>  src/aix/classes/sun/nio/ch/AixPollPort.java
>  src/aix/classes/sun/nio/fs/AixFileStore.java
>  src/aix/classes/sun/nio/fs/AixFileSystem.java
>  src/aix/classes/sun/nio/fs/AixFileSystemProvider.java
>  src/aix/classes/sun/nio/fs/AixNativeDispatcher.java
>  src/aix/classes/sun/tools/attach/AixAttachProvider.java
>  src/aix/classes/sun/tools/attach/AixVirtualMachine.java
>  src/aix/native/java/net/aix_close.c
>  src/aix/native/sun/nio/ch/AixPollPort.c
>  src/aix/native/sun/nio/fs/AixNativeDispatcher.c
>  src/aix/native/sun/tools/attach/AixVirtualMachine.c
>  src/aix/porting/porting_aix.c
>  src/aix/porting/porting_aix.h
>
> src/aix/porting/porting_aix.c
> src/aix/porting/porting_aix.h
>
>    - Added these two files for AIX relevant utility code.
>    - Currently these files only contain an implementation of dladdr which
>    is not available on AIX.
>    - In the first review round the existing dladdr users in the code
>    either called the version from the HotSpot on AIX (
>    src/solaris/native/sun/awt/awt_LoadLibrary.c) or had a private copy of
>    the whole implementation (src/solaris/demo/jvmti/hprof/hprof_md.c).
>    This is now not necessary any more.
>
>  The new file layout required some small changes to the makefiles to make
> them aware of the new directory locations:
>
> makefiles/CompileDemos.gmk
>
>    - Add an extra argument to SetupJVMTIDemo which can be used to pass
>    additional source locations.
>    - Currently this is only used on AIX for the AIX porting utilities
>    which are required by hprof.
>
> makefiles/lib/Awt2dLibraries.gmk
> makefiles/lib/ServiceabilityLibraries.gmk
>
>    - On AIX add the sources of the AIX porting utilities to the build.
>    They are required by src/solaris/native/sun/awt/awt_LoadLibrary.c and
>    src/solaris/demo/jvmti/hprof/hprof_md.c because dladdr is not
>    available on AIX.
>
> makefiles/lib/NioLibraries.gmk
>
>    - Make the AIX-build aware of the new NIO source locations under
>    src/aix/native/sun/nio/.
>
> makefiles/lib/NetworkingLibraries.gmk
>
>    - Make the AIX-build aware of the new aix_close.c source location
>    under src/aix/native/java/net/.
>
> src/share/bin/jli_util.h
>
>    - Define JLI_Lseek on AIX.
>
> src/share/lib/security/java.security-aix
>
>    - Provide default java.security-aix for AIX based on the latest Linux
>    version as suggested by Sean Mullan.
>
> src/share/native/common/check_code.c
>
>    - On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is
>    legal, but the code in check_code.c does not handles this properly. So
>    we wrap the two methods on AIX and return a non-NULL pointer even if we
>    allocate 0 bytes.
>
> src/share/native/sun/awt/medialib/mlib_sys.c
>
>    - malloc always returns 8-byte aligned pointers on AIX as well.
>
> src/share/native/sun/awt/medialib/mlib_types.h
>
>    - Add AIX to the list of known platforms.
>
> src/share/native/sun/font/layout/KernTable.cpp
>
>    - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too
>    common and may be defined in other headers as well as on the command line
>    and xlc bails out on macro redefinitions with a different value.
>
> src/share/native/sun/security/ec/impl/ecc_impl.h
>
>    - Define required types and macros on AIX.
>
> src/solaris/back/exec_md.c
>
>    - AIX behaves like Linux in this case so check for it in the Linux
>    branch.
>
> src/solaris/bin/java_md_solinux.c,
> src/solaris/bin/java_md_solinux.h
>
>    - On AIX LD_LIBRARY_PATH is called LIBPATH
>    - Always use LD_LIBRARY_PATH macro instead of using the string "
>    LD_LIBRARY_PATH" directly to cope with different library path names.
>    - Add jre/lib/<arch>/jli to the standard library search path on AIX
>    because the AIX linker doesn't support the -rpath option.
>    - Replace #ifdef __linux__ by #ifndef __solaris__ because in this
>    case, AIX behaves like Linux.
>    - Removed the definition of JVM_DLL, JAVA_DLL and LD_LIBRARY_PATH from
>    java_md_solinux.h because the macros are redefined in the
>    corresponding .c files anyway.
>
> src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>
>    - Provide basic fontconfig.propertiesfor AIX.
>
> src/solaris/classes/java/lang/UNIXProcess.java.aix,
> src/aix/classes/sun/tools/attach/AixAttachProvider.java,
> src/aix/classes/sun/tools/attach/AixVirtualMachine.java,
> src/aix/native/sun/tools/attach/AixVirtualMachine.c
>
>    - Provide AIX specific Java versions, mostly based on the
>    corresponding Linux versions.
>
> src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java
> src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java
>
>    - Detect AIX operating system and return the corresponding channel and
>    file system providers.
>
> src/solaris/classes/sun/nio/ch/Port.java
>
>    - Add a callback function unregisterImpl(int fd) for implementations
>    that need special handling when fd is removed and call it from unregister(int
>    fd). By default the implementation of unregisterImpl(int fd) is empty
>    except for the derived AixPollPort class on AIX.
>
> src/solaris/demo/jvmti/hprof/hprof_md.c
>
>    - Add AIX support. AIX mostly behaves like Linux, with the one
>    exception that it has no dladdr functionality.
>    - Use the dladdr implementation from porting_aix.{c,h} on AIX.
>
> src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>
>    - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory).
>
> src/solaris/native/common/jdk_util_md.h
>
>    - Add AIX definitions of the ISNANF and ISNAND macros.
>
> src/solaris/native/java/io/io_util_md.c
>
>    - AIX behaves like Linux in this case so check for it in the Linux
>    branch.
>
> src/solaris/native/java/lang/UNIXProcess_md.c
>
>    - AIX behaves mostly like Solraris in this case so adjust the ifdefs
>    accordingly.
>
> src/solaris/native/java/lang/childproc.c
>
>    - AIX does not understand '/proc/self' - it requires the real process
>    ID to query the proc file system for the current process.
>
> src/solaris/native/java/net/NetworkInterface.c
>
>    - Add AIX support into the Linux branch because AIX mostly behaves
>    like AIX for IPv4.
>    - AIX needs a special function to enumerate IPv6 interfaces and to
>    query the MAC address.
>    - Moved the declaration of siocgifconfRequest to the beginning a the
>    function (as recommend by Michael McMahon) to remain C89 compatible.
>
> src/solaris/native/java/net/PlainSocketImpl.c
>
>    - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the
>    socket is closed. The default error message is then confusing.
>
> src/aix/native/java/net/aix_close.c,
> src/share/native/java/net/net_util.c
>
>    - As recommended by Michael McMahon and Alan Bateman I've move an
>    adapted version of linux_close.c to src/aix/native/java/net/aix_close.cbecause we also need the file and socket wrappers on AIX.
>    - Compared to the Linux version, we've added the initialization of
>    some previously uninitialized data structures.
>    - Also, on AIX we don't have __attribute((constructor)) so we need to
>    initialize manually (from JNI_OnLoad() in
>    src/share/native/java/net/net_util.c.
>
> src/solaris/native/java/net/net_util_md.h
>
>    - AIX needs the same workaround for I/O cancellation like Linux and
>    MacOSX.
>
> src/solaris/native/java/net/net_util_md.c
>
>    - SO_REUSEADDR is called SO_REUSEPORT on AIX.
>    - On AIX we have to ignore failures due to ENOBUFS when setting the
>    SO_SNDBUF/SO_RCVBUF socket options.
>
> src/solaris/native/java/util/TimeZone_md.c
>
>    - Currently on AIX the only way to get the platform time zone is to
>    read it from the TZ environment variable.
>
> src/solaris/native/sun/awt/awt_LoadLibrary.c
>
>    - Use the dladdr from porting_aix.{c,h} on AIX.
>
> src/solaris/native/sun/awt/fontpath.c
>
>    - Changed some macros from if !defined(__linux__) to if
>    defined(__solaris__) because that's their real meaning.
>    - Add AIX specific fontpath settings and library search paths for
>    libfontconfig.so.
>
> src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>
>    - Rename the MIN and MAX macros to XSD_MIN and XSD_MAX to avoid name
>    clashes (MIN and MAX are much too common and thexy are already defined
>    in some AIX system headers).
>
> src/solaris/native/sun/java2d/x11/XRBackendNative.c
>
>    - Handle AIX like Solaris.
>
> src/solaris/native/sun/nio/ch/Net.c
>
>    - Add AIX-specific includes and constant definitions.
>    - On AIX "socket extensions for multicast source filters" support
>    depends on the OS version. Check for this and throw appropriate exceptions
>    if it is requested but not supported. This is needed to pass
>    JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast
>
> src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
>
>    - On AIX strerror() is not thread-safe so we have to use strerror_r()instead.
>    - On AIX readdir_r() returns EBADF (i.e. '9') and sets 'result' to
>    NULL for the directory stream end. Otherwise, 'errno' will contain the
>    error code.
>    - Handle some AIX corner cases for the results of the statvfs64() call.
>    - On AIX getgrgid_r() returns ESRCH if group does not exist.
>
> src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>
>    - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX.
>
> test/java/lang/ProcessBuilder/Basic.java
> test/java/lang/ProcessBuilder/DestroyTest.java
>
>    - Port this test to AIX and make it more robust (i.e. recognize the
>    "C" locale as isEnglish(), ignore VM-warnings in the output, make sure
>    the "grandchild" processes created by the test don't run too long (60s vs.
>    6666s) because in the case of test problems these processes will pollute
>    the process space, make sure the test fails with an error and doesn't hang
>    indefinitley in the case of a problem).
>
>  *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this
> intended?
>
> Well, _AIX is defined in some system headers while AIX is defined by the
> build system. This is already used inconsistently (i.e. __linux__ vs.
> LINUX) and in general I try to be consistent with the style of the file
> where I the changes are. That said, I changes most of the occurences of
> AIX to _AIX.
>
> *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are
> they supposed to be there?
>
> We currently don't support OS/400 (later renamed into i5/OS and currently
> called IBM i) in our OpenJDK port but we do support it in our internel, SAP
> JVM build. We stripped out all the extra OS/400 functionality from the port
> but in some places where there is common functionality needd by both, AIX
> and OS/400 the OS/400 support may still be visible in the OpenJDK port. I
> don't think this is a real problem and it helps us to keep our internel
> sources in sync with the OpenJDK port. That said, I think I've removed all
> the references to OS/400 now.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131126/07f59421/attachment.html>

From Alan.Bateman at oracle.com  Tue Nov 26 17:03:15 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 26 Nov 2013 17:03:15 +0000
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <CA+3eh133mStOUeyoFEdN77MbuVWrMRW9fjs-j9R5RXi6k7Fn5g@mail.gmail.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
	<CA+3eh133mStOUeyoFEdN77MbuVWrMRW9fjs-j9R5RXi6k7Fn5g@mail.gmail.com>
Message-ID: <5294D453.5050402@oracle.com>

On 26/11/2013 16:23, Volker Simonis wrote:
> Hi,
>
> thanks to everybody for the prompt and helpful reviews. Here comes the
> final webrev which incorporates all the corrections and suggestions from
> the second review round:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/
>
> I've successfully build (and run some smoke tests) with these changes on
> Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, MacOSX and
> AIX (5.3, 7.1).
>
I've skimmed over the last webrev with focus on:

NetworkingLibraries.gmk where I see this is now fixed for all platforms.

net_util.* and the platform specific net_util_md.* where I see you've 
added platformInit so it's much cleaner.

UnixNativeDispatcher.c where the error translation is now removed (and 
looks fine).

So overall it looks good to me and should be pushed to the staging 
forest once you hear from others that commented previously.

-Alan


From jennifer.godinez at oracle.com  Tue Nov 26 18:25:55 2013
From: jennifer.godinez at oracle.com (jennifer.godinez at oracle.com)
Date: Tue, 26 Nov 2013 18:25:55 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 8028584:
	sun.net.www.protocol.file.FileURLConnection	cannot be cast to
	java.net.HttpURLConnection
Message-ID: <20131126182639.AAE4E62876@hg.openjdk.java.net>

Changeset: 723bcc68738b
Author:    jgodinez
Date:      2013-11-26 10:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/723bcc68738b

8028584: sun.net.www.protocol.file.FileURLConnection cannot be cast to java.net.HttpURLConnection
Reviewed-by: bae, prr

! src/solaris/classes/sun/print/IPPPrintService.java
! src/solaris/classes/sun/print/UnixPrintServiceLookup.java
! test/java/awt/print/PageFormat/PageFormatFromAttributes.java



From iris.clark at oracle.com  Tue Nov 26 18:08:51 2013
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 26 Nov 2013 10:08:51 -0800 (PST)
Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and
 files to build the class library on AIX
In-Reply-To: <5294D453.5050402@oracle.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
	<CA+3eh133mStOUeyoFEdN77MbuVWrMRW9fjs-j9R5RXi6k7Fn5g@mail.gmail.com>
	<5294D453.5050402@oracle.com>
Message-ID: <b9383e9c-e0e0-4349-b8f2-4c6a83a13e09@default>

> So overall it looks good to me and should be pushed to the staging > forest once you hear from others that commented previously.

I think that means Chris Hegarty, Michael McMahon, and Sergey Bylokhov.  Alan, please correct me if I'm wrong.

Thanks,
iris

-----Original Message-----
From: Alan Bateman 
Sent: Tuesday, November 26, 2013 9:03 AM
To: Volker Simonis
Cc: Vladimir Kozlov; 2d-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; security-dev; ppc-aix-port-dev at openjdk.java.net; awt-dev at openjdk.java.net; Java Core Libs; net-dev
Subject: Re: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

On 26/11/2013 16:23, Volker Simonis wrote:
> Hi,
>
> thanks to everybody for the prompt and helpful reviews. Here comes the 
> final webrev which incorporates all the corrections and suggestions 
> from the second review round:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/
>
> I've successfully build (and run some smoke tests) with these changes 
> on Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, 
> MacOSX and AIX (5.3, 7.1).
>
I've skimmed over the last webrev with focus on:

NetworkingLibraries.gmk where I see this is now fixed for all platforms.

net_util.* and the platform specific net_util_md.* where I see you've added platformInit so it's much cleaner.

UnixNativeDispatcher.c where the error translation is now removed (and looks fine).

So overall it looks good to me and should be pushed to the staging forest once you hear from others that commented previously.

-Alan


From iris.clark at oracle.com  Tue Nov 26 19:18:19 2013
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 26 Nov 2013 11:18:19 -0800 (PST)
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR(L) - 2nd round: 8024854: Basic
 changes and files to build the class library on AIX
In-Reply-To: <5294EDB7.8020408@oracle.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
	<CA+3eh133mStOUeyoFEdN77MbuVWrMRW9fjs-j9R5RXi6k7Fn5g@mail.gmail.com>
	<5294D453.5050402@oracle.com> <5294EDB7.8020408@oracle.com>
Message-ID: <20bfb263-7e01-484f-b7b2-94d6516141bd@default>

Hi.

>> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/

> + src/solaris/classes/java/lang/UNIXProcess.java.aix
>     2  * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved.
>     3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Oracle copyright in acceptable location and uses correct format.

> + src/aix/porting/porting_aix.h
>     2  * Copyright 2012, 2013 SAP AG. All rights reserved.
>     3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

SAP copyright in acceptable location.

> + src/aix/native/sun/tools/attach/AixVirtualMachine.c
>     2  * Copyright (c) 2008, 2013, Oracle and/or its affiliates. All rights reserved.
>     3  * Copyright 2013 SAP AG. All rights reserved.
>     4  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER

Oracle and SAP copyrights in acceptable locations.  Oracle format is correct.

The licenses (GPL+CP) look fine to me.

Thanks,
iris

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, November 26, 2013 10:52 AM
To: Alan Bateman; Volker Simonis
Cc: 2d-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; security-dev; ppc-aix-port-dev at openjdk.java.net; awt-dev at openjdk.java.net; Java Core Libs; net-dev
Subject: Re: <AWT Dev> RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

On 26.11.2013 21:03, Alan Bateman wrote:
> On 26/11/2013 16:23, Volker Simonis wrote:
>> Hi,
>>
>> thanks to everybody for the prompt and helpful reviews. Here comes 
>> the final webrev which incorporates all the corrections and 
>> suggestions from the second review round:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/
>>
>> I've successfully build (and run some smoke tests) with these changes 
>> on Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, 
>> MacOSX and AIX (5.3, 7.1).
>>
> I've skimmed over the last webrev with focus on:
>
> NetworkingLibraries.gmk where I see this is now fixed for all platforms.
>
> net_util.* and the platform specific net_util_md.* where I see you've 
> added platformInit so it's much cleaner.
I have a question about boolean_t in the [1]. Is it correct to skip it in the new block?
http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/src/share/native/sun/security/ec/impl/ecc_impl.h.frames.html

Also I have a question about headers in the added files. Looks like different templates are used:

+ src/solaris/classes/java/lang/UNIXProcess.java.aix
    2  * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved.
    3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ src/aix/porting/porting_aix.h
    2  * Copyright 2012, 2013 SAP AG. All rights reserved.
    3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ src/aix/native/sun/tools/attach/AixVirtualMachine.c
    2  * Copyright (c) 2008, 2013, Oracle and/or its affiliates. All rights reserved.
    3  * Copyright 2013 SAP AG. All rights reserved.
    4  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

etc..

Do we have some rules about that?
>
> UnixNativeDispatcher.c where the error translation is now removed (and 
> looks fine).
>
> So overall it looks good to me and should be pushed to the staging 
> forest once you hear from others that commented previously.
>
> -Alan


--
Best regards, Sergey.



From philip.race at oracle.com  Tue Nov 26 20:01:11 2013
From: philip.race at oracle.com (Phil Race)
Date: Tue, 26 Nov 2013 12:01:11 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR(L) - 2nd round: 8024854: Basic
 changes and files to build the class library on AIX
In-Reply-To: <CA+3eh133mStOUeyoFEdN77MbuVWrMRW9fjs-j9R5RXi6k7Fn5g@mail.gmail.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
	<CA+3eh133mStOUeyoFEdN77MbuVWrMRW9fjs-j9R5RXi6k7Fn5g@mail.gmail.com>
Message-ID: <5294FE07.3060309@oracle.com>

Looking only at what you needed to change this time round, all seems 
fine now.

-phil.

On 11/26/13 8:23 AM, Volker Simonis wrote:
> Hi,
>
> thanks to everybody for the prompt and helpful reviews. Here comes the 
> final webrev which incorporates all the corrections and suggestions 
> from the second review round:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/ 
> <http://cr.openjdk.java.net/%7Esimonis/webrevs/8024854.v3/>
>
> I've successfully build (and run some smoke tests) with these changes 
> on Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, 
> MacOSX and AIX (5.3, 7.1).
>
> So if nobody vetoes these changes are ready for push into our staging 
> repository.
>
> @Vladimir: can I push them or do you want to run them trough JPRT?
>
> Thank you and best regards,
> Volker
>
> PS: compared to the last webrev 
> (http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ 
> <http://cr.openjdk.java.net/%7Esimonis/webrevs/8024854.v2/>), I've 
> slightly changed the following files:
>
> makefiles/lib/Awt2dLibraries.gmk
> makefiles/lib/NetworkingLibraries.gmk
> makefiles/Setup.gmk
> src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
> src/aix/classes/sun/nio/ch/AixPollPort.java
> src/aix/classes/sun/nio/fs/AixFileSystem.java
> src/aix/native/java/net/aix_close.c
> src/aix/porting/porting_aix.c
> src/share/native/java/net/net_util.c
> src/share/native/java/net/net_util.h
> src/share/native/sun/awt/medialib/mlib_sys.c
> src/solaris/bin/java_md_solinux.c
> src/solaris/classes/sun/nio/ch/Port.java
> src/solaris/native/java/net/net_util_md.c
> src/solaris/native/sun/java2d/x11/XRBackendNative.c
> src/solaris/native/sun/management/OperatingSystemImpl.c
> src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
> src/windows/native/java/net/net_util_md.c
>
> Most of the changes are cosmetic, except the ones in:
>
> src/share/native/java/net/net_util.c
> src/share/native/java/net/net_util.h
> src/solaris/native/java/net/net_util_md.c
> src/windows/native/java/net/net_util_md.c
>
> where I renamed 'initLocalAddrTable()' to 'platformInit()'. For AIX, 
> this method will now call 'aix_close_init()' as suggested by Alan.
>
> The changes to src/solaris/native/com/sun/ 
> management/UnixOperatingSystem_md.c are now in 
> src/solaris/native/sun/management/OperatingSystemImpl.c because that 
> file was moved by an upstream change.
>
>
>
> On Wed, Nov 20, 2013 at 7:26 PM, Volker Simonis 
> <volker.simonis at gmail.com <mailto:volker.simonis at gmail.com>> wrote:
>
>     Hi,
>
>     this is the second review round for "8024854: Basic changes and
>     files to build the class library on AIX
>     <https://bugs.openjdk.java.net/browse/JDK-8024854>". The previous
>     reviews can be found at the end of this mail in the references
>     section.
>
>     I've tried to address all the comments and suggestions from the
>     first round and to further streamline the patch (it perfectly
>     builds on Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and
>     Windows/x86_64). The biggest change compared to the first review
>     round is the new "aix/" subdirectory which I've now created under
>     "jdk/src" and which contains AIX-only code.
>
>     The webrev is against our
>     http://hg.openjdk.java.net/ppc-aix-port/stage repository which has
>     been recently synchronised with the jdk8 master:
>
>     http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/
>     <http://cr.openjdk.java.net/%7Esimonis/webrevs/8024854.v2/>
>
>     Below (and in the webrev) you can find some comments which explain
>     the changes to each file. In order to be able to push this big
>     change, I need the approval of reviewers from the lib, net, svc,
>     2d, awt and sec groups. So please don't hesitate to jump at it -
>     there are enough changes for everybody:)
>
>     Thank you and best regards,
>     Volker
>
>     *References:*
>
>     The following reviews have been posted so far (thanks Iris for
>     collecting them :)
>
>     - Alan Bateman (lib): Initial comments (16 Sep [2])
>     - Chris Hegarty (lib/net): Initial comments (20 Sep [3])
>     - Michael McMahon (net): Initial comments (20 Sept [4])
>     - Steffan Larsen (svc): APPROVED (20 Sept [5])
>     - Phil Race (2d): Initial comments  (18 Sept [6]); Additional
>     comments (15 Oct [7])
>     - Sean Mullan (sec): Initial comments (26 Sept [8])
>
>     [2]:
>     http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html
>     [3]:
>     http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html
>     [4]:
>     http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html
>     [5]:
>     http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html
>     [6]:
>     http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html
>     [7]:
>     http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html
>     [8]:
>     http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html
>
>
>     *Detailed change description:*
>
>     The new "jdk/src/aix" subdirectory contains the following new and
>     AIX-specific files for now:
>
>       src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>       src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java
>       src/aix/classes/sun/nio/ch/AixPollPort.java
>       src/aix/classes/sun/nio/fs/AixFileStore.java
>       src/aix/classes/sun/nio/fs/AixFileSystem.java
>       src/aix/classes/sun/nio/fs/AixFileSystemProvider.java
>       src/aix/classes/sun/nio/fs/AixNativeDispatcher.java
>       src/aix/classes/sun/tools/attach/AixAttachProvider.java
>       src/aix/classes/sun/tools/attach/AixVirtualMachine.java
>       src/aix/native/java/net/aix_close.c
>       src/aix/native/sun/nio/ch/AixPollPort.c
>       src/aix/native/sun/nio/fs/AixNativeDispatcher.c
>       src/aix/native/sun/tools/attach/AixVirtualMachine.c
>       src/aix/porting/porting_aix.c
>       src/aix/porting/porting_aix.h
>
>
>             src/aix/porting/porting_aix.c
>             src/aix/porting/porting_aix.h
>
>       * Added these two files for AIX relevant utility code.
>       * Currently these files only contain an implementation of
>         |dladdr| which is not available on AIX.
>       * In the first review round the existing |dladdr| users in the
>         code either called the version from the HotSpot on AIX
>         (|src/solaris/native/sun/awt/awt_LoadLibrary.c|) or had a
>         private copy of the whole implementation
>         (|src/solaris/demo/jvmti/hprof/hprof_md.c|). This is now not
>         necessary any more.
>
>     The new file layout required some small changes to the makefiles
>     to make them aware of the new directory locations:
>
>
>             makefiles/CompileDemos.gmk
>
>       * Add an extra argument to |SetupJVMTIDemo| which can be used to
>         pass additional source locations.
>       * Currently this is only used on AIX for the AIX porting
>         utilities which are required by hprof.
>
>
>             makefiles/lib/Awt2dLibraries.gmk
>             makefiles/lib/ServiceabilityLibraries.gmk
>
>       * On AIX add the sources of the AIX porting utilities to the
>         build. They are required by
>         |src/solaris/native/sun/awt/awt_LoadLibrary.c| and
>         |src/solaris/demo/jvmti/hprof/hprof_md.c| because |dladdr| is
>         not available on AIX.
>
>
>             makefiles/lib/NioLibraries.gmk
>
>       * Make the AIX-build aware of the new NIO source locations under
>         |src/aix/native/sun/nio/|.
>
>
>             makefiles/lib/NetworkingLibraries.gmk
>
>       * Make the AIX-build aware of the new |aix_close.c| source
>         location under |src/aix/native/java/net/|.
>
>
>             src/share/bin/jli_util.h
>
>       * Define |JLI_Lseek| on AIX.
>
>
>             src/share/lib/security/java.security-aix
>
>       * Provide default |java.security-aix| for AIX based on the
>         latest Linux version as suggested by Sean Mullan.
>
>
>             src/share/native/common/check_code.c
>
>       * On AIX malloc(0) and calloc(0, ...) return a NULL pointer,
>         which is legal, but the code in |check_code.c| does not
>         handles this properly. So we wrap the two methods on AIX and
>         return a non-NULL pointer even if we allocate 0 bytes.
>
>
>             src/share/native/sun/awt/medialib/mlib_sys.c
>
>       * |malloc| always returns 8-byte aligned pointers on AIX as well.
>
>
>             src/share/native/sun/awt/medialib/mlib_types.h
>
>       * Add AIX to the list of known platforms.
>
>
>             src/share/native/sun/font/layout/KernTable.cpp
>
>       * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG|
>         is too common and may be defined in other headers as well as
>         on the command line and |xlc| bails out on macro redefinitions
>         with a different value.
>
>
>             src/share/native/sun/security/ec/impl/ecc_impl.h
>
>       * Define required types and macros on AIX.
>
>
>             src/solaris/back/exec_md.c
>
>       * AIX behaves like Linux in this case so check for it in the
>         Linux branch.
>
>
>             src/solaris/bin/java_md_solinux.c,
>             src/solaris/bin/java_md_solinux.h
>
>       * On AIX |LD_LIBRARY_PATH| is called |LIBPATH|
>       * Always use |LD_LIBRARY_PATH| macro instead of using the string
>         "|LD_LIBRARY_PATH|" directly to cope with different library
>         path names.
>       * Add |jre/lib/<arch>/jli| to the standard library search path
>         on AIX because the AIX linker doesn't support the |-rpath| option.
>       * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in
>         this case, AIX behaves like Linux.
>       * Removed the definition of |JVM_DLL|, |JAVA_DLL| and
>         |LD_LIBRARY_PATH| from |java_md_solinux.h| because the macros
>         are redefined in the corresponding |.c| files anyway.
>
>
>             src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>
>       * Provide basic |fontconfig.properties|for AIX.
>
>
>             src/solaris/classes/java/lang/UNIXProcess.java.aix,
>             src/aix/classes/sun/tools/attach/AixAttachProvider.java,
>             src/aix/classes/sun/tools/attach/AixVirtualMachine.java,
>             src/aix/native/sun/tools/attach/AixVirtualMachine.c
>
>       * Provide AIX specific Java versions, mostly based on the
>         corresponding Linux versions.
>
>
>             src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java
>             src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java
>
>       * Detect AIX operating system and return the corresponding
>         channel and file system providers.
>
>
>             src/solaris/classes/sun/nio/ch/Port.java
>
>       * Add a callback function |unregisterImpl(int fd)| for
>         implementations that need special handling when |fd| is
>         removed and call it from |unregister(int fd)|. By default the
>         implementation of |unregisterImpl(int fd)| is empty except for
>         the derived |AixPollPort| class on AIX.
>
>
>             src/solaris/demo/jvmti/hprof/hprof_md.c
>
>       * Add AIX support. AIX mostly behaves like Linux, with the one
>         exception that it has no |dladdr| functionality.
>       * Use the |dladdr| implementation from |porting_aix.{c,h}| on AIX.
>
>
>             src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>
>       * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory).
>
>
>             src/solaris/native/common/jdk_util_md.h
>
>       * Add AIX definitions of the |ISNANF| and |ISNAND| macros.
>
>
>             src/solaris/native/java/io/io_util_md.c
>
>       * AIX behaves like Linux in this case so check for it in the
>         Linux branch.
>
>
>             src/solaris/native/java/lang/UNIXProcess_md.c
>
>       * AIX behaves mostly like Solraris in this case so adjust the
>         ifdefs accordingly.
>
>
>             src/solaris/native/java/lang/childproc.c
>
>       * AIX does not understand '/proc/self' - it requires the real
>         process ID to query the proc file system for the current process.
>
>
>             src/solaris/native/java/net/NetworkInterface.c
>
>       * Add AIX support into the Linux branch because AIX mostly
>         behaves like AIX for IPv4.
>       * AIX needs a special function to enumerate IPv6 interfaces and
>         to query the MAC address.
>       * Moved the declaration of |siocgifconfRequest| to the beginning
>         a the function (as recommend by Michael McMahon) to remain C89
>         compatible.
>
>
>             src/solaris/native/java/net/PlainSocketImpl.c
>
>       * On AIX (like on Solaris) |setsockopt| will set errno to
>         |EINVAL| if the socket is closed. The default error message is
>         then confusing.
>
>
>             src/aix/native/java/net/aix_close.c,
>             src/share/native/java/net/net_util.c
>
>       * As recommended by Michael McMahon and Alan Bateman I've move
>         an adapted version of |linux_close.c| to
>         |src/aix/native/java/net/aix_close.c| because we also need the
>         file and socket wrappers on AIX.
>       * Compared to the Linux version, we've added the initialization
>         of some previously uninitialized data structures.
>       * Also, on AIX we don't have |__attribute((constructor))| so we
>         need to initialize manually (from |JNI_OnLoad()| in
>         |src/share/native/java/net/net_util.c|.
>
>
>             src/solaris/native/java/net/net_util_md.h
>
>       * AIX needs the same workaround for I/O cancellation like Linux
>         and MacOSX.
>
>
>             src/solaris/native/java/net/net_util_md.c
>
>       * |SO_REUSEADDR| is called |SO_REUSEPORT| on AIX.
>       * On AIX we have to ignore failures due to |ENOBUFS| when
>         setting the |SO_SNDBUF|/|SO_RCVBUF| socket options.
>
>
>             src/solaris/native/java/util/TimeZone_md.c
>
>       * Currently on AIX the only way to get the platform time zone is
>         to read it from the |TZ| environment variable.
>
>
>             src/solaris/native/sun/awt/awt_LoadLibrary.c
>
>       * Use the |dladdr| from |porting_aix.{c,h}| on AIX.
>
>
>             src/solaris/native/sun/awt/fontpath.c
>
>       * Changed some macros from |if !defined(__linux__)| to |if
>         defined(__solaris__)| because that's their real meaning.
>       * Add AIX specific fontpath settings and library search paths
>         for |libfontconfig.so|.
>
>
>             src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>
>       * Rename the |MIN| and |MAX| macros to |XSD_MIN| and |XSD_MAX|
>         to avoid name clashes (|MIN| and |MAX| are much too common and
>         thexy are already defined in some AIX system headers).
>
>
>             src/solaris/native/sun/java2d/x11/XRBackendNative.c
>
>       * Handle AIX like Solaris.
>
>
>             src/solaris/native/sun/nio/ch/Net.c
>
>       * Add AIX-specific includes and constant definitions.
>       * On AIX "socket extensions for multicast source filters"
>         support depends on the OS version. Check for this and throw
>         appropriate exceptions if it is requested but not supported.
>         This is needed to pass
>         JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast
>
>
>             src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
>
>       * On AIX |strerror()| is not thread-safe so we have to use
>         |strerror_r()| instead.
>       * On AIX |readdir_r()| returns EBADF (i.e. '9') and sets
>         'result' to NULL for the directory stream end. Otherwise,
>         'errno' will contain the error code.
>       * Handle some AIX corner cases for the results of the
>         |statvfs64()| call.
>       * On AIX |getgrgid_r()| returns ESRCH if group does not exist.
>
>
>             src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>
>       * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX.
>
>
>             test/java/lang/ProcessBuilder/Basic.java
>             test/java/lang/ProcessBuilder/DestroyTest.java
>
>       * Port this test to AIX and make it more robust (i.e. recognize
>         the "C" locale as |isEnglish()|, ignore VM-warnings in the
>         output, make sure the "grandchild" processes created by the
>         test don't run too long (60s vs. 6666s) because in the case of
>         test problems these processes will pollute the process space,
>         make sure the test fails with an error and doesn't hang
>         indefinitley in the case of a problem).
>
>     *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is
>     this intended?
>
>     Well, |_AIX| is defined in some system headers while |AIX| is
>     defined by the build system. This is already used inconsistently
>     (i.e. |__linux__| vs. |LINUX|) and in general I try to be
>     consistent with the style of the file where I the changes are.
>     That said, I changes most of the occurences of |AIX| to |_AIX|.
>
>     *Q (Alan Bateman):* There are a few changes for OS/400 in the
>     patch, are they supposed to be there?
>
>     We currently don't support OS/400 (later renamed into i5/OS and
>     currently called IBM i) in our OpenJDK port but we do support it
>     in our internel, SAP JVM build. We stripped out all the extra
>     OS/400 functionality from the port but in some places where there
>     is common functionality needd by both, AIX and OS/400 the OS/400
>     support may still be visible in the OpenJDK port. I don't think
>     this is a real problem and it helps us to keep our internel
>     sources in sync with the OpenJDK port. That said, I think I've
>     removed all the references to OS/400 now.
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131126/51b1b229/attachment.html>

From Sergey.Bylokhov at oracle.com  Tue Nov 26 22:32:08 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 Nov 2013 02:32:08 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR(L) - 2nd round: 8024854: Basic
 changes and files to build the class library on AIX
In-Reply-To: <CA+3eh10yBOfJg7XAq_+yv3MPQUivBqUvXtsw7CKU9LgW1-c54g@mail.gmail.com>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>	<CA+3eh133mStOUeyoFEdN77MbuVWrMRW9fjs-j9R5RXi6k7Fn5g@mail.gmail.com>	<5294D453.5050402@oracle.com>	<5294EDB7.8020408@oracle.com>
	<CA+3eh10yBOfJg7XAq_+yv3MPQUivBqUvXtsw7CKU9LgW1-c54g@mail.gmail.com>
Message-ID: <52952168.1060704@oracle.com>

HI, Volker.
Thanks for clarification. The fix looks good.

On 11/27/13 12:48 AM, Volker Simonis wrote:
> Hi Sergey,
>
> on AIX, there's already a typedef for "boolean_t" in sys/types.h 
> that's why we have to omit it from ecc_impl.h to avoid compile errors.
>
> The question regarding the copyright headers has been already answered 
> by Iris (thanks Iris).
>
> Thank you and best regards,
> Volker
>
> On Tuesday, November 26, 2013, Sergey Bylokhov wrote:
>
>     On 26.11.2013 21:03, Alan Bateman wrote:
>
>         On 26/11/2013 16:23, Volker Simonis wrote:
>
>             Hi,
>
>             thanks to everybody for the prompt and helpful reviews.
>             Here comes the
>             final webrev which incorporates all the corrections and
>             suggestions from
>             the second review round:
>
>             http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/
>             <http://cr.openjdk.java.net/%7Esimonis/webrevs/8024854.v3/>
>
>             I've successfully build (and run some smoke tests) with
>             these changes on
>             Linux (x86_32, x86_64, ppc64), Solaris/sparcv9,
>             Windows/x86_64, MacOSX and
>             AIX (5.3, 7.1).
>
>         I've skimmed over the last webrev with focus on:
>
>         NetworkingLibraries.gmk where I see this is now fixed for all
>         platforms.
>
>         net_util.* and the platform specific net_util_md.* where I see
>         you've added platformInit so it's much cleaner.
>
>     I have a question about boolean_t in the [1]. Is it correct to
>     skip it in the new block?
>     http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/src/share/native/sun/security/ec/impl/ecc_impl.h.frames.html
>     <http://cr.openjdk.java.net/%7Esimonis/webrevs/8024854.v3/src/share/native/sun/security/ec/impl/ecc_impl.h.frames.html>
>
>     Also I have a question about headers in the added files. Looks
>     like different templates are used:
>
>     + src/solaris/classes/java/lang/UNIXProcess.java.aix
>        2  * Copyright (c) 1995, 2013, Oracle and/or its affiliates.
>     All rights reserved.
>        3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>     + src/aix/porting/porting_aix.h
>        2  * Copyright 2012, 2013 SAP AG. All rights reserved.
>        3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>     + src/aix/native/sun/tools/attach/AixVirtualMachine.c
>        2  * Copyright (c) 2008, 2013, Oracle and/or its affiliates.
>     All rights reserved.
>        3  * Copyright 2013 SAP AG. All rights reserved.
>        4  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>
>     etc..
>
>     Do we have some rules about that?
>
>
>         UnixNativeDispatcher.c where the error translation is now
>         removed (and looks fine).
>
>         So overall it looks good to me and should be pushed to the
>         staging forest once you hear from others that commented
>         previously.
>
>         -Alan
>
>
>
>     -- 
>     Best regards, Sergey.
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20131127/d25d51e6/attachment.html>

From Sergey.Bylokhov at oracle.com  Wed Nov 27 11:12:25 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 Nov 2013 15:12:25 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5293CFBA.6010209@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<5272C1AB.9030202@gmail.com>	<5278D385.2000205@oracle.com>
	<5280FEDA.20202@oracle.com>	<528284FF.3080007@oracle.com>
	<5283A4A4.60007@oracle.com>	<5283D2F9.6010100@oracle.com>
	<528B625D.7060406@oracle.com>	<528BFA66.7040307@oracle.com>
	<528E1591.90309@oracle.com>	<528E3145.1020105@oracle.com>
	<528F37C2.8050907@oracle.com>	<529000B4.6070503@oracle.com>
	<529355F0.4040506@oracle.com> <5293CFBA.6010209@oracle.com>
Message-ID: <5295D399.8050905@oracle.com>

Hello.
Probably we are in a point when it is necessary to stop and move out all 
extensions to the separate bugs.
We should give a time to our sqe to test these changes.
Actually current version looks good to me.

On 26.11.2013 2:31, Jim Graham wrote:
>
>
> On 11/25/13 5:51 AM, Alexander Scherbatiy wrote:
>> On 11/23/2013 5:11 AM, Jim Graham wrote:
>>> Hi Alexander,
>>>
>>> If we are going to be advertising it as something that developers use
>>> in production code then we would need to file this via CCC. With the
>>> current implementation, any user that has their own ImageObservers
>>> must use this API and so it becomes not only public, at a time when
>>> there is a lockdown on new public API in 8.0, but it also means that
>>> we are tied to its implementation and we can't rely on "it was
>>> experimental and so we can change it at any point" - you can't say
>>> that about an API that is necessary to correctly use a touted feature.
>>
>>      This issue has its own history.  It has been already fixed for the
>> JDK 7u for the Java2D demo. It was decided to not bring new API for the
>> HiDPI support in the JDK 7.
>>      It was suggested to using code like below to create a 
>> ScalableImage.
>> ------------------------------
>> /**
>>   * Class that loads and returns images according to
>>   * scale factor of graphic device
>>   *
>>   *  <pre> {@code
>>   *    Image image = new ScalableImage() {
>>   *
>>   *        public Image createScaledImage(float scaleFactor) {
>>   *            return (scaleFactor <= 1) ? loadImage("image.png")
>>   *                : loadImage("image at 2x.png");
>>   *        }
>>   *
>>   *        Image loadImage(String name){
>>   *            // load image
>>   *        }
>>   *    };}</pre>
>>   */
>> ------------------------------
>>
>>   It was based on the display scale factor. The scale factor should be
>> manually retrieved from the Graphics2D and was not a part of the public
>> API:
>>   g2d.drawImage(scalbleImage.getScaledImage(scaleFactor),..).
>>
>>   From that time it was clear that there should be 2 basic operations
>> for the HiDPI images support:
>>    - retrieve an image with necessary resolution
>>    - retrieve images with all resolutions
>>
>>    The second one is useful when it is necessary to create one set of
>> images using the given one (for example, to draw a shape on all images).
>
> For now, these are just ToolkitImages and you can't draw on them, so 
> this is moot for the case of @2x support in getImage().
>
>>    The JDK 7 solution has been revisited for the JDK 8 and the neccesary
>> CCC request 8011059  has been created and approved.
>>
>>    Both the JDK-8011059 issue description and the approved CCC request
>> says:
>>    -----------------------
>>    A user should have a unified way to provide high resolution images
>> that can be drawn on HIDPI displays according to the user provided
>> algorithm.
>>    -----------------------
>
> We've implemented the Hint part of that solution, but the mechanism 
> for creating custom multi-res images was not workable. I no longer sit 
> as the client rep on the CCC or I would have pointed that out, my 
> apologies.
>
>>    The 8011059 fix consists of two parts:
>>    - Provide a way for a custom image creation that holds images with
>> different resolutions
>>    - Load @2x images on Mac OS X
>>
>>    The first one of the fix can be used without the second. it is not
>> difficult to crate just a class which loads @2x images using the given
>> file path/url.
>
> If we support @2x transparently behind the scenes as we are doing now, 
> who is the requester for the way to create a custom set of resolution 
> variants?  I think the most important customer-driven request was to 
> support @2x for the Mac developers, wasn't it?
>
>>    Now it is suggested to implement the given MultiResolutionImage
>> interface  and override two methods:
>>     - Image getResolutionVariant(int width, int height)
>>     - List<Image> getResolutionVariants()
>>
>>     An image with necessary resolution should be drawn automatically in
>> SunGraphics2D.
>>
>>    What we need is to focus on the first part of the fix.
>>    From this point of view it up to the user' code to load all or some
>> resolution variants by MediaTracker and using
>> Component.prepareImage/checkImage methods.
>
> This is all an interesting goal, but I'm not sure it is as high a 
> priority if we support a convention (based on platform conventions) 
> for high resolution variants behind the scenes.  I do agree that we 
> need something like this before too long, but I don't think it was 
> workable to target the getScaledInstance() method as the mechanism to 
> implement it.  That was the only convention that was approved in that 
> CCC request, so a more complete API based on another mechanism is not 
> covered there.
>
> Also, Win8 has its own conventions as well which come into play on the 
> new high resolution Surface tablets and we should consider those to 
> guide the API we develop.
>
> All, in all, though, I think if we get @2x support in with no code 
> changes needed for apps then we have taken care of the primary use 
> case.  We can probably even handle the Win8 conventions behind the 
> scenes in an 8u release...
>
>             ...jim


-- 
Best regards, Sergey.



From andrew.brygin at oracle.com  Wed Nov 27 11:28:04 2013
From: andrew.brygin at oracle.com (andrew.brygin at oracle.com)
Date: Wed, 27 Nov 2013 11:28:04 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 8024767: [TEST] need test to
	cover JDK-7189452
Message-ID: <20131127112832.C0723628A3@hg.openjdk.java.net>

Changeset: 76171168e894
Author:    bae
Date:      2013-11-27 15:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/76171168e894

8024767: [TEST] need test to cover JDK-7189452
Reviewed-by: ceisserer, bae
Contributed-by: alexander.v.stepanov at oracle.com

+ test/java/awt/Graphics2D/DrawString/TextRenderingTest.java



From Sergey.Bylokhov at oracle.com  Wed Nov 27 14:28:38 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 Nov 2013 18:28:38 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <5295D399.8050905@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<5272C1AB.9030202@gmail.com>	<5278D385.2000205@oracle.com>
	<5280FEDA.20202@oracle.com>	<528284FF.3080007@oracle.com>
	<5283A4A4.60007@oracle.com>	<5283D2F9.6010100@oracle.com>
	<528B625D.7060406@oracle.com>	<528BFA66.7040307@oracle.com>
	<528E1591.90309@oracle.com>	<528E3145.1020105@oracle.com>
	<528F37C2.8050907@oracle.com>	<529000B4.6070503@oracle.com>
	<529355F0.4040506@oracle.com> <5293CFBA.6010209@oracle.com>
	<5295D399.8050905@oracle.com>
Message-ID: <52960196.4090805@oracle.com>

On 27.11.2013 15:12, Sergey Bylokhov wrote:
> Hello.
> Probably we are in a point when it is necessary to stop and move out 
> all extensions to the separate bugs.
> We should give a time to our sqe to test these changes.
> Actually current version looks good to me.
Small additional notes, It would be good:
  - to wrap initial observer in the drawImage and replace img/x,y,.... 
in the observer.
  - don't draw hidpi image, if it was loaded with errors.
  - sun.com package should be used?
  - If MediaTracker was requested to load MultiResolutionImage,it should 
load all versions?
>
> On 26.11.2013 2:31, Jim Graham wrote:
>>
>>
>> On 11/25/13 5:51 AM, Alexander Scherbatiy wrote:
>>> On 11/23/2013 5:11 AM, Jim Graham wrote:
>>>> Hi Alexander,
>>>>
>>>> If we are going to be advertising it as something that developers use
>>>> in production code then we would need to file this via CCC. With the
>>>> current implementation, any user that has their own ImageObservers
>>>> must use this API and so it becomes not only public, at a time when
>>>> there is a lockdown on new public API in 8.0, but it also means that
>>>> we are tied to its implementation and we can't rely on "it was
>>>> experimental and so we can change it at any point" - you can't say
>>>> that about an API that is necessary to correctly use a touted feature.
>>>
>>>      This issue has its own history.  It has been already fixed for the
>>> JDK 7u for the Java2D demo. It was decided to not bring new API for the
>>> HiDPI support in the JDK 7.
>>>      It was suggested to using code like below to create a 
>>> ScalableImage.
>>> ------------------------------
>>> /**
>>>   * Class that loads and returns images according to
>>>   * scale factor of graphic device
>>>   *
>>>   *  <pre> {@code
>>>   *    Image image = new ScalableImage() {
>>>   *
>>>   *        public Image createScaledImage(float scaleFactor) {
>>>   *            return (scaleFactor <= 1) ? loadImage("image.png")
>>>   *                : loadImage("image at 2x.png");
>>>   *        }
>>>   *
>>>   *        Image loadImage(String name){
>>>   *            // load image
>>>   *        }
>>>   *    };}</pre>
>>>   */
>>> ------------------------------
>>>
>>>   It was based on the display scale factor. The scale factor should be
>>> manually retrieved from the Graphics2D and was not a part of the public
>>> API:
>>>   g2d.drawImage(scalbleImage.getScaledImage(scaleFactor),..).
>>>
>>>   From that time it was clear that there should be 2 basic operations
>>> for the HiDPI images support:
>>>    - retrieve an image with necessary resolution
>>>    - retrieve images with all resolutions
>>>
>>>    The second one is useful when it is necessary to create one set of
>>> images using the given one (for example, to draw a shape on all 
>>> images).
>>
>> For now, these are just ToolkitImages and you can't draw on them, so 
>> this is moot for the case of @2x support in getImage().
>>
>>>    The JDK 7 solution has been revisited for the JDK 8 and the 
>>> neccesary
>>> CCC request 8011059  has been created and approved.
>>>
>>>    Both the JDK-8011059 issue description and the approved CCC request
>>> says:
>>>    -----------------------
>>>    A user should have a unified way to provide high resolution images
>>> that can be drawn on HIDPI displays according to the user provided
>>> algorithm.
>>>    -----------------------
>>
>> We've implemented the Hint part of that solution, but the mechanism 
>> for creating custom multi-res images was not workable. I no longer 
>> sit as the client rep on the CCC or I would have pointed that out, my 
>> apologies.
>>
>>>    The 8011059 fix consists of two parts:
>>>    - Provide a way for a custom image creation that holds images with
>>> different resolutions
>>>    - Load @2x images on Mac OS X
>>>
>>>    The first one of the fix can be used without the second. it is not
>>> difficult to crate just a class which loads @2x images using the given
>>> file path/url.
>>
>> If we support @2x transparently behind the scenes as we are doing 
>> now, who is the requester for the way to create a custom set of 
>> resolution variants?  I think the most important customer-driven 
>> request was to support @2x for the Mac developers, wasn't it?
>>
>>>    Now it is suggested to implement the given MultiResolutionImage
>>> interface  and override two methods:
>>>     - Image getResolutionVariant(int width, int height)
>>>     - List<Image> getResolutionVariants()
>>>
>>>     An image with necessary resolution should be drawn automatically in
>>> SunGraphics2D.
>>>
>>>    What we need is to focus on the first part of the fix.
>>>    From this point of view it up to the user' code to load all or some
>>> resolution variants by MediaTracker and using
>>> Component.prepareImage/checkImage methods.
>>
>> This is all an interesting goal, but I'm not sure it is as high a 
>> priority if we support a convention (based on platform conventions) 
>> for high resolution variants behind the scenes.  I do agree that we 
>> need something like this before too long, but I don't think it was 
>> workable to target the getScaledInstance() method as the mechanism to 
>> implement it.  That was the only convention that was approved in that 
>> CCC request, so a more complete API based on another mechanism is not 
>> covered there.
>>
>> Also, Win8 has its own conventions as well which come into play on 
>> the new high resolution Surface tablets and we should consider those 
>> to guide the API we develop.
>>
>> All, in all, though, I think if we get @2x support in with no code 
>> changes needed for apps then we have taken care of the primary use 
>> case.  We can probably even handle the Win8 conventions behind the 
>> scenes in an 8u release...
>>
>>             ...jim
>
>


-- 
Best regards, Sergey.



From james.graham at oracle.com  Wed Nov 27 23:21:24 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 27 Nov 2013 15:21:24 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <52960196.4090805@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<5272C1AB.9030202@gmail.com>	<5278D385.2000205@oracle.com>
	<5280FEDA.20202@oracle.com>	<528284FF.3080007@oracle.com>
	<5283A4A4.60007@oracle.com>	<5283D2F9.6010100@oracle.com>
	<528B625D.7060406@oracle.com>	<528BFA66.7040307@oracle.com>
	<528E1591.90309@oracle.com>	<528E3145.1020105@oracle.com>
	<528F37C2.8050907@oracle.com>	<529000B4.6070503@oracle.com>
	<529355F0.4040506@oracle.com> <5293CFBA.6010209@oracle.com>
	<5295D399.8050905@oracle.com> <52960196.4090805@oracle.com>
Message-ID: <52967E74.4030205@oracle.com>

The things I was talking about in the quoted email were mostly future 
directions, but I did point out some issues in another email that should 
be addressed before FCS.  In particular:

We do need to get the callbacks working whether they draw hi res or not. 
  I think the current fix delivers no notifications at all because the 
observer is not registered anywhere during the course of a drawImage(). 
  That's a big bug.  I don't think we need to wrap observers to do that, 
there are only a few helper functions that deliver the notifications and 
they can be taught how to translate a resolution variant into the base 
image easily enough.

You point out that there was no error checking for the hidpi image.  I 
agree.  Also, if the base image errors out, should we draw the @2x 
anyway?  Or should that base image be required?  Minimally I think we 
need to not attempt the @2x for FCS if it errored and we can worry about 
how to respond to errors in the base image later.

I think that com.sun would require CCC approval for a new interface and 
the bar is really high for API in 8.0 right now.  Unless a developer 
really needs to use it it might be best to move the API to sun.*.  I 
didn't see any developers clamoring for it in the discussions I read, 
but let me know if I missed something.  If we get automatic use of @2x 
images then I think that satisfies the discussions I saw.

MediaTracker defers to Component.prepareImage() for which variants 
should be loaded.  I think we need to teach prepareImage() to trigger 
the variant appropriate for the screen that the Component is on (perhaps 
the default screen if it isn't displayed yet).

Also, there should probably be some MediaTracker, ImageIcon, and Cursor 
test cases that show that those mechanisms all work on images that have 
@2x variants.  Minimally they shouldn't fail entirely, and very 
desireably they should use the @2x version when appropriate, but that 
could be a follow on bug fix as long as they don't fail for the first fix.

I've included below the quote from my last "review" email about the 
specific issues I found.  The main "blocking" issue right now is that it 
looks to me that no imageUpdate notifications at all happen for a hidpi 
image due to the ImageObserver getting dropped on the floor.  Can we at 
least get imageUpdate() called with the base image, even if the xywh are 
wrong before we push the initial fix?  I hope my info below helps make 
that an easy task.

> If they only ever use the image on a retina display (or some scaled context) then I don't think we ever send any notifications the way the current fix is written.  Also, if you don't send notifications for the scaled variant, but load the original and expect its notifications to suffice, then we have a race condition - if the original variant is fully constructed before the scaled version is done then the final "OK to draw everything" notice would not happen and they'd be left with a partial image.
>
> I think it should be easy to pass along the observer and simply have ImageRep translate the image variant into the base image in its newInfo method (and there are a couple of other locations that imageUpdate is called that could do the same).  All it takes is adding "ToolkitImage.set/getBaseImage()" to ToolkitImage, defaulting to "this", but the Multi-Res image will set the base image on both of its variants to the Multi-Res instance.
>
> Then we get full notices of all resolution variants.
>
> It would be best to scale the xywh supplied there as well.  That should be fairly easy, but if it is a big problem then that is lower priority than getting the "ALLBITS" notification right, as that is the main trigger for so many uses.
>
> (In the future we can add ImageObserver2 (or MultiResObserver?) which has support for receiving notifications of variants without translation.)


			...jim

On 11/27/13 6:28 AM, Sergey Bylokhov wrote:
> On 27.11.2013 15:12, Sergey Bylokhov wrote:
>> Hello.
>> Probably we are in a point when it is necessary to stop and move out
>> all extensions to the separate bugs.
>> We should give a time to our sqe to test these changes.
>> Actually current version looks good to me.
> Small additional notes, It would be good:
>   - to wrap initial observer in the drawImage and replace img/x,y,....
> in the observer.
>   - don't draw hidpi image, if it was loaded with errors.
>   - sun.com package should be used?
>   - If MediaTracker was requested to load MultiResolutionImage,it should
> load all versions?
>>
>> On 26.11.2013 2:31, Jim Graham wrote:
>>>
>>>
>>> On 11/25/13 5:51 AM, Alexander Scherbatiy wrote:
>>>> On 11/23/2013 5:11 AM, Jim Graham wrote:
>>>>> Hi Alexander,
>>>>>
>>>>> If we are going to be advertising it as something that developers use
>>>>> in production code then we would need to file this via CCC. With the
>>>>> current implementation, any user that has their own ImageObservers
>>>>> must use this API and so it becomes not only public, at a time when
>>>>> there is a lockdown on new public API in 8.0, but it also means that
>>>>> we are tied to its implementation and we can't rely on "it was
>>>>> experimental and so we can change it at any point" - you can't say
>>>>> that about an API that is necessary to correctly use a touted feature.
>>>>
>>>>      This issue has its own history.  It has been already fixed for the
>>>> JDK 7u for the Java2D demo. It was decided to not bring new API for the
>>>> HiDPI support in the JDK 7.
>>>>      It was suggested to using code like below to create a
>>>> ScalableImage.
>>>> ------------------------------
>>>> /**
>>>>   * Class that loads and returns images according to
>>>>   * scale factor of graphic device
>>>>   *
>>>>   *  <pre> {@code
>>>>   *    Image image = new ScalableImage() {
>>>>   *
>>>>   *        public Image createScaledImage(float scaleFactor) {
>>>>   *            return (scaleFactor <= 1) ? loadImage("image.png")
>>>>   *                : loadImage("image at 2x.png");
>>>>   *        }
>>>>   *
>>>>   *        Image loadImage(String name){
>>>>   *            // load image
>>>>   *        }
>>>>   *    };}</pre>
>>>>   */
>>>> ------------------------------
>>>>
>>>>   It was based on the display scale factor. The scale factor should be
>>>> manually retrieved from the Graphics2D and was not a part of the public
>>>> API:
>>>>   g2d.drawImage(scalbleImage.getScaledImage(scaleFactor),..).
>>>>
>>>>   From that time it was clear that there should be 2 basic operations
>>>> for the HiDPI images support:
>>>>    - retrieve an image with necessary resolution
>>>>    - retrieve images with all resolutions
>>>>
>>>>    The second one is useful when it is necessary to create one set of
>>>> images using the given one (for example, to draw a shape on all
>>>> images).
>>>
>>> For now, these are just ToolkitImages and you can't draw on them, so
>>> this is moot for the case of @2x support in getImage().
>>>
>>>>    The JDK 7 solution has been revisited for the JDK 8 and the
>>>> neccesary
>>>> CCC request 8011059  has been created and approved.
>>>>
>>>>    Both the JDK-8011059 issue description and the approved CCC request
>>>> says:
>>>>    -----------------------
>>>>    A user should have a unified way to provide high resolution images
>>>> that can be drawn on HIDPI displays according to the user provided
>>>> algorithm.
>>>>    -----------------------
>>>
>>> We've implemented the Hint part of that solution, but the mechanism
>>> for creating custom multi-res images was not workable. I no longer
>>> sit as the client rep on the CCC or I would have pointed that out, my
>>> apologies.
>>>
>>>>    The 8011059 fix consists of two parts:
>>>>    - Provide a way for a custom image creation that holds images with
>>>> different resolutions
>>>>    - Load @2x images on Mac OS X
>>>>
>>>>    The first one of the fix can be used without the second. it is not
>>>> difficult to crate just a class which loads @2x images using the given
>>>> file path/url.
>>>
>>> If we support @2x transparently behind the scenes as we are doing
>>> now, who is the requester for the way to create a custom set of
>>> resolution variants?  I think the most important customer-driven
>>> request was to support @2x for the Mac developers, wasn't it?
>>>
>>>>    Now it is suggested to implement the given MultiResolutionImage
>>>> interface  and override two methods:
>>>>     - Image getResolutionVariant(int width, int height)
>>>>     - List<Image> getResolutionVariants()
>>>>
>>>>     An image with necessary resolution should be drawn automatically in
>>>> SunGraphics2D.
>>>>
>>>>    What we need is to focus on the first part of the fix.
>>>>    From this point of view it up to the user' code to load all or some
>>>> resolution variants by MediaTracker and using
>>>> Component.prepareImage/checkImage methods.
>>>
>>> This is all an interesting goal, but I'm not sure it is as high a
>>> priority if we support a convention (based on platform conventions)
>>> for high resolution variants behind the scenes.  I do agree that we
>>> need something like this before too long, but I don't think it was
>>> workable to target the getScaledInstance() method as the mechanism to
>>> implement it.  That was the only convention that was approved in that
>>> CCC request, so a more complete API based on another mechanism is not
>>> covered there.
>>>
>>> Also, Win8 has its own conventions as well which come into play on
>>> the new high resolution Surface tablets and we should consider those
>>> to guide the API we develop.
>>>
>>> All, in all, though, I think if we get @2x support in with no code
>>> changes needed for apps then we have taken care of the primary use
>>> case.  We can probably even handle the Win8 conventions behind the
>>> scenes in an 8u release...
>>>
>>>             ...jim
>>
>>
>
>


From alexandr.scherbatiy at oracle.com  Thu Nov 28 14:45:45 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 28 Nov 2013 18:45:45 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <52967E74.4030205@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<5272C1AB.9030202@gmail.com>	<5278D385.2000205@oracle.com>
	<5280FEDA.20202@oracle.com>	<528284FF.3080007@oracle.com>
	<5283A4A4.60007@oracle.com>	<5283D2F9.6010100@oracle.com>
	<528B625D.7060406@oracle.com>	<528BFA66.7040307@oracle.com>
	<528E1591.90309@oracle.com>	<528E3145.1020105@oracle.com>
	<528F37C2.8050907@oracle.com>	<529000B4.6070503@oracle.com>
	<529355F0.4040506@oracle.com> <5293CFBA.6010209@oracle.com>
	<5295D399.8050905@oracle.com> <52960196.4090805@oracle.com>
	<52967E74.4030205@oracle.com>
Message-ID: <52975719.4050502@oracle.com>


  Could you review the updated fix:
    http://cr.openjdk.java.net/~alexsch/8011059/webrev.11/

   I have moved new API supporting to the separate issue:
     JDK-8029339 Custom MultiResolution image support on HiDPI displays
       https://bugs.openjdk.java.net/browse/JDK-8029339

    - SunToolkit.checkImage/updateImage are updated to handle 
multi-resolution image
       Both base image and the resolution variant are loaded now. 
However, in future, it would be useful to have an ability to load, for 
example, only @2x image
       if the system has only Retina display on Mac OS X. So there are 
can be problems with backward compatibility.

   - MediaTracker is updated to handle multi-resolution image
      MediaTracker uses notifications both form the 
Toolkit.prepareImage() method and image decoders. So only updating 
Toolkit.prepareImage() is not enough.

   - ImageObserver is wrapped both in drawImage() and 
SunToolkit.prepareImage() methods. Size and coordinates are converted to 
the base image.
     A user can receive several notifications about the complete image 
loading from the original image and from the resolution variant.
     It can breaks his code if the code relies that only one 
notification should be received.

   - Resolution variant is ignored in case of errors in the drawImage()
      It needs to be decided on which step a user should be notified 
that a resolution variant has error or this notification should be just 
ignored.

   - Test is updated

   Icons and CustomCursor issues are handled by 8028212 and 8024926 bugs 
and depend on the current bug implementation.

  Thanks,
  Alexandr.

On 11/28/2013 3:21 AM, Jim Graham wrote:
> The things I was talking about in the quoted email were mostly future 
> directions, but I did point out some issues in another email that 
> should be addressed before FCS.  In particular:
>
> We do need to get the callbacks working whether they draw hi res or 
> not.  I think the current fix delivers no notifications at all because 
> the observer is not registered anywhere during the course of a 
> drawImage().  That's a big bug.  I don't think we need to wrap 
> observers to do that, there are only a few helper functions that 
> deliver the notifications and they can be taught how to translate a 
> resolution variant into the base image easily enough.
>
> You point out that there was no error checking for the hidpi image.  I 
> agree.  Also, if the base image errors out, should we draw the @2x 
> anyway?  Or should that base image be required? Minimally I think we 
> need to not attempt the @2x for FCS if it errored and we can worry 
> about how to respond to errors in the base image later.
>
> I think that com.sun would require CCC approval for a new interface 
> and the bar is really high for API in 8.0 right now. Unless a 
> developer really needs to use it it might be best to move the API to 
> sun.*.  I didn't see any developers clamoring for it in the 
> discussions I read, but let me know if I missed something.  If we get 
> automatic use of @2x images then I think that satisfies the 
> discussions I saw.
>
> MediaTracker defers to Component.prepareImage() for which variants 
> should be loaded.  I think we need to teach prepareImage() to trigger 
> the variant appropriate for the screen that the Component is on 
> (perhaps the default screen if it isn't displayed yet).
>
> Also, there should probably be some MediaTracker, ImageIcon, and 
> Cursor test cases that show that those mechanisms all work on images 
> that have @2x variants.  Minimally they shouldn't fail entirely, and 
> very desireably they should use the @2x version when appropriate, but 
> that could be a follow on bug fix as long as they don't fail for the 
> first fix.
>
> I've included below the quote from my last "review" email about the 
> specific issues I found.  The main "blocking" issue right now is that 
> it looks to me that no imageUpdate notifications at all happen for a 
> hidpi image due to the ImageObserver getting dropped on the floor.  
> Can we at least get imageUpdate() called with the base image, even if 
> the xywh are wrong before we push the initial fix?  I hope my info 
> below helps make that an easy task.
>
>> If they only ever use the image on a retina display (or some scaled 
>> context) then I don't think we ever send any notifications the way 
>> the current fix is written. Also, if you don't send notifications for 
>> the scaled variant, but load the original and expect its 
>> notifications to suffice, then we have a race condition - if the 
>> original variant is fully constructed before the scaled version is 
>> done then the final "OK to draw everything" notice would not happen 
>> and they'd be left with a partial image.
>>
>> I think it should be easy to pass along the observer and simply have 
>> ImageRep translate the image variant into the base image in its 
>> newInfo method (and there are a couple of other locations that 
>> imageUpdate is called that could do the same).  All it takes is 
>> adding "ToolkitImage.set/getBaseImage()" to ToolkitImage, defaulting 
>> to "this", but the Multi-Res image will set the base image on both of 
>> its variants to the Multi-Res instance.
>>
>> Then we get full notices of all resolution variants.
>>
>> It would be best to scale the xywh supplied there as well.  That 
>> should be fairly easy, but if it is a big problem then that is lower 
>> priority than getting the "ALLBITS" notification right, as that is 
>> the main trigger for so many uses.
>>
>> (In the future we can add ImageObserver2 (or MultiResObserver?) which 
>> has support for receiving notifications of variants without 
>> translation.)
>
>
>             ...jim
>
> On 11/27/13 6:28 AM, Sergey Bylokhov wrote:
>> On 27.11.2013 15:12, Sergey Bylokhov wrote:
>>> Hello.
>>> Probably we are in a point when it is necessary to stop and move out
>>> all extensions to the separate bugs.
>>> We should give a time to our sqe to test these changes.
>>> Actually current version looks good to me.
>> Small additional notes, It would be good:
>>   - to wrap initial observer in the drawImage and replace img/x,y,....
>> in the observer.
>>   - don't draw hidpi image, if it was loaded with errors.
>>   - sun.com package should be used?
>>   - If MediaTracker was requested to load MultiResolutionImage,it should
>> load all versions?
>>>
>>> On 26.11.2013 2:31, Jim Graham wrote:
>>>>
>>>>
>>>> On 11/25/13 5:51 AM, Alexander Scherbatiy wrote:
>>>>> On 11/23/2013 5:11 AM, Jim Graham wrote:
>>>>>> Hi Alexander,
>>>>>>
>>>>>> If we are going to be advertising it as something that developers 
>>>>>> use
>>>>>> in production code then we would need to file this via CCC. With the
>>>>>> current implementation, any user that has their own ImageObservers
>>>>>> must use this API and so it becomes not only public, at a time when
>>>>>> there is a lockdown on new public API in 8.0, but it also means that
>>>>>> we are tied to its implementation and we can't rely on "it was
>>>>>> experimental and so we can change it at any point" - you can't say
>>>>>> that about an API that is necessary to correctly use a touted 
>>>>>> feature.
>>>>>
>>>>>      This issue has its own history.  It has been already fixed 
>>>>> for the
>>>>> JDK 7u for the Java2D demo. It was decided to not bring new API 
>>>>> for the
>>>>> HiDPI support in the JDK 7.
>>>>>      It was suggested to using code like below to create a
>>>>> ScalableImage.
>>>>> ------------------------------
>>>>> /**
>>>>>   * Class that loads and returns images according to
>>>>>   * scale factor of graphic device
>>>>>   *
>>>>>   *  <pre> {@code
>>>>>   *    Image image = new ScalableImage() {
>>>>>   *
>>>>>   *        public Image createScaledImage(float scaleFactor) {
>>>>>   *            return (scaleFactor <= 1) ? loadImage("image.png")
>>>>>   *                : loadImage("image at 2x.png");
>>>>>   *        }
>>>>>   *
>>>>>   *        Image loadImage(String name){
>>>>>   *            // load image
>>>>>   *        }
>>>>>   *    };}</pre>
>>>>>   */
>>>>> ------------------------------
>>>>>
>>>>>   It was based on the display scale factor. The scale factor 
>>>>> should be
>>>>> manually retrieved from the Graphics2D and was not a part of the 
>>>>> public
>>>>> API:
>>>>> g2d.drawImage(scalbleImage.getScaledImage(scaleFactor),..).
>>>>>
>>>>>   From that time it was clear that there should be 2 basic operations
>>>>> for the HiDPI images support:
>>>>>    - retrieve an image with necessary resolution
>>>>>    - retrieve images with all resolutions
>>>>>
>>>>>    The second one is useful when it is necessary to create one set of
>>>>> images using the given one (for example, to draw a shape on all
>>>>> images).
>>>>
>>>> For now, these are just ToolkitImages and you can't draw on them, so
>>>> this is moot for the case of @2x support in getImage().
>>>>
>>>>>    The JDK 7 solution has been revisited for the JDK 8 and the
>>>>> neccesary
>>>>> CCC request 8011059  has been created and approved.
>>>>>
>>>>>    Both the JDK-8011059 issue description and the approved CCC 
>>>>> request
>>>>> says:
>>>>>    -----------------------
>>>>>    A user should have a unified way to provide high resolution images
>>>>> that can be drawn on HIDPI displays according to the user provided
>>>>> algorithm.
>>>>>    -----------------------
>>>>
>>>> We've implemented the Hint part of that solution, but the mechanism
>>>> for creating custom multi-res images was not workable. I no longer
>>>> sit as the client rep on the CCC or I would have pointed that out, my
>>>> apologies.
>>>>
>>>>>    The 8011059 fix consists of two parts:
>>>>>    - Provide a way for a custom image creation that holds images with
>>>>> different resolutions
>>>>>    - Load @2x images on Mac OS X
>>>>>
>>>>>    The first one of the fix can be used without the second. it is not
>>>>> difficult to crate just a class which loads @2x images using the 
>>>>> given
>>>>> file path/url.
>>>>
>>>> If we support @2x transparently behind the scenes as we are doing
>>>> now, who is the requester for the way to create a custom set of
>>>> resolution variants?  I think the most important customer-driven
>>>> request was to support @2x for the Mac developers, wasn't it?
>>>>
>>>>>    Now it is suggested to implement the given MultiResolutionImage
>>>>> interface  and override two methods:
>>>>>     - Image getResolutionVariant(int width, int height)
>>>>>     - List<Image> getResolutionVariants()
>>>>>
>>>>>     An image with necessary resolution should be drawn 
>>>>> automatically in
>>>>> SunGraphics2D.
>>>>>
>>>>>    What we need is to focus on the first part of the fix.
>>>>>    From this point of view it up to the user' code to load all or 
>>>>> some
>>>>> resolution variants by MediaTracker and using
>>>>> Component.prepareImage/checkImage methods.
>>>>
>>>> This is all an interesting goal, but I'm not sure it is as high a
>>>> priority if we support a convention (based on platform conventions)
>>>> for high resolution variants behind the scenes.  I do agree that we
>>>> need something like this before too long, but I don't think it was
>>>> workable to target the getScaledInstance() method as the mechanism to
>>>> implement it.  That was the only convention that was approved in that
>>>> CCC request, so a more complete API based on another mechanism is not
>>>> covered there.
>>>>
>>>> Also, Win8 has its own conventions as well which come into play on
>>>> the new high resolution Surface tablets and we should consider those
>>>> to guide the API we develop.
>>>>
>>>> All, in all, though, I think if we get @2x support in with no code
>>>> changes needed for apps then we have taken care of the primary use
>>>> case.  We can probably even handle the Win8 conventions behind the
>>>> scenes in an 8u release...
>>>>
>>>>             ...jim
>>>
>>>
>>
>>



From james.graham at oracle.com  Fri Nov 29 23:27:25 2013
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 29 Nov 2013 15:27:25 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <52975719.4050502@oracle.com>
References: <52664607.2090807@oracle.com>
	<5267EA15.1080103@oracle.com>	<526A6FB7.7000800@oracle.com>
	<526E3D75.5070308@oracle.com>	<526FE63C.1020408@oracle.com>
	<5272C1AB.9030202@gmail.com>	<5278D385.2000205@oracle.com>
	<5280FEDA.20202@oracle.com>	<528284FF.3080007@oracle.com>
	<5283A4A4.60007@oracle.com>	<5283D2F9.6010100@oracle.com>
	<528B625D.7060406@oracle.com>	<528BFA66.7040307@oracle.com>
	<528E1591.90309@oracle.com>	<528E3145.1020105@oracle.com>
	<528F37C2.8050907@oracle.com>	<529000B4.6070503@oracle.com>
	<529355F0.4040506@oracle.com> <5293CFBA.6010209@oracle.com>
	<5295D399.8050905@oracle.com> <52960196.4090805@oracle.com>
	<52967E74.4030205@oracle.com> <52975719.4050502@oracle.com>
Message-ID: <529922DD.7020605@oracle.com>

Hi Alexander,

I suppose the wrapping solution works for ImageObservers, but I think 
the suggestion I gave in recent emails was to simply modify the newInfo 
method (and a couple of other methods) to deliver the same information 
with no caches, no hashmaps/lookups, no wrapping the observer, and no 
wrapping with soft references.  Keep in mind that observers are 
typically references to Component objects so any delay in processing the 
soft references could keep relatively large component hierarchies in 
play (if they are parents).  It should work well for a first draft, though.

Also, why does ObserverCache exist?  Couldn't the cache just be a static 
field on MRToolkitImage?

The current way of baking in the image dimensions assumes that they are 
known.  If the image is loaded asynchronously, then the calls to 
getWidth/Height(null) may return -1 and the cached observer wrapper has 
no way to get them later.  I would think this would fail in the typical 
default scenario where the user gets an image and the first even that 
triggers loading it is to render to the screen which would bake the -1's 
into the observer wrapper in all of those cases.  This should probably 
be addressed sooner rather than later.

If an @2x image gets an error we silently start using just the regular 
version of the image.  In addition MediaTracker should not reflect that 
error in its answers, but I think it currently does since you add it as 
an implicit extra media with the same ID.  I think this is OK for the 
first pass, but we need to track it as an issue.

I saw that you fixed the toolkit versions of check/prepare image. 
Component also has the same operations (via its peers).  The Component 
versions do back off to the toolkit versions, but only if they fail to 
find an actual peer to delegate to.  Note that MediaTracker uses the 
Component versions so it is affected by this, but I don't think it will 
cause functional problems that I can think of.  Eventually we'd want MT 
to only load the version that is appropriate for the indicated Component 
- and at that point then this might be an issue, but I don't think it is 
an issue for this first draft if it tracks both variations.

I think it is OK to send multiple notifications to an observer since 
we've always been loose on the exact sequencing and the operations are 
all asynchronous.  There could potentially be several notifications in 
flight at the time that the observer indicates a lack of interest and 
there is no way to stop them.  This could be considered "another case of 
that".  Eventually we could consider addressing this with a tighter 
integration between the wrapper mechanism and the code that calls 
imageUpdate() and receives the answer that the observer is no longer 
interested, but I think this is all OK for now.

The only thing I think we should worry about now for this first draft is 
the issue of getting the right dimensions for the observer wrappers. 
They need to be more asynchronous about that.  It already has a handle 
on the original image anyway, so I think it just needs to get the 
dimensions from there instead of passing them into the constructor, with 
appropriate checks for -1's...

			...jim

On 11/28/13 6:45 AM, Alexander Scherbatiy wrote:
>
>   Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8011059/webrev.11/
>
>    I have moved new API supporting to the separate issue:
>      JDK-8029339 Custom MultiResolution image support on HiDPI displays
>        https://bugs.openjdk.java.net/browse/JDK-8029339
>
>     - SunToolkit.checkImage/updateImage are updated to handle
> multi-resolution image
>        Both base image and the resolution variant are loaded now.
> However, in future, it would be useful to have an ability to load, for
> example, only @2x image
>        if the system has only Retina display on Mac OS X. So there are
> can be problems with backward compatibility.
>
>    - MediaTracker is updated to handle multi-resolution image
>       MediaTracker uses notifications both form the
> Toolkit.prepareImage() method and image decoders. So only updating
> Toolkit.prepareImage() is not enough.
>
>    - ImageObserver is wrapped both in drawImage() and
> SunToolkit.prepareImage() methods. Size and coordinates are converted to
> the base image.
>      A user can receive several notifications about the complete image
> loading from the original image and from the resolution variant.
>      It can breaks his code if the code relies that only one
> notification should be received.
>
>    - Resolution variant is ignored in case of errors in the drawImage()
>       It needs to be decided on which step a user should be notified
> that a resolution variant has error or this notification should be just
> ignored.
>
>    - Test is updated
>
>    Icons and CustomCursor issues are handled by 8028212 and 8024926 bugs
> and depend on the current bug implementation.
>
>   Thanks,
>   Alexandr.
>
> On 11/28/2013 3:21 AM, Jim Graham wrote:
>> The things I was talking about in the quoted email were mostly future
>> directions, but I did point out some issues in another email that
>> should be addressed before FCS.  In particular:
>>
>> We do need to get the callbacks working whether they draw hi res or
>> not.  I think the current fix delivers no notifications at all because
>> the observer is not registered anywhere during the course of a
>> drawImage().  That's a big bug.  I don't think we need to wrap
>> observers to do that, there are only a few helper functions that
>> deliver the notifications and they can be taught how to translate a
>> resolution variant into the base image easily enough.
>>
>> You point out that there was no error checking for the hidpi image.  I
>> agree.  Also, if the base image errors out, should we draw the @2x
>> anyway?  Or should that base image be required? Minimally I think we
>> need to not attempt the @2x for FCS if it errored and we can worry
>> about how to respond to errors in the base image later.
>>
>> I think that com.sun would require CCC approval for a new interface
>> and the bar is really high for API in 8.0 right now. Unless a
>> developer really needs to use it it might be best to move the API to
>> sun.*.  I didn't see any developers clamoring for it in the
>> discussions I read, but let me know if I missed something.  If we get
>> automatic use of @2x images then I think that satisfies the
>> discussions I saw.
>>
>> MediaTracker defers to Component.prepareImage() for which variants
>> should be loaded.  I think we need to teach prepareImage() to trigger
>> the variant appropriate for the screen that the Component is on
>> (perhaps the default screen if it isn't displayed yet).
>>
>> Also, there should probably be some MediaTracker, ImageIcon, and
>> Cursor test cases that show that those mechanisms all work on images
>> that have @2x variants.  Minimally they shouldn't fail entirely, and
>> very desireably they should use the @2x version when appropriate, but
>> that could be a follow on bug fix as long as they don't fail for the
>> first fix.
>>
>> I've included below the quote from my last "review" email about the
>> specific issues I found.  The main "blocking" issue right now is that
>> it looks to me that no imageUpdate notifications at all happen for a
>> hidpi image due to the ImageObserver getting dropped on the floor. Can
>> we at least get imageUpdate() called with the base image, even if the
>> xywh are wrong before we push the initial fix?  I hope my info below
>> helps make that an easy task.
>>
>>> If they only ever use the image on a retina display (or some scaled
>>> context) then I don't think we ever send any notifications the way
>>> the current fix is written. Also, if you don't send notifications for
>>> the scaled variant, but load the original and expect its
>>> notifications to suffice, then we have a race condition - if the
>>> original variant is fully constructed before the scaled version is
>>> done then the final "OK to draw everything" notice would not happen
>>> and they'd be left with a partial image.
>>>
>>> I think it should be easy to pass along the observer and simply have
>>> ImageRep translate the image variant into the base image in its
>>> newInfo method (and there are a couple of other locations that
>>> imageUpdate is called that could do the same).  All it takes is
>>> adding "ToolkitImage.set/getBaseImage()" to ToolkitImage, defaulting
>>> to "this", but the Multi-Res image will set the base image on both of
>>> its variants to the Multi-Res instance.
>>>
>>> Then we get full notices of all resolution variants.
>>>
>>> It would be best to scale the xywh supplied there as well.  That
>>> should be fairly easy, but if it is a big problem then that is lower
>>> priority than getting the "ALLBITS" notification right, as that is
>>> the main trigger for so many uses.
>>>
>>> (In the future we can add ImageObserver2 (or MultiResObserver?) which
>>> has support for receiving notifications of variants without
>>> translation.)
>>
>>
>>             ...jim
>>
>> On 11/27/13 6:28 AM, Sergey Bylokhov wrote:
>>> On 27.11.2013 15:12, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Probably we are in a point when it is necessary to stop and move out
>>>> all extensions to the separate bugs.
>>>> We should give a time to our sqe to test these changes.
>>>> Actually current version looks good to me.
>>> Small additional notes, It would be good:
>>>   - to wrap initial observer in the drawImage and replace img/x,y,....
>>> in the observer.
>>>   - don't draw hidpi image, if it was loaded with errors.
>>>   - sun.com package should be used?
>>>   - If MediaTracker was requested to load MultiResolutionImage,it should
>>> load all versions?
>>>>
>>>> On 26.11.2013 2:31, Jim Graham wrote:
>>>>>
>>>>>
>>>>> On 11/25/13 5:51 AM, Alexander Scherbatiy wrote:
>>>>>> On 11/23/2013 5:11 AM, Jim Graham wrote:
>>>>>>> Hi Alexander,
>>>>>>>
>>>>>>> If we are going to be advertising it as something that developers
>>>>>>> use
>>>>>>> in production code then we would need to file this via CCC. With the
>>>>>>> current implementation, any user that has their own ImageObservers
>>>>>>> must use this API and so it becomes not only public, at a time when
>>>>>>> there is a lockdown on new public API in 8.0, but it also means that
>>>>>>> we are tied to its implementation and we can't rely on "it was
>>>>>>> experimental and so we can change it at any point" - you can't say
>>>>>>> that about an API that is necessary to correctly use a touted
>>>>>>> feature.
>>>>>>
>>>>>>      This issue has its own history.  It has been already fixed
>>>>>> for the
>>>>>> JDK 7u for the Java2D demo. It was decided to not bring new API
>>>>>> for the
>>>>>> HiDPI support in the JDK 7.
>>>>>>      It was suggested to using code like below to create a
>>>>>> ScalableImage.
>>>>>> ------------------------------
>>>>>> /**
>>>>>>   * Class that loads and returns images according to
>>>>>>   * scale factor of graphic device
>>>>>>   *
>>>>>>   *  <pre> {@code
>>>>>>   *    Image image = new ScalableImage() {
>>>>>>   *
>>>>>>   *        public Image createScaledImage(float scaleFactor) {
>>>>>>   *            return (scaleFactor <= 1) ? loadImage("image.png")
>>>>>>   *                : loadImage("image at 2x.png");
>>>>>>   *        }
>>>>>>   *
>>>>>>   *        Image loadImage(String name){
>>>>>>   *            // load image
>>>>>>   *        }
>>>>>>   *    };}</pre>
>>>>>>   */
>>>>>> ------------------------------
>>>>>>
>>>>>>   It was based on the display scale factor. The scale factor
>>>>>> should be
>>>>>> manually retrieved from the Graphics2D and was not a part of the
>>>>>> public
>>>>>> API:
>>>>>> g2d.drawImage(scalbleImage.getScaledImage(scaleFactor),..).
>>>>>>
>>>>>>   From that time it was clear that there should be 2 basic operations
>>>>>> for the HiDPI images support:
>>>>>>    - retrieve an image with necessary resolution
>>>>>>    - retrieve images with all resolutions
>>>>>>
>>>>>>    The second one is useful when it is necessary to create one set of
>>>>>> images using the given one (for example, to draw a shape on all
>>>>>> images).
>>>>>
>>>>> For now, these are just ToolkitImages and you can't draw on them, so
>>>>> this is moot for the case of @2x support in getImage().
>>>>>
>>>>>>    The JDK 7 solution has been revisited for the JDK 8 and the
>>>>>> neccesary
>>>>>> CCC request 8011059  has been created and approved.
>>>>>>
>>>>>>    Both the JDK-8011059 issue description and the approved CCC
>>>>>> request
>>>>>> says:
>>>>>>    -----------------------
>>>>>>    A user should have a unified way to provide high resolution images
>>>>>> that can be drawn on HIDPI displays according to the user provided
>>>>>> algorithm.
>>>>>>    -----------------------
>>>>>
>>>>> We've implemented the Hint part of that solution, but the mechanism
>>>>> for creating custom multi-res images was not workable. I no longer
>>>>> sit as the client rep on the CCC or I would have pointed that out, my
>>>>> apologies.
>>>>>
>>>>>>    The 8011059 fix consists of two parts:
>>>>>>    - Provide a way for a custom image creation that holds images with
>>>>>> different resolutions
>>>>>>    - Load @2x images on Mac OS X
>>>>>>
>>>>>>    The first one of the fix can be used without the second. it is not
>>>>>> difficult to crate just a class which loads @2x images using the
>>>>>> given
>>>>>> file path/url.
>>>>>
>>>>> If we support @2x transparently behind the scenes as we are doing
>>>>> now, who is the requester for the way to create a custom set of
>>>>> resolution variants?  I think the most important customer-driven
>>>>> request was to support @2x for the Mac developers, wasn't it?
>>>>>
>>>>>>    Now it is suggested to implement the given MultiResolutionImage
>>>>>> interface  and override two methods:
>>>>>>     - Image getResolutionVariant(int width, int height)
>>>>>>     - List<Image> getResolutionVariants()
>>>>>>
>>>>>>     An image with necessary resolution should be drawn
>>>>>> automatically in
>>>>>> SunGraphics2D.
>>>>>>
>>>>>>    What we need is to focus on the first part of the fix.
>>>>>>    From this point of view it up to the user' code to load all or
>>>>>> some
>>>>>> resolution variants by MediaTracker and using
>>>>>> Component.prepareImage/checkImage methods.
>>>>>
>>>>> This is all an interesting goal, but I'm not sure it is as high a
>>>>> priority if we support a convention (based on platform conventions)
>>>>> for high resolution variants behind the scenes.  I do agree that we
>>>>> need something like this before too long, but I don't think it was
>>>>> workable to target the getScaledInstance() method as the mechanism to
>>>>> implement it.  That was the only convention that was approved in that
>>>>> CCC request, so a more complete API based on another mechanism is not
>>>>> covered there.
>>>>>
>>>>> Also, Win8 has its own conventions as well which come into play on
>>>>> the new high resolution Surface tablets and we should consider those
>>>>> to guide the API we develop.
>>>>>
>>>>> All, in all, though, I think if we get @2x support in with no code
>>>>> changes needed for apps then we have taken care of the primary use
>>>>> case.  We can probably even handle the Win8 conventions behind the
>>>>> scenes in an 8u release...
>>>>>
>>>>>             ...jim
>>>>
>>>>
>>>
>>>
>