From artem.ananiev at oracle.com  Mon Dec  2 00:19:20 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 02 Dec 2013 12:19:20 +0400
Subject: <AWT Dev> [8] Review request for 8025775: JNI warnings in
	TryXShmAttach
In-Reply-To: <5299117B.8080604@oracle.com>
References: <5299117B.8080604@oracle.com>
Message-ID: <529C4288.80904@oracle.com>

Hi, Anton,

the fix looks fine in general. A few minor comments:

1. xerror_code is not used now and can be removed. XERROR_SAVE seems to 
be unused as well.

2. current_native_xerror_handler can be declared as "extern" in 
awt_util.h, so you don't need to declare it in every file where it's 
used (e.g. in XlibWrapper.c)

Thanks,

Artem

On 11/30/2013 2:13 AM, Anton Litvinov wrote:
> Hello,
>
> Could you please review the following fix for the bug, which consists in
> invocation of Java methods from native code via JNI ("TryXShmAttach"
> function in "awt_GraphicsEnv.c" file) after "GetPrimitiveArrayCritical"
> is called ("BufImg_GetRasInfo" function in "BufImgSurfaceData.c" file).
>
> Bug: http://bugs.sun.com/view_bug.do?bug_id=8025775
> Webrev: http://cr.openjdk.java.net/~alitvinov/8025775/jdk8/webrev.00
>
> The solution is based on:
> - Reversion of all XError handling code implemented as "native -> Java"
> calls in the fix for CR 8005607 to its prior state with native error
> handlers.
> - Introduction of a native synthetic error handler
> "awt_util.c::current_native_xerror_handler" set/unset through previously
> known macros in "awt_util.h" file and called from
> "XlibWrapper.c::ToolkitErrorHandler" function before a call to Java
> synthetic error handler.
>
> The fix also changed both returned native error handlers:
> "awt_GraphicsEnv.c::XShmAttachXErrHandler",
> "GLXSurfaceData.c::GLXSD_BadAllocXErrHandler" not to call previous error
> handler and to always return "0" value as a result.
>
> Thank you,
> Anton

From andrei.eremeev at oracle.com  Mon Dec  2 01:45:27 2013
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Mon, 02 Dec 2013 13:45:27 +0400
Subject: <AWT Dev> [8] Review Request: JDK-8023576 Fix for [TEST BUG]
 Compilation fails for
 java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java
Message-ID: <529C56B7.6040006@oracle.com>

Hi, AWT team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8023576
The fix is available at:
http://cr.openjdk.java.net/~yan/8023576/webrev.00/

The problem:

 1. test can not find Util.java during compilation.
 2. jtreg thinks that test failed if System.exit was called.

The fix:

 1. added tags to test's header.
 2. System.exit(0) was removed.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131202/82097a32/attachment.html 

From Sergey.Bylokhov at oracle.com  Mon Dec  2 03:37:53 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 02 Dec 2013 15:37:53 +0400
Subject: <AWT Dev> [8] Review Request: JDK-8023576 Fix for [TEST BUG]
 Compilation fails for
 java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java
In-Reply-To: <529C56B7.6040006@oracle.com>
References: <529C56B7.6040006@oracle.com>
Message-ID: <529C7111.9070104@oracle.com>

On 12/2/13 1:45 PM, andrei.eremeev wrote:
> Hi, AWT team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8023576
> The fix is available at:
> http://cr.openjdk.java.net/~yan/8023576/webrev.00/
Looks like the link is incorrect? There is nothing about a test.
>
> The problem:
>
>  1. test can not find Util.java during compilation.
>  2. jtreg thinks that test failed if System.exit was called.
>
> The fix:
>
>  1. added tags to test's header.
>  2. System.exit(0) was removed.
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131202/e744bf72/attachment.html 

From andrei.eremeev at oracle.com  Mon Dec  2 04:12:38 2013
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Mon, 02 Dec 2013 16:12:38 +0400
Subject: <AWT Dev> [8] Review Request: JDK-8023576 Fix for [TEST BUG]
 Compilation fails for
 java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java
In-Reply-To: <529C7111.9070104@oracle.com>
References: <529C56B7.6040006@oracle.com> <529C7111.9070104@oracle.com>
Message-ID: <529C7936.6040603@oracle.com>

Sorry.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8023576
Fix:
http://cr.openjdk.java.net/~yan/8023576/webrev.00/

Andrei

On 12/02/2013 03:37 PM, Sergey Bylokhov wrote:
> On 12/2/13 1:45 PM, andrei.eremeev wrote:
>> Hi, AWT team.
>>
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8023576
>> The fix is available at:
>> http://cr.openjdk.java.net/~yan/8023576/webrev.00/
> Looks like the link is incorrect? There is nothing about a test.
>>
>> The problem:
>>
>>  1. test can not find Util.java during compilation.
>>  2. jtreg thinks that test failed if System.exit was called.
>>
>> The fix:
>>
>>  1. added tags to test's header.
>>  2. System.exit(0) was removed.
>>
>
>
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131202/2ce363b7/attachment.html 

From alexandr.scherbatiy at oracle.com  Mon Dec  2 04:55:02 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 02 Dec 2013 16:55:02 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529922DD.7020605@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>
	<529922DD.7020605@oracle.com>
Message-ID: <529C8326.7020401@oracle.com>


   Could you review the updated fix:
    http://cr.openjdk.java.net/~alexsch/8011059/webrev.12/
     - Image observers are not cached now for the resolution variants
     - base image width and height are checked in the wrapped image observer

On 11/30/2013 3:27 AM, Jim Graham wrote:
> 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.
     It seems that just updating the newInfo method is not enough.
     The resolution variant can have a reference to the base image. 
Loading the base image it still should compare its result with the 
resolution variant loading.
     So the image loading status is just moved from the SunToolkit to 
the ToolkitImage.
     I think that the current fix for the checkImage/prepareImage in the 
SunToolkit is the simplest  for the current implementation.
     The separate fix for the ToolkitImage/ImageRepresentation can get 
all things right.
>
> Also, why does ObserverCache exist?  Couldn't the cache just be a 
> static field on MRToolkitImage?
      MRToolkitImage can be used in drawImage(Image,..,ImageObserver) 
method always with null observer. So the is no need to create the 
observer cache or use a synchronization during the cache initialization.

>
> 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.
     I added the base image width/height check to the observer wrapper. 
However, there is no way to rescale image representation width and 
height in case if the base image width and height are not known.

>
> 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 checked all peers like W/LW/XComponentPeer and toolkits.  They all 
delegate check/prepareImage calls to the default toolkit.

    Thanks,
    Alexandr.

> 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
>>>>>
>>>>>
>>>>
>>>>
>>


From anthony.petrov at oracle.com  Mon Dec  2 05:27:00 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 02 Dec 2013 17:27:00 +0400
Subject: <AWT Dev> [8] Review Request: JDK-8023576 Fix for [TEST BUG]
 Compilation fails for
 java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java
In-Reply-To: <529C7936.6040603@oracle.com>
References: <529C56B7.6040006@oracle.com> <529C7111.9070104@oracle.com>
	<529C7936.6040603@oracle.com>
Message-ID: <529C8AA4.4090108@oracle.com>

Hi Andrei,

The fix looks fine to me.

--
best regards,
Anthony

On 12/02/2013 04:12 PM, andrei.eremeev wrote:
> Sorry.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8023576
> Fix:
> http://cr.openjdk.java.net/~yan/8023576/webrev.00/
>
> Andrei
>
> On 12/02/2013 03:37 PM, Sergey Bylokhov wrote:
>> On 12/2/13 1:45 PM, andrei.eremeev wrote:
>>> Hi, AWT team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8023576
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~yan/8023576/webrev.00/
>> Looks like the link is incorrect? There is nothing about a test.
>>>
>>> The problem:
>>>
>>>  1. test can not find Util.java during compilation.
>>>  2. jtreg thinks that test failed if System.exit was called.
>>>
>>> The fix:
>>>
>>>  1. added tags to test's header.
>>>  2. System.exit(0) was removed.
>>>
>>
>>
>> --
>> Best regards, Sergey.
>

From anthony.petrov at oracle.com  Mon Dec  2 05:51:49 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 02 Dec 2013 17:51:49 +0400
Subject: <AWT Dev> [8] Review request for 8025775: JNI warnings in
	TryXShmAttach
In-Reply-To: <5299117B.8080604@oracle.com>
References: <5299117B.8080604@oracle.com>
Message-ID: <529C9075.1050000@oracle.com>

Hi Anton,

The fix looks good to me.

--
best regards,
Anthony

On 11/30/2013 02:13 AM, Anton Litvinov wrote:
> Hello,
>
> Could you please review the following fix for the bug, which consists in
> invocation of Java methods from native code via JNI ("TryXShmAttach"
> function in "awt_GraphicsEnv.c" file) after "GetPrimitiveArrayCritical"
> is called ("BufImg_GetRasInfo" function in "BufImgSurfaceData.c" file).
>
> Bug: http://bugs.sun.com/view_bug.do?bug_id=8025775
> Webrev: http://cr.openjdk.java.net/~alitvinov/8025775/jdk8/webrev.00
>
> The solution is based on:
> - Reversion of all XError handling code implemented as "native -> Java"
> calls in the fix for CR 8005607 to its prior state with native error
> handlers.
> - Introduction of a native synthetic error handler
> "awt_util.c::current_native_xerror_handler" set/unset through previously
> known macros in "awt_util.h" file and called from
> "XlibWrapper.c::ToolkitErrorHandler" function before a call to Java
> synthetic error handler.
>
> The fix also changed both returned native error handlers:
> "awt_GraphicsEnv.c::XShmAttachXErrHandler",
> "GLXSurfaceData.c::GLXSD_BadAllocXErrHandler" not to call previous error
> handler and to always return "0" value as a result.
>
> Thank you,
> Anton

From Sergey.Bylokhov at oracle.com  Mon Dec  2 06:02:27 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 02 Dec 2013 18:02:27 +0400
Subject: <AWT Dev> [8] Review Request: JDK-8023576 Fix for [TEST BUG]
 Compilation fails for
 java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java
In-Reply-To: <529C7936.6040603@oracle.com>
References: <529C56B7.6040006@oracle.com> <529C7111.9070104@oracle.com>
	<529C7936.6040603@oracle.com>
Message-ID: <529C92F3.9090402@oracle.com>

Hi, Andrei.
The fix looks good.

On 12/2/13 4:12 PM, andrei.eremeev wrote:
> Sorry.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8023576
> Fix:
> http://cr.openjdk.java.net/~yan/8023576/webrev.00/
>
> Andrei
>
> On 12/02/2013 03:37 PM, Sergey Bylokhov wrote:
>> On 12/2/13 1:45 PM, andrei.eremeev wrote:
>>> Hi, AWT team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8023576
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~yan/8023576/webrev.00/
>> Looks like the link is incorrect? There is nothing about a test.
>>>
>>> The problem:
>>>
>>>  1. test can not find Util.java during compilation.
>>>  2. jtreg thinks that test failed if System.exit was called.
>>>
>>> The fix:
>>>
>>>  1. added tags to test's header.
>>>  2. System.exit(0) was removed.
>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131202/05647da2/attachment.html 

From anton.litvinov at oracle.com  Mon Dec  2 06:52:05 2013
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Mon, 02 Dec 2013 18:52:05 +0400
Subject: <AWT Dev> [8] Review request for 8025775: JNI warnings in
	TryXShmAttach
In-Reply-To: <529C4288.80904@oracle.com>
References: <5299117B.8080604@oracle.com> <529C4288.80904@oracle.com>
Message-ID: <529C9E95.8050102@oracle.com>

Hello Artem,

Thank you for review of this fix. Could you please review the second 
version of the fix, which should follow your remarks.

Webrev: http://cr.openjdk.java.net/~alitvinov/8025775/jdk8/webrev.01

Differences between this version of the fix and the previous version are 
following:

1.  The unused variable "xerror_code" was removed from "awt_util.h", 
"awt_util.c" files.
2.  The unused macro "XERROR_SAVE" was removed from "awt_util.h" file.
3.  Declaration of the external variable "current_native_xerror_handler" 
was removed from "XlibWrapper.c" file, however the next line was added 
to "XlibWrapper.c" file to be able to compile JDK.

     44 #include <awt_util.h>

4.  In the file "XlibWrapper.c" the comment was changed from

     1270     // Pass the event to a native synthetic error handler first.
to
     1270     // First call the native synthetic error handler declared 
in "awt_util.h" file.

Thank you,
Anton

On 12/2/2013 12:19 PM, Artem Ananiev wrote:
> Hi, Anton,
>
> the fix looks fine in general. A few minor comments:
>
> 1. xerror_code is not used now and can be removed. XERROR_SAVE seems 
> to be unused as well.
>
> 2. current_native_xerror_handler can be declared as "extern" in 
> awt_util.h, so you don't need to declare it in every file where it's 
> used (e.g. in XlibWrapper.c)
>
> Thanks,
>
> Artem
>
> On 11/30/2013 2:13 AM, Anton Litvinov wrote:
>> Hello,
>>
>> Could you please review the following fix for the bug, which consists in
>> invocation of Java methods from native code via JNI ("TryXShmAttach"
>> function in "awt_GraphicsEnv.c" file) after "GetPrimitiveArrayCritical"
>> is called ("BufImg_GetRasInfo" function in "BufImgSurfaceData.c" file).
>>
>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8025775
>> Webrev: http://cr.openjdk.java.net/~alitvinov/8025775/jdk8/webrev.00
>>
>> The solution is based on:
>> - Reversion of all XError handling code implemented as "native -> Java"
>> calls in the fix for CR 8005607 to its prior state with native error
>> handlers.
>> - Introduction of a native synthetic error handler
>> "awt_util.c::current_native_xerror_handler" set/unset through previously
>> known macros in "awt_util.h" file and called from
>> "XlibWrapper.c::ToolkitErrorHandler" function before a call to Java
>> synthetic error handler.
>>
>> The fix also changed both returned native error handlers:
>> "awt_GraphicsEnv.c::XShmAttachXErrHandler",
>> "GLXSurfaceData.c::GLXSD_BadAllocXErrHandler" not to call previous error
>> handler and to always return "0" value as a result.
>>
>> Thank you,
>> Anton


From artem.ananiev at oracle.com  Mon Dec  2 06:54:19 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 02 Dec 2013 18:54:19 +0400
Subject: <AWT Dev> [8] Review request for 8025775: JNI warnings in
	TryXShmAttach
In-Reply-To: <529C9E95.8050102@oracle.com>
References: <5299117B.8080604@oracle.com> <529C4288.80904@oracle.com>
	<529C9E95.8050102@oracle.com>
Message-ID: <529C9F1B.5060808@oracle.com>

Hi, Anton,

the new version is fine. Thanks for addressing my comments,

Artem

On 12/2/2013 6:52 PM, Anton Litvinov wrote:
> Hello Artem,
>
> Thank you for review of this fix. Could you please review the second
> version of the fix, which should follow your remarks.
>
> Webrev: http://cr.openjdk.java.net/~alitvinov/8025775/jdk8/webrev.01
>
> Differences between this version of the fix and the previous version are
> following:
>
> 1.  The unused variable "xerror_code" was removed from "awt_util.h",
> "awt_util.c" files.
> 2.  The unused macro "XERROR_SAVE" was removed from "awt_util.h" file.
> 3.  Declaration of the external variable "current_native_xerror_handler"
> was removed from "XlibWrapper.c" file, however the next line was added
> to "XlibWrapper.c" file to be able to compile JDK.
>
>      44 #include <awt_util.h>
>
> 4.  In the file "XlibWrapper.c" the comment was changed from
>
>      1270     // Pass the event to a native synthetic error handler first.
> to
>      1270     // First call the native synthetic error handler declared
> in "awt_util.h" file.
>
> Thank you,
> Anton
>
> On 12/2/2013 12:19 PM, Artem Ananiev wrote:
>> Hi, Anton,
>>
>> the fix looks fine in general. A few minor comments:
>>
>> 1. xerror_code is not used now and can be removed. XERROR_SAVE seems
>> to be unused as well.
>>
>> 2. current_native_xerror_handler can be declared as "extern" in
>> awt_util.h, so you don't need to declare it in every file where it's
>> used (e.g. in XlibWrapper.c)
>>
>> Thanks,
>>
>> Artem
>>
>> On 11/30/2013 2:13 AM, Anton Litvinov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix for the bug, which consists in
>>> invocation of Java methods from native code via JNI ("TryXShmAttach"
>>> function in "awt_GraphicsEnv.c" file) after "GetPrimitiveArrayCritical"
>>> is called ("BufImg_GetRasInfo" function in "BufImgSurfaceData.c" file).
>>>
>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8025775
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8025775/jdk8/webrev.00
>>>
>>> The solution is based on:
>>> - Reversion of all XError handling code implemented as "native -> Java"
>>> calls in the fix for CR 8005607 to its prior state with native error
>>> handlers.
>>> - Introduction of a native synthetic error handler
>>> "awt_util.c::current_native_xerror_handler" set/unset through previously
>>> known macros in "awt_util.h" file and called from
>>> "XlibWrapper.c::ToolkitErrorHandler" function before a call to Java
>>> synthetic error handler.
>>>
>>> The fix also changed both returned native error handlers:
>>> "awt_GraphicsEnv.c::XShmAttachXErrHandler",
>>> "GLXSurfaceData.c::GLXSD_BadAllocXErrHandler" not to call previous error
>>> handler and to always return "0" value as a result.
>>>
>>> Thank you,
>>> Anton
>

From anthony.petrov at oracle.com  Mon Dec  2 08:25:57 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 02 Dec 2013 20:25:57 +0400
Subject: <AWT Dev> [8] Review request for 8025775: JNI warnings in
	TryXShmAttach
In-Reply-To: <529C9F1B.5060808@oracle.com>
References: <5299117B.8080604@oracle.com> <529C4288.80904@oracle.com>
	<529C9E95.8050102@oracle.com> <529C9F1B.5060808@oracle.com>
Message-ID: <529CB495.7010303@oracle.com>

+1

--
best regards,
Anthony

On 12/02/2013 06:54 PM, Artem Ananiev wrote:
> Hi, Anton,
>
> the new version is fine. Thanks for addressing my comments,
>
> Artem
>
> On 12/2/2013 6:52 PM, Anton Litvinov wrote:
>> Hello Artem,
>>
>> Thank you for review of this fix. Could you please review the second
>> version of the fix, which should follow your remarks.
>>
>> Webrev: http://cr.openjdk.java.net/~alitvinov/8025775/jdk8/webrev.01
>>
>> Differences between this version of the fix and the previous version are
>> following:
>>
>> 1.  The unused variable "xerror_code" was removed from "awt_util.h",
>> "awt_util.c" files.
>> 2.  The unused macro "XERROR_SAVE" was removed from "awt_util.h" file.
>> 3.  Declaration of the external variable "current_native_xerror_handler"
>> was removed from "XlibWrapper.c" file, however the next line was added
>> to "XlibWrapper.c" file to be able to compile JDK.
>>
>>      44 #include <awt_util.h>
>>
>> 4.  In the file "XlibWrapper.c" the comment was changed from
>>
>>      1270     // Pass the event to a native synthetic error handler
>> first.
>> to
>>      1270     // First call the native synthetic error handler declared
>> in "awt_util.h" file.
>>
>> Thank you,
>> Anton
>>
>> On 12/2/2013 12:19 PM, Artem Ananiev wrote:
>>> Hi, Anton,
>>>
>>> the fix looks fine in general. A few minor comments:
>>>
>>> 1. xerror_code is not used now and can be removed. XERROR_SAVE seems
>>> to be unused as well.
>>>
>>> 2. current_native_xerror_handler can be declared as "extern" in
>>> awt_util.h, so you don't need to declare it in every file where it's
>>> used (e.g. in XlibWrapper.c)
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>> On 11/30/2013 2:13 AM, Anton Litvinov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix for the bug, which
>>>> consists in
>>>> invocation of Java methods from native code via JNI ("TryXShmAttach"
>>>> function in "awt_GraphicsEnv.c" file) after "GetPrimitiveArrayCritical"
>>>> is called ("BufImg_GetRasInfo" function in "BufImgSurfaceData.c" file).
>>>>
>>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8025775
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8025775/jdk8/webrev.00
>>>>
>>>> The solution is based on:
>>>> - Reversion of all XError handling code implemented as "native -> Java"
>>>> calls in the fix for CR 8005607 to its prior state with native error
>>>> handlers.
>>>> - Introduction of a native synthetic error handler
>>>> "awt_util.c::current_native_xerror_handler" set/unset through
>>>> previously
>>>> known macros in "awt_util.h" file and called from
>>>> "XlibWrapper.c::ToolkitErrorHandler" function before a call to Java
>>>> synthetic error handler.
>>>>
>>>> The fix also changed both returned native error handlers:
>>>> "awt_GraphicsEnv.c::XShmAttachXErrHandler",
>>>> "GLXSurfaceData.c::GLXSD_BadAllocXErrHandler" not to call previous
>>>> error
>>>> handler and to always return "0" value as a result.
>>>>
>>>> Thank you,
>>>> Anton
>>

From Sergey.Bylokhov at oracle.com  Mon Dec  2 08:37:01 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 02 Dec 2013 20:37:01 +0400
Subject: <AWT Dev> [8] Review Request: 8029382 [macosx] Need test for
	JDK-7161437
Message-ID: <529CB72D.4080902@oracle.com>

Hello.
Please review the fix for jdk 8.
The new test is for "apple.awt.fileDialogForDirectories" property, which 
was added in the JDK-7161437

Bug: https://bugs.openjdk.java.net/browse/JDK-8029382
Webrev can be found at: http://cr.openjdk.java.net/~serb/8029382/webrev.00

-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Mon Dec  2 08:41:12 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 02 Dec 2013 20:41:12 +0400
Subject: <AWT Dev> [8] Review Request: 8029382 [macosx] Need test for
	JDK-7161437
In-Reply-To: <529CB72D.4080902@oracle.com>
References: <529CB72D.4080902@oracle.com>
Message-ID: <529CB828.7080904@oracle.com>

Hi Sergey,

The fix looks fine to me.

--
best regards,
Anthony

On 12/02/2013 08:37 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 8.
> The new test is for "apple.awt.fileDialogForDirectories" property, which
> was added in the JDK-7161437
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8029382
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8029382/webrev.00
>

From james.graham at oracle.com  Mon Dec  2 13:16:14 2013
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 02 Dec 2013 13:16:14 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529C8326.7020401@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>
	<529922DD.7020605@oracle.com> <529C8326.7020401@oracle.com>
Message-ID: <529CF89E.80309@oracle.com>

Hi Alexander,

There must have been a miscommunication.  While I think the cache has 
some issues that worry me, it is absolutely needed if you are going to 
wrap the observer.  You can't just delete it and re-wrap the observer on 
every call because that will create a number of problems.  If you are 
going to use a wrapper solution then we will need to live with the 
potential issues of a cache.

Note that the underlying ImageReps store lists of observers to be 
notified.  You will be growing that list every time a call is made on an 
image because each new wrapper looks like a new observer.  For an 
animated GIF the number of drawImage calls and associated wrappers could 
be infinite (since they are never fully loaded).  Also, for each new 
wrapper, an additional callback is performed.  This will drive the 
performance of an animated GIF into the ground after a time when 
thousands of growing callbacks are issued for each frame.

If you are going to use observer wrappers then you must cache the 
wrapper so you reuse the same wrapper on every new call.

On 12/2/13 4:55 AM, Alexander Scherbatiy wrote:
>
>    Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8011059/webrev.12/
>      - Image observers are not cached now for the resolution variants
>      - base image width and height are checked in the wrapped image
> observer
>
> On 11/30/2013 3:27 AM, Jim Graham wrote:
>> 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.
>      It seems that just updating the newInfo method is not enough.

There were 5 or 6 places that called imageUpdate when I did a quick 
search and most of the calls went through newInfo.  They'd all have to 
be updated.  Other than that, I'm not sure why it would not be enough?

>      The resolution variant can have a reference to the base image.
> Loading the base image it still should compare its result with the
> resolution variant loading.
>      So the image loading status is just moved from the SunToolkit to
> the ToolkitImage.

If you are referring to comparing the new and old dimensions then the 
newInfo method would have access to that information if it could ask a 
resolution variant what its base image is.  That should be a very simple 
change to ToolkitImage (add a set/getBaseImage() method).  Then it can 
do the associated comparisons and parameter adjustments right before 
calling back to the observer.

Perhaps I haven't explained my vision of modifying newInfo very well. 
I'll look into sketching it out in another email since I think the 
cache/wrappers are OK for now.

>      I think that the current fix for the checkImage/prepareImage in the
> SunToolkit is the simplest  for the current implementation.
>      The separate fix for the ToolkitImage/ImageRepresentation can get
> all things right.

I didn't really follow you here, but I said above that the cache should 
be fine for now.  The cache is definitely needed if you are wrapping 
observers as I said above in the first couple of paragraphs.

>> Also, why does ObserverCache exist?  Couldn't the cache just be a
>> static field on MRToolkitImage?
>       MRToolkitImage can be used in drawImage(Image,..,ImageObserver)
> method always with null observer. So the is no need to create the
> observer cache or use a synchronization during the cache initialization.

Maybe I'm missing something about your answer here, but I think you may 
have misunderstood my question.  You placed the field that holds the 
reference to the cache inside an inner class.  I didn't see why the 
reference could not be stored in the base class.  Why is there an empty 
inner class to wrap a single field?  In other words, why was this used:

   56
   57     private static class ObserverCache {
   58
   59         static final SoftCache INSTANCE = new SoftCache();
   60     }
   61

Instead of just:

   56
   59     static final SoftCache INSTANCE = new SoftCache();
   61

>> 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.
>      I added the base image width/height check to the observer wrapper.
> However, there is no way to rescale image representation width and
> height in case if the base image width and height are not known.

That is true if we are basing the scaling solely on the difference in 
dimensions.  In the case of @2x we also could assume that the scaling 
would be 2.0.  I'm not sure if that kind of assumption can be made for 
all future resolution variant mechanisms, but I'd imagine that many of 
them come with a standard for determining the scaling of the variants up 
front so that the correct media can be chosen without having to load all 
of it first just to compare dimensions.

If the image dimensions weren't known when your observer was created 
then you never attempt to recover, though.  You should be querying 
"image.getWidth(this)" to try to grab the dimensions on the fly when 
they come in rather than always punting.  In the current case where 
nothing is cached, you end up with multiple wrappers so some of them 
will have been created before the dimensions were known and some will be 
created after the dimensions are known and the multiple callbacks will 
all have conflicting information.  You'll need to go back to a cache and 
that will mean a single wrapper for any given observer and, at that 
point, inserting calls to "image.getWidth(this /* wrapper */)" will be 
needed to make sure you get the proper dimensions at some point.

>> 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 checked all peers like W/LW/XComponentPeer and toolkits.  They all
> delegate check/prepareImage calls to the default toolkit.

Sounds good.  Eventually we might want to have them prepare just the 
default resolution for that particular device if they are already 
associated with a screen, but this should be good to go for now...

The outstanding issues for me are:

- The cache was necessary to eliminate the overhead of duplicated 
wrappers so it should go back (unless you want to investigate an 
alternate solution by modifying all places that call imageUpdate 
instead, which are hopefully few)

- Retrying on the base image dimensions if they weren't known when a 
wrapper was created (or switching to a pre-determined scale derived from 
the resolution mechanism which benefits @2x and keeping the "relative 
dimension" scaling for the general case)

			...jim

>     Thanks,
>     Alexandr.
>
>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>

From roger.riggs at oracle.com  Mon Dec  2 14:53:30 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Mon, 02 Dec 2013 17:53:30 -0500
Subject: <AWT Dev> RFR 8028019 Doclint cleanup of java.awt
In-Reply-To: <5296FF98.30106@oracle.com>
References: <527C11B4.5070707@oracle.com> <527EA573.9060801@oracle.com>
	<5295B93A.5050901@oracle.com> <52961A8C.3040901@oracle.com>
	<5296FF98.30106@oracle.com>
Message-ID: <529D0F6A.2050600@oracle.com>

Hi Yuri,

I updated the webrev to remove conflicts with the changeset in the 2D 
repository.
I will push on Tuesday based on your OK comment unless I hear otherwise.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-lint-awt-8028019/

Thanks, Roger

On 11/28/2013 3:32 AM, Yuri Nesterenko wrote:
>
> On 11/27/2013 08:15 PM, roger riggs wrote:
>> Hi Yuri,
>>
>> I don't see a spacing difference between <br> and no markup.
>> <br> is supposed only to terminate the line, not add any spacing
>> and I did not see any difference in an example I tried.
>> Perhaps you would point me to a specific example.
>
> Uhm, Roger, you are right. In your files that "p" seems to be always
> somewhere before "@see" which is wrapped in "div" by javadoc.
>
> So, the fix is OK with me.
> Please try to avoid merge in 2D code with 4592f0985e78 (in 2D team
> repository since Nov.20, JDK-8025235).
>
>>
>> The formatting should be handled by the stylesheets and adding extra
>> markup to affect the presentation is not the best approach.
> That's always true but we don't control stylelesheets.
>
> Thanks,
> -yan


From edward.burns at oracle.com  Mon Dec  2 15:43:28 2013
From: edward.burns at oracle.com (Edward Burns)
Date: Mon, 2 Dec 2013 15:43:28 -0800
Subject: <AWT Dev> JDK-8028617: Dvorak keyboard mapping not honored when
	ctrl key pressed
Message-ID: <21149.6944.847358.20855@gargle.gargle.HOWL>

Hello AWT dev,

I have a pet issue that prevents me from using NetBeans 7.4+ on Mac OS X
because I use the DVORAK keyboard layout [1].  Basically, when I press
Ctrl-e to go to the end of the line, the system things I'm pressing
Ctrl-d, and deletes a character.  According to this research from Svata
Dedic on the NetBeans team, it's a problem in
KeyEvent.getExtendedKeyCode().

Svata Dedic wrote:

SD> This seems as a defect in JDK/MacOS X, specifically the method
SD> KeyEvent.getExtendedKeyCode() fails to produce the correct key code
SD> (returns VK_UNDEFINED).

SD> The KeyEvent that arrives to the NetBeans for pressing "E" key has
SD> the following properties on both Linux (working) and MacOS X (not
SD> working):

SD> * keyText='E'
SD> * keyChar='.'
SD> * keyCode=69

SD> extendedKeyCode returns 46 on Linux, 0 on MacOS X. 

I'm attempting to build the relevant parts of OpenJDK to attempt to fix
this myself, but I need some help getting started.

Thanks,

Ed

-- 



[1] https://bugs.openjdk.java.net/browse/JDK-8028617


From chris.hegarty at oracle.com  Mon Dec  2 10:23:45 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 2 Dec 2013 18:23:45 +0000
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic
	changes and files to build the class library on AIX
In-Reply-To: <b9383e9c-e0e0-4349-b8f2-4c6a83a13e09@default>
References: <CA+3eh11+1xUpTSmQti0aCWbBtKpW8AJ4n6VV3fk0J4uGc6xBzA@mail.gmail.com>
	<CA+3eh133mStOUeyoFEdN77MbuVWrMRW9fjs-j9R5RXi6k7Fn5g@mail.gmail.com>
	<5294D453.5050402@oracle.com>
	<b9383e9c-e0e0-4349-b8f2-4c6a83a13e09@default>
Message-ID: <B3E2151A-9CAA-41AE-924E-DEB1B1A643C8@oracle.com>


On 26 Nov 2013, at 18:08, Iris Clark wrote:

>> 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.

I'm ok with these changes going into the staging forest as are.

-Chris.

> 
> 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 Sergey.Bylokhov at oracle.com  Tue Dec  3 01:03:28 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 03 Dec 2013 13:03:28 +0400
Subject: <AWT Dev> JDK-8028617: Dvorak keyboard mapping not honored when
 ctrl key pressed
In-Reply-To: <21149.6944.847358.20855@gargle.gargle.HOWL>
References: <21149.6944.847358.20855@gargle.gargle.HOWL>
Message-ID: <529D9E60.90406@oracle.com>

Hello,Edward.
Can you confirm that the problem can be reproduced on jdk 8?
https://jdk8.java.net/download.html

On 03.12.2013 3:43, Edward Burns wrote:
> Hello AWT dev,
>
> I have a pet issue that prevents me from using NetBeans 7.4+ on Mac OS X
> because I use the DVORAK keyboard layout [1].  Basically, when I press
> Ctrl-e to go to the end of the line, the system things I'm pressing
> Ctrl-d, and deletes a character.  According to this research from Svata
> Dedic on the NetBeans team, it's a problem in
> KeyEvent.getExtendedKeyCode().
>
> Svata Dedic wrote:
>
> SD> This seems as a defect in JDK/MacOS X, specifically the method
> SD> KeyEvent.getExtendedKeyCode() fails to produce the correct key code
> SD> (returns VK_UNDEFINED).
>
> SD> The KeyEvent that arrives to the NetBeans for pressing "E" key has
> SD> the following properties on both Linux (working) and MacOS X (not
> SD> working):
>
> SD> * keyText='E'
> SD> * keyChar='.'
> SD> * keyCode=69
>
> SD> extendedKeyCode returns 46 on Linux, 0 on MacOS X.
>
> I'm attempting to build the relevant parts of OpenJDK to attempt to fix
> this myself, but I need some help getting started.
>
> Thanks,
>
> Ed
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Dec  3 01:21:14 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 03 Dec 2013 13:21:14 +0400
Subject: <AWT Dev> [8] Review Request: JDK-8028484 [TEST_BUG][macosx]
 closed/java/awt/MouseInfo/JContainerMousePositionTest fails
In-Reply-To: <7F3A3438-6826-4E0E-AF27-48B94500CC83@oracle.com>
References: <7F3A3438-6826-4E0E-AF27-48B94500CC83@oracle.com>
Message-ID: <529DA28A.5000304@oracle.com>

Hi, Petr.
Some of the swing components are accessed on non EDT.
On 29.11.2013 15:18, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8028484
> The test have been added to open:
> http://cr.openjdk.java.net/~pchelko/8028484/webrev_new/
> Here's a webrev for test changes:
> http://cr.openjdk.java.net/~pchelko/8028484/
>
> The main difference is that robot now has autoDelay and autoWaiForIdle.
>
> Thank you.
> With best regards. Petr.


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Dec  3 01:22:03 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 03 Dec 2013 13:22:03 +0400
Subject: <AWT Dev> [8] Review Request: [TEST_BUG][macosx] Use safari
 browser,
 the ouput contain information that DataFlavor.allHtmlFlavor is not present
 in the system clipboard
In-Reply-To: <E4E6B210-925C-4A45-A172-5C32CAA51B94@oracle.com>
References: <E4E6B210-925C-4A45-A172-5C32CAA51B94@oracle.com>
Message-ID: <529DA2BB.1090303@oracle.com>

Hi, Petr.
The fix looks good.

On 29.11.2013 14:29, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8029251
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/8029251/webrev/
>
> It appears that when you DnD from Safari it does not provide HTML in the clipboard, it converts it to RTF. So the tests instructions are incomplete.
> The test was modified to indicate that Safari should not be used for testing.
>
> With best regards. Petr.


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Tue Dec  3 03:28:23 2013
From: petr.pchelko at oracle.com (petr.pchelko at oracle.com)
Date: Tue, 03 Dec 2013 11:28:23 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 8029251: [TEST_BUG][macosx] Use safari
	browser,
	the ouput contain information that DataFlavor.allHtmlFlavor is
	not	present in the system clipboard
Message-ID: <20131203112836.B6E5F629BB@hg.openjdk.java.net>

Changeset: 776024b3f13d
Author:    pchelko
Date:      2013-12-03 15:31 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/776024b3f13d

8029251: [TEST_BUG][macosx] Use safari browser, the ouput contain information that DataFlavor.allHtmlFlavor is not present in the system clipboard
Reviewed-by: anthony, serb

! test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.java


From yuri.nesterenko at oracle.com  Tue Dec  3 03:20:09 2013
From: yuri.nesterenko at oracle.com (yuri.nesterenko at oracle.com)
Date: Tue, 03 Dec 2013 11:20:09 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 8023576: [TEST BUG] Compilation fails
	for	java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java
Message-ID: <20131203112057.8BBC6629B9@hg.openjdk.java.net>

Changeset: e4bdf647215f
Author:    yan
Date:      2013-12-03 15:18 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e4bdf647215f

8023576: [TEST BUG] Compilation fails for java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java
Reviewed-by: anthony, serb
Contributed-by: Andrei Eremeev <andrei.eremeev at oracle.com>

! test/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java


From alexandr.scherbatiy at oracle.com  Tue Dec  3 03:48:43 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 03 Dec 2013 15:48:43 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529CF89E.80309@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>
	<529922DD.7020605@oracle.com> <529C8326.7020401@oracle.com>
	<529CF89E.80309@oracle.com>
Message-ID: <529DC51B.8090604@oracle.com>


  Hello,

  Could you review the updated fix:
    http://cr.openjdk.java.net/~alexsch/8011059/webrev.13/
   - observer cache is returned back
   - resolution variant x/y/width/height are divided by 2 in the 
observer wrapper

On 12/3/2013 1:16 AM, Jim Graham wrote:
> Hi Alexander,
>
> There must have been a miscommunication.  While I think the cache has 
> some issues that worry me, it is absolutely needed if you are going to 
> wrap the observer.  You can't just delete it and re-wrap the observer 
> on every call because that will create a number of problems.  If you 
> are going to use a wrapper solution then we will need to live with the 
> potential issues of a cache.
>
> Note that the underlying ImageReps store lists of observers to be 
> notified.  You will be growing that list every time a call is made on 
> an image because each new wrapper looks like a new observer. For an 
> animated GIF the number of drawImage calls and associated wrappers 
> could be infinite (since they are never fully loaded). Also, for each 
> new wrapper, an additional callback is performed. This will drive the 
> performance of an animated GIF into the ground after a time when 
> thousands of growing callbacks are issued for each frame.
>
> If you are going to use observer wrappers then you must cache the 
> wrapper so you reuse the same wrapper on every new call.
>
> On 12/2/13 4:55 AM, Alexander Scherbatiy wrote:
>>
>>    Could you review the updated fix:
>>     http://cr.openjdk.java.net/~alexsch/8011059/webrev.12/
>>      - Image observers are not cached now for the resolution variants
>>      - base image width and height are checked in the wrapped image
>> observer
>>
>> On 11/30/2013 3:27 AM, Jim Graham wrote:
>>> 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.
>>      It seems that just updating the newInfo method is not enough.
>
> There were 5 or 6 places that called imageUpdate when I did a quick 
> search and most of the calls went through newInfo.  They'd all have to 
> be updated.  Other than that, I'm not sure why it would not be enough?

   Consider the following scenario. There are image.png and image at 2x.png 
files on the disk.
     Image image1 = Toolkit.getImage("image.png");  // load as 
multi-resolution image
     Image image2 = Toolkit.getImage("image at 2x.png");  // load the image 
from cache
     toolkit.prepareImage(image2,.., imageObserver2);

    The image2 has image1 as the base image so it rescale its 
coordinates/dimension and passes the base instead of self to the 
imageObserver2 which does not look correct.

>
>>      The resolution variant can have a reference to the base image.
>> Loading the base image it still should compare its result with the
>> resolution variant loading.
>>      So the image loading status is just moved from the SunToolkit to
>> the ToolkitImage.
>
> If you are referring to comparing the new and old dimensions then the 
> newInfo method would have access to that information if it could ask a 
> resolution variant what its base image is.  That should be a very 
> simple change to ToolkitImage (add a set/getBaseImage() method).  Then 
> it can do the associated comparisons and parameter adjustments right 
> before calling back to the observer.
>
> Perhaps I haven't explained my vision of modifying newInfo very well. 
> I'll look into sketching it out in another email since I think the 
> cache/wrappers are OK for now.
>
>>      I think that the current fix for the checkImage/prepareImage in the
>> SunToolkit is the simplest  for the current implementation.
>>      The separate fix for the ToolkitImage/ImageRepresentation can get
>> all things right.
>
> I didn't really follow you here, but I said above that the cache 
> should be fine for now.  The cache is definitely needed if you are 
> wrapping observers as I said above in the first couple of paragraphs.
>
>>> Also, why does ObserverCache exist? Couldn't the cache just be a
>>> static field on MRToolkitImage?
>>       MRToolkitImage can be used in drawImage(Image,..,ImageObserver)
>> method always with null observer. So the is no need to create the
>> observer cache or use a synchronization during the cache initialization.
>
> Maybe I'm missing something about your answer here, but I think you 
> may have misunderstood my question.  You placed the field that holds 
> the reference to the cache inside an inner class.  I didn't see why 
> the reference could not be stored in the base class.  Why is there an 
> empty inner class to wrap a single field?  In other words, why was 
> this used:
>
>   56
>   57     private static class ObserverCache {
>   58
>   59         static final SoftCache INSTANCE = new SoftCache();
>   60     }
>   61
>
> Instead of just:
>
>   56
>   59     static final SoftCache INSTANCE = new SoftCache();
>   61

    Just to not create the cache in case if MRToolkitImageis used but 
image observers are always null. See the comment above.

    Thanks,
    Alexandr,.

>
>>> 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.
>>      I added the base image width/height check to the observer wrapper.
>> However, there is no way to rescale image representation width and
>> height in case if the base image width and height are not known.
>
> That is true if we are basing the scaling solely on the difference in 
> dimensions.  In the case of @2x we also could assume that the scaling 
> would be 2.0.  I'm not sure if that kind of assumption can be made for 
> all future resolution variant mechanisms, but I'd imagine that many of 
> them come with a standard for determining the scaling of the variants 
> up front so that the correct media can be chosen without having to 
> load all of it first just to compare dimensions.
>
> If the image dimensions weren't known when your observer was created 
> then you never attempt to recover, though.  You should be querying 
> "image.getWidth(this)" to try to grab the dimensions on the fly when 
> they come in rather than always punting.  In the current case where 
> nothing is cached, you end up with multiple wrappers so some of them 
> will have been created before the dimensions were known and some will 
> be created after the dimensions are known and the multiple callbacks 
> will all have conflicting information.  You'll need to go back to a 
> cache and that will mean a single wrapper for any given observer and, 
> at that point, inserting calls to "image.getWidth(this /* wrapper */)" 
> will be needed to make sure you get the proper dimensions at some point.
>
>>> 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 checked all peers like W/LW/XComponentPeer and toolkits. They all
>> delegate check/prepareImage calls to the default toolkit.
>
> Sounds good.  Eventually we might want to have them prepare just the 
> default resolution for that particular device if they are already 
> associated with a screen, but this should be good to go for now...
>
> The outstanding issues for me are:
>
> - The cache was necessary to eliminate the overhead of duplicated 
> wrappers so it should go back (unless you want to investigate an 
> alternate solution by modifying all places that call imageUpdate 
> instead, which are hopefully few)
>
> - Retrying on the base image dimensions if they weren't known when a 
> wrapper was created (or switching to a pre-determined scale derived 
> from the resolution mechanism which benefits @2x and keeping the 
> "relative dimension" scaling for the general case)
>
>             ...jim
>
>>     Thanks,
>>     Alexandr.
>>
>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>


From petr.pchelko at oracle.com  Tue Dec  3 04:05:41 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 3 Dec 2013 16:05:41 +0400
Subject: <AWT Dev> [8] Review Request: JDK-8028484 [TEST_BUG][macosx]
	closed/java/awt/MouseInfo/JContainerMousePositionTest fails
In-Reply-To: <529DA28A.5000304@oracle.com>
References: <7F3A3438-6826-4E0E-AF27-48B94500CC83@oracle.com>
	<529DA28A.5000304@oracle.com>
Message-ID: <1302C4E3-A47B-4FA3-AF24-CE2DD61224D6@oracle.com>

Hello, Sergey.

Thank you for the review, the new version is available here:
Test diff: http://cr.openjdk.java.net/~pchelko/8028484/webrev_diff/
Open diff: http://cr.openjdk.java.net/~pchelko/8028484/webrev_new.v1/

With best regards. Petr.

On 03.12.2013, at 13:21, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Petr.
> Some of the swing components are accessed on non EDT.
> On 29.11.2013 15:18, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8028484
>> The test have been added to open:
>> http://cr.openjdk.java.net/~pchelko/8028484/webrev_new/
>> Here's a webrev for test changes:
>> http://cr.openjdk.java.net/~pchelko/8028484/
>> 
>> The main difference is that robot now has autoDelay and autoWaiForIdle.
>> 
>> Thank you.
>> With best regards. Petr.
> 
> 
> -- 
> Best regards, Sergey.
> 


From alexander.zvegintsev at oracle.com  Tue Dec  3 06:12:09 2013
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 03 Dec 2013 18:12:09 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029447 [TEST_BUG] AWT toolkit
 initialization fails with UnsatisfiedLinkError on linux x64
Message-ID: <529DE6B9.3060005@oracle.com>

Hello, AWT Team.

Please review the fix
http://cr.openjdk.java.net/~azvegint/jdk/8/8029447/webrev.00/
for the issue
https://bugs.openjdk.java.net/browse/JDK-8029447/

These tests fail due to test execution was performed with 32-bit JDK on a 64-bit Linux,
obviously this 64-bit Linux system doesn't have 32-bit libraries installed. However,
test failure can be avoided by running these tests in headless mode.

-- 
--
Thanks,
Alexander.


From petr.pchelko at oracle.com  Tue Dec  3 06:26:39 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 3 Dec 2013 18:26:39 +0400
Subject: <AWT Dev> <AWT-Dev> [8] Review Request for JDK-7124391
	[TEST_BUG][macosx] MouseEvents are not dispatched when the
	mouse cursor leaves the component
Message-ID: <53EB8527-CB98-4B06-8CAB-1A2AE33C67F3@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-7124391
The fix is available at:
http://cr.openjdk.java.net/~pchelko/7124391/webrev/

The test is being open sourced.

With best regards. Petr.

From anthony.petrov at oracle.com  Tue Dec  3 06:25:28 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 03 Dec 2013 18:25:28 +0400
Subject: <AWT Dev> [8] Review Request: JDK-8028484 [TEST_BUG][macosx]
 closed/java/awt/MouseInfo/JContainerMousePositionTest fails
In-Reply-To: <1302C4E3-A47B-4FA3-AF24-CE2DD61224D6@oracle.com>
References: <7F3A3438-6826-4E0E-AF27-48B94500CC83@oracle.com>
	<529DA28A.5000304@oracle.com>
	<1302C4E3-A47B-4FA3-AF24-CE2DD61224D6@oracle.com>
Message-ID: <529DE9D8.2060804@oracle.com>

Looks good.

--
best regards,
Anthony

On 12/03/2013 04:05 PM, Petr Pchelko wrote:
> Hello, Sergey.
>
> Thank you for the review, the new version is available here:
> Test diff: http://cr.openjdk.java.net/~pchelko/8028484/webrev_diff/
> Open diff: http://cr.openjdk.java.net/~pchelko/8028484/webrev_new.v1/
>
> With best regards. Petr.
>
> On 03.12.2013, at 13:21, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Petr.
>> Some of the swing components are accessed on non EDT.
>> On 29.11.2013 15:18, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8028484
>>> The test have been added to open:
>>> http://cr.openjdk.java.net/~pchelko/8028484/webrev_new/
>>> Here's a webrev for test changes:
>>> http://cr.openjdk.java.net/~pchelko/8028484/
>>>
>>> The main difference is that robot now has autoDelay and autoWaiForIdle.
>>>
>>> Thank you.
>>> With best regards. Petr.
>>
>>
>> --
>> Best regards, Sergey.
>>
>

From Sergey.Bylokhov at oracle.com  Tue Dec  3 06:28:33 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 03 Dec 2013 18:28:33 +0400
Subject: <AWT Dev> <AWT-Dev> [8] Review Request for JDK-7124391
 [TEST_BUG][macosx] MouseEvents are not dispatched when the mouse cursor
 leaves the component
In-Reply-To: <53EB8527-CB98-4B06-8CAB-1A2AE33C67F3@oracle.com>
References: <53EB8527-CB98-4B06-8CAB-1A2AE33C67F3@oracle.com>
Message-ID: <529DEA91.50507@oracle.com>

Hi, Petr.
The fix looks good
On 03.12.2013 18:26, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-7124391
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/7124391/webrev/
>
> The test is being open sourced.
>
> With best regards. Petr.


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Tue Dec  3 06:35:51 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 03 Dec 2013 18:35:51 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029447 [TEST_BUG] AWT
 toolkit initialization fails with UnsatisfiedLinkError on linux x64
In-Reply-To: <529DE6B9.3060005@oracle.com>
References: <529DE6B9.3060005@oracle.com>
Message-ID: <529DEC47.3080305@oracle.com>

Hi Alexander,

On the one hand, I agree that the nature of the tests is headless, and 
thus running them in this mode looks appropriate in general.

On the other hand, I see that the root cause of the tests failure is a 
misconfigured PC on which the tests are being run. This issue can bite 
us (or rather, the tester) later on. Besides, the app-context related 
code may (in theory and/or in the future) behave differently in the 
headfull vs. headless mode, and this latter issue will in fact bite us.

So, if you really-really want to fix this for JDK 8 now, you may 
consider this fix reviewed. However, I'd prefer to fix the PC's 
configuration instead of pushing this patch, or at least file a separate 
issue so that the configuration could be fixed later.

--
best regards,
Anthony

On 12/03/2013 06:12 PM, Alexander Zvegintsev wrote:
> Hello, AWT Team.
>
> Please review the fix
> http://cr.openjdk.java.net/~azvegint/jdk/8/8029447/webrev.00/
> for the issue
> https://bugs.openjdk.java.net/browse/JDK-8029447/
>
> These tests fail due to test execution was performed with 32-bit JDK on
> a 64-bit Linux,
> obviously this 64-bit Linux system doesn't have 32-bit libraries
> installed. However,
> test failure can be avoided by running these tests in headless mode.
>

From anthony.petrov at oracle.com  Tue Dec  3 06:37:44 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 03 Dec 2013 18:37:44 +0400
Subject: <AWT Dev> <AWT-Dev> [8] Review Request for JDK-7124391
 [TEST_BUG][macosx] MouseEvents are not dispatched when the mouse cursor
 leaves the component
In-Reply-To: <529DEA91.50507@oracle.com>
References: <53EB8527-CB98-4B06-8CAB-1A2AE33C67F3@oracle.com>
	<529DEA91.50507@oracle.com>
Message-ID: <529DECB8.1020805@oracle.com>

+1

--
best regards,
Anthony

On 12/03/2013 06:28 PM, Sergey Bylokhov wrote:
> Hi, Petr.
> The fix looks good
> On 03.12.2013 18:26, Petr Pchelko wrote:
>> Hello, AWT Team.
>>
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-7124391
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/7124391/webrev/
>>
>> The test is being open sourced.
>>
>> With best regards. Petr.
>
>

From andrei.eremeev at oracle.com  Tue Dec  3 06:44:16 2013
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Tue, 03 Dec 2013 18:44:16 +0400
Subject: <AWT Dev> Review Request: JDK-7112454 Fix for TEST_BUG:
 java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html
 failed
Message-ID: <529DEE40.8020707@oracle.com>

Hi, AWT team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-7112454

The fix is available at:
http://cr.openjdk.java.net/~yan/7112454/webrev.diff.00/

Test moved to open:
http://cr.openjdk.java.net/~yan/7112454/webrev.00/

From andrei.eremeev at oracle.com  Tue Dec  3 06:46:43 2013
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Tue, 03 Dec 2013 18:46:43 +0400
Subject: <AWT Dev> Review Request: JDK-7175457 Fix for [TEST_BUG]
 closed/java/awt/Window/AlwaysOnTop/TestAlwaysOnTopBeforeShow.java still
 failed
Message-ID: <529DEED3.4090201@oracle.com>

Hi, AWT team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-7175457

The fix is available at:
http://cr.openjdk.java.net/~yan/7175457/webrev.diff.00/

Test moved to open:
http://cr.openjdk.java.net/~yan/7175457/webrev.00/

From edward.burns at oracle.com  Tue Dec  3 06:53:23 2013
From: edward.burns at oracle.com (Edward Burns)
Date: Tue, 3 Dec 2013 06:53:23 -0800
Subject: <AWT Dev> JDK-8028617: Dvorak keyboard mapping not honored when
 ctrl key pressed
In-Reply-To: Re: <AWT Dev> JDK-8028617: Dvorak keyboard mapping not honored
	when ctrl key pressed on 3 December 2013
References: <21149.6944.847358.20855@gargle.gargle.HOWL>
	<529D9E60.90406@oracle.com>
Message-ID: <21149.61539.311000.178302@gargle.gargle.HOWL>

>>>>> On Tue, 03 Dec 2013 13:03:28 +0400, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> said:

SB> Hello,Edward.
SB> Can you confirm that the problem can be reproduced on jdk 8?
SB> https://jdk8.java.net/download.html

I just downloaded "8 Build b118".

Unfortunately, the problem persists.  Pressing Ctrl-e gives me Ctrl-d.

Ed

From alexander.zvegintsev at oracle.com  Tue Dec  3 07:04:15 2013
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 03 Dec 2013 19:04:15 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029447 [TEST_BUG] AWT
 toolkit initialization fails with UnsatisfiedLinkError on linux x64
In-Reply-To: <529DEC47.3080305@oracle.com>
References: <529DE6B9.3060005@oracle.com> <529DEC47.3080305@oracle.com>
Message-ID: <529DF2EF.7090103@oracle.com>

Hi Anthony,

As you can see in this issue history it was resolved as not an issue 
firstly.
I am not a fan this changes too, however, it was supposed by Sergey and
Victor to fix these tests since the fix looks safe for now.
I'd actually prefer to not change these tests too.

Sergey, Victor, what do you think?

--
Thanks,
Alexander.

On 12/03/2013 06:35 PM, Anthony Petrov wrote:
> Hi Alexander,
>
> On the one hand, I agree that the nature of the tests is headless, and 
> thus running them in this mode looks appropriate in general.
>
> On the other hand, I see that the root cause of the tests failure is a 
> misconfigured PC on which the tests are being run. This issue can bite 
> us (or rather, the tester) later on. Besides, the app-context related 
> code may (in theory and/or in the future) behave differently in the 
> headfull vs. headless mode, and this latter issue will in fact bite us.
>
> So, if you really-really want to fix this for JDK 8 now, you may 
> consider this fix reviewed. However, I'd prefer to fix the PC's 
> configuration instead of pushing this patch, or at least file a 
> separate issue so that the configuration could be fixed later.
>
> -- 
> best regards,
> Anthony
>
> On 12/03/2013 06:12 PM, Alexander Zvegintsev wrote:
>> Hello, AWT Team.
>>
>> Please review the fix
>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029447/webrev.00/
>> for the issue
>> https://bugs.openjdk.java.net/browse/JDK-8029447/
>>
>> These tests fail due to test execution was performed with 32-bit JDK on
>> a 64-bit Linux,
>> obviously this 64-bit Linux system doesn't have 32-bit libraries
>> installed. However,
>> test failure can be avoided by running these tests in headless mode.
>>


From petr.pchelko at oracle.com  Tue Dec  3 07:30:23 2013
From: petr.pchelko at oracle.com (petr.pchelko at oracle.com)
Date: Tue, 03 Dec 2013 15:30:23 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 7124391: [TEST_BUG][macosx] MouseEvents
	are not	dispatched when the mouse cursor leaves the component
Message-ID: <20131203153101.034A8629D7@hg.openjdk.java.net>

Changeset: 5774800ba1e9
Author:    pchelko
Date:      2013-12-03 19:33 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5774800ba1e9

7124391: [TEST_BUG][macosx] MouseEvents are not dispatched when the mouse cursor leaves the component
Reviewed-by: anthony, serb

+ test/java/awt/event/MouseEvent/EnterAsGrabbedEvent/EnterAsGrabbedEvent.java


From alexandr.scherbatiy at oracle.com  Tue Dec  3 08:11:39 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 03 Dec 2013 20:11:39 +0400
Subject: <AWT Dev> [8] Review request for 8024926 [macosx] AquaIcon
	HiDPI support
In-Reply-To: <526FE6BB.3010109@oracle.com>
References: <526FE6BB.3010109@oracle.com>
Message-ID: <529E02BB.2020609@oracle.com>


   Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8024926/webrev.01/
   - MultiResolutionImage interface is used from the fix 8011059
   - Only icons with resolution 1x and 2x are created.

     The real Mac OS X system icon have more resolutions.
     The full fix requires retrieving and handling all NSImage 
representations. It can be addressed for the next release.

   Thanks,
   Alexandr.

On 10/29/2013 8:47 PM, Alexander Scherbatiy wrote:
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8024926
>   webrev: http://cr.openjdk.java.net/~alexsch/8024926/webrev.00
>
> The fix returns a high resolution system icon in the overridden 
> getScaledInstance(width, height, hints) method.
>
> The fix relies on the fix for the issue JDK-8011059 [macosx] Make JDK 
> demos look perfect on retina displays:
> http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html
>  - getScaledInstance(width, height, hints) method is used for the 
> image drawing when IMAGE_SCALING hints are enabled
>  - LWCToolkit.ScalableToolkitImage class is public
>
> Thanks,
> Alexandr.
>


From alexandr.scherbatiy at oracle.com  Tue Dec  3 08:32:27 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 03 Dec 2013 20:32:27 +0400
Subject: <AWT Dev> [8] Review request for 8028212 Custom cursor HiDPI support
Message-ID: <529E079B.6050708@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8028212
   webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00

   - MultiResolutionImage interface is used from the fix 8011059
   - NSImage with representations are created for the multi-resolution 
cursor
   - NSImage representations are rescaled to the base cursor size

Thanks,
Alexandr.


From anthony.petrov at oracle.com  Tue Dec  3 08:39:46 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 03 Dec 2013 20:39:46 +0400
Subject: <AWT Dev> [8] Review request for 8024926 [macosx] AquaIcon
	HiDPI support
In-Reply-To: <529E02BB.2020609@oracle.com>
References: <526FE6BB.3010109@oracle.com> <529E02BB.2020609@oracle.com>
Message-ID: <529E0952.6080106@oracle.com>

Hi Alexander,

The Graphics obtained at line 519 in AquaImageFactory.java is never 
dispose()'d.

Other than that, the fix looks good to me (although I'm not an expert in 
Aqua L&F or HiDPI support code).

--
best regards,
Anthony

On 12/03/2013 08:11 PM, Alexander Scherbatiy wrote:
>
>    Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8024926/webrev.01/
>    - MultiResolutionImage interface is used from the fix 8011059
>    - Only icons with resolution 1x and 2x are created.
>
>      The real Mac OS X system icon have more resolutions.
>      The full fix requires retrieving and handling all NSImage
> representations. It can be addressed for the next release.
>
>    Thanks,
>    Alexandr.
>
> On 10/29/2013 8:47 PM, Alexander Scherbatiy wrote:
>> Hello,
>>
>> Could you review the fix:
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8024926
>>   webrev: http://cr.openjdk.java.net/~alexsch/8024926/webrev.00
>>
>> The fix returns a high resolution system icon in the overridden
>> getScaledInstance(width, height, hints) method.
>>
>> The fix relies on the fix for the issue JDK-8011059 [macosx] Make JDK
>> demos look perfect on retina displays:
>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html
>>  - getScaledInstance(width, height, hints) method is used for the
>> image drawing when IMAGE_SCALING hints are enabled
>>  - LWCToolkit.ScalableToolkitImage class is public
>>
>> Thanks,
>> Alexandr.
>>
>

From anthony.petrov at oracle.com  Tue Dec  3 09:06:45 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 03 Dec 2013 21:06:45 +0400
Subject: <AWT Dev> [8] Review request for 8028212 Custom cursor HiDPI
	support
In-Reply-To: <529E079B.6050708@oracle.com>
References: <529E079B.6050708@oracle.com>
Message-ID: <529E0FA5.6090300@oracle.com>

Hi Alexander,

If we go with this fix, I suggest to move the 
CImage.Creator.resizeImageRepresentations() to the CImage class and make 
it a member method, so that you don't need to pass a CImage reference to 
it as an argument.

Also, there's the CImage.resize() method already. Why does it not work 
for us? Having a specification for both methods (or for one, if the 
second is unneeded) might be helpful.

However, I'm not sure if we really want to resize each representation of 
an NSImage object to the same size. Why would we want to do that? In 
fact, one of the representations might already have the correct size, 
and we could use just that whenever we need it w/o wasting resources on 
resizing each of them. If there's no representations of suitable size, 
then we should choose the closest one and resize just it to the desired 
size. Or am I misunderstanding anything?

Also, in CCustomCursor.getImageData(), could we somehow encapsulate a 
part (or all) of the Image vs. MultiResolutionImage logic in the 
CImage.Creator class?

PS. I'm not really an expert in Image handling code. I'd suggest someone 
from the 2D team to review this as well. Maybe Jim could help?

--
best regards,
Anthony

On 12/03/2013 08:32 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>    bug: https://bugs.openjdk.java.net/browse/JDK-8028212
>    webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00
>
>    - MultiResolutionImage interface is used from the fix 8011059
>    - NSImage with representations are created for the multi-resolution
> cursor
>    - NSImage representations are rescaled to the base cursor size
>
> Thanks,
> Alexandr.
>

From james.graham at oracle.com  Tue Dec  3 09:49:13 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 03 Dec 2013 09:49:13 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529DC51B.8090604@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>
	<529922DD.7020605@oracle.com> <529C8326.7020401@oracle.com>
	<529CF89E.80309@oracle.com> <529DC51B.8090604@oracle.com>
Message-ID: <529E1999.5080200@oracle.com>

Hi Alexander,

There is one last thing that I think I forgot to mention in SG2D that 
might make some other comments I made make more sense.  There is no 
observer registered on the resolution variant in SG2D.drawHiDPIImage() 
in the case where the resolution variant hasn't been loaded yet. 
Basically, the lines at 3099,3100 will trigger the variant to load, but 
there is no observer in those calls to trace it back to the guy who 
needs to call drawImage() again.  So, the only thing I think that needs 
to be done is that the observer needs to be wrapped and handed in to 
those calls to getWidth/Height(observer).

The rest of that method looks fine - the regular variant will be used 
(and will trigger repaints via the code that calls into drawImage()) 
until the base image dimensions are known enough to trigger the 
getResolutionVariant() code, and then we might continue to use the 
regular version until the resolution variant at least knows its 
dimensions, and that is all OK, but we need to start using the observer 
wrapper on the resolution variant starting at lines 3099,3100 in order 
to get the repaints to keep happening for that version of the image.

Arguably, in addition, the unwrapped observer probably could be used on 
lines 3089, 3090 when you get the dimensions of the base image, but 
since the base image will later be handed to the drawImage pipeline, the 
observer will be registered there anyway, so that isn't a bug.  But, the 
wrapped observer needs to be used on 3099,3100 or we may never repaint 
with the resolution variant (it will be a race condition based on how 
fast the regular and hiDPI images load).

More comments below, but that is the only remaining blocker that I can 
see...

On 12/3/13 3:48 AM, Alexander Scherbatiy wrote:
> On 12/3/2013 1:16 AM, Jim Graham wrote:
>> On 12/2/13 4:55 AM, Alexander Scherbatiy wrote:
>>> On 11/30/2013 3:27 AM, Jim Graham wrote:
>>>> 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.
>>>      It seems that just updating the newInfo method is not enough.
>>
>> There were 5 or 6 places that called imageUpdate when I did a quick
>> search and most of the calls went through newInfo.  They'd all have to
>> be updated.  Other than that, I'm not sure why it would not be enough?
>
>    Consider the following scenario. There are image.png and image at 2x.png
> files on the disk.
>      Image image1 = Toolkit.getImage("image.png");  // load as
> multi-resolution image
>      Image image2 = Toolkit.getImage("image at 2x.png");  // load the image
> from cache
>      toolkit.prepareImage(image2,.., imageObserver2);
>
>     The image2 has image1 as the base image so it rescale its
> coordinates/dimension and passes the base instead of self to the
> imageObserver2 which does not look correct.

I see your point now.  I had thought that they would be cached 
separately, but I see now that both are inserted into the hash directly. 
  That allows sharing if they access both manually, but it complicates 
the observer issue.  I don't think I would have bothered with sharing 
the Image instance with a manual reference to the @2x in that case, but 
we should be able to handle both in a future bug fix and hopefully also 
get rid of wrappers, but it would take some surgery on the drawImage 
pipeline and the record keeping in the observer lists.  The existing 
solution will work fine for @2x images and allow sharing so it is good 
to go for now (modulo the one issue with using the wrapper for the 
getWidth()/getHeight() I mentioned above).

>>>> Also, why does ObserverCache exist? Couldn't the cache just be a
>>>> static field on MRToolkitImage?
>>>       MRToolkitImage can be used in drawImage(Image,..,ImageObserver)
>>> method always with null observer. So the is no need to create the
>>> observer cache or use a synchronization during the cache initialization.
>>
>> Maybe I'm missing something about your answer here, but I think you
>> may have misunderstood my question.  You placed the field that holds
>> the reference to the cache inside an inner class.  I didn't see why
>> the reference could not be stored in the base class.  Why is there an
>> empty inner class to wrap a single field?  In other words, why was
>> this used:
>>
>>   56
>>   57     private static class ObserverCache {
>>   58
>>   59         static final SoftCache INSTANCE = new SoftCache();
>>   60     }
>>   61
>>
>> Instead of just:
>>
>>   56
>>   59     static final SoftCache INSTANCE = new SoftCache();
>>   61
>
>     Just to not create the cache in case if MRToolkitImageis used but
> image observers are always null. See the comment above.

Ah, so this is just a micro-optimization then?  I'm not sure what you 
mean by "always null".  It depends on whether they hand in an observer, 
doesn't it?  The standard case of drawImage() tends to hand in the 
Component as the observer.  In cases where we know we are using a 
BufferedImage, we often use null, but code that uses a toolkit image (or 
that doesn't know what the image is) should be using a non-null observer 
or it won't paint right the first time when it triggers the image loading.

The cache object itself takes so little room that I don't think it is 
worth worrying about.  If something triggers MRToolkitImage to be 
referenced at all, then the 99% case will likely eventually involve 
drawImage() calls with observer and an empty cache takes so little room 
that it is probably fine to just aggressively create it at that time.

There is no bug or problem here, I just don't think the indirection buys 
us anything worthwhile here...

			...jim

From james.graham at oracle.com  Tue Dec  3 10:10:40 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 03 Dec 2013 10:10:40 -0800
Subject: <AWT Dev> [OpenJDK 2D-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: <529E1EA0.7080209@oracle.com>

Hi Mike,

One more question about @2x handling on MacOS.

Clearly, in the simple case of someone loading an ordinary "foo.png" and 
painting it on a retina display without doing anything special with the 
transform, it will be scaled up by 2x to retain proper size.

Also, clearly, if a "foo at 2x.png" file exists, it will be loaded 
automatically and found to be twice as large and displayed with no 
scaling so that it is the same "size".

But, what if in the first step they manually specified the image file 
name as "foo at 2x.png" (and assuming there is no "foo at 2x@2x.png")?  Will 
it display with its pixels scaled up to double sized because it was the 
direct image that they specified?  Or, does the system recognize that it 
came from a file named @2x and assume that it is a 
double-screen-resolution image and paint it the same way it would have 
done if it was implicitly loaded as the higher resolution variant of 
"foo.png"?

Let me spell out the scenarios:

Scenario 1:
- app is retina-enabled
- app has WxH foo.png media (and no @2x versions)
- app loads image from "foo.png"
- app displays image with standard default scaling on a retina screen
=> result is image takes up 2W x 2H pixels on the retina screen

Scenario 2:
- app is retina-enabled
- app has WxH foo.png media
- app also has 2W x 2H foo at 2x.png media
- app loads image from "foo.png"
- app displays image with standard default scaling on a retina screen
=> result is system also loads foo at 2x.png and displays it with 2W x 2H 
retina pixels on the retina screen - the same physical size as in the 
previous example

Scenario 3:
- app is retina-enabled
- app has WxH foo.png media
- app also has 2W x 2H foo at 2x.png media
- app loads image from "foo at 2x.png" rather than "foo.png"
- app displays image with standard default scaling on a retina screen
=> result is ???
=> I'm guessing that it gets drawn twice the size as Scenario's 1 and 2 
because it is no longer relative to the WxH base image?

Scenario 4:
same as Scenario 3, but foo.png doesn't exist, foo at 2x.png is the only 
version found in the media for the app
=> result is ???
=> I'm guessing the result is the same as Scenario 3

Also, the convention is for the @2x image to be twice the pixel size of 
the regular image, but what if it isn't?  Is it always drawn at a 0.5x 
relative scale because of the implication of the @2x file name, or will 
it be dynamically sized for "basew/@2xw, baseh/@2xh" which just usually 
works out to 0.5x if the author followed conventions?

			...jim

From james.graham at oracle.com  Tue Dec  3 10:16:21 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 03 Dec 2013 10:16:21 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529E1999.5080200@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>
	<529922DD.7020605@oracle.com> <529C8326.7020401@oracle.com>
	<529CF89E.80309@oracle.com> <529DC51B.8090604@oracle.com>
	<529E1999.5080200@oracle.com>
Message-ID: <529E1FF5.10301@oracle.com>

Just to be specific so we don't get bogged down in misunderstandings. 
Here is the modification that I'm suggesting:

3086         } else if (img instanceof MultiResolutionImage) {
3087             // get scaled destination image size
3088
3089             int width = img.getWidth(null);
3090             int height = img.getHeight(null);
3091
3092             Image resolutionVariant = getResolutionVariant(
3093                     (MultiResolutionImage) img, width, height,
3094                     dx1, dy1, dx2, dy2, sx1, sy1, sx2, sy2);
3095
3096             if (resolutionVariant != img && resolutionVariant != 
null) {
3097                 // recalculate source region for the resolution variant
3098
                      ImageObserver rvobserver = 
MultiResolutionToolkitImage.
                                  getResolutionVariantObserver(img, 
observer,
                                          width, height, -1, -1);

3099                 int rvWidth = resolutionVariant.getWidth(rvobserver);
3100                 int rvHeight = resolutionVariant.getHeight(rvobserver);
3101
3102                 if (0 < width && 0 < height && 0 < rvWidth && 0 < 
rvHeight) {
3103
3104                     float widthScale = ((float) rvWidth) / width;
3105                     float heightScale = ((float) rvHeight) / height;
3106
3107                     sx1 = Region.clipScale(sx1, widthScale);
3108                     sy1 = Region.clipScale(sy1, heightScale);
3109                     sx2 = Region.clipScale(sx2, widthScale);
3110                     sy2 = Region.clipScale(sy2, heightScale);
3111
                          observer = rvobserver;
3115                     img = resolutionVariant;
3116                 }
3117             }
3118         }

(And perhaps this explains why I was pushing for the rv dimensions to be 
determined on the fly - or hardcoded at 2x for now - in the wrapped 
observer?)

			...jim

On 12/3/13 9:49 AM, Jim Graham wrote:
> Hi Alexander,
>
> There is one last thing that I think I forgot to mention in SG2D that
> might make some other comments I made make more sense.  There is no
> observer registered on the resolution variant in SG2D.drawHiDPIImage()
> in the case where the resolution variant hasn't been loaded yet.
> Basically, the lines at 3099,3100 will trigger the variant to load, but
> there is no observer in those calls to trace it back to the guy who
> needs to call drawImage() again.  So, the only thing I think that needs
> to be done is that the observer needs to be wrapped and handed in to
> those calls to getWidth/Height(observer).
>
> The rest of that method looks fine - the regular variant will be used
> (and will trigger repaints via the code that calls into drawImage())
> until the base image dimensions are known enough to trigger the
> getResolutionVariant() code, and then we might continue to use the
> regular version until the resolution variant at least knows its
> dimensions, and that is all OK, but we need to start using the observer
> wrapper on the resolution variant starting at lines 3099,3100 in order
> to get the repaints to keep happening for that version of the image.
>
> Arguably, in addition, the unwrapped observer probably could be used on
> lines 3089, 3090 when you get the dimensions of the base image, but
> since the base image will later be handed to the drawImage pipeline, the
> observer will be registered there anyway, so that isn't a bug.  But, the
> wrapped observer needs to be used on 3099,3100 or we may never repaint
> with the resolution variant (it will be a race condition based on how
> fast the regular and hiDPI images load).
>
> More comments below, but that is the only remaining blocker that I can
> see...
>
> On 12/3/13 3:48 AM, Alexander Scherbatiy wrote:
>> On 12/3/2013 1:16 AM, Jim Graham wrote:
>>> On 12/2/13 4:55 AM, Alexander Scherbatiy wrote:
>>>> On 11/30/2013 3:27 AM, Jim Graham wrote:
>>>>> 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.
>>>>      It seems that just updating the newInfo method is not enough.
>>>
>>> There were 5 or 6 places that called imageUpdate when I did a quick
>>> search and most of the calls went through newInfo.  They'd all have to
>>> be updated.  Other than that, I'm not sure why it would not be enough?
>>
>>    Consider the following scenario. There are image.png and image at 2x.png
>> files on the disk.
>>      Image image1 = Toolkit.getImage("image.png");  // load as
>> multi-resolution image
>>      Image image2 = Toolkit.getImage("image at 2x.png");  // load the image
>> from cache
>>      toolkit.prepareImage(image2,.., imageObserver2);
>>
>>     The image2 has image1 as the base image so it rescale its
>> coordinates/dimension and passes the base instead of self to the
>> imageObserver2 which does not look correct.
>
> I see your point now.  I had thought that they would be cached
> separately, but I see now that both are inserted into the hash directly.
>   That allows sharing if they access both manually, but it complicates
> the observer issue.  I don't think I would have bothered with sharing
> the Image instance with a manual reference to the @2x in that case, but
> we should be able to handle both in a future bug fix and hopefully also
> get rid of wrappers, but it would take some surgery on the drawImage
> pipeline and the record keeping in the observer lists.  The existing
> solution will work fine for @2x images and allow sharing so it is good
> to go for now (modulo the one issue with using the wrapper for the
> getWidth()/getHeight() I mentioned above).
>
>>>>> Also, why does ObserverCache exist? Couldn't the cache just be a
>>>>> static field on MRToolkitImage?
>>>>       MRToolkitImage can be used in drawImage(Image,..,ImageObserver)
>>>> method always with null observer. So the is no need to create the
>>>> observer cache or use a synchronization during the cache
>>>> initialization.
>>>
>>> Maybe I'm missing something about your answer here, but I think you
>>> may have misunderstood my question.  You placed the field that holds
>>> the reference to the cache inside an inner class.  I didn't see why
>>> the reference could not be stored in the base class.  Why is there an
>>> empty inner class to wrap a single field?  In other words, why was
>>> this used:
>>>
>>>   56
>>>   57     private static class ObserverCache {
>>>   58
>>>   59         static final SoftCache INSTANCE = new SoftCache();
>>>   60     }
>>>   61
>>>
>>> Instead of just:
>>>
>>>   56
>>>   59     static final SoftCache INSTANCE = new SoftCache();
>>>   61
>>
>>     Just to not create the cache in case if MRToolkitImageis used but
>> image observers are always null. See the comment above.
>
> Ah, so this is just a micro-optimization then?  I'm not sure what you
> mean by "always null".  It depends on whether they hand in an observer,
> doesn't it?  The standard case of drawImage() tends to hand in the
> Component as the observer.  In cases where we know we are using a
> BufferedImage, we often use null, but code that uses a toolkit image (or
> that doesn't know what the image is) should be using a non-null observer
> or it won't paint right the first time when it triggers the image loading.
>
> The cache object itself takes so little room that I don't think it is
> worth worrying about.  If something triggers MRToolkitImage to be
> referenced at all, then the 99% case will likely eventually involve
> drawImage() calls with observer and an empty cache takes so little room
> that it is probably fine to just aggressively create it at that time.
>
> There is no bug or problem here, I just don't think the indirection buys
> us anything worthwhile here...
>
>              ...jim

From james.graham at oracle.com  Tue Dec  3 10:26:39 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 03 Dec 2013 10:26:39 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529E1999.5080200@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>
	<529922DD.7020605@oracle.com> <529C8326.7020401@oracle.com>
	<529CF89E.80309@oracle.com> <529DC51B.8090604@oracle.com>
	<529E1999.5080200@oracle.com>
Message-ID: <529E225F.4030006@oracle.com>

Ah, sorry, one last (non-blocking) issue with the new code.  Typically 
we report image loading a scan line at a time for GIFs and 
non-progressive JPEGs.  The simple "divide by integer 2" lines in the 
new observer will round OK for the x,y, but the dimensions will be 
rounded down and often be wrong.  For now I think this is OK since I'm 
not sure that anyone actually uses the notifications of single scan 
lines to do anything but redraw the image in its entirety, but it should 
go on the list of things to fix later.

Minimally, you could change the lines that adjust the dimensions to 
"(width + 1) / 2" and "(height + 1) / 2" which isn't quite correct, but 
should be reasonably close for now.  Eventually we should be using 
"round down, round up" semantics on the full rectangle, but for the 
simple case of 2x, this simple change should be enough...

			...jim

On 12/3/13 9:49 AM, Jim Graham wrote:
> Hi Alexander,
>
> There is one last thing that I think I forgot to mention in SG2D that
> might make some other comments I made make more sense.  There is no
> observer registered on the resolution variant in SG2D.drawHiDPIImage()
> in the case where the resolution variant hasn't been loaded yet.
> Basically, the lines at 3099,3100 will trigger the variant to load, but
> there is no observer in those calls to trace it back to the guy who
> needs to call drawImage() again.  So, the only thing I think that needs
> to be done is that the observer needs to be wrapped and handed in to
> those calls to getWidth/Height(observer).
>
> The rest of that method looks fine - the regular variant will be used
> (and will trigger repaints via the code that calls into drawImage())
> until the base image dimensions are known enough to trigger the
> getResolutionVariant() code, and then we might continue to use the
> regular version until the resolution variant at least knows its
> dimensions, and that is all OK, but we need to start using the observer
> wrapper on the resolution variant starting at lines 3099,3100 in order
> to get the repaints to keep happening for that version of the image.
>
> Arguably, in addition, the unwrapped observer probably could be used on
> lines 3089, 3090 when you get the dimensions of the base image, but
> since the base image will later be handed to the drawImage pipeline, the
> observer will be registered there anyway, so that isn't a bug.  But, the
> wrapped observer needs to be used on 3099,3100 or we may never repaint
> with the resolution variant (it will be a race condition based on how
> fast the regular and hiDPI images load).
>
> More comments below, but that is the only remaining blocker that I can
> see...
>
> On 12/3/13 3:48 AM, Alexander Scherbatiy wrote:
>> On 12/3/2013 1:16 AM, Jim Graham wrote:
>>> On 12/2/13 4:55 AM, Alexander Scherbatiy wrote:
>>>> On 11/30/2013 3:27 AM, Jim Graham wrote:
>>>>> 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.
>>>>      It seems that just updating the newInfo method is not enough.
>>>
>>> There were 5 or 6 places that called imageUpdate when I did a quick
>>> search and most of the calls went through newInfo.  They'd all have to
>>> be updated.  Other than that, I'm not sure why it would not be enough?
>>
>>    Consider the following scenario. There are image.png and image at 2x.png
>> files on the disk.
>>      Image image1 = Toolkit.getImage("image.png");  // load as
>> multi-resolution image
>>      Image image2 = Toolkit.getImage("image at 2x.png");  // load the image
>> from cache
>>      toolkit.prepareImage(image2,.., imageObserver2);
>>
>>     The image2 has image1 as the base image so it rescale its
>> coordinates/dimension and passes the base instead of self to the
>> imageObserver2 which does not look correct.
>
> I see your point now.  I had thought that they would be cached
> separately, but I see now that both are inserted into the hash directly.
>   That allows sharing if they access both manually, but it complicates
> the observer issue.  I don't think I would have bothered with sharing
> the Image instance with a manual reference to the @2x in that case, but
> we should be able to handle both in a future bug fix and hopefully also
> get rid of wrappers, but it would take some surgery on the drawImage
> pipeline and the record keeping in the observer lists.  The existing
> solution will work fine for @2x images and allow sharing so it is good
> to go for now (modulo the one issue with using the wrapper for the
> getWidth()/getHeight() I mentioned above).
>
>>>>> Also, why does ObserverCache exist? Couldn't the cache just be a
>>>>> static field on MRToolkitImage?
>>>>       MRToolkitImage can be used in drawImage(Image,..,ImageObserver)
>>>> method always with null observer. So the is no need to create the
>>>> observer cache or use a synchronization during the cache
>>>> initialization.
>>>
>>> Maybe I'm missing something about your answer here, but I think you
>>> may have misunderstood my question.  You placed the field that holds
>>> the reference to the cache inside an inner class.  I didn't see why
>>> the reference could not be stored in the base class.  Why is there an
>>> empty inner class to wrap a single field?  In other words, why was
>>> this used:
>>>
>>>   56
>>>   57     private static class ObserverCache {
>>>   58
>>>   59         static final SoftCache INSTANCE = new SoftCache();
>>>   60     }
>>>   61
>>>
>>> Instead of just:
>>>
>>>   56
>>>   59     static final SoftCache INSTANCE = new SoftCache();
>>>   61
>>
>>     Just to not create the cache in case if MRToolkitImageis used but
>> image observers are always null. See the comment above.
>
> Ah, so this is just a micro-optimization then?  I'm not sure what you
> mean by "always null".  It depends on whether they hand in an observer,
> doesn't it?  The standard case of drawImage() tends to hand in the
> Component as the observer.  In cases where we know we are using a
> BufferedImage, we often use null, but code that uses a toolkit image (or
> that doesn't know what the image is) should be using a non-null observer
> or it won't paint right the first time when it triggers the image loading.
>
> The cache object itself takes so little room that I don't think it is
> worth worrying about.  If something triggers MRToolkitImage to be
> referenced at all, then the 99% case will likely eventually involve
> drawImage() calls with observer and an empty cache takes so little room
> that it is probably fine to just aggressively create it at that time.
>
> There is no bug or problem here, I just don't think the indirection buys
> us anything worthwhile here...
>
>              ...jim

From anthony.petrov at oracle.com  Tue Dec  3 10:48:02 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 03 Dec 2013 22:48:02 +0400
Subject: <AWT Dev> Review Request: JDK-7175457 Fix for [TEST_BUG]
 closed/java/awt/Window/AlwaysOnTop/TestAlwaysOnTopBeforeShow.java still
 failed
In-Reply-To: <529DEED3.4090201@oracle.com>
References: <529DEED3.4090201@oracle.com>
Message-ID: <529E2762.90201@oracle.com>

Hi Andrei,

The fix looks good to me.

--
best regards,
Anthony

On 12/03/2013 06:46 PM, andrei.eremeev wrote:
> Hi, AWT team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-7175457
>
> The fix is available at:
> http://cr.openjdk.java.net/~yan/7175457/webrev.diff.00/
>
> Test moved to open:
> http://cr.openjdk.java.net/~yan/7175457/webrev.00/

From james.graham at oracle.com  Tue Dec  3 12:24:44 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 03 Dec 2013 12:24:44 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529E225F.4030006@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>
	<529922DD.7020605@oracle.com> <529C8326.7020401@oracle.com>
	<529CF89E.80309@oracle.com> <529DC51B.8090604@oracle.com>
	<529E1999.5080200@oracle.com> <529E225F.4030006@oracle.com>
Message-ID: <529E3E0C.6060508@oracle.com>

(Non-blocking issue discussion here...)

Hmmm...  This won't actually help anyway because you only divide the 
dimensions when the WIDTH/HEIGHT flags are set.  The tests for dividing 
the dimensions should also include SOMEBITS, FRAMEBITS, and ALLBITS 
since all 3 of those include a scaled width/height.

Again, this issue isn't blocking because at least the WIDTH|HEIGHT flags 
get the correct information and all of the other flags which report 
which part of the image changed, will just over-report the dimensions of 
the new data (for now)...

			...jim

On 12/3/13 10:26 AM, Jim Graham wrote:
> Ah, sorry, one last (non-blocking) issue with the new code.  Typically
> we report image loading a scan line at a time for GIFs and
> non-progressive JPEGs.  The simple "divide by integer 2" lines in the
> new observer will round OK for the x,y, but the dimensions will be
> rounded down and often be wrong.  For now I think this is OK since I'm
> not sure that anyone actually uses the notifications of single scan
> lines to do anything but redraw the image in its entirety, but it should
> go on the list of things to fix later.
>
> Minimally, you could change the lines that adjust the dimensions to
> "(width + 1) / 2" and "(height + 1) / 2" which isn't quite correct, but
> should be reasonably close for now.  Eventually we should be using
> "round down, round up" semantics on the full rectangle, but for the
> simple case of 2x, this simple change should be enough...
>
>              ...jim
>
> On 12/3/13 9:49 AM, Jim Graham wrote:
>> Hi Alexander,
>>
>> There is one last thing that I think I forgot to mention in SG2D that
>> might make some other comments I made make more sense.  There is no
>> observer registered on the resolution variant in SG2D.drawHiDPIImage()
>> in the case where the resolution variant hasn't been loaded yet.
>> Basically, the lines at 3099,3100 will trigger the variant to load, but
>> there is no observer in those calls to trace it back to the guy who
>> needs to call drawImage() again.  So, the only thing I think that needs
>> to be done is that the observer needs to be wrapped and handed in to
>> those calls to getWidth/Height(observer).
>>
>> The rest of that method looks fine - the regular variant will be used
>> (and will trigger repaints via the code that calls into drawImage())
>> until the base image dimensions are known enough to trigger the
>> getResolutionVariant() code, and then we might continue to use the
>> regular version until the resolution variant at least knows its
>> dimensions, and that is all OK, but we need to start using the observer
>> wrapper on the resolution variant starting at lines 3099,3100 in order
>> to get the repaints to keep happening for that version of the image.
>>
>> Arguably, in addition, the unwrapped observer probably could be used on
>> lines 3089, 3090 when you get the dimensions of the base image, but
>> since the base image will later be handed to the drawImage pipeline, the
>> observer will be registered there anyway, so that isn't a bug.  But, the
>> wrapped observer needs to be used on 3099,3100 or we may never repaint
>> with the resolution variant (it will be a race condition based on how
>> fast the regular and hiDPI images load).
>>
>> More comments below, but that is the only remaining blocker that I can
>> see...
>>
>> On 12/3/13 3:48 AM, Alexander Scherbatiy wrote:
>>> On 12/3/2013 1:16 AM, Jim Graham wrote:
>>>> On 12/2/13 4:55 AM, Alexander Scherbatiy wrote:
>>>>> On 11/30/2013 3:27 AM, Jim Graham wrote:
>>>>>> 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.
>>>>>      It seems that just updating the newInfo method is not enough.
>>>>
>>>> There were 5 or 6 places that called imageUpdate when I did a quick
>>>> search and most of the calls went through newInfo.  They'd all have to
>>>> be updated.  Other than that, I'm not sure why it would not be enough?
>>>
>>>    Consider the following scenario. There are image.png and image at 2x.png
>>> files on the disk.
>>>      Image image1 = Toolkit.getImage("image.png");  // load as
>>> multi-resolution image
>>>      Image image2 = Toolkit.getImage("image at 2x.png");  // load the image
>>> from cache
>>>      toolkit.prepareImage(image2,.., imageObserver2);
>>>
>>>     The image2 has image1 as the base image so it rescale its
>>> coordinates/dimension and passes the base instead of self to the
>>> imageObserver2 which does not look correct.
>>
>> I see your point now.  I had thought that they would be cached
>> separately, but I see now that both are inserted into the hash directly.
>>   That allows sharing if they access both manually, but it complicates
>> the observer issue.  I don't think I would have bothered with sharing
>> the Image instance with a manual reference to the @2x in that case, but
>> we should be able to handle both in a future bug fix and hopefully also
>> get rid of wrappers, but it would take some surgery on the drawImage
>> pipeline and the record keeping in the observer lists.  The existing
>> solution will work fine for @2x images and allow sharing so it is good
>> to go for now (modulo the one issue with using the wrapper for the
>> getWidth()/getHeight() I mentioned above).
>>
>>>>>> Also, why does ObserverCache exist? Couldn't the cache just be a
>>>>>> static field on MRToolkitImage?
>>>>>       MRToolkitImage can be used in drawImage(Image,..,ImageObserver)
>>>>> method always with null observer. So the is no need to create the
>>>>> observer cache or use a synchronization during the cache
>>>>> initialization.
>>>>
>>>> Maybe I'm missing something about your answer here, but I think you
>>>> may have misunderstood my question.  You placed the field that holds
>>>> the reference to the cache inside an inner class.  I didn't see why
>>>> the reference could not be stored in the base class.  Why is there an
>>>> empty inner class to wrap a single field?  In other words, why was
>>>> this used:
>>>>
>>>>   56
>>>>   57     private static class ObserverCache {
>>>>   58
>>>>   59         static final SoftCache INSTANCE = new SoftCache();
>>>>   60     }
>>>>   61
>>>>
>>>> Instead of just:
>>>>
>>>>   56
>>>>   59     static final SoftCache INSTANCE = new SoftCache();
>>>>   61
>>>
>>>     Just to not create the cache in case if MRToolkitImageis used but
>>> image observers are always null. See the comment above.
>>
>> Ah, so this is just a micro-optimization then?  I'm not sure what you
>> mean by "always null".  It depends on whether they hand in an observer,
>> doesn't it?  The standard case of drawImage() tends to hand in the
>> Component as the observer.  In cases where we know we are using a
>> BufferedImage, we often use null, but code that uses a toolkit image (or
>> that doesn't know what the image is) should be using a non-null observer
>> or it won't paint right the first time when it triggers the image
>> loading.
>>
>> The cache object itself takes so little room that I don't think it is
>> worth worrying about.  If something triggers MRToolkitImage to be
>> referenced at all, then the 99% case will likely eventually involve
>> drawImage() calls with observer and an empty cache takes so little room
>> that it is probably fine to just aggressively create it at that time.
>>
>> There is no bug or problem here, I just don't think the indirection buys
>> us anything worthwhile here...
>>
>>              ...jim

From lana.steuck at oracle.com  Tue Dec  3 17:16:04 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 01:16:04 +0000
Subject: <AWT Dev> hg: jdk8/awt/corba: 5 new changesets
Message-ID: <20131204011612.13EAF62A18@hg.openjdk.java.net>

Changeset: 5029f982dfae
Author:    cl
Date:      2013-11-28 08:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/5029f982dfae

Added tag jdk8-b118 for changeset d6820a414f18

! .hgtags

Changeset: 9729f9862eb4
Author:    ihse
Date:      2013-11-04 11:09 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/9729f9862eb4

8027566: Remove the old build system
Reviewed-by: erikj, tbell

+ make/BuildCorba.gmk
! make/Makefile
- make/com/Makefile
- make/com/sun/Makefile
- make/com/sun/corba/Makefile
- make/com/sun/corba/minclude/com_sun_corba_se_PortableActivationIDL.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_activation.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_corba.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_core.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_dynamicany.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_encoding.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_interceptors.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_io.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_ior.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_legacy.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_logging.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_monitoring.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_naming_cosnaming.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_naming_namingutil.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_naming_pcosnaming.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_oa_poa.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_oa_toa.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_orb.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_presentation_rmi.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_protocol.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_resolver.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_transport.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_impl_util.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_internal_LegacyFiles.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_pept.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_activation.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_copyobject.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_encoding.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_extension.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_ior.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_legacy_connection.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_legacy_interceptor.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_logging.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_monitoring.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_oa.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_orb.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_orbutil.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_presentation_rmi.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_protocol.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_resolver.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_servicecontext.jmk
- make/com/sun/corba/minclude/com_sun_corba_se_spi_transport.jmk
- make/com/sun/corba/minclude/com_sun_tools_corba_se_idl_toJavaPortable.jmk
- make/com/sun/corba/minclude/javax_activity.jmk
- make/com/sun/corba/minclude/javax_rmi.jmk
- make/com/sun/corba/minclude/javax_rmi_CORBA.jmk
- make/com/sun/corba/minclude/javax_transaction.jmk
- make/com/sun/corba/minclude/org_omg_CORBA.jmk
- make/com/sun/corba/minclude/org_omg_CORBAX.jmk
- make/com/sun/corba/minclude/org_omg_CORBA_2_3.jmk
- make/com/sun/corba/minclude/org_omg_CosNaming.jmk
- make/com/sun/corba/minclude/org_omg_DynamicAny.jmk
- make/com/sun/corba/minclude/org_omg_IOP.jmk
- make/com/sun/corba/minclude/org_omg_Messaging.jmk
- make/com/sun/corba/minclude/org_omg_PortableInterceptor.jmk
- make/com/sun/corba/minclude/org_omg_PortableServer.jmk
- make/com/sun/corba/minclude/org_omg_SendingContext.jmk
- make/com/sun/corba/minclude/sun_corba.jmk
- make/com/sun/corba/se/Makefile
- make/com/sun/corba/se/PortableActivationIDL/Makefile
- make/com/sun/corba/se/connection/FILES_java.gmk
- make/com/sun/corba/se/connection/Makefile
- make/com/sun/corba/se/core/Makefile
- make/com/sun/corba/se/corespi/Makefile
- make/com/sun/corba/se/impl/Makefile
- make/com/sun/corba/se/impl/activation/Makefile
- make/com/sun/corba/se/impl/activation/orbd/Makefile
- make/com/sun/corba/se/impl/activation/servertool/Makefile
- make/com/sun/corba/se/impl/interceptors/Makefile
- make/com/sun/corba/se/impl/logging/Makefile
- make/com/sun/corba/se/impl/monitoring/Makefile
- make/com/sun/corba/se/impl/naming/Makefile
- make/com/sun/corba/se/impl/naming/cosnaming/Makefile
- make/com/sun/corba/se/impl/naming/namingutil/Makefile
- make/com/sun/corba/se/impl/naming/pcosnaming/Makefile
- make/com/sun/corba/se/impl/oa/Makefile
- make/com/sun/corba/se/impl/oa/poa/Makefile
- make/com/sun/corba/se/impl/oa/toa/Makefile
- make/com/sun/corba/se/interceptor/FILES_java.gmk
- make/com/sun/corba/se/interceptor/Makefile
- make/com/sun/corba/se/pept/Makefile
- make/com/sun/corba/se/rmi/Makefile
- make/com/sun/corba/se/rmi/rmic/Makefile
- make/com/sun/corba/se/rmi/rmic/SUN_RMI_RMIC_IIOP_java.gmk
- make/com/sun/corba/se/sources/Makefile
- make/com/sun/corba/se/spi/Makefile
- make/com/sun/corba/se/spi/activation/Makefile
- make/com/sun/corba/se/spi/copyobject/Makefile
- make/com/sun/corba/se/spi/encoding/Makefile
- make/com/sun/corba/se/spi/extension/Makefile
- make/com/sun/corba/se/spi/legacy/Makefile
- make/com/sun/corba/se/spi/legacy/connection/Makefile
- make/com/sun/corba/se/spi/legacy/interceptor/Makefile
- make/com/sun/corba/se/spi/logging/Makefile
- make/com/sun/corba/se/spi/monitoring/Makefile
- make/common/BuildToolJar.gmk
- make/common/CancelImplicits.gmk
- make/common/Classes.gmk
- make/common/Defs-bsd.gmk
- make/common/Defs-linux.gmk
- make/common/Defs-solaris.gmk
- make/common/Defs-windows.gmk
- make/common/Defs.gmk
- make/common/Rules.gmk
- make/common/internal/Resources.gmk
- make/common/shared/Defs-bsd.gmk
- make/common/shared/Defs-java.gmk
- make/common/shared/Defs-linux.gmk
- make/common/shared/Defs-solaris.gmk
- make/common/shared/Defs-utils.gmk
- make/common/shared/Defs-windows.gmk
- make/common/shared/Defs.gmk
- make/common/shared/Platform.gmk
- make/javax/Makefile
- make/javax/xa/Makefile
- make/jprt.properties
- make/org/Makefile
- make/org/omg/CORBA/Makefile
- make/org/omg/CORBAX_java.gmk
- make/org/omg/CosNaming/Makefile
- make/org/omg/DynamicAny/Makefile
- make/org/omg/Makefile
- make/org/omg/PortableInterceptor/Makefile
- make/org/omg/PortableServer/Makefile
- make/org/omg/idl/FILES_java.gmk
- make/org/omg/idl/Makefile
- make/org/omg/sources/Makefile
- make/sun/Makefile
- make/sun/corba/Makefile
- make/sun/corba/core/Makefile
- make/sun/corba/org/Makefile
- make/sun/corba/org/omg/FILES_java.gmk
- make/sun/corba/org/omg/Makefile
- make/sun/rmi/Makefile
- make/sun/rmi/corbalogcompile/Makefile
- make/sun/rmi/corbalogsources/Makefile
- make/sun/rmi/rmic/FILES.gmk
- make/sun/rmi/rmic/Makefile
- make/tools/Makefile
- make/tools/idlj/Makefile
- make/tools/logutil/Makefile
- make/tools/strip_properties/Makefile
- makefiles/BuildCorba.gmk
- makefiles/Makefile

Changeset: fe781b3badd6
Author:    msheppar
Date:      2013-11-21 11:30 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/fe781b3badd6

8028215: ORB.init fails with SecurityException if properties select the JDK default ORB
Summary: check for default ORBImpl and ORBSingleton set via properties or System properties
Reviewed-by: alanb, coffeys, mchung

! src/share/classes/org/omg/CORBA/ORB.java

Changeset: e648df60c8a2
Author:    lana
Date:      2013-11-25 09:27 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/e648df60c8a2

Merge


Changeset: 379fc7609beb
Author:    lana
Date:      2013-12-03 10:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/379fc7609beb

Merge



From lana.steuck at oracle.com  Tue Dec  3 17:16:16 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 01:16:16 +0000
Subject: <AWT Dev> hg: jdk8/awt/nashorn: 9 new changesets
Message-ID: <20131204011628.9EA4062A1A@hg.openjdk.java.net>

Changeset: b55a011cf8ae
Author:    cl
Date:      2013-11-28 08:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/b55a011cf8ae

Added tag jdk8-b118 for changeset 8d014b039b44

! .hgtags

Changeset: 779e155419b8
Author:    ihse
Date:      2013-11-04 11:11 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/779e155419b8

8027566: Remove the old build system
Reviewed-by: erikj, tbell

+ make/BuildNashorn.gmk
! make/Makefile
- makefiles/BuildNashorn.gmk
- makefiles/Makefile

Changeset: fea9f0f9bbde
Author:    sundar
Date:      2013-11-14 15:53 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/fea9f0f9bbde

8028161: nashorn: src/jdk/nashorn/api/scripting/ScriptEngineTest.java
Reviewed-by: lagergren, hannesw

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

Changeset: a165c0fb5be6
Author:    hannesw
Date:      2013-11-16 00:23 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/a165c0fb5be6

8028210: Missing conversions on array index expression
Reviewed-by: attila, jlaskey, lagergren

! src/jdk/nashorn/internal/objects/NativeArguments.java
! src/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk/nashorn/internal/objects/NativeString.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java
+ test/script/basic/JDK-8028210.js
+ test/script/basic/JDK-8028210.js.EXPECTED

Changeset: bce2bbfb35ae
Author:    lagergren
Date:      2013-11-18 16:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/bce2bbfb35ae

8028434: Line number nodes were off for while nodes and do while nodes - the line number of a loop node should be treated as the location of the test expression
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java
! src/jdk/nashorn/internal/parser/Parser.java
+ test/script/basic/JDK-8028434.js
+ test/script/basic/JDK-8028434.js.EXPECTED

Changeset: b375d261e56c
Author:    lagergren
Date:      2013-11-19 10:29 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/b375d261e56c

8028573: Line number nodes were off for while nodes and do while nodes - the line number of a loop node should be treated as the location of the test expression
Reviewed-by: attila, hannesw

! test/script/basic/JDK-8028434.js

Changeset: 73d741231651
Author:    sundar
Date:      2013-11-22 08:52 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/73d741231651

Merge


Changeset: 44ea3815e414
Author:    lana
Date:      2013-11-25 09:41 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/44ea3815e414

Merge


Changeset: c3343930c73c
Author:    lana
Date:      2013-12-03 10:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/c3343930c73c

Merge



From lana.steuck at oracle.com  Tue Dec  3 17:16:06 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 01:16:06 +0000
Subject: <AWT Dev> hg: jdk8/awt/jaxws: 4 new changesets
Message-ID: <20131204011623.15E0C62A19@hg.openjdk.java.net>

Changeset: 7ac7d1afd966
Author:    cl
Date:      2013-11-28 08:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/7ac7d1afd966

Added tag jdk8-b118 for changeset 76a598cf50c4

! .hgtags

Changeset: 1d1af4ce8eeb
Author:    ihse
Date:      2013-11-04 11:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/1d1af4ce8eeb

8027566: Remove the old build system
Reviewed-by: erikj, tbell

+ make/BuildJaxws.gmk
! make/Makefile
- make/jprt.properties
- make/scripts/update_src.sh
- makefiles/BuildJaxws.gmk
- makefiles/Makefile

Changeset: 4900fcaae498
Author:    lana
Date:      2013-11-25 09:28 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/4900fcaae498

Merge


Changeset: 172b8e056ff2
Author:    lana
Date:      2013-12-03 10:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/172b8e056ff2

Merge



From lana.steuck at oracle.com  Tue Dec  3 17:16:22 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 01:16:22 +0000
Subject: <AWT Dev> hg: jdk8/awt/jaxp: 6 new changesets
Message-ID: <20131204011641.07D0162A1B@hg.openjdk.java.net>

Changeset: 6b37ae056340
Author:    cl
Date:      2013-11-28 08:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/6b37ae056340

Added tag jdk8-b118 for changeset e4e5069250e7

! .hgtags

Changeset: 80acb8151797
Author:    ihse
Date:      2013-11-04 11:09 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/80acb8151797

8027566: Remove the old build system
Reviewed-by: erikj, tbell

+ make/BuildJaxp.gmk
! make/Makefile
- make/jprt.properties
- make/scripts/update_src.sh
- makefiles/BuildJaxp.gmk
- makefiles/Makefile

Changeset: 7ce7e38868d3
Author:    lana
Date:      2013-11-25 09:28 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/7ce7e38868d3

Merge


Changeset: abd44ea60dbe
Author:    mfang
Date:      2013-11-21 15:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/abd44ea60dbe

8028803: jdk8 l10n resource file translation update 5 - jaxp repo
Reviewed-by: joehw, yhuang

! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java
! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_CN.java

Changeset: e65463c785ed
Author:    mfang
Date:      2013-11-25 14:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/e65463c785ed

Merge


Changeset: 69a930376c70
Author:    lana
Date:      2013-12-03 10:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/69a930376c70

Merge



From lana.steuck at oracle.com  Tue Dec  3 17:16:21 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 01:16:21 +0000
Subject: <AWT Dev> hg: jdk8/awt/langtools: 13 new changesets
Message-ID: <20131204011706.D975162A1C@hg.openjdk.java.net>

Changeset: 1f6ffcd56363
Author:    cl
Date:      2013-11-28 08:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/1f6ffcd56363

Added tag jdk8-b118 for changeset 4fd6a7ff8c06

! .hgtags

Changeset: 8043b9cf31ab
Author:    ihse
Date:      2013-11-04 11:08 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/8043b9cf31ab

8027566: Remove the old build system
Reviewed-by: erikj, tbell

+ make/BuildLangtools.gmk
! make/Makefile
- make/jprt.properties
- makefiles/BuildLangtools.gmk
- makefiles/Makefile

Changeset: f42a22e2b2cd
Author:    kizune
Date:      2013-11-19 22:14 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/f42a22e2b2cd

6726154: javadoc generated with incorrect version in comment
Reviewed-by: jjg, bpatel, erikj, tbell

! make/BuildLangtools.gmk
! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java

Changeset: 66bcd5d4b3d1
Author:    vromero
Date:      2013-11-19 23:35 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/66bcd5d4b3d1

8028504: javac generates LocalVariableTable even with -g:none
Reviewed-by: jjg, jlahoda

! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
+ test/tools/javac/T8028504/DontGenerateLVTForGNoneOpTest.java

Changeset: 7c89d200781b
Author:    jlahoda
Date:      2013-11-20 13:44 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/7c89d200781b

6557966: Multiple upper bounds of the TypeVariable
Summary: Adjusting javax.lang.model javadoc regarding IntersectionType, IntersectionType.accept now calls visitIntersection for all kinds of IntersectionTypes.
Reviewed-by: darcy, vromero
Contributed-by: joe.darcy at oracle.com, jan.lahoda at oracle.com

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/javax/lang/model/type/DeclaredType.java
! src/share/classes/javax/lang/model/type/IntersectionType.java
! src/share/classes/javax/lang/model/type/TypeVariable.java
! test/tools/javac/processing/model/type/IntersectionPropertiesTest.java

Changeset: ef44a2971cb1
Author:    bpatel
Date:      2013-11-20 10:53 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/ef44a2971cb1

8027977: javadoc dies on NumberFormat/DateFormat subclass
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javadoc/DocEnv.java
+ test/com/sun/javadoc/testCompletionFailure/TestCompletionFailure.java
+ test/com/sun/javadoc/testCompletionFailure/pkg1/NumberFormatTest.java

Changeset: 4fa835472e3c
Author:    rfield
Date:      2013-11-22 17:07 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/4fa835472e3c

8028739: javac generates incorrect descriptor for MethodHandle::invoke
Summary: introduce special handling for signature polymorphic methods
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestMethodHandle.java

Changeset: 7ef88faaa16c
Author:    lana
Date:      2013-11-25 09:41 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/7ef88faaa16c

Merge


Changeset: a78f51d6bd5e
Author:    jjg
Date:      2013-11-25 17:42 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/a78f51d6bd5e

8028318: [doclint] doclint will reject existing user-written doc comments using custom tags that follow the recommended rules
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
! test/tools/doclint/CustomTagTest.java
! test/tools/doclint/CustomTagTest.out
! test/tools/doclint/CustomTagTestWithOption.out

Changeset: 3ea55d523981
Author:    jfranck
Date:      2013-11-26 13:33 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/3ea55d523981

8028428: strictfp allowed as annotation element modifier
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Flags.java
+ test/tools/javac/annotations/AnnotationTypeElementModifiers.java
+ test/tools/javac/annotations/AnnotationTypeElementModifiers.out

Changeset: 8acb838c9b79
Author:    jlahoda
Date:      2013-11-26 15:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/8acb838c9b79

8026374: javac accepts void as a method parameter
Summary: Changing Check.validate to reject void types.
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/declaration/method/MethodVoidParameter.java
+ test/tools/javac/declaration/method/MethodVoidParameter.out

Changeset: 756ae3791c45
Author:    jlahoda
Date:      2013-11-26 15:33 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/756ae3791c45

8027789: Access method for Outer.super.m() references indirect superclass
Summary: Internally convert the qualified super access to an equivalent of an unqualified super access inside the access method.
Reviewed-by: vromero, jjg

! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/expression/_super/NonDirectSuper/Base.java
+ test/tools/javac/expression/_super/NonDirectSuper/NonDirectSuper.java
+ test/tools/javac/expression/_super/NonDirectSuper/Target11.java

Changeset: 43a80d75d06e
Author:    lana
Date:      2013-12-03 10:47 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/43a80d75d06e

Merge



From lana.steuck at oracle.com  Tue Dec  3 17:16:30 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 01:16:30 +0000
Subject: <AWT Dev> hg: jdk8/awt/hotspot: 26 new changesets
Message-ID: <20131204011728.600C262A1D@hg.openjdk.java.net>

Changeset: 854a42db7069
Author:    amurillo
Date:      2013-11-15 07:58 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/854a42db7069

8028444: new hotspot build - hs25-b60
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 570aaefce624
Author:    morris
Date:      2013-11-18 12:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/570aaefce624

8028319: ConflictingDefaultsTest.testReabstract spins when running with -mode invoke and -Xcomp
Summary: Change _abstract_method_handler to return AbstractMethodError i2c, c2i and c2iv entries.
Reviewed-by: kvn, vlivanov

! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp

Changeset: 938e1e64e28f
Author:    anoll
Date:      2013-11-14 19:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/938e1e64e28f

8028306: nsk stress tests, CodeCache fills, then safepoint asserts
Summary: Move handle_full_code_cache() out of block that forbids safepoints
Reviewed-by: kvn, iveresov

! src/share/vm/ci/ciEnv.cpp
! src/share/vm/runtime/sweeper.cpp

Changeset: fca8f4799229
Author:    roland
Date:      2013-11-20 12:46 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/fca8f4799229

8028308: nsk regression, assert(obj->is_oop()) failed: not an oop
Summary: rbp not restored when stack overflow is thrown from deopt/uncommon trap blobs
Reviewed-by: kvn, iveresov

! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
+ test/compiler/uncommontrap/TestStackBangRbp.java

Changeset: cdf20166ec45
Author:    minqi
Date:      2013-11-13 16:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/cdf20166ec45

8025632: Remove all references to MagicLambdaImpl from Hotspot
Summary: MagicLambdaImpl was removed from jdk side, this should be done in vm side too
Reviewed-by: coleenp, hseigel, rdurbin

! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/reflection.cpp
! test/compiler/jsr292/ConcurrentClassLoadingTest.java

Changeset: 3edddbff4865
Author:    minqi
Date:      2013-11-13 16:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3edddbff4865

Merge


Changeset: b03f33670080
Author:    sla
Date:      2013-11-14 19:30 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b03f33670080

6606002: jinfo doesn't detect dynamic vm flags changing
Reviewed-by: coleenp, jbachorik, sspitsyn

! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java

Changeset: 5280822ddfcd
Author:    sla
Date:      2013-11-14 20:03 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/5280822ddfcd

6626412: jstack using SA prints some info messages into err stream
Reviewed-by: coleenp, farvidsson, jbachorik, dsamersoff, sspitsyn

! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java

Changeset: 438fe38c63c8
Author:    mgronlun
Date:      2013-11-15 21:39 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/438fe38c63c8

Merge

! src/share/vm/runtime/globals.hpp

Changeset: d61a1a166f44
Author:    coleenp
Date:      2013-11-15 17:20 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d61a1a166f44

8028347: Rewriter::scan_method asserts with array oob in RT_Baseline
Summary: Fix reversing rewriting for invokespecial
Reviewed-by: jrose, hseigel

! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/interpreter/rewriter.hpp

Changeset: 0b9ea9a72436
Author:    sla
Date:      2013-11-18 10:20 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/0b9ea9a72436

8027630: SIGSEGV in const char*Klass::external_name()
Reviewed-by: coleenp, sspitsyn, mgronlun

! src/share/vm/classfile/metadataOnStackMark.cpp
! src/share/vm/services/threadService.cpp
! src/share/vm/services/threadService.hpp

Changeset: 396564992823
Author:    sgabdura
Date:      2013-11-18 08:21 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/396564992823

8028341: PSR:FUNC: SCOPE PARAMETER MISSING FROM THE -XX:+PRINTFLAGSFINAL
Reviewed-by: dcubed, sla

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

Changeset: aa933e6b061d
Author:    mgronlun
Date:      2013-11-22 20:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/aa933e6b061d

Merge


Changeset: abad3b2d905d
Author:    amurillo
Date:      2013-11-22 13:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/abad3b2d905d

Merge


Changeset: c9f439732b18
Author:    amurillo
Date:      2013-11-22 13:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c9f439732b18

Added tag hs25-b60 for changeset abad3b2d905d

! .hgtags

Changeset: e6dfcdf37ef2
Author:    cl
Date:      2013-11-28 08:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e6dfcdf37ef2

Added tag jdk8-b118 for changeset c9f439732b18

! .hgtags

Changeset: e51d73189692
Author:    amurillo
Date:      2013-11-22 13:42 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e51d73189692

8028815: new hotspot build - hs25-b61
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 19146c82b6fc
Author:    hseigel
Date:      2013-11-21 14:41 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/19146c82b6fc

8028520: JVM should not throw VerifyError when a private method overrides a final method
Summary: Exclude private methods when checking for final method override.
Reviewed-by: kamg, coleenp, dholmes, mseledtsov

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

Changeset: 260ac69dc096
Author:    mgronlun
Date:      2013-11-23 09:56 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/260ac69dc096

Merge


Changeset: 86e6d691f2e1
Author:    mgronlun
Date:      2013-11-23 12:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/86e6d691f2e1

8028128: Add a type safe alternative for working with counter based data
Reviewed-by: dholmes, egahlin

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/shared/gcTimer.cpp
! src/share/vm/gc_implementation/shared/gcTimer.hpp
! src/share/vm/gc_implementation/shared/gcTrace.cpp
! src/share/vm/gc_implementation/shared/gcTrace.hpp
! src/share/vm/gc_implementation/shared/gcTraceSend.cpp
! src/share/vm/gc_implementation/shared/gcTraceTime.cpp
! src/share/vm/gc_implementation/shared/gcTraceTime.hpp
! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp
! src/share/vm/gc_implementation/shared/objectCountEventSender.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/generation.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/trace/noTraceBackend.hpp
! src/share/vm/trace/trace.xml
! src/share/vm/trace/traceBackend.hpp
! src/share/vm/trace/traceEvent.hpp
! src/share/vm/trace/traceEventClasses.xsl
! src/share/vm/trace/traceTime.hpp
! src/share/vm/trace/traceTypes.xsl
! src/share/vm/trace/tracetypes.xml
+ src/share/vm/utilities/ticks.cpp
+ src/share/vm/utilities/ticks.hpp
+ src/share/vm/utilities/ticks.inline.hpp

Changeset: 22eaa15b7960
Author:    hseigel
Date:      2013-11-26 09:52 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/22eaa15b7960

8026065: InterfaceMethodref for invokespecial must name a direct superinterface
Summary: Add verification to check that invokespecial of an InterfaceMethodref names a method in a direct superinterface of the current class or interface in accordance with JSR 335, JVMS 4.9.2 Structural Constraints.
Reviewed-by: acorn, hseigel, coleenp
Contributed-by: lois.foltan at oracle.com

! src/share/vm/classfile/verifier.cpp
! src/share/vm/classfile/verifier.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp

Changeset: e567d5afd4dd
Author:    hseigel
Date:      2013-11-26 16:03 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e567d5afd4dd

8028160: [TESTBUG] Exclude failing (runtime) jtreg tests using @ignore
Summary: Use @ignore to exclude failing tests
Reviewed-by: coleenp, ctornqvi, mseledtsov
Contributed-by: george.triantafillou at oracle.com

! test/runtime/6626217/Test6626217.sh
! test/runtime/6929067/Test6929067.sh
! test/runtime/CDSCompressedKPtrs/XShareAuto.java
! test/runtime/InitialThreadOverflow/testme.sh
! test/runtime/LoadClass/LoadClassNegative.java
! test/runtime/XCheckJniJsig/XCheckJSig.java
! test/runtime/jsig/Test8017498.sh
! test/runtime/memory/ReadFromNoaccessArea.java

Changeset: 9d15b81d5d1b
Author:    drchase
Date:      2013-11-26 18:16 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9d15b81d5d1b

8016839: JSR292: AME instead of IAE when calling a method
Summary: Catch missing-because-illegal case for itable entries and use an exception-throwing method instead of null.
Reviewed-by: acorn, jrose, coleenp

! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/klassVtable.cpp
! test/compiler/jsr292/methodHandleExceptions/ByteClassLoader.java
- test/compiler/jsr292/methodHandleExceptions/C.java
- test/compiler/jsr292/methodHandleExceptions/I.java
! test/compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java
+ test/compiler/jsr292/methodHandleExceptions/p/C.java
+ test/compiler/jsr292/methodHandleExceptions/p/Dok.java
+ test/compiler/jsr292/methodHandleExceptions/p/E.java
+ test/compiler/jsr292/methodHandleExceptions/p/F.java
+ test/compiler/jsr292/methodHandleExceptions/p/I.java
+ test/compiler/jsr292/methodHandleExceptions/p/Tdirect.java
+ test/compiler/jsr292/methodHandleExceptions/p/Treflect.java

Changeset: 2315fab779ca
Author:    drchase
Date:      2013-11-29 11:32 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/2315fab779ca

Merge

! src/share/vm/classfile/systemDictionary.hpp
- test/compiler/jsr292/methodHandleExceptions/C.java
- test/compiler/jsr292/methodHandleExceptions/I.java

Changeset: b2426da30009
Author:    amurillo
Date:      2013-11-29 11:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b2426da30009

Merge

- test/compiler/jsr292/methodHandleExceptions/C.java
- test/compiler/jsr292/methodHandleExceptions/I.java

Changeset: ce42d815dd21
Author:    amurillo
Date:      2013-11-29 11:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ce42d815dd21

Added tag hs25-b61 for changeset b2426da30009

! .hgtags


From lana.steuck at oracle.com  Tue Dec  3 17:16:04 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 01:16:04 +0000
Subject: <AWT Dev> hg: jdk8/awt: 5 new changesets
Message-ID: <20131204011605.8270062A16@hg.openjdk.java.net>

Changeset: 06d512d44c31
Author:    cl
Date:      2013-11-28 08:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/06d512d44c31

Added tag jdk8-b118 for changeset 0a6db1aac998

! .hgtags

Changeset: a667caba1e84
Author:    ihse
Date:      2013-11-14 10:53 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/a667caba1e84

8027566: Remove the old build system
Reviewed-by: erikj, tbell

! Makefile
- NewMakefile.gmk
! common/autoconf/Makefile.in
! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/hotspot-spec.gmk.in
! common/autoconf/source-dirs.m4
! common/autoconf/spec.gmk.in
! common/bin/compare.sh
- common/makefiles/HotspotWrapper.gmk
- common/makefiles/IdlCompilation.gmk
- common/makefiles/JavaCompilation.gmk
- common/makefiles/Jprt.gmk
- common/makefiles/Main.gmk
- common/makefiles/MakeBase.gmk
- common/makefiles/MakeHelpers.gmk
- common/makefiles/Makefile
- common/makefiles/NativeCompilation.gmk
- common/makefiles/RMICompilation.gmk
- common/makefiles/devkit/Makefile
- common/makefiles/devkit/Tools.gmk
- common/makefiles/javadoc/CORE_PKGS.gmk
- common/makefiles/javadoc/Javadoc.gmk
- common/makefiles/javadoc/NON_CORE_PKGS.gmk
- common/makefiles/javadoc/Notes.html
- common/makefiles/support/ListPathsSafely-post-compress.incl
- common/makefiles/support/ListPathsSafely-pre-compress.incl
- common/makefiles/support/ListPathsSafely-uncompress.sed
- common/makefiles/support/unicode2x.sed
! common/nb_native/nbproject/configurations.xml
- make/Defs-internal.gmk
+ make/HotspotWrapper.gmk
+ make/Javadoc.gmk
+ make/Jprt.gmk
+ make/Main.gmk
+ make/MakeHelpers.gmk
- make/README.pre-components
+ make/common/CORE_PKGS.gmk
+ make/common/IdlCompilation.gmk
+ make/common/JavaCompilation.gmk
+ make/common/MakeBase.gmk
+ make/common/NON_CORE_PKGS.gmk
+ make/common/NativeCompilation.gmk
+ make/common/RMICompilation.gmk
+ make/common/support/ListPathsSafely-post-compress.incl
+ make/common/support/ListPathsSafely-pre-compress.incl
+ make/common/support/ListPathsSafely-uncompress.sed
+ make/common/support/unicode2x.sed
- make/corba-rules.gmk
- make/deploy-rules.gmk
+ make/devkit/Makefile
+ make/devkit/Tools.gmk
- make/hotspot-rules.gmk
- make/install-rules.gmk
- make/jaxp-rules.gmk
- make/jaxws-rules.gmk
- make/jdk-rules.gmk
- make/jprt.gmk
- make/langtools-rules.gmk
- make/nashorn-rules.gmk
- make/sanity-rules.gmk
- make/scripts/fixpath.pl
- make/scripts/vsvars.sh
- make/sponsors-rules.gmk

Changeset: 9937f406e27e
Author:    alanb
Date:      2013-11-19 14:11 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/9937f406e27e

8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests
Reviewed-by: dholmes, sla, tbell

! make/jprt.properties
! test/Makefile

Changeset: 24847bd96465
Author:    lana
Date:      2013-11-25 09:27 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/24847bd96465

Merge


Changeset: 9e90215673be
Author:    lana
Date:      2013-12-03 10:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/9e90215673be

Merge



From anton.litvinov at oracle.com  Wed Dec  4 00:31:51 2013
From: anton.litvinov at oracle.com (anton.litvinov at oracle.com)
Date: Wed, 04 Dec 2013 08:31:51 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 8025775: JNI warnings in TryXShmAttach
Message-ID: <20131204083229.3139562A4A@hg.openjdk.java.net>

Changeset: 233cc95e1a0a
Author:    alitvinov
Date:      2013-12-04 12:29 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/233cc95e1a0a

8025775: JNI warnings in TryXShmAttach
Reviewed-by: art, anthony

! src/solaris/classes/sun/awt/X11/XConstants.java
! src/solaris/classes/sun/awt/X11/XErrorHandler.java
! src/solaris/classes/sun/awt/X11/XErrorHandlerUtil.java
! src/solaris/native/sun/awt/awt_GraphicsEnv.c
! src/solaris/native/sun/awt/awt_GraphicsEnv.h
! src/solaris/native/sun/awt/awt_util.c
! src/solaris/native/sun/awt/awt_util.h
! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c
! src/solaris/native/sun/java2d/x11/X11SurfaceData.c
! src/solaris/native/sun/xawt/XlibWrapper.c


From lana.steuck at oracle.com  Tue Dec  3 17:18:12 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Dec 2013 01:18:12 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 70 new changesets
Message-ID: <20131204013337.F021162A21@hg.openjdk.java.net>

Changeset: 6c1f5c7baab0
Author:    ksrini
Date:      2013-11-21 12:01 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6c1f5c7baab0

8028645: [infra] purge applet demos from the Solaris distros
Reviewed-by: erikj

! makefiles/CompileDemos.gmk

Changeset: 66c98bd811f1
Author:    rgallard
Date:      2013-11-25 20:19 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/66c98bd811f1

8029043: Update nroff files for JDK 8
Reviewed-by: weijun, alanb, ksrini, naoto

! src/bsd/doc/man/appletviewer.1
! src/bsd/doc/man/extcheck.1
! src/bsd/doc/man/idlj.1
! src/bsd/doc/man/jar.1
! src/bsd/doc/man/jarsigner.1
! src/bsd/doc/man/java.1
! src/bsd/doc/man/javac.1
! src/bsd/doc/man/javadoc.1
! src/bsd/doc/man/javah.1
! src/bsd/doc/man/javap.1
+ src/bsd/doc/man/jcmd.1
! src/bsd/doc/man/jconsole.1
! src/bsd/doc/man/jdb.1
+ src/bsd/doc/man/jdeps.1
! src/bsd/doc/man/jhat.1
! src/bsd/doc/man/jinfo.1
+ src/bsd/doc/man/jjs.1
! src/bsd/doc/man/jmap.1
! src/bsd/doc/man/jps.1
! src/bsd/doc/man/jrunscript.1
! src/bsd/doc/man/jsadebugd.1
! src/bsd/doc/man/jstack.1
! src/bsd/doc/man/jstat.1
! src/bsd/doc/man/jstatd.1
! src/bsd/doc/man/keytool.1
! src/bsd/doc/man/native2ascii.1
! src/bsd/doc/man/orbd.1
! src/bsd/doc/man/pack200.1
! src/bsd/doc/man/policytool.1
! src/bsd/doc/man/rmic.1
! src/bsd/doc/man/rmid.1
! src/bsd/doc/man/rmiregistry.1
! src/bsd/doc/man/schemagen.1
! src/bsd/doc/man/serialver.1
! src/bsd/doc/man/servertool.1
! src/bsd/doc/man/tnameserv.1
! src/bsd/doc/man/unpack200.1
! src/bsd/doc/man/wsgen.1
! src/bsd/doc/man/wsimport.1
! src/bsd/doc/man/xjc.1
! src/linux/doc/man/appletviewer.1
! src/linux/doc/man/extcheck.1
! src/linux/doc/man/idlj.1
! src/linux/doc/man/jar.1
! src/linux/doc/man/jarsigner.1
! src/linux/doc/man/java.1
! src/linux/doc/man/javac.1
! src/linux/doc/man/javadoc.1
! src/linux/doc/man/javah.1
! src/linux/doc/man/javap.1
! src/linux/doc/man/jcmd.1
! src/linux/doc/man/jconsole.1
! src/linux/doc/man/jdb.1
+ src/linux/doc/man/jdeps.1
! src/linux/doc/man/jhat.1
! src/linux/doc/man/jinfo.1
+ src/linux/doc/man/jjs.1
! src/linux/doc/man/jmap.1
! src/linux/doc/man/jps.1
! src/linux/doc/man/jrunscript.1
! src/linux/doc/man/jsadebugd.1
! src/linux/doc/man/jstack.1
! src/linux/doc/man/jstat.1
! src/linux/doc/man/jstatd.1
! src/linux/doc/man/keytool.1
! src/linux/doc/man/native2ascii.1
! src/linux/doc/man/orbd.1
! src/linux/doc/man/pack200.1
! src/linux/doc/man/policytool.1
! src/linux/doc/man/rmic.1
! src/linux/doc/man/rmid.1
! src/linux/doc/man/rmiregistry.1
! src/linux/doc/man/schemagen.1
! src/linux/doc/man/serialver.1
! src/linux/doc/man/servertool.1
! src/linux/doc/man/tnameserv.1
! src/linux/doc/man/unpack200.1
! src/linux/doc/man/wsgen.1
! src/linux/doc/man/wsimport.1
! src/linux/doc/man/xjc.1
! src/solaris/doc/sun/man/man1/appletviewer.1
! src/solaris/doc/sun/man/man1/extcheck.1
! src/solaris/doc/sun/man/man1/idlj.1
! src/solaris/doc/sun/man/man1/jar.1
! src/solaris/doc/sun/man/man1/jarsigner.1
! src/solaris/doc/sun/man/man1/java.1
! src/solaris/doc/sun/man/man1/javac.1
! src/solaris/doc/sun/man/man1/javadoc.1
! src/solaris/doc/sun/man/man1/javah.1
! src/solaris/doc/sun/man/man1/javap.1
! src/solaris/doc/sun/man/man1/jcmd.1
! src/solaris/doc/sun/man/man1/jconsole.1
! src/solaris/doc/sun/man/man1/jdb.1
+ src/solaris/doc/sun/man/man1/jdeps.1
! src/solaris/doc/sun/man/man1/jhat.1
! src/solaris/doc/sun/man/man1/jinfo.1
+ src/solaris/doc/sun/man/man1/jjs.1
! src/solaris/doc/sun/man/man1/jmap.1
! src/solaris/doc/sun/man/man1/jps.1
! src/solaris/doc/sun/man/man1/jrunscript.1
! src/solaris/doc/sun/man/man1/jsadebugd.1
! src/solaris/doc/sun/man/man1/jstack.1
! src/solaris/doc/sun/man/man1/jstat.1
! src/solaris/doc/sun/man/man1/jstatd.1
! src/solaris/doc/sun/man/man1/keytool.1
! src/solaris/doc/sun/man/man1/native2ascii.1
! src/solaris/doc/sun/man/man1/orbd.1
! src/solaris/doc/sun/man/man1/pack200.1
! src/solaris/doc/sun/man/man1/policytool.1
! src/solaris/doc/sun/man/man1/rmic.1
! src/solaris/doc/sun/man/man1/rmid.1
! src/solaris/doc/sun/man/man1/rmiregistry.1
! src/solaris/doc/sun/man/man1/schemagen.1
! src/solaris/doc/sun/man/man1/serialver.1
! src/solaris/doc/sun/man/man1/servertool.1
! src/solaris/doc/sun/man/man1/tnameserv.1
! src/solaris/doc/sun/man/man1/unpack200.1
! src/solaris/doc/sun/man/man1/wsgen.1
! src/solaris/doc/sun/man/man1/wsimport.1
! src/solaris/doc/sun/man/man1/xjc.1

Changeset: 28ca338366ff
Author:    rgallard
Date:      2013-11-25 20:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/28ca338366ff

Merge


Changeset: a1c49f8881ae
Author:    cl
Date:      2013-11-28 08:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a1c49f8881ae

Added tag jdk8-b118 for changeset 28ca338366ff

! .hgtags

Changeset: e5eb65043d31
Author:    prr
Date:      2013-11-19 10:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e5eb65043d31

8027541: ully transparent jframe becomes black.
Reviewed-by: bae, ceisserer

! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java

Changeset: 4592f0985e78
Author:    yan
Date:      2013-11-20 12:23 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/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

Changeset: c7b0f01e2268
Author:    ceisserer
Date:      2013-11-25 09:38 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/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

Changeset: f8104b663f58
Author:    lana
Date:      2013-11-25 12:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/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

Changeset: 723bcc68738b
Author:    jgodinez
Date:      2013-11-26 10:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/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

Changeset: 76171168e894
Author:    bae
Date:      2013-11-27 15:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/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

Changeset: d98e37b8209d
Author:    lana
Date:      2013-11-27 10:42 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d98e37b8209d

Merge


Changeset: 2bcdf1e05642
Author:    lana
Date:      2013-11-27 10:44 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2bcdf1e05642

Merge


Changeset: 64a492bc0ba7
Author:    sla
Date:      2013-11-14 12:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/64a492bc0ba7

8023138: [TEST_BUG] java/lang/instrument/PremainClass/NoPremainAgent.sh fails intermittently
Summary: Port tests for java/lang/instrument/PremainClass from script to java
Reviewed-by: sla
Contributed-by: mattias.tobiasson at oracle.com

- test/java/lang/instrument/PremainClass/NoPremainAgent.sh
+ test/java/lang/instrument/PremainClass/NoPremainAgentTest.java
+ test/java/lang/instrument/PremainClass/PremainClassTest.java
- test/java/lang/instrument/PremainClass/PremainClassTest.sh
- test/java/lang/instrument/PremainClass/ZeroArgPremainAgent.sh
+ test/java/lang/instrument/PremainClass/ZeroArgPremainAgentTest.java
! test/lib/testlibrary/jdk/testlibrary/Utils.java

Changeset: 19ff80da8283
Author:    yan
Date:      2013-11-18 17:00 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/19ff80da8283

8028049: Tidy warnings cleanup for packages java.nio/java.io
Reviewed-by: alanb, darcy
Contributed-by: Sergey Lugovoy <sergey.lugovoy at oracle.com>

! src/share/classes/java/io/EOFException.java
! src/share/classes/java/io/FilePermission.java
! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java
! src/share/classes/java/nio/channels/AsynchronousFileChannel.java
! src/share/classes/java/nio/channels/FileChannel.java
! src/share/classes/java/nio/charset/Charset.java
! src/share/classes/java/nio/file/FileSystem.java
! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/nio/package.html

Changeset: d842131d12d8
Author:    jbachorik
Date:      2013-11-18 15:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d842131d12d8

8027163: sun/management/jmxremote/bootstrap/CustomLauncherTest.java should be updated for jdk8 removal of solaris-32bit support
Reviewed-by: sla

! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java
! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java
! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java
+ test/sun/management/jmxremote/bootstrap/solaris-amd64/launcher
- test/sun/management/jmxremote/bootstrap/solaris-i586/launcher
- test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher
+ test/sun/management/jmxremote/bootstrap/solaris-sparcv9/launcher

Changeset: 0298ebbaf3b8
Author:    jbachorik
Date:      2013-11-18 16:20 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0298ebbaf3b8

8028433: [TESTBUG] add -XX:+UsePerfData to some sun.management tests
Reviewed-by: sla, egahlin

! test/sun/management/HotspotClassLoadingMBean/GetClassLoadingTime.java
! test/sun/management/HotspotClassLoadingMBean/GetInitializedClassCount.java
! test/sun/management/HotspotClassLoadingMBean/GetLoadedClassSize.java
! test/sun/management/HotspotClassLoadingMBean/GetMethodDataSize.java
! test/sun/management/HotspotClassLoadingMBean/GetUnloadedClassSize.java
! test/sun/management/HotspotRuntimeMBean/GetSafepointCount.java

Changeset: c2b56fe61626
Author:    kizune
Date:      2013-11-18 20:22 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c2b56fe61626

8028197: tools/launcher/DiacriticTest.java failed on MacOSX: Input length = 1
Reviewed-by: ksrini

! test/tools/launcher/DiacriticTest.java

Changeset: 4be14673b9bf
Author:    ihse
Date:      2013-11-14 11:19 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4be14673b9bf

8027566: Remove the old build system
Reviewed-by: erikj, tbell

+ make/BuildJdk.gmk
+ make/Bundles.gmk
+ make/CompileDemos.gmk
+ make/CompileJavaClasses.gmk
+ make/CompileLaunchers.gmk
+ make/CompileNativeLibraries.gmk
+ make/CopyFiles.gmk
+ make/CopyIntoClasses.gmk
+ make/CopySamples.gmk
+ make/CreateJars.gmk
+ make/CreateSecurityJars.gmk
+ make/GenerateClasses.gmk
+ make/GenerateData.gmk
+ make/GenerateSources.gmk
+ make/Images.gmk
+ make/Import.gmk
! make/Makefile
- make/PatchList.solaris
+ make/ProfileNames.gmk
+ make/Profiles.gmk
+ make/Setup.gmk
+ make/SignJars.gmk
+ make/Tools.gmk
- make/altclasses/Makefile
- make/apple/Makefile
- make/apple/applescript/Makefile
- make/bridge/AccessBridgeJava/Makefile
- make/bridge/JAWTAccessBridge/Files_cpp.gmk
- make/bridge/JAWTAccessBridge/Makefile
- make/bridge/Jabswitch/Makefile
- make/bridge/Jaccess/Makefile
- make/bridge/JavaAccessBridge/Files_cpp.gmk
- make/bridge/JavaAccessBridge/Makefile
- make/bridge/Makefile
- make/bridge/WindowsAccessBridge/Files_cpp.gmk
- make/bridge/WindowsAccessBridge/Makefile
- make/com/Makefile
- make/com/apple/Makefile
- make/com/apple/osx/Makefile
- make/com/apple/osxui/Makefile
- make/com/oracle/Makefile
- make/com/oracle/jfr/Makefile
- make/com/oracle/net/Makefile
- make/com/oracle/nio/Makefile
- make/com/oracle/security/ucrypto/FILES_c.gmk
- make/com/oracle/security/ucrypto/Makefile
- make/com/oracle/security/ucrypto/mapfile-vers
- make/com/oracle/util/Makefile
- make/com/sun/Makefile
- make/com/sun/crypto/provider/Makefile
- make/com/sun/demo/Makefile
- make/com/sun/demo/jvmti/Makefile
- make/com/sun/demo/jvmti/hprof/Makefile
- make/com/sun/image/Makefile
- make/com/sun/jarsigner/Makefile
- make/com/sun/java/Makefile
- make/com/sun/java/browser/Makefile
- make/com/sun/java/browser/dom/Makefile
- make/com/sun/java/browser/net/Makefile
- make/com/sun/java/pack/FILES_cpp.gmk
- make/com/sun/java/pack/Makefile
- make/com/sun/java/pack/mapfile-vers
- make/com/sun/java/pack/mapfile-vers-unpack200
- make/com/sun/java/pack/prop/Makefile
- make/com/sun/jmx/Makefile
- make/com/sun/jmx/snmp/Makefile
- make/com/sun/jndi/Makefile
- make/com/sun/jndi/cosnaming/Makefile
- make/com/sun/jndi/dns/Makefile
- make/com/sun/jndi/ldap/Makefile
- make/com/sun/jndi/rmi/Makefile
- make/com/sun/jndi/rmi/registry/Makefile
- make/com/sun/jndi/toolkit/Makefile
- make/com/sun/net/httpserver/Makefile
- make/com/sun/net/ssl/Makefile
- make/com/sun/nio/Makefile
- make/com/sun/nio/sctp/Exportedfiles.gmk
- make/com/sun/nio/sctp/FILES_c.gmk
- make/com/sun/nio/sctp/FILES_java.gmk
- make/com/sun/nio/sctp/Makefile
- make/com/sun/nio/sctp/mapfile-vers
- make/com/sun/org/Makefile
- make/com/sun/org/apache/Makefile
- make/com/sun/org/apache/xml/Makefile
- make/com/sun/rowset/Makefile
- make/com/sun/security/Makefile
- make/com/sun/security/auth/FILES_java.gmk
- make/com/sun/security/auth/Makefile
- make/com/sun/security/auth/module/FILES_c_solaris.gmk
- make/com/sun/security/auth/module/FILES_c_unix.gmk
- make/com/sun/security/auth/module/FILES_c_windows.gmk
- make/com/sun/security/auth/module/FILES_export_solaris.gmk
- make/com/sun/security/auth/module/FILES_export_unix.gmk
- make/com/sun/security/auth/module/FILES_export_windows.gmk
- make/com/sun/security/auth/module/FILES_java.gmk
- make/com/sun/security/auth/module/Makefile
- make/com/sun/security/auth/module/mapfile-vers
- make/com/sun/security/jgss/Makefile
- make/com/sun/security/ntlm/Makefile
- make/com/sun/security/sasl/Makefile
- make/com/sun/sql/FILES_java.gmk
- make/com/sun/sql/Makefile
- make/com/sun/tools/Makefile
- make/com/sun/tools/attach/Exportedfiles.gmk
- make/com/sun/tools/attach/FILES_c.gmk
- make/com/sun/tools/attach/FILES_java.gmk
- make/com/sun/tools/attach/Makefile
- make/com/sun/tools/attach/mapfile-bsd
- make/com/sun/tools/attach/mapfile-linux
- make/com/sun/tools/attach/mapfile-solaris
- make/com/sun/tracing/Makefile
- make/com/sun/tracing/dtrace/Makefile
- make/common/BuildToolJar.gmk
- make/common/CancelImplicits.gmk
- make/common/Classes.gmk
- make/common/Cscope.gmk
- make/common/Defs-linux.gmk
- make/common/Defs-macosx.gmk
- make/common/Defs-solaris.gmk
- make/common/Defs-windows.gmk
- make/common/Defs.gmk
- make/common/Demo.gmk
- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/Program.gmk
- make/common/Release-macosx.gmk
- make/common/Release.gmk
- make/common/Rules.gmk
- make/common/Sanity.gmk
- make/common/Subdirs.gmk
- make/common/internal/Defs-corba.gmk
- make/common/internal/Defs-jaxp.gmk
- make/common/internal/Defs-jaxws.gmk
- make/common/internal/Defs-langtools.gmk
- make/common/internal/ImportComponents.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/internal/Resources.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-llvm.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Defs-control.gmk
- make/common/shared/Defs-java.gmk
- make/common/shared/Defs-javadoc.gmk
- make/common/shared/Defs-linux.gmk
- make/common/shared/Defs-macosx.gmk
- make/common/shared/Defs-solaris.gmk
- make/common/shared/Defs-utils.gmk
- make/common/shared/Defs-versions.gmk
- make/common/shared/Defs-windows.gmk
- make/common/shared/Defs.gmk
- make/common/shared/Platform.gmk
- make/common/shared/PrivateDefs.gmk-example
- make/common/shared/Sanity-Settings.gmk
- make/common/shared/Sanity.gmk
+ make/data/characterdata/CharacterData00.java.template
+ make/data/characterdata/CharacterData01.java.template
+ make/data/characterdata/CharacterData02.java.template
+ make/data/characterdata/CharacterData0E.java.template
+ make/data/characterdata/CharacterDataLatin1.java.template
+ make/data/characterdata/CharacterDataPrivateUse.java.template
+ make/data/characterdata/CharacterDataUndefined.java.template
+ make/data/charsetmapping/Big5.map
+ make/data/charsetmapping/Big5.nr
+ make/data/charsetmapping/DoubleByte-X.java.template
+ make/data/charsetmapping/EUC_CN.map
+ make/data/charsetmapping/EUC_KR.map
+ make/data/charsetmapping/GBK.map
+ make/data/charsetmapping/HKSCS2001.c2b
+ make/data/charsetmapping/HKSCS2001.map
+ make/data/charsetmapping/HKSCS2008.c2b
+ make/data/charsetmapping/HKSCS2008.map
+ make/data/charsetmapping/HKSCS_XP.c2b
+ make/data/charsetmapping/HKSCS_XP.map
+ make/data/charsetmapping/IBM037.c2b
+ make/data/charsetmapping/IBM037.map
+ make/data/charsetmapping/IBM037.nr
+ make/data/charsetmapping/IBM1006.map
+ make/data/charsetmapping/IBM1025.c2b
+ make/data/charsetmapping/IBM1025.map
+ make/data/charsetmapping/IBM1025.nr
+ make/data/charsetmapping/IBM1026.c2b
+ make/data/charsetmapping/IBM1026.map
+ make/data/charsetmapping/IBM1026.nr
+ make/data/charsetmapping/IBM1046.map
+ make/data/charsetmapping/IBM1047.map
+ make/data/charsetmapping/IBM1097.map
+ make/data/charsetmapping/IBM1098.map
+ make/data/charsetmapping/IBM1112.c2b
+ make/data/charsetmapping/IBM1112.map
+ make/data/charsetmapping/IBM1112.nr
+ make/data/charsetmapping/IBM1122.c2b
+ make/data/charsetmapping/IBM1122.map
+ make/data/charsetmapping/IBM1122.nr
+ make/data/charsetmapping/IBM1123.c2b
+ make/data/charsetmapping/IBM1123.map
+ make/data/charsetmapping/IBM1123.nr
+ make/data/charsetmapping/IBM1124.map
+ make/data/charsetmapping/IBM1140.c2b
+ make/data/charsetmapping/IBM1140.map
+ make/data/charsetmapping/IBM1141.c2b
+ make/data/charsetmapping/IBM1141.map
+ make/data/charsetmapping/IBM1142.c2b
+ make/data/charsetmapping/IBM1142.map
+ make/data/charsetmapping/IBM1143.c2b
+ make/data/charsetmapping/IBM1143.map
+ make/data/charsetmapping/IBM1144.c2b
+ make/data/charsetmapping/IBM1144.map
+ make/data/charsetmapping/IBM1145.c2b
+ make/data/charsetmapping/IBM1145.map
+ make/data/charsetmapping/IBM1146.c2b
+ make/data/charsetmapping/IBM1146.map
+ make/data/charsetmapping/IBM1147.c2b
+ make/data/charsetmapping/IBM1147.map
+ make/data/charsetmapping/IBM1148.c2b
+ make/data/charsetmapping/IBM1148.map
+ make/data/charsetmapping/IBM1149.c2b
+ make/data/charsetmapping/IBM1149.map
+ make/data/charsetmapping/IBM1364.c2b
+ make/data/charsetmapping/IBM1364.map
+ make/data/charsetmapping/IBM1381.c2b
+ make/data/charsetmapping/IBM1381.map
+ make/data/charsetmapping/IBM1383.c2b
+ make/data/charsetmapping/IBM1383.map
+ make/data/charsetmapping/IBM1383.nr
+ make/data/charsetmapping/IBM273.c2b
+ make/data/charsetmapping/IBM273.map
+ make/data/charsetmapping/IBM273.nr
+ make/data/charsetmapping/IBM277.c2b
+ make/data/charsetmapping/IBM277.map
+ make/data/charsetmapping/IBM277.nr
+ make/data/charsetmapping/IBM278.c2b
+ make/data/charsetmapping/IBM278.map
+ make/data/charsetmapping/IBM278.nr
+ make/data/charsetmapping/IBM280.c2b
+ make/data/charsetmapping/IBM280.map
+ make/data/charsetmapping/IBM280.nr
+ make/data/charsetmapping/IBM284.c2b
+ make/data/charsetmapping/IBM284.map
+ make/data/charsetmapping/IBM284.nr
+ make/data/charsetmapping/IBM285.c2b
+ make/data/charsetmapping/IBM285.map
+ make/data/charsetmapping/IBM285.nr
+ make/data/charsetmapping/IBM290.c2b
+ make/data/charsetmapping/IBM290.map
+ make/data/charsetmapping/IBM297.c2b
+ make/data/charsetmapping/IBM297.map
+ make/data/charsetmapping/IBM297.nr
+ make/data/charsetmapping/IBM300.c2b
+ make/data/charsetmapping/IBM300.map
+ make/data/charsetmapping/IBM420.c2b
+ make/data/charsetmapping/IBM420.map
+ make/data/charsetmapping/IBM420.nr
+ make/data/charsetmapping/IBM424.c2b
+ make/data/charsetmapping/IBM424.map
+ make/data/charsetmapping/IBM424.nr
+ make/data/charsetmapping/IBM437.map
+ make/data/charsetmapping/IBM500.c2b
+ make/data/charsetmapping/IBM500.map
+ make/data/charsetmapping/IBM500.nr
+ make/data/charsetmapping/IBM737.map
+ make/data/charsetmapping/IBM775.map
+ make/data/charsetmapping/IBM833.c2b
+ make/data/charsetmapping/IBM833.map
+ make/data/charsetmapping/IBM838.c2b
+ make/data/charsetmapping/IBM838.map
+ make/data/charsetmapping/IBM838.nr
+ make/data/charsetmapping/IBM850.map
+ make/data/charsetmapping/IBM852.map
+ make/data/charsetmapping/IBM855.map
+ make/data/charsetmapping/IBM856.map
+ make/data/charsetmapping/IBM857.map
+ make/data/charsetmapping/IBM858.map
+ make/data/charsetmapping/IBM860.map
+ make/data/charsetmapping/IBM861.map
+ make/data/charsetmapping/IBM862.map
+ make/data/charsetmapping/IBM863.map
+ make/data/charsetmapping/IBM864.map
+ make/data/charsetmapping/IBM865.map
+ make/data/charsetmapping/IBM866.map
+ make/data/charsetmapping/IBM868.map
+ make/data/charsetmapping/IBM869.map
+ make/data/charsetmapping/IBM870.c2b
+ make/data/charsetmapping/IBM870.map
+ make/data/charsetmapping/IBM870.nr
+ make/data/charsetmapping/IBM871.c2b
+ make/data/charsetmapping/IBM871.map
+ make/data/charsetmapping/IBM871.nr
+ make/data/charsetmapping/IBM874.map
+ make/data/charsetmapping/IBM874.nr
+ make/data/charsetmapping/IBM875.c2b
+ make/data/charsetmapping/IBM875.map
+ make/data/charsetmapping/IBM875.nr
+ make/data/charsetmapping/IBM918.c2b
+ make/data/charsetmapping/IBM918.map
+ make/data/charsetmapping/IBM918.nr
+ make/data/charsetmapping/IBM921.map
+ make/data/charsetmapping/IBM922.map
+ make/data/charsetmapping/IBM930.c2b
+ make/data/charsetmapping/IBM930.map
+ make/data/charsetmapping/IBM930.nr
+ make/data/charsetmapping/IBM933.c2b
+ make/data/charsetmapping/IBM933.map
+ make/data/charsetmapping/IBM935.c2b
+ make/data/charsetmapping/IBM935.map
+ make/data/charsetmapping/IBM935.nr
+ make/data/charsetmapping/IBM937.c2b
+ make/data/charsetmapping/IBM937.map
+ make/data/charsetmapping/IBM937.nr
+ make/data/charsetmapping/IBM939.c2b
+ make/data/charsetmapping/IBM939.map
+ make/data/charsetmapping/IBM939.nr
+ make/data/charsetmapping/IBM942.c2b
+ make/data/charsetmapping/IBM942.map
+ make/data/charsetmapping/IBM943.map
+ make/data/charsetmapping/IBM943.nr
+ make/data/charsetmapping/IBM948.c2b
+ make/data/charsetmapping/IBM948.map
+ make/data/charsetmapping/IBM949.map
+ make/data/charsetmapping/IBM950.c2b
+ make/data/charsetmapping/IBM950.map
+ make/data/charsetmapping/IBM970.c2b
+ make/data/charsetmapping/IBM970.map
+ make/data/charsetmapping/ISO_8859_11.map
+ make/data/charsetmapping/ISO_8859_13.map
+ make/data/charsetmapping/ISO_8859_15.map
+ make/data/charsetmapping/ISO_8859_2.map
+ make/data/charsetmapping/ISO_8859_3.map
+ make/data/charsetmapping/ISO_8859_4.map
+ make/data/charsetmapping/ISO_8859_5.map
+ make/data/charsetmapping/ISO_8859_6.map
+ make/data/charsetmapping/ISO_8859_7.map
+ make/data/charsetmapping/ISO_8859_8.map
+ make/data/charsetmapping/ISO_8859_9.map
+ make/data/charsetmapping/JIS_X_0201.c2b
+ make/data/charsetmapping/JIS_X_0201.map
+ make/data/charsetmapping/JIS_X_0208.map
+ make/data/charsetmapping/JIS_X_0208_MS5022X.c2b
+ make/data/charsetmapping/JIS_X_0208_MS5022X.map
+ make/data/charsetmapping/JIS_X_0208_MS932.map
+ make/data/charsetmapping/JIS_X_0208_MS932.nr
+ make/data/charsetmapping/JIS_X_0208_Solaris.map
+ make/data/charsetmapping/JIS_X_0208_Solaris.nr
+ make/data/charsetmapping/JIS_X_0212.map
+ make/data/charsetmapping/JIS_X_0212_MS5022X.map
+ make/data/charsetmapping/JIS_X_0212_Solaris.map
+ make/data/charsetmapping/JIS_X_0212_Solaris.nr
+ make/data/charsetmapping/Johab.map
+ make/data/charsetmapping/KOI8_R.map
+ make/data/charsetmapping/KOI8_U.map
+ make/data/charsetmapping/MS1250.map
+ make/data/charsetmapping/MS1251.map
+ make/data/charsetmapping/MS1252.map
+ make/data/charsetmapping/MS1253.map
+ make/data/charsetmapping/MS1254.map
+ make/data/charsetmapping/MS1255.map
+ make/data/charsetmapping/MS1256.map
+ make/data/charsetmapping/MS1257.map
+ make/data/charsetmapping/MS1258.map
+ make/data/charsetmapping/MS874.map
+ make/data/charsetmapping/MS932.c2b
+ make/data/charsetmapping/MS932.map
+ make/data/charsetmapping/MS932.nr
+ make/data/charsetmapping/MS936.map
+ make/data/charsetmapping/MS949.map
+ make/data/charsetmapping/MS950.map
+ make/data/charsetmapping/MS950.nr
+ make/data/charsetmapping/MacArabic.map
+ make/data/charsetmapping/MacCentralEurope.map
+ make/data/charsetmapping/MacCroatian.map
+ make/data/charsetmapping/MacCyrillic.map
+ make/data/charsetmapping/MacDingbat.map
+ make/data/charsetmapping/MacGreek.map
+ make/data/charsetmapping/MacHebrew.map
+ make/data/charsetmapping/MacIceland.map
+ make/data/charsetmapping/MacRoman.map
+ make/data/charsetmapping/MacRomania.map
+ make/data/charsetmapping/MacSymbol.map
+ make/data/charsetmapping/MacThai.map
+ make/data/charsetmapping/MacTurkish.map
+ make/data/charsetmapping/MacUkraine.map
+ make/data/charsetmapping/PCK.c2b
+ make/data/charsetmapping/PCK.map
+ make/data/charsetmapping/PCK.nr
+ make/data/charsetmapping/SJIS.c2b
+ make/data/charsetmapping/SJIS.map
+ make/data/charsetmapping/SingleByte-X.java.template
+ make/data/charsetmapping/TIS_620.map
+ make/data/charsetmapping/dbcs
+ make/data/charsetmapping/euc_tw.map
+ make/data/charsetmapping/extsbcs
+ make/data/charsetmapping/sbcs
+ make/data/charsetmapping/sjis0213.map
+ make/data/checkdeps/refs.allowed
+ make/data/classlist/classlist.linux
+ make/data/classlist/classlist.macosx
+ make/data/classlist/classlist.solaris
+ make/data/classlist/classlist.windows
+ make/data/cryptopolicy/limited/LIMITED
+ make/data/cryptopolicy/limited/default_local.policy
+ make/data/cryptopolicy/limited/exempt_local.policy
+ make/data/cryptopolicy/unlimited/UNLIMITED
+ make/data/cryptopolicy/unlimited/default_US_export.policy
+ make/data/cryptopolicy/unlimited/default_local.policy
+ make/data/dtdbuilder/HTMLlat1.sgml
+ make/data/dtdbuilder/HTMLspecial.sgml
+ make/data/dtdbuilder/HTMLsymbol.sgml
+ make/data/dtdbuilder/html32.dtd
+ make/data/dtdbuilder/public.map
+ make/data/jdwp/jdwp.spec
+ make/data/mainmanifest/manifest.mf
+ make/data/swingbeaninfo/SwingBeanInfo.template
+ make/data/swingbeaninfo/images/AbstractButtonColor16.gif
+ make/data/swingbeaninfo/images/BorderColor16.gif
+ make/data/swingbeaninfo/images/BoxColor16.gif
+ make/data/swingbeaninfo/images/BoxColor32.gif
+ make/data/swingbeaninfo/images/BoxMono16.gif
+ make/data/swingbeaninfo/images/BoxMono32.gif
+ make/data/swingbeaninfo/images/JAppletColor16.gif
+ make/data/swingbeaninfo/images/JAppletColor32.gif
+ make/data/swingbeaninfo/images/JAppletMono16.gif
+ make/data/swingbeaninfo/images/JAppletMono32.gif
+ make/data/swingbeaninfo/images/JButtonColor16.gif
+ make/data/swingbeaninfo/images/JButtonColor32.gif
+ make/data/swingbeaninfo/images/JButtonMono16.gif
+ make/data/swingbeaninfo/images/JButtonMono32.gif
+ make/data/swingbeaninfo/images/JCheckBoxColor16.gif
+ make/data/swingbeaninfo/images/JCheckBoxColor32.gif
+ make/data/swingbeaninfo/images/JCheckBoxMenuItemColor16.gif
+ make/data/swingbeaninfo/images/JCheckBoxMenuItemColor32.gif
+ make/data/swingbeaninfo/images/JCheckBoxMenuItemMono16.gif
+ make/data/swingbeaninfo/images/JCheckBoxMenuItemMono32.gif
+ make/data/swingbeaninfo/images/JCheckBoxMono16.gif
+ make/data/swingbeaninfo/images/JCheckBoxMono32.gif
+ make/data/swingbeaninfo/images/JColorChooserColor16.gif
+ make/data/swingbeaninfo/images/JColorChooserColor32.gif
+ make/data/swingbeaninfo/images/JColorChooserMono16.gif
+ make/data/swingbeaninfo/images/JColorChooserMono32.gif
+ make/data/swingbeaninfo/images/JComboBoxColor16.gif
+ make/data/swingbeaninfo/images/JComboBoxColor32.gif
+ make/data/swingbeaninfo/images/JComboBoxMono16.gif
+ make/data/swingbeaninfo/images/JComboBoxMono32.gif
+ make/data/swingbeaninfo/images/JComponentColor16.gif
+ make/data/swingbeaninfo/images/JDesktopPaneColor16.gif
+ make/data/swingbeaninfo/images/JDesktopPaneColor32.gif
+ make/data/swingbeaninfo/images/JDesktopPaneMono16.gif
+ make/data/swingbeaninfo/images/JDesktopPaneMono32.gif
+ make/data/swingbeaninfo/images/JDialogColor16.gif
+ make/data/swingbeaninfo/images/JDialogColor32.gif
+ make/data/swingbeaninfo/images/JDialogMono16.gif
+ make/data/swingbeaninfo/images/JDialogMono32.gif
+ make/data/swingbeaninfo/images/JEditorPaneColor16.gif
+ make/data/swingbeaninfo/images/JEditorPaneColor32.gif
+ make/data/swingbeaninfo/images/JEditorPaneMono16.gif
+ make/data/swingbeaninfo/images/JEditorPaneMono32.gif
+ make/data/swingbeaninfo/images/JFileChooserColor16.gif
+ make/data/swingbeaninfo/images/JFileChooserColor32.gif
+ make/data/swingbeaninfo/images/JFileChooserMono16.gif
+ make/data/swingbeaninfo/images/JFileChooserMono32.gif
+ make/data/swingbeaninfo/images/JFormattedTextFieldColor16.gif
+ make/data/swingbeaninfo/images/JFormattedTextFieldColor32.gif
+ make/data/swingbeaninfo/images/JFormattedTextFieldMono16.gif
+ make/data/swingbeaninfo/images/JFormattedTextFieldMono32.gif
+ make/data/swingbeaninfo/images/JFrameColor16.gif
+ make/data/swingbeaninfo/images/JFrameColor32.gif
+ make/data/swingbeaninfo/images/JFrameMono16.gif
+ make/data/swingbeaninfo/images/JFrameMono32.gif
+ make/data/swingbeaninfo/images/JInternalFrameColor16.gif
+ make/data/swingbeaninfo/images/JInternalFrameColor32.gif
+ make/data/swingbeaninfo/images/JInternalFrameMono16.gif
+ make/data/swingbeaninfo/images/JInternalFrameMono32.gif
+ make/data/swingbeaninfo/images/JLabelColor16.gif
+ make/data/swingbeaninfo/images/JLabelColor32.gif
+ make/data/swingbeaninfo/images/JLabelMono16.gif
+ make/data/swingbeaninfo/images/JLabelMono32.gif
+ make/data/swingbeaninfo/images/JLayeredPaneColor16.gif
+ make/data/swingbeaninfo/images/JLayeredPaneColor32.gif
+ make/data/swingbeaninfo/images/JLayeredPaneMono16.gif
+ make/data/swingbeaninfo/images/JLayeredPaneMono32.gif
+ make/data/swingbeaninfo/images/JListColor16.gif
+ make/data/swingbeaninfo/images/JListColor32.gif
+ make/data/swingbeaninfo/images/JListMono16.gif
+ make/data/swingbeaninfo/images/JListMono32.gif
+ make/data/swingbeaninfo/images/JMenuBarColor16.gif
+ make/data/swingbeaninfo/images/JMenuBarColor32.gif
+ make/data/swingbeaninfo/images/JMenuBarMono16.gif
+ make/data/swingbeaninfo/images/JMenuBarMono32.gif
+ make/data/swingbeaninfo/images/JMenuColor16.gif
+ make/data/swingbeaninfo/images/JMenuColor32.gif
+ make/data/swingbeaninfo/images/JMenuItemColor16.gif
+ make/data/swingbeaninfo/images/JMenuItemColor32.gif
+ make/data/swingbeaninfo/images/JMenuItemMono16.gif
+ make/data/swingbeaninfo/images/JMenuItemMono32.gif
+ make/data/swingbeaninfo/images/JMenuMono16.gif
+ make/data/swingbeaninfo/images/JMenuMono32.gif
+ make/data/swingbeaninfo/images/JOptionPaneColor16.gif
+ make/data/swingbeaninfo/images/JOptionPaneColor32.gif
+ make/data/swingbeaninfo/images/JOptionPaneMono16.gif
+ make/data/swingbeaninfo/images/JOptionPaneMono32.gif
+ make/data/swingbeaninfo/images/JPanelColor16.gif
+ make/data/swingbeaninfo/images/JPanelColor32.gif
+ make/data/swingbeaninfo/images/JPanelMono16.gif
+ make/data/swingbeaninfo/images/JPanelMono32.gif
+ make/data/swingbeaninfo/images/JPasswordFieldColor16.gif
+ make/data/swingbeaninfo/images/JPasswordFieldColor32.gif
+ make/data/swingbeaninfo/images/JPasswordFieldMono16.gif
+ make/data/swingbeaninfo/images/JPasswordFieldMono32.gif
+ make/data/swingbeaninfo/images/JPopupMenuColor16.gif
+ make/data/swingbeaninfo/images/JPopupMenuColor32.gif
+ make/data/swingbeaninfo/images/JPopupMenuMono16.gif
+ make/data/swingbeaninfo/images/JPopupMenuMono32.gif
+ make/data/swingbeaninfo/images/JProgressBarColor16.gif
+ make/data/swingbeaninfo/images/JProgressBarColor32.gif
+ make/data/swingbeaninfo/images/JProgressBarMono16.gif
+ make/data/swingbeaninfo/images/JProgressBarMono32.gif
+ make/data/swingbeaninfo/images/JRadioButtonColor16.gif
+ make/data/swingbeaninfo/images/JRadioButtonColor32.gif
+ make/data/swingbeaninfo/images/JRadioButtonMenuItemColor16.gif
+ make/data/swingbeaninfo/images/JRadioButtonMenuItemColor32.gif
+ make/data/swingbeaninfo/images/JRadioButtonMenuItemMono16.gif
+ make/data/swingbeaninfo/images/JRadioButtonMenuItemMono32.gif
+ make/data/swingbeaninfo/images/JRadioButtonMono16.gif
+ make/data/swingbeaninfo/images/JRadioButtonMono32.gif
+ make/data/swingbeaninfo/images/JRootPaneColor16.gif
+ make/data/swingbeaninfo/images/JRootPaneColor32.gif
+ make/data/swingbeaninfo/images/JRootPaneMono16.gif
+ make/data/swingbeaninfo/images/JRootPaneMono32.gif
+ make/data/swingbeaninfo/images/JScrollBarColor16.gif
+ make/data/swingbeaninfo/images/JScrollBarColor32.gif
+ make/data/swingbeaninfo/images/JScrollBarMono16.gif
+ make/data/swingbeaninfo/images/JScrollBarMono32.gif
+ make/data/swingbeaninfo/images/JScrollPaneColor16.gif
+ make/data/swingbeaninfo/images/JScrollPaneColor32.gif
+ make/data/swingbeaninfo/images/JScrollPaneMono16.gif
+ make/data/swingbeaninfo/images/JScrollPaneMono32.gif
+ make/data/swingbeaninfo/images/JSeparatorColor16.gif
+ make/data/swingbeaninfo/images/JSeparatorColor32.gif
+ make/data/swingbeaninfo/images/JSeparatorMono16.gif
+ make/data/swingbeaninfo/images/JSeparatorMono32.gif
+ make/data/swingbeaninfo/images/JSliderColor16.gif
+ make/data/swingbeaninfo/images/JSliderColor32.gif
+ make/data/swingbeaninfo/images/JSliderMono16.gif
+ make/data/swingbeaninfo/images/JSliderMono32.gif
+ make/data/swingbeaninfo/images/JSpinnerColor16.gif
+ make/data/swingbeaninfo/images/JSpinnerColor32.gif
+ make/data/swingbeaninfo/images/JSpinnerMono16.gif
+ make/data/swingbeaninfo/images/JSpinnerMono32.gif
+ make/data/swingbeaninfo/images/JSplitPaneColor16.gif
+ make/data/swingbeaninfo/images/JSplitPaneColor32.gif
+ make/data/swingbeaninfo/images/JSplitPaneMono16.gif
+ make/data/swingbeaninfo/images/JSplitPaneMono32.gif
+ make/data/swingbeaninfo/images/JTabbedPaneColor16.gif
+ make/data/swingbeaninfo/images/JTabbedPaneColor32.gif
+ make/data/swingbeaninfo/images/JTabbedPaneMono16.gif
+ make/data/swingbeaninfo/images/JTabbedPaneMono32.gif
+ make/data/swingbeaninfo/images/JTableColor16.gif
+ make/data/swingbeaninfo/images/JTableColor32.gif
+ make/data/swingbeaninfo/images/JTableMono16.gif
+ make/data/swingbeaninfo/images/JTableMono32.gif
+ make/data/swingbeaninfo/images/JTextAreaColor16.gif
+ make/data/swingbeaninfo/images/JTextAreaColor32.gif
+ make/data/swingbeaninfo/images/JTextAreaMono16.gif
+ make/data/swingbeaninfo/images/JTextAreaMono32.gif
+ make/data/swingbeaninfo/images/JTextFieldColor16.gif
+ make/data/swingbeaninfo/images/JTextFieldColor32.gif
+ make/data/swingbeaninfo/images/JTextFieldMono16.gif
+ make/data/swingbeaninfo/images/JTextFieldMono32.gif
+ make/data/swingbeaninfo/images/JTextPaneColor16.gif
+ make/data/swingbeaninfo/images/JTextPaneColor32.gif
+ make/data/swingbeaninfo/images/JTextPaneMono16.gif
+ make/data/swingbeaninfo/images/JTextPaneMono32.gif
+ make/data/swingbeaninfo/images/JToggleButtonColor16.gif
+ make/data/swingbeaninfo/images/JToggleButtonColor32.gif
+ make/data/swingbeaninfo/images/JToggleButtonMono16.gif
+ make/data/swingbeaninfo/images/JToggleButtonMono32.gif
+ make/data/swingbeaninfo/images/JToolBarColor16.gif
+ make/data/swingbeaninfo/images/JToolBarColor32.gif
+ make/data/swingbeaninfo/images/JToolBarMono16.gif
+ make/data/swingbeaninfo/images/JToolBarMono32.gif
+ make/data/swingbeaninfo/images/JTreeColor16.gif
+ make/data/swingbeaninfo/images/JTreeColor32.gif
+ make/data/swingbeaninfo/images/JTreeMono16.gif
+ make/data/swingbeaninfo/images/JTreeMono32.gif
+ make/data/swingbeaninfo/images/JViewportColor16.gif
+ make/data/swingbeaninfo/images/JViewportColor32.gif
+ make/data/swingbeaninfo/images/JViewportMono16.gif
+ make/data/swingbeaninfo/images/JViewportMono32.gif
+ make/data/swingbeaninfo/images/JWindowColor16.gif
+ make/data/swingbeaninfo/images/JWindowColor32.gif
+ make/data/swingbeaninfo/images/JWindowMono16.gif
+ make/data/swingbeaninfo/images/JWindowMono32.gif
+ make/data/swingbeaninfo/javax/swing/SwingBeanInfoBase.java
+ make/data/swingbeaninfo/manifest.mf
+ make/data/swingbeaninfo/sun/swing/BeanInfoUtils.java
+ make/data/tzdata/VERSION
+ make/data/tzdata/africa
+ make/data/tzdata/antarctica
+ make/data/tzdata/asia
+ make/data/tzdata/australasia
+ make/data/tzdata/backward
+ make/data/tzdata/etcetera
+ make/data/tzdata/europe
+ make/data/tzdata/factory
+ make/data/tzdata/gmt
+ make/data/tzdata/iso3166.tab
+ make/data/tzdata/jdk11_backward
+ make/data/tzdata/leapseconds
+ make/data/tzdata/northamerica
+ make/data/tzdata/pacificnew
+ make/data/tzdata/solar87
+ make/data/tzdata/solar88
+ make/data/tzdata/solar89
+ make/data/tzdata/southamerica
+ make/data/tzdata/systemv
+ make/data/tzdata/zone.tab
+ make/data/unicodedata/PropList.txt
+ make/data/unicodedata/Scripts.txt
+ make/data/unicodedata/SpecialCasing.txt
+ make/data/unicodedata/UnicodeData.txt
+ make/data/unicodedata/VERSION
- make/docs/CORE_PKGS.gmk
- make/docs/Makefile
- make/docs/NON_CORE_PKGS.gmk
- make/docs/Notes.html
+ make/gendata/GendataBreakIterator.gmk
+ make/gendata/GendataFontConfig.gmk
+ make/gendata/GendataHtml32dtd.gmk
+ make/gendata/GendataTZDB.gmk
+ make/gensrc/GensrcBuffer.gmk
+ make/gensrc/GensrcCLDR.gmk
+ make/gensrc/GensrcCharacterData.gmk
+ make/gensrc/GensrcCharsetCoder.gmk
+ make/gensrc/GensrcCharsetMapping.gmk
+ make/gensrc/GensrcExceptions.gmk
+ make/gensrc/GensrcIcons.gmk
+ make/gensrc/GensrcJDWP.gmk
+ make/gensrc/GensrcJObjC.gmk
+ make/gensrc/GensrcLocaleDataMetaInfo.gmk
+ make/gensrc/GensrcMisc.gmk
+ make/gensrc/GensrcProperties.gmk
+ make/gensrc/GensrcSwing.gmk
+ make/gensrc/GensrcX11Wrappers.gmk
- make/java/Makefile
- make/java/applet/Makefile
- make/java/awt/Makefile
- make/java/beans/Makefile
- make/java/fdlibm/FILES_c.gmk
- make/java/fdlibm/Makefile
- make/java/instrument/Makefile
- make/java/instrument/mapfile-vers
- make/java/invoke/Makefile
- make/java/jar/Makefile
- make/java/java/Exportedfiles.gmk
- make/java/java/FILES_c.gmk
- make/java/java/FILES_java.gmk
- make/java/java/Makefile
- make/java/java/genlocales.gmk
- make/java/java/localegen.sh
- make/java/java/localelist.sh
- make/java/java/mapfile-vers
- make/java/java/reflect/Makefile
- make/java/java/reorder-i586
- make/java/java/reorder-sparc
- make/java/java/reorder-sparcv9
- make/java/java_crw_demo/Makefile
- make/java/java_crw_demo/mapfile-vers
- make/java/java_hprof_demo/Makefile
- make/java/java_hprof_demo/mapfile-vers
- make/java/jexec/Makefile
- make/java/jli/Makefile
- make/java/jli/mapfile-vers
- make/java/jobjc/Makefile
- make/java/jvm/Makefile
- make/java/logging/Makefile
- make/java/main/Makefile
- make/java/main/java/Makefile
- make/java/main/java/mapfile-amd64
- make/java/main/java/mapfile-i586
- make/java/main/java/mapfile-sparc
- make/java/main/java/mapfile-sparcv9
- make/java/main/javaw/Makefile
- make/java/management/Exportedfiles.gmk
- make/java/management/FILES_c.gmk
- make/java/management/Makefile
- make/java/management/mapfile-vers
- make/java/math/Makefile
- make/java/net/FILES_c.gmk
- make/java/net/Makefile
- make/java/net/mapfile-vers
- make/java/nio/Exportedfiles.gmk
- make/java/nio/FILES_c.gmk
- make/java/nio/FILES_java.gmk
- make/java/nio/Makefile
- make/java/nio/addNotices.sh
- make/java/nio/genBuffer.sh
- make/java/nio/genCharsetProvider.sh
- make/java/nio/genCoder.sh
- make/java/nio/genExceptions.sh
- make/java/nio/mapfile-bsd
- make/java/nio/mapfile-linux
- make/java/nio/mapfile-solaris
- make/java/nio/reorder-i586
- make/java/nio/reorder-sparc
- make/java/nio/reorder-sparcv9
- make/java/npt/Makefile
- make/java/npt/mapfile-vers
- make/java/redist/Makefile
- make/java/redist/fonts/Makefile
- make/java/redist/sajdi/Makefile
- make/java/rmi/Makefile
- make/java/security/Makefile
- make/java/sql/Makefile
- make/java/sun_nio/FILES_java.gmk
- make/java/sun_nio/Makefile
- make/java/text/Makefile
- make/java/text/base/FILES_java.gmk
- make/java/text/base/Makefile
- make/java/text/bidi/Makefile
- make/java/time/Makefile
- make/java/util/FILES_java.gmk
- make/java/util/FILES_properties.gmk
- make/java/util/Makefile
- make/java/verify/Makefile
- make/java/verify/mapfile-vers
- make/java/verify/reorder-i586
- make/java/verify/reorder-sparc
- make/java/verify/reorder-sparcv9
- make/java/version/Makefile
- make/java/zip/FILES_c.gmk
- make/java/zip/FILES_java.gmk
- make/java/zip/Makefile
- make/java/zip/mapfile-vers
- make/java/zip/reorder-i586
- make/java/zip/reorder-sparc
- make/java/zip/reorder-sparcv9
- make/javax/Makefile
- make/javax/accessibility/Makefile
- make/javax/crypto/Defs-jce.gmk
- make/javax/crypto/Makefile
- make/javax/crypto/policy/limited/LIMITED
- make/javax/crypto/policy/limited/default_local.policy
- make/javax/crypto/policy/limited/exempt_local.policy
- make/javax/crypto/policy/unlimited/UNLIMITED
- make/javax/crypto/policy/unlimited/default_US_export.policy
- make/javax/crypto/policy/unlimited/default_local.policy
- make/javax/imageio/Makefile
- make/javax/management/Makefile
- make/javax/others/Makefile
- make/javax/print/Makefile
- make/javax/rmi/Makefile
- make/javax/rmi/ssl/Makefile
- make/javax/security/Makefile
- make/javax/sound/FILES_c.gmk
- make/javax/sound/Makefile
- make/javax/sound/SoundDefs.gmk
- make/javax/sound/jsoundalsa/Makefile
- make/javax/sound/jsoundalsa/mapfile-vers
- make/javax/sound/jsoundds/Makefile
- make/javax/sound/mapfile-vers
- make/javax/sql/Makefile
- make/javax/swing/FILES.gmk
- make/javax/swing/Makefile
- make/javax/swing/beaninfo/FILES.gmk
- make/javax/swing/beaninfo/Makefile
- make/javax/swing/beaninfo/SwingBeans.gmk
- make/javax/swing/beaninfo/manifest
- make/javax/swing/html32dtd/Makefile
- make/javax/swing/plaf/FILES.gmk
- make/javax/swing/plaf/Makefile
- make/jdk/Makefile
- make/jdk_generic_profile.sh
- make/jpda/Makefile
- make/jpda/back/Makefile
- make/jpda/back/mapfile-vers
- make/jpda/bdi/Makefile
- make/jpda/expr/Makefile
- make/jpda/front/Makefile
- make/jpda/gui/Makefile
- make/jpda/jdwp/Makefile
- make/jpda/jdwp/jdwp.spec
- make/jpda/transport/Makefile
- make/jpda/transport/shmem/Makefile
- make/jpda/transport/shmem/mapfile-vers
- make/jpda/transport/socket/Makefile
- make/jpda/transport/socket/mapfile-vers
- make/jpda/tty/Makefile
- make/jprt.gmk
- make/jprt.properties
- make/launchers/Makefile
- make/launchers/Makefile.launcher
+ make/lib/Awt2dLibraries.gmk
+ make/lib/CoreLibraries.gmk
+ make/lib/NetworkingLibraries.gmk
+ make/lib/NioLibraries.gmk
+ make/lib/PlatformLibraries.gmk
+ make/lib/SecurityLibraries.gmk
+ make/lib/ServiceabilityLibraries.gmk
+ make/lib/SoundLibraries.gmk
+ make/mapfiles/launchers/mapfile-sparc
+ make/mapfiles/launchers/mapfile-sparcv9
+ make/mapfiles/launchers/mapfile-x86
+ make/mapfiles/launchers/mapfile-x86_64
+ make/mapfiles/libattach/mapfile-linux
+ make/mapfiles/libattach/mapfile-solaris
+ make/mapfiles/libattach/reorder-windows-x86
+ make/mapfiles/libattach/reorder-windows-x86_64
+ make/mapfiles/libawt/mapfile-mawt-vers
+ make/mapfiles/libawt/mapfile-vers
+ make/mapfiles/libawt/mapfile-vers-linux
+ make/mapfiles/libawt_headless/mapfile-vers
+ make/mapfiles/libawt_headless/reorder-sparc
+ make/mapfiles/libawt_headless/reorder-sparcv9
+ make/mapfiles/libawt_headless/reorder-x86
+ make/mapfiles/libawt_xawt/mapfile-vers
+ make/mapfiles/libdcpr/mapfile-vers
+ make/mapfiles/libdt_socket/mapfile-vers
+ make/mapfiles/libfontmanager/mapfile-vers
+ make/mapfiles/libfontmanager/mapfile-vers.openjdk
+ make/mapfiles/libhprof/mapfile-vers
+ make/mapfiles/libinstrument/mapfile-vers
+ make/mapfiles/libj2gss/mapfile-vers
+ make/mapfiles/libj2pcsc/mapfile-vers
+ make/mapfiles/libj2pkcs11/mapfile-vers
+ make/mapfiles/libj2ucrypto/mapfile-vers
+ make/mapfiles/libjaas/mapfile-vers
+ make/mapfiles/libjava/mapfile-vers
+ make/mapfiles/libjava/reorder-sparc
+ make/mapfiles/libjava/reorder-sparcv9
+ make/mapfiles/libjava/reorder-x86
+ make/mapfiles/libjava_crw_demo/mapfile-vers
+ make/mapfiles/libjawt/mapfile-vers
+ make/mapfiles/libjdga/mapfile-vers
+ make/mapfiles/libjdwp/mapfile-vers
+ make/mapfiles/libjfr/mapfile-vers
+ make/mapfiles/libjli/mapfile-vers
+ make/mapfiles/libjpeg/mapfile-vers
+ make/mapfiles/libjpeg/mapfile-vers-closed
+ make/mapfiles/libjpeg/reorder-sparc
+ make/mapfiles/libjpeg/reorder-sparcv9
+ make/mapfiles/libjpeg/reorder-x86
+ make/mapfiles/libjsdt/mapfile-vers
+ make/mapfiles/libjsound/mapfile-vers
+ make/mapfiles/libjsoundalsa/mapfile-vers
+ make/mapfiles/libkcms/mapfile-vers
+ make/mapfiles/liblcms/mapfile-vers
+ make/mapfiles/libmanagement/mapfile-vers
+ make/mapfiles/libmlib_image/mapfile-vers
+ make/mapfiles/libnet/mapfile-vers
+ make/mapfiles/libnio/mapfile-linux
+ make/mapfiles/libnio/mapfile-macosx
+ make/mapfiles/libnio/mapfile-solaris
+ make/mapfiles/libnio/reorder-sparc
+ make/mapfiles/libnio/reorder-sparcv9
+ make/mapfiles/libnio/reorder-x86
+ make/mapfiles/libnpt/mapfile-vers
+ make/mapfiles/libsctp/mapfile-vers
+ make/mapfiles/libsplashscreen/mapfile-vers
+ make/mapfiles/libsunec/mapfile-vers
+ make/mapfiles/libt2k/mapfile-vers
+ make/mapfiles/libunpack/mapfile-vers
+ make/mapfiles/libunpack/mapfile-vers-unpack200
+ make/mapfiles/libverify/mapfile-vers
+ make/mapfiles/libverify/reorder-sparc
+ make/mapfiles/libverify/reorder-sparcv9
+ make/mapfiles/libverify/reorder-x86
+ make/mapfiles/libzip/mapfile-vers
+ make/mapfiles/libzip/reorder-sparc
+ make/mapfiles/libzip/reorder-sparcv9
+ make/mapfiles/libzip/reorder-x86
- make/mkdemo/Makefile
- make/mkdemo/applets/Animator/Makefile
- make/mkdemo/applets/ArcTest/Makefile
- make/mkdemo/applets/BarChart/Makefile
- make/mkdemo/applets/Blink/Makefile
- make/mkdemo/applets/CardTest/Makefile
- make/mkdemo/applets/Clock/Makefile
- make/mkdemo/applets/DitherTest/Makefile
- make/mkdemo/applets/DrawTest/Makefile
- make/mkdemo/applets/Fractal/Makefile
- make/mkdemo/applets/GraphLayout/Makefile
- make/mkdemo/applets/GraphicsTest/Makefile
- make/mkdemo/applets/JumpingBox/Makefile
- make/mkdemo/applets/Makefile
- make/mkdemo/applets/MoleculeViewer/Makefile
- make/mkdemo/applets/NervousText/Makefile
- make/mkdemo/applets/SimpleGraph/Makefile
- make/mkdemo/applets/SortDemo/Makefile
- make/mkdemo/applets/SpreadSheet/Makefile
- make/mkdemo/applets/TicTacToe/Makefile
- make/mkdemo/applets/WireFrame/Makefile
- make/mkdemo/jfc/CodePointIM/Makefile
- make/mkdemo/jfc/FileChooserDemo/Makefile
- make/mkdemo/jfc/Font2DTest/Makefile
- make/mkdemo/jfc/Java2D/Makefile
- make/mkdemo/jfc/Laffy/Makefile
- make/mkdemo/jfc/Makefile
- make/mkdemo/jfc/Metalworks/Makefile
- make/mkdemo/jfc/Notepad/Makefile
- make/mkdemo/jfc/SampleTree/Makefile
- make/mkdemo/jfc/Stylepad/Makefile
- make/mkdemo/jfc/SwingApplet/Makefile
- make/mkdemo/jfc/SwingSet2/Makefile
- make/mkdemo/jfc/SwingSet3/Makefile
- make/mkdemo/jfc/TableExample/Makefile
- make/mkdemo/jfc/TransparentRuler/Makefile
- make/mkdemo/jni/Makefile
- make/mkdemo/jni/Poller/Makefile
- make/mkdemo/jpda/Makefile
- make/mkdemo/jvmti/Makefile
- make/mkdemo/jvmti/README.txt
- make/mkdemo/jvmti/compiledMethodLoad/Makefile
- make/mkdemo/jvmti/gctest/Makefile
- make/mkdemo/jvmti/heapTracker/Makefile
- make/mkdemo/jvmti/heapViewer/Makefile
- make/mkdemo/jvmti/hprof/Makefile
- make/mkdemo/jvmti/mapfile-vers
- make/mkdemo/jvmti/minst/Makefile
- make/mkdemo/jvmti/mtrace/Makefile
- make/mkdemo/jvmti/versionCheck/Makefile
- make/mkdemo/jvmti/waiters/Makefile
- make/mkdemo/management/FullThreadDump/Makefile
- make/mkdemo/management/JTop/Makefile
- make/mkdemo/management/Makefile
- make/mkdemo/management/MemoryMonitor/Makefile
- make/mkdemo/management/README.txt
- make/mkdemo/management/VerboseGC/Makefile
- make/mkdemo/nio/Makefile
- make/mkdemo/nio/zipfs/Makefile
- make/mkdemo/scripting/Makefile
- make/mkdemo/scripting/jconsole-plugin/Makefile
- make/mksample/Makefile
- make/mksample/dtrace/Makefile
- make/mksample/forkjoin/Makefile
- make/mksample/forkjoin/mergesort/Makefile
- make/mksample/jmx/Makefile
- make/mksample/jmx/jmx-scandir/Makefile
- make/mksample/nbproject/Makefile
- make/mksample/nio/Makefile
- make/mksample/nio/chatserver/Makefile
- make/mksample/nio/file/Makefile
- make/mksample/nio/multicast/Makefile
- make/mksample/nio/server/Makefile
- make/mksample/scripting/Makefile
- make/mksample/scripting/scriptpad/Makefile
- make/mksample/webservices/EbayClient/Makefile
- make/mksample/webservices/EbayServer/Makefile
- make/mksample/webservices/Makefile
! make/netbeans/jdwpgen/nbproject/project.properties
+ make/non-build-utils/reorder/Makefile
+ make/non-build-utils/reorder/tests/Exit.java
+ make/non-build-utils/reorder/tests/Hello.java
+ make/non-build-utils/reorder/tests/IntToString.java
+ make/non-build-utils/reorder/tests/JHello.java
+ make/non-build-utils/reorder/tests/LoadFrame.java
+ make/non-build-utils/reorder/tests/LoadJFrame.java
+ make/non-build-utils/reorder/tests/LoadToolkit.java
+ make/non-build-utils/reorder/tests/Null.java
+ make/non-build-utils/reorder/tests/Sleep.java
+ make/non-build-utils/reorder/tools/Combine.java
+ make/non-build-utils/reorder/tools/MaxTime.java
+ make/non-build-utils/reorder/tools/mcount.c
+ make/non-build-utils/reorder/tools/remove_mcount.c
+ make/non-build-utils/reorder/tools/util-i586.il
+ make/non-build-utils/reorder/tools/util-sparc.il
+ make/non-build-utils/reorder/tools/util-sparcv9.il
+ make/non-build-utils/sharing/README.txt
+ make/non-build-utils/sharing/tests/GHello.java
+ make/non-build-utils/sharing/tests/Hello.java
+ make/non-build-utils/sharing/tests/JHello.java
+ make/non-build-utils/src/build/tools/commentchecker/CommentChecker.java
+ make/non-build-utils/src/build/tools/dirdiff/DirDiff.java
+ make/non-build-utils/src/build/tools/makeclasslist/MakeClasslist.java
- make/org/Makefile
- make/org/ietf/Makefile
- make/org/ietf/jgss/FILES_java.gmk
- make/org/ietf/jgss/Makefile
- make/org/jcp/Makefile
+ make/profile-includes.txt
+ make/profile-rtjar-includes.txt
+ make/scripts/addNotices.sh
+ make/scripts/genCharsetProvider.sh
+ make/scripts/genExceptions.sh
+ make/scripts/localelist.sh
+ make/src/classes/build/tools/addjsum/AddJsum.java
+ make/src/classes/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java
+ make/src/classes/build/tools/buildmetaindex/BuildMetaIndex.java
+ make/src/classes/build/tools/charsetmapping/DBCS.java
+ make/src/classes/build/tools/charsetmapping/EUC_TW.java
+ make/src/classes/build/tools/charsetmapping/HKSCS.java
+ make/src/classes/build/tools/charsetmapping/JIS0213.java
+ make/src/classes/build/tools/charsetmapping/Main.java
+ make/src/classes/build/tools/charsetmapping/SBCS.java
+ make/src/classes/build/tools/charsetmapping/Utils.java
+ make/src/classes/build/tools/classfile/RemoveMethods.java
+ make/src/classes/build/tools/cldrconverter/AbstractLDMLHandler.java
+ make/src/classes/build/tools/cldrconverter/Bundle.java
+ make/src/classes/build/tools/cldrconverter/BundleGenerator.java
+ make/src/classes/build/tools/cldrconverter/CLDRConverter.java
+ make/src/classes/build/tools/cldrconverter/CalendarType.java
+ make/src/classes/build/tools/cldrconverter/Container.java
+ make/src/classes/build/tools/cldrconverter/CopyrightHeaders.java
+ make/src/classes/build/tools/cldrconverter/Entry.java
+ make/src/classes/build/tools/cldrconverter/IgnoredContainer.java
+ make/src/classes/build/tools/cldrconverter/KeyContainer.java
+ make/src/classes/build/tools/cldrconverter/LDMLParseHandler.java
+ make/src/classes/build/tools/cldrconverter/MetaZonesParseHandler.java
+ make/src/classes/build/tools/cldrconverter/NumberingSystemsParseHandler.java
+ make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java
+ make/src/classes/build/tools/cldrconverter/StringArrayElement.java
+ make/src/classes/build/tools/cldrconverter/StringArrayEntry.java
+ make/src/classes/build/tools/cldrconverter/StringEntry.java
+ make/src/classes/build/tools/cldrconverter/SupplementDataParseHandler.java
+ make/src/classes/build/tools/compilefontconfig/CompileFontConfig.java
+ make/src/classes/build/tools/compileproperties/CompileProperties.java
+ make/src/classes/build/tools/deps/CheckDeps.java
+ make/src/classes/build/tools/dtdbuilder/DTDBuilder.java
+ make/src/classes/build/tools/dtdbuilder/DTDInputStream.java
+ make/src/classes/build/tools/dtdbuilder/DTDParser.java
+ make/src/classes/build/tools/dtdbuilder/PublicMapping.java
+ make/src/classes/build/tools/dtdbuilder/README.txt
+ make/src/classes/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java
+ make/src/classes/build/tools/generatebreakiteratordata/CharSet.java
+ make/src/classes/build/tools/generatebreakiteratordata/CharacterCategory.java
+ make/src/classes/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java
+ make/src/classes/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java
+ make/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
+ make/src/classes/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java
+ make/src/classes/build/tools/generatecharacter/CharacterName.java
+ make/src/classes/build/tools/generatecharacter/CharacterScript.java
+ make/src/classes/build/tools/generatecharacter/GenerateCharacter.java
+ make/src/classes/build/tools/generatecharacter/PrintCharacterRanges.java
+ make/src/classes/build/tools/generatecharacter/PropList.java
+ make/src/classes/build/tools/generatecharacter/SpecialCaseMap.java
+ make/src/classes/build/tools/generatecharacter/UnicodeSpec.java
+ make/src/classes/build/tools/generatecharacter/Utility.java
+ make/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java
+ make/src/classes/build/tools/generatenimbus/AbstractGradient.java
+ make/src/classes/build/tools/generatenimbus/Border.java
+ make/src/classes/build/tools/generatenimbus/Canvas.java
+ make/src/classes/build/tools/generatenimbus/ComponentColor.java
+ make/src/classes/build/tools/generatenimbus/Dimension.java
+ make/src/classes/build/tools/generatenimbus/Ellipse.java
+ make/src/classes/build/tools/generatenimbus/Generator.java
+ make/src/classes/build/tools/generatenimbus/Gradient.java
+ make/src/classes/build/tools/generatenimbus/GradientStop.java
+ make/src/classes/build/tools/generatenimbus/Insets.java
+ make/src/classes/build/tools/generatenimbus/Layer.java
+ make/src/classes/build/tools/generatenimbus/Matte.java
+ make/src/classes/build/tools/generatenimbus/ObjectFactory.java
+ make/src/classes/build/tools/generatenimbus/Paint.java
+ make/src/classes/build/tools/generatenimbus/PainterGenerator.java
+ make/src/classes/build/tools/generatenimbus/Path.java
+ make/src/classes/build/tools/generatenimbus/Point.java
+ make/src/classes/build/tools/generatenimbus/RadialGradient.java
+ make/src/classes/build/tools/generatenimbus/Rectangle.java
+ make/src/classes/build/tools/generatenimbus/Shape.java
+ make/src/classes/build/tools/generatenimbus/SynthModel.java
+ make/src/classes/build/tools/generatenimbus/Typeface.java
+ make/src/classes/build/tools/generatenimbus/UIColor.java
+ make/src/classes/build/tools/generatenimbus/UIComponent.java
+ make/src/classes/build/tools/generatenimbus/UIDefault.java
+ make/src/classes/build/tools/generatenimbus/UIFont.java
+ make/src/classes/build/tools/generatenimbus/UIIconRegion.java
+ make/src/classes/build/tools/generatenimbus/UIProperty.java
+ make/src/classes/build/tools/generatenimbus/UIRegion.java
+ make/src/classes/build/tools/generatenimbus/UIState.java
+ make/src/classes/build/tools/generatenimbus/UIStateType.java
+ make/src/classes/build/tools/generatenimbus/UIStyle.java
+ make/src/classes/build/tools/generatenimbus/Utils.java
+ make/src/classes/build/tools/hasher/Hasher.java
+ make/src/classes/build/tools/icondata/awt/ToBin.java
+ make/src/classes/build/tools/icondata/osxapp/ToBin.java
+ make/src/classes/build/tools/jarreorder/JarReorder.java
+ make/src/classes/build/tools/jdwpgen/AbstractCommandNode.java
+ make/src/classes/build/tools/jdwpgen/AbstractGroupNode.java
+ make/src/classes/build/tools/jdwpgen/AbstractNamedNode.java
+ make/src/classes/build/tools/jdwpgen/AbstractSimpleNode.java
+ make/src/classes/build/tools/jdwpgen/AbstractSimpleTypeNode.java
+ make/src/classes/build/tools/jdwpgen/AbstractTypeListNode.java
+ make/src/classes/build/tools/jdwpgen/AbstractTypeNode.java
+ make/src/classes/build/tools/jdwpgen/AltNode.java
+ make/src/classes/build/tools/jdwpgen/ArrayObjectTypeNode.java
+ make/src/classes/build/tools/jdwpgen/ArrayRegionTypeNode.java
+ make/src/classes/build/tools/jdwpgen/ArrayTypeNode.java
+ make/src/classes/build/tools/jdwpgen/BooleanTypeNode.java
+ make/src/classes/build/tools/jdwpgen/ByteTypeNode.java
+ make/src/classes/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java
+ make/src/classes/build/tools/jdwpgen/ClassObjectTypeNode.java
+ make/src/classes/build/tools/jdwpgen/ClassTypeNode.java
+ make/src/classes/build/tools/jdwpgen/CommandNode.java
+ make/src/classes/build/tools/jdwpgen/CommandSetNode.java
+ make/src/classes/build/tools/jdwpgen/CommentNode.java
+ make/src/classes/build/tools/jdwpgen/ConstantNode.java
+ make/src/classes/build/tools/jdwpgen/ConstantSetNode.java
+ make/src/classes/build/tools/jdwpgen/Context.java
+ make/src/classes/build/tools/jdwpgen/ErrorNode.java
+ make/src/classes/build/tools/jdwpgen/ErrorSetNode.java
+ make/src/classes/build/tools/jdwpgen/EventNode.java
+ make/src/classes/build/tools/jdwpgen/FieldTypeNode.java
+ make/src/classes/build/tools/jdwpgen/FrameTypeNode.java
+ make/src/classes/build/tools/jdwpgen/GroupNode.java
+ make/src/classes/build/tools/jdwpgen/IntTypeNode.java
+ make/src/classes/build/tools/jdwpgen/InterfaceTypeNode.java
+ make/src/classes/build/tools/jdwpgen/LocationTypeNode.java
+ make/src/classes/build/tools/jdwpgen/LongTypeNode.java
+ make/src/classes/build/tools/jdwpgen/Main.java
+ make/src/classes/build/tools/jdwpgen/MethodTypeNode.java
+ make/src/classes/build/tools/jdwpgen/NameNode.java
+ make/src/classes/build/tools/jdwpgen/NameValueNode.java
+ make/src/classes/build/tools/jdwpgen/Node.java
+ make/src/classes/build/tools/jdwpgen/ObjectTypeNode.java
+ make/src/classes/build/tools/jdwpgen/OutNode.java
+ make/src/classes/build/tools/jdwpgen/Parse.java
+ make/src/classes/build/tools/jdwpgen/ReferenceIDTypeNode.java
+ make/src/classes/build/tools/jdwpgen/ReferenceTypeNode.java
+ make/src/classes/build/tools/jdwpgen/RepeatNode.java
+ make/src/classes/build/tools/jdwpgen/ReplyNode.java
+ make/src/classes/build/tools/jdwpgen/RootNode.java
+ make/src/classes/build/tools/jdwpgen/SelectNode.java
+ make/src/classes/build/tools/jdwpgen/StringObjectTypeNode.java
+ make/src/classes/build/tools/jdwpgen/StringTypeNode.java
+ make/src/classes/build/tools/jdwpgen/TaggedObjectTypeNode.java
+ make/src/classes/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java
+ make/src/classes/build/tools/jdwpgen/ThreadObjectTypeNode.java
+ make/src/classes/build/tools/jdwpgen/TypeNode.java
+ make/src/classes/build/tools/jdwpgen/UntaggedValueTypeNode.java
+ make/src/classes/build/tools/jdwpgen/ValueTypeNode.java
+ make/src/classes/build/tools/spp/Spp.java
+ make/src/classes/build/tools/stripproperties/StripProperties.java
+ make/src/classes/build/tools/swingbeaninfo/DocBeanInfo.java
+ make/src/classes/build/tools/swingbeaninfo/GenDocletBeanInfo.java
+ make/src/classes/build/tools/swingbeaninfo/GenSwingBeanInfo.java
+ make/src/classes/build/tools/tzdb/ChronoField.java
+ make/src/classes/build/tools/tzdb/DateTimeException.java
+ make/src/classes/build/tools/tzdb/LocalDate.java
+ make/src/classes/build/tools/tzdb/LocalDateTime.java
+ make/src/classes/build/tools/tzdb/LocalTime.java
+ make/src/classes/build/tools/tzdb/TimeDefinition.java
+ make/src/classes/build/tools/tzdb/TzdbZoneRulesCompiler.java
+ make/src/classes/build/tools/tzdb/Utils.java
+ make/src/classes/build/tools/tzdb/ZoneOffset.java
+ make/src/classes/build/tools/tzdb/ZoneOffsetTransition.java
+ make/src/classes/build/tools/tzdb/ZoneOffsetTransitionRule.java
+ make/src/classes/build/tools/tzdb/ZoneRules.java
+ make/src/classes/build/tools/tzdb/ZoneRulesBuilder.java
+ make/src/native/add_gnu_debuglink/add_gnu_debuglink.c
+ make/src/native/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c
- make/sun/Makefile
- make/sun/applet/Makefile
- make/sun/audio/Makefile
- make/sun/awt/CondenseRules.awk
- make/sun/awt/Depend.mak
- make/sun/awt/Depend.sed
- make/sun/awt/FILES_c_unix.gmk
- make/sun/awt/FILES_c_windows.gmk
- make/sun/awt/FILES_export_unix.gmk
- make/sun/awt/FILES_export_windows.gmk
- make/sun/awt/Makefile
- make/sun/awt/README
- make/sun/awt/ToBin.java
- make/sun/awt/make.depend
- make/sun/awt/mapfile-mawt-vers
- make/sun/awt/mapfile-vers
- make/sun/awt/mapfile-vers-bsd
- make/sun/awt/mapfile-vers-linux
- make/sun/awt/mawt.gmk
- make/sun/cldr/Makefile
- make/sun/cmm/Makefile
- make/sun/cmm/kcms/FILES_c_unix.gmk
- make/sun/cmm/kcms/FILES_c_windows.gmk
- make/sun/cmm/kcms/Makefile
- make/sun/cmm/kcms/mapfile-vers
- make/sun/cmm/lcms/FILES_c_unix.gmk
- make/sun/cmm/lcms/FILES_c_windows.gmk
- make/sun/cmm/lcms/Makefile
- make/sun/cmm/lcms/mapfile-vers
- make/sun/dcpr/FILES_c.gmk
- make/sun/dcpr/Makefile
- make/sun/dcpr/mapfile-vers
- make/sun/font/FILES_c.gmk
- make/sun/font/Makefile
- make/sun/font/mapfile-vers
- make/sun/font/mapfile-vers.openjdk
- make/sun/font/reorder-i586
- make/sun/font/reorder-sparc
- make/sun/font/reorder-sparcv9
- make/sun/font/t2k/FILES_c.gmk
- make/sun/font/t2k/Makefile
- make/sun/font/t2k/mapfile-vers
- make/sun/headless/Makefile
- make/sun/headless/mapfile-vers
- make/sun/headless/reorder-i586
- make/sun/headless/reorder-sparc
- make/sun/headless/reorder-sparcv9
- make/sun/image/Makefile
- make/sun/image/generic/FILES_c.gmk
- make/sun/image/generic/Makefile
- make/sun/image/generic/mapfile-vers
- make/sun/image/vis/FILES_c.gmk
- make/sun/image/vis/Makefile
- make/sun/jar/Makefile
- make/sun/javazic/Makefile
- make/sun/javazic/javatz/fullset.txt
- make/sun/javazic/javatz/java_11_ids.txt
- make/sun/javazic/javatz/java_us_ids.txt
- make/sun/javazic/javatz/java_win_ids.txt
- make/sun/javazic/javatz/java_zone_ids.txt
- make/sun/javazic/javatz/jdk1.1.x_zone_ids.txt
- make/sun/javazic/tzdata/VERSION
- make/sun/javazic/tzdata/africa
- make/sun/javazic/tzdata/antarctica
- make/sun/javazic/tzdata/asia
- make/sun/javazic/tzdata/australasia
- make/sun/javazic/tzdata/backward
- make/sun/javazic/tzdata/etcetera
- make/sun/javazic/tzdata/europe
- make/sun/javazic/tzdata/factory
- make/sun/javazic/tzdata/gmt
- make/sun/javazic/tzdata/iso3166.tab
- make/sun/javazic/tzdata/jdk11_backward
- make/sun/javazic/tzdata/leapseconds
- make/sun/javazic/tzdata/northamerica
- make/sun/javazic/tzdata/pacificnew
- make/sun/javazic/tzdata/solar87
- make/sun/javazic/tzdata/solar88
- make/sun/javazic/tzdata/solar89
- make/sun/javazic/tzdata/southamerica
- make/sun/javazic/tzdata/systemv
- make/sun/javazic/tzdata/zone.tab
- make/sun/javazic/tzdata_jdk/gmt
- make/sun/javazic/tzdata_jdk/jdk11_backward
- make/sun/javazic/tzdata_jdk/jdk11_full_backward
- make/sun/jawt/Depend.mak
- make/sun/jawt/Depend.sed
- make/sun/jawt/Makefile
- make/sun/jawt/make.depend
- make/sun/jawt/mapfile-vers
- make/sun/jconsole/FILES.gmk
- make/sun/jconsole/Makefile
- make/sun/jdga/Makefile
- make/sun/jdga/mapfile-vers
- make/sun/jpeg/FILES_c.gmk
- make/sun/jpeg/Makefile
- make/sun/jpeg/mapfile-vers
- make/sun/jpeg/mapfile-vers-closed
- make/sun/jpeg/reorder-i586
- make/sun/jpeg/reorder-sparc
- make/sun/jpeg/reorder-sparcv9
- make/sun/launcher/Makefile
- make/sun/lwawt/FILES_c_macosx.gmk
- make/sun/lwawt/FILES_export_macosx.gmk
- make/sun/lwawt/Makefile
- make/sun/management/Makefile
- make/sun/management/jmxremote/Makefile
- make/sun/management/snmp/Makefile
- make/sun/misc/Makefile
- make/sun/native2ascii/Makefile
- make/sun/net/FILES_java.gmk
- make/sun/net/Makefile
- make/sun/net/others/Makefile
- make/sun/net/spi/Makefile
- make/sun/net/spi/nameservice/Makefile
- make/sun/net/spi/nameservice/dns/Makefile
- make/sun/nio/Makefile
- make/sun/nio/cs/FILES_java.gmk
- make/sun/nio/cs/Makefile
- make/sun/osxapp/Makefile
- make/sun/osxapp/ToBin.java
- make/sun/pisces/Makefile
- make/sun/rmi/Makefile
- make/sun/rmi/cgi/Makefile
- make/sun/rmi/oldtools/FILES_java.gmk
- make/sun/rmi/oldtools/Makefile
- make/sun/rmi/registry/Makefile
- make/sun/rmi/rmi/Makefile
- make/sun/rmi/rmi/mapfile-vers
- make/sun/rmi/rmic/FILES.gmk
- make/sun/rmi/rmic/Makefile
- make/sun/rmi/rmid/Makefile
- make/sun/security/Makefile
- make/sun/security/action/Makefile
- make/sun/security/ec/FILES_c.gmk
- make/sun/security/ec/Makefile
- make/sun/security/ec/mapfile-vers
- make/sun/security/jgss/Makefile
- make/sun/security/jgss/wrapper/FILES_c.gmk
- make/sun/security/jgss/wrapper/Makefile
- make/sun/security/jgss/wrapper/mapfile-vers
- make/sun/security/krb5/FILES_c_windows.gmk
- make/sun/security/krb5/Makefile
- make/sun/security/mscapi/FILES_cpp.gmk
- make/sun/security/mscapi/Makefile
- make/sun/security/other/Makefile
- make/sun/security/pkcs11/FILES_c.gmk
- make/sun/security/pkcs11/Makefile
- make/sun/security/pkcs11/mapfile-vers
- make/sun/security/smartcardio/FILES_c.gmk
- make/sun/security/smartcardio/Makefile
- make/sun/security/smartcardio/mapfile-vers
- make/sun/security/tools/Makefile
- make/sun/security/util/Makefile
- make/sun/serialver/Makefile
- make/sun/splashscreen/FILES_c.gmk
- make/sun/splashscreen/Makefile
- make/sun/splashscreen/mapfile-vers
- make/sun/text/FILES_java.gmk
- make/sun/text/FILES_properties.gmk
- make/sun/text/Makefile
- make/sun/tools/Makefile
- make/sun/tracing/Makefile
- make/sun/tracing/dtrace/Makefile
- make/sun/tracing/dtrace/mapfile-vers
- make/sun/tzdb/Makefile
- make/sun/usagetracker/Makefile
- make/sun/util/Makefile
- make/sun/xawt/FILES_c_unix.gmk
- make/sun/xawt/FILES_export_unix.gmk
- make/sun/xawt/Makefile
- make/sun/xawt/mapfile-vers
- make/templates/bsd-header
- make/templates/gpl-cp-header
- make/templates/gpl-header
- make/tools/CharsetMapping/Big5.map
- make/tools/CharsetMapping/Big5.nr
- make/tools/CharsetMapping/DoubleByte-X.java.template
- make/tools/CharsetMapping/EUC_CN.map
- make/tools/CharsetMapping/EUC_KR.map
- make/tools/CharsetMapping/GBK.map
- make/tools/CharsetMapping/HKSCS2001.c2b
- make/tools/CharsetMapping/HKSCS2001.map
- make/tools/CharsetMapping/HKSCS2008.c2b
- make/tools/CharsetMapping/HKSCS2008.map
- make/tools/CharsetMapping/HKSCS_XP.c2b
- make/tools/CharsetMapping/HKSCS_XP.map
- make/tools/CharsetMapping/IBM037.c2b
- make/tools/CharsetMapping/IBM037.map
- make/tools/CharsetMapping/IBM037.nr
- make/tools/CharsetMapping/IBM1006.map
- make/tools/CharsetMapping/IBM1025.c2b
- make/tools/CharsetMapping/IBM1025.map
- make/tools/CharsetMapping/IBM1025.nr
- make/tools/CharsetMapping/IBM1026.c2b
- make/tools/CharsetMapping/IBM1026.map
- make/tools/CharsetMapping/IBM1026.nr
- make/tools/CharsetMapping/IBM1046.map
- make/tools/CharsetMapping/IBM1047.map
- make/tools/CharsetMapping/IBM1097.map
- make/tools/CharsetMapping/IBM1098.map
- make/tools/CharsetMapping/IBM1112.c2b
- make/tools/CharsetMapping/IBM1112.map
- make/tools/CharsetMapping/IBM1112.nr
- make/tools/CharsetMapping/IBM1122.c2b
- make/tools/CharsetMapping/IBM1122.map
- make/tools/CharsetMapping/IBM1122.nr
- make/tools/CharsetMapping/IBM1123.c2b
- make/tools/CharsetMapping/IBM1123.map
- make/tools/CharsetMapping/IBM1123.nr
- make/tools/CharsetMapping/IBM1124.map
- make/tools/CharsetMapping/IBM1140.c2b
- make/tools/CharsetMapping/IBM1140.map
- make/tools/CharsetMapping/IBM1141.c2b
- make/tools/CharsetMapping/IBM1141.map
- make/tools/CharsetMapping/IBM1142.c2b
- make/tools/CharsetMapping/IBM1142.map
- make/tools/CharsetMapping/IBM1143.c2b
- make/tools/CharsetMapping/IBM1143.map
- make/tools/CharsetMapping/IBM1144.c2b
- make/tools/CharsetMapping/IBM1144.map
- make/tools/CharsetMapping/IBM1145.c2b
- make/tools/CharsetMapping/IBM1145.map
- make/tools/CharsetMapping/IBM1146.c2b
- make/tools/CharsetMapping/IBM1146.map
- make/tools/CharsetMapping/IBM1147.c2b
- make/tools/CharsetMapping/IBM1147.map
- make/tools/CharsetMapping/IBM1148.c2b
- make/tools/CharsetMapping/IBM1148.map
- make/tools/CharsetMapping/IBM1149.c2b
- make/tools/CharsetMapping/IBM1149.map
- make/tools/CharsetMapping/IBM1364.c2b
- make/tools/CharsetMapping/IBM1364.map
- make/tools/CharsetMapping/IBM1381.c2b
- make/tools/CharsetMapping/IBM1381.map
- make/tools/CharsetMapping/IBM1383.c2b
- make/tools/CharsetMapping/IBM1383.map
- make/tools/CharsetMapping/IBM1383.nr
- make/tools/CharsetMapping/IBM273.c2b
- make/tools/CharsetMapping/IBM273.map
- make/tools/CharsetMapping/IBM273.nr
- make/tools/CharsetMapping/IBM277.c2b
- make/tools/CharsetMapping/IBM277.map
- make/tools/CharsetMapping/IBM277.nr
- make/tools/CharsetMapping/IBM278.c2b
- make/tools/CharsetMapping/IBM278.map
- make/tools/CharsetMapping/IBM278.nr
- make/tools/CharsetMapping/IBM280.c2b
- make/tools/CharsetMapping/IBM280.map
- make/tools/CharsetMapping/IBM280.nr
- make/tools/CharsetMapping/IBM284.c2b
- make/tools/CharsetMapping/IBM284.map
- make/tools/CharsetMapping/IBM284.nr
- make/tools/CharsetMapping/IBM285.c2b
- make/tools/CharsetMapping/IBM285.map
- make/tools/CharsetMapping/IBM285.nr
- make/tools/CharsetMapping/IBM290.c2b
- make/tools/CharsetMapping/IBM290.map
- make/tools/CharsetMapping/IBM297.c2b
- make/tools/CharsetMapping/IBM297.map
- make/tools/CharsetMapping/IBM297.nr
- make/tools/CharsetMapping/IBM300.c2b
- make/tools/CharsetMapping/IBM300.map
- make/tools/CharsetMapping/IBM420.c2b
- make/tools/CharsetMapping/IBM420.map
- make/tools/CharsetMapping/IBM420.nr
- make/tools/CharsetMapping/IBM424.c2b
- make/tools/CharsetMapping/IBM424.map
- make/tools/CharsetMapping/IBM424.nr
- make/tools/CharsetMapping/IBM437.map
- make/tools/CharsetMapping/IBM500.c2b
- make/tools/CharsetMapping/IBM500.map
- make/tools/CharsetMapping/IBM500.nr
- make/tools/CharsetMapping/IBM737.map
- make/tools/CharsetMapping/IBM775.map
- make/tools/CharsetMapping/IBM833.c2b
- make/tools/CharsetMapping/IBM833.map
- make/tools/CharsetMapping/IBM838.c2b
- make/tools/CharsetMapping/IBM838.map
- make/tools/CharsetMapping/IBM838.nr
- make/tools/CharsetMapping/IBM850.map
- make/tools/CharsetMapping/IBM852.map
- make/tools/CharsetMapping/IBM855.map
- make/tools/CharsetMapping/IBM856.map
- make/tools/CharsetMapping/IBM857.map
- make/tools/CharsetMapping/IBM858.map
- make/tools/CharsetMapping/IBM860.map
- make/tools/CharsetMapping/IBM861.map
- make/tools/CharsetMapping/IBM862.map
- make/tools/CharsetMapping/IBM863.map
- make/tools/CharsetMapping/IBM864.map
- make/tools/CharsetMapping/IBM865.map
- make/tools/CharsetMapping/IBM866.map
- make/tools/CharsetMapping/IBM868.map
- make/tools/CharsetMapping/IBM869.map
- make/tools/CharsetMapping/IBM870.c2b
- make/tools/CharsetMapping/IBM870.map
- make/tools/CharsetMapping/IBM870.nr
- make/tools/CharsetMapping/IBM871.c2b
- make/tools/CharsetMapping/IBM871.map
- make/tools/CharsetMapping/IBM871.nr
- make/tools/CharsetMapping/IBM874.map
- make/tools/CharsetMapping/IBM874.nr
- make/tools/CharsetMapping/IBM875.c2b
- make/tools/CharsetMapping/IBM875.map
- make/tools/CharsetMapping/IBM875.nr
- make/tools/CharsetMapping/IBM918.c2b
- make/tools/CharsetMapping/IBM918.map
- make/tools/CharsetMapping/IBM918.nr
- make/tools/CharsetMapping/IBM921.map
- make/tools/CharsetMapping/IBM922.map
- make/tools/CharsetMapping/IBM930.c2b
- make/tools/CharsetMapping/IBM930.map
- make/tools/CharsetMapping/IBM930.nr
- make/tools/CharsetMapping/IBM933.c2b
- make/tools/CharsetMapping/IBM933.map
- make/tools/CharsetMapping/IBM935.c2b
- make/tools/CharsetMapping/IBM935.map
- make/tools/CharsetMapping/IBM935.nr
- make/tools/CharsetMapping/IBM937.c2b
- make/tools/CharsetMapping/IBM937.map
- make/tools/CharsetMapping/IBM937.nr
- make/tools/CharsetMapping/IBM939.c2b
- make/tools/CharsetMapping/IBM939.map
- make/tools/CharsetMapping/IBM939.nr
- make/tools/CharsetMapping/IBM942.c2b
- make/tools/CharsetMapping/IBM942.map
- make/tools/CharsetMapping/IBM943.map
- make/tools/CharsetMapping/IBM943.nr
- make/tools/CharsetMapping/IBM948.c2b
- make/tools/CharsetMapping/IBM948.map
- make/tools/CharsetMapping/IBM949.map
- make/tools/CharsetMapping/IBM950.c2b
- make/tools/CharsetMapping/IBM950.map
- make/tools/CharsetMapping/IBM970.c2b
- make/tools/CharsetMapping/IBM970.map
- make/tools/CharsetMapping/ISO_8859_11.map
- make/tools/CharsetMapping/ISO_8859_13.map
- make/tools/CharsetMapping/ISO_8859_15.map
- make/tools/CharsetMapping/ISO_8859_2.map
- make/tools/CharsetMapping/ISO_8859_3.map
- make/tools/CharsetMapping/ISO_8859_4.map
- make/tools/CharsetMapping/ISO_8859_5.map
- make/tools/CharsetMapping/ISO_8859_6.map
- make/tools/CharsetMapping/ISO_8859_7.map
- make/tools/CharsetMapping/ISO_8859_8.map
- make/tools/CharsetMapping/ISO_8859_9.map
- make/tools/CharsetMapping/JIS_X_0201.c2b
- make/tools/CharsetMapping/JIS_X_0201.map
- make/tools/CharsetMapping/JIS_X_0208.map
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.nr
- make/tools/CharsetMapping/JIS_X_0208_Solaris.map
- make/tools/CharsetMapping/JIS_X_0208_Solaris.nr
- make/tools/CharsetMapping/JIS_X_0212.map
- make/tools/CharsetMapping/JIS_X_0212_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.nr
- make/tools/CharsetMapping/Johab.map
- make/tools/CharsetMapping/KOI8_R.map
- make/tools/CharsetMapping/KOI8_U.map
- make/tools/CharsetMapping/MS1250.map
- make/tools/CharsetMapping/MS1251.map
- make/tools/CharsetMapping/MS1252.map
- make/tools/CharsetMapping/MS1253.map
- make/tools/CharsetMapping/MS1254.map
- make/tools/CharsetMapping/MS1255.map
- make/tools/CharsetMapping/MS1256.map
- make/tools/CharsetMapping/MS1257.map
- make/tools/CharsetMapping/MS1258.map
- make/tools/CharsetMapping/MS874.map
- make/tools/CharsetMapping/MS932.c2b
- make/tools/CharsetMapping/MS932.map
- make/tools/CharsetMapping/MS932.nr
- make/tools/CharsetMapping/MS936.map
- make/tools/CharsetMapping/MS949.map
- make/tools/CharsetMapping/MS950.map
- make/tools/CharsetMapping/MS950.nr
- make/tools/CharsetMapping/MacArabic.map
- make/tools/CharsetMapping/MacCentralEurope.map
- make/tools/CharsetMapping/MacCroatian.map
- make/tools/CharsetMapping/MacCyrillic.map
- make/tools/CharsetMapping/MacDingbat.map
- make/tools/CharsetMapping/MacGreek.map
- make/tools/CharsetMapping/MacHebrew.map
- make/tools/CharsetMapping/MacIceland.map
- make/tools/CharsetMapping/MacRoman.map
- make/tools/CharsetMapping/MacRomania.map
- make/tools/CharsetMapping/MacSymbol.map
- make/tools/CharsetMapping/MacThai.map
- make/tools/CharsetMapping/MacTurkish.map
- make/tools/CharsetMapping/MacUkraine.map
- make/tools/CharsetMapping/Makefile
- make/tools/CharsetMapping/PCK.c2b
- make/tools/CharsetMapping/PCK.map
- make/tools/CharsetMapping/PCK.nr
- make/tools/CharsetMapping/SJIS.c2b
- make/tools/CharsetMapping/SJIS.map
- make/tools/CharsetMapping/SingleByte-X.java.template
- make/tools/CharsetMapping/TIS_620.map
- make/tools/CharsetMapping/dbcs
- make/tools/CharsetMapping/euc_tw.map
- make/tools/CharsetMapping/extsbcs
- make/tools/CharsetMapping/sbcs
- make/tools/CharsetMapping/sjis0213.map
- make/tools/GenerateCharacter/Character.c.template
- make/tools/GenerateCharacter/CharacterData00.java.template
- make/tools/GenerateCharacter/CharacterData01.java.template
- make/tools/GenerateCharacter/CharacterData02.java.template
- make/tools/GenerateCharacter/CharacterData0E.java.template
- make/tools/GenerateCharacter/CharacterDataLatin1.java.template
- make/tools/GenerateCharacter/CharacterDataPrivateUse.java.template
- make/tools/GenerateCharacter/CharacterDataUndefined.java.template
- make/tools/GenerateCharacter/Makefile
- make/tools/GenerateCharacter/check_class.c.template
- make/tools/Makefile
- make/tools/README.txt
- make/tools/UnicodeData/PropList.txt
- make/tools/UnicodeData/Scripts.txt
- make/tools/UnicodeData/SpecialCasing.txt
- make/tools/UnicodeData/UnicodeData.txt
- make/tools/UnicodeData/VERSION
- make/tools/add_gnu_debuglink/Makefile
- make/tools/add_gnu_debuglink/add_gnu_debuglink.c
- make/tools/addjsum/Makefile
- make/tools/addtorestrictedpkgs/Makefile
- make/tools/buildmetaindex/Makefile
- make/tools/cldrconverter/Makefile
- make/tools/commentchecker/Makefile
- make/tools/compile_font_config/Makefile
- make/tools/compile_properties/Makefile
- make/tools/dir_diff/Makefile
- make/tools/dtdbuilder/Makefile
- make/tools/dtdbuilder/dtds/HTMLlat1.sgml
- make/tools/dtdbuilder/dtds/HTMLspecial.sgml
- make/tools/dtdbuilder/dtds/HTMLsymbol.sgml
- make/tools/dtdbuilder/dtds/html32.dtd
- make/tools/dtdbuilder/dtds/public.map
- make/tools/fix_empty_sec_hdr_flags/Makefile
- make/tools/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c
- make/tools/freetypecheck/Makefile
- make/tools/freetypecheck/freetypecheck.c
- make/tools/generate_break_iterator/Makefile
- make/tools/generate_nimbus/Makefile
- make/tools/generatecurrencydata/Makefile
- make/tools/hasher_classes/Makefile
- make/tools/jarreorder/Makefile
- make/tools/jarsplit/Makefile
- make/tools/jdwpgen/Makefile
- make/tools/makeclasslist/Makefile
- make/tools/manifest.mf
- make/tools/msys_build_scripts/dospath.sh
- make/tools/msys_build_scripts/dospath.vbs
- make/tools/reorder/Makefile
- make/tools/reorder/tests/Exit.java
- make/tools/reorder/tests/Hello.java
- make/tools/reorder/tests/IntToString.java
- make/tools/reorder/tests/JHello.java
- make/tools/reorder/tests/LoadFrame.java
- make/tools/reorder/tests/LoadJFrame.java
- make/tools/reorder/tests/LoadToolkit.java
- make/tools/reorder/tests/Null.java
- make/tools/reorder/tests/Sleep.java
- make/tools/reorder/tools/Combine.java
- make/tools/reorder/tools/MaxTime.java
- make/tools/reorder/tools/mcount.c
- make/tools/reorder/tools/remove_mcount.c
- make/tools/reorder/tools/util-i586.il
- make/tools/reorder/tools/util-sparc.il
- make/tools/reorder/tools/util-sparcv9.il
- make/tools/sharing/README.txt
- make/tools/sharing/classlist.linux
- make/tools/sharing/classlist.macosx
- make/tools/sharing/classlist.solaris
- make/tools/sharing/classlist.windows
- make/tools/sharing/tests/GHello.java
- make/tools/sharing/tests/Hello.java
- make/tools/sharing/tests/JHello.java
- make/tools/spp/Makefile
- make/tools/src/build/tools/addjsum/AddJsum.java
- make/tools/src/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java
- make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java
- make/tools/src/build/tools/charsetmapping/DBCS.java
- make/tools/src/build/tools/charsetmapping/EUC_TW.java
- make/tools/src/build/tools/charsetmapping/HKSCS.java
- make/tools/src/build/tools/charsetmapping/JIS0213.java
- make/tools/src/build/tools/charsetmapping/Main.java
- make/tools/src/build/tools/charsetmapping/SBCS.java
- make/tools/src/build/tools/charsetmapping/Utils.java
- make/tools/src/build/tools/classfile/RemoveMethods.java
- make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java
- make/tools/src/build/tools/cldrconverter/Bundle.java
- make/tools/src/build/tools/cldrconverter/BundleGenerator.java
- make/tools/src/build/tools/cldrconverter/CLDRConverter.java
- make/tools/src/build/tools/cldrconverter/CalendarType.java
- make/tools/src/build/tools/cldrconverter/Container.java
- make/tools/src/build/tools/cldrconverter/CopyrightHeaders.java
- make/tools/src/build/tools/cldrconverter/Entry.java
- make/tools/src/build/tools/cldrconverter/IgnoredContainer.java
- make/tools/src/build/tools/cldrconverter/KeyContainer.java
- make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java
- make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java
- make/tools/src/build/tools/cldrconverter/NumberingSystemsParseHandler.java
- make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java
- make/tools/src/build/tools/cldrconverter/StringArrayElement.java
- make/tools/src/build/tools/cldrconverter/StringArrayEntry.java
- make/tools/src/build/tools/cldrconverter/StringEntry.java
- make/tools/src/build/tools/cldrconverter/SupplementDataParseHandler.java
- make/tools/src/build/tools/commentchecker/CommentChecker.java
- make/tools/src/build/tools/compilefontconfig/CompileFontConfig.java
- make/tools/src/build/tools/compileproperties/CompileProperties.java
- make/tools/src/build/tools/deps/CheckDeps.java
- make/tools/src/build/tools/deps/refs.allowed
- make/tools/src/build/tools/dirdiff/DirDiff.java
- make/tools/src/build/tools/dtdbuilder/DTDBuilder.java
- make/tools/src/build/tools/dtdbuilder/DTDInputStream.java
- make/tools/src/build/tools/dtdbuilder/DTDParser.java
- make/tools/src/build/tools/dtdbuilder/PublicMapping.java
- make/tools/src/build/tools/dtdbuilder/README.txt
- make/tools/src/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java
- make/tools/src/build/tools/generatebreakiteratordata/CharSet.java
- make/tools/src/build/tools/generatebreakiteratordata/CharacterCategory.java
- make/tools/src/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java
- make/tools/src/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java
- make/tools/src/build/tools/generatecharacter/CharacterName.java
- make/tools/src/build/tools/generatecharacter/CharacterScript.java
- make/tools/src/build/tools/generatecharacter/GenerateCharacter.java
- make/tools/src/build/tools/generatecharacter/PrintCharacterRanges.java
- make/tools/src/build/tools/generatecharacter/PropList.java
- make/tools/src/build/tools/generatecharacter/SpecialCaseMap.java
- make/tools/src/build/tools/generatecharacter/UnicodeSpec.java
- make/tools/src/build/tools/generatecharacter/Utility.java
- make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java
- make/tools/src/build/tools/generatenimbus/AbstractGradient.java
- make/tools/src/build/tools/generatenimbus/Border.java
- make/tools/src/build/tools/generatenimbus/Canvas.java
- make/tools/src/build/tools/generatenimbus/ComponentColor.java
- make/tools/src/build/tools/generatenimbus/Dimension.java
- make/tools/src/build/tools/generatenimbus/Ellipse.java
- make/tools/src/build/tools/generatenimbus/Generator.java
- make/tools/src/build/tools/generatenimbus/Gradient.java
- make/tools/src/build/tools/generatenimbus/GradientStop.java
- make/tools/src/build/tools/generatenimbus/Insets.java
- make/tools/src/build/tools/generatenimbus/Layer.java
- make/tools/src/build/tools/generatenimbus/Matte.java
- make/tools/src/build/tools/generatenimbus/ObjectFactory.java
- make/tools/src/build/tools/generatenimbus/Paint.java
- make/tools/src/build/tools/generatenimbus/PainterGenerator.java
- make/tools/src/build/tools/generatenimbus/Path.java
- make/tools/src/build/tools/generatenimbus/Point.java
- make/tools/src/build/tools/generatenimbus/RadialGradient.java
- make/tools/src/build/tools/generatenimbus/Rectangle.java
- make/tools/src/build/tools/generatenimbus/Shape.java
- make/tools/src/build/tools/generatenimbus/SynthModel.java
- make/tools/src/build/tools/generatenimbus/Typeface.java
- make/tools/src/build/tools/generatenimbus/UIColor.java
- make/tools/src/build/tools/generatenimbus/UIComponent.java
- make/tools/src/build/tools/generatenimbus/UIDefault.java
- make/tools/src/build/tools/generatenimbus/UIFont.java
- make/tools/src/build/tools/generatenimbus/UIIconRegion.java
- make/tools/src/build/tools/generatenimbus/UIProperty.java
- make/tools/src/build/tools/generatenimbus/UIRegion.java
- make/tools/src/build/tools/generatenimbus/UIState.java
- make/tools/src/build/tools/generatenimbus/UIStateType.java
- make/tools/src/build/tools/generatenimbus/UIStyle.java
- make/tools/src/build/tools/generatenimbus/Utils.java
- make/tools/src/build/tools/hasher/Hasher.java
- make/tools/src/build/tools/jarreorder/JarReorder.java
- make/tools/src/build/tools/jarsplit/JarSplit.java
- make/tools/src/build/tools/jdwpgen/AbstractCommandNode.java
- make/tools/src/build/tools/jdwpgen/AbstractGroupNode.java
- make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleTypeNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeListNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeNode.java
- make/tools/src/build/tools/jdwpgen/AltNode.java
- make/tools/src/build/tools/jdwpgen/ArrayObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayTypeNode.java
- make/tools/src/build/tools/jdwpgen/BooleanTypeNode.java
- make/tools/src/build/tools/jdwpgen/ByteTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassTypeNode.java
- make/tools/src/build/tools/jdwpgen/CommandNode.java
- make/tools/src/build/tools/jdwpgen/CommandSetNode.java
- make/tools/src/build/tools/jdwpgen/CommentNode.java
- make/tools/src/build/tools/jdwpgen/ConstantNode.java
- make/tools/src/build/tools/jdwpgen/ConstantSetNode.java
- make/tools/src/build/tools/jdwpgen/Context.java
- make/tools/src/build/tools/jdwpgen/ErrorNode.java
- make/tools/src/build/tools/jdwpgen/ErrorSetNode.java
- make/tools/src/build/tools/jdwpgen/EventNode.java
- make/tools/src/build/tools/jdwpgen/FieldTypeNode.java
- make/tools/src/build/tools/jdwpgen/FrameTypeNode.java
- make/tools/src/build/tools/jdwpgen/GroupNode.java
- make/tools/src/build/tools/jdwpgen/IntTypeNode.java
- make/tools/src/build/tools/jdwpgen/InterfaceTypeNode.java
- make/tools/src/build/tools/jdwpgen/LocationTypeNode.java
- make/tools/src/build/tools/jdwpgen/LongTypeNode.java
- make/tools/src/build/tools/jdwpgen/Main.java
- make/tools/src/build/tools/jdwpgen/MethodTypeNode.java
- make/tools/src/build/tools/jdwpgen/NameNode.java
- make/tools/src/build/tools/jdwpgen/NameValueNode.java
- make/tools/src/build/tools/jdwpgen/Node.java
- make/tools/src/build/tools/jdwpgen/ObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/OutNode.java
- make/tools/src/build/tools/jdwpgen/Parse.java
- make/tools/src/build/tools/jdwpgen/ReferenceIDTypeNode.java
- make/tools/src/build/tools/jdwpgen/ReferenceTypeNode.java
- make/tools/src/build/tools/jdwpgen/RepeatNode.java
- make/tools/src/build/tools/jdwpgen/ReplyNode.java
- make/tools/src/build/tools/jdwpgen/RootNode.java
- make/tools/src/build/tools/jdwpgen/SelectNode.java
- make/tools/src/build/tools/jdwpgen/StringObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/StringTypeNode.java
- make/tools/src/build/tools/jdwpgen/TaggedObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/TypeNode.java
- make/tools/src/build/tools/jdwpgen/UntaggedValueTypeNode.java
- make/tools/src/build/tools/jdwpgen/ValueTypeNode.java
- make/tools/src/build/tools/makeclasslist/MakeClasslist.java
- make/tools/src/build/tools/spp/Spp.java
- make/tools/src/build/tools/stripproperties/StripProperties.java
- make/tools/src/build/tools/tzdb/ChronoField.java
- make/tools/src/build/tools/tzdb/DateTimeException.java
- make/tools/src/build/tools/tzdb/LocalDate.java
- make/tools/src/build/tools/tzdb/LocalDateTime.java
- make/tools/src/build/tools/tzdb/LocalTime.java
- make/tools/src/build/tools/tzdb/TimeDefinition.java
- make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java
- make/tools/src/build/tools/tzdb/Utils.java
- make/tools/src/build/tools/tzdb/ZoneOffset.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransition.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransitionRule.java
- make/tools/src/build/tools/tzdb/ZoneRules.java
- make/tools/src/build/tools/tzdb/ZoneRulesBuilder.java
- make/tools/strip_properties/Makefile
- make/tools/swing-beans/DocBeanInfo.java
- make/tools/swing-beans/GenDocletBeanInfo.java
- make/tools/swing-beans/GenSwingBeanInfo.java
- make/tools/swing-beans/SwingBeanInfo.template
- make/tools/swing-beans/beaninfo/images/AbstractButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/BorderColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor32.gif
- make/tools/swing-beans/beaninfo/images/BoxMono16.gif
- make/tools/swing-beans/beaninfo/images/BoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor16.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor32.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono16.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono32.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JComponentColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor16.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor32.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono16.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor16.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor32.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono16.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JListColor16.gif
- make/tools/swing-beans/beaninfo/images/JListColor32.gif
- make/tools/swing-beans/beaninfo/images/JListMono16.gif
- make/tools/swing-beans/beaninfo/images/JListMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor16.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor32.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono16.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono32.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor16.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor32.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono16.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTableColor16.gif
- make/tools/swing-beans/beaninfo/images/JTableColor32.gif
- make/tools/swing-beans/beaninfo/images/JTableMono16.gif
- make/tools/swing-beans/beaninfo/images/JTableMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor16.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor32.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono16.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono32.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor16.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor32.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono16.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono32.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor16.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor32.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono16.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono32.gif
- make/tools/swing-beans/javax/swing/SwingBeanInfoBase.java
- make/tools/swing-beans/sun/swing/BeanInfoUtils.java
- make/tools/tzdb/Makefile
- makefiles/BuildJdk.gmk
- makefiles/Bundles.gmk
- makefiles/CompileDemos.gmk
- makefiles/CompileJavaClasses.gmk
- makefiles/CompileLaunchers.gmk
- makefiles/CompileNativeLibraries.gmk
- makefiles/CopyFiles.gmk
- makefiles/CopyIntoClasses.gmk
- makefiles/CopySamples.gmk
- makefiles/CreateJars.gmk
- makefiles/CreateSecurityJars.gmk
- makefiles/GenerateClasses.gmk
- makefiles/GenerateData.gmk
- makefiles/GenerateSources.gmk
- makefiles/Images.gmk
- makefiles/Import.gmk
- makefiles/Makefile
- makefiles/PatchList.solaris
- makefiles/ProfileNames.gmk
- makefiles/Profiles.gmk
- makefiles/Setup.gmk
- makefiles/SignJars.gmk
- makefiles/Tools.gmk
- makefiles/gendata/GendataBreakIterator.gmk
- makefiles/gendata/GendataFontConfig.gmk
- makefiles/gendata/GendataHtml32dtd.gmk
- makefiles/gendata/GendataTZDB.gmk
- makefiles/gendata/GendataTimeZone.gmk
- makefiles/gensrc/GensrcBuffer.gmk
- makefiles/gensrc/GensrcCLDR.gmk
- makefiles/gensrc/GensrcCharacterData.gmk
- makefiles/gensrc/GensrcCharsetCoder.gmk
- makefiles/gensrc/GensrcCharsetMapping.gmk
- makefiles/gensrc/GensrcExceptions.gmk
- makefiles/gensrc/GensrcIcons.gmk
- makefiles/gensrc/GensrcJDWP.gmk
- makefiles/gensrc/GensrcJObjC.gmk
- makefiles/gensrc/GensrcLocaleDataMetaInfo.gmk
- makefiles/gensrc/GensrcMisc.gmk
- makefiles/gensrc/GensrcProperties.gmk
- makefiles/gensrc/GensrcSwing.gmk
- makefiles/gensrc/GensrcX11Wrappers.gmk
- makefiles/jpda/jdwp/jdwp.spec
- makefiles/jprt.gmk
- makefiles/jprt.properties
- makefiles/lib/Awt2dLibraries.gmk
- makefiles/lib/CoreLibraries.gmk
- makefiles/lib/NetworkingLibraries.gmk
- makefiles/lib/NioLibraries.gmk
- makefiles/lib/PlatformLibraries.gmk
- makefiles/lib/SecurityLibraries.gmk
- makefiles/lib/ServiceabilityLibraries.gmk
- makefiles/lib/SoundLibraries.gmk
- makefiles/mapfiles/launchers/mapfile-sparc
- makefiles/mapfiles/launchers/mapfile-sparcv9
- makefiles/mapfiles/launchers/mapfile-x86
- makefiles/mapfiles/launchers/mapfile-x86_64
- makefiles/mapfiles/libattach/mapfile-linux
- makefiles/mapfiles/libattach/mapfile-solaris
- makefiles/mapfiles/libattach/reorder-windows-x86
- makefiles/mapfiles/libattach/reorder-windows-x86_64
- makefiles/mapfiles/libawt/mapfile-mawt-vers
- makefiles/mapfiles/libawt/mapfile-vers
- makefiles/mapfiles/libawt/mapfile-vers-linux
- makefiles/mapfiles/libawt_headless/mapfile-vers
- makefiles/mapfiles/libawt_headless/reorder-sparc
- makefiles/mapfiles/libawt_headless/reorder-sparcv9
- makefiles/mapfiles/libawt_headless/reorder-x86
- makefiles/mapfiles/libawt_xawt/mapfile-vers
- makefiles/mapfiles/libdcpr/mapfile-vers
- makefiles/mapfiles/libdt_socket/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk
- makefiles/mapfiles/libhprof/mapfile-vers
- makefiles/mapfiles/libinstrument/mapfile-vers
- makefiles/mapfiles/libj2gss/mapfile-vers
- makefiles/mapfiles/libj2pcsc/mapfile-vers
- makefiles/mapfiles/libj2pkcs11/mapfile-vers
- makefiles/mapfiles/libj2ucrypto/mapfile-vers
- makefiles/mapfiles/libjaas/mapfile-vers
- makefiles/mapfiles/libjava/mapfile-vers
- makefiles/mapfiles/libjava/reorder-sparc
- makefiles/mapfiles/libjava/reorder-sparcv9
- makefiles/mapfiles/libjava/reorder-x86
- makefiles/mapfiles/libjava_crw_demo/mapfile-vers
- makefiles/mapfiles/libjawt/mapfile-vers
- makefiles/mapfiles/libjdga/mapfile-vers
- makefiles/mapfiles/libjdwp/mapfile-vers
- makefiles/mapfiles/libjfr/mapfile-vers
- makefiles/mapfiles/libjli/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers-closed
- makefiles/mapfiles/libjpeg/reorder-sparc
- makefiles/mapfiles/libjpeg/reorder-sparcv9
- makefiles/mapfiles/libjpeg/reorder-x86
- makefiles/mapfiles/libjsdt/mapfile-vers
- makefiles/mapfiles/libjsound/mapfile-vers
- makefiles/mapfiles/libjsoundalsa/mapfile-vers
- makefiles/mapfiles/libkcms/mapfile-vers
- makefiles/mapfiles/liblcms/mapfile-vers
- makefiles/mapfiles/libmanagement/mapfile-vers
- makefiles/mapfiles/libmlib_image/mapfile-vers
- makefiles/mapfiles/libnet/mapfile-vers
- makefiles/mapfiles/libnio/mapfile-linux
- makefiles/mapfiles/libnio/mapfile-macosx
- makefiles/mapfiles/libnio/mapfile-solaris
- makefiles/mapfiles/libnio/reorder-sparc
- makefiles/mapfiles/libnio/reorder-sparcv9
- makefiles/mapfiles/libnio/reorder-x86
- makefiles/mapfiles/libnpt/mapfile-vers
- makefiles/mapfiles/libsctp/mapfile-vers
- makefiles/mapfiles/libsplashscreen/mapfile-vers
- makefiles/mapfiles/libsunec/mapfile-vers
- makefiles/mapfiles/libt2k/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers-unpack200
- makefiles/mapfiles/libverify/mapfile-vers
- makefiles/mapfiles/libverify/reorder-sparc
- makefiles/mapfiles/libverify/reorder-sparcv9
- makefiles/mapfiles/libverify/reorder-x86
- makefiles/mapfiles/libzip/mapfile-vers
- makefiles/mapfiles/libzip/reorder-sparc
- makefiles/mapfiles/libzip/reorder-sparcv9
- makefiles/mapfiles/libzip/reorder-x86
- makefiles/profile-includes.txt
- makefiles/profile-rtjar-includes.txt
- makefiles/scripts/addNotices.sh
- makefiles/scripts/genCharsetProvider.sh
- makefiles/scripts/genExceptions.sh
- makefiles/scripts/localelist.sh
- makefiles/sun/awt/ToBin.java
- makefiles/sun/osxapp/ToBin.java

Changeset: 7b71e53c6a2b
Author:    weijun
Date:      2013-11-19 14:14 +0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7b71e53c6a2b

8028479: runNameEquals still cannot precisely detect if a usable native krb5 is available
Reviewed-by: xuelei

! test/sun/security/krb5/runNameEquals.sh

Changeset: d6195774dd1f
Author:    egahlin
Date:      2013-11-19 11:47 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d6195774dd1f

8028505: Put sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh on ProblemList.txt
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: d5ddde25d107
Author:    tyan
Date:      2013-11-19 13:46 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d5ddde25d107

7086879: java/net/InetAddress/CheckJNI.java hangs on Linux when IPv6 enabled
Reviewed-by: chegar

! test/ProblemList.txt

Changeset: 2e574350a2b6
Author:    alanb
Date:      2013-11-19 14:08 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2e574350a2b6

8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests
Reviewed-by: dholmes, sla, tbell

! test/Makefile

Changeset: d1bb85f0a45a
Author:    coffeys
Date:      2013-11-19 14:47 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d1bb85f0a45a

8028583: Add helper methods to test libraries
Reviewed-by: chegar

! test/java/rmi/testlibrary/TestLibrary.java
! test/lib/testlibrary/jdk/testlibrary/FileUtils.java

Changeset: 36821ee241a2
Author:    alanb
Date:      2013-11-19 15:09 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/36821ee241a2

8028589: Instrument tools/jar/JarEntryTime.java to make it easier to diagnose failures
Reviewed-by: chegar

! test/tools/jar/JarEntryTime.java

Changeset: 40462a41b41b
Author:    ksrini
Date:      2013-11-19 07:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/40462a41b41b

8023978: [TEST_BUG] launcher tests must exclude platforms without server vm
Reviewed-by: dholmes, mchung

! test/tools/launcher/ExecutionEnvironment.java
! test/tools/launcher/Test7029048.java
! test/tools/launcher/TestHelper.java

Changeset: cfbee8ee71bf
Author:    bvaidya
Date:      2013-11-19 15:31 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/cfbee8ee71bf

8028094: TEST_BUG: java/lang/ProcessBuilder/Basic.java leaves "sleep 6666" processes behind
Reviewed-by: chegar

! test/java/lang/ProcessBuilder/Basic.java

Changeset: e8daf5a83e42
Author:    vinnie
Date:      2013-11-19 15:39 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e8daf5a83e42

8028377: test/sun/security/provider/KeyStore/DKSTest.sh attempts to write to ${test.src}
Reviewed-by: alanb, weijun

! test/sun/security/provider/KeyStore/DKSTest.java
! test/sun/security/provider/KeyStore/domains.cfg

Changeset: bfd4e632eeda
Author:    vinnie
Date:      2013-11-19 15:42 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bfd4e632eeda

Merge


Changeset: 63b696dafc8a
Author:    robm
Date:      2013-11-19 15:36 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/63b696dafc8a

8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java
Reviewed-by: chegar, alanb

! test/java/lang/ProcessBuilder/Basic.java

Changeset: f2ccd3530476
Author:    coffeys
Date:      2013-11-19 16:22 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f2ccd3530476

8016728: TEST_BUG: test/java/rmi/transport/closeServerSocket/CloseServerSocket.java failing intermittently
Reviewed-by: chegar

! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java

Changeset: 79e975dfeb8a
Author:    michaelm
Date:      2013-11-19 17:49 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/79e975dfeb8a

8028581: [TESTBUG] java/net/Socket/LingerTest.java failing
Reviewed-by: alanb

! test/java/net/Socket/LingerTest.java

Changeset: f8b24e1a609e
Author:    vinnie
Date:      2013-11-19 17:55 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f8b24e1a609e

8015571: OCSP validation fails if ocsp.responderCertSubjectName is set
Reviewed-by: mullan, xuelei

! src/share/classes/sun/security/provider/certpath/OCSP.java
! src/share/classes/sun/security/provider/certpath/OCSPRequest.java
! src/share/classes/sun/security/provider/certpath/OCSPResponse.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/share/classes/sun/security/x509/X509CertImpl.java

Changeset: 5aa853ca08a8
Author:    kizune
Date:      2013-11-19 22:05 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5aa853ca08a8

8027900: pack200 option is broken due to the incorrect makefile definition for its driver
Reviewed-by: ksrini, ihse

! make/CompileLaunchers.gmk

Changeset: 48c61808374f
Author:    mchung
Date:      2013-11-19 10:19 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/48c61808374f

8028565: Remove java/lang/management/ThreadMXBean/ThreadStateTest.java from ProblemList.txt
Reviewed-by: sla

! test/ProblemList.txt

Changeset: 3f47e393e1dd
Author:    rriggs
Date:      2013-11-19 13:20 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3f47e393e1dd

8028141: test/sun/management/jmxremote/bootstrap/LocalManagementTest|CustomLauncherTest.java failing again
Summary: Correct to use the test.class.path instead of test.classes
Reviewed-by: alanb, chegar

! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java
! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java

Changeset: 67d742c75971
Author:    dfuchs
Date:      2013-11-19 20:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/67d742c75971

8028185: XMLFormatter.format emits incorrect year
Summary: Fixes a regression where the year in the date was increased by 1900.
Reviewed-by: alanb, mchung

! src/share/classes/java/util/logging/XMLFormatter.java
+ test/java/util/logging/XMLFormatterDate.java

Changeset: f496565c4eec
Author:    dxu
Date:      2013-11-19 13:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f496565c4eec

8028631: Improve the test coverage to the pathname handling on unix-like platforms
Summary: Add GeneralSolaris.java testcase and fix the concurrency issue
Reviewed-by: lancea, chegar, alanb

! test/java/io/pathNames/General.java
+ test/java/io/pathNames/GeneralSolaris.java
! test/java/io/pathNames/GeneralWin32.java

Changeset: 059530c5ae9a
Author:    dfuchs
Date:      2013-11-19 22:28 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/059530c5ae9a

8005202: java/util/logging/CheckLockLocationTest.java fail on solars_10
Summary: this test has been seen failing on Solaris 10, presumably because it was run as root. The fix will skip the non-writable case if it can't make a non-writable dir.
Reviewed-by: mchung

! test/java/util/logging/CheckLockLocationTest.java

Changeset: 19d2e9649138
Author:    smarks
Date:      2013-11-19 15:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/19d2e9649138

8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails
Reviewed-by: lancea

! test/java/rmi/testlibrary/RMID.java

Changeset: 894a4bae9e33
Author:    egahlin
Date:      2013-11-20 12:32 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/894a4bae9e33

7141544: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails
Reviewed-by: sla

! test/com/sun/jdi/BreakpointWithFullGC.sh

Changeset: f39be11835ff
Author:    jfranck
Date:      2013-11-20 13:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f39be11835ff

8027413: Clarify javadoc for j.l.a.Target and j.l.a.ElementType
Reviewed-by: darcy

! src/share/classes/java/lang/annotation/ElementType.java
! src/share/classes/java/lang/annotation/Target.java

Changeset: 90e27a47ff28
Author:    mchung
Date:      2013-11-20 10:00 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/90e27a47ff28

8028647: Add instrumentation in GetSafepointSyncTime.java and remove it from ProblemList.txt
Reviewed-by: sla, chegar

! test/ProblemList.txt
! test/sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java

Changeset: ecd6c25b54ce
Author:    alanb
Date:      2013-11-20 21:34 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ecd6c25b54ce

8028734: test/java/util/Locale/InternationalBAT.java changes does not restore the default TimeZone
Reviewed-by: naoto

! test/java/util/Locale/InternationalBAT.java

Changeset: d5d4b9a63174
Author:    msheppar
Date:      2013-11-21 11:36 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d5d4b9a63174

8028215: ORB.init fails with SecurityException if properties select the JDK default ORB
Summary: check for default ORBImpl and ORBSingleton set via properties or System properties
Reviewed-by: alanb, coffeys, mchung

+ test/com/sun/corba/se/impl/orb/SetDefaultORBTest.java

Changeset: 91ec3bc92793
Author:    egahlin
Date:      2013-11-21 13:46 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/91ec3bc92793

6402201: ProcessAttachTest.sh needs better synchronization
Reviewed-by: alanb

! test/ProblemList.txt
! test/com/sun/jdi/ProcessAttachDebuggee.java
! test/com/sun/jdi/ProcessAttachTest.sh

Changeset: fc9f24b9408e
Author:    sla
Date:      2013-11-21 12:57 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/fc9f24b9408e

8028632: Update jdk/test/ProblemList.txt to reflect fix JDK-8024423
Summary: Removed 5 testcases from the ProblemList
Reviewed-by: sla
Contributed-by: balchandra.vaidya at oracle.com

! test/ProblemList.txt

Changeset: 2972241cf7eb
Author:    tyan
Date:      2013-11-21 13:37 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2972241cf7eb

7036666: test/com/sun/net/httpserver/Test9a.java fails intermittently
Summary: Additional stacktrace information is printed on failure
Reviewed-by: alanb, dfuchs, chegar

! test/ProblemList.txt
! test/com/sun/net/httpserver/Test9a.java

Changeset: ed979f9b40cd
Author:    tyan
Date:      2013-11-21 13:42 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ed979f9b40cd

8022212: Intermittent test failures in java/net
Reviewed-by: chegar

! test/java/net/NetworkInterface/IndexTest.java

Changeset: 89fccc5a7469
Author:    martin
Date:      2013-11-21 16:06 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/89fccc5a7469

6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug
Reviewed-by: alanb

! test/java/lang/ProcessBuilder/Basic.java

Changeset: 93826827e8b4
Author:    valeriep
Date:      2013-11-19 15:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/93826827e8b4

8026943: SQE test jce/Global/Cipher/SameBuffer failed
Summary: Always use different input/output buffers when calling FeedbackCipher objects
Reviewed-by: mullan

! src/share/classes/com/sun/crypto/provider/CipherBlockChaining.java
! src/share/classes/com/sun/crypto/provider/CipherCore.java
! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java
+ test/com/sun/crypto/provider/Cipher/AES/TestCopySafe.java

Changeset: 06d155a7c9b0
Author:    valeriep
Date:      2013-11-21 11:58 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/06d155a7c9b0

Merge


Changeset: a74d6aa51654
Author:    dxu
Date:      2013-11-21 14:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a74d6aa51654

7065902: (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root
Reviewed-by: alanb

! test/java/nio/file/Files/Misc.java

Changeset: 81708985c0a2
Author:    dxu
Date:      2013-11-21 14:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/81708985c0a2

8028628: java/nio/channels/FileChannel/Size.java failed once in the same binary run
Reviewed-by: alanb, chegar, mchung, lancea

! test/java/nio/channels/FileChannel/Size.java

Changeset: 4bc37b6c4133
Author:    smarks
Date:      2013-11-21 16:02 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4bc37b6c4133

7174936: several String methods claim to always create new String
Reviewed-by: dholmes, bchristi, alanb, lancea

! src/share/classes/java/lang/String.java

Changeset: cd56de5896b4
Author:    aefimov
Date:      2013-11-15 15:06 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/cd56de5896b4

8027848: The ZoneInfoFile doesn't honor future GMT offset changes
Reviewed-by: sherman, coffeys

! src/share/classes/sun/util/calendar/ZoneInfoFile.java

Changeset: ebd47f6ab172
Author:    aefimov
Date:      2013-11-21 20:48 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ebd47f6ab172

8027370: Support tzdata2013h
Reviewed-by: sherman, coffeys

! make/data/tzdata/VERSION
! make/data/tzdata/africa
! make/data/tzdata/southamerica
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java
! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java
! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java
! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java
! test/sun/util/calendar/zi/tzdata/VERSION
! test/sun/util/calendar/zi/tzdata/africa
! test/sun/util/calendar/zi/tzdata/southamerica

Changeset: 3b50d682e7c1
Author:    coffeys
Date:      2013-11-22 09:56 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3b50d682e7c1

Merge


Changeset: 0775f4f6532a
Author:    jfranck
Date:      2013-11-22 11:34 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0775f4f6532a

8023278: Reflection API methods do not throw AnnotationFormatError in case of malformed Runtime[In]VisibleTypeAnnotations attribute
Reviewed-by: darcy

! src/share/classes/sun/reflect/annotation/TypeAnnotation.java
! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java
+ test/java/lang/annotation/typeAnnotations/BadCPIndex.java

Changeset: 1f45b24ffe4b
Author:    psandoz
Date:      2013-11-25 09:55 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1f45b24ffe4b

8028516: Java doc error in Int/Long/Double/Stream.peek
Reviewed-by: chegar

! 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/Stream.java

Changeset: ee3c7ab60373
Author:    lana
Date:      2013-11-25 09:40 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ee3c7ab60373

Merge

! make/CompileDemos.gmk
! make/SignJars.gmk
! test/ProblemList.txt
! test/tools/launcher/DiacriticTest.java

Changeset: 8d5a9245b9ca
Author:    valeriep
Date:      2013-11-25 11:56 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8d5a9245b9ca

7200306: SunPKCS11 provider delays the check of DSA key size for SHA1withDSA to sign() instead of init()
Summary: Add key length checks to P11Signature class
Reviewed-by: mullan

! src/share/classes/sun/security/pkcs11/P11Signature.java
! src/share/classes/sun/security/pkcs11/Token.java
+ test/sun/security/pkcs11/Signature/TestDSAKeyLength.java

Changeset: 0bf3a58a1783
Author:    joehw
Date:      2013-11-25 16:53 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0bf3a58a1783

8027973: javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win)
Reviewed-by: alanb, dfuchs, joehw
Contributed-by: patrick.zhang at oracle.com

+ test/javax/xml/jaxp/transform/8004476/SecureProcessingTest.xml
+ test/javax/xml/jaxp/transform/8004476/TestBase.java
+ test/javax/xml/jaxp/transform/8004476/XPathExFuncTest.java
+ test/javax/xml/jaxp/transform/8004476/XSLTExFuncTest.java
+ test/javax/xml/jaxp/transform/8004476/tokenize.xml
+ test/javax/xml/jaxp/transform/8004476/tokenize.xsl
- 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: 4d9078b1f25b
Author:    peytoia
Date:      2013-11-26 14:49 +0900
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4d9078b1f25b

8029057: test/java/text/Bidi/Bug6665028.java can fail with OutOfMemoryError
Reviewed-by: okutsu

- test/java/text/Bidi/Bug6665028.java

Changeset: e822676cd3cd
Author:    jrose
Date:      2013-11-26 17:16 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e822676cd3cd

8016839: JSR292: AME instead of IAE when calling a method
Summary: Catch missing-because-illegal case for itable entries and use an exception-throwing method instead of null.
Reviewed-by: acorn, jrose, coleenp
Contributed-by: david.r.chase at oracle.com

! src/share/classes/sun/misc/Unsafe.java

Changeset: 1738dfb0c52a
Author:    weijun
Date:      2013-11-27 09:56 +0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1738dfb0c52a

8029181: ts.sh generates invalid file after JDK-8027026
Reviewed-by: vinnie, mullan

! test/sun/security/tools/jarsigner/TimestampCheck.java

Changeset: 2370d285d08b
Author:    naoto
Date:      2013-11-27 10:01 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2370d285d08b

8028771: regression test java/util/Locale/LocaleProviders.sh failed
Reviewed-by: alanb

! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh

Changeset: 657a3cccf8a1
Author:    lana
Date:      2013-11-27 10:47 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/657a3cccf8a1

Merge

+ make/CompileDemos.gmk
- make/PatchList.solaris
- make/altclasses/Makefile
- make/apple/Makefile
- make/apple/applescript/Makefile
- make/bridge/AccessBridgeJava/Makefile
- make/bridge/JAWTAccessBridge/Files_cpp.gmk
- make/bridge/JAWTAccessBridge/Makefile
- make/bridge/Jabswitch/Makefile
- make/bridge/Jaccess/Makefile
- make/bridge/JavaAccessBridge/Files_cpp.gmk
- make/bridge/JavaAccessBridge/Makefile
- make/bridge/Makefile
- make/bridge/WindowsAccessBridge/Files_cpp.gmk
- make/bridge/WindowsAccessBridge/Makefile
- make/com/Makefile
- make/com/apple/Makefile
- make/com/apple/osx/Makefile
- make/com/apple/osxui/Makefile
- make/com/oracle/Makefile
- make/com/oracle/jfr/Makefile
- make/com/oracle/net/Makefile
- make/com/oracle/nio/Makefile
- make/com/oracle/security/ucrypto/FILES_c.gmk
- make/com/oracle/security/ucrypto/Makefile
- make/com/oracle/security/ucrypto/mapfile-vers
- make/com/oracle/util/Makefile
- make/com/sun/Makefile
- make/com/sun/crypto/provider/Makefile
- make/com/sun/demo/Makefile
- make/com/sun/demo/jvmti/Makefile
- make/com/sun/demo/jvmti/hprof/Makefile
- make/com/sun/image/Makefile
- make/com/sun/jarsigner/Makefile
- make/com/sun/java/Makefile
- make/com/sun/java/browser/Makefile
- make/com/sun/java/browser/dom/Makefile
- make/com/sun/java/browser/net/Makefile
- make/com/sun/java/pack/FILES_cpp.gmk
- make/com/sun/java/pack/Makefile
- make/com/sun/java/pack/mapfile-vers
- make/com/sun/java/pack/mapfile-vers-unpack200
- make/com/sun/java/pack/prop/Makefile
- make/com/sun/jmx/Makefile
- make/com/sun/jmx/snmp/Makefile
- make/com/sun/jndi/Makefile
- make/com/sun/jndi/cosnaming/Makefile
- make/com/sun/jndi/dns/Makefile
- make/com/sun/jndi/ldap/Makefile
- make/com/sun/jndi/rmi/Makefile
- make/com/sun/jndi/rmi/registry/Makefile
- make/com/sun/jndi/toolkit/Makefile
- make/com/sun/net/httpserver/Makefile
- make/com/sun/net/ssl/Makefile
- make/com/sun/nio/Makefile
- make/com/sun/nio/sctp/Exportedfiles.gmk
- make/com/sun/nio/sctp/FILES_c.gmk
- make/com/sun/nio/sctp/FILES_java.gmk
- make/com/sun/nio/sctp/Makefile
- make/com/sun/nio/sctp/mapfile-vers
- make/com/sun/org/Makefile
- make/com/sun/org/apache/Makefile
- make/com/sun/org/apache/xml/Makefile
- make/com/sun/rowset/Makefile
- make/com/sun/security/Makefile
- make/com/sun/security/auth/FILES_java.gmk
- make/com/sun/security/auth/Makefile
- make/com/sun/security/auth/module/FILES_c_solaris.gmk
- make/com/sun/security/auth/module/FILES_c_unix.gmk
- make/com/sun/security/auth/module/FILES_c_windows.gmk
- make/com/sun/security/auth/module/FILES_export_solaris.gmk
- make/com/sun/security/auth/module/FILES_export_unix.gmk
- make/com/sun/security/auth/module/FILES_export_windows.gmk
- make/com/sun/security/auth/module/FILES_java.gmk
- make/com/sun/security/auth/module/Makefile
- make/com/sun/security/auth/module/mapfile-vers
- make/com/sun/security/jgss/Makefile
- make/com/sun/security/ntlm/Makefile
- make/com/sun/security/sasl/Makefile
- make/com/sun/sql/FILES_java.gmk
- make/com/sun/sql/Makefile
- make/com/sun/tools/Makefile
- make/com/sun/tools/attach/Exportedfiles.gmk
- make/com/sun/tools/attach/FILES_c.gmk
- make/com/sun/tools/attach/FILES_java.gmk
- make/com/sun/tools/attach/Makefile
- make/com/sun/tools/attach/mapfile-bsd
- make/com/sun/tools/attach/mapfile-linux
- make/com/sun/tools/attach/mapfile-solaris
- make/com/sun/tracing/Makefile
- make/com/sun/tracing/dtrace/Makefile
- make/common/BuildToolJar.gmk
- make/common/CancelImplicits.gmk
- make/common/Classes.gmk
- make/common/Cscope.gmk
- make/common/Defs-linux.gmk
- make/common/Defs-macosx.gmk
- make/common/Defs-solaris.gmk
- make/common/Defs-windows.gmk
- make/common/Defs.gmk
- make/common/Demo.gmk
- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/Program.gmk
- make/common/Release-macosx.gmk
- make/common/Release.gmk
- make/common/Rules.gmk
- make/common/Sanity.gmk
- make/common/Subdirs.gmk
- make/common/internal/Defs-corba.gmk
- make/common/internal/Defs-jaxp.gmk
- make/common/internal/Defs-jaxws.gmk
- make/common/internal/Defs-langtools.gmk
- make/common/internal/ImportComponents.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/internal/Resources.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-llvm.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Defs-control.gmk
- make/common/shared/Defs-java.gmk
- make/common/shared/Defs-javadoc.gmk
- make/common/shared/Defs-linux.gmk
- make/common/shared/Defs-macosx.gmk
- make/common/shared/Defs-solaris.gmk
- make/common/shared/Defs-utils.gmk
- make/common/shared/Defs-versions.gmk
- make/common/shared/Defs-windows.gmk
- make/common/shared/Defs.gmk
- make/common/shared/Platform.gmk
- make/common/shared/PrivateDefs.gmk-example
- make/common/shared/Sanity-Settings.gmk
- make/common/shared/Sanity.gmk
- make/docs/CORE_PKGS.gmk
- make/docs/Makefile
- make/docs/NON_CORE_PKGS.gmk
- make/docs/Notes.html
- make/java/Makefile
- make/java/applet/Makefile
- make/java/awt/Makefile
- make/java/beans/Makefile
- make/java/fdlibm/FILES_c.gmk
- make/java/fdlibm/Makefile
- make/java/instrument/Makefile
- make/java/instrument/mapfile-vers
- make/java/invoke/Makefile
- make/java/jar/Makefile
- make/java/java/Exportedfiles.gmk
- make/java/java/FILES_c.gmk
- make/java/java/FILES_java.gmk
- make/java/java/Makefile
- make/java/java/genlocales.gmk
- make/java/java/localegen.sh
- make/java/java/localelist.sh
- make/java/java/mapfile-vers
- make/java/java/reflect/Makefile
- make/java/java/reorder-i586
- make/java/java/reorder-sparc
- make/java/java/reorder-sparcv9
- make/java/java_crw_demo/Makefile
- make/java/java_crw_demo/mapfile-vers
- make/java/java_hprof_demo/Makefile
- make/java/java_hprof_demo/mapfile-vers
- make/java/jexec/Makefile
- make/java/jli/Makefile
- make/java/jli/mapfile-vers
- make/java/jobjc/Makefile
- make/java/jvm/Makefile
- make/java/logging/Makefile
- make/java/main/Makefile
- make/java/main/java/Makefile
- make/java/main/java/mapfile-amd64
- make/java/main/java/mapfile-i586
- make/java/main/java/mapfile-sparc
- make/java/main/java/mapfile-sparcv9
- make/java/main/javaw/Makefile
- make/java/management/Exportedfiles.gmk
- make/java/management/FILES_c.gmk
- make/java/management/Makefile
- make/java/management/mapfile-vers
- make/java/math/Makefile
- make/java/net/FILES_c.gmk
- make/java/net/Makefile
- make/java/net/mapfile-vers
- make/java/nio/Exportedfiles.gmk
- make/java/nio/FILES_c.gmk
- make/java/nio/FILES_java.gmk
- make/java/nio/Makefile
- make/java/nio/addNotices.sh
- make/java/nio/genBuffer.sh
- make/java/nio/genCharsetProvider.sh
- make/java/nio/genCoder.sh
- make/java/nio/genExceptions.sh
- make/java/nio/mapfile-bsd
- make/java/nio/mapfile-linux
- make/java/nio/mapfile-solaris
- make/java/nio/reorder-i586
- make/java/nio/reorder-sparc
- make/java/nio/reorder-sparcv9
- make/java/npt/Makefile
- make/java/npt/mapfile-vers
- make/java/redist/Makefile
- make/java/redist/fonts/Makefile
- make/java/redist/sajdi/Makefile
- make/java/rmi/Makefile
- make/java/security/Makefile
- make/java/sql/Makefile
- make/java/sun_nio/FILES_java.gmk
- make/java/sun_nio/Makefile
- make/java/text/Makefile
- make/java/text/base/FILES_java.gmk
- make/java/text/base/Makefile
- make/java/text/bidi/Makefile
- make/java/time/Makefile
- make/java/util/FILES_java.gmk
- make/java/util/FILES_properties.gmk
- make/java/util/Makefile
- make/java/verify/Makefile
- make/java/verify/mapfile-vers
- make/java/verify/reorder-i586
- make/java/verify/reorder-sparc
- make/java/verify/reorder-sparcv9
- make/java/version/Makefile
- make/java/zip/FILES_c.gmk
- make/java/zip/FILES_java.gmk
- make/java/zip/Makefile
- make/java/zip/mapfile-vers
- make/java/zip/reorder-i586
- make/java/zip/reorder-sparc
- make/java/zip/reorder-sparcv9
- make/javax/Makefile
- make/javax/accessibility/Makefile
- make/javax/crypto/Defs-jce.gmk
- make/javax/crypto/Makefile
- make/javax/crypto/policy/limited/LIMITED
- make/javax/crypto/policy/limited/default_local.policy
- make/javax/crypto/policy/limited/exempt_local.policy
- make/javax/crypto/policy/unlimited/UNLIMITED
- make/javax/crypto/policy/unlimited/default_US_export.policy
- make/javax/crypto/policy/unlimited/default_local.policy
- make/javax/imageio/Makefile
- make/javax/management/Makefile
- make/javax/others/Makefile
- make/javax/print/Makefile
- make/javax/rmi/Makefile
- make/javax/rmi/ssl/Makefile
- make/javax/security/Makefile
- make/javax/sound/FILES_c.gmk
- make/javax/sound/Makefile
- make/javax/sound/SoundDefs.gmk
- make/javax/sound/jsoundalsa/Makefile
- make/javax/sound/jsoundalsa/mapfile-vers
- make/javax/sound/jsoundds/Makefile
- make/javax/sound/mapfile-vers
- make/javax/sql/Makefile
- make/javax/swing/FILES.gmk
- make/javax/swing/Makefile
- make/javax/swing/beaninfo/FILES.gmk
- make/javax/swing/beaninfo/Makefile
- make/javax/swing/beaninfo/SwingBeans.gmk
- make/javax/swing/beaninfo/manifest
- make/javax/swing/html32dtd/Makefile
- make/javax/swing/plaf/FILES.gmk
- make/javax/swing/plaf/Makefile
- make/jdk/Makefile
- make/jdk_generic_profile.sh
- make/jpda/Makefile
- make/jpda/back/Makefile
- make/jpda/back/mapfile-vers
- make/jpda/bdi/Makefile
- make/jpda/expr/Makefile
- make/jpda/front/Makefile
- make/jpda/gui/Makefile
- make/jpda/jdwp/Makefile
- make/jpda/jdwp/jdwp.spec
- make/jpda/transport/Makefile
- make/jpda/transport/shmem/Makefile
- make/jpda/transport/shmem/mapfile-vers
- make/jpda/transport/socket/Makefile
- make/jpda/transport/socket/mapfile-vers
- make/jpda/tty/Makefile
- make/jprt.gmk
- make/jprt.properties
- make/launchers/Makefile
- make/launchers/Makefile.launcher
- make/mkdemo/Makefile
- make/mkdemo/applets/Animator/Makefile
- make/mkdemo/applets/ArcTest/Makefile
- make/mkdemo/applets/BarChart/Makefile
- make/mkdemo/applets/Blink/Makefile
- make/mkdemo/applets/CardTest/Makefile
- make/mkdemo/applets/Clock/Makefile
- make/mkdemo/applets/DitherTest/Makefile
- make/mkdemo/applets/DrawTest/Makefile
- make/mkdemo/applets/Fractal/Makefile
- make/mkdemo/applets/GraphLayout/Makefile
- make/mkdemo/applets/GraphicsTest/Makefile
- make/mkdemo/applets/JumpingBox/Makefile
- make/mkdemo/applets/Makefile
- make/mkdemo/applets/MoleculeViewer/Makefile
- make/mkdemo/applets/NervousText/Makefile
- make/mkdemo/applets/SimpleGraph/Makefile
- make/mkdemo/applets/SortDemo/Makefile
- make/mkdemo/applets/SpreadSheet/Makefile
- make/mkdemo/applets/TicTacToe/Makefile
- make/mkdemo/applets/WireFrame/Makefile
- make/mkdemo/jfc/CodePointIM/Makefile
- make/mkdemo/jfc/FileChooserDemo/Makefile
- make/mkdemo/jfc/Font2DTest/Makefile
- make/mkdemo/jfc/Java2D/Makefile
- make/mkdemo/jfc/Laffy/Makefile
- make/mkdemo/jfc/Makefile
- make/mkdemo/jfc/Metalworks/Makefile
- make/mkdemo/jfc/Notepad/Makefile
- make/mkdemo/jfc/SampleTree/Makefile
- make/mkdemo/jfc/Stylepad/Makefile
- make/mkdemo/jfc/SwingApplet/Makefile
- make/mkdemo/jfc/SwingSet2/Makefile
- make/mkdemo/jfc/SwingSet3/Makefile
- make/mkdemo/jfc/TableExample/Makefile
- make/mkdemo/jfc/TransparentRuler/Makefile
- make/mkdemo/jni/Makefile
- make/mkdemo/jni/Poller/Makefile
- make/mkdemo/jpda/Makefile
- make/mkdemo/jvmti/Makefile
- make/mkdemo/jvmti/README.txt
- make/mkdemo/jvmti/compiledMethodLoad/Makefile
- make/mkdemo/jvmti/gctest/Makefile
- make/mkdemo/jvmti/heapTracker/Makefile
- make/mkdemo/jvmti/heapViewer/Makefile
- make/mkdemo/jvmti/hprof/Makefile
- make/mkdemo/jvmti/mapfile-vers
- make/mkdemo/jvmti/minst/Makefile
- make/mkdemo/jvmti/mtrace/Makefile
- make/mkdemo/jvmti/versionCheck/Makefile
- make/mkdemo/jvmti/waiters/Makefile
- make/mkdemo/management/FullThreadDump/Makefile
- make/mkdemo/management/JTop/Makefile
- make/mkdemo/management/Makefile
- make/mkdemo/management/MemoryMonitor/Makefile
- make/mkdemo/management/README.txt
- make/mkdemo/management/VerboseGC/Makefile
- make/mkdemo/nio/Makefile
- make/mkdemo/nio/zipfs/Makefile
- make/mkdemo/scripting/Makefile
- make/mkdemo/scripting/jconsole-plugin/Makefile
- make/mksample/Makefile
- make/mksample/dtrace/Makefile
- make/mksample/forkjoin/Makefile
- make/mksample/forkjoin/mergesort/Makefile
- make/mksample/jmx/Makefile
- make/mksample/jmx/jmx-scandir/Makefile
- make/mksample/nbproject/Makefile
- make/mksample/nio/Makefile
- make/mksample/nio/chatserver/Makefile
- make/mksample/nio/file/Makefile
- make/mksample/nio/multicast/Makefile
- make/mksample/nio/server/Makefile
- make/mksample/scripting/Makefile
- make/mksample/scripting/scriptpad/Makefile
- make/mksample/webservices/EbayClient/Makefile
- make/mksample/webservices/EbayServer/Makefile
- make/mksample/webservices/Makefile
- make/org/Makefile
- make/org/ietf/Makefile
- make/org/ietf/jgss/FILES_java.gmk
- make/org/ietf/jgss/Makefile
- make/org/jcp/Makefile
- make/sun/Makefile
- make/sun/applet/Makefile
- make/sun/audio/Makefile
- make/sun/awt/CondenseRules.awk
- make/sun/awt/Depend.mak
- make/sun/awt/Depend.sed
- make/sun/awt/FILES_c_unix.gmk
- make/sun/awt/FILES_c_windows.gmk
- make/sun/awt/FILES_export_unix.gmk
- make/sun/awt/FILES_export_windows.gmk
- make/sun/awt/Makefile
- make/sun/awt/README
- make/sun/awt/ToBin.java
- make/sun/awt/make.depend
- make/sun/awt/mapfile-mawt-vers
- make/sun/awt/mapfile-vers
- make/sun/awt/mapfile-vers-bsd
- make/sun/awt/mapfile-vers-linux
- make/sun/awt/mawt.gmk
- make/sun/cldr/Makefile
- make/sun/cmm/Makefile
- make/sun/cmm/kcms/FILES_c_unix.gmk
- make/sun/cmm/kcms/FILES_c_windows.gmk
- make/sun/cmm/kcms/Makefile
- make/sun/cmm/kcms/mapfile-vers
- make/sun/cmm/lcms/FILES_c_unix.gmk
- make/sun/cmm/lcms/FILES_c_windows.gmk
- make/sun/cmm/lcms/Makefile
- make/sun/cmm/lcms/mapfile-vers
- make/sun/dcpr/FILES_c.gmk
- make/sun/dcpr/Makefile
- make/sun/dcpr/mapfile-vers
- make/sun/font/FILES_c.gmk
- make/sun/font/Makefile
- make/sun/font/mapfile-vers
- make/sun/font/mapfile-vers.openjdk
- make/sun/font/reorder-i586
- make/sun/font/reorder-sparc
- make/sun/font/reorder-sparcv9
- make/sun/font/t2k/FILES_c.gmk
- make/sun/font/t2k/Makefile
- make/sun/font/t2k/mapfile-vers
- make/sun/headless/Makefile
- make/sun/headless/mapfile-vers
- make/sun/headless/reorder-i586
- make/sun/headless/reorder-sparc
- make/sun/headless/reorder-sparcv9
- make/sun/image/Makefile
- make/sun/image/generic/FILES_c.gmk
- make/sun/image/generic/Makefile
- make/sun/image/generic/mapfile-vers
- make/sun/image/vis/FILES_c.gmk
- make/sun/image/vis/Makefile
- make/sun/jar/Makefile
- make/sun/javazic/Makefile
- make/sun/javazic/javatz/fullset.txt
- make/sun/javazic/javatz/java_11_ids.txt
- make/sun/javazic/javatz/java_us_ids.txt
- make/sun/javazic/javatz/java_win_ids.txt
- make/sun/javazic/javatz/java_zone_ids.txt
- make/sun/javazic/javatz/jdk1.1.x_zone_ids.txt
- make/sun/javazic/tzdata/VERSION
- make/sun/javazic/tzdata/africa
- make/sun/javazic/tzdata/antarctica
- make/sun/javazic/tzdata/asia
- make/sun/javazic/tzdata/australasia
- make/sun/javazic/tzdata/backward
- make/sun/javazic/tzdata/etcetera
- make/sun/javazic/tzdata/europe
- make/sun/javazic/tzdata/factory
- make/sun/javazic/tzdata/gmt
- make/sun/javazic/tzdata/iso3166.tab
- make/sun/javazic/tzdata/jdk11_backward
- make/sun/javazic/tzdata/leapseconds
- make/sun/javazic/tzdata/northamerica
- make/sun/javazic/tzdata/pacificnew
- make/sun/javazic/tzdata/solar87
- make/sun/javazic/tzdata/solar88
- make/sun/javazic/tzdata/solar89
- make/sun/javazic/tzdata/southamerica
- make/sun/javazic/tzdata/systemv
- make/sun/javazic/tzdata/zone.tab
- make/sun/javazic/tzdata_jdk/gmt
- make/sun/javazic/tzdata_jdk/jdk11_backward
- make/sun/javazic/tzdata_jdk/jdk11_full_backward
- make/sun/jawt/Depend.mak
- make/sun/jawt/Depend.sed
- make/sun/jawt/Makefile
- make/sun/jawt/make.depend
- make/sun/jawt/mapfile-vers
- make/sun/jconsole/FILES.gmk
- make/sun/jconsole/Makefile
- make/sun/jdga/Makefile
- make/sun/jdga/mapfile-vers
- make/sun/jpeg/FILES_c.gmk
- make/sun/jpeg/Makefile
- make/sun/jpeg/mapfile-vers
- make/sun/jpeg/mapfile-vers-closed
- make/sun/jpeg/reorder-i586
- make/sun/jpeg/reorder-sparc
- make/sun/jpeg/reorder-sparcv9
- make/sun/launcher/Makefile
- make/sun/lwawt/FILES_c_macosx.gmk
- make/sun/lwawt/FILES_export_macosx.gmk
- make/sun/lwawt/Makefile
- make/sun/management/Makefile
- make/sun/management/jmxremote/Makefile
- make/sun/management/snmp/Makefile
- make/sun/misc/Makefile
- make/sun/native2ascii/Makefile
- make/sun/net/FILES_java.gmk
- make/sun/net/Makefile
- make/sun/net/others/Makefile
- make/sun/net/spi/Makefile
- make/sun/net/spi/nameservice/Makefile
- make/sun/net/spi/nameservice/dns/Makefile
- make/sun/nio/Makefile
- make/sun/nio/cs/FILES_java.gmk
- make/sun/nio/cs/Makefile
- make/sun/osxapp/Makefile
- make/sun/osxapp/ToBin.java
- make/sun/pisces/Makefile
- make/sun/rmi/Makefile
- make/sun/rmi/cgi/Makefile
- make/sun/rmi/oldtools/FILES_java.gmk
- make/sun/rmi/oldtools/Makefile
- make/sun/rmi/registry/Makefile
- make/sun/rmi/rmi/Makefile
- make/sun/rmi/rmi/mapfile-vers
- make/sun/rmi/rmic/FILES.gmk
- make/sun/rmi/rmic/Makefile
- make/sun/rmi/rmid/Makefile
- make/sun/security/Makefile
- make/sun/security/action/Makefile
- make/sun/security/ec/FILES_c.gmk
- make/sun/security/ec/Makefile
- make/sun/security/ec/mapfile-vers
- make/sun/security/jgss/Makefile
- make/sun/security/jgss/wrapper/FILES_c.gmk
- make/sun/security/jgss/wrapper/Makefile
- make/sun/security/jgss/wrapper/mapfile-vers
- make/sun/security/krb5/FILES_c_windows.gmk
- make/sun/security/krb5/Makefile
- make/sun/security/mscapi/FILES_cpp.gmk
- make/sun/security/mscapi/Makefile
- make/sun/security/other/Makefile
- make/sun/security/pkcs11/FILES_c.gmk
- make/sun/security/pkcs11/Makefile
- make/sun/security/pkcs11/mapfile-vers
- make/sun/security/smartcardio/FILES_c.gmk
- make/sun/security/smartcardio/Makefile
- make/sun/security/smartcardio/mapfile-vers
- make/sun/security/tools/Makefile
- make/sun/security/util/Makefile
- make/sun/serialver/Makefile
- make/sun/splashscreen/FILES_c.gmk
- make/sun/splashscreen/Makefile
- make/sun/splashscreen/mapfile-vers
- make/sun/text/FILES_java.gmk
- make/sun/text/FILES_properties.gmk
- make/sun/text/Makefile
- make/sun/tools/Makefile
- make/sun/tracing/Makefile
- make/sun/tracing/dtrace/Makefile
- make/sun/tracing/dtrace/mapfile-vers
- make/sun/tzdb/Makefile
- make/sun/usagetracker/Makefile
- make/sun/util/Makefile
- make/sun/xawt/FILES_c_unix.gmk
- make/sun/xawt/FILES_export_unix.gmk
- make/sun/xawt/Makefile
- make/sun/xawt/mapfile-vers
- make/templates/bsd-header
- make/templates/gpl-cp-header
- make/templates/gpl-header
- make/tools/CharsetMapping/Big5.map
- make/tools/CharsetMapping/Big5.nr
- make/tools/CharsetMapping/DoubleByte-X.java.template
- make/tools/CharsetMapping/EUC_CN.map
- make/tools/CharsetMapping/EUC_KR.map
- make/tools/CharsetMapping/GBK.map
- make/tools/CharsetMapping/HKSCS2001.c2b
- make/tools/CharsetMapping/HKSCS2001.map
- make/tools/CharsetMapping/HKSCS2008.c2b
- make/tools/CharsetMapping/HKSCS2008.map
- make/tools/CharsetMapping/HKSCS_XP.c2b
- make/tools/CharsetMapping/HKSCS_XP.map
- make/tools/CharsetMapping/IBM037.c2b
- make/tools/CharsetMapping/IBM037.map
- make/tools/CharsetMapping/IBM037.nr
- make/tools/CharsetMapping/IBM1006.map
- make/tools/CharsetMapping/IBM1025.c2b
- make/tools/CharsetMapping/IBM1025.map
- make/tools/CharsetMapping/IBM1025.nr
- make/tools/CharsetMapping/IBM1026.c2b
- make/tools/CharsetMapping/IBM1026.map
- make/tools/CharsetMapping/IBM1026.nr
- make/tools/CharsetMapping/IBM1046.map
- make/tools/CharsetMapping/IBM1047.map
- make/tools/CharsetMapping/IBM1097.map
- make/tools/CharsetMapping/IBM1098.map
- make/tools/CharsetMapping/IBM1112.c2b
- make/tools/CharsetMapping/IBM1112.map
- make/tools/CharsetMapping/IBM1112.nr
- make/tools/CharsetMapping/IBM1122.c2b
- make/tools/CharsetMapping/IBM1122.map
- make/tools/CharsetMapping/IBM1122.nr
- make/tools/CharsetMapping/IBM1123.c2b
- make/tools/CharsetMapping/IBM1123.map
- make/tools/CharsetMapping/IBM1123.nr
- make/tools/CharsetMapping/IBM1124.map
- make/tools/CharsetMapping/IBM1140.c2b
- make/tools/CharsetMapping/IBM1140.map
- make/tools/CharsetMapping/IBM1141.c2b
- make/tools/CharsetMapping/IBM1141.map
- make/tools/CharsetMapping/IBM1142.c2b
- make/tools/CharsetMapping/IBM1142.map
- make/tools/CharsetMapping/IBM1143.c2b
- make/tools/CharsetMapping/IBM1143.map
- make/tools/CharsetMapping/IBM1144.c2b
- make/tools/CharsetMapping/IBM1144.map
- make/tools/CharsetMapping/IBM1145.c2b
- make/tools/CharsetMapping/IBM1145.map
- make/tools/CharsetMapping/IBM1146.c2b
- make/tools/CharsetMapping/IBM1146.map
- make/tools/CharsetMapping/IBM1147.c2b
- make/tools/CharsetMapping/IBM1147.map
- make/tools/CharsetMapping/IBM1148.c2b
- make/tools/CharsetMapping/IBM1148.map
- make/tools/CharsetMapping/IBM1149.c2b
- make/tools/CharsetMapping/IBM1149.map
- make/tools/CharsetMapping/IBM1364.c2b
- make/tools/CharsetMapping/IBM1364.map
- make/tools/CharsetMapping/IBM1381.c2b
- make/tools/CharsetMapping/IBM1381.map
- make/tools/CharsetMapping/IBM1383.c2b
- make/tools/CharsetMapping/IBM1383.map
- make/tools/CharsetMapping/IBM1383.nr
- make/tools/CharsetMapping/IBM273.c2b
- make/tools/CharsetMapping/IBM273.map
- make/tools/CharsetMapping/IBM273.nr
- make/tools/CharsetMapping/IBM277.c2b
- make/tools/CharsetMapping/IBM277.map
- make/tools/CharsetMapping/IBM277.nr
- make/tools/CharsetMapping/IBM278.c2b
- make/tools/CharsetMapping/IBM278.map
- make/tools/CharsetMapping/IBM278.nr
- make/tools/CharsetMapping/IBM280.c2b
- make/tools/CharsetMapping/IBM280.map
- make/tools/CharsetMapping/IBM280.nr
- make/tools/CharsetMapping/IBM284.c2b
- make/tools/CharsetMapping/IBM284.map
- make/tools/CharsetMapping/IBM284.nr
- make/tools/CharsetMapping/IBM285.c2b
- make/tools/CharsetMapping/IBM285.map
- make/tools/CharsetMapping/IBM285.nr
- make/tools/CharsetMapping/IBM290.c2b
- make/tools/CharsetMapping/IBM290.map
- make/tools/CharsetMapping/IBM297.c2b
- make/tools/CharsetMapping/IBM297.map
- make/tools/CharsetMapping/IBM297.nr
- make/tools/CharsetMapping/IBM300.c2b
- make/tools/CharsetMapping/IBM300.map
- make/tools/CharsetMapping/IBM420.c2b
- make/tools/CharsetMapping/IBM420.map
- make/tools/CharsetMapping/IBM420.nr
- make/tools/CharsetMapping/IBM424.c2b
- make/tools/CharsetMapping/IBM424.map
- make/tools/CharsetMapping/IBM424.nr
- make/tools/CharsetMapping/IBM437.map
- make/tools/CharsetMapping/IBM500.c2b
- make/tools/CharsetMapping/IBM500.map
- make/tools/CharsetMapping/IBM500.nr
- make/tools/CharsetMapping/IBM737.map
- make/tools/CharsetMapping/IBM775.map
- make/tools/CharsetMapping/IBM833.c2b
- make/tools/CharsetMapping/IBM833.map
- make/tools/CharsetMapping/IBM838.c2b
- make/tools/CharsetMapping/IBM838.map
- make/tools/CharsetMapping/IBM838.nr
- make/tools/CharsetMapping/IBM850.map
- make/tools/CharsetMapping/IBM852.map
- make/tools/CharsetMapping/IBM855.map
- make/tools/CharsetMapping/IBM856.map
- make/tools/CharsetMapping/IBM857.map
- make/tools/CharsetMapping/IBM858.map
- make/tools/CharsetMapping/IBM860.map
- make/tools/CharsetMapping/IBM861.map
- make/tools/CharsetMapping/IBM862.map
- make/tools/CharsetMapping/IBM863.map
- make/tools/CharsetMapping/IBM864.map
- make/tools/CharsetMapping/IBM865.map
- make/tools/CharsetMapping/IBM866.map
- make/tools/CharsetMapping/IBM868.map
- make/tools/CharsetMapping/IBM869.map
- make/tools/CharsetMapping/IBM870.c2b
- make/tools/CharsetMapping/IBM870.map
- make/tools/CharsetMapping/IBM870.nr
- make/tools/CharsetMapping/IBM871.c2b
- make/tools/CharsetMapping/IBM871.map
- make/tools/CharsetMapping/IBM871.nr
- make/tools/CharsetMapping/IBM874.map
- make/tools/CharsetMapping/IBM874.nr
- make/tools/CharsetMapping/IBM875.c2b
- make/tools/CharsetMapping/IBM875.map
- make/tools/CharsetMapping/IBM875.nr
- make/tools/CharsetMapping/IBM918.c2b
- make/tools/CharsetMapping/IBM918.map
- make/tools/CharsetMapping/IBM918.nr
- make/tools/CharsetMapping/IBM921.map
- make/tools/CharsetMapping/IBM922.map
- make/tools/CharsetMapping/IBM930.c2b
- make/tools/CharsetMapping/IBM930.map
- make/tools/CharsetMapping/IBM930.nr
- make/tools/CharsetMapping/IBM933.c2b
- make/tools/CharsetMapping/IBM933.map
- make/tools/CharsetMapping/IBM935.c2b
- make/tools/CharsetMapping/IBM935.map
- make/tools/CharsetMapping/IBM935.nr
- make/tools/CharsetMapping/IBM937.c2b
- make/tools/CharsetMapping/IBM937.map
- make/tools/CharsetMapping/IBM937.nr
- make/tools/CharsetMapping/IBM939.c2b
- make/tools/CharsetMapping/IBM939.map
- make/tools/CharsetMapping/IBM939.nr
- make/tools/CharsetMapping/IBM942.c2b
- make/tools/CharsetMapping/IBM942.map
- make/tools/CharsetMapping/IBM943.map
- make/tools/CharsetMapping/IBM943.nr
- make/tools/CharsetMapping/IBM948.c2b
- make/tools/CharsetMapping/IBM948.map
- make/tools/CharsetMapping/IBM949.map
- make/tools/CharsetMapping/IBM950.c2b
- make/tools/CharsetMapping/IBM950.map
- make/tools/CharsetMapping/IBM970.c2b
- make/tools/CharsetMapping/IBM970.map
- make/tools/CharsetMapping/ISO_8859_11.map
- make/tools/CharsetMapping/ISO_8859_13.map
- make/tools/CharsetMapping/ISO_8859_15.map
- make/tools/CharsetMapping/ISO_8859_2.map
- make/tools/CharsetMapping/ISO_8859_3.map
- make/tools/CharsetMapping/ISO_8859_4.map
- make/tools/CharsetMapping/ISO_8859_5.map
- make/tools/CharsetMapping/ISO_8859_6.map
- make/tools/CharsetMapping/ISO_8859_7.map
- make/tools/CharsetMapping/ISO_8859_8.map
- make/tools/CharsetMapping/ISO_8859_9.map
- make/tools/CharsetMapping/JIS_X_0201.c2b
- make/tools/CharsetMapping/JIS_X_0201.map
- make/tools/CharsetMapping/JIS_X_0208.map
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.nr
- make/tools/CharsetMapping/JIS_X_0208_Solaris.map
- make/tools/CharsetMapping/JIS_X_0208_Solaris.nr
- make/tools/CharsetMapping/JIS_X_0212.map
- make/tools/CharsetMapping/JIS_X_0212_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.nr
- make/tools/CharsetMapping/Johab.map
- make/tools/CharsetMapping/KOI8_R.map
- make/tools/CharsetMapping/KOI8_U.map
- make/tools/CharsetMapping/MS1250.map
- make/tools/CharsetMapping/MS1251.map
- make/tools/CharsetMapping/MS1252.map
- make/tools/CharsetMapping/MS1253.map
- make/tools/CharsetMapping/MS1254.map
- make/tools/CharsetMapping/MS1255.map
- make/tools/CharsetMapping/MS1256.map
- make/tools/CharsetMapping/MS1257.map
- make/tools/CharsetMapping/MS1258.map
- make/tools/CharsetMapping/MS874.map
- make/tools/CharsetMapping/MS932.c2b
- make/tools/CharsetMapping/MS932.map
- make/tools/CharsetMapping/MS932.nr
- make/tools/CharsetMapping/MS936.map
- make/tools/CharsetMapping/MS949.map
- make/tools/CharsetMapping/MS950.map
- make/tools/CharsetMapping/MS950.nr
- make/tools/CharsetMapping/MacArabic.map
- make/tools/CharsetMapping/MacCentralEurope.map
- make/tools/CharsetMapping/MacCroatian.map
- make/tools/CharsetMapping/MacCyrillic.map
- make/tools/CharsetMapping/MacDingbat.map
- make/tools/CharsetMapping/MacGreek.map
- make/tools/CharsetMapping/MacHebrew.map
- make/tools/CharsetMapping/MacIceland.map
- make/tools/CharsetMapping/MacRoman.map
- make/tools/CharsetMapping/MacRomania.map
- make/tools/CharsetMapping/MacSymbol.map
- make/tools/CharsetMapping/MacThai.map
- make/tools/CharsetMapping/MacTurkish.map
- make/tools/CharsetMapping/MacUkraine.map
- make/tools/CharsetMapping/Makefile
- make/tools/CharsetMapping/PCK.c2b
- make/tools/CharsetMapping/PCK.map
- make/tools/CharsetMapping/PCK.nr
- make/tools/CharsetMapping/SJIS.c2b
- make/tools/CharsetMapping/SJIS.map
- make/tools/CharsetMapping/SingleByte-X.java.template
- make/tools/CharsetMapping/TIS_620.map
- make/tools/CharsetMapping/dbcs
- make/tools/CharsetMapping/euc_tw.map
- make/tools/CharsetMapping/extsbcs
- make/tools/CharsetMapping/sbcs
- make/tools/CharsetMapping/sjis0213.map
- make/tools/GenerateCharacter/Character.c.template
- make/tools/GenerateCharacter/CharacterData00.java.template
- make/tools/GenerateCharacter/CharacterData01.java.template
- make/tools/GenerateCharacter/CharacterData02.java.template
- make/tools/GenerateCharacter/CharacterData0E.java.template
- make/tools/GenerateCharacter/CharacterDataLatin1.java.template
- make/tools/GenerateCharacter/CharacterDataPrivateUse.java.template
- make/tools/GenerateCharacter/CharacterDataUndefined.java.template
- make/tools/GenerateCharacter/Makefile
- make/tools/GenerateCharacter/check_class.c.template
- make/tools/Makefile
- make/tools/README.txt
- make/tools/UnicodeData/PropList.txt
- make/tools/UnicodeData/Scripts.txt
- make/tools/UnicodeData/SpecialCasing.txt
- make/tools/UnicodeData/UnicodeData.txt
- make/tools/UnicodeData/VERSION
- make/tools/add_gnu_debuglink/Makefile
- make/tools/add_gnu_debuglink/add_gnu_debuglink.c
- make/tools/addjsum/Makefile
- make/tools/addtorestrictedpkgs/Makefile
- make/tools/buildmetaindex/Makefile
- make/tools/cldrconverter/Makefile
- make/tools/commentchecker/Makefile
- make/tools/compile_font_config/Makefile
- make/tools/compile_properties/Makefile
- make/tools/dir_diff/Makefile
- make/tools/dtdbuilder/Makefile
- make/tools/dtdbuilder/dtds/HTMLlat1.sgml
- make/tools/dtdbuilder/dtds/HTMLspecial.sgml
- make/tools/dtdbuilder/dtds/HTMLsymbol.sgml
- make/tools/dtdbuilder/dtds/html32.dtd
- make/tools/dtdbuilder/dtds/public.map
- make/tools/fix_empty_sec_hdr_flags/Makefile
- make/tools/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c
- make/tools/freetypecheck/Makefile
- make/tools/freetypecheck/freetypecheck.c
- make/tools/generate_break_iterator/Makefile
- make/tools/generate_nimbus/Makefile
- make/tools/generatecurrencydata/Makefile
- make/tools/hasher_classes/Makefile
- make/tools/jarreorder/Makefile
- make/tools/jarsplit/Makefile
- make/tools/jdwpgen/Makefile
- make/tools/makeclasslist/Makefile
- make/tools/manifest.mf
- make/tools/msys_build_scripts/dospath.sh
- make/tools/msys_build_scripts/dospath.vbs
- make/tools/reorder/Makefile
- make/tools/reorder/tests/Exit.java
- make/tools/reorder/tests/Hello.java
- make/tools/reorder/tests/IntToString.java
- make/tools/reorder/tests/JHello.java
- make/tools/reorder/tests/LoadFrame.java
- make/tools/reorder/tests/LoadJFrame.java
- make/tools/reorder/tests/LoadToolkit.java
- make/tools/reorder/tests/Null.java
- make/tools/reorder/tests/Sleep.java
- make/tools/reorder/tools/Combine.java
- make/tools/reorder/tools/MaxTime.java
- make/tools/reorder/tools/mcount.c
- make/tools/reorder/tools/remove_mcount.c
- make/tools/reorder/tools/util-i586.il
- make/tools/reorder/tools/util-sparc.il
- make/tools/reorder/tools/util-sparcv9.il
- make/tools/sharing/README.txt
- make/tools/sharing/classlist.linux
- make/tools/sharing/classlist.macosx
- make/tools/sharing/classlist.solaris
- make/tools/sharing/classlist.windows
- make/tools/sharing/tests/GHello.java
- make/tools/sharing/tests/Hello.java
- make/tools/sharing/tests/JHello.java
- make/tools/spp/Makefile
- make/tools/src/build/tools/addjsum/AddJsum.java
- make/tools/src/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java
- make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java
- make/tools/src/build/tools/charsetmapping/DBCS.java
- make/tools/src/build/tools/charsetmapping/EUC_TW.java
- make/tools/src/build/tools/charsetmapping/HKSCS.java
- make/tools/src/build/tools/charsetmapping/JIS0213.java
- make/tools/src/build/tools/charsetmapping/Main.java
- make/tools/src/build/tools/charsetmapping/SBCS.java
- make/tools/src/build/tools/charsetmapping/Utils.java
- make/tools/src/build/tools/classfile/RemoveMethods.java
- make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java
- make/tools/src/build/tools/cldrconverter/Bundle.java
- make/tools/src/build/tools/cldrconverter/BundleGenerator.java
- make/tools/src/build/tools/cldrconverter/CLDRConverter.java
- make/tools/src/build/tools/cldrconverter/CalendarType.java
- make/tools/src/build/tools/cldrconverter/Container.java
- make/tools/src/build/tools/cldrconverter/CopyrightHeaders.java
- make/tools/src/build/tools/cldrconverter/Entry.java
- make/tools/src/build/tools/cldrconverter/IgnoredContainer.java
- make/tools/src/build/tools/cldrconverter/KeyContainer.java
- make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java
- make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java
- make/tools/src/build/tools/cldrconverter/NumberingSystemsParseHandler.java
- make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java
- make/tools/src/build/tools/cldrconverter/StringArrayElement.java
- make/tools/src/build/tools/cldrconverter/StringArrayEntry.java
- make/tools/src/build/tools/cldrconverter/StringEntry.java
- make/tools/src/build/tools/cldrconverter/SupplementDataParseHandler.java
- make/tools/src/build/tools/commentchecker/CommentChecker.java
- make/tools/src/build/tools/compilefontconfig/CompileFontConfig.java
- make/tools/src/build/tools/compileproperties/CompileProperties.java
- make/tools/src/build/tools/deps/CheckDeps.java
- make/tools/src/build/tools/deps/refs.allowed
- make/tools/src/build/tools/dirdiff/DirDiff.java
- make/tools/src/build/tools/dtdbuilder/DTDBuilder.java
- make/tools/src/build/tools/dtdbuilder/DTDInputStream.java
- make/tools/src/build/tools/dtdbuilder/DTDParser.java
- make/tools/src/build/tools/dtdbuilder/PublicMapping.java
- make/tools/src/build/tools/dtdbuilder/README.txt
- make/tools/src/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java
- make/tools/src/build/tools/generatebreakiteratordata/CharSet.java
- make/tools/src/build/tools/generatebreakiteratordata/CharacterCategory.java
- make/tools/src/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java
- make/tools/src/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java
- make/tools/src/build/tools/generatecharacter/CharacterName.java
- make/tools/src/build/tools/generatecharacter/CharacterScript.java
- make/tools/src/build/tools/generatecharacter/GenerateCharacter.java
- make/tools/src/build/tools/generatecharacter/PrintCharacterRanges.java
- make/tools/src/build/tools/generatecharacter/PropList.java
- make/tools/src/build/tools/generatecharacter/SpecialCaseMap.java
- make/tools/src/build/tools/generatecharacter/UnicodeSpec.java
- make/tools/src/build/tools/generatecharacter/Utility.java
- make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java
- make/tools/src/build/tools/generatenimbus/AbstractGradient.java
- make/tools/src/build/tools/generatenimbus/Border.java
- make/tools/src/build/tools/generatenimbus/Canvas.java
- make/tools/src/build/tools/generatenimbus/ComponentColor.java
- make/tools/src/build/tools/generatenimbus/Dimension.java
- make/tools/src/build/tools/generatenimbus/Ellipse.java
- make/tools/src/build/tools/generatenimbus/Generator.java
- make/tools/src/build/tools/generatenimbus/Gradient.java
- make/tools/src/build/tools/generatenimbus/GradientStop.java
- make/tools/src/build/tools/generatenimbus/Insets.java
- make/tools/src/build/tools/generatenimbus/Layer.java
- make/tools/src/build/tools/generatenimbus/Matte.java
- make/tools/src/build/tools/generatenimbus/ObjectFactory.java
- make/tools/src/build/tools/generatenimbus/Paint.java
- make/tools/src/build/tools/generatenimbus/PainterGenerator.java
- make/tools/src/build/tools/generatenimbus/Path.java
- make/tools/src/build/tools/generatenimbus/Point.java
- make/tools/src/build/tools/generatenimbus/RadialGradient.java
- make/tools/src/build/tools/generatenimbus/Rectangle.java
- make/tools/src/build/tools/generatenimbus/Shape.java
- make/tools/src/build/tools/generatenimbus/SynthModel.java
- make/tools/src/build/tools/generatenimbus/Typeface.java
- make/tools/src/build/tools/generatenimbus/UIColor.java
- make/tools/src/build/tools/generatenimbus/UIComponent.java
- make/tools/src/build/tools/generatenimbus/UIDefault.java
- make/tools/src/build/tools/generatenimbus/UIFont.java
- make/tools/src/build/tools/generatenimbus/UIIconRegion.java
- make/tools/src/build/tools/generatenimbus/UIProperty.java
- make/tools/src/build/tools/generatenimbus/UIRegion.java
- make/tools/src/build/tools/generatenimbus/UIState.java
- make/tools/src/build/tools/generatenimbus/UIStateType.java
- make/tools/src/build/tools/generatenimbus/UIStyle.java
- make/tools/src/build/tools/generatenimbus/Utils.java
- make/tools/src/build/tools/hasher/Hasher.java
- make/tools/src/build/tools/jarreorder/JarReorder.java
- make/tools/src/build/tools/jarsplit/JarSplit.java
- make/tools/src/build/tools/jdwpgen/AbstractCommandNode.java
- make/tools/src/build/tools/jdwpgen/AbstractGroupNode.java
- make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleTypeNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeListNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeNode.java
- make/tools/src/build/tools/jdwpgen/AltNode.java
- make/tools/src/build/tools/jdwpgen/ArrayObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayTypeNode.java
- make/tools/src/build/tools/jdwpgen/BooleanTypeNode.java
- make/tools/src/build/tools/jdwpgen/ByteTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassTypeNode.java
- make/tools/src/build/tools/jdwpgen/CommandNode.java
- make/tools/src/build/tools/jdwpgen/CommandSetNode.java
- make/tools/src/build/tools/jdwpgen/CommentNode.java
- make/tools/src/build/tools/jdwpgen/ConstantNode.java
- make/tools/src/build/tools/jdwpgen/ConstantSetNode.java
- make/tools/src/build/tools/jdwpgen/Context.java
- make/tools/src/build/tools/jdwpgen/ErrorNode.java
- make/tools/src/build/tools/jdwpgen/ErrorSetNode.java
- make/tools/src/build/tools/jdwpgen/EventNode.java
- make/tools/src/build/tools/jdwpgen/FieldTypeNode.java
- make/tools/src/build/tools/jdwpgen/FrameTypeNode.java
- make/tools/src/build/tools/jdwpgen/GroupNode.java
- make/tools/src/build/tools/jdwpgen/IntTypeNode.java
- make/tools/src/build/tools/jdwpgen/InterfaceTypeNode.java
- make/tools/src/build/tools/jdwpgen/LocationTypeNode.java
- make/tools/src/build/tools/jdwpgen/LongTypeNode.java
- make/tools/src/build/tools/jdwpgen/Main.java
- make/tools/src/build/tools/jdwpgen/MethodTypeNode.java
- make/tools/src/build/tools/jdwpgen/NameNode.java
- make/tools/src/build/tools/jdwpgen/NameValueNode.java
- make/tools/src/build/tools/jdwpgen/Node.java
- make/tools/src/build/tools/jdwpgen/ObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/OutNode.java
- make/tools/src/build/tools/jdwpgen/Parse.java
- make/tools/src/build/tools/jdwpgen/ReferenceIDTypeNode.java
- make/tools/src/build/tools/jdwpgen/ReferenceTypeNode.java
- make/tools/src/build/tools/jdwpgen/RepeatNode.java
- make/tools/src/build/tools/jdwpgen/ReplyNode.java
- make/tools/src/build/tools/jdwpgen/RootNode.java
- make/tools/src/build/tools/jdwpgen/SelectNode.java
- make/tools/src/build/tools/jdwpgen/StringObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/StringTypeNode.java
- make/tools/src/build/tools/jdwpgen/TaggedObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/TypeNode.java
- make/tools/src/build/tools/jdwpgen/UntaggedValueTypeNode.java
- make/tools/src/build/tools/jdwpgen/ValueTypeNode.java
- make/tools/src/build/tools/makeclasslist/MakeClasslist.java
- make/tools/src/build/tools/spp/Spp.java
- make/tools/src/build/tools/stripproperties/StripProperties.java
- make/tools/src/build/tools/tzdb/ChronoField.java
- make/tools/src/build/tools/tzdb/DateTimeException.java
- make/tools/src/build/tools/tzdb/LocalDate.java
- make/tools/src/build/tools/tzdb/LocalDateTime.java
- make/tools/src/build/tools/tzdb/LocalTime.java
- make/tools/src/build/tools/tzdb/TimeDefinition.java
- make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java
- make/tools/src/build/tools/tzdb/Utils.java
- make/tools/src/build/tools/tzdb/ZoneOffset.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransition.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransitionRule.java
- make/tools/src/build/tools/tzdb/ZoneRules.java
- make/tools/src/build/tools/tzdb/ZoneRulesBuilder.java
- make/tools/strip_properties/Makefile
- make/tools/swing-beans/DocBeanInfo.java
- make/tools/swing-beans/GenDocletBeanInfo.java
- make/tools/swing-beans/GenSwingBeanInfo.java
- make/tools/swing-beans/SwingBeanInfo.template
- make/tools/swing-beans/beaninfo/images/AbstractButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/BorderColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor32.gif
- make/tools/swing-beans/beaninfo/images/BoxMono16.gif
- make/tools/swing-beans/beaninfo/images/BoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor16.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor32.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono16.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono32.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JComponentColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor16.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor32.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono16.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor16.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor32.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono16.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JListColor16.gif
- make/tools/swing-beans/beaninfo/images/JListColor32.gif
- make/tools/swing-beans/beaninfo/images/JListMono16.gif
- make/tools/swing-beans/beaninfo/images/JListMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor16.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor32.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono16.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono32.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor16.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor32.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono16.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTableColor16.gif
- make/tools/swing-beans/beaninfo/images/JTableColor32.gif
- make/tools/swing-beans/beaninfo/images/JTableMono16.gif
- make/tools/swing-beans/beaninfo/images/JTableMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor16.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor32.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono16.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono32.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor16.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor32.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono16.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono32.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor16.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor32.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono16.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono32.gif
- make/tools/swing-beans/javax/swing/SwingBeanInfoBase.java
- make/tools/swing-beans/sun/swing/BeanInfoUtils.java
- make/tools/tzdb/Makefile
- makefiles/BuildJdk.gmk
- makefiles/Bundles.gmk
- makefiles/CompileDemos.gmk
- makefiles/CompileJavaClasses.gmk
- makefiles/CompileLaunchers.gmk
- makefiles/CompileNativeLibraries.gmk
- makefiles/CopyFiles.gmk
- makefiles/CopyIntoClasses.gmk
- makefiles/CopySamples.gmk
- makefiles/CreateJars.gmk
- makefiles/CreateSecurityJars.gmk
- makefiles/GenerateClasses.gmk
- makefiles/GenerateData.gmk
- makefiles/GenerateSources.gmk
- makefiles/Images.gmk
- makefiles/Import.gmk
- makefiles/Makefile
- makefiles/PatchList.solaris
- makefiles/ProfileNames.gmk
- makefiles/Profiles.gmk
- makefiles/Setup.gmk
- makefiles/SignJars.gmk
- makefiles/Tools.gmk
- makefiles/gendata/GendataBreakIterator.gmk
- makefiles/gendata/GendataFontConfig.gmk
- makefiles/gendata/GendataHtml32dtd.gmk
- makefiles/gendata/GendataTZDB.gmk
- makefiles/gendata/GendataTimeZone.gmk
- makefiles/gensrc/GensrcBuffer.gmk
- makefiles/gensrc/GensrcCLDR.gmk
- makefiles/gensrc/GensrcCharacterData.gmk
- makefiles/gensrc/GensrcCharsetCoder.gmk
- makefiles/gensrc/GensrcCharsetMapping.gmk
- makefiles/gensrc/GensrcExceptions.gmk
- makefiles/gensrc/GensrcIcons.gmk
- makefiles/gensrc/GensrcJDWP.gmk
- makefiles/gensrc/GensrcJObjC.gmk
- makefiles/gensrc/GensrcLocaleDataMetaInfo.gmk
- makefiles/gensrc/GensrcMisc.gmk
- makefiles/gensrc/GensrcProperties.gmk
- makefiles/gensrc/GensrcSwing.gmk
- makefiles/gensrc/GensrcX11Wrappers.gmk
- makefiles/jpda/jdwp/jdwp.spec
- makefiles/jprt.gmk
- makefiles/jprt.properties
- makefiles/lib/Awt2dLibraries.gmk
- makefiles/lib/CoreLibraries.gmk
- makefiles/lib/NetworkingLibraries.gmk
- makefiles/lib/NioLibraries.gmk
- makefiles/lib/PlatformLibraries.gmk
- makefiles/lib/SecurityLibraries.gmk
- makefiles/lib/ServiceabilityLibraries.gmk
- makefiles/lib/SoundLibraries.gmk
- makefiles/mapfiles/launchers/mapfile-sparc
- makefiles/mapfiles/launchers/mapfile-sparcv9
- makefiles/mapfiles/launchers/mapfile-x86
- makefiles/mapfiles/launchers/mapfile-x86_64
- makefiles/mapfiles/libattach/mapfile-linux
- makefiles/mapfiles/libattach/mapfile-solaris
- makefiles/mapfiles/libattach/reorder-windows-x86
- makefiles/mapfiles/libattach/reorder-windows-x86_64
- makefiles/mapfiles/libawt/mapfile-mawt-vers
- makefiles/mapfiles/libawt/mapfile-vers
- makefiles/mapfiles/libawt/mapfile-vers-linux
- makefiles/mapfiles/libawt_headless/mapfile-vers
- makefiles/mapfiles/libawt_headless/reorder-sparc
- makefiles/mapfiles/libawt_headless/reorder-sparcv9
- makefiles/mapfiles/libawt_headless/reorder-x86
- makefiles/mapfiles/libawt_xawt/mapfile-vers
- makefiles/mapfiles/libdcpr/mapfile-vers
- makefiles/mapfiles/libdt_socket/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk
- makefiles/mapfiles/libhprof/mapfile-vers
- makefiles/mapfiles/libinstrument/mapfile-vers
- makefiles/mapfiles/libj2gss/mapfile-vers
- makefiles/mapfiles/libj2pcsc/mapfile-vers
- makefiles/mapfiles/libj2pkcs11/mapfile-vers
- makefiles/mapfiles/libj2ucrypto/mapfile-vers
- makefiles/mapfiles/libjaas/mapfile-vers
- makefiles/mapfiles/libjava/mapfile-vers
- makefiles/mapfiles/libjava/reorder-sparc
- makefiles/mapfiles/libjava/reorder-sparcv9
- makefiles/mapfiles/libjava/reorder-x86
- makefiles/mapfiles/libjava_crw_demo/mapfile-vers
- makefiles/mapfiles/libjawt/mapfile-vers
- makefiles/mapfiles/libjdga/mapfile-vers
- makefiles/mapfiles/libjdwp/mapfile-vers
- makefiles/mapfiles/libjfr/mapfile-vers
- makefiles/mapfiles/libjli/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers-closed
- makefiles/mapfiles/libjpeg/reorder-sparc
- makefiles/mapfiles/libjpeg/reorder-sparcv9
- makefiles/mapfiles/libjpeg/reorder-x86
- makefiles/mapfiles/libjsdt/mapfile-vers
- makefiles/mapfiles/libjsound/mapfile-vers
- makefiles/mapfiles/libjsoundalsa/mapfile-vers
- makefiles/mapfiles/libkcms/mapfile-vers
- makefiles/mapfiles/liblcms/mapfile-vers
- makefiles/mapfiles/libmanagement/mapfile-vers
- makefiles/mapfiles/libmlib_image/mapfile-vers
- makefiles/mapfiles/libnet/mapfile-vers
- makefiles/mapfiles/libnio/mapfile-linux
- makefiles/mapfiles/libnio/mapfile-macosx
- makefiles/mapfiles/libnio/mapfile-solaris
- makefiles/mapfiles/libnio/reorder-sparc
- makefiles/mapfiles/libnio/reorder-sparcv9
- makefiles/mapfiles/libnio/reorder-x86
- makefiles/mapfiles/libnpt/mapfile-vers
- makefiles/mapfiles/libsctp/mapfile-vers
- makefiles/mapfiles/libsplashscreen/mapfile-vers
- makefiles/mapfiles/libsunec/mapfile-vers
- makefiles/mapfiles/libt2k/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers-unpack200
- makefiles/mapfiles/libverify/mapfile-vers
- makefiles/mapfiles/libverify/reorder-sparc
- makefiles/mapfiles/libverify/reorder-sparcv9
- makefiles/mapfiles/libverify/reorder-x86
- makefiles/mapfiles/libzip/mapfile-vers
- makefiles/mapfiles/libzip/reorder-sparc
- makefiles/mapfiles/libzip/reorder-sparcv9
- makefiles/mapfiles/libzip/reorder-x86
- makefiles/profile-includes.txt
- makefiles/profile-rtjar-includes.txt
- makefiles/scripts/addNotices.sh
- makefiles/scripts/genCharsetProvider.sh
- makefiles/scripts/genExceptions.sh
- makefiles/scripts/localelist.sh
- makefiles/sun/awt/ToBin.java
- makefiles/sun/osxapp/ToBin.java
- test/java/lang/instrument/PremainClass/NoPremainAgent.sh
- test/java/lang/instrument/PremainClass/PremainClassTest.sh
- test/java/lang/instrument/PremainClass/ZeroArgPremainAgent.sh
- test/java/text/Bidi/Bug6665028.java
- 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
- test/sun/management/jmxremote/bootstrap/solaris-i586/launcher
- test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher

Changeset: ad44a8473b3f
Author:    lana
Date:      2013-12-03 10:48 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ad44a8473b3f

Merge


Changeset: e4499a6529e8
Author:    amurillo
Date:      2013-12-03 12:37 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e4499a6529e8

8029421: Add java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java to exclude list
Reviewed-by: alanb, jcoomes

! test/ProblemList.txt

Changeset: e9cd2dfd545f
Author:    lana
Date:      2013-12-03 15:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e9cd2dfd545f

Merge

- make/PatchList.solaris
- make/altclasses/Makefile
- make/apple/Makefile
- make/apple/applescript/Makefile
- make/bridge/AccessBridgeJava/Makefile
- make/bridge/JAWTAccessBridge/Files_cpp.gmk
- make/bridge/JAWTAccessBridge/Makefile
- make/bridge/Jabswitch/Makefile
- make/bridge/Jaccess/Makefile
- make/bridge/JavaAccessBridge/Files_cpp.gmk
- make/bridge/JavaAccessBridge/Makefile
- make/bridge/Makefile
- make/bridge/WindowsAccessBridge/Files_cpp.gmk
- make/bridge/WindowsAccessBridge/Makefile
- make/com/Makefile
- make/com/apple/Makefile
- make/com/apple/osx/Makefile
- make/com/apple/osxui/Makefile
- make/com/oracle/Makefile
- make/com/oracle/jfr/Makefile
- make/com/oracle/net/Makefile
- make/com/oracle/nio/Makefile
- make/com/oracle/security/ucrypto/FILES_c.gmk
- make/com/oracle/security/ucrypto/Makefile
- make/com/oracle/security/ucrypto/mapfile-vers
- make/com/oracle/util/Makefile
- make/com/sun/Makefile
- make/com/sun/crypto/provider/Makefile
- make/com/sun/demo/Makefile
- make/com/sun/demo/jvmti/Makefile
- make/com/sun/demo/jvmti/hprof/Makefile
- make/com/sun/image/Makefile
- make/com/sun/jarsigner/Makefile
- make/com/sun/java/Makefile
- make/com/sun/java/browser/Makefile
- make/com/sun/java/browser/dom/Makefile
- make/com/sun/java/browser/net/Makefile
- make/com/sun/java/pack/FILES_cpp.gmk
- make/com/sun/java/pack/Makefile
- make/com/sun/java/pack/mapfile-vers
- make/com/sun/java/pack/mapfile-vers-unpack200
- make/com/sun/java/pack/prop/Makefile
- make/com/sun/jmx/Makefile
- make/com/sun/jmx/snmp/Makefile
- make/com/sun/jndi/Makefile
- make/com/sun/jndi/cosnaming/Makefile
- make/com/sun/jndi/dns/Makefile
- make/com/sun/jndi/ldap/Makefile
- make/com/sun/jndi/rmi/Makefile
- make/com/sun/jndi/rmi/registry/Makefile
- make/com/sun/jndi/toolkit/Makefile
- make/com/sun/net/httpserver/Makefile
- make/com/sun/net/ssl/Makefile
- make/com/sun/nio/Makefile
- make/com/sun/nio/sctp/Exportedfiles.gmk
- make/com/sun/nio/sctp/FILES_c.gmk
- make/com/sun/nio/sctp/FILES_java.gmk
- make/com/sun/nio/sctp/Makefile
- make/com/sun/nio/sctp/mapfile-vers
- make/com/sun/org/Makefile
- make/com/sun/org/apache/Makefile
- make/com/sun/org/apache/xml/Makefile
- make/com/sun/rowset/Makefile
- make/com/sun/security/Makefile
- make/com/sun/security/auth/FILES_java.gmk
- make/com/sun/security/auth/Makefile
- make/com/sun/security/auth/module/FILES_c_solaris.gmk
- make/com/sun/security/auth/module/FILES_c_unix.gmk
- make/com/sun/security/auth/module/FILES_c_windows.gmk
- make/com/sun/security/auth/module/FILES_export_solaris.gmk
- make/com/sun/security/auth/module/FILES_export_unix.gmk
- make/com/sun/security/auth/module/FILES_export_windows.gmk
- make/com/sun/security/auth/module/FILES_java.gmk
- make/com/sun/security/auth/module/Makefile
- make/com/sun/security/auth/module/mapfile-vers
- make/com/sun/security/jgss/Makefile
- make/com/sun/security/ntlm/Makefile
- make/com/sun/security/sasl/Makefile
- make/com/sun/sql/FILES_java.gmk
- make/com/sun/sql/Makefile
- make/com/sun/tools/Makefile
- make/com/sun/tools/attach/Exportedfiles.gmk
- make/com/sun/tools/attach/FILES_c.gmk
- make/com/sun/tools/attach/FILES_java.gmk
- make/com/sun/tools/attach/Makefile
- make/com/sun/tools/attach/mapfile-bsd
- make/com/sun/tools/attach/mapfile-linux
- make/com/sun/tools/attach/mapfile-solaris
- make/com/sun/tracing/Makefile
- make/com/sun/tracing/dtrace/Makefile
- make/common/BuildToolJar.gmk
- make/common/CancelImplicits.gmk
- make/common/Classes.gmk
- make/common/Cscope.gmk
- make/common/Defs-linux.gmk
- make/common/Defs-macosx.gmk
- make/common/Defs-solaris.gmk
- make/common/Defs-windows.gmk
- make/common/Defs.gmk
- make/common/Demo.gmk
- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/Program.gmk
- make/common/Release-macosx.gmk
- make/common/Release.gmk
- make/common/Rules.gmk
- make/common/Sanity.gmk
- make/common/Subdirs.gmk
- make/common/internal/Defs-corba.gmk
- make/common/internal/Defs-jaxp.gmk
- make/common/internal/Defs-jaxws.gmk
- make/common/internal/Defs-langtools.gmk
- make/common/internal/ImportComponents.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/internal/Resources.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-llvm.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Defs-control.gmk
- make/common/shared/Defs-java.gmk
- make/common/shared/Defs-javadoc.gmk
- make/common/shared/Defs-linux.gmk
- make/common/shared/Defs-macosx.gmk
- make/common/shared/Defs-solaris.gmk
- make/common/shared/Defs-utils.gmk
- make/common/shared/Defs-versions.gmk
- make/common/shared/Defs-windows.gmk
- make/common/shared/Defs.gmk
- make/common/shared/Platform.gmk
- make/common/shared/PrivateDefs.gmk-example
- make/common/shared/Sanity-Settings.gmk
- make/common/shared/Sanity.gmk
- make/docs/CORE_PKGS.gmk
- make/docs/Makefile
- make/docs/NON_CORE_PKGS.gmk
- make/docs/Notes.html
- make/java/Makefile
- make/java/applet/Makefile
- make/java/awt/Makefile
- make/java/beans/Makefile
- make/java/fdlibm/FILES_c.gmk
- make/java/fdlibm/Makefile
- make/java/instrument/Makefile
- make/java/instrument/mapfile-vers
- make/java/invoke/Makefile
- make/java/jar/Makefile
- make/java/java/Exportedfiles.gmk
- make/java/java/FILES_c.gmk
- make/java/java/FILES_java.gmk
- make/java/java/Makefile
- make/java/java/genlocales.gmk
- make/java/java/localegen.sh
- make/java/java/localelist.sh
- make/java/java/mapfile-vers
- make/java/java/reflect/Makefile
- make/java/java/reorder-i586
- make/java/java/reorder-sparc
- make/java/java/reorder-sparcv9
- make/java/java_crw_demo/Makefile
- make/java/java_crw_demo/mapfile-vers
- make/java/java_hprof_demo/Makefile
- make/java/java_hprof_demo/mapfile-vers
- make/java/jexec/Makefile
- make/java/jli/Makefile
- make/java/jli/mapfile-vers
- make/java/jobjc/Makefile
- make/java/jvm/Makefile
- make/java/logging/Makefile
- make/java/main/Makefile
- make/java/main/java/Makefile
- make/java/main/java/mapfile-amd64
- make/java/main/java/mapfile-i586
- make/java/main/java/mapfile-sparc
- make/java/main/java/mapfile-sparcv9
- make/java/main/javaw/Makefile
- make/java/management/Exportedfiles.gmk
- make/java/management/FILES_c.gmk
- make/java/management/Makefile
- make/java/management/mapfile-vers
- make/java/math/Makefile
- make/java/net/FILES_c.gmk
- make/java/net/Makefile
- make/java/net/mapfile-vers
- make/java/nio/Exportedfiles.gmk
- make/java/nio/FILES_c.gmk
- make/java/nio/FILES_java.gmk
- make/java/nio/Makefile
- make/java/nio/addNotices.sh
- make/java/nio/genBuffer.sh
- make/java/nio/genCharsetProvider.sh
- make/java/nio/genCoder.sh
- make/java/nio/genExceptions.sh
- make/java/nio/mapfile-bsd
- make/java/nio/mapfile-linux
- make/java/nio/mapfile-solaris
- make/java/nio/reorder-i586
- make/java/nio/reorder-sparc
- make/java/nio/reorder-sparcv9
- make/java/npt/Makefile
- make/java/npt/mapfile-vers
- make/java/redist/Makefile
- make/java/redist/fonts/Makefile
- make/java/redist/sajdi/Makefile
- make/java/rmi/Makefile
- make/java/security/Makefile
- make/java/sql/Makefile
- make/java/sun_nio/FILES_java.gmk
- make/java/sun_nio/Makefile
- make/java/text/Makefile
- make/java/text/base/FILES_java.gmk
- make/java/text/base/Makefile
- make/java/text/bidi/Makefile
- make/java/time/Makefile
- make/java/util/FILES_java.gmk
- make/java/util/FILES_properties.gmk
- make/java/util/Makefile
- make/java/verify/Makefile
- make/java/verify/mapfile-vers
- make/java/verify/reorder-i586
- make/java/verify/reorder-sparc
- make/java/verify/reorder-sparcv9
- make/java/version/Makefile
- make/java/zip/FILES_c.gmk
- make/java/zip/FILES_java.gmk
- make/java/zip/Makefile
- make/java/zip/mapfile-vers
- make/java/zip/reorder-i586
- make/java/zip/reorder-sparc
- make/java/zip/reorder-sparcv9
- make/javax/Makefile
- make/javax/accessibility/Makefile
- make/javax/crypto/Defs-jce.gmk
- make/javax/crypto/Makefile
- make/javax/crypto/policy/limited/LIMITED
- make/javax/crypto/policy/limited/default_local.policy
- make/javax/crypto/policy/limited/exempt_local.policy
- make/javax/crypto/policy/unlimited/UNLIMITED
- make/javax/crypto/policy/unlimited/default_US_export.policy
- make/javax/crypto/policy/unlimited/default_local.policy
- make/javax/imageio/Makefile
- make/javax/management/Makefile
- make/javax/others/Makefile
- make/javax/print/Makefile
- make/javax/rmi/Makefile
- make/javax/rmi/ssl/Makefile
- make/javax/security/Makefile
- make/javax/sound/FILES_c.gmk
- make/javax/sound/Makefile
- make/javax/sound/SoundDefs.gmk
- make/javax/sound/jsoundalsa/Makefile
- make/javax/sound/jsoundalsa/mapfile-vers
- make/javax/sound/jsoundds/Makefile
- make/javax/sound/mapfile-vers
- make/javax/sql/Makefile
- make/javax/swing/FILES.gmk
- make/javax/swing/Makefile
- make/javax/swing/beaninfo/FILES.gmk
- make/javax/swing/beaninfo/Makefile
- make/javax/swing/beaninfo/SwingBeans.gmk
- make/javax/swing/beaninfo/manifest
- make/javax/swing/html32dtd/Makefile
- make/javax/swing/plaf/FILES.gmk
- make/javax/swing/plaf/Makefile
- make/jdk/Makefile
- make/jdk_generic_profile.sh
- make/jpda/Makefile
- make/jpda/back/Makefile
- make/jpda/back/mapfile-vers
- make/jpda/bdi/Makefile
- make/jpda/expr/Makefile
- make/jpda/front/Makefile
- make/jpda/gui/Makefile
- make/jpda/jdwp/Makefile
- make/jpda/jdwp/jdwp.spec
- make/jpda/transport/Makefile
- make/jpda/transport/shmem/Makefile
- make/jpda/transport/shmem/mapfile-vers
- make/jpda/transport/socket/Makefile
- make/jpda/transport/socket/mapfile-vers
- make/jpda/tty/Makefile
- make/jprt.gmk
- make/jprt.properties
- make/launchers/Makefile
- make/launchers/Makefile.launcher
- make/mkdemo/Makefile
- make/mkdemo/applets/Animator/Makefile
- make/mkdemo/applets/ArcTest/Makefile
- make/mkdemo/applets/BarChart/Makefile
- make/mkdemo/applets/Blink/Makefile
- make/mkdemo/applets/CardTest/Makefile
- make/mkdemo/applets/Clock/Makefile
- make/mkdemo/applets/DitherTest/Makefile
- make/mkdemo/applets/DrawTest/Makefile
- make/mkdemo/applets/Fractal/Makefile
- make/mkdemo/applets/GraphLayout/Makefile
- make/mkdemo/applets/GraphicsTest/Makefile
- make/mkdemo/applets/JumpingBox/Makefile
- make/mkdemo/applets/Makefile
- make/mkdemo/applets/MoleculeViewer/Makefile
- make/mkdemo/applets/NervousText/Makefile
- make/mkdemo/applets/SimpleGraph/Makefile
- make/mkdemo/applets/SortDemo/Makefile
- make/mkdemo/applets/SpreadSheet/Makefile
- make/mkdemo/applets/TicTacToe/Makefile
- make/mkdemo/applets/WireFrame/Makefile
- make/mkdemo/jfc/CodePointIM/Makefile
- make/mkdemo/jfc/FileChooserDemo/Makefile
- make/mkdemo/jfc/Font2DTest/Makefile
- make/mkdemo/jfc/Java2D/Makefile
- make/mkdemo/jfc/Laffy/Makefile
- make/mkdemo/jfc/Makefile
- make/mkdemo/jfc/Metalworks/Makefile
- make/mkdemo/jfc/Notepad/Makefile
- make/mkdemo/jfc/SampleTree/Makefile
- make/mkdemo/jfc/Stylepad/Makefile
- make/mkdemo/jfc/SwingApplet/Makefile
- make/mkdemo/jfc/SwingSet2/Makefile
- make/mkdemo/jfc/SwingSet3/Makefile
- make/mkdemo/jfc/TableExample/Makefile
- make/mkdemo/jfc/TransparentRuler/Makefile
- make/mkdemo/jni/Makefile
- make/mkdemo/jni/Poller/Makefile
- make/mkdemo/jpda/Makefile
- make/mkdemo/jvmti/Makefile
- make/mkdemo/jvmti/README.txt
- make/mkdemo/jvmti/compiledMethodLoad/Makefile
- make/mkdemo/jvmti/gctest/Makefile
- make/mkdemo/jvmti/heapTracker/Makefile
- make/mkdemo/jvmti/heapViewer/Makefile
- make/mkdemo/jvmti/hprof/Makefile
- make/mkdemo/jvmti/mapfile-vers
- make/mkdemo/jvmti/minst/Makefile
- make/mkdemo/jvmti/mtrace/Makefile
- make/mkdemo/jvmti/versionCheck/Makefile
- make/mkdemo/jvmti/waiters/Makefile
- make/mkdemo/management/FullThreadDump/Makefile
- make/mkdemo/management/JTop/Makefile
- make/mkdemo/management/Makefile
- make/mkdemo/management/MemoryMonitor/Makefile
- make/mkdemo/management/README.txt
- make/mkdemo/management/VerboseGC/Makefile
- make/mkdemo/nio/Makefile
- make/mkdemo/nio/zipfs/Makefile
- make/mkdemo/scripting/Makefile
- make/mkdemo/scripting/jconsole-plugin/Makefile
- make/mksample/Makefile
- make/mksample/dtrace/Makefile
- make/mksample/forkjoin/Makefile
- make/mksample/forkjoin/mergesort/Makefile
- make/mksample/jmx/Makefile
- make/mksample/jmx/jmx-scandir/Makefile
- make/mksample/nbproject/Makefile
- make/mksample/nio/Makefile
- make/mksample/nio/chatserver/Makefile
- make/mksample/nio/file/Makefile
- make/mksample/nio/multicast/Makefile
- make/mksample/nio/server/Makefile
- make/mksample/scripting/Makefile
- make/mksample/scripting/scriptpad/Makefile
- make/mksample/webservices/EbayClient/Makefile
- make/mksample/webservices/EbayServer/Makefile
- make/mksample/webservices/Makefile
- make/org/Makefile
- make/org/ietf/Makefile
- make/org/ietf/jgss/FILES_java.gmk
- make/org/ietf/jgss/Makefile
- make/org/jcp/Makefile
- make/sun/Makefile
- make/sun/applet/Makefile
- make/sun/audio/Makefile
- make/sun/awt/CondenseRules.awk
- make/sun/awt/Depend.mak
- make/sun/awt/Depend.sed
- make/sun/awt/FILES_c_unix.gmk
- make/sun/awt/FILES_c_windows.gmk
- make/sun/awt/FILES_export_unix.gmk
- make/sun/awt/FILES_export_windows.gmk
- make/sun/awt/Makefile
- make/sun/awt/README
- make/sun/awt/ToBin.java
- make/sun/awt/make.depend
- make/sun/awt/mapfile-mawt-vers
- make/sun/awt/mapfile-vers
- make/sun/awt/mapfile-vers-bsd
- make/sun/awt/mapfile-vers-linux
- make/sun/awt/mawt.gmk
- make/sun/cldr/Makefile
- make/sun/cmm/Makefile
- make/sun/cmm/kcms/FILES_c_unix.gmk
- make/sun/cmm/kcms/FILES_c_windows.gmk
- make/sun/cmm/kcms/Makefile
- make/sun/cmm/kcms/mapfile-vers
- make/sun/cmm/lcms/FILES_c_unix.gmk
- make/sun/cmm/lcms/FILES_c_windows.gmk
- make/sun/cmm/lcms/Makefile
- make/sun/cmm/lcms/mapfile-vers
- make/sun/dcpr/FILES_c.gmk
- make/sun/dcpr/Makefile
- make/sun/dcpr/mapfile-vers
- make/sun/font/FILES_c.gmk
- make/sun/font/Makefile
- make/sun/font/mapfile-vers
- make/sun/font/mapfile-vers.openjdk
- make/sun/font/reorder-i586
- make/sun/font/reorder-sparc
- make/sun/font/reorder-sparcv9
- make/sun/font/t2k/FILES_c.gmk
- make/sun/font/t2k/Makefile
- make/sun/font/t2k/mapfile-vers
- make/sun/headless/Makefile
- make/sun/headless/mapfile-vers
- make/sun/headless/reorder-i586
- make/sun/headless/reorder-sparc
- make/sun/headless/reorder-sparcv9
- make/sun/image/Makefile
- make/sun/image/generic/FILES_c.gmk
- make/sun/image/generic/Makefile
- make/sun/image/generic/mapfile-vers
- make/sun/image/vis/FILES_c.gmk
- make/sun/image/vis/Makefile
- make/sun/jar/Makefile
- make/sun/javazic/Makefile
- make/sun/javazic/javatz/fullset.txt
- make/sun/javazic/javatz/java_11_ids.txt
- make/sun/javazic/javatz/java_us_ids.txt
- make/sun/javazic/javatz/java_win_ids.txt
- make/sun/javazic/javatz/java_zone_ids.txt
- make/sun/javazic/javatz/jdk1.1.x_zone_ids.txt
- make/sun/javazic/tzdata/VERSION
- make/sun/javazic/tzdata/africa
- make/sun/javazic/tzdata/antarctica
- make/sun/javazic/tzdata/asia
- make/sun/javazic/tzdata/australasia
- make/sun/javazic/tzdata/backward
- make/sun/javazic/tzdata/etcetera
- make/sun/javazic/tzdata/europe
- make/sun/javazic/tzdata/factory
- make/sun/javazic/tzdata/gmt
- make/sun/javazic/tzdata/iso3166.tab
- make/sun/javazic/tzdata/jdk11_backward
- make/sun/javazic/tzdata/leapseconds
- make/sun/javazic/tzdata/northamerica
- make/sun/javazic/tzdata/pacificnew
- make/sun/javazic/tzdata/solar87
- make/sun/javazic/tzdata/solar88
- make/sun/javazic/tzdata/solar89
- make/sun/javazic/tzdata/southamerica
- make/sun/javazic/tzdata/systemv
- make/sun/javazic/tzdata/zone.tab
- make/sun/javazic/tzdata_jdk/gmt
- make/sun/javazic/tzdata_jdk/jdk11_backward
- make/sun/javazic/tzdata_jdk/jdk11_full_backward
- make/sun/jawt/Depend.mak
- make/sun/jawt/Depend.sed
- make/sun/jawt/Makefile
- make/sun/jawt/make.depend
- make/sun/jawt/mapfile-vers
- make/sun/jconsole/FILES.gmk
- make/sun/jconsole/Makefile
- make/sun/jdga/Makefile
- make/sun/jdga/mapfile-vers
- make/sun/jpeg/FILES_c.gmk
- make/sun/jpeg/Makefile
- make/sun/jpeg/mapfile-vers
- make/sun/jpeg/mapfile-vers-closed
- make/sun/jpeg/reorder-i586
- make/sun/jpeg/reorder-sparc
- make/sun/jpeg/reorder-sparcv9
- make/sun/launcher/Makefile
- make/sun/lwawt/FILES_c_macosx.gmk
- make/sun/lwawt/FILES_export_macosx.gmk
- make/sun/lwawt/Makefile
- make/sun/management/Makefile
- make/sun/management/jmxremote/Makefile
- make/sun/management/snmp/Makefile
- make/sun/misc/Makefile
- make/sun/native2ascii/Makefile
- make/sun/net/FILES_java.gmk
- make/sun/net/Makefile
- make/sun/net/others/Makefile
- make/sun/net/spi/Makefile
- make/sun/net/spi/nameservice/Makefile
- make/sun/net/spi/nameservice/dns/Makefile
- make/sun/nio/Makefile
- make/sun/nio/cs/FILES_java.gmk
- make/sun/nio/cs/Makefile
- make/sun/osxapp/Makefile
- make/sun/osxapp/ToBin.java
- make/sun/pisces/Makefile
- make/sun/rmi/Makefile
- make/sun/rmi/cgi/Makefile
- make/sun/rmi/oldtools/FILES_java.gmk
- make/sun/rmi/oldtools/Makefile
- make/sun/rmi/registry/Makefile
- make/sun/rmi/rmi/Makefile
- make/sun/rmi/rmi/mapfile-vers
- make/sun/rmi/rmic/FILES.gmk
- make/sun/rmi/rmic/Makefile
- make/sun/rmi/rmid/Makefile
- make/sun/security/Makefile
- make/sun/security/action/Makefile
- make/sun/security/ec/FILES_c.gmk
- make/sun/security/ec/Makefile
- make/sun/security/ec/mapfile-vers
- make/sun/security/jgss/Makefile
- make/sun/security/jgss/wrapper/FILES_c.gmk
- make/sun/security/jgss/wrapper/Makefile
- make/sun/security/jgss/wrapper/mapfile-vers
- make/sun/security/krb5/FILES_c_windows.gmk
- make/sun/security/krb5/Makefile
- make/sun/security/mscapi/FILES_cpp.gmk
- make/sun/security/mscapi/Makefile
- make/sun/security/other/Makefile
- make/sun/security/pkcs11/FILES_c.gmk
- make/sun/security/pkcs11/Makefile
- make/sun/security/pkcs11/mapfile-vers
- make/sun/security/smartcardio/FILES_c.gmk
- make/sun/security/smartcardio/Makefile
- make/sun/security/smartcardio/mapfile-vers
- make/sun/security/tools/Makefile
- make/sun/security/util/Makefile
- make/sun/serialver/Makefile
- make/sun/splashscreen/FILES_c.gmk
- make/sun/splashscreen/Makefile
- make/sun/splashscreen/mapfile-vers
- make/sun/text/FILES_java.gmk
- make/sun/text/FILES_properties.gmk
- make/sun/text/Makefile
- make/sun/tools/Makefile
- make/sun/tracing/Makefile
- make/sun/tracing/dtrace/Makefile
- make/sun/tracing/dtrace/mapfile-vers
- make/sun/tzdb/Makefile
- make/sun/usagetracker/Makefile
- make/sun/util/Makefile
- make/sun/xawt/FILES_c_unix.gmk
- make/sun/xawt/FILES_export_unix.gmk
- make/sun/xawt/Makefile
- make/sun/xawt/mapfile-vers
- make/templates/bsd-header
- make/templates/gpl-cp-header
- make/templates/gpl-header
- make/tools/CharsetMapping/Big5.map
- make/tools/CharsetMapping/Big5.nr
- make/tools/CharsetMapping/DoubleByte-X.java.template
- make/tools/CharsetMapping/EUC_CN.map
- make/tools/CharsetMapping/EUC_KR.map
- make/tools/CharsetMapping/GBK.map
- make/tools/CharsetMapping/HKSCS2001.c2b
- make/tools/CharsetMapping/HKSCS2001.map
- make/tools/CharsetMapping/HKSCS2008.c2b
- make/tools/CharsetMapping/HKSCS2008.map
- make/tools/CharsetMapping/HKSCS_XP.c2b
- make/tools/CharsetMapping/HKSCS_XP.map
- make/tools/CharsetMapping/IBM037.c2b
- make/tools/CharsetMapping/IBM037.map
- make/tools/CharsetMapping/IBM037.nr
- make/tools/CharsetMapping/IBM1006.map
- make/tools/CharsetMapping/IBM1025.c2b
- make/tools/CharsetMapping/IBM1025.map
- make/tools/CharsetMapping/IBM1025.nr
- make/tools/CharsetMapping/IBM1026.c2b
- make/tools/CharsetMapping/IBM1026.map
- make/tools/CharsetMapping/IBM1026.nr
- make/tools/CharsetMapping/IBM1046.map
- make/tools/CharsetMapping/IBM1047.map
- make/tools/CharsetMapping/IBM1097.map
- make/tools/CharsetMapping/IBM1098.map
- make/tools/CharsetMapping/IBM1112.c2b
- make/tools/CharsetMapping/IBM1112.map
- make/tools/CharsetMapping/IBM1112.nr
- make/tools/CharsetMapping/IBM1122.c2b
- make/tools/CharsetMapping/IBM1122.map
- make/tools/CharsetMapping/IBM1122.nr
- make/tools/CharsetMapping/IBM1123.c2b
- make/tools/CharsetMapping/IBM1123.map
- make/tools/CharsetMapping/IBM1123.nr
- make/tools/CharsetMapping/IBM1124.map
- make/tools/CharsetMapping/IBM1140.c2b
- make/tools/CharsetMapping/IBM1140.map
- make/tools/CharsetMapping/IBM1141.c2b
- make/tools/CharsetMapping/IBM1141.map
- make/tools/CharsetMapping/IBM1142.c2b
- make/tools/CharsetMapping/IBM1142.map
- make/tools/CharsetMapping/IBM1143.c2b
- make/tools/CharsetMapping/IBM1143.map
- make/tools/CharsetMapping/IBM1144.c2b
- make/tools/CharsetMapping/IBM1144.map
- make/tools/CharsetMapping/IBM1145.c2b
- make/tools/CharsetMapping/IBM1145.map
- make/tools/CharsetMapping/IBM1146.c2b
- make/tools/CharsetMapping/IBM1146.map
- make/tools/CharsetMapping/IBM1147.c2b
- make/tools/CharsetMapping/IBM1147.map
- make/tools/CharsetMapping/IBM1148.c2b
- make/tools/CharsetMapping/IBM1148.map
- make/tools/CharsetMapping/IBM1149.c2b
- make/tools/CharsetMapping/IBM1149.map
- make/tools/CharsetMapping/IBM1364.c2b
- make/tools/CharsetMapping/IBM1364.map
- make/tools/CharsetMapping/IBM1381.c2b
- make/tools/CharsetMapping/IBM1381.map
- make/tools/CharsetMapping/IBM1383.c2b
- make/tools/CharsetMapping/IBM1383.map
- make/tools/CharsetMapping/IBM1383.nr
- make/tools/CharsetMapping/IBM273.c2b
- make/tools/CharsetMapping/IBM273.map
- make/tools/CharsetMapping/IBM273.nr
- make/tools/CharsetMapping/IBM277.c2b
- make/tools/CharsetMapping/IBM277.map
- make/tools/CharsetMapping/IBM277.nr
- make/tools/CharsetMapping/IBM278.c2b
- make/tools/CharsetMapping/IBM278.map
- make/tools/CharsetMapping/IBM278.nr
- make/tools/CharsetMapping/IBM280.c2b
- make/tools/CharsetMapping/IBM280.map
- make/tools/CharsetMapping/IBM280.nr
- make/tools/CharsetMapping/IBM284.c2b
- make/tools/CharsetMapping/IBM284.map
- make/tools/CharsetMapping/IBM284.nr
- make/tools/CharsetMapping/IBM285.c2b
- make/tools/CharsetMapping/IBM285.map
- make/tools/CharsetMapping/IBM285.nr
- make/tools/CharsetMapping/IBM290.c2b
- make/tools/CharsetMapping/IBM290.map
- make/tools/CharsetMapping/IBM297.c2b
- make/tools/CharsetMapping/IBM297.map
- make/tools/CharsetMapping/IBM297.nr
- make/tools/CharsetMapping/IBM300.c2b
- make/tools/CharsetMapping/IBM300.map
- make/tools/CharsetMapping/IBM420.c2b
- make/tools/CharsetMapping/IBM420.map
- make/tools/CharsetMapping/IBM420.nr
- make/tools/CharsetMapping/IBM424.c2b
- make/tools/CharsetMapping/IBM424.map
- make/tools/CharsetMapping/IBM424.nr
- make/tools/CharsetMapping/IBM437.map
- make/tools/CharsetMapping/IBM500.c2b
- make/tools/CharsetMapping/IBM500.map
- make/tools/CharsetMapping/IBM500.nr
- make/tools/CharsetMapping/IBM737.map
- make/tools/CharsetMapping/IBM775.map
- make/tools/CharsetMapping/IBM833.c2b
- make/tools/CharsetMapping/IBM833.map
- make/tools/CharsetMapping/IBM838.c2b
- make/tools/CharsetMapping/IBM838.map
- make/tools/CharsetMapping/IBM838.nr
- make/tools/CharsetMapping/IBM850.map
- make/tools/CharsetMapping/IBM852.map
- make/tools/CharsetMapping/IBM855.map
- make/tools/CharsetMapping/IBM856.map
- make/tools/CharsetMapping/IBM857.map
- make/tools/CharsetMapping/IBM858.map
- make/tools/CharsetMapping/IBM860.map
- make/tools/CharsetMapping/IBM861.map
- make/tools/CharsetMapping/IBM862.map
- make/tools/CharsetMapping/IBM863.map
- make/tools/CharsetMapping/IBM864.map
- make/tools/CharsetMapping/IBM865.map
- make/tools/CharsetMapping/IBM866.map
- make/tools/CharsetMapping/IBM868.map
- make/tools/CharsetMapping/IBM869.map
- make/tools/CharsetMapping/IBM870.c2b
- make/tools/CharsetMapping/IBM870.map
- make/tools/CharsetMapping/IBM870.nr
- make/tools/CharsetMapping/IBM871.c2b
- make/tools/CharsetMapping/IBM871.map
- make/tools/CharsetMapping/IBM871.nr
- make/tools/CharsetMapping/IBM874.map
- make/tools/CharsetMapping/IBM874.nr
- make/tools/CharsetMapping/IBM875.c2b
- make/tools/CharsetMapping/IBM875.map
- make/tools/CharsetMapping/IBM875.nr
- make/tools/CharsetMapping/IBM918.c2b
- make/tools/CharsetMapping/IBM918.map
- make/tools/CharsetMapping/IBM918.nr
- make/tools/CharsetMapping/IBM921.map
- make/tools/CharsetMapping/IBM922.map
- make/tools/CharsetMapping/IBM930.c2b
- make/tools/CharsetMapping/IBM930.map
- make/tools/CharsetMapping/IBM930.nr
- make/tools/CharsetMapping/IBM933.c2b
- make/tools/CharsetMapping/IBM933.map
- make/tools/CharsetMapping/IBM935.c2b
- make/tools/CharsetMapping/IBM935.map
- make/tools/CharsetMapping/IBM935.nr
- make/tools/CharsetMapping/IBM937.c2b
- make/tools/CharsetMapping/IBM937.map
- make/tools/CharsetMapping/IBM937.nr
- make/tools/CharsetMapping/IBM939.c2b
- make/tools/CharsetMapping/IBM939.map
- make/tools/CharsetMapping/IBM939.nr
- make/tools/CharsetMapping/IBM942.c2b
- make/tools/CharsetMapping/IBM942.map
- make/tools/CharsetMapping/IBM943.map
- make/tools/CharsetMapping/IBM943.nr
- make/tools/CharsetMapping/IBM948.c2b
- make/tools/CharsetMapping/IBM948.map
- make/tools/CharsetMapping/IBM949.map
- make/tools/CharsetMapping/IBM950.c2b
- make/tools/CharsetMapping/IBM950.map
- make/tools/CharsetMapping/IBM970.c2b
- make/tools/CharsetMapping/IBM970.map
- make/tools/CharsetMapping/ISO_8859_11.map
- make/tools/CharsetMapping/ISO_8859_13.map
- make/tools/CharsetMapping/ISO_8859_15.map
- make/tools/CharsetMapping/ISO_8859_2.map
- make/tools/CharsetMapping/ISO_8859_3.map
- make/tools/CharsetMapping/ISO_8859_4.map
- make/tools/CharsetMapping/ISO_8859_5.map
- make/tools/CharsetMapping/ISO_8859_6.map
- make/tools/CharsetMapping/ISO_8859_7.map
- make/tools/CharsetMapping/ISO_8859_8.map
- make/tools/CharsetMapping/ISO_8859_9.map
- make/tools/CharsetMapping/JIS_X_0201.c2b
- make/tools/CharsetMapping/JIS_X_0201.map
- make/tools/CharsetMapping/JIS_X_0208.map
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.nr
- make/tools/CharsetMapping/JIS_X_0208_Solaris.map
- make/tools/CharsetMapping/JIS_X_0208_Solaris.nr
- make/tools/CharsetMapping/JIS_X_0212.map
- make/tools/CharsetMapping/JIS_X_0212_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.nr
- make/tools/CharsetMapping/Johab.map
- make/tools/CharsetMapping/KOI8_R.map
- make/tools/CharsetMapping/KOI8_U.map
- make/tools/CharsetMapping/MS1250.map
- make/tools/CharsetMapping/MS1251.map
- make/tools/CharsetMapping/MS1252.map
- make/tools/CharsetMapping/MS1253.map
- make/tools/CharsetMapping/MS1254.map
- make/tools/CharsetMapping/MS1255.map
- make/tools/CharsetMapping/MS1256.map
- make/tools/CharsetMapping/MS1257.map
- make/tools/CharsetMapping/MS1258.map
- make/tools/CharsetMapping/MS874.map
- make/tools/CharsetMapping/MS932.c2b
- make/tools/CharsetMapping/MS932.map
- make/tools/CharsetMapping/MS932.nr
- make/tools/CharsetMapping/MS936.map
- make/tools/CharsetMapping/MS949.map
- make/tools/CharsetMapping/MS950.map
- make/tools/CharsetMapping/MS950.nr
- make/tools/CharsetMapping/MacArabic.map
- make/tools/CharsetMapping/MacCentralEurope.map
- make/tools/CharsetMapping/MacCroatian.map
- make/tools/CharsetMapping/MacCyrillic.map
- make/tools/CharsetMapping/MacDingbat.map
- make/tools/CharsetMapping/MacGreek.map
- make/tools/CharsetMapping/MacHebrew.map
- make/tools/CharsetMapping/MacIceland.map
- make/tools/CharsetMapping/MacRoman.map
- make/tools/CharsetMapping/MacRomania.map
- make/tools/CharsetMapping/MacSymbol.map
- make/tools/CharsetMapping/MacThai.map
- make/tools/CharsetMapping/MacTurkish.map
- make/tools/CharsetMapping/MacUkraine.map
- make/tools/CharsetMapping/Makefile
- make/tools/CharsetMapping/PCK.c2b
- make/tools/CharsetMapping/PCK.map
- make/tools/CharsetMapping/PCK.nr
- make/tools/CharsetMapping/SJIS.c2b
- make/tools/CharsetMapping/SJIS.map
- make/tools/CharsetMapping/SingleByte-X.java.template
- make/tools/CharsetMapping/TIS_620.map
- make/tools/CharsetMapping/dbcs
- make/tools/CharsetMapping/euc_tw.map
- make/tools/CharsetMapping/extsbcs
- make/tools/CharsetMapping/sbcs
- make/tools/CharsetMapping/sjis0213.map
- make/tools/GenerateCharacter/Character.c.template
- make/tools/GenerateCharacter/CharacterData00.java.template
- make/tools/GenerateCharacter/CharacterData01.java.template
- make/tools/GenerateCharacter/CharacterData02.java.template
- make/tools/GenerateCharacter/CharacterData0E.java.template
- make/tools/GenerateCharacter/CharacterDataLatin1.java.template
- make/tools/GenerateCharacter/CharacterDataPrivateUse.java.template
- make/tools/GenerateCharacter/CharacterDataUndefined.java.template
- make/tools/GenerateCharacter/Makefile
- make/tools/GenerateCharacter/check_class.c.template
- make/tools/Makefile
- make/tools/README.txt
- make/tools/UnicodeData/PropList.txt
- make/tools/UnicodeData/Scripts.txt
- make/tools/UnicodeData/SpecialCasing.txt
- make/tools/UnicodeData/UnicodeData.txt
- make/tools/UnicodeData/VERSION
- make/tools/add_gnu_debuglink/Makefile
- make/tools/add_gnu_debuglink/add_gnu_debuglink.c
- make/tools/addjsum/Makefile
- make/tools/addtorestrictedpkgs/Makefile
- make/tools/buildmetaindex/Makefile
- make/tools/cldrconverter/Makefile
- make/tools/commentchecker/Makefile
- make/tools/compile_font_config/Makefile
- make/tools/compile_properties/Makefile
- make/tools/dir_diff/Makefile
- make/tools/dtdbuilder/Makefile
- make/tools/dtdbuilder/dtds/HTMLlat1.sgml
- make/tools/dtdbuilder/dtds/HTMLspecial.sgml
- make/tools/dtdbuilder/dtds/HTMLsymbol.sgml
- make/tools/dtdbuilder/dtds/html32.dtd
- make/tools/dtdbuilder/dtds/public.map
- make/tools/fix_empty_sec_hdr_flags/Makefile
- make/tools/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c
- make/tools/freetypecheck/Makefile
- make/tools/freetypecheck/freetypecheck.c
- make/tools/generate_break_iterator/Makefile
- make/tools/generate_nimbus/Makefile
- make/tools/generatecurrencydata/Makefile
- make/tools/hasher_classes/Makefile
- make/tools/jarreorder/Makefile
- make/tools/jarsplit/Makefile
- make/tools/jdwpgen/Makefile
- make/tools/makeclasslist/Makefile
- make/tools/manifest.mf
- make/tools/msys_build_scripts/dospath.sh
- make/tools/msys_build_scripts/dospath.vbs
- make/tools/reorder/Makefile
- make/tools/reorder/tests/Exit.java
- make/tools/reorder/tests/Hello.java
- make/tools/reorder/tests/IntToString.java
- make/tools/reorder/tests/JHello.java
- make/tools/reorder/tests/LoadFrame.java
- make/tools/reorder/tests/LoadJFrame.java
- make/tools/reorder/tests/LoadToolkit.java
- make/tools/reorder/tests/Null.java
- make/tools/reorder/tests/Sleep.java
- make/tools/reorder/tools/Combine.java
- make/tools/reorder/tools/MaxTime.java
- make/tools/reorder/tools/mcount.c
- make/tools/reorder/tools/remove_mcount.c
- make/tools/reorder/tools/util-i586.il
- make/tools/reorder/tools/util-sparc.il
- make/tools/reorder/tools/util-sparcv9.il
- make/tools/sharing/README.txt
- make/tools/sharing/classlist.linux
- make/tools/sharing/classlist.macosx
- make/tools/sharing/classlist.solaris
- make/tools/sharing/classlist.windows
- make/tools/sharing/tests/GHello.java
- make/tools/sharing/tests/Hello.java
- make/tools/sharing/tests/JHello.java
- make/tools/spp/Makefile
- make/tools/src/build/tools/addjsum/AddJsum.java
- make/tools/src/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java
- make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java
- make/tools/src/build/tools/charsetmapping/DBCS.java
- make/tools/src/build/tools/charsetmapping/EUC_TW.java
- make/tools/src/build/tools/charsetmapping/HKSCS.java
- make/tools/src/build/tools/charsetmapping/JIS0213.java
- make/tools/src/build/tools/charsetmapping/Main.java
- make/tools/src/build/tools/charsetmapping/SBCS.java
- make/tools/src/build/tools/charsetmapping/Utils.java
- make/tools/src/build/tools/classfile/RemoveMethods.java
- make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java
- make/tools/src/build/tools/cldrconverter/Bundle.java
- make/tools/src/build/tools/cldrconverter/BundleGenerator.java
- make/tools/src/build/tools/cldrconverter/CLDRConverter.java
- make/tools/src/build/tools/cldrconverter/CalendarType.java
- make/tools/src/build/tools/cldrconverter/Container.java
- make/tools/src/build/tools/cldrconverter/CopyrightHeaders.java
- make/tools/src/build/tools/cldrconverter/Entry.java
- make/tools/src/build/tools/cldrconverter/IgnoredContainer.java
- make/tools/src/build/tools/cldrconverter/KeyContainer.java
- make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java
- make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java
- make/tools/src/build/tools/cldrconverter/NumberingSystemsParseHandler.java
- make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java
- make/tools/src/build/tools/cldrconverter/StringArrayElement.java
- make/tools/src/build/tools/cldrconverter/StringArrayEntry.java
- make/tools/src/build/tools/cldrconverter/StringEntry.java
- make/tools/src/build/tools/cldrconverter/SupplementDataParseHandler.java
- make/tools/src/build/tools/commentchecker/CommentChecker.java
- make/tools/src/build/tools/compilefontconfig/CompileFontConfig.java
- make/tools/src/build/tools/compileproperties/CompileProperties.java
- make/tools/src/build/tools/deps/CheckDeps.java
- make/tools/src/build/tools/deps/refs.allowed
- make/tools/src/build/tools/dirdiff/DirDiff.java
- make/tools/src/build/tools/dtdbuilder/DTDBuilder.java
- make/tools/src/build/tools/dtdbuilder/DTDInputStream.java
- make/tools/src/build/tools/dtdbuilder/DTDParser.java
- make/tools/src/build/tools/dtdbuilder/PublicMapping.java
- make/tools/src/build/tools/dtdbuilder/README.txt
- make/tools/src/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java
- make/tools/src/build/tools/generatebreakiteratordata/CharSet.java
- make/tools/src/build/tools/generatebreakiteratordata/CharacterCategory.java
- make/tools/src/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java
- make/tools/src/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java
- make/tools/src/build/tools/generatecharacter/CharacterName.java
- make/tools/src/build/tools/generatecharacter/CharacterScript.java
- make/tools/src/build/tools/generatecharacter/GenerateCharacter.java
- make/tools/src/build/tools/generatecharacter/PrintCharacterRanges.java
- make/tools/src/build/tools/generatecharacter/PropList.java
- make/tools/src/build/tools/generatecharacter/SpecialCaseMap.java
- make/tools/src/build/tools/generatecharacter/UnicodeSpec.java
- make/tools/src/build/tools/generatecharacter/Utility.java
- make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java
- make/tools/src/build/tools/generatenimbus/AbstractGradient.java
- make/tools/src/build/tools/generatenimbus/Border.java
- make/tools/src/build/tools/generatenimbus/Canvas.java
- make/tools/src/build/tools/generatenimbus/ComponentColor.java
- make/tools/src/build/tools/generatenimbus/Dimension.java
- make/tools/src/build/tools/generatenimbus/Ellipse.java
- make/tools/src/build/tools/generatenimbus/Generator.java
- make/tools/src/build/tools/generatenimbus/Gradient.java
- make/tools/src/build/tools/generatenimbus/GradientStop.java
- make/tools/src/build/tools/generatenimbus/Insets.java
- make/tools/src/build/tools/generatenimbus/Layer.java
- make/tools/src/build/tools/generatenimbus/Matte.java
- make/tools/src/build/tools/generatenimbus/ObjectFactory.java
- make/tools/src/build/tools/generatenimbus/Paint.java
- make/tools/src/build/tools/generatenimbus/PainterGenerator.java
- make/tools/src/build/tools/generatenimbus/Path.java
- make/tools/src/build/tools/generatenimbus/Point.java
- make/tools/src/build/tools/generatenimbus/RadialGradient.java
- make/tools/src/build/tools/generatenimbus/Rectangle.java
- make/tools/src/build/tools/generatenimbus/Shape.java
- make/tools/src/build/tools/generatenimbus/SynthModel.java
- make/tools/src/build/tools/generatenimbus/Typeface.java
- make/tools/src/build/tools/generatenimbus/UIColor.java
- make/tools/src/build/tools/generatenimbus/UIComponent.java
- make/tools/src/build/tools/generatenimbus/UIDefault.java
- make/tools/src/build/tools/generatenimbus/UIFont.java
- make/tools/src/build/tools/generatenimbus/UIIconRegion.java
- make/tools/src/build/tools/generatenimbus/UIProperty.java
- make/tools/src/build/tools/generatenimbus/UIRegion.java
- make/tools/src/build/tools/generatenimbus/UIState.java
- make/tools/src/build/tools/generatenimbus/UIStateType.java
- make/tools/src/build/tools/generatenimbus/UIStyle.java
- make/tools/src/build/tools/generatenimbus/Utils.java
- make/tools/src/build/tools/hasher/Hasher.java
- make/tools/src/build/tools/jarreorder/JarReorder.java
- make/tools/src/build/tools/jarsplit/JarSplit.java
- make/tools/src/build/tools/jdwpgen/AbstractCommandNode.java
- make/tools/src/build/tools/jdwpgen/AbstractGroupNode.java
- make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleTypeNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeListNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeNode.java
- make/tools/src/build/tools/jdwpgen/AltNode.java
- make/tools/src/build/tools/jdwpgen/ArrayObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayTypeNode.java
- make/tools/src/build/tools/jdwpgen/BooleanTypeNode.java
- make/tools/src/build/tools/jdwpgen/ByteTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassTypeNode.java
- make/tools/src/build/tools/jdwpgen/CommandNode.java
- make/tools/src/build/tools/jdwpgen/CommandSetNode.java
- make/tools/src/build/tools/jdwpgen/CommentNode.java
- make/tools/src/build/tools/jdwpgen/ConstantNode.java
- make/tools/src/build/tools/jdwpgen/ConstantSetNode.java
- make/tools/src/build/tools/jdwpgen/Context.java
- make/tools/src/build/tools/jdwpgen/ErrorNode.java
- make/tools/src/build/tools/jdwpgen/ErrorSetNode.java
- make/tools/src/build/tools/jdwpgen/EventNode.java
- make/tools/src/build/tools/jdwpgen/FieldTypeNode.java
- make/tools/src/build/tools/jdwpgen/FrameTypeNode.java
- make/tools/src/build/tools/jdwpgen/GroupNode.java
- make/tools/src/build/tools/jdwpgen/IntTypeNode.java
- make/tools/src/build/tools/jdwpgen/InterfaceTypeNode.java
- make/tools/src/build/tools/jdwpgen/LocationTypeNode.java
- make/tools/src/build/tools/jdwpgen/LongTypeNode.java
- make/tools/src/build/tools/jdwpgen/Main.java
- make/tools/src/build/tools/jdwpgen/MethodTypeNode.java
- make/tools/src/build/tools/jdwpgen/NameNode.java
- make/tools/src/build/tools/jdwpgen/NameValueNode.java
- make/tools/src/build/tools/jdwpgen/Node.java
- make/tools/src/build/tools/jdwpgen/ObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/OutNode.java
- make/tools/src/build/tools/jdwpgen/Parse.java
- make/tools/src/build/tools/jdwpgen/ReferenceIDTypeNode.java
- make/tools/src/build/tools/jdwpgen/ReferenceTypeNode.java
- make/tools/src/build/tools/jdwpgen/RepeatNode.java
- make/tools/src/build/tools/jdwpgen/ReplyNode.java
- make/tools/src/build/tools/jdwpgen/RootNode.java
- make/tools/src/build/tools/jdwpgen/SelectNode.java
- make/tools/src/build/tools/jdwpgen/StringObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/StringTypeNode.java
- make/tools/src/build/tools/jdwpgen/TaggedObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/TypeNode.java
- make/tools/src/build/tools/jdwpgen/UntaggedValueTypeNode.java
- make/tools/src/build/tools/jdwpgen/ValueTypeNode.java
- make/tools/src/build/tools/makeclasslist/MakeClasslist.java
- make/tools/src/build/tools/spp/Spp.java
- make/tools/src/build/tools/stripproperties/StripProperties.java
- make/tools/src/build/tools/tzdb/ChronoField.java
- make/tools/src/build/tools/tzdb/DateTimeException.java
- make/tools/src/build/tools/tzdb/LocalDate.java
- make/tools/src/build/tools/tzdb/LocalDateTime.java
- make/tools/src/build/tools/tzdb/LocalTime.java
- make/tools/src/build/tools/tzdb/TimeDefinition.java
- make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java
- make/tools/src/build/tools/tzdb/Utils.java
- make/tools/src/build/tools/tzdb/ZoneOffset.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransition.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransitionRule.java
- make/tools/src/build/tools/tzdb/ZoneRules.java
- make/tools/src/build/tools/tzdb/ZoneRulesBuilder.java
- make/tools/strip_properties/Makefile
- make/tools/swing-beans/DocBeanInfo.java
- make/tools/swing-beans/GenDocletBeanInfo.java
- make/tools/swing-beans/GenSwingBeanInfo.java
- make/tools/swing-beans/SwingBeanInfo.template
- make/tools/swing-beans/beaninfo/images/AbstractButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/BorderColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor32.gif
- make/tools/swing-beans/beaninfo/images/BoxMono16.gif
- make/tools/swing-beans/beaninfo/images/BoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor16.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor32.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono16.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono32.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JComponentColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor16.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor32.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono16.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor16.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor32.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono16.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JListColor16.gif
- make/tools/swing-beans/beaninfo/images/JListColor32.gif
- make/tools/swing-beans/beaninfo/images/JListMono16.gif
- make/tools/swing-beans/beaninfo/images/JListMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor16.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor32.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono16.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono32.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor16.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor32.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono16.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTableColor16.gif
- make/tools/swing-beans/beaninfo/images/JTableColor32.gif
- make/tools/swing-beans/beaninfo/images/JTableMono16.gif
- make/tools/swing-beans/beaninfo/images/JTableMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor16.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor32.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono16.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono32.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor16.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor32.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono16.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono32.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor16.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor32.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono16.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono32.gif
- make/tools/swing-beans/javax/swing/SwingBeanInfoBase.java
- make/tools/swing-beans/sun/swing/BeanInfoUtils.java
- make/tools/tzdb/Makefile
- makefiles/BuildJdk.gmk
- makefiles/Bundles.gmk
- makefiles/CompileDemos.gmk
- makefiles/CompileJavaClasses.gmk
- makefiles/CompileLaunchers.gmk
- makefiles/CompileNativeLibraries.gmk
- makefiles/CopyFiles.gmk
- makefiles/CopyIntoClasses.gmk
- makefiles/CopySamples.gmk
- makefiles/CreateJars.gmk
- makefiles/CreateSecurityJars.gmk
- makefiles/GenerateClasses.gmk
- makefiles/GenerateData.gmk
- makefiles/GenerateSources.gmk
- makefiles/Images.gmk
- makefiles/Import.gmk
- makefiles/Makefile
- makefiles/PatchList.solaris
- makefiles/ProfileNames.gmk
- makefiles/Profiles.gmk
- makefiles/Setup.gmk
- makefiles/SignJars.gmk
- makefiles/Tools.gmk
- makefiles/gendata/GendataBreakIterator.gmk
- makefiles/gendata/GendataFontConfig.gmk
- makefiles/gendata/GendataHtml32dtd.gmk
- makefiles/gendata/GendataTZDB.gmk
- makefiles/gendata/GendataTimeZone.gmk
- makefiles/gensrc/GensrcBuffer.gmk
- makefiles/gensrc/GensrcCLDR.gmk
- makefiles/gensrc/GensrcCharacterData.gmk
- makefiles/gensrc/GensrcCharsetCoder.gmk
- makefiles/gensrc/GensrcCharsetMapping.gmk
- makefiles/gensrc/GensrcExceptions.gmk
- makefiles/gensrc/GensrcIcons.gmk
- makefiles/gensrc/GensrcJDWP.gmk
- makefiles/gensrc/GensrcJObjC.gmk
- makefiles/gensrc/GensrcLocaleDataMetaInfo.gmk
- makefiles/gensrc/GensrcMisc.gmk
- makefiles/gensrc/GensrcProperties.gmk
- makefiles/gensrc/GensrcSwing.gmk
- makefiles/gensrc/GensrcX11Wrappers.gmk
- makefiles/jpda/jdwp/jdwp.spec
- makefiles/jprt.gmk
- makefiles/jprt.properties
- makefiles/lib/Awt2dLibraries.gmk
- makefiles/lib/CoreLibraries.gmk
- makefiles/lib/NetworkingLibraries.gmk
- makefiles/lib/NioLibraries.gmk
- makefiles/lib/PlatformLibraries.gmk
- makefiles/lib/SecurityLibraries.gmk
- makefiles/lib/ServiceabilityLibraries.gmk
- makefiles/lib/SoundLibraries.gmk
- makefiles/mapfiles/launchers/mapfile-sparc
- makefiles/mapfiles/launchers/mapfile-sparcv9
- makefiles/mapfiles/launchers/mapfile-x86
- makefiles/mapfiles/launchers/mapfile-x86_64
- makefiles/mapfiles/libattach/mapfile-linux
- makefiles/mapfiles/libattach/mapfile-solaris
- makefiles/mapfiles/libattach/reorder-windows-x86
- makefiles/mapfiles/libattach/reorder-windows-x86_64
- makefiles/mapfiles/libawt/mapfile-mawt-vers
- makefiles/mapfiles/libawt/mapfile-vers
- makefiles/mapfiles/libawt/mapfile-vers-linux
- makefiles/mapfiles/libawt_headless/mapfile-vers
- makefiles/mapfiles/libawt_headless/reorder-sparc
- makefiles/mapfiles/libawt_headless/reorder-sparcv9
- makefiles/mapfiles/libawt_headless/reorder-x86
- makefiles/mapfiles/libawt_xawt/mapfile-vers
- makefiles/mapfiles/libdcpr/mapfile-vers
- makefiles/mapfiles/libdt_socket/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk
- makefiles/mapfiles/libhprof/mapfile-vers
- makefiles/mapfiles/libinstrument/mapfile-vers
- makefiles/mapfiles/libj2gss/mapfile-vers
- makefiles/mapfiles/libj2pcsc/mapfile-vers
- makefiles/mapfiles/libj2pkcs11/mapfile-vers
- makefiles/mapfiles/libj2ucrypto/mapfile-vers
- makefiles/mapfiles/libjaas/mapfile-vers
- makefiles/mapfiles/libjava/mapfile-vers
- makefiles/mapfiles/libjava/reorder-sparc
- makefiles/mapfiles/libjava/reorder-sparcv9
- makefiles/mapfiles/libjava/reorder-x86
- makefiles/mapfiles/libjava_crw_demo/mapfile-vers
- makefiles/mapfiles/libjawt/mapfile-vers
- makefiles/mapfiles/libjdga/mapfile-vers
- makefiles/mapfiles/libjdwp/mapfile-vers
- makefiles/mapfiles/libjfr/mapfile-vers
- makefiles/mapfiles/libjli/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers-closed
- makefiles/mapfiles/libjpeg/reorder-sparc
- makefiles/mapfiles/libjpeg/reorder-sparcv9
- makefiles/mapfiles/libjpeg/reorder-x86
- makefiles/mapfiles/libjsdt/mapfile-vers
- makefiles/mapfiles/libjsound/mapfile-vers
- makefiles/mapfiles/libjsoundalsa/mapfile-vers
- makefiles/mapfiles/libkcms/mapfile-vers
- makefiles/mapfiles/liblcms/mapfile-vers
- makefiles/mapfiles/libmanagement/mapfile-vers
- makefiles/mapfiles/libmlib_image/mapfile-vers
- makefiles/mapfiles/libnet/mapfile-vers
- makefiles/mapfiles/libnio/mapfile-linux
- makefiles/mapfiles/libnio/mapfile-macosx
- makefiles/mapfiles/libnio/mapfile-solaris
- makefiles/mapfiles/libnio/reorder-sparc
- makefiles/mapfiles/libnio/reorder-sparcv9
- makefiles/mapfiles/libnio/reorder-x86
- makefiles/mapfiles/libnpt/mapfile-vers
- makefiles/mapfiles/libsctp/mapfile-vers
- makefiles/mapfiles/libsplashscreen/mapfile-vers
- makefiles/mapfiles/libsunec/mapfile-vers
- makefiles/mapfiles/libt2k/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers-unpack200
- makefiles/mapfiles/libverify/mapfile-vers
- makefiles/mapfiles/libverify/reorder-sparc
- makefiles/mapfiles/libverify/reorder-sparcv9
- makefiles/mapfiles/libverify/reorder-x86
- makefiles/mapfiles/libzip/mapfile-vers
- makefiles/mapfiles/libzip/reorder-sparc
- makefiles/mapfiles/libzip/reorder-sparcv9
- makefiles/mapfiles/libzip/reorder-x86
- makefiles/profile-includes.txt
- makefiles/profile-rtjar-includes.txt
- makefiles/scripts/addNotices.sh
- makefiles/scripts/genCharsetProvider.sh
- makefiles/scripts/genExceptions.sh
- makefiles/scripts/localelist.sh
- makefiles/sun/awt/ToBin.java
- makefiles/sun/osxapp/ToBin.java
- test/java/lang/instrument/PremainClass/NoPremainAgent.sh
- test/java/lang/instrument/PremainClass/PremainClassTest.sh
- test/java/lang/instrument/PremainClass/ZeroArgPremainAgent.sh
- test/java/text/Bidi/Bug6665028.java
- 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
- test/sun/management/jmxremote/bootstrap/solaris-i586/launcher
- test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher


From petr.pchelko at oracle.com  Wed Dec  4 03:25:33 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 4 Dec 2013 15:25:33 +0400
Subject: <AWT Dev> [8] Review Request: 8029382 [macosx] Need test for
	JDK-7161437
In-Reply-To: <529CB828.7080904@oracle.com>
References: <529CB72D.4080902@oracle.com> <529CB828.7080904@oracle.com>
Message-ID: <9A3D20B0-EFFB-4A41-8433-65D926A9068E@oracle.com>

Hello, Sergey.

The fix looks good to me.

With best regards. Petr.

On 02.12.2013, at 20:41, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Sergey,
> 
> The fix looks fine to me.
> 
> --
> best regards,
> Anthony
> 
> On 12/02/2013 08:37 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk 8.
>> The new test is for "apple.awt.fileDialogForDirectories" property, which
>> was added in the JDK-7161437
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029382
>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8029382/webrev.00
>> 


From Sergey.Bylokhov at oracle.com  Wed Dec  4 03:27:56 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 04 Dec 2013 15:27:56 +0400
Subject: <AWT Dev> [8] Review Request: JDK-8028484 [TEST_BUG][macosx]
 closed/java/awt/MouseInfo/JContainerMousePositionTest fails
In-Reply-To: <1302C4E3-A47B-4FA3-AF24-CE2DD61224D6@oracle.com>
References: <7F3A3438-6826-4E0E-AF27-48B94500CC83@oracle.com>
	<529DA28A.5000304@oracle.com>
	<1302C4E3-A47B-4FA3-AF24-CE2DD61224D6@oracle.com>
Message-ID: <529F11BC.7090906@oracle.com>

Hi, Petr.
The fix looks good.

On 03.12.2013 16:05, Petr Pchelko wrote:
> Hello, Sergey.
>
> Thank you for the review, the new version is available here:
> Test diff: http://cr.openjdk.java.net/~pchelko/8028484/webrev_diff/
> Open diff: http://cr.openjdk.java.net/~pchelko/8028484/webrev_new.v1/
>
> With best regards. Petr.
>
> On 03.12.2013, at 13:21, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Petr.
>> Some of the swing components are accessed on non EDT.
>> On 29.11.2013 15:18, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8028484
>>> The test have been added to open:
>>> http://cr.openjdk.java.net/~pchelko/8028484/webrev_new/
>>> Here's a webrev for test changes:
>>> http://cr.openjdk.java.net/~pchelko/8028484/
>>>
>>> The main difference is that robot now has autoDelay and autoWaiForIdle.
>>>
>>> Thank you.
>>> With best regards. Petr.
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Wed Dec  4 03:38:30 2013
From: petr.pchelko at oracle.com (petr.pchelko at oracle.com)
Date: Wed, 04 Dec 2013 11:38:30 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 8028484:
	[TEST_BUG][macosx]	closed/java/awt/MouseInfo/JContainerMousePositionTest
	fails
Message-ID: <20131204113943.8A9EC62A50@hg.openjdk.java.net>

Changeset: 1490b2b2af97
Author:    pchelko
Date:      2013-12-04 15:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1490b2b2af97

8028484: [TEST_BUG][macosx] closed/java/awt/MouseInfo/JContainerMousePositionTest fails
Reviewed-by: anthony, serb

+ test/java/awt/MouseInfo/JContainerMousePositionTest.java


From sergey.bylokhov at oracle.com  Wed Dec  4 03:56:44 2013
From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com)
Date: Wed, 04 Dec 2013 11:56:44 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 8029382: [macosx] Need test for
	JDK-7161437
Message-ID: <20131204115656.9E92562A52@hg.openjdk.java.net>

Changeset: 613fdc6afb2c
Author:    serb
Date:      2013-12-04 15:55 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/613fdc6afb2c

8029382: [macosx] Need test for JDK-7161437
Reviewed-by: pchelko, anthony

+ test/java/awt/FileDialog/FileDialogForDirectories/FileDialogForDirectories.html
+ test/java/awt/FileDialog/FileDialogForDirectories/FileDialogForDirectories.java


From anthony.petrov at oracle.com  Wed Dec  4 05:18:37 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 04 Dec 2013 17:18:37 +0400
Subject: <AWT Dev> Review Request: JDK-7112454 Fix for TEST_BUG:
 java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html
 failed
In-Reply-To: <529DEE40.8020707@oracle.com>
References: <529DEE40.8020707@oracle.com>
Message-ID: <529F2BAD.4080500@oracle.com>

Looks good.

--
best regards,
Anthony

On 12/03/2013 06:44 PM, andrei.eremeev wrote:
> Hi, AWT team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-7112454
>
> The fix is available at:
> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.00/
>
> Test moved to open:
> http://cr.openjdk.java.net/~yan/7112454/webrev.00/

From alexandr.scherbatiy at oracle.com  Wed Dec  4 06:15:52 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 04 Dec 2013 18:15:52 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529E1999.5080200@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>
	<529922DD.7020605@oracle.com> <529C8326.7020401@oracle.com>
	<529CF89E.80309@oracle.com> <529DC51B.8090604@oracle.com>
	<529E1999.5080200@oracle.com>
Message-ID: <529F3918.40607@oracle.com>


   Could you review the updated fix:
     http://cr.openjdk.java.net/~alexsch/8011059/webrev.14
   - Observer and rvObserver are used to get width/hight from 
image/rvImage in SunGraphics2D
   - width and height are rounded up in the image observer wrapper
   - width and height are also rescaled for the SOMEBITS, FRAMEBITS , 
and ALLBITS infoflags

  Thanks,
  Alexandr.


On 12/3/2013 9:49 PM, Jim Graham wrote:
> Hi Alexander,
>
> There is one last thing that I think I forgot to mention in SG2D that 
> might make some other comments I made make more sense.  There is no 
> observer registered on the resolution variant in SG2D.drawHiDPIImage() 
> in the case where the resolution variant hasn't been loaded yet. 
> Basically, the lines at 3099,3100 will trigger the variant to load, 
> but there is no observer in those calls to trace it back to the guy 
> who needs to call drawImage() again.  So, the only thing I think that 
> needs to be done is that the observer needs to be wrapped and handed 
> in to those calls to getWidth/Height(observer).
>
> The rest of that method looks fine - the regular variant will be used 
> (and will trigger repaints via the code that calls into drawImage()) 
> until the base image dimensions are known enough to trigger the 
> getResolutionVariant() code, and then we might continue to use the 
> regular version until the resolution variant at least knows its 
> dimensions, and that is all OK, but we need to start using the 
> observer wrapper on the resolution variant starting at lines 3099,3100 
> in order to get the repaints to keep happening for that version of the 
> image.
>
> Arguably, in addition, the unwrapped observer probably could be used 
> on lines 3089, 3090 when you get the dimensions of the base image, but 
> since the base image will later be handed to the drawImage pipeline, 
> the observer will be registered there anyway, so that isn't a bug.  
> But, the wrapped observer needs to be used on 3099,3100 or we may 
> never repaint with the resolution variant (it will be a race condition 
> based on how fast the regular and hiDPI images load).
>
> More comments below, but that is the only remaining blocker that I can 
> see...
>
> On 12/3/13 3:48 AM, Alexander Scherbatiy wrote:
>> On 12/3/2013 1:16 AM, Jim Graham wrote:
>>> On 12/2/13 4:55 AM, Alexander Scherbatiy wrote:
>>>> On 11/30/2013 3:27 AM, Jim Graham wrote:
>>>>> 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.
>>>>      It seems that just updating the newInfo method is not enough.
>>>
>>> There were 5 or 6 places that called imageUpdate when I did a quick
>>> search and most of the calls went through newInfo.  They'd all have to
>>> be updated.  Other than that, I'm not sure why it would not be enough?
>>
>>    Consider the following scenario. There are image.png and image at 2x.png
>> files on the disk.
>>      Image image1 = Toolkit.getImage("image.png");  // load as
>> multi-resolution image
>>      Image image2 = Toolkit.getImage("image at 2x.png");  // load the image
>> from cache
>>      toolkit.prepareImage(image2,.., imageObserver2);
>>
>>     The image2 has image1 as the base image so it rescale its
>> coordinates/dimension and passes the base instead of self to the
>> imageObserver2 which does not look correct.
>
> I see your point now.  I had thought that they would be cached 
> separately, but I see now that both are inserted into the hash 
> directly.  That allows sharing if they access both manually, but it 
> complicates the observer issue.  I don't think I would have bothered 
> with sharing the Image instance with a manual reference to the @2x in 
> that case, but we should be able to handle both in a future bug fix 
> and hopefully also get rid of wrappers, but it would take some surgery 
> on the drawImage pipeline and the record keeping in the observer 
> lists.  The existing solution will work fine for @2x images and allow 
> sharing so it is good to go for now (modulo the one issue with using 
> the wrapper for the getWidth()/getHeight() I mentioned above).
>
>>>>> Also, why does ObserverCache exist? Couldn't the cache just be a
>>>>> static field on MRToolkitImage?
>>>>       MRToolkitImage can be used in drawImage(Image,..,ImageObserver)
>>>> method always with null observer. So the is no need to create the
>>>> observer cache or use a synchronization during the cache 
>>>> initialization.
>>>
>>> Maybe I'm missing something about your answer here, but I think you
>>> may have misunderstood my question.  You placed the field that holds
>>> the reference to the cache inside an inner class.  I didn't see why
>>> the reference could not be stored in the base class.  Why is there an
>>> empty inner class to wrap a single field?  In other words, why was
>>> this used:
>>>
>>>   56
>>>   57     private static class ObserverCache {
>>>   58
>>>   59         static final SoftCache INSTANCE = new SoftCache();
>>>   60     }
>>>   61
>>>
>>> Instead of just:
>>>
>>>   56
>>>   59     static final SoftCache INSTANCE = new SoftCache();
>>>   61
>>
>>     Just to not create the cache in case if MRToolkitImageis used but
>> image observers are always null. See the comment above.
>
> Ah, so this is just a micro-optimization then?  I'm not sure what you 
> mean by "always null".  It depends on whether they hand in an 
> observer, doesn't it?  The standard case of drawImage() tends to hand 
> in the Component as the observer.  In cases where we know we are using 
> a BufferedImage, we often use null, but code that uses a toolkit image 
> (or that doesn't know what the image is) should be using a non-null 
> observer or it won't paint right the first time when it triggers the 
> image loading.
>
> The cache object itself takes so little room that I don't think it is 
> worth worrying about.  If something triggers MRToolkitImage to be 
> referenced at all, then the 99% case will likely eventually involve 
> drawImage() calls with observer and an empty cache takes so little 
> room that it is probably fine to just aggressively create it at that 
> time.
>
> There is no bug or problem here, I just don't think the indirection 
> buys us anything worthwhile here...
>
>             ...jim


From alexandr.scherbatiy at oracle.com  Wed Dec  4 06:59:44 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 04 Dec 2013 18:59:44 +0400
Subject: <AWT Dev> [8] Review request for 8028212 Custom cursor HiDPI
	support
In-Reply-To: <529E0FA5.6090300@oracle.com>
References: <529E079B.6050708@oracle.com> <529E0FA5.6090300@oracle.com>
Message-ID: <529F4360.5010808@oracle.com>

On 12/3/2013 9:06 PM, Anthony Petrov wrote:
> Hi Alexander,
>
> If we go with this fix, I suggest to move the 
> CImage.Creator.resizeImageRepresentations() to the CImage class and 
> make it a member method, so that you don't need to pass a CImage 
> reference to it as an argument.
     I will update this.
>
> Also, there's the CImage.resize() method already. Why does it not work 
> for us? Having a specification for both methods (or for one, if the 
> second is unneeded) might be helpful.

      I do not know why, but SetNSImageSize (  [i 
setScalesWhenResized:TRUE], [i setSize:NSMakeSize(w, h)]) just does not 
work in this case. The high resolution representation is not chosen on
      my Mac OS X with enabled Quartz Debug.

     I tried to narrow the problem and write the cocoa code. It is 
described in https://bugs.openjdk.java.net/browse/JDK-8028212

    Thanks,
    Alexandr.

>
> However, I'm not sure if we really want to resize each representation 
> of an NSImage object to the same size. Why would we want to do that? 
> In fact, one of the representations might already have the correct 
> size, and we could use just that whenever we need it w/o wasting 
> resources on resizing each of them. If there's no representations of 
> suitable size, then we should choose the closest one and resize just 
> it to the desired size. Or am I misunderstanding anything?
>
> Also, in CCustomCursor.getImageData(), could we somehow encapsulate a 
> part (or all) of the Image vs. MultiResolutionImage logic in the 
> CImage.Creator class?
>
> PS. I'm not really an expert in Image handling code. I'd suggest 
> someone from the 2D team to review this as well. Maybe Jim could help?
>
> -- 
> best regards,
> Anthony
>
> On 12/03/2013 08:32 PM, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the fix:
>>    bug: https://bugs.openjdk.java.net/browse/JDK-8028212
>>    webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00
>>
>>    - MultiResolutionImage interface is used from the fix 8011059
>>    - NSImage with representations are created for the multi-resolution
>> cursor
>>    - NSImage representations are rescaled to the base cursor size
>>
>> Thanks,
>> Alexandr.
>>


From anthony.petrov at oracle.com  Wed Dec  4 08:24:22 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 04 Dec 2013 20:24:22 +0400
Subject: <AWT Dev> [8] Review request for 8028212 Custom cursor HiDPI
	support
In-Reply-To: <529F4360.5010808@oracle.com>
References: <529E079B.6050708@oracle.com> <529E0FA5.6090300@oracle.com>
	<529F4360.5010808@oracle.com>
Message-ID: <529F5736.2030901@oracle.com>

Thanks for the update, Alexander. I understand.

So, my only concerns that remain are:

1. The membership of the resizeImageRepresentations() method.

2. The encapsulation of the logic handling the 
Image/MultiResolutionImage case (see at the bottom of my original message).

--
best regards,
Anthony

On 12/04/2013 06:59 PM, Alexander Scherbatiy wrote:
> On 12/3/2013 9:06 PM, Anthony Petrov wrote:
>> Hi Alexander,
>>
>> If we go with this fix, I suggest to move the
>> CImage.Creator.resizeImageRepresentations() to the CImage class and
>> make it a member method, so that you don't need to pass a CImage
>> reference to it as an argument.
>      I will update this.
>>
>> Also, there's the CImage.resize() method already. Why does it not work
>> for us? Having a specification for both methods (or for one, if the
>> second is unneeded) might be helpful.
>
>       I do not know why, but SetNSImageSize (  [i
> setScalesWhenResized:TRUE], [i setSize:NSMakeSize(w, h)]) just does not
> work in this case. The high resolution representation is not chosen on
>       my Mac OS X with enabled Quartz Debug.
>
>      I tried to narrow the problem and write the cocoa code. It is
> described in https://bugs.openjdk.java.net/browse/JDK-8028212
>
>     Thanks,
>     Alexandr.
>
>>
>> However, I'm not sure if we really want to resize each representation
>> of an NSImage object to the same size. Why would we want to do that?
>> In fact, one of the representations might already have the correct
>> size, and we could use just that whenever we need it w/o wasting
>> resources on resizing each of them. If there's no representations of
>> suitable size, then we should choose the closest one and resize just
>> it to the desired size. Or am I misunderstanding anything?
>>
>> Also, in CCustomCursor.getImageData(), could we somehow encapsulate a
>> part (or all) of the Image vs. MultiResolutionImage logic in the
>> CImage.Creator class?
>>
>> PS. I'm not really an expert in Image handling code. I'd suggest
>> someone from the 2D team to review this as well. Maybe Jim could help?
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/03/2013 08:32 PM, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the fix:
>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8028212
>>>    webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00
>>>
>>>    - MultiResolutionImage interface is used from the fix 8011059
>>>    - NSImage with representations are created for the multi-resolution
>>> cursor
>>>    - NSImage representations are rescaled to the base cursor size
>>>
>>> Thanks,
>>> Alexandr.
>>>
>

From james.graham at oracle.com  Wed Dec  4 10:16:20 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 04 Dec 2013 10:16:20 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529F3918.40607@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>
	<529922DD.7020605@oracle.com> <529C8326.7020401@oracle.com>
	<529CF89E.80309@oracle.com> <529DC51B.8090604@oracle.com>
	<529E1999.5080200@oracle.com> <529F3918.40607@oracle.com>
Message-ID: <529F7174.3030805@oracle.com>

Hi Alexander,

It looks good to go.  I only skimmed the other parts of the fix on the 
assumption that they haven't changed in a few revisions, but it all 
looked good.  Glad to see you fixed the dimension issues in the observer 
as well.

I'll follow up with a list of future issues to track...

			...jim

On 12/4/13 6:15 AM, Alexander Scherbatiy wrote:
>
>    Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.14
>    - Observer and rvObserver are used to get width/hight from
> image/rvImage in SunGraphics2D
>    - width and height are rounded up in the image observer wrapper
>    - width and height are also rescaled for the SOMEBITS, FRAMEBITS ,
> and ALLBITS infoflags
>
>   Thanks,
>   Alexandr.
>
>
> On 12/3/2013 9:49 PM, Jim Graham wrote:
>> Hi Alexander,
>>
>> There is one last thing that I think I forgot to mention in SG2D that
>> might make some other comments I made make more sense.  There is no
>> observer registered on the resolution variant in SG2D.drawHiDPIImage()
>> in the case where the resolution variant hasn't been loaded yet.
>> Basically, the lines at 3099,3100 will trigger the variant to load,
>> but there is no observer in those calls to trace it back to the guy
>> who needs to call drawImage() again.  So, the only thing I think that
>> needs to be done is that the observer needs to be wrapped and handed
>> in to those calls to getWidth/Height(observer).
>>
>> The rest of that method looks fine - the regular variant will be used
>> (and will trigger repaints via the code that calls into drawImage())
>> until the base image dimensions are known enough to trigger the
>> getResolutionVariant() code, and then we might continue to use the
>> regular version until the resolution variant at least knows its
>> dimensions, and that is all OK, but we need to start using the
>> observer wrapper on the resolution variant starting at lines 3099,3100
>> in order to get the repaints to keep happening for that version of the
>> image.
>>
>> Arguably, in addition, the unwrapped observer probably could be used
>> on lines 3089, 3090 when you get the dimensions of the base image, but
>> since the base image will later be handed to the drawImage pipeline,
>> the observer will be registered there anyway, so that isn't a bug.
>> But, the wrapped observer needs to be used on 3099,3100 or we may
>> never repaint with the resolution variant (it will be a race condition
>> based on how fast the regular and hiDPI images load).
>>
>> More comments below, but that is the only remaining blocker that I can
>> see...
>>
>> On 12/3/13 3:48 AM, Alexander Scherbatiy wrote:
>>> On 12/3/2013 1:16 AM, Jim Graham wrote:
>>>> On 12/2/13 4:55 AM, Alexander Scherbatiy wrote:
>>>>> On 11/30/2013 3:27 AM, Jim Graham wrote:
>>>>>> 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.
>>>>>      It seems that just updating the newInfo method is not enough.
>>>>
>>>> There were 5 or 6 places that called imageUpdate when I did a quick
>>>> search and most of the calls went through newInfo.  They'd all have to
>>>> be updated.  Other than that, I'm not sure why it would not be enough?
>>>
>>>    Consider the following scenario. There are image.png and image at 2x.png
>>> files on the disk.
>>>      Image image1 = Toolkit.getImage("image.png");  // load as
>>> multi-resolution image
>>>      Image image2 = Toolkit.getImage("image at 2x.png");  // load the image
>>> from cache
>>>      toolkit.prepareImage(image2,.., imageObserver2);
>>>
>>>     The image2 has image1 as the base image so it rescale its
>>> coordinates/dimension and passes the base instead of self to the
>>> imageObserver2 which does not look correct.
>>
>> I see your point now.  I had thought that they would be cached
>> separately, but I see now that both are inserted into the hash
>> directly.  That allows sharing if they access both manually, but it
>> complicates the observer issue.  I don't think I would have bothered
>> with sharing the Image instance with a manual reference to the @2x in
>> that case, but we should be able to handle both in a future bug fix
>> and hopefully also get rid of wrappers, but it would take some surgery
>> on the drawImage pipeline and the record keeping in the observer
>> lists.  The existing solution will work fine for @2x images and allow
>> sharing so it is good to go for now (modulo the one issue with using
>> the wrapper for the getWidth()/getHeight() I mentioned above).
>>
>>>>>> Also, why does ObserverCache exist? Couldn't the cache just be a
>>>>>> static field on MRToolkitImage?
>>>>>       MRToolkitImage can be used in drawImage(Image,..,ImageObserver)
>>>>> method always with null observer. So the is no need to create the
>>>>> observer cache or use a synchronization during the cache
>>>>> initialization.
>>>>
>>>> Maybe I'm missing something about your answer here, but I think you
>>>> may have misunderstood my question.  You placed the field that holds
>>>> the reference to the cache inside an inner class.  I didn't see why
>>>> the reference could not be stored in the base class.  Why is there an
>>>> empty inner class to wrap a single field?  In other words, why was
>>>> this used:
>>>>
>>>>   56
>>>>   57     private static class ObserverCache {
>>>>   58
>>>>   59         static final SoftCache INSTANCE = new SoftCache();
>>>>   60     }
>>>>   61
>>>>
>>>> Instead of just:
>>>>
>>>>   56
>>>>   59     static final SoftCache INSTANCE = new SoftCache();
>>>>   61
>>>
>>>     Just to not create the cache in case if MRToolkitImageis used but
>>> image observers are always null. See the comment above.
>>
>> Ah, so this is just a micro-optimization then?  I'm not sure what you
>> mean by "always null".  It depends on whether they hand in an
>> observer, doesn't it?  The standard case of drawImage() tends to hand
>> in the Component as the observer.  In cases where we know we are using
>> a BufferedImage, we often use null, but code that uses a toolkit image
>> (or that doesn't know what the image is) should be using a non-null
>> observer or it won't paint right the first time when it triggers the
>> image loading.
>>
>> The cache object itself takes so little room that I don't think it is
>> worth worrying about.  If something triggers MRToolkitImage to be
>> referenced at all, then the 99% case will likely eventually involve
>> drawImage() calls with observer and an empty cache takes so little
>> room that it is probably fine to just aggressively create it at that
>> time.
>>
>> There is no bug or problem here, I just don't think the indirection
>> buys us anything worthwhile here...
>>
>>             ...jim
>

From james.graham at oracle.com  Wed Dec  4 13:56:52 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 04 Dec 2013 13:56:52 -0800
Subject: <AWT Dev> [8] Review request for 8028212 Custom cursor HiDPI
	support
In-Reply-To: <529E0FA5.6090300@oracle.com>
References: <529E079B.6050708@oracle.com> <529E0FA5.6090300@oracle.com>
Message-ID: <529FA524.2080302@oracle.com>

In the native code, is ImageReprese-M-tations really a class with a 
spelling error, or is that a typo in the new code?

In any case, all of this code was outside my areas of familiarity so I 
could only give it a passing "nothing smells wrong here" check, other 
than that spelling anomaly...

			...jim

On 12/3/13 9:06 AM, Anthony Petrov wrote:
> Hi Alexander,
>
> If we go with this fix, I suggest to move the
> CImage.Creator.resizeImageRepresentations() to the CImage class and make
> it a member method, so that you don't need to pass a CImage reference to
> it as an argument.
>
> Also, there's the CImage.resize() method already. Why does it not work
> for us? Having a specification for both methods (or for one, if the
> second is unneeded) might be helpful.
>
> However, I'm not sure if we really want to resize each representation of
> an NSImage object to the same size. Why would we want to do that? In
> fact, one of the representations might already have the correct size,
> and we could use just that whenever we need it w/o wasting resources on
> resizing each of them. If there's no representations of suitable size,
> then we should choose the closest one and resize just it to the desired
> size. Or am I misunderstanding anything?
>
> Also, in CCustomCursor.getImageData(), could we somehow encapsulate a
> part (or all) of the Image vs. MultiResolutionImage logic in the
> CImage.Creator class?
>
> PS. I'm not really an expert in Image handling code. I'd suggest someone
> from the 2D team to review this as well. Maybe Jim could help?
>
> --
> best regards,
> Anthony
>
> On 12/03/2013 08:32 PM, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the fix:
>>    bug: https://bugs.openjdk.java.net/browse/JDK-8028212
>>    webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00
>>
>>    - MultiResolutionImage interface is used from the fix 8011059
>>    - NSImage with representations are created for the multi-resolution
>> cursor
>>    - NSImage representations are rescaled to the base cursor size
>>
>> Thanks,
>> Alexandr.
>>

From andrei.eremeev at oracle.com  Thu Dec  5 01:18:46 2013
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Thu, 05 Dec 2013 13:18:46 +0400
Subject: <AWT Dev> Review Request: JDK-7175457 Fix for [TEST_BUG]
 closed/java/awt/Window/AlwaysOnTop/TestAlwaysOnTopBeforeShow.java still
 failed
In-Reply-To: <529E2762.90201@oracle.com>
References: <529DEED3.4090201@oracle.com> <529E2762.90201@oracle.com>
Message-ID: <52A044F6.7080100@oracle.com>

I have updated fix after Shura's review.

Andrei

On 12/03/2013 10:48 PM, Anthony Petrov wrote:
> Hi Andrei,
>
> The fix looks good to me.
>
> -- 
> best regards,
> Anthony
>
> On 12/03/2013 06:46 PM, andrei.eremeev wrote:
>> Hi, AWT team.
>>
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-7175457
>>
>> The fix is available at:
>> http://cr.openjdk.java.net/~yan/7175457/webrev.diff.00/
>>
>> Test moved to open:
>> http://cr.openjdk.java.net/~yan/7175457/webrev.00/


From Sergey.Bylokhov at oracle.com  Thu Dec  5 01:58:12 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 05 Dec 2013 13:58:12 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529F7174.3030805@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>
	<529922DD.7020605@oracle.com> <529C8326.7020401@oracle.com>
	<529CF89E.80309@oracle.com> <529DC51B.8090604@oracle.com>
	<529E1999.5080200@oracle.com> <529F3918.40607@oracle.com>
	<529F7174.3030805@oracle.com>
Message-ID: <52A04E34.1080804@oracle.com>

Hi, Alexander.
Count me as a second reviewer.

On 12/4/13 10:16 PM, Jim Graham wrote:
> Hi Alexander,
>
> It looks good to go.  I only skimmed the other parts of the fix on the 
> assumption that they haven't changed in a few revisions, but it all 
> looked good.  Glad to see you fixed the dimension issues in the 
> observer as well.
>
> I'll follow up with a list of future issues to track...
>
>             ...jim
>
> On 12/4/13 6:15 AM, Alexander Scherbatiy wrote:
>>
>>    Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8011059/webrev.14
>>    - Observer and rvObserver are used to get width/hight from
>> image/rvImage in SunGraphics2D
>>    - width and height are rounded up in the image observer wrapper
>>    - width and height are also rescaled for the SOMEBITS, FRAMEBITS ,
>> and ALLBITS infoflags
>>
>>   Thanks,
>>   Alexandr.
>>
>>
>> On 12/3/2013 9:49 PM, Jim Graham wrote:
>>> Hi Alexander,
>>>
>>> There is one last thing that I think I forgot to mention in SG2D that
>>> might make some other comments I made make more sense.  There is no
>>> observer registered on the resolution variant in SG2D.drawHiDPIImage()
>>> in the case where the resolution variant hasn't been loaded yet.
>>> Basically, the lines at 3099,3100 will trigger the variant to load,
>>> but there is no observer in those calls to trace it back to the guy
>>> who needs to call drawImage() again.  So, the only thing I think that
>>> needs to be done is that the observer needs to be wrapped and handed
>>> in to those calls to getWidth/Height(observer).
>>>
>>> The rest of that method looks fine - the regular variant will be used
>>> (and will trigger repaints via the code that calls into drawImage())
>>> until the base image dimensions are known enough to trigger the
>>> getResolutionVariant() code, and then we might continue to use the
>>> regular version until the resolution variant at least knows its
>>> dimensions, and that is all OK, but we need to start using the
>>> observer wrapper on the resolution variant starting at lines 3099,3100
>>> in order to get the repaints to keep happening for that version of the
>>> image.
>>>
>>> Arguably, in addition, the unwrapped observer probably could be used
>>> on lines 3089, 3090 when you get the dimensions of the base image, but
>>> since the base image will later be handed to the drawImage pipeline,
>>> the observer will be registered there anyway, so that isn't a bug.
>>> But, the wrapped observer needs to be used on 3099,3100 or we may
>>> never repaint with the resolution variant (it will be a race condition
>>> based on how fast the regular and hiDPI images load).
>>>
>>> More comments below, but that is the only remaining blocker that I can
>>> see...
>>>
>>> On 12/3/13 3:48 AM, Alexander Scherbatiy wrote:
>>>> On 12/3/2013 1:16 AM, Jim Graham wrote:
>>>>> On 12/2/13 4:55 AM, Alexander Scherbatiy wrote:
>>>>>> On 11/30/2013 3:27 AM, Jim Graham wrote:
>>>>>>> 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.
>>>>>>      It seems that just updating the newInfo method is not enough.
>>>>>
>>>>> There were 5 or 6 places that called imageUpdate when I did a quick
>>>>> search and most of the calls went through newInfo.  They'd all 
>>>>> have to
>>>>> be updated.  Other than that, I'm not sure why it would not be 
>>>>> enough?
>>>>
>>>>    Consider the following scenario. There are image.png and 
>>>> image at 2x.png
>>>> files on the disk.
>>>>      Image image1 = Toolkit.getImage("image.png");  // load as
>>>> multi-resolution image
>>>>      Image image2 = Toolkit.getImage("image at 2x.png");  // load the 
>>>> image
>>>> from cache
>>>>      toolkit.prepareImage(image2,.., imageObserver2);
>>>>
>>>>     The image2 has image1 as the base image so it rescale its
>>>> coordinates/dimension and passes the base instead of self to the
>>>> imageObserver2 which does not look correct.
>>>
>>> I see your point now.  I had thought that they would be cached
>>> separately, but I see now that both are inserted into the hash
>>> directly.  That allows sharing if they access both manually, but it
>>> complicates the observer issue.  I don't think I would have bothered
>>> with sharing the Image instance with a manual reference to the @2x in
>>> that case, but we should be able to handle both in a future bug fix
>>> and hopefully also get rid of wrappers, but it would take some surgery
>>> on the drawImage pipeline and the record keeping in the observer
>>> lists.  The existing solution will work fine for @2x images and allow
>>> sharing so it is good to go for now (modulo the one issue with using
>>> the wrapper for the getWidth()/getHeight() I mentioned above).
>>>
>>>>>>> Also, why does ObserverCache exist? Couldn't the cache just be a
>>>>>>> static field on MRToolkitImage?
>>>>>>       MRToolkitImage can be used in 
>>>>>> drawImage(Image,..,ImageObserver)
>>>>>> method always with null observer. So the is no need to create the
>>>>>> observer cache or use a synchronization during the cache
>>>>>> initialization.
>>>>>
>>>>> Maybe I'm missing something about your answer here, but I think you
>>>>> may have misunderstood my question.  You placed the field that holds
>>>>> the reference to the cache inside an inner class.  I didn't see why
>>>>> the reference could not be stored in the base class.  Why is there an
>>>>> empty inner class to wrap a single field?  In other words, why was
>>>>> this used:
>>>>>
>>>>>   56
>>>>>   57     private static class ObserverCache {
>>>>>   58
>>>>>   59         static final SoftCache INSTANCE = new SoftCache();
>>>>>   60     }
>>>>>   61
>>>>>
>>>>> Instead of just:
>>>>>
>>>>>   56
>>>>>   59     static final SoftCache INSTANCE = new SoftCache();
>>>>>   61
>>>>
>>>>     Just to not create the cache in case if MRToolkitImageis used but
>>>> image observers are always null. See the comment above.
>>>
>>> Ah, so this is just a micro-optimization then?  I'm not sure what you
>>> mean by "always null".  It depends on whether they hand in an
>>> observer, doesn't it?  The standard case of drawImage() tends to hand
>>> in the Component as the observer.  In cases where we know we are using
>>> a BufferedImage, we often use null, but code that uses a toolkit image
>>> (or that doesn't know what the image is) should be using a non-null
>>> observer or it won't paint right the first time when it triggers the
>>> image loading.
>>>
>>> The cache object itself takes so little room that I don't think it is
>>> worth worrying about.  If something triggers MRToolkitImage to be
>>> referenced at all, then the 99% case will likely eventually involve
>>> drawImage() calls with observer and an empty cache takes so little
>>> room that it is probably fine to just aggressively create it at that
>>> time.
>>>
>>> There is no bug or problem here, I just don't think the indirection
>>> buys us anything worthwhile here...
>>>
>>>             ...jim
>>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Thu Dec  5 02:04:28 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 05 Dec 2013 14:04:28 +0400
Subject: <AWT Dev> Review Request: JDK-7175457 Fix for [TEST_BUG]
 closed/java/awt/Window/AlwaysOnTop/TestAlwaysOnTopBeforeShow.java still
 failed
In-Reply-To: <52A044F6.7080100@oracle.com>
References: <529DEED3.4090201@oracle.com> <529E2762.90201@oracle.com>
	<52A044F6.7080100@oracle.com>
Message-ID: <52A04FAC.8080402@oracle.com>

Hi Andrei,

I haven't seen any messages regarding this fix on this mailing list.

Where did the review take place? What suggestions have been proposed, 
and what exactly have changed in the new version? And yes, where's this 
new version of the fix published?

--
best regards,
Anthony

On 12/05/2013 01:18 PM, andrei.eremeev wrote:
> I have updated fix after Shura's review.
>
> Andrei
>
> On 12/03/2013 10:48 PM, Anthony Petrov wrote:
>> Hi Andrei,
>>
>> The fix looks good to me.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/03/2013 06:46 PM, andrei.eremeev wrote:
>>> Hi, AWT team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-7175457
>>>
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~yan/7175457/webrev.diff.00/
>>>
>>> Test moved to open:
>>> http://cr.openjdk.java.net/~yan/7175457/webrev.00/
>

From andrei.eremeev at oracle.com  Thu Dec  5 03:01:27 2013
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Thu, 05 Dec 2013 15:01:27 +0400
Subject: <AWT Dev> Review Request: JDK-7175457 Fix for [TEST_BUG]
 closed/java/awt/Window/AlwaysOnTop/TestAlwaysOnTopBeforeShow.java still
 failed
In-Reply-To: <52A04FAC.8080402@oracle.com>
References: <529DEED3.4090201@oracle.com> <529E2762.90201@oracle.com>
	<52A044F6.7080100@oracle.com> <52A04FAC.8080402@oracle.com>
Message-ID: <52A05D07.6000309@oracle.com>

Shura have advised me to make some variables which can be accessed from 
several threads volatile.

The fix is available at:
http://cr.openjdk.java.net/~yan/7175457/webrev.diff.01/

Test moved to open:
http://cr.openjdk.java.net/~yan/7175457/webrev.01/

Andrei

On 12/05/2013 02:04 PM, Anthony Petrov wrote:
> Hi Andrei,
>
> I haven't seen any messages regarding this fix on this mailing list.
>
> Where did the review take place? What suggestions have been proposed, 
> and what exactly have changed in the new version? And yes, where's 
> this new version of the fix published?
>
> -- 
> best regards,
> Anthony
>
> On 12/05/2013 01:18 PM, andrei.eremeev wrote:
>> I have updated fix after Shura's review.
>>
>> Andrei
>>
>> On 12/03/2013 10:48 PM, Anthony Petrov wrote:
>>> Hi Andrei,
>>>
>>> The fix looks good to me.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 12/03/2013 06:46 PM, andrei.eremeev wrote:
>>>> Hi, AWT team.
>>>>
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-7175457
>>>>
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~yan/7175457/webrev.diff.00/
>>>>
>>>> Test moved to open:
>>>> http://cr.openjdk.java.net/~yan/7175457/webrev.00/
>>


From andrei.eremeev at oracle.com  Thu Dec  5 03:29:38 2013
From: andrei.eremeev at oracle.com (andrei.eremeev)
Date: Thu, 05 Dec 2013 15:29:38 +0400
Subject: <AWT Dev> Review Request: JDK-7112454 Fix for TEST_BUG:
 java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html
 failed
In-Reply-To: <529DEE40.8020707@oracle.com>
References: <529DEE40.8020707@oracle.com>
Message-ID: <52A063A2.3050106@oracle.com>

Shura have advised me to make some variables which can be accessed from 
several threads volatile.
And little refactoring.

The fix is available at:
http://cr.openjdk.java.net/~yan/7112454/webrev.diff.02/

Test moved to open:
http://cr.openjdk.java.net/~yan/7112454/webrev.02/

Andrei

On 12/03/2013 06:44 PM, andrei.eremeev wrote:
> Hi, AWT team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-7112454
>
> The fix is available at:
> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.00/
>
> Test moved to open:
> http://cr.openjdk.java.net/~yan/7112454/webrev.00/


From alexandr.scherbatiy at oracle.com  Thu Dec  5 06:01:27 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 05 Dec 2013 18:01:27 +0400
Subject: <AWT Dev> [8] Review request for 8024926 [macosx] AquaIcon
	HiDPI support
In-Reply-To: <529E0952.6080106@oracle.com>
References: <526FE6BB.3010109@oracle.com> <529E02BB.2020609@oracle.com>
	<529E0952.6080106@oracle.com>
Message-ID: <52A08737.4070305@oracle.com>


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

    - the graphics object is disposed in the 
AquaImageFactory.MultiResolutionIconImage constructor

   Thanks,
   Alexandr.

On 12/3/2013 8:39 PM, Anthony Petrov wrote:
> Hi Alexander,
>
> The Graphics obtained at line 519 in AquaImageFactory.java is never 
> dispose()'d.
>
> Other than that, the fix looks good to me (although I'm not an expert 
> in Aqua L&F or HiDPI support code).
>
> -- 
> best regards,
> Anthony
>
> On 12/03/2013 08:11 PM, Alexander Scherbatiy wrote:
>>
>>    Could you review the updated fix:
>>      http://cr.openjdk.java.net/~alexsch/8024926/webrev.01/
>>    - MultiResolutionImage interface is used from the fix 8011059
>>    - Only icons with resolution 1x and 2x are created.
>>
>>      The real Mac OS X system icon have more resolutions.
>>      The full fix requires retrieving and handling all NSImage
>> representations. It can be addressed for the next release.
>>
>>    Thanks,
>>    Alexandr.
>>
>> On 10/29/2013 8:47 PM, Alexander Scherbatiy wrote:
>>> Hello,
>>>
>>> Could you review the fix:
>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8024926
>>>   webrev: http://cr.openjdk.java.net/~alexsch/8024926/webrev.00
>>>
>>> The fix returns a high resolution system icon in the overridden
>>> getScaledInstance(width, height, hints) method.
>>>
>>> The fix relies on the fix for the issue JDK-8011059 [macosx] Make JDK
>>> demos look perfect on retina displays:
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html
>>>  - getScaledInstance(width, height, hints) method is used for the
>>> image drawing when IMAGE_SCALING hints are enabled
>>>  - LWCToolkit.ScalableToolkitImage class is public
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>


From alexandr.scherbatiy at oracle.com  Thu Dec  5 06:06:09 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 05 Dec 2013 18:06:09 +0400
Subject: <AWT Dev> [8] Review request for 8028212 Custom cursor HiDPI
	support
In-Reply-To: <529F5736.2030901@oracle.com>
References: <529E079B.6050708@oracle.com> <529E0FA5.6090300@oracle.com>
	<529F4360.5010808@oracle.com> <529F5736.2030901@oracle.com>
Message-ID: <52A08851.4010400@oracle.com>


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

   - CImage.createFromImage() method is updated to handle 
MultiResolutionImage
   - resizeRepresentations() method is moved from Creator to the CImage 
class
   - nativeResizeImageRepresentations method is renamed to 
nativeResizeNSImageRepresentations in the CImage class
   - ImageReprese-M-tations typo is fixed in the CImage native code

   Thanks,
   Alexandr.

On 12/4/2013 8:24 PM, Anthony Petrov wrote:
> Thanks for the update, Alexander. I understand.
>
> So, my only concerns that remain are:
>
> 1. The membership of the resizeImageRepresentations() method.
>
> 2. The encapsulation of the logic handling the 
> Image/MultiResolutionImage case (see at the bottom of my original 
> message).
>
> -- 
> best regards,
> Anthony
>
> On 12/04/2013 06:59 PM, Alexander Scherbatiy wrote:
>> On 12/3/2013 9:06 PM, Anthony Petrov wrote:
>>> Hi Alexander,
>>>
>>> If we go with this fix, I suggest to move the
>>> CImage.Creator.resizeImageRepresentations() to the CImage class and
>>> make it a member method, so that you don't need to pass a CImage
>>> reference to it as an argument.
>>      I will update this.
>>>
>>> Also, there's the CImage.resize() method already. Why does it not work
>>> for us? Having a specification for both methods (or for one, if the
>>> second is unneeded) might be helpful.
>>
>>       I do not know why, but SetNSImageSize (  [i
>> setScalesWhenResized:TRUE], [i setSize:NSMakeSize(w, h)]) just does not
>> work in this case. The high resolution representation is not chosen on
>>       my Mac OS X with enabled Quartz Debug.
>>
>>      I tried to narrow the problem and write the cocoa code. It is
>> described in https://bugs.openjdk.java.net/browse/JDK-8028212
>>
>>     Thanks,
>>     Alexandr.
>>
>>>
>>> However, I'm not sure if we really want to resize each representation
>>> of an NSImage object to the same size. Why would we want to do that?
>>> In fact, one of the representations might already have the correct
>>> size, and we could use just that whenever we need it w/o wasting
>>> resources on resizing each of them. If there's no representations of
>>> suitable size, then we should choose the closest one and resize just
>>> it to the desired size. Or am I misunderstanding anything?
>>>
>>> Also, in CCustomCursor.getImageData(), could we somehow encapsulate a
>>> part (or all) of the Image vs. MultiResolutionImage logic in the
>>> CImage.Creator class?
>>>
>>> PS. I'm not really an expert in Image handling code. I'd suggest
>>> someone from the 2D team to review this as well. Maybe Jim could help?
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 12/03/2013 08:32 PM, Alexander Scherbatiy wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8028212
>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00
>>>>
>>>>    - MultiResolutionImage interface is used from the fix 8011059
>>>>    - NSImage with representations are created for the multi-resolution
>>>> cursor
>>>>    - NSImage representations are rescaled to the base cursor size
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>


From Sergey.Bylokhov at oracle.com  Thu Dec  5 06:59:49 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 05 Dec 2013 18:59:49 +0400
Subject: <AWT Dev> [8] Review request for 8024926 [macosx] AquaIcon
	HiDPI support
In-Reply-To: <52A08737.4070305@oracle.com>
References: <526FE6BB.3010109@oracle.com> <529E02BB.2020609@oracle.com>
	<529E0952.6080106@oracle.com> <52A08737.4070305@oracle.com>
Message-ID: <52A094E5.5080800@oracle.com>

Hi, Alexander.
The fix looks good.
On 12/5/13 6:01 PM, Alexander Scherbatiy wrote:
>
>  Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8024926/webrev.02/
>
>    - the graphics object is disposed in the 
> AquaImageFactory.MultiResolutionIconImage constructor
>
>   Thanks,
>   Alexandr.
>
> On 12/3/2013 8:39 PM, Anthony Petrov wrote:
>> Hi Alexander,
>>
>> The Graphics obtained at line 519 in AquaImageFactory.java is never 
>> dispose()'d.
>>
>> Other than that, the fix looks good to me (although I'm not an expert 
>> in Aqua L&F or HiDPI support code).
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 12/03/2013 08:11 PM, Alexander Scherbatiy wrote:
>>>
>>>    Could you review the updated fix:
>>>      http://cr.openjdk.java.net/~alexsch/8024926/webrev.01/
>>>    - MultiResolutionImage interface is used from the fix 8011059
>>>    - Only icons with resolution 1x and 2x are created.
>>>
>>>      The real Mac OS X system icon have more resolutions.
>>>      The full fix requires retrieving and handling all NSImage
>>> representations. It can be addressed for the next release.
>>>
>>>    Thanks,
>>>    Alexandr.
>>>
>>> On 10/29/2013 8:47 PM, Alexander Scherbatiy wrote:
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8024926
>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8024926/webrev.00
>>>>
>>>> The fix returns a high resolution system icon in the overridden
>>>> getScaledInstance(width, height, hints) method.
>>>>
>>>> The fix relies on the fix for the issue JDK-8011059 [macosx] Make JDK
>>>> demos look perfect on retina displays:
>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html 
>>>>
>>>>  - getScaledInstance(width, height, hints) method is used for the
>>>> image drawing when IMAGE_SCALING hints are enabled
>>>>  - LWCToolkit.ScalableToolkitImage class is public
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Dec  5 07:01:50 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 05 Dec 2013 19:01:50 +0400
Subject: <AWT Dev> [8] Review request for 8028212 Custom cursor HiDPI
	support
In-Reply-To: <52A08851.4010400@oracle.com>
References: <529E079B.6050708@oracle.com> <529E0FA5.6090300@oracle.com>
	<529F4360.5010808@oracle.com> <529F5736.2030901@oracle.com>
	<52A08851.4010400@oracle.com>
Message-ID: <52A0955E.4000209@oracle.com>

Hi, Alexander.
The fix looks good.
On 12/5/13 6:06 PM, Alexander Scherbatiy wrote:
>
>   Could you review the updated fix:
>     http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/
>
>   - CImage.createFromImage() method is updated to handle 
> MultiResolutionImage
>   - resizeRepresentations() method is moved from Creator to the CImage 
> class
>   - nativeResizeImageRepresentations method is renamed to 
> nativeResizeNSImageRepresentations in the CImage class
>   - ImageReprese-M-tations typo is fixed in the CImage native code
>
>   Thanks,
>   Alexandr.
>
> On 12/4/2013 8:24 PM, Anthony Petrov wrote:
>> Thanks for the update, Alexander. I understand.
>>
>> So, my only concerns that remain are:
>>
>> 1. The membership of the resizeImageRepresentations() method.
>>
>> 2. The encapsulation of the logic handling the 
>> Image/MultiResolutionImage case (see at the bottom of my original 
>> message).
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 12/04/2013 06:59 PM, Alexander Scherbatiy wrote:
>>> On 12/3/2013 9:06 PM, Anthony Petrov wrote:
>>>> Hi Alexander,
>>>>
>>>> If we go with this fix, I suggest to move the
>>>> CImage.Creator.resizeImageRepresentations() to the CImage class and
>>>> make it a member method, so that you don't need to pass a CImage
>>>> reference to it as an argument.
>>>      I will update this.
>>>>
>>>> Also, there's the CImage.resize() method already. Why does it not work
>>>> for us? Having a specification for both methods (or for one, if the
>>>> second is unneeded) might be helpful.
>>>
>>>       I do not know why, but SetNSImageSize (  [i
>>> setScalesWhenResized:TRUE], [i setSize:NSMakeSize(w, h)]) just does not
>>> work in this case. The high resolution representation is not chosen on
>>>       my Mac OS X with enabled Quartz Debug.
>>>
>>>      I tried to narrow the problem and write the cocoa code. It is
>>> described in https://bugs.openjdk.java.net/browse/JDK-8028212
>>>
>>>     Thanks,
>>>     Alexandr.
>>>
>>>>
>>>> However, I'm not sure if we really want to resize each representation
>>>> of an NSImage object to the same size. Why would we want to do that?
>>>> In fact, one of the representations might already have the correct
>>>> size, and we could use just that whenever we need it w/o wasting
>>>> resources on resizing each of them. If there's no representations of
>>>> suitable size, then we should choose the closest one and resize just
>>>> it to the desired size. Or am I misunderstanding anything?
>>>>
>>>> Also, in CCustomCursor.getImageData(), could we somehow encapsulate a
>>>> part (or all) of the Image vs. MultiResolutionImage logic in the
>>>> CImage.Creator class?
>>>>
>>>> PS. I'm not really an expert in Image handling code. I'd suggest
>>>> someone from the 2D team to review this as well. Maybe Jim could help?
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 12/03/2013 08:32 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8028212
>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00
>>>>>
>>>>>    - MultiResolutionImage interface is used from the fix 8011059
>>>>>    - NSImage with representations are created for the 
>>>>> multi-resolution
>>>>> cursor
>>>>>    - NSImage representations are rescaled to the base cursor size
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>
>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Thu Dec  5 11:49:23 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 05 Dec 2013 23:49:23 +0400
Subject: <AWT Dev> Review Request: JDK-7175457 Fix for [TEST_BUG]
 closed/java/awt/Window/AlwaysOnTop/TestAlwaysOnTopBeforeShow.java still
 failed
In-Reply-To: <52A05D07.6000309@oracle.com>
References: <529DEED3.4090201@oracle.com> <529E2762.90201@oracle.com>
	<52A044F6.7080100@oracle.com> <52A04FAC.8080402@oracle.com>
	<52A05D07.6000309@oracle.com>
Message-ID: <52A0D8C3.80202@oracle.com>

Thanks, Andrei. The second version of the fix looks fine to me.

In the future, please advise Shura to send his feedback on the mailing 
list directly, so that all interested parties could see and discuss any 
suggestions.

--
best regards,
Anthony

On 12/05/2013 03:01 PM, andrei.eremeev wrote:
> Shura have advised me to make some variables which can be accessed from
> several threads volatile.
>
> The fix is available at:
> http://cr.openjdk.java.net/~yan/7175457/webrev.diff.01/
>
> Test moved to open:
> http://cr.openjdk.java.net/~yan/7175457/webrev.01/
>
> Andrei
>
> On 12/05/2013 02:04 PM, Anthony Petrov wrote:
>> Hi Andrei,
>>
>> I haven't seen any messages regarding this fix on this mailing list.
>>
>> Where did the review take place? What suggestions have been proposed,
>> and what exactly have changed in the new version? And yes, where's
>> this new version of the fix published?
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/05/2013 01:18 PM, andrei.eremeev wrote:
>>> I have updated fix after Shura's review.
>>>
>>> Andrei
>>>
>>> On 12/03/2013 10:48 PM, Anthony Petrov wrote:
>>>> Hi Andrei,
>>>>
>>>> The fix looks good to me.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 12/03/2013 06:46 PM, andrei.eremeev wrote:
>>>>> Hi, AWT team.
>>>>>
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-7175457
>>>>>
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~yan/7175457/webrev.diff.00/
>>>>>
>>>>> Test moved to open:
>>>>> http://cr.openjdk.java.net/~yan/7175457/webrev.00/
>>>
>

From anthony.petrov at oracle.com  Thu Dec  5 11:51:03 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 05 Dec 2013 23:51:03 +0400
Subject: <AWT Dev> Review Request: JDK-7112454 Fix for TEST_BUG:
 java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html
 failed
In-Reply-To: <52A063A2.3050106@oracle.com>
References: <529DEE40.8020707@oracle.com> <52A063A2.3050106@oracle.com>
Message-ID: <52A0D927.8050106@oracle.com>

This one looks fine, too.

--
best regards,
Anthony

On 12/05/2013 03:29 PM, andrei.eremeev wrote:
> Shura have advised me to make some variables which can be accessed from
> several threads volatile.
> And little refactoring.
>
> The fix is available at:
> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.02/
>
> Test moved to open:
> http://cr.openjdk.java.net/~yan/7112454/webrev.02/
>
> Andrei
>
> On 12/03/2013 06:44 PM, andrei.eremeev wrote:
>> Hi, AWT team.
>>
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-7112454
>>
>> The fix is available at:
>> http://cr.openjdk.java.net/~yan/7112454/webrev.diff.00/
>>
>> Test moved to open:
>> http://cr.openjdk.java.net/~yan/7112454/webrev.00/
>

From anthony.petrov at oracle.com  Thu Dec  5 11:55:19 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 05 Dec 2013 23:55:19 +0400
Subject: <AWT Dev> [8] Review request for 8028212 Custom cursor HiDPI
	support
In-Reply-To: <52A08851.4010400@oracle.com>
References: <529E079B.6050708@oracle.com> <529E0FA5.6090300@oracle.com>
	<529F4360.5010808@oracle.com> <529F5736.2030901@oracle.com>
	<52A08851.4010400@oracle.com>
Message-ID: <52A0DA27.8050907@oracle.com>

The fix looks fine to me. Thank you.

--
best regards,
Anthony

On 12/05/2013 06:06 PM, Alexander Scherbatiy wrote:
>
>    Could you review the updated fix:
>      http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/
>
>    - CImage.createFromImage() method is updated to handle
> MultiResolutionImage
>    - resizeRepresentations() method is moved from Creator to the CImage
> class
>    - nativeResizeImageRepresentations method is renamed to
> nativeResizeNSImageRepresentations in the CImage class
>    - ImageReprese-M-tations typo is fixed in the CImage native code
>
>    Thanks,
>    Alexandr.
>
> On 12/4/2013 8:24 PM, Anthony Petrov wrote:
>> Thanks for the update, Alexander. I understand.
>>
>> So, my only concerns that remain are:
>>
>> 1. The membership of the resizeImageRepresentations() method.
>>
>> 2. The encapsulation of the logic handling the
>> Image/MultiResolutionImage case (see at the bottom of my original
>> message).
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/04/2013 06:59 PM, Alexander Scherbatiy wrote:
>>> On 12/3/2013 9:06 PM, Anthony Petrov wrote:
>>>> Hi Alexander,
>>>>
>>>> If we go with this fix, I suggest to move the
>>>> CImage.Creator.resizeImageRepresentations() to the CImage class and
>>>> make it a member method, so that you don't need to pass a CImage
>>>> reference to it as an argument.
>>>      I will update this.
>>>>
>>>> Also, there's the CImage.resize() method already. Why does it not work
>>>> for us? Having a specification for both methods (or for one, if the
>>>> second is unneeded) might be helpful.
>>>
>>>       I do not know why, but SetNSImageSize (  [i
>>> setScalesWhenResized:TRUE], [i setSize:NSMakeSize(w, h)]) just does not
>>> work in this case. The high resolution representation is not chosen on
>>>       my Mac OS X with enabled Quartz Debug.
>>>
>>>      I tried to narrow the problem and write the cocoa code. It is
>>> described in https://bugs.openjdk.java.net/browse/JDK-8028212
>>>
>>>     Thanks,
>>>     Alexandr.
>>>
>>>>
>>>> However, I'm not sure if we really want to resize each representation
>>>> of an NSImage object to the same size. Why would we want to do that?
>>>> In fact, one of the representations might already have the correct
>>>> size, and we could use just that whenever we need it w/o wasting
>>>> resources on resizing each of them. If there's no representations of
>>>> suitable size, then we should choose the closest one and resize just
>>>> it to the desired size. Or am I misunderstanding anything?
>>>>
>>>> Also, in CCustomCursor.getImageData(), could we somehow encapsulate a
>>>> part (or all) of the Image vs. MultiResolutionImage logic in the
>>>> CImage.Creator class?
>>>>
>>>> PS. I'm not really an expert in Image handling code. I'd suggest
>>>> someone from the 2D team to review this as well. Maybe Jim could help?
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 12/03/2013 08:32 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8028212
>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8028212/webrev.00
>>>>>
>>>>>    - MultiResolutionImage interface is used from the fix 8011059
>>>>>    - NSImage with representations are created for the multi-resolution
>>>>> cursor
>>>>>    - NSImage representations are rescaled to the base cursor size
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>
>

From anthony.petrov at oracle.com  Thu Dec  5 11:57:29 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 05 Dec 2013 23:57:29 +0400
Subject: <AWT Dev> [8] Review request for 8024926 [macosx] AquaIcon
	HiDPI support
In-Reply-To: <52A094E5.5080800@oracle.com>
References: <526FE6BB.3010109@oracle.com> <529E02BB.2020609@oracle.com>
	<529E0952.6080106@oracle.com> <52A08737.4070305@oracle.com>
	<52A094E5.5080800@oracle.com>
Message-ID: <52A0DAA9.5050106@oracle.com>

+1.

--
best regards,
Anthony

On 12/05/2013 06:59 PM, Sergey Bylokhov wrote:
> Hi, Alexander.
> The fix looks good.
> On 12/5/13 6:01 PM, Alexander Scherbatiy wrote:
>>
>>  Could you review the updated fix:
>>     http://cr.openjdk.java.net/~alexsch/8024926/webrev.02/
>>
>>    - the graphics object is disposed in the
>> AquaImageFactory.MultiResolutionIconImage constructor
>>
>>   Thanks,
>>   Alexandr.
>>
>> On 12/3/2013 8:39 PM, Anthony Petrov wrote:
>>> Hi Alexander,
>>>
>>> The Graphics obtained at line 519 in AquaImageFactory.java is never
>>> dispose()'d.
>>>
>>> Other than that, the fix looks good to me (although I'm not an expert
>>> in Aqua L&F or HiDPI support code).
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 12/03/2013 08:11 PM, Alexander Scherbatiy wrote:
>>>>
>>>>    Could you review the updated fix:
>>>>      http://cr.openjdk.java.net/~alexsch/8024926/webrev.01/
>>>>    - MultiResolutionImage interface is used from the fix 8011059
>>>>    - Only icons with resolution 1x and 2x are created.
>>>>
>>>>      The real Mac OS X system icon have more resolutions.
>>>>      The full fix requires retrieving and handling all NSImage
>>>> representations. It can be addressed for the next release.
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>
>>>> On 10/29/2013 8:47 PM, Alexander Scherbatiy wrote:
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8024926
>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8024926/webrev.00
>>>>>
>>>>> The fix returns a high resolution system icon in the overridden
>>>>> getScaledInstance(width, height, hints) method.
>>>>>
>>>>> The fix relies on the fix for the issue JDK-8011059 [macosx] Make JDK
>>>>> demos look perfect on retina displays:
>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html
>>>>>
>>>>>  - getScaledInstance(width, height, hints) method is used for the
>>>>> image drawing when IMAGE_SCALING hints are enabled
>>>>>  - LWCToolkit.ScalableToolkitImage class is public
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>
>>
>
>

From swingler at apple.com  Thu Dec  5 12:07:39 2013
From: swingler at apple.com (Mike Swingler)
Date: Thu, 05 Dec 2013 12:07:39 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059
 [macosx] Make JDK demos look perfect on retina displays
In-Reply-To: <529E1EA0.7080209@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>
	<3F1315D7-D09F-46F2-8A72-4C43F9CE5D8F@apple.com>
	<529E1EA0.7080209@oracle.com>
Message-ID: <D3C8A49A-260A-4585-AF95-D76AC0BCF32E@apple.com>

On Dec 3, 2013, at 10:10 AM, Jim Graham <james.graham at oracle.com> wrote:

> Hi Mike,
> 
> One more question about @2x handling on MacOS.
> 
> Clearly, in the simple case of someone loading an ordinary "foo.png" and painting it on a retina display without doing anything special with the transform, it will be scaled up by 2x to retain proper size.
> 
> Also, clearly, if a "foo at 2x.png" file exists, it will be loaded automatically and found to be twice as large and displayed with no scaling so that it is the same "size".
> 
> But, what if in the first step they manually specified the image file name as "foo at 2x.png" (and assuming there is no "foo at 2x@2x.png")?  Will it display with its pixels scaled up to double sized because it was the direct image that they specified?

Yes, explicitly asking for "foo at 2x" cause the search machinery to look for "foo at 2x.png" and "foo at 2x@2x.png".

> Or, does the system recognize that it came from a file named @2x and assume that it is a double-screen-resolution image and paint it the same way it would have done if it was implicitly loaded as the higher resolution variant of "foo.png"?

No. Images reps loaded with the @2x suffix are not special ? they are just an additional representation of the same named image, and could vary unpredictable in dimensions, bit depth, and color space. We simply prefer that they not. :-)

> Let me spell out the scenarios:
> 
> Scenario 1:
> - app is retina-enabled
> - app has WxH foo.png media (and no @2x versions)
> - app loads image from "foo.png"
> - app displays image with standard default scaling on a retina screen
> => result is image takes up 2W x 2H pixels on the retina screen
> 
> Scenario 2:
> - app is retina-enabled
> - app has WxH foo.png media
> - app also has 2W x 2H foo at 2x.png media
> - app loads image from "foo.png"
> - app displays image with standard default scaling on a retina screen
> => result is system also loads foo at 2x.png and displays it with 2W x 2H retina pixels on the retina screen - the same physical size as in the previous example
> 
> Scenario 3:
> - app is retina-enabled
> - app has WxH foo.png media
> - app also has 2W x 2H foo at 2x.png media
> - app loads image from "foo at 2x.png" rather than "foo.png"
> - app displays image with standard default scaling on a retina screen
> => result is ???
> => I'm guessing that it gets drawn twice the size as Scenario's 1 and 2 because it is no longer relative to the WxH base image?
> 
> Scenario 4:
> same as Scenario 3, but foo.png doesn't exist, foo at 2x.png is the only version found in the media for the app
> => result is ???
> => I'm guessing the result is the same as Scenario 3
> 
> Also, the convention is for the @2x image to be twice the pixel size of the regular image, but what if it isn't?  Is it always drawn at a 0.5x relative scale because of the implication of the @2x file name, or will it be dynamically sized for "basew/@2xw, baseh/@2xh" which just usually works out to 0.5x if the author followed conventions?
> 
> 			...jim

@2x in the file name is just a hack to add more representations to images that are not already multi-rep (.png vs. .tiff and .icns). The actual dimensions of the image dictate when/how it gets used at runtime. I believe the search for @2x variants is only performed if the original image rep is not sufficient to fully fill the rect of pixels in the destination.

Regards,
Mike Swingler
Apple Inc.


From edward.burns at oracle.com  Thu Dec  5 14:13:27 2013
From: edward.burns at oracle.com (Edward Burns)
Date: Thu, 5 Dec 2013 14:13:27 -0800
Subject: <AWT Dev> JDK-8028617: Dvorak keyboard mapping not honored when
 ctrl key pressed
In-Reply-To: Re: <AWT Dev> JDK-8028617: Dvorak keyboard mapping not honored
	when ctrl key pressed on 3 December 2013
References: <21149.6944.847358.20855@gargle.gargle.HOWL>
	<529D9E60.90406@oracle.com>
	<21149.61539.311000.178302@gargle.gargle.HOWL>
Message-ID: <21152.64135.339383.653240@gargle.gargle.HOWL>

>>>>> On Tue, 3 Dec 2013 06:53:23 -0800, Edward Burns <edward.burns at oracle.com> said:

>>>>> On Tue, 03 Dec 2013 13:03:28 +0400, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> said:
SB> Hello,Edward.
SB> Can you confirm that the problem can be reproduced on jdk 8?
SB> https://jdk8.java.net/download.html

EB> I just downloaded "8 Build b118".

EB> Unfortunately, the problem persists.  Pressing Ctrl-e gives me Ctrl-d.

Do you have any suggestions for me?  If someone would help me get
started in building a runnable JDK installer on my local workstation, I
can try to start learning how to fix the bug.  I tried looking at the
openjdk building documentation, and found it was beyond me, given the
time I have to devote to it.  However, if I could have some help in
getting started building, I might be able to start down the road to a
fix.

Thanks,

Ed
-- 

From anthony.petrov at oracle.com  Thu Dec  5 14:23:28 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 06 Dec 2013 02:23:28 +0400
Subject: <AWT Dev> JDK-8028617: Dvorak keyboard mapping not honored when
 ctrl key pressed
In-Reply-To: <21152.64135.339383.653240@gargle.gargle.HOWL>
References: <21149.6944.847358.20855@gargle.gargle.HOWL>
	<529D9E60.90406@oracle.com>
	<21149.61539.311000.178302@gargle.gargle.HOWL>
	<21152.64135.339383.653240@gargle.gargle.HOWL>
Message-ID: <52A0FCE0.3090304@oracle.com>

Hi Edward,

On 12/06/2013 02:13 AM, Edward Burns wrote:
>>>>>> On Tue, 3 Dec 2013 06:53:23 -0800, Edward Burns <edward.burns at oracle.com> said:
>
>>>>>> On Tue, 03 Dec 2013 13:03:28 +0400, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> said:
> SB> Hello,Edward.
> SB> Can you confirm that the problem can be reproduced on jdk 8?
> SB> https://jdk8.java.net/download.html
>
> EB> I just downloaded "8 Build b118".
>
> EB> Unfortunately, the problem persists.  Pressing Ctrl-e gives me Ctrl-d.
>
> Do you have any suggestions for me?  If someone would help me get
> started in building a runnable JDK installer on my local workstation, I
> can try to start learning how to fix the bug.  I tried looking at the
> openjdk building documentation, and found it was beyond me, given the
> time I have to devote to it.  However, if I could have some help in
> getting started building, I might be able to start down the road to a
> fix.

You don't want to build the installer. You only need to build the JDK. 
Please see the following link to get started:

http://hg.openjdk.java.net/jdk8/build/raw-file/tip/README-builds.html

--
best regards,
Anthony

From Sergey.Bylokhov at oracle.com  Sat Dec  7 03:31:49 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 07 Dec 2013 15:31:49 +0400
Subject: <AWT Dev> [8] Review Request: 8001472
 api/java_awt/Window/indexTGF_* tests fail because expected colors aren't
 equal
Message-ID: <52A30725.8080507@oracle.com>

Hello.
Please review the fix for jdk 8.
According to the documentation of XSetWindowBackground [1]:
"Changing the background does not cause the window contents to be 
changed. To repaint the window and its background, use XClearWindow."

This error has big history as it was unstable. The behavior changes from 
update2update depending on that we generated UPDATE event or not, because
by default Container.update in distinguishing from Container.paint does 
clearRect().
After 7090424 we began to generate less paints and a problem became more 
visible.

[1] http://www.kodkast.com/unix-command/XSetWindowBackground

Bug: https://bugs.openjdk.java.net/browse/JDK-8001472
Webrev can be found at: http://cr.openjdk.java.net/~serb/8001472/webrev.00

-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Fri Dec  6 04:17:04 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 6 Dec 2013 16:17:04 +0400
Subject: <AWT Dev> <AWT-Dev> [8] Review Request: 8029565
	java.awt.dnd.InvalidDnDOperationException: data translation
	failed on file drop
Message-ID: <575304B8-6851-4AA7-9B4A-A4D2CBCC8214@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8029565
The fix is available at:
http://cr.openjdk.java.net/~pchelko/8029565/webrev/

This is a yet another regression of the  JDK-7075105 and a yet another copy/paste fix. 
I'm going to file a bug to perform a major refactoring of the DataTransferer code early in JDK 9 as now it's a mess.

With best regards. Petr.

From anthony.petrov at oracle.com  Fri Dec  6 04:15:54 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 06 Dec 2013 16:15:54 +0400
Subject: <AWT Dev> [8] Review Request: 8001472
 api/java_awt/Window/indexTGF_* tests fail because expected colors aren't
 equal
In-Reply-To: <52A30725.8080507@oracle.com>
References: <52A30725.8080507@oracle.com>
Message-ID: <52A1BFFA.5010801@oracle.com>

Hi Sergey,

Note that XClearWindow() won't generate any Expose events for the 
window, so that the contents of it won't be repainted automatically 
after a call to XWindow.xSetBackground(). Is the code calling this 
method aware of that and forces the repainting elsewhere? If not, 
shouldn't we call XClearArea(display, w, 0, 0, 0, 0, True) instead?

--
best regards,
Anthony

On 12/07/2013 03:31 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 8.
> According to the documentation of XSetWindowBackground [1]:
> "Changing the background does not cause the window contents to be
> changed. To repaint the window and its background, use XClearWindow."
>
> This error has big history as it was unstable. The behavior changes from
> update2update depending on that we generated UPDATE event or not, because
> by default Container.update in distinguishing from Container.paint does
> clearRect().
> After 7090424 we began to generate less paints and a problem became more
> visible.
>
> [1] http://www.kodkast.com/unix-command/XSetWindowBackground
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8001472
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8001472/webrev.00
>

From anthony.petrov at oracle.com  Fri Dec  6 04:25:32 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 06 Dec 2013 16:25:32 +0400
Subject: <AWT Dev> <AWT-Dev> [8] Review Request: 8029565
 java.awt.dnd.InvalidDnDOperationException: data translation failed on file
 drop
In-Reply-To: <575304B8-6851-4AA7-9B4A-A4D2CBCC8214@oracle.com>
References: <575304B8-6851-4AA7-9B4A-A4D2CBCC8214@oracle.com>
Message-ID: <52A1C23C.8060408@oracle.com>

Hi Petr,

The fix looks OK. A couple of remarks:

1.
> 1618                         // common practice (Wine, SWT) seems to be to

Is that Wine - the www.winehq.org ? Or is it a typo?

2. Does it make sense to compile two lists for the if/else statements: 
one before JDK-7075105, and the other one - the current one, and compare 
them to make sure this is the last regression of this kind?

--
best regards,
Anthony

On 12/06/2013 04:17 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8029565
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/8029565/webrev/
>
> This is a yet another regression of the  JDK-7075105 and a yet another copy/paste fix.
> I'm going to file a bug to perform a major refactoring of the DataTransferer code early in JDK 9 as now it's a mess.
>
> With best regards. Petr.
>

From Sergey.Bylokhov at oracle.com  Fri Dec  6 04:28:32 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 06 Dec 2013 16:28:32 +0400
Subject: <AWT Dev> [8] Review Request: 8001472
 api/java_awt/Window/indexTGF_* tests fail because expected colors aren't
 equal
In-Reply-To: <52A1BFFA.5010801@oracle.com>
References: <52A30725.8080507@oracle.com> <52A1BFFA.5010801@oracle.com>
Message-ID: <52A1C2F0.6070201@oracle.com>

On 06.12.2013 16:15, Anthony Petrov wrote:
> Hi Sergey,
>
> Note that XClearWindow() won't generate any Expose events for the 
> window, so that the contents of it won't be repainted automatically 
> after a call to XWindow.xSetBackground(). Is the code calling this 
> method aware of that and forces the repainting elsewhere? If not, 
> shouldn't we call XClearArea(display, w, 0, 0, 0, 0, True) instead?
XComponent.setBackground() calls repaint at the end, which paint all 
necessary staff, except background.
sequence of calls:
XComponent.setBackground()
     XWindow->xSetBackground()
         XlibWrapper.XSetWindowBackground()
         XlibWrapper.XClearWindow
XComponent.repaint()
>
> -- 
> best regards,
> Anthony
>
> On 12/07/2013 03:31 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk 8.
>> According to the documentation of XSetWindowBackground [1]:
>> "Changing the background does not cause the window contents to be
>> changed. To repaint the window and its background, use XClearWindow."
>>
>> This error has big history as it was unstable. The behavior changes from
>> update2update depending on that we generated UPDATE event or not, 
>> because
>> by default Container.update in distinguishing from Container.paint does
>> clearRect().
>> After 7090424 we began to generate less paints and a problem became more
>> visible.
>>
>> [1] http://www.kodkast.com/unix-command/XSetWindowBackground
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8001472
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8001472/webrev.00
>>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Fri Dec  6 04:33:17 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 06 Dec 2013 16:33:17 +0400
Subject: <AWT Dev> [8] Review Request: 8001472
 api/java_awt/Window/indexTGF_* tests fail because expected colors aren't
 equal
In-Reply-To: <52A1C2F0.6070201@oracle.com>
References: <52A30725.8080507@oracle.com> <52A1BFFA.5010801@oracle.com>
	<52A1C2F0.6070201@oracle.com>
Message-ID: <52A1C40D.6080900@oracle.com>

Sounds good. I'm fine with the fix then.

--
best regards,
Anthony

On 12/06/2013 04:28 PM, Sergey Bylokhov wrote:
> On 06.12.2013 16:15, Anthony Petrov wrote:
>> Hi Sergey,
>>
>> Note that XClearWindow() won't generate any Expose events for the
>> window, so that the contents of it won't be repainted automatically
>> after a call to XWindow.xSetBackground(). Is the code calling this
>> method aware of that and forces the repainting elsewhere? If not,
>> shouldn't we call XClearArea(display, w, 0, 0, 0, 0, True) instead?
> XComponent.setBackground() calls repaint at the end, which paint all
> necessary staff, except background.
> sequence of calls:
> XComponent.setBackground()
>      XWindow->xSetBackground()
>          XlibWrapper.XSetWindowBackground()
>          XlibWrapper.XClearWindow
> XComponent.repaint()
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/07/2013 03:31 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk 8.
>>> According to the documentation of XSetWindowBackground [1]:
>>> "Changing the background does not cause the window contents to be
>>> changed. To repaint the window and its background, use XClearWindow."
>>>
>>> This error has big history as it was unstable. The behavior changes from
>>> update2update depending on that we generated UPDATE event or not,
>>> because
>>> by default Container.update in distinguishing from Container.paint does
>>> clearRect().
>>> After 7090424 we began to generate less paints and a problem became more
>>> visible.
>>>
>>> [1] http://www.kodkast.com/unix-command/XSetWindowBackground
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8001472
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8001472/webrev.00
>>>
>
>

From petr.pchelko at oracle.com  Fri Dec  6 04:46:44 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 6 Dec 2013 16:46:44 +0400
Subject: <AWT Dev> <AWT-Dev> [8] Review Request: 8029565
	java.awt.dnd.InvalidDnDOperationException: data translation
	failed on file drop
In-Reply-To: <52A1C23C.8060408@oracle.com>
References: <575304B8-6851-4AA7-9B4A-A4D2CBCC8214@oracle.com>
	<52A1C23C.8060408@oracle.com>
Message-ID: <747D9AF2-F537-4ECC-935C-DF0A47679B0A@oracle.com>

Hello, Anthony.

>> 1618                         // common practice (Wine, SWT) seems to be to
> 
> Is that Wine - the www.winehq.org ? Or is it a typo?

This comment was there for ages, so I can't answer this question. 

> Does it make sense to compile two lists for the if/else statements: one before JDK-7075105, and the other one - the current one, and compare them to make sure this is the last regression of this kind?
This make sense and I've tried to do this. The list of the clauses is the same, but they are separated to translateBytes/translateStream. The problem is that some of the if-else clauses are valid only for bytes
and some only for stream and this seem to be correct.  I can't predict what will happen if I accidentally add an extra if-else clause to the place where it does not belong. We are going to native it this clauses, 
so I can easily introduce a crash. I think it's too risky to try fixing it now. Early in JDK 9 I'm going to rewrite this code and we could backport it to 8u20. 

With best regards. Petr.

On 06.12.2013, at 16:25, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Petr,
> 
> The fix looks OK. A couple of remarks:
> 
> 1.
>> 1618                         // common practice (Wine, SWT) seems to be to
> 
> Is that Wine - the www.winehq.org ? Or is it a typo?
> 
> 2. Does it make sense to compile two lists for the if/else statements: one before JDK-7075105, and the other one - the current one, and compare them to make sure this is the last regression of this kind?
> 
> --
> best regards,
> Anthony
> 
> On 12/06/2013 04:17 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8029565
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/8029565/webrev/
>> 
>> This is a yet another regression of the  JDK-7075105 and a yet another copy/paste fix.
>> I'm going to file a bug to perform a major refactoring of the DataTransferer code early in JDK 9 as now it's a mess.
>> 
>> With best regards. Petr.
>> 


From anthony.petrov at oracle.com  Fri Dec  6 04:57:08 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 06 Dec 2013 16:57:08 +0400
Subject: <AWT Dev> <AWT-Dev> [8] Review Request: 8029565
 java.awt.dnd.InvalidDnDOperationException: data translation failed on file
 drop
In-Reply-To: <747D9AF2-F537-4ECC-935C-DF0A47679B0A@oracle.com>
References: <575304B8-6851-4AA7-9B4A-A4D2CBCC8214@oracle.com>
	<52A1C23C.8060408@oracle.com>
	<747D9AF2-F537-4ECC-935C-DF0A47679B0A@oracle.com>
Message-ID: <52A1C9A4.4010004@oracle.com>

Thanks for the comments, Petr. I'm OK with the fix.

--
best regards,
Anthony

On 12/06/2013 04:46 PM, Petr Pchelko wrote:
> Hello, Anthony.
>
>>> 1618                         // common practice (Wine, SWT) seems to be to
>>
>> Is that Wine - the www.winehq.org ? Or is it a typo?
>
> This comment was there for ages, so I can't answer this question.
>
>> Does it make sense to compile two lists for the if/else statements: one before JDK-7075105, and the other one - the current one, and compare them to make sure this is the last regression of this kind?
> This make sense and I've tried to do this. The list of the clauses is the same, but they are separated to translateBytes/translateStream. The problem is that some of the if-else clauses are valid only for bytes
> and some only for stream and this seem to be correct.  I can't predict what will happen if I accidentally add an extra if-else clause to the place where it does not belong. We are going to native it this clauses,
> so I can easily introduce a crash. I think it's too risky to try fixing it now. Early in JDK 9 I'm going to rewrite this code and we could backport it to 8u20.
>
> With best regards. Petr.
>
> On 06.12.2013, at 16:25, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hi Petr,
>>
>> The fix looks OK. A couple of remarks:
>>
>> 1.
>>> 1618                         // common practice (Wine, SWT) seems to be to
>>
>> Is that Wine - the www.winehq.org ? Or is it a typo?
>>
>> 2. Does it make sense to compile two lists for the if/else statements: one before JDK-7075105, and the other one - the current one, and compare them to make sure this is the last regression of this kind?
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/06/2013 04:17 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8029565
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/8029565/webrev/
>>>
>>> This is a yet another regression of the  JDK-7075105 and a yet another copy/paste fix.
>>> I'm going to file a bug to perform a major refactoring of the DataTransferer code early in JDK 9 as now it's a mess.
>>>
>>> With best regards. Petr.
>>>
>

From Sergey.Bylokhov at oracle.com  Fri Dec  6 05:11:51 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 06 Dec 2013 17:11:51 +0400
Subject: <AWT Dev> <AWT-Dev> [8] Review Request: 8029565
 java.awt.dnd.InvalidDnDOperationException: data translation failed on file
 drop
In-Reply-To: <52A1C9A4.4010004@oracle.com>
References: <575304B8-6851-4AA7-9B4A-A4D2CBCC8214@oracle.com>
	<52A1C23C.8060408@oracle.com>
	<747D9AF2-F537-4ECC-935C-DF0A47679B0A@oracle.com>
	<52A1C9A4.4010004@oracle.com>
Message-ID: <52A1CD17.4030804@oracle.com>

Hi, Petr.
The fix looks good to me too.

On 06.12.2013 16:57, Anthony Petrov wrote:
> Thanks for the comments, Petr. I'm OK with the fix.
>
> -- 
> best regards,
> Anthony
>
> On 12/06/2013 04:46 PM, Petr Pchelko wrote:
>> Hello, Anthony.
>>
>>>> 1618                         // common practice (Wine, SWT) seems 
>>>> to be to
>>>
>>> Is that Wine - the www.winehq.org ? Or is it a typo?
>>
>> This comment was there for ages, so I can't answer this question.
>>
>>> Does it make sense to compile two lists for the if/else statements: 
>>> one before JDK-7075105, and the other one - the current one, and 
>>> compare them to make sure this is the last regression of this kind?
>> This make sense and I've tried to do this. The list of the clauses is 
>> the same, but they are separated to translateBytes/translateStream. 
>> The problem is that some of the if-else clauses are valid only for bytes
>> and some only for stream and this seem to be correct.  I can't 
>> predict what will happen if I accidentally add an extra if-else 
>> clause to the place where it does not belong. We are going to native 
>> it this clauses,
>> so I can easily introduce a crash. I think it's too risky to try 
>> fixing it now. Early in JDK 9 I'm going to rewrite this code and we 
>> could backport it to 8u20.
>>
>> With best regards. Petr.
>>
>> On 06.12.2013, at 16:25, Anthony Petrov <anthony.petrov at oracle.com> 
>> wrote:
>>
>>> Hi Petr,
>>>
>>> The fix looks OK. A couple of remarks:
>>>
>>> 1.
>>>> 1618                         // common practice (Wine, SWT) seems 
>>>> to be to
>>>
>>> Is that Wine - the www.winehq.org ? Or is it a typo?
>>>
>>> 2. Does it make sense to compile two lists for the if/else 
>>> statements: one before JDK-7075105, and the other one - the current 
>>> one, and compare them to make sure this is the last regression of 
>>> this kind?
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 12/06/2013 04:17 PM, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>>
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8029565
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/8029565/webrev/
>>>>
>>>> This is a yet another regression of the  JDK-7075105 and a yet 
>>>> another copy/paste fix.
>>>> I'm going to file a bug to perform a major refactoring of the 
>>>> DataTransferer code early in JDK 9 as now it's a mess.
>>>>
>>>> With best regards. Petr.
>>>>
>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Fri Dec  6 05:50:15 2013
From: petr.pchelko at oracle.com (petr.pchelko at oracle.com)
Date: Fri, 06 Dec 2013 13:50:15 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 8029565:
	java.awt.dnd.InvalidDnDOperationException:	data translation
	failed on file drop
Message-ID: <20131206135152.7EDCC62B31@hg.openjdk.java.net>

Changeset: 9e0e8eed676a
Author:    pchelko
Date:      2013-12-06 17:47 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9e0e8eed676a

8029565: java.awt.dnd.InvalidDnDOperationException: data translation failed on file drop
Reviewed-by: anthony, serb

! src/share/classes/sun/awt/datatransfer/DataTransferer.java
! src/solaris/classes/sun/awt/X11/XDataTransferer.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/InterprocessMessages.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/SourceFileListFrame.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/TargetFileListFrame.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.html
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.java
+ test/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListTransferable.java


From anton.litvinov at oracle.com  Fri Dec  6 14:03:13 2013
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Sat, 07 Dec 2013 02:03:13 +0400
Subject: <AWT Dev> [7u] Review request for 8025775: JNI warnings in
	TryXShmAttach
Message-ID: <52A249A1.3020904@oracle.com>

Hello Artem and Anthony,

Could you please review this backport of the fix, which was approved by 
you for JDK 8, from JDK 8 to JDK 7.

Bug: http://bugs.sun.com/view_bug.do?bug_id=8025775
Webrev: http://cr.openjdk.java.net/~alitvinov/8025775/jdk7/webrev.00
JDK 8 webrev: http://cr.openjdk.java.net/~alitvinov/8025775/jdk8/webrev.01

The fix contains all changes from the fix for JDK 8 and the next 
additional changes:

1. Files "awt_wm.c", "awt_xembed_server.c". Reversion of XError handling 
code implemented as "native -> Java" calls in JDK 7 version of the fix 
for CR 8005607 to its prior state with native error handlers.

2. Files "awt_util.h", "awt_util.c". Return of the macro "XERROR_SAVE" 
and the external global variable "xerror_code", because of their active 
use in XError handling code in the files "awt_wm.c" and 
"awt_xembed_server.c".

Thank you,
Anton

From alexander.zvegintsev at oracle.com  Mon Dec  9 04:18:56 2013
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 09 Dec 2013 16:18:56 +0400
Subject: <AWT Dev> [8] Review Request: 8001472
 api/java_awt/Window/indexTGF_* tests fail because expected colors aren't
 equal
In-Reply-To: <52A30725.8080507@oracle.com>
References: <52A30725.8080507@oracle.com>
Message-ID: <52A5B530.7030702@oracle.com>

HI Sergey,

this fix looks fine to me.

Thanks,

Alexander.

On 12/07/2013 03:31 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 8.
> According to the documentation of XSetWindowBackground [1]:
> "Changing the background does not cause the window contents to be 
> changed. To repaint the window and its background, use XClearWindow."
>
> This error has big history as it was unstable. The behavior changes 
> from update2update depending on that we generated UPDATE event or not, 
> because
> by default Container.update in distinguishing from Container.paint 
> does clearRect().
> After 7090424 we began to generate less paints and a problem became 
> more visible.
>
> [1] http://www.kodkast.com/unix-command/XSetWindowBackground
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8001472
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8001472/webrev.00
>


From anthony.petrov at oracle.com  Mon Dec  9 05:15:41 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 09 Dec 2013 17:15:41 +0400
Subject: <AWT Dev> [7u] Review request for 8025775: JNI warnings in
	TryXShmAttach
In-Reply-To: <52A249A1.3020904@oracle.com>
References: <52A249A1.3020904@oracle.com>
Message-ID: <52A5C27D.3070404@oracle.com>

Hi Anton,

The fix looks good to me.

--
best regards,
Anthony

On 12/07/2013 02:03 AM, Anton Litvinov wrote:
> Hello Artem and Anthony,
>
> Could you please review this backport of the fix, which was approved by
> you for JDK 8, from JDK 8 to JDK 7.
>
> Bug: http://bugs.sun.com/view_bug.do?bug_id=8025775
> Webrev: http://cr.openjdk.java.net/~alitvinov/8025775/jdk7/webrev.00
> JDK 8 webrev: http://cr.openjdk.java.net/~alitvinov/8025775/jdk8/webrev.01
>
> The fix contains all changes from the fix for JDK 8 and the next
> additional changes:
>
> 1. Files "awt_wm.c", "awt_xembed_server.c". Reversion of XError handling
> code implemented as "native -> Java" calls in JDK 7 version of the fix
> for CR 8005607 to its prior state with native error handlers.
>
> 2. Files "awt_util.h", "awt_util.c". Return of the macro "XERROR_SAVE"
> and the external global variable "xerror_code", because of their active
> use in XError handling code in the files "awt_wm.c" and
> "awt_xembed_server.c".
>
> Thank you,
> Anton

From artem.ananiev at oracle.com  Mon Dec  9 06:41:27 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 09 Dec 2013 18:41:27 +0400
Subject: <AWT Dev> [7u] Review request for 8025775: JNI warnings in
	TryXShmAttach
In-Reply-To: <52A5C27D.3070404@oracle.com>
References: <52A249A1.3020904@oracle.com> <52A5C27D.3070404@oracle.com>
Message-ID: <52A5D697.6070404@oracle.com>


Looks fine to me as well.

Thanks,

Artem

On 12/9/2013 5:15 PM, Anthony Petrov wrote:
> Hi Anton,
>
> The fix looks good to me.
>
> --
> best regards,
> Anthony
>
> On 12/07/2013 02:03 AM, Anton Litvinov wrote:
>> Hello Artem and Anthony,
>>
>> Could you please review this backport of the fix, which was approved by
>> you for JDK 8, from JDK 8 to JDK 7.
>>
>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8025775
>> Webrev: http://cr.openjdk.java.net/~alitvinov/8025775/jdk7/webrev.00
>> JDK 8 webrev:
>> http://cr.openjdk.java.net/~alitvinov/8025775/jdk8/webrev.01
>>
>> The fix contains all changes from the fix for JDK 8 and the next
>> additional changes:
>>
>> 1. Files "awt_wm.c", "awt_xembed_server.c". Reversion of XError handling
>> code implemented as "native -> Java" calls in JDK 7 version of the fix
>> for CR 8005607 to its prior state with native error handlers.
>>
>> 2. Files "awt_util.h", "awt_util.c". Return of the macro "XERROR_SAVE"
>> and the external global variable "xerror_code", because of their active
>> use in XError handling code in the files "awt_wm.c" and
>> "awt_xembed_server.c".
>>
>> Thank you,
>> Anton

From petr.pchelko at oracle.com  Mon Dec  9 22:57:08 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 10 Dec 2013 10:57:08 +0400
Subject: <AWT Dev> RFR 8028019 Doclint cleanup of java.awt
In-Reply-To: <529D0F6A.2050600@oracle.com>
References: <527C11B4.5070707@oracle.com> <527EA573.9060801@oracle.com>
	<5295B93A.5050901@oracle.com> <52961A8C.3040901@oracle.com>
	<5296FF98.30106@oracle.com> <529D0F6A.2050600@oracle.com>
Message-ID: <E2B1D675-5228-4E7C-8ADE-B83DC766220E@oracle.com>

Hello, Roger.

The fix looks good to me.

With best regards. Petr.

On 03.12.2013, at 2:53, roger riggs <roger.riggs at oracle.com> wrote:

> Hi Yuri,
> 
> I updated the webrev to remove conflicts with the changeset in the 2D repository.
> I will push on Tuesday based on your OK comment unless I hear otherwise.
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-lint-awt-8028019/
> 
> Thanks, Roger
> 
> On 11/28/2013 3:32 AM, Yuri Nesterenko wrote:
>> 
>> On 11/27/2013 08:15 PM, roger riggs wrote:
>>> Hi Yuri,
>>> 
>>> I don't see a spacing difference between <br> and no markup.
>>> <br> is supposed only to terminate the line, not add any spacing
>>> and I did not see any difference in an example I tried.
>>> Perhaps you would point me to a specific example.
>> 
>> Uhm, Roger, you are right. In your files that "p" seems to be always
>> somewhere before "@see" which is wrapped in "div" by javadoc.
>> 
>> So, the fix is OK with me.
>> Please try to avoid merge in 2D code with 4592f0985e78 (in 2D team
>> repository since Nov.20, JDK-8025235).
>> 
>>> 
>>> The formatting should be handled by the stylesheets and adding extra
>>> markup to affect the presentation is not the best approach.
>> That's always true but we don't control stylelesheets.
>> 
>> Thanks,
>> -yan
> 


From Alan.Bateman at oracle.com  Tue Dec 10 05:51:54 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Dec 2013 13:51:54 +0000
Subject: <AWT Dev> 8029886: Change SecurityManager check{TopLevelWindow,
 SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
Message-ID: <52A71C7A.4050404@oracle.com>


In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods 
checkTopLevelWindow, checkSystemClipboard and 
checkAccessAwtEventQueueAccess with a warning that they would be changed 
in a future release to check AllPermission. At the same time we changed 
the java.awt.Window and Toolkit methods to use checkPermission directly 
so that the legacy methods aren't used. The motive for all this is 
modules of course and the strong desire to remove the dependency on 
java.awt.AWTPermission.

I'd like to get the second phase of this work into JDK 9 early to give 
every opportunity to find any potential issues. The second phase of this 
work changes the SecurityManager methods to check AllPermission and 
updates the implementation to remove the reflection hackery that was 
used to allow this code work without AWT being present (something that 
was needed for the profiles build).

The webrev with the changes is here:
   http://cr.openjdk.java.net/~alanb/8029886/webrev/

The main thing that I'd like to get agreement on is the wording for the 
updated methods and also agreement from the AWT group to move the 
permission constants to a new class sun.awt.AWTPermissions.

-Alan.

From anton.tarasov at oracle.com  Tue Dec 10 06:22:48 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Tue, 10 Dec 2013 18:22:48 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
Message-ID: <52A723B8.7090705@oracle.com>

Hi Jim, Sergey and All,

Please review the fix that adds support of Retina displays to 
JLightweightFrame (which javafx SwingNode is based on).

webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
jira: https://bugs.openjdk.java.net/browse/JDK-8029455

(After the fix goes into jdk9 it should be ported to 8u20 as well, 
because the functionality is essential for SwingNode.)

The general idea of the fix is as follows.

A BufferedImage instance, being created in the context in which the 
scale factor is determined and is different from one, is automatically 
created with appropriately extended size. The image itself becomes a 
scaled image (a "scale" private field is set on it). By the "context" I 
mean the circumstances where the BufferedImage is related to a  
JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a 
GraphicsDevice which determine the scale factor.

Here are the related changes:

- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
(the resizeBuffer method)
- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html

The "scale" value of a BufferedImage is used when 1) 
BufferedImageGraphicsConfig is created 2) 
BufImgSurfaceData.getDefaultScale() is called:

- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html

The former is used in the GraphicsConfiguration.createCompatibleImage() 
calls, and the latter is used in SurfaceManager.getImageScale(Image):

- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html

A scaled BufferedImage is supported by the SunGraphics2D.drawImage() 
primitives. Here's the pattern of how the image may be created and drawn:

int scale = <get the scale factor from the context>;
BufferedImage img = new BufferedImage(width * scale, height * scale, ...);
img.setScale(scale); // an accessor is currently used instead
<...>
g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a 
specified rect

In the first case, if the BufferedImage is created with an extended 
size, the "scale" value of the image matters, it should be drawn as a 
HiDPI image.
In the second case, if the BufferedImage is created with an extended 
size, the "scale" value of the image doesn't matter (it may not be 
evidently set) as the image will anyway be scaled from its physical 
bounds into provided logical bounds. This all should (as I suppose) 
provide backward compatibility for buffered images that were created in 
their logical bounds or without setting the "scale" field. For instance, 
the AquaPainter.paintFromSingleCachedImage(...) method creates & draws 
an image as follows:

int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
int imgW = bounds.width * scale;
int imgH = bounds.height * scale;
BufferedImage img = new BufferedImage(imgW, imgH, ...);
<paint into the img>
g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);

Here, the img.scale value is not set (I didn't modify this code), and 
SunGraphics2D doesn't treat the image as a HiDPI image, however it is 
drawn as expected. An alternative way to draw the image would be:

int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
int imgW = bounds.width * scale;
int imgH = bounds.height * scale;
BufferedImage img = new BufferedImage(imgW, imgH, ...);
img.setScale(scale);
<paint into the img>
g.drawImage(img, bounds.x, bounds.y, ...);

The result would be the same.

- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html

The following changes:

- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html

are defined by this logic. Running Swing via JLightweightFrame (JLF) 
makes it "display agnostic". Swing is painted to an off-screen buffer 
and it's the host (e.g. SwingNode) that renders the buffer on a 
particular device. So, the host should detect the scale of the current 
display and set it on JLF.

However, AWT in order to paint to a volatile image requires 
CGraphicsDevice and CGLSurfaceData to be created. By default AWT creates 
CGraphicsDevice instances matching all the detected display devices 
(CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any 
platform window behind it, AWT can't match JLF to the exact device it's 
currently displayed on. So, on the one hand, AWT doesn't know which 
device is current and what is the current scale (the host passes this 
value), but from the other hand, AWT has a list of all the 
CGraphicsDevice instances.

I tried to leverage from that fact. The 
CPlatformLWView.getGraphicsDevice() method takes the current scale from 
the JLF instance, and then tries to match it to an existent device from 
the list. In case it can't find a device with the specified scale (which 
should not actually happen, unless the host passes an arbitrary scale 
value, which is not the case for SwingNode) it takes a default device 
and changes its scale forcedly. I'm not sure if I should create a new 
dummy device instance instead. The scale factor of the device (which is 
then propagated to CGLSurfaceData on its creation) is the only info that 
JLF will take from the device to create a scaled volatile image.

The following changes:

- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html

were made to map a backing store image to a scale factor.

The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on 
scrolling. The method was not implemented for a graphics with a scale 
transform and a BufImgSurfaceData (it threw exceptions). I took that 
code, copied it to the BufImgSurfaceData.copyArea(...) and added a 
general translation for the coords:

- 
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html

It works, but I'm not sure the implementation is eligible (I don't know 
the details of the Blit class, at least it warns not to use the same 
source and dest).

The rest of the changes (not covered here) should be clear.

Testing:

- Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & 
embedded into SwingNode [1]).
- Testing both Nimbus and Aqua L&F.
- Setting swing.volatileImageBufferEnabled=false/true for all combinations.

Currently, I see no regressions and no visual issues comparing a 
standalone mode and a SwingSet mode.

At the end, I suspect there may be some intersection b/w this fix and 
the fix which introduced MultiResolutionToolkitImage. Unfortunately, I 
didn't yet read that review saga... Please tell me if I should 
incorporate anything from that fix.

Thanks,
Anton.

[1] There's a SwingSet part of the fix which I'm going to post to the 
jfx alias separately.


From mandy.chung at oracle.com  Tue Dec 10 10:37:35 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Dec 2013 10:37:35 -0800
Subject: <AWT Dev> 8029886: Change SecurityManager check{TopLevelWindow,
 SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A71C7A.4050404@oracle.com>
References: <52A71C7A.4050404@oracle.com>
Message-ID: <52A75F6F.7020800@oracle.com>

Alan,

The change looks good.   A minor one - in the class description of 
java.lang.SecurityManager,  I suggest to remove the references to 
java.awt.AWTPermission line 143 and 214.

Mandy

On 12/10/2013 5:51 AM, Alan Bateman wrote:
>
> In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods 
> checkTopLevelWindow, checkSystemClipboard and 
> checkAccessAwtEventQueueAccess with a warning that they would be 
> changed in a future release to check AllPermission. At the same time 
> we changed the java.awt.Window and Toolkit methods to use 
> checkPermission directly so that the legacy methods aren't used. The 
> motive for all this is modules of course and the strong desire to 
> remove the dependency on java.awt.AWTPermission.
>
> I'd like to get the second phase of this work into JDK 9 early to give 
> every opportunity to find any potential issues. The second phase of 
> this work changes the SecurityManager methods to check AllPermission 
> and updates the implementation to remove the reflection hackery that 
> was used to allow this code work without AWT being present (something 
> that was needed for the profiles build).
>
> The webrev with the changes is here:
>   http://cr.openjdk.java.net/~alanb/8029886/webrev/
>
> The main thing that I'd like to get agreement on is the wording for 
> the updated methods and also agreement from the AWT group to move the 
> permission constants to a new class sun.awt.AWTPermissions.
>
> -Alan.


From philip.race at oracle.com  Tue Dec 10 11:20:51 2013
From: philip.race at oracle.com (Phil Race)
Date: Tue, 10 Dec 2013 11:20:51 -0800
Subject: <AWT Dev> 8029886: Change SecurityManager check{TopLevelWindow,
 SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A71C7A.4050404@oracle.com>
References: <52A71C7A.4050404@oracle.com>
Message-ID: <52A76993.3060905@oracle.com>

 > was trusted to bring up a top-level winodw. It no longer has a use

What's a winodw ? :-)

"It no longer has a use" suggests it does nothing so might be better 
phrased as
"no longer the recommended or sole way to perform this check and is 
superseded by .. "


Is there a CCC for this ? It seems that there's a compatibility impact
on permissions required if you don't/can't change your code, and on your
code if you want to keep the same permissions.

-phil.

On 12/10/2013 5:51 AM, Alan Bateman wrote:
>
> In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods 
> checkTopLevelWindow, checkSystemClipboard and 
> checkAccessAwtEventQueueAccess with a warning that they would be 
> changed in a future release to check AllPermission. At the same time 
> we changed the java.awt.Window and Toolkit methods to use 
> checkPermission directly so that the legacy methods aren't used. The 
> motive for all this is modules of course and the strong desire to 
> remove the dependency on java.awt.AWTPermission.
>
> I'd like to get the second phase of this work into JDK 9 early to give 
> every opportunity to find any potential issues. The second phase of 
> this work changes the SecurityManager methods to check AllPermission 
> and updates the implementation to remove the reflection hackery that 
> was used to allow this code work without AWT being present (something 
> that was needed for the profiles build).
>
> The webrev with the changes is here:
>   http://cr.openjdk.java.net/~alanb/8029886/webrev/
>
> The main thing that I'd like to get agreement on is the wording for 
> the updated methods and also agreement from the AWT group to move the 
> permission constants to a new class sun.awt.AWTPermissions.
>
> -Alan.


From anthony.petrov at oracle.com  Tue Dec 10 11:57:37 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 10 Dec 2013 23:57:37 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A723B8.7090705@oracle.com>
References: <52A723B8.7090705@oracle.com>
Message-ID: <52A77231.1030902@oracle.com>

Hi Anton,

I'm not an expert in HiDPI rendering, so I'll defer to Jim and Sergey to 
comment on the core changes. I still have a few comments regarding the fix:

1. src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
>  265         contentView.initialize(peer, null);

Are you sure calling view.initialize() from CPW.initializeBase() doesn't 
introduce any unwanted side-effects? Interestingly, the contentView 
field gets re-written and re-initialized in the CPW.initialize() method 
after calling the initializeBase(). Seems very strange to me.


2. I'm not sure if adding the scale field to the BI is a good idea. I 
think that the image shouldn't be aware of any scale. After all, it's 
just an image, a bitmap. It has its real dimensions corresponding to the 
actual size of the image stored in RAM. Whether this image is going to 
be represented as a scaled image is something that a code that uses the 
image should be concerned with, not the image itself.


3. src/share/classes/java/awt/peer/FramePeer.java
>  139     default void notifyScaleFactorChanged() {}

I think this deserves to be declared in WindowPeer so that we could use 
it w/o additional modifications in the future if we add support for 
public notifications about the scale factor changes.


4. I'm CC'ing swing-dev@ and Alexander Scherbatiy to review changes in 
the JViewport class and other Swing classes.

--
best regards,
Anthony

On 12/10/2013 06:22 PM, Anton V. Tarasov wrote:
> Hi Jim, Sergey and All,
>
> Please review the fix that adds support of Retina displays to
> JLightweightFrame (which javafx SwingNode is based on).
>
> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>
> (After the fix goes into jdk9 it should be ported to 8u20 as well,
> because the functionality is essential for SwingNode.)
>
> The general idea of the fix is as follows.
>
> A BufferedImage instance, being created in the context in which the
> scale factor is determined and is different from one, is automatically
> created with appropriately extended size. The image itself becomes a
> scaled image (a "scale" private field is set on it). By the "context" I
> mean the circumstances where the BufferedImage is related to a
> JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a
> GraphicsDevice which determine the scale factor.
>
> Here are the related changes:
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html
> (the resizeBuffer method)
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>
>
> The "scale" value of a BufferedImage is used when 1)
> BufferedImageGraphicsConfig is created 2)
> BufImgSurfaceData.getDefaultScale() is called:
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>
>
> The former is used in the GraphicsConfiguration.createCompatibleImage()
> calls, and the latter is used in SurfaceManager.getImageScale(Image):
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>
>
> A scaled BufferedImage is supported by the SunGraphics2D.drawImage()
> primitives. Here's the pattern of how the image may be created and drawn:
>
> int scale = <get the scale factor from the context>;
> BufferedImage img = new BufferedImage(width * scale, height * scale, ...);
> img.setScale(scale); // an accessor is currently used instead
> <...>
> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a
> specified rect
>
> In the first case, if the BufferedImage is created with an extended
> size, the "scale" value of the image matters, it should be drawn as a
> HiDPI image.
> In the second case, if the BufferedImage is created with an extended
> size, the "scale" value of the image doesn't matter (it may not be
> evidently set) as the image will anyway be scaled from its physical
> bounds into provided logical bounds. This all should (as I suppose)
> provide backward compatibility for buffered images that were created in
> their logical bounds or without setting the "scale" field. For instance,
> the AquaPainter.paintFromSingleCachedImage(...) method creates & draws
> an image as follows:
>
> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
> int imgW = bounds.width * scale;
> int imgH = bounds.height * scale;
> BufferedImage img = new BufferedImage(imgW, imgH, ...);
> <paint into the img>
> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);
>
> Here, the img.scale value is not set (I didn't modify this code), and
> SunGraphics2D doesn't treat the image as a HiDPI image, however it is
> drawn as expected. An alternative way to draw the image would be:
>
> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
> int imgW = bounds.width * scale;
> int imgH = bounds.height * scale;
> BufferedImage img = new BufferedImage(imgW, imgH, ...);
> img.setScale(scale);
> <paint into the img>
> g.drawImage(img, bounds.x, bounds.y, ...);
>
> The result would be the same.
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>
>
> The following changes:
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>
>
> are defined by this logic. Running Swing via JLightweightFrame (JLF)
> makes it "display agnostic". Swing is painted to an off-screen buffer
> and it's the host (e.g. SwingNode) that renders the buffer on a
> particular device. So, the host should detect the scale of the current
> display and set it on JLF.
>
> However, AWT in order to paint to a volatile image requires
> CGraphicsDevice and CGLSurfaceData to be created. By default AWT creates
> CGraphicsDevice instances matching all the detected display devices
> (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any
> platform window behind it, AWT can't match JLF to the exact device it's
> currently displayed on. So, on the one hand, AWT doesn't know which
> device is current and what is the current scale (the host passes this
> value), but from the other hand, AWT has a list of all the
> CGraphicsDevice instances.
>
> I tried to leverage from that fact. The
> CPlatformLWView.getGraphicsDevice() method takes the current scale from
> the JLF instance, and then tries to match it to an existent device from
> the list. In case it can't find a device with the specified scale (which
> should not actually happen, unless the host passes an arbitrary scale
> value, which is not the case for SwingNode) it takes a default device
> and changes its scale forcedly. I'm not sure if I should create a new
> dummy device instance instead. The scale factor of the device (which is
> then propagated to CGLSurfaceData on its creation) is the only info that
> JLF will take from the device to create a scaled volatile image.
>
> The following changes:
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>
>
> were made to map a backing store image to a scale factor.
>
> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on
> scrolling. The method was not implemented for a graphics with a scale
> transform and a BufImgSurfaceData (it threw exceptions). I took that
> code, copied it to the BufImgSurfaceData.copyArea(...) and added a
> general translation for the coords:
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>
>
> It works, but I'm not sure the implementation is eligible (I don't know
> the details of the Blit class, at least it warns not to use the same
> source and dest).
>
> The rest of the changes (not covered here) should be clear.
>
> Testing:
>
> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode &
> embedded into SwingNode [1]).
> - Testing both Nimbus and Aqua L&F.
> - Setting swing.volatileImageBufferEnabled=false/true for all combinations.
>
> Currently, I see no regressions and no visual issues comparing a
> standalone mode and a SwingSet mode.
>
> At the end, I suspect there may be some intersection b/w this fix and
> the fix which introduced MultiResolutionToolkitImage. Unfortunately, I
> didn't yet read that review saga... Please tell me if I should
> incorporate anything from that fix.
>
> Thanks,
> Anton.
>
> [1] There's a SwingSet part of the fix which I'm going to post to the
> jfx alias separately.
>

From Alan.Bateman at oracle.com  Tue Dec 10 12:47:27 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Dec 2013 20:47:27 +0000
Subject: <AWT Dev> 8029886: Change SecurityManager check{TopLevelWindow,
 SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A76993.3060905@oracle.com>
References: <52A71C7A.4050404@oracle.com> <52A76993.3060905@oracle.com>
Message-ID: <52A77DDF.1020109@oracle.com>

On 10/12/2013 19:20, Phil Race wrote:
> > was trusted to bring up a top-level winodw. It no longer has a use
>
> What's a winodw ? :-)
Thanks, I'll fix that.

>
> "It no longer has a use" suggests it does nothing so might be better 
> phrased as
> "no longer the recommended or sole way to perform this check and is 
> superseded by .. "
"It" refers to the method as it really doesn't have a use now (these 
methods haven't really been needed since JDK 1.1). However, I see how 
this could be mis-read so I will adjust the wording.

>
>
> Is there a CCC for this ? It seems that there's a compatibility impact
> on permissions required if you don't/can't change your code, and on your
> code if you want to keep the same permissions.
The permissions haven't changed and existing policy files will continue 
to work. Also remember we changed the AWT implementation in JDK 8 to use 
checkPermission directly so the 3 methods aren't used. It's possible 
that there is code somewhere are is invoking these legacy methods 
directly and that was the reason for deprecating it in 8 with the 
wording to make it clear that these methods would be change in the 
future. Also by getting this change done early in JDK 9 then it gives 
every opportunity to flush out issues.

-Alan.

From Sergey.Bylokhov at oracle.com  Tue Dec 10 15:26:17 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 11 Dec 2013 03:26:17 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A723B8.7090705@oracle.com>
References: <52A723B8.7090705@oracle.com>
Message-ID: <52A7A319.80001@oracle.com>

Hi, Anton.
My expectation was that everything should work automatically, if you get 
correct CGraphicsDevice for the embedded swing window + some tweaks in 
the code related to the peer and CGLSurfaceData/

Why we need all this change in 
CGraphicsDevice,CGLGraphicsConfig,OffScreenImage,CPlatformLWView,JViewport,RepaintManager.Probably 
it will be better to disable doublebuffering and 
SwingPaintEventDispatcher completely(see swing.showFromDoubleBuffer)?
Actually I still do not understand why JViewport works in the standalone 
application.

One unrelated question. Did you try to use CALayer's embedding 
mechanics? Probably it is possible to add CAlayer which is used by the 
swing and awt to the FX CAlayer? In this case all problems related to 
the painting goes away and it will be much faster, only events should be 
generated(The same way our plugin works see CPlatformEmbeddedFrame).

On 10.12.2013 18:22, Anton V. Tarasov wrote:
> Hi Jim, Sergey and All,
>
> Please review the fix that adds support of Retina displays to 
> JLightweightFrame (which javafx SwingNode is based on).
>
> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>
> (After the fix goes into jdk9 it should be ported to 8u20 as well, 
> because the functionality is essential for SwingNode.)
>
> The general idea of the fix is as follows.
>
> A BufferedImage instance, being created in the context in which the 
> scale factor is determined and is different from one, is automatically 
> created with appropriately extended size. The image itself becomes a 
> scaled image (a "scale" private field is set on it). By the "context" 
> I mean the circumstances where the BufferedImage is related to a  
> JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a 
> GraphicsDevice which determine the scale factor.
>
> Here are the related changes:
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
> (the resizeBuffer method)
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>
> The "scale" value of a BufferedImage is used when 1) 
> BufferedImageGraphicsConfig is created 2) 
> BufImgSurfaceData.getDefaultScale() is called:
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>
> The former is used in the 
> GraphicsConfiguration.createCompatibleImage() calls, and the latter is 
> used in SurfaceManager.getImageScale(Image):
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>
> A scaled BufferedImage is supported by the SunGraphics2D.drawImage() 
> primitives. Here's the pattern of how the image may be created and drawn:
>
> int scale = <get the scale factor from the context>;
> BufferedImage img = new BufferedImage(width * scale, height * scale, 
> ...);
> img.setScale(scale); // an accessor is currently used instead
> <...>
> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a 
> specified rect
>
> In the first case, if the BufferedImage is created with an extended 
> size, the "scale" value of the image matters, it should be drawn as a 
> HiDPI image.
> In the second case, if the BufferedImage is created with an extended 
> size, the "scale" value of the image doesn't matter (it may not be 
> evidently set) as the image will anyway be scaled from its physical 
> bounds into provided logical bounds. This all should (as I suppose) 
> provide backward compatibility for buffered images that were created 
> in their logical bounds or without setting the "scale" field. For 
> instance, the AquaPainter.paintFromSingleCachedImage(...) method 
> creates & draws an image as follows:
>
> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
> int imgW = bounds.width * scale;
> int imgH = bounds.height * scale;
> BufferedImage img = new BufferedImage(imgW, imgH, ...);
> <paint into the img>
> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);
>
> Here, the img.scale value is not set (I didn't modify this code), and 
> SunGraphics2D doesn't treat the image as a HiDPI image, however it is 
> drawn as expected. An alternative way to draw the image would be:
>
> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
> int imgW = bounds.width * scale;
> int imgH = bounds.height * scale;
> BufferedImage img = new BufferedImage(imgW, imgH, ...);
> img.setScale(scale);
> <paint into the img>
> g.drawImage(img, bounds.x, bounds.y, ...);
>
> The result would be the same.
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>
> The following changes:
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>
> are defined by this logic. Running Swing via JLightweightFrame (JLF) 
> makes it "display agnostic". Swing is painted to an off-screen buffer 
> and it's the host (e.g. SwingNode) that renders the buffer on a 
> particular device. So, the host should detect the scale of the current 
> display and set it on JLF.
Does it mean that all methods related to the 
Component.getLocationOnScreen() does not work?
>
> However, AWT in order to paint to a volatile image requires 
> CGraphicsDevice and CGLSurfaceData to be created. By default AWT 
> creates CGraphicsDevice instances matching all the detected display 
> devices (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have 
> any platform window behind it, AWT can't match JLF to the exact device 
> it's currently displayed on.
Why? You can try to check it youseft via 
CGLGraphicsConfig.getBounds()+Peer.getBounds();
> So, on the one hand, AWT doesn't know which device is current and what 
> is the current scale (the host passes this value), but from the other 
> hand, AWT has a list of all the CGraphicsDevice instances.
>
> I tried to leverage from that fact. The 
> CPlatformLWView.getGraphicsDevice() method takes the current scale 
> from the JLF instance, and then tries to match it to an existent 
> device from the list. In case it can't find a device with the 
> specified scale (which should not actually happen, unless the host 
> passes an arbitrary scale value, which is not the case for SwingNode) 
> it takes a default device and changes its scale forcedly. I'm not sure 
> if I should create a new dummy device instance instead. The scale 
> factor of the device (which is then propagated to CGLSurfaceData on 
> its creation) is the only info that JLF will take from the device to 
> create a scaled volatile image.
>
> The following changes:
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>
> were made to map a backing store image to a scale factor.
>
> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on 
> scrolling. The method was not implemented for a graphics with a scale 
> transform and a BufImgSurfaceData (it threw exceptions). I took that 
> code, copied it to the BufImgSurfaceData.copyArea(...) and added a 
> general translation for the coords:
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>
> It works, but I'm not sure the implementation is eligible (I don't 
> know the details of the Blit class, at least it warns not to use the 
> same source and dest).
>
> The rest of the changes (not covered here) should be clear.
>
> Testing:
>
> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & 
> embedded into SwingNode [1]).
> - Testing both Nimbus and Aqua L&F.
> - Setting swing.volatileImageBufferEnabled=false/true for all 
> combinations.
>
> Currently, I see no regressions and no visual issues comparing a 
> standalone mode and a SwingSet mode.
>
> At the end, I suspect there may be some intersection b/w this fix and 
> the fix which introduced MultiResolutionToolkitImage. Unfortunately, I 
> didn't yet read that review saga... Please tell me if I should 
> incorporate anything from that fix.
>
> Thanks,
> Anton.
>
> [1] There's a SwingSet part of the fix which I'm going to post to the 
> jfx alias separately.
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Dec 10 16:46:40 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 11 Dec 2013 04:46:40 +0400
Subject: <AWT Dev> [8] Review Request: 8027778 [macosx] Full screen not
 working properly on 7u45 with 10.7
Message-ID: <52A7B5F0.5000208@oracle.com>

Hello.
Please review the fix for jdk 8.
Some history of the bug:
  - Initially we did not constrain size of the window and got JDK-7160609
  - Then we try to use a union of the screens to constrain of the window 
and got JDK-8015100.
  - Then we start to use GL_MAX_TEXTURE_SIZE/2. But for some systems it 
was too big JDK-8023159 OR too small JDK-8027778.
But on macosx 10.9 the windows are constrained automatically by the size 
of the screen(Petr please confirm).
I make the fix as simple as possible and use max(SCREEN_SIZE, 
GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native 
application on 10.9
nativeGetMaxTextureSize was moved under the render lock, where other 
related opengl data are initialized(see 
CGLGraphicsConfig.getCGLConfigInfo()). To me it seems safe because it 
works in similar way in jdk7 and CGLGraphicsConfig is recreated on the 
each event related to the screen(new resolution, new video card, etc).
Also I adds updateMinimumSize to the displayChanged and notifyReshape, 
to reapply a new constrain to the window.
Any suggestion are welcome.


Bugs which are covered by this fix:
https://bugs.openjdk.java.net/browse/JDK-8027778- after the fix the 
maximum size is not less than the screen
https://bugs.openjdk.java.net/browse/JDK-8015100 - we use half of the 
GL_MAX_TEXTURE_SIZE if supported by the system, and usually it is larger 
than the screen
https://bugs.openjdk.java.net/browse/JDK-8010999 - the maximum possible 
size of the window is 8192
Webrev can be found at: http://cr.openjdk.java.net/~serb/8027778/webrev.00

-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Tue Dec 10 23:23:33 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 11 Dec 2013 11:23:33 +0400
Subject: <AWT Dev> [8] Review Request: 8027778 [macosx] Full screen not
	working properly on 7u45 with 10.7
In-Reply-To: <52A7B5F0.5000208@oracle.com>
References: <52A7B5F0.5000208@oracle.com>
Message-ID: <6052F96A-08C5-49FC-A7D2-60DA2CA42E3F@oracle.com>

Hello, Sergey.

> I make the fix as simple as possible and use max(SCREEN_SIZE, GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native application on 10.9
This is not 100% true. If you create a big window on a big screen and then drag it to the smaller screen - you'll get a window which is bigger than the screen. 
So with your fix in case the GL_MAX_TEXTURE_SIZE/2 < SCREEN_SIZE, wouldn't the frame automatically constrain itself to the bounds of the smaller screen 
when dragged from the bigger screen?

With best regards. Petr.

On 11.12.2013, at 4:46, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hello.
> Please review the fix for jdk 8.
> Some history of the bug:
> - Initially we did not constrain size of the window and got JDK-7160609
> - Then we try to use a union of the screens to constrain of the window and got JDK-8015100.
> - Then we start to use GL_MAX_TEXTURE_SIZE/2. But for some systems it was too big JDK-8023159 OR too small JDK-8027778.
> But on macosx 10.9 the windows are constrained automatically by the size of the screen(Petr please confirm).
> I make the fix as simple as possible and use max(SCREEN_SIZE, GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native application on 10.9
> nativeGetMaxTextureSize was moved under the render lock, where other related opengl data are initialized(see CGLGraphicsConfig.getCGLConfigInfo()). To me it seems safe because it works in similar way in jdk7 and CGLGraphicsConfig is recreated on the each event related to the screen(new resolution, new video card, etc).
> Also I adds updateMinimumSize to the displayChanged and notifyReshape, to reapply a new constrain to the window.
> Any suggestion are welcome.
> 
> 
> Bugs which are covered by this fix:
> https://bugs.openjdk.java.net/browse/JDK-8027778- after the fix the maximum size is not less than the screen
> https://bugs.openjdk.java.net/browse/JDK-8015100 - we use half of the GL_MAX_TEXTURE_SIZE if supported by the system, and usually it is larger than the screen
> https://bugs.openjdk.java.net/browse/JDK-8010999 - the maximum possible size of the window is 8192
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8027778/webrev.00
> 
> -- 
> Best regards, Sergey.
> 


From james.graham at oracle.com  Wed Dec 11 01:14:19 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 11 Dec 2013 01:14:19 -0800
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A723B8.7090705@oracle.com>
References: <52A723B8.7090705@oracle.com>
Message-ID: <52A82CEB.3010203@oracle.com>

The "inCreateCI" field is not MT-safe.  BufferedImage objects don't have 
any threading restrictions so a solution that is MT-safe is required 
there in the BufferedImageGraphicsConfig object.  I also think that any 
device-associated GraphicsConfig objects should be MT-safe in those 
methods as well - I'm not sure if we've ever documented otherwise, but 
those methods have tended to be harmless to call on any thread and 
fairly far removed from the more platform/screen intensive parts of the 
AWT that might assume thread safety.

In BufferedImage, the private fields and methods will require an 
accessor method for the inner class to access them.  Is there a reason 
they can't be left package-accessible?

In JViewport, is there a reason why a map of various scaled backing 
stores are kept rather than just validating the existing backing store 
against the new desired scale and replacing it when it changes?  Does 
the scale on the backing store ping-pong back and forth between scales much?

BufImgSurfaceData - you have to validate the transform as not flipping 
or rotating (even quadrant rotation will violate your conditions.  I 
believe that testing the transform type with a mask consisting of the 
TRANSLATE and SCALE_MASK flags should be fine.  Also, do we wan to set a 
precedent of allowing copyArea under an arbitrary scale, or should we 
test it to make sure it is specifically the same scale as the device 
scale factor?

SG2D - I'm worried about the performance impliciations of adding a new 
method in that creates and returns an array on every drawImage call. Did 
you do a performance test with J2DBench to verify the impact of these 
operations?

With the new support for scaled BufferedImages we now have a situation 
where some images return their logical dimensions from 
getWidth/Height(null) and some return physical dimensions.  That's a 
little dicey as the method now has two meanings depending on how the 
images were created.  We're sort of between a rock and a hard place in 
that BufferedImage objects have a historical context for how their 
values relate to the pixels you can access, but we also have a 
relationship between how the return values of getWidth/Height(observer) 
relate to the size the image is drawn on the screen.  Is this only ever 
done for the backing store objects?  Do we ever expose them to 
developers?  Could this be implemented by having the code that renders 
the backing store state its explicit on-screen size so that we don't 
need to add any computations to the use of getWidth/Height(null) to SG2D?

I'm going to take a break here and hit send to get these concepts out 
into the discussion before I look too much further...

			...jim

On 12/10/13 6:22 AM, Anton V. Tarasov wrote:
> Hi Jim, Sergey and All,
>
> Please review the fix that adds support of Retina displays to
> JLightweightFrame (which javafx SwingNode is based on).
>
> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>
> (After the fix goes into jdk9 it should be ported to 8u20 as well,
> because the functionality is essential for SwingNode.)
>
> The general idea of the fix is as follows.
>
> A BufferedImage instance, being created in the context in which the
> scale factor is determined and is different from one, is automatically
> created with appropriately extended size. The image itself becomes a
> scaled image (a "scale" private field is set on it). By the "context" I
> mean the circumstances where the BufferedImage is related to a
> JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a
> GraphicsDevice which determine the scale factor.
>
> Here are the related changes:
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html
> (the resizeBuffer method)
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>
>
> The "scale" value of a BufferedImage is used when 1)
> BufferedImageGraphicsConfig is created 2)
> BufImgSurfaceData.getDefaultScale() is called:
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>
>
> The former is used in the GraphicsConfiguration.createCompatibleImage()
> calls, and the latter is used in SurfaceManager.getImageScale(Image):
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>
>
> A scaled BufferedImage is supported by the SunGraphics2D.drawImage()
> primitives. Here's the pattern of how the image may be created and drawn:
>
> int scale = <get the scale factor from the context>;
> BufferedImage img = new BufferedImage(width * scale, height * scale, ...);
> img.setScale(scale); // an accessor is currently used instead
> <...>
> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a
> specified rect
>
> In the first case, if the BufferedImage is created with an extended
> size, the "scale" value of the image matters, it should be drawn as a
> HiDPI image.
> In the second case, if the BufferedImage is created with an extended
> size, the "scale" value of the image doesn't matter (it may not be
> evidently set) as the image will anyway be scaled from its physical
> bounds into provided logical bounds. This all should (as I suppose)
> provide backward compatibility for buffered images that were created in
> their logical bounds or without setting the "scale" field. For instance,
> the AquaPainter.paintFromSingleCachedImage(...) method creates & draws
> an image as follows:
>
> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
> int imgW = bounds.width * scale;
> int imgH = bounds.height * scale;
> BufferedImage img = new BufferedImage(imgW, imgH, ...);
> <paint into the img>
> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);
>
> Here, the img.scale value is not set (I didn't modify this code), and
> SunGraphics2D doesn't treat the image as a HiDPI image, however it is
> drawn as expected. An alternative way to draw the image would be:
>
> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
> int imgW = bounds.width * scale;
> int imgH = bounds.height * scale;
> BufferedImage img = new BufferedImage(imgW, imgH, ...);
> img.setScale(scale);
> <paint into the img>
> g.drawImage(img, bounds.x, bounds.y, ...);
>
> The result would be the same.
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>
>
> The following changes:
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>
>
> are defined by this logic. Running Swing via JLightweightFrame (JLF)
> makes it "display agnostic". Swing is painted to an off-screen buffer
> and it's the host (e.g. SwingNode) that renders the buffer on a
> particular device. So, the host should detect the scale of the current
> display and set it on JLF.
>
> However, AWT in order to paint to a volatile image requires
> CGraphicsDevice and CGLSurfaceData to be created. By default AWT creates
> CGraphicsDevice instances matching all the detected display devices
> (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any
> platform window behind it, AWT can't match JLF to the exact device it's
> currently displayed on. So, on the one hand, AWT doesn't know which
> device is current and what is the current scale (the host passes this
> value), but from the other hand, AWT has a list of all the
> CGraphicsDevice instances.
>
> I tried to leverage from that fact. The
> CPlatformLWView.getGraphicsDevice() method takes the current scale from
> the JLF instance, and then tries to match it to an existent device from
> the list. In case it can't find a device with the specified scale (which
> should not actually happen, unless the host passes an arbitrary scale
> value, which is not the case for SwingNode) it takes a default device
> and changes its scale forcedly. I'm not sure if I should create a new
> dummy device instance instead. The scale factor of the device (which is
> then propagated to CGLSurfaceData on its creation) is the only info that
> JLF will take from the device to create a scaled volatile image.
>
> The following changes:
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>
>
> were made to map a backing store image to a scale factor.
>
> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on
> scrolling. The method was not implemented for a graphics with a scale
> transform and a BufImgSurfaceData (it threw exceptions). I took that
> code, copied it to the BufImgSurfaceData.copyArea(...) and added a
> general translation for the coords:
>
> -
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>
>
> It works, but I'm not sure the implementation is eligible (I don't know
> the details of the Blit class, at least it warns not to use the same
> source and dest).
>
> The rest of the changes (not covered here) should be clear.
>
> Testing:
>
> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode &
> embedded into SwingNode [1]).
> - Testing both Nimbus and Aqua L&F.
> - Setting swing.volatileImageBufferEnabled=false/true for all combinations.
>
> Currently, I see no regressions and no visual issues comparing a
> standalone mode and a SwingSet mode.
>
> At the end, I suspect there may be some intersection b/w this fix and
> the fix which introduced MultiResolutionToolkitImage. Unfortunately, I
> didn't yet read that review saga... Please tell me if I should
> incorporate anything from that fix.
>
> Thanks,
> Anton.
>
> [1] There's a SwingSet part of the fix which I'm going to post to the
> jfx alias separately.
>

From anton.tarasov at oracle.com  Wed Dec 11 01:18:32 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Wed, 11 Dec 2013 13:18:32 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A7A319.80001@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
Message-ID: <52A82DE8.4070707@oracle.com>

Hi Sergey,

On 11.12.2013 3:26, Sergey Bylokhov wrote:
> Hi, Anton.
> My expectation was that everything should work automatically, if you get correct CGraphicsDevice 
> for the embedded swing window + some tweaks in the code related to the peer and CGLSurfaceData/
>
> Why we need all this change in 
> CGraphicsDevice,CGLGraphicsConfig,OffScreenImage,CPlatformLWView,JViewport,RepaintManager.

With Nimus, at some moment, when the nimbus.AbstractRegionPainter.paint(Graphics2D g, ...) method is 
called it is passed the graphics instance created by JLF.createGraphics() which derives it from the 
JLF's root buffered image. Then, somewhere up the stack the method calls for 
getImage(g.getDeviceConfiguration(),..), where the graphics conf is of BufferdeImageGraphicsConfig 
type. This flows into GraphicsConfiguration.createCompatibleVolatileImage(int w, int h, ...) and 
then into BufImgVolatileSurfaceManager which doesn't support acceleration, and eventually into 
BufferedImageGraphicsConfig.createCompatibleImage(int w, int h, ...). The [w, h] values passed here 
represent a logical size of a Nimbus ui element. Unless I scale the size of the requested image 
here, the ui element is shown stretched. That's why the changes in BufferedImageGraphicsConfig.

With Aqua, I don't observe calls into BufImgVolatileSurfaceManager. I suppose the reason is that a 
GraphicsConfiguration instance is always taken from a component (from the JLF's hierarchy) which is 
tight to a CGraphicsDevice and has a CGLGraphicsConfig, not BufferdeImageGraphicsConfig. 
CGLVolatileSurfaceManager enables acceleration, and so the process of a volatile image creation 
never falls back to CLGGraphicsConfig.createCompatibleImage(...). By "never" I mean that I didn't 
catch it with the tests I ran. However, "find usages" shows that these methods are directly called 
from CTrayIcon, CDragSourceContextPeer, CCustomCursor, at least. I rather should cover those areas 
with some tests as well. Anyway, I've made these methods 
(CLGGraphicsConfig.createCompatibleImage(...)) consistent with the 
BufferedImageGraphicsConfig.createCompatibleImage(...) methods and with the general idea I've 
described before.

Then, the other files you're referring to:

- CPlatformLWView

As I explained before, AWT in the lw embedding mode can't match a window to the display it is 
showing on, simply because it doesn't have a platform window underneath. 
CPlatformView.nativeGetNSViewDisplayID(getAWTView()) returns zero, and so 
CPlatformView.getGraphicsDevice() returns default device, not necessarily matching the scale factor 
of the current device.

- CGraphicsDevice

This setter is only called from CPlatformLWView.getGraphicsDevice(). I've explained it in my 
previous message. It's needed to change the scale factor of the default device when no device in the 
list fits. The case is impossible with the current implementation of SwingNode (which only passes 
JLF a scale factor matching one of a real display), however, as JLF provides a generic lw embedding 
API, I should cover that case as well.

- OffScreenImage

I've put a BufferedImage accessor there, nothing else. I didn't find a better place... (I'd 
appreciate showing it).

- JViewport, RepaintManager

These classes create a double buffer. In case the buffer is backed by a BufferedImage, it will be 
created with the current scale factor set. The buffer won't be changed when a user moves the host 
window across multiple screens with different scales. I see two options. 1) Drop the double buffer 
reference every time the scale changes (in that case, the buffer will be recreated every time, I 
cross a screen) 2) Create a map which will cache the buffers (say, for 1 and 2 scale factors for 
double screen env). I think the second approach is better.

 > Probably it will be better to disable doublebuffering and SwingPaintEventDispatcher 
completely(see swing.showFromDoubleBuffer)?

Why? If we can manage it for JLF/SwingNode, why should we downgrade performance?

> Actually I still do not understand why JViewport works in the standalone application.

Could you please clarify, I don't understand this question...

>
> One unrelated question. Did you try to use CALayer's embedding mechanics? Probably it is possible 
> to add CAlayer which is used by the swing and awt to the FX CAlayer? In this case all problems 
> related to the painting goes away and it will be much faster, only events should be generated(The 
> same way our plugin works see CPlatformEmbeddedFrame).

This is in plans (interop "unified rendering" for d3d, ogl). At least, there are plans to 
investigate it....

Thanks for the review!

Anton.

>
> On 10.12.2013 18:22, Anton V. Tarasov wrote:
>> Hi Jim, Sergey and All,
>>
>> Please review the fix that adds support of Retina displays to JLightweightFrame (which javafx 
>> SwingNode is based on).
>>
>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>
>> (After the fix goes into jdk9 it should be ported to 8u20 as well, because the functionality is 
>> essential for SwingNode.)
>>
>> The general idea of the fix is as follows.
>>
>> A BufferedImage instance, being created in the context in which the scale factor is determined 
>> and is different from one, is automatically created with appropriately extended size. The image 
>> itself becomes a scaled image (a "scale" private field is set on it). By the "context" I mean the 
>> circumstances where the BufferedImage is related to a  JLightweightFrame, a 
>> GraphicsConfiguration, a SurfaceData, or a GraphicsDevice which determine the scale factor.
>>
>> Here are the related changes:
>>
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
>> (the resizeBuffer method)
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>>
>> The "scale" value of a BufferedImage is used when 1) BufferedImageGraphicsConfig is created 2) 
>> BufImgSurfaceData.getDefaultScale() is called:
>>
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>
>> The former is used in the GraphicsConfiguration.createCompatibleImage() calls, and the latter is 
>> used in SurfaceManager.getImageScale(Image):
>>
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>>
>> A scaled BufferedImage is supported by the SunGraphics2D.drawImage() primitives. Here's the 
>> pattern of how the image may be created and drawn:
>>
>> int scale = <get the scale factor from the context>;
>> BufferedImage img = new BufferedImage(width * scale, height * scale, ...);
>> img.setScale(scale); // an accessor is currently used instead
>> <...>
>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a specified rect
>>
>> In the first case, if the BufferedImage is created with an extended size, the "scale" value of 
>> the image matters, it should be drawn as a HiDPI image.
>> In the second case, if the BufferedImage is created with an extended size, the "scale" value of 
>> the image doesn't matter (it may not be evidently set) as the image will anyway be scaled from 
>> its physical bounds into provided logical bounds. This all should (as I suppose) provide backward 
>> compatibility for buffered images that were created in their logical bounds or without setting 
>> the "scale" field. For instance, the AquaPainter.paintFromSingleCachedImage(...) method creates & 
>> draws an image as follows:
>>
>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>> int imgW = bounds.width * scale;
>> int imgH = bounds.height * scale;
>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>> <paint into the img>
>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);
>>
>> Here, the img.scale value is not set (I didn't modify this code), and SunGraphics2D doesn't treat 
>> the image as a HiDPI image, however it is drawn as expected. An alternative way to draw the image 
>> would be:
>>
>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>> int imgW = bounds.width * scale;
>> int imgH = bounds.height * scale;
>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>> img.setScale(scale);
>> <paint into the img>
>> g.drawImage(img, bounds.x, bounds.y, ...);
>>
>> The result would be the same.
>>
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>>
>> The following changes:
>>
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>>
>> are defined by this logic. Running Swing via JLightweightFrame (JLF) makes it "display agnostic". 
>> Swing is painted to an off-screen buffer and it's the host (e.g. SwingNode) that renders the 
>> buffer on a particular device. So, the host should detect the scale of the current display and 
>> set it on JLF.
> Does it mean that all methods related to the Component.getLocationOnScreen() does not work?
>>
>> However, AWT in order to paint to a volatile image requires CGraphicsDevice and CGLSurfaceData to 
>> be created. By default AWT creates CGraphicsDevice instances matching all the detected display 
>> devices (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any platform window behind 
>> it, AWT can't match JLF to the exact device it's currently displayed on.
> Why? You can try to check it youseft via CGLGraphicsConfig.getBounds()+Peer.getBounds();
>> So, on the one hand, AWT doesn't know which device is current and what is the current scale (the 
>> host passes this value), but from the other hand, AWT has a list of all the CGraphicsDevice 
>> instances.
>>
>> I tried to leverage from that fact. The CPlatformLWView.getGraphicsDevice() method takes the 
>> current scale from the JLF instance, and then tries to match it to an existent device from the 
>> list. In case it can't find a device with the specified scale (which should not actually happen, 
>> unless the host passes an arbitrary scale value, which is not the case for SwingNode) it takes a 
>> default device and changes its scale forcedly. I'm not sure if I should create a new dummy device 
>> instance instead. The scale factor of the device (which is then propagated to CGLSurfaceData on 
>> its creation) is the only info that JLF will take from the device to create a scaled volatile image.
>>
>> The following changes:
>>
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>>
>> were made to map a backing store image to a scale factor.
>>
>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on scrolling. The method was 
>> not implemented for a graphics with a scale transform and a BufImgSurfaceData (it threw 
>> exceptions). I took that code, copied it to the BufImgSurfaceData.copyArea(...) and added a 
>> general translation for the coords:
>>
>> - 
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>
>> It works, but I'm not sure the implementation is eligible (I don't know the details of the Blit 
>> class, at least it warns not to use the same source and dest).
>>
>> The rest of the changes (not covered here) should be clear.
>>
>> Testing:
>>
>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & embedded into SwingNode [1]).
>> - Testing both Nimbus and Aqua L&F.
>> - Setting swing.volatileImageBufferEnabled=false/true for all combinations.
>>
>> Currently, I see no regressions and no visual issues comparing a standalone mode and a SwingSet 
>> mode.
>>
>> At the end, I suspect there may be some intersection b/w this fix and the fix which introduced 
>> MultiResolutionToolkitImage. Unfortunately, I didn't yet read that review saga... Please tell me 
>> if I should incorporate anything from that fix.
>>
>> Thanks,
>> Anton.
>>
>> [1] There's a SwingSet part of the fix which I'm going to post to the jfx alias separately.
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed Dec 11 02:38:38 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 11 Dec 2013 14:38:38 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A82DE8.4070707@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com>
Message-ID: <52A840AE.2010000@oracle.com>

On 11.12.2013 13:18, Anton V. Tarasov wrote:
> Hi Sergey,
>
> On 11.12.2013 3:26, Sergey Bylokhov wrote:
>> Hi, Anton.
>> My expectation was that everything should work automatically, if you 
>> get correct CGraphicsDevice for the embedded swing window + some 
>> tweaks in the code related to the peer and CGLSurfaceData/
>>
>> Why we need all this change in 
>> CGraphicsDevice,CGLGraphicsConfig,OffScreenImage,CPlatformLWView,JViewport,RepaintManager.
>
> With Nimus, at some moment, when the 
> nimbus.AbstractRegionPainter.paint(Graphics2D g, ...) method is called 
> it is passed the graphics instance created by JLF.createGraphics() 
> which derives it from the JLF's root buffered image. Then, somewhere 
> up the stack the method calls for getImage(g.getDeviceConfiguration(),..),
Yes, correct. But you can created double sized surface for you buffered 
image(in the same way as it was done for volatile) and provide correct 
DeviceConfiguration for it.
> where the graphics conf is of BufferdeImageGraphicsConfig type. This 
> flows into GraphicsConfiguration.createCompatibleVolatileImage(int w, 
> int h, ...) and then into BufImgVolatileSurfaceManager which doesn't 
> support acceleration, and eventually into 
> BufferedImageGraphicsConfig.createCompatibleImage(int w, int h, ...). 
> The [w, h] values passed here represent a logical size of a Nimbus ui 
> element. Unless I scale the size of the requested image here, the ui 
> element is shown stretched. That's why the changes in 
> BufferedImageGraphicsConfig.
>
> With Aqua, I don't observe calls into BufImgVolatileSurfaceManager. I 
> suppose the reason is that a GraphicsConfiguration instance is always 
> taken from a component (from the JLF's hierarchy) which is tight to a 
> CGraphicsDevice and has a CGLGraphicsConfig, not 
> BufferdeImageGraphicsConfig. CGLVolatileSurfaceManager enables 
> acceleration, and so the process of a volatile image creation never 
> falls back to CLGGraphicsConfig.createCompatibleImage(...). By "never" 
> I mean that I didn't catch it with the tests I ran. However, "find 
> usages" shows that these methods are directly called from CTrayIcon, 
> CDragSourceContextPeer, CCustomCursor, at least. I rather should cover 
> those areas with some tests as well. Anyway, I've made these methods 
> (CLGGraphicsConfig.createCompatibleImage(...)) consistent with the 
> BufferedImageGraphicsConfig.createCompatibleImage(...) methods and 
> with the general idea I've described before.
>
> Then, the other files you're referring to:
>
> - CPlatformLWView
>
> As I explained before, AWT in the lw embedding mode can't match a 
> window to the display it is showing on, simply because it doesn't have 
> a platform window underneath. 
> CPlatformView.nativeGetNSViewDisplayID(getAWTView()) returns zero, and 
> so CPlatformView.getGraphicsDevice() returns default device, not 
> necessarily matching the scale factor of the current device.
Why? You can try to check it youseft via 
CGLGraphicsConfig.getBounds()+Peer.getBounds(); You need to override 
CPlatformWindow.getGraphicsDevice() and return correct device.  I see 
that the similar bug exists in applets where 
CPlatformEmbeddedFrame.getGraphicsDevice always return  default device.
Same question about Component.getLocationOnScreen() is working in SwingNode?
>
> - CGraphicsDevice
>
> This setter is only called from CPlatformLWView.getGraphicsDevice(). 
> I've explained it in my previous message. It's needed to change the 
> scale factor of the default device when no device in the list fits. 
> The case is impossible with the current implementation of SwingNode 
> (which only passes JLF a scale factor matching one of a real display), 
> however, as JLF provides a generic lw embedding API, I should cover 
> that case as well.
>
> - OffScreenImage
>
> I've put a BufferedImage accessor there, nothing else. I didn't find a 
> better place... (I'd appreciate showing it).
>
> - JViewport, RepaintManager
>
> These classes create a double buffer. In case the buffer is backed by 
> a BufferedImage, it will be created with the current scale factor set. 
> The buffer won't be changed when a user moves the host window across 
> multiple screens with different scales. I see two options. 1) Drop the 
> double buffer reference every time the scale changes (in that case, 
> the buffer will be recreated every time, I cross a screen) 2) Create a 
> map which will cache the buffers (say, for 1 and 2 scale factors for 
> double screen env). I think the second approach is better.
>
> > Probably it will be better to disable doublebuffering and 
> SwingPaintEventDispatcher completely(see swing.showFromDoubleBuffer)?
>
> Why? If we can manage it for JLF/SwingNode, why should we downgrade 
> performance?
You have 1 buffere on fx side, buffer in SwingNode, buffer in jviewport, 
and swing itself use double buffering.
>
>> Actually I still do not understand why JViewport works in the 
>> standalone application.
>
> Could you please clarify, I don't understand this question...
I see that JViewport use Offscreen image as a double buffer, is that 
true that it use it in the standalone swing application? If yes why it 
works.
>
>>
>> One unrelated question. Did you try to use CALayer's embedding 
>> mechanics? Probably it is possible to add CAlayer which is used by 
>> the swing and awt to the FX CAlayer? In this case all problems 
>> related to the painting goes away and it will be much faster, only 
>> events should be generated(The same way our plugin works see 
>> CPlatformEmbeddedFrame).
>
> This is in plans (interop "unified rendering" for d3d, ogl). At least, 
> there are plans to investigate it....
I guess it could be simpler than the current solution, because different 
layers will have different context which will be used by the swing and 
fx independently.
>
> Thanks for the review!
>
> Anton.
>
>>
>> On 10.12.2013 18:22, Anton V. Tarasov wrote:
>>> Hi Jim, Sergey and All,
>>>
>>> Please review the fix that adds support of Retina displays to 
>>> JLightweightFrame (which javafx SwingNode is based on).
>>>
>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>>
>>> (After the fix goes into jdk9 it should be ported to 8u20 as well, 
>>> because the functionality is essential for SwingNode.)
>>>
>>> The general idea of the fix is as follows.
>>>
>>> A BufferedImage instance, being created in the context in which the 
>>> scale factor is determined and is different from one, is 
>>> automatically created with appropriately extended size. The image 
>>> itself becomes a scaled image (a "scale" private field is set on 
>>> it). By the "context" I mean the circumstances where the 
>>> BufferedImage is related to a JLightweightFrame, a 
>>> GraphicsConfiguration, a SurfaceData, or a GraphicsDevice which 
>>> determine the scale factor.
>>>
>>> Here are the related changes:
>>>
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
>>> (the resizeBuffer method)
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>>>
>>> The "scale" value of a BufferedImage is used when 1) 
>>> BufferedImageGraphicsConfig is created 2) 
>>> BufImgSurfaceData.getDefaultScale() is called:
>>>
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>
>>> The former is used in the 
>>> GraphicsConfiguration.createCompatibleImage() calls, and the latter 
>>> is used in SurfaceManager.getImageScale(Image):
>>>
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>>>
>>> A scaled BufferedImage is supported by the SunGraphics2D.drawImage() 
>>> primitives. Here's the pattern of how the image may be created and 
>>> drawn:
>>>
>>> int scale = <get the scale factor from the context>;
>>> BufferedImage img = new BufferedImage(width * scale, height * scale, 
>>> ...);
>>> img.setScale(scale); // an accessor is currently used instead
>>> <...>
>>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
>>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a 
>>> specified rect
>>>
>>> In the first case, if the BufferedImage is created with an extended 
>>> size, the "scale" value of the image matters, it should be drawn as 
>>> a HiDPI image.
>>> In the second case, if the BufferedImage is created with an extended 
>>> size, the "scale" value of the image doesn't matter (it may not be 
>>> evidently set) as the image will anyway be scaled from its physical 
>>> bounds into provided logical bounds. This all should (as I suppose) 
>>> provide backward compatibility for buffered images that were created 
>>> in their logical bounds or without setting the "scale" field. For 
>>> instance, the AquaPainter.paintFromSingleCachedImage(...) method 
>>> creates & draws an image as follows:
>>>
>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>> int imgW = bounds.width * scale;
>>> int imgH = bounds.height * scale;
>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>> <paint into the img>
>>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, 
>>> null);
>>>
>>> Here, the img.scale value is not set (I didn't modify this code), 
>>> and SunGraphics2D doesn't treat the image as a HiDPI image, however 
>>> it is drawn as expected. An alternative way to draw the image would be:
>>>
>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>> int imgW = bounds.width * scale;
>>> int imgH = bounds.height * scale;
>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>> img.setScale(scale);
>>> <paint into the img>
>>> g.drawImage(img, bounds.x, bounds.y, ...);
>>>
>>> The result would be the same.
>>>
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>>>
>>> The following changes:
>>>
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>>>
>>> are defined by this logic. Running Swing via JLightweightFrame (JLF) 
>>> makes it "display agnostic". Swing is painted to an off-screen 
>>> buffer and it's the host (e.g. SwingNode) that renders the buffer on 
>>> a particular device. So, the host should detect the scale of the 
>>> current display and set it on JLF.
>> Does it mean that all methods related to the 
>> Component.getLocationOnScreen() does not work?
>>>
>>> However, AWT in order to paint to a volatile image requires 
>>> CGraphicsDevice and CGLSurfaceData to be created. By default AWT 
>>> creates CGraphicsDevice instances matching all the detected display 
>>> devices (CGraphicsEnvironment.initDevices()). But, as JLF doesn't 
>>> have any platform window behind it, AWT can't match JLF to the exact 
>>> device it's currently displayed on.
>> Why? You can try to check it youseft via 
>> CGLGraphicsConfig.getBounds()+Peer.getBounds();
>>> So, on the one hand, AWT doesn't know which device is current and 
>>> what is the current scale (the host passes this value), but from the 
>>> other hand, AWT has a list of all the CGraphicsDevice instances.
>>>
>>> I tried to leverage from that fact. The 
>>> CPlatformLWView.getGraphicsDevice() method takes the current scale 
>>> from the JLF instance, and then tries to match it to an existent 
>>> device from the list. In case it can't find a device with the 
>>> specified scale (which should not actually happen, unless the host 
>>> passes an arbitrary scale value, which is not the case for 
>>> SwingNode) it takes a default device and changes its scale forcedly. 
>>> I'm not sure if I should create a new dummy device instance instead. 
>>> The scale factor of the device (which is then propagated to 
>>> CGLSurfaceData on its creation) is the only info that JLF will take 
>>> from the device to create a scaled volatile image.
>>>
>>> The following changes:
>>>
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>>>
>>> were made to map a backing store image to a scale factor.
>>>
>>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on 
>>> scrolling. The method was not implemented for a graphics with a 
>>> scale transform and a BufImgSurfaceData (it threw exceptions). I 
>>> took that code, copied it to the BufImgSurfaceData.copyArea(...) and 
>>> added a general translation for the coords:
>>>
>>> - 
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>
>>> It works, but I'm not sure the implementation is eligible (I don't 
>>> know the details of the Blit class, at least it warns not to use the 
>>> same source and dest).
>>>
>>> The rest of the changes (not covered here) should be clear.
>>>
>>> Testing:
>>>
>>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & 
>>> embedded into SwingNode [1]).
>>> - Testing both Nimbus and Aqua L&F.
>>> - Setting swing.volatileImageBufferEnabled=false/true for all 
>>> combinations.
>>>
>>> Currently, I see no regressions and no visual issues comparing a 
>>> standalone mode and a SwingSet mode.
>>>
>>> At the end, I suspect there may be some intersection b/w this fix 
>>> and the fix which introduced MultiResolutionToolkitImage. 
>>> Unfortunately, I didn't yet read that review saga... Please tell me 
>>> if I should incorporate anything from that fix.
>>>
>>> Thanks,
>>> Anton.
>>>
>>> [1] There's a SwingSet part of the fix which I'm going to post to 
>>> the jfx alias separately.
>>>
>>
>>
>


-- 
Best regards, Sergey.


From anton.tarasov at oracle.com  Wed Dec 11 02:40:04 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Wed, 11 Dec 2013 14:40:04 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A77231.1030902@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A77231.1030902@oracle.com>
Message-ID: <52A84104.9040400@oracle.com>

Hi Anthony,

On 10.12.2013 23:57, Anthony Petrov wrote:
> Hi Anton,
>
> I'm not an expert in HiDPI rendering, so I'll defer to Jim and Sergey to comment on the core 
> changes. I still have a few comments regarding the fix:
>
> 1. src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
>>  265         contentView.initialize(peer, null);

> Are you sure calling view.initialize() from CPW.initializeBase() doesn't introduce any unwanted 
> side-effects? Interestingly, the contentView field gets re-written and re-initialized in the 
> CPW.initialize() method after calling the initializeBase(). Seems very strange to me.

Oh, this is a miss. I should have put it into CPlatformLWWindow. Thanks for noticing!

>
>
> 2. I'm not sure if adding the scale field to the BI is a good idea. I think that the image 
> shouldn't be aware of any scale. After all, it's just an image, a bitmap. It has its real 
> dimensions corresponding to the actual size of the image stored in RAM. Whether this image is 
> going to be represented as a scaled image is something that a code that uses the image should be 
> concerned with, not the image itself.

There are two options. 1) Follow to your logic, that is to fix every place in AWT/Swing where 
BufferedImage is created. In which case in every such place we will have to get a current scale 
factor from the context. 2) Don't touch that code, but solve the task in some generic way, the way I 
tried to implement, when a buffered image is created with an extended size right in the factory methods.

The logic of the first approach is simpler. However, it would require lots of modifications (in the 
L&F code, and not only there). And it would require to take into account the scale factor every time 
a new buffered image case is added to the code. Still, this is possible.

With the scond approach I don't need to bother about that code, I just create scaled images "on the 
fly".

 > I think that the image shouldn't be aware of any scale.

The "scale" field put into the BufferedImage class means that an image instance should (or 
shouldn't) be treated as a HiDPI image by the Graphics.drawImage(). So, this is a kind of a special 
"scale" case, aimed at supporting Retina technology. Probably it deserves a better name, 
"hidpiScale" or something. So, it's not that the image has been scaled by the user to be drawn on a 
lager area, but that the image should (or shouldn't) be scaled just to "look smoothly" on a Retina 
display. That's what I was thinking about...

>
>
>
> 3. src/share/classes/java/awt/peer/FramePeer.java
>>  139     default void notifyScaleFactorChanged() {}
>
> I think this deserves to be declared in WindowPeer so that we could use it w/o additional 
> modifications in the future if we add support for public notifications about the scale factor 
> changes.

Ok.

>
>
> 4. I'm CC'ing swing-dev@ and Alexander Scherbatiy to review changes in the JViewport class and 
> other Swing classes.

Thanks for the review!

Anton.

>
> -- 
> best regards,
> Anthony
>
> On 12/10/2013 06:22 PM, Anton V. Tarasov wrote:
>> Hi Jim, Sergey and All,
>>
>> Please review the fix that adds support of Retina displays to
>> JLightweightFrame (which javafx SwingNode is based on).
>>
>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>
>> (After the fix goes into jdk9 it should be ported to 8u20 as well,
>> because the functionality is essential for SwingNode.)
>>
>> The general idea of the fix is as follows.
>>
>> A BufferedImage instance, being created in the context in which the
>> scale factor is determined and is different from one, is automatically
>> created with appropriately extended size. The image itself becomes a
>> scaled image (a "scale" private field is set on it). By the "context" I
>> mean the circumstances where the BufferedImage is related to a
>> JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a
>> GraphicsDevice which determine the scale factor.
>>
>> Here are the related changes:
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html 
>>
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html 
>>
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
>>
>> (the resizeBuffer method)
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html 
>>
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html 
>>
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html 
>>
>>
>>
>> The "scale" value of a BufferedImage is used when 1)
>> BufferedImageGraphicsConfig is created 2)
>> BufImgSurfaceData.getDefaultScale() is called:
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html 
>>
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html 
>>
>>
>>
>> The former is used in the GraphicsConfiguration.createCompatibleImage()
>> calls, and the latter is used in SurfaceManager.getImageScale(Image):
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html 
>>
>>
>>
>> A scaled BufferedImage is supported by the SunGraphics2D.drawImage()
>> primitives. Here's the pattern of how the image may be created and drawn:
>>
>> int scale = <get the scale factor from the context>;
>> BufferedImage img = new BufferedImage(width * scale, height * scale, ...);
>> img.setScale(scale); // an accessor is currently used instead
>> <...>
>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a
>> specified rect
>>
>> In the first case, if the BufferedImage is created with an extended
>> size, the "scale" value of the image matters, it should be drawn as a
>> HiDPI image.
>> In the second case, if the BufferedImage is created with an extended
>> size, the "scale" value of the image doesn't matter (it may not be
>> evidently set) as the image will anyway be scaled from its physical
>> bounds into provided logical bounds. This all should (as I suppose)
>> provide backward compatibility for buffered images that were created in
>> their logical bounds or without setting the "scale" field. For instance,
>> the AquaPainter.paintFromSingleCachedImage(...) method creates & draws
>> an image as follows:
>>
>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>> int imgW = bounds.width * scale;
>> int imgH = bounds.height * scale;
>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>> <paint into the img>
>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);
>>
>> Here, the img.scale value is not set (I didn't modify this code), and
>> SunGraphics2D doesn't treat the image as a HiDPI image, however it is
>> drawn as expected. An alternative way to draw the image would be:
>>
>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>> int imgW = bounds.width * scale;
>> int imgH = bounds.height * scale;
>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>> img.setScale(scale);
>> <paint into the img>
>> g.drawImage(img, bounds.x, bounds.y, ...);
>>
>> The result would be the same.
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html 
>>
>>
>>
>> The following changes:
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html 
>>
>>
>>
>> are defined by this logic. Running Swing via JLightweightFrame (JLF)
>> makes it "display agnostic". Swing is painted to an off-screen buffer
>> and it's the host (e.g. SwingNode) that renders the buffer on a
>> particular device. So, the host should detect the scale of the current
>> display and set it on JLF.
>>
>> However, AWT in order to paint to a volatile image requires
>> CGraphicsDevice and CGLSurfaceData to be created. By default AWT creates
>> CGraphicsDevice instances matching all the detected display devices
>> (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any
>> platform window behind it, AWT can't match JLF to the exact device it's
>> currently displayed on. So, on the one hand, AWT doesn't know which
>> device is current and what is the current scale (the host passes this
>> value), but from the other hand, AWT has a list of all the
>> CGraphicsDevice instances.
>>
>> I tried to leverage from that fact. The
>> CPlatformLWView.getGraphicsDevice() method takes the current scale from
>> the JLF instance, and then tries to match it to an existent device from
>> the list. In case it can't find a device with the specified scale (which
>> should not actually happen, unless the host passes an arbitrary scale
>> value, which is not the case for SwingNode) it takes a default device
>> and changes its scale forcedly. I'm not sure if I should create a new
>> dummy device instance instead. The scale factor of the device (which is
>> then propagated to CGLSurfaceData on its creation) is the only info that
>> JLF will take from the device to create a scaled volatile image.
>>
>> The following changes:
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html 
>>
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html 
>>
>>
>>
>> were made to map a backing store image to a scale factor.
>>
>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on
>> scrolling. The method was not implemented for a graphics with a scale
>> transform and a BufImgSurfaceData (it threw exceptions). I took that
>> code, copied it to the BufImgSurfaceData.copyArea(...) and added a
>> general translation for the coords:
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html 
>>
>>
>>
>> It works, but I'm not sure the implementation is eligible (I don't know
>> the details of the Blit class, at least it warns not to use the same
>> source and dest).
>>
>> The rest of the changes (not covered here) should be clear.
>>
>> Testing:
>>
>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode &
>> embedded into SwingNode [1]).
>> - Testing both Nimbus and Aqua L&F.
>> - Setting swing.volatileImageBufferEnabled=false/true for all combinations.
>>
>> Currently, I see no regressions and no visual issues comparing a
>> standalone mode and a SwingSet mode.
>>
>> At the end, I suspect there may be some intersection b/w this fix and
>> the fix which introduced MultiResolutionToolkitImage. Unfortunately, I
>> didn't yet read that review saga... Please tell me if I should
>> incorporate anything from that fix.
>>
>> Thanks,
>> Anton.
>>
>> [1] There's a SwingSet part of the fix which I'm going to post to the
>> jfx alias separately.
>>


From Sergey.Bylokhov at oracle.com  Wed Dec 11 02:49:20 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 11 Dec 2013 14:49:20 +0400
Subject: <AWT Dev> [8] Review Request: 8027778 [macosx] Full screen not
 working properly on 7u45 with 10.7
In-Reply-To: <6052F96A-08C5-49FC-A7D2-60DA2CA42E3F@oracle.com>
References: <52A7B5F0.5000208@oracle.com>
	<6052F96A-08C5-49FC-A7D2-60DA2CA42E3F@oracle.com>
Message-ID: <52A84330.6090904@oracle.com>

On 11.12.2013 11:23, Petr Pchelko wrote:
> Hello, Sergey.
> I make the fix as simple as possible and use max(SCREEN_SIZE, GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native application on 10.9
> This is not 100% true. If you create a big window on a big screen and then drag it to the smaller screen - you'll get a window which is bigger than the screen.
> So with your fix in case the GL_MAX_TEXTURE_SIZE/2 < SCREEN_SIZE, wouldn't the frame automatically constrain itself to the bounds of the smaller screen
> when dragged from the bigger screen?
The question is about do we trust to the GL_MAX_TEXTURE_SIZE or not, if 
we assume that GL_MAX_TEXTURE_SIZE/2 is a maximum supported opengl 
texture size, and it less than a screen-> we could assume that the 
screen size is supported only or... what size?
>
> With best regards. Petr.
>
> On 11.12.2013, at 4:46, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hello.
>> Please review the fix for jdk 8.
>> Some history of the bug:
>> - Initially we did not constrain size of the window and got JDK-7160609
>> - Then we try to use a union of the screens to constrain of the window and got JDK-8015100.
>> - Then we start to use GL_MAX_TEXTURE_SIZE/2. But for some systems it was too big JDK-8023159 OR too small JDK-8027778.
>> But on macosx 10.9 the windows are constrained automatically by the size of the screen(Petr please confirm).
>> I make the fix as simple as possible and use max(SCREEN_SIZE, GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native application on 10.9
>> nativeGetMaxTextureSize was moved under the render lock, where other related opengl data are initialized(see CGLGraphicsConfig.getCGLConfigInfo()). To me it seems safe because it works in similar way in jdk7 and CGLGraphicsConfig is recreated on the each event related to the screen(new resolution, new video card, etc).
>> Also I adds updateMinimumSize to the displayChanged and notifyReshape, to reapply a new constrain to the window.
>> Any suggestion are welcome.
>>
>>
>> Bugs which are covered by this fix:
>> https://bugs.openjdk.java.net/browse/JDK-8027778- after the fix the maximum size is not less than the screen
>> https://bugs.openjdk.java.net/browse/JDK-8015100 - we use half of the GL_MAX_TEXTURE_SIZE if supported by the system, and usually it is larger than the screen
>> https://bugs.openjdk.java.net/browse/JDK-8010999 - the maximum possible size of the window is 8192
>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8027778/webrev.00
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Wed Dec 11 03:46:58 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 11 Dec 2013 15:46:58 +0400
Subject: <AWT Dev> [8] Review Request: 8027778 [macosx] Full screen not
	working properly on 7u45 with 10.7
In-Reply-To: <52A84330.6090904@oracle.com>
References: <52A7B5F0.5000208@oracle.com>
	<6052F96A-08C5-49FC-A7D2-60DA2CA42E3F@oracle.com>
	<52A84330.6090904@oracle.com>
Message-ID: <5486494E-87BA-4FD4-BA9C-D6AFD7E18F33@oracle.com>

Hello, Sergey.

>> I make the fix as simple as possible and use max(SCREEN_SIZE, GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native application on 10.9
>> This is not 100% true. If you create a big window on a big screen and then drag it to the smaller screen - you'll get a window which is bigger than the screen.
>> So with your fix in case the GL_MAX_TEXTURE_SIZE/2 < SCREEN_SIZE, wouldn't the frame automatically constrain itself to the bounds of the smaller screen
>> when dragged from the bigger screen?
> The question is about do we trust to the GL_MAX_TEXTURE_SIZE or not, if we assume that GL_MAX_TEXTURE_SIZE/2 is a maximum supported opengl texture size, and it less than a screen-> we could assume that the screen size is supported only or... what size?
I agree that the we should better trust the screen size than GL_MAX_TEXTURE_SIZE, as the latter have proved that it's unreliable.
In an offline discusion Sergey told me that the frame will not autoresize when it is moved to a different screen, so I'm OK with the fix now.

So, the fix look good to me.

With best regards. Petr.

On 11.12.2013, at 14:49, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> On 11.12.2013 11:23, Petr Pchelko wrote:
>> Hello, Sergey.
>> I make the fix as simple as possible and use max(SCREEN_SIZE, GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native application on 10.9
>> This is not 100% true. If you create a big window on a big screen and then drag it to the smaller screen - you'll get a window which is bigger than the screen.
>> So with your fix in case the GL_MAX_TEXTURE_SIZE/2 < SCREEN_SIZE, wouldn't the frame automatically constrain itself to the bounds of the smaller screen
>> when dragged from the bigger screen?
> The question is about do we trust to the GL_MAX_TEXTURE_SIZE or not, if we assume that GL_MAX_TEXTURE_SIZE/2 is a maximum supported opengl texture size, and it less than a screen-> we could assume that the screen size is supported only or... what size?
>> 
>> With best regards. Petr.
>> 
>> On 11.12.2013, at 4:46, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>> 
>>> Hello.
>>> Please review the fix for jdk 8.
>>> Some history of the bug:
>>> - Initially we did not constrain size of the window and got JDK-7160609
>>> - Then we try to use a union of the screens to constrain of the window and got JDK-8015100.
>>> - Then we start to use GL_MAX_TEXTURE_SIZE/2. But for some systems it was too big JDK-8023159 OR too small JDK-8027778.
>>> But on macosx 10.9 the windows are constrained automatically by the size of the screen(Petr please confirm).
>>> I make the fix as simple as possible and use max(SCREEN_SIZE, GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native application on 10.9
>>> nativeGetMaxTextureSize was moved under the render lock, where other related opengl data are initialized(see CGLGraphicsConfig.getCGLConfigInfo()). To me it seems safe because it works in similar way in jdk7 and CGLGraphicsConfig is recreated on the each event related to the screen(new resolution, new video card, etc).
>>> Also I adds updateMinimumSize to the displayChanged and notifyReshape, to reapply a new constrain to the window.
>>> Any suggestion are welcome.
>>> 
>>> 
>>> Bugs which are covered by this fix:
>>> https://bugs.openjdk.java.net/browse/JDK-8027778- after the fix the maximum size is not less than the screen
>>> https://bugs.openjdk.java.net/browse/JDK-8015100 - we use half of the GL_MAX_TEXTURE_SIZE if supported by the system, and usually it is larger than the screen
>>> https://bugs.openjdk.java.net/browse/JDK-8010999 - the maximum possible size of the window is 8192
>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8027778/webrev.00
>>> 
>>> -- 
>>> Best regards, Sergey.
>>> 
> 
> 
> -- 
> Best regards, Sergey.
> 


From Alan.Bateman at oracle.com  Wed Dec 11 04:01:56 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Dec 2013 12:01:56 +0000
Subject: <AWT Dev> 8029886: Change SecurityManager check{TopLevelWindow,
 SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A75F6F.7020800@oracle.com>
References: <52A71C7A.4050404@oracle.com> <52A75F6F.7020800@oracle.com>
Message-ID: <52A85434.1070704@oracle.com>

On 10/12/2013 18:37, Mandy Chung wrote:
> Alan,
>
> The change looks good.   A minor one - in the class description of 
> java.lang.SecurityManager,  I suggest to remove the references to 
> java.awt.AWTPermission line 143 and 214.
Thanks Mandy. I left in these links as it's just a sample list of 
permissions but I don't have a strong opinion and I'm happy to remove 
them too.

-Alan

From Sergey.Bylokhov at oracle.com  Wed Dec 11 04:35:29 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 11 Dec 2013 16:35:29 +0400
Subject: <AWT Dev> [8] Review Request: 8027778 [macosx] Full screen not
 working properly on 7u45 with 10.7
In-Reply-To: <5486494E-87BA-4FD4-BA9C-D6AFD7E18F33@oracle.com>
References: <52A7B5F0.5000208@oracle.com>
	<6052F96A-08C5-49FC-A7D2-60DA2CA42E3F@oracle.com>
	<52A84330.6090904@oracle.com>
	<5486494E-87BA-4FD4-BA9C-D6AFD7E18F33@oracle.com>
Message-ID: <52A85C11.4010902@oracle.com>

On 11.12.2013 15:46, Petr Pchelko wrote:
> Hello, Sergey.
>
>>> I make the fix as simple as possible and use max(SCREEN_SIZE, GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native application on 10.9
>>> This is not 100% true. If you create a big window on a big screen and then drag it to the smaller screen - you'll get a window which is bigger than the screen.
>>> So with your fix in case the GL_MAX_TEXTURE_SIZE/2 < SCREEN_SIZE, wouldn't the frame automatically constrain itself to the bounds of the smaller screen
>>> when dragged from the bigger screen?
>> The question is about do we trust to the GL_MAX_TEXTURE_SIZE or not, if we assume that GL_MAX_TEXTURE_SIZE/2 is a maximum supported opengl texture size, and it less than a screen-> we could assume that the screen size is supported only or... what size?
> I agree that the we should better trust the screen size than GL_MAX_TEXTURE_SIZE, as the latter have proved that it's unreliable.
> In an offline discusion Sergey told me that the frame will not autoresize when it is moved to a different screen, so I'm OK with the fix now.
I checked it on a native application and at least on my configuration 
osx changes the size of window, if it was moved from big screen to the 
small screen.
>
> So, the fix look good to me.
>
> With best regards. Petr.
>
> On 11.12.2013, at 14:49, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> On 11.12.2013 11:23, Petr Pchelko wrote:
>>> Hello, Sergey.
>>> I make the fix as simple as possible and use max(SCREEN_SIZE, GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native application on 10.9
>>> This is not 100% true. If you create a big window on a big screen and then drag it to the smaller screen - you'll get a window which is bigger than the screen.
>>> So with your fix in case the GL_MAX_TEXTURE_SIZE/2 < SCREEN_SIZE, wouldn't the frame automatically constrain itself to the bounds of the smaller screen
>>> when dragged from the bigger screen?
>> The question is about do we trust to the GL_MAX_TEXTURE_SIZE or not, if we assume that GL_MAX_TEXTURE_SIZE/2 is a maximum supported opengl texture size, and it less than a screen-> we could assume that the screen size is supported only or... what size?
>>> With best regards. Petr.
>>>
>>> On 11.12.2013, at 4:46, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>>
>>>> Hello.
>>>> Please review the fix for jdk 8.
>>>> Some history of the bug:
>>>> - Initially we did not constrain size of the window and got JDK-7160609
>>>> - Then we try to use a union of the screens to constrain of the window and got JDK-8015100.
>>>> - Then we start to use GL_MAX_TEXTURE_SIZE/2. But for some systems it was too big JDK-8023159 OR too small JDK-8027778.
>>>> But on macosx 10.9 the windows are constrained automatically by the size of the screen(Petr please confirm).
>>>> I make the fix as simple as possible and use max(SCREEN_SIZE, GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native application on 10.9
>>>> nativeGetMaxTextureSize was moved under the render lock, where other related opengl data are initialized(see CGLGraphicsConfig.getCGLConfigInfo()). To me it seems safe because it works in similar way in jdk7 and CGLGraphicsConfig is recreated on the each event related to the screen(new resolution, new video card, etc).
>>>> Also I adds updateMinimumSize to the displayChanged and notifyReshape, to reapply a new constrain to the window.
>>>> Any suggestion are welcome.
>>>>
>>>>
>>>> Bugs which are covered by this fix:
>>>> https://bugs.openjdk.java.net/browse/JDK-8027778- after the fix the maximum size is not less than the screen
>>>> https://bugs.openjdk.java.net/browse/JDK-8015100 - we use half of the GL_MAX_TEXTURE_SIZE if supported by the system, and usually it is larger than the screen
>>>> https://bugs.openjdk.java.net/browse/JDK-8010999 - the maximum possible size of the window is 8192
>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8027778/webrev.00
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>>
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From anton.tarasov at oracle.com  Wed Dec 11 05:13:44 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Wed, 11 Dec 2013 17:13:44 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A82CEB.3010203@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A82CEB.3010203@oracle.com>
Message-ID: <52A86508.3030803@oracle.com>

Hi Jim,

On 11.12.2013 13:14, Jim Graham wrote:
> The "inCreateCI" field is not MT-safe.  BufferedImage objects don't have any threading 
> restrictions so a solution that is MT-safe is required there in the BufferedImageGraphicsConfig 
> object.  I also think that any device-associated GraphicsConfig objects should be MT-safe in those 
> methods as well - I'm not sure if we've ever documented otherwise, but those methods have tended 
> to be harmless to call on any thread and fairly far removed from the more platform/screen 
> intensive parts of the AWT that might assume thread safety.

Right, I didn't take into account that a GraphicsConfig don't have threading restrictions. Will have 
to fix that.

>
>
> In BufferedImage, the private fields and methods will require an accessor method for the inner 
> class to access them.  Is there a reason they can't be left package-accessible?

Sorry, I don't clearly understand what you mean... The "scale" private field and the new methods are 
accessed from other packages, so I can't make them package-private. I've added the accessor which I 
put into OffscreenImage (an internal class).

>
>
> In JViewport, is there a reason why a map of various scaled backing stores are kept rather than 
> just validating the existing backing store against the new desired scale and replacing it when it 
> changes?  Does the scale on the backing store ping-pong back and forth between scales much?

This doesn't ping-pong much, indeed. So you want to say using a cache here is not justified? Ok, why 
I did that is probably to mimic the logic used by RepaintManager which does use a map b/w graphic 
configs and volatile images (the volatileMap field), whereas changes of the GraphicsConfig shouldn't 
occur often.

Anyway, this indeed doesn't increase performance but increases a footprint, so I'm ok not to use 
cache here.

>
>
> BufImgSurfaceData - you have to validate the transform as not flipping or rotating (even quadrant 
> rotation will violate your conditions.  I believe that testing the transform type with a mask 
> consisting of the TRANSLATE and SCALE_MASK flags should be fine. Also, do we wan to set a 
> precedent of allowing copyArea under an arbitrary scale, or should we test it to make sure it is 
> specifically the same scale as the device scale factor?

Ok, I'll check the transform for TRANSLATE/SCALE only. The same scale as the device works for me, so 
I'll limit it to that case.

>
> SG2D - I'm worried about the performance impliciations of adding a new method in that creates and 
> returns an array on every drawImage call. Did you do a performance test with J2DBench to verify 
> the impact of these operations?

Well, this was done just to make the code more clear. I can remove that method (and do the 
instanceof check in every place I called it), or as an alternative I can cache the array so that not 
to create it (out of the stack) every time. Does this make sense to you? (I didn't run J2DBench yet).

>
>
> With the new support for scaled BufferedImages we now have a situation where some images return 
> their logical dimensions from getWidth/Height(null) and some return physical dimensions.  That's a 
> little dicey as the method now has two meanings depending on how the images were created.  We're 
> sort of between a rock and a hard place in that BufferedImage objects have a historical context 
> for how their values relate to the pixels you can access, but we also have a relationship between 
> how the return values of getWidth/Height(observer) relate to the size the image is drawn on the 
> screen.  Is this only ever done for the backing store objects?  Do we ever expose them to developers?

Well, this is the question I was waiting for... The methods getWidth/Height will continue to return 
the physical size of an image, regardless of was it scaled or not. However, for a scaled image the 
physical size, and so the returned values will be auto-scaled. This is applicable to the following 
"factory" methods I've overriden:

1) BufferedImageGraphicsConfig.createCompatibleImage(...)
2) CGLGraphicsConfig.createCompatibleImage(...)
3) LWLightweightFramePeer.createImage(...)

The 1st depend on the scale factor of the GC instance the method is called on. The scale factor of 
BufferedImageGraphicsConfig is taken from the BI instance passed to its ctor. So, this won't affect 
any third party code, as the BI.scale field has a private access.

The 2nd depend on the scale factor of the device, which is set either by the platform or by me (in 
case when I set it to the default device in CPlatformLWView.java). So, theoretically it is possible 
for a user to call this method on a Retina display and get a scaled image.

The 3rd depend on the scale factor taken from the JLightweightFrame instance. This affects only the 
code run inside the JLF, however a user is able to call this method (on any of a component from the 
JLF's hierarchy) and get a scaled image.

So, we have situations when a user might create a BufferedImage with w*h size but get back an image 
with w*h*4 size (on a Retina display). And this might be unexpected. However, this image will 
produce a "context" with the same scale factor. A BufferedImageGraphicsConfig will be created with 
the same scale (see its ctor), a BufImgSurfaceData will be created with the same scale (see its 
getDefaultScale() method), and a SunGraphics2D will be created with the same scale ("devScale = 
sd.getDefaultScale();" in its ctor). In this case, all drawings into the image will take the scale 
into account, and should be correct. The only concern is the size of the image itself. At least, 
this is not documented...

 >   Could this be implemented by having the code that renders the backing store state its explicit 
on-screen size so that we don't need to add any computations to the use of getWidth/Height(null) to 
SG2D?

The computations we do in SG2D, namely the getLogicalSize(Image) method, is the way to get the 
"logical" size of a BufferedImage (the size it would have not being scaled) which returns its 
physical size via its getWidth/Height methods. So, the problem is that the image doesn't keep its 
logical size, but its physical (prescaled) width/height values and the scale factor.

Thanks for the review!

Anton.

>
> I'm going to take a break here and hit send to get these concepts out into the discussion before I 
> look too much further...
>
>             ...jim
>
> On 12/10/13 6:22 AM, Anton V. Tarasov wrote:
>> Hi Jim, Sergey and All,
>>
>> Please review the fix that adds support of Retina displays to
>> JLightweightFrame (which javafx SwingNode is based on).
>>
>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>
>> (After the fix goes into jdk9 it should be ported to 8u20 as well,
>> because the functionality is essential for SwingNode.)
>>
>> The general idea of the fix is as follows.
>>
>> A BufferedImage instance, being created in the context in which the
>> scale factor is determined and is different from one, is automatically
>> created with appropriately extended size. The image itself becomes a
>> scaled image (a "scale" private field is set on it). By the "context" I
>> mean the circumstances where the BufferedImage is related to a
>> JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a
>> GraphicsDevice which determine the scale factor.
>>
>> Here are the related changes:
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html 
>>
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html 
>>
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
>>
>> (the resizeBuffer method)
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html 
>>
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html 
>>
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html 
>>
>>
>>
>> The "scale" value of a BufferedImage is used when 1)
>> BufferedImageGraphicsConfig is created 2)
>> BufImgSurfaceData.getDefaultScale() is called:
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html 
>>
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html 
>>
>>
>>
>> The former is used in the GraphicsConfiguration.createCompatibleImage()
>> calls, and the latter is used in SurfaceManager.getImageScale(Image):
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html 
>>
>>
>>
>> A scaled BufferedImage is supported by the SunGraphics2D.drawImage()
>> primitives. Here's the pattern of how the image may be created and drawn:
>>
>> int scale = <get the scale factor from the context>;
>> BufferedImage img = new BufferedImage(width * scale, height * scale, ...);
>> img.setScale(scale); // an accessor is currently used instead
>> <...>
>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a
>> specified rect
>>
>> In the first case, if the BufferedImage is created with an extended
>> size, the "scale" value of the image matters, it should be drawn as a
>> HiDPI image.
>> In the second case, if the BufferedImage is created with an extended
>> size, the "scale" value of the image doesn't matter (it may not be
>> evidently set) as the image will anyway be scaled from its physical
>> bounds into provided logical bounds. This all should (as I suppose)
>> provide backward compatibility for buffered images that were created in
>> their logical bounds or without setting the "scale" field. For instance,
>> the AquaPainter.paintFromSingleCachedImage(...) method creates & draws
>> an image as follows:
>>
>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>> int imgW = bounds.width * scale;
>> int imgH = bounds.height * scale;
>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>> <paint into the img>
>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);
>>
>> Here, the img.scale value is not set (I didn't modify this code), and
>> SunGraphics2D doesn't treat the image as a HiDPI image, however it is
>> drawn as expected. An alternative way to draw the image would be:
>>
>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>> int imgW = bounds.width * scale;
>> int imgH = bounds.height * scale;
>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>> img.setScale(scale);
>> <paint into the img>
>> g.drawImage(img, bounds.x, bounds.y, ...);
>>
>> The result would be the same.
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html 
>>
>>
>>
>> The following changes:
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html 
>>
>>
>>
>> are defined by this logic. Running Swing via JLightweightFrame (JLF)
>> makes it "display agnostic". Swing is painted to an off-screen buffer
>> and it's the host (e.g. SwingNode) that renders the buffer on a
>> particular device. So, the host should detect the scale of the current
>> display and set it on JLF.
>>
>> However, AWT in order to paint to a volatile image requires
>> CGraphicsDevice and CGLSurfaceData to be created. By default AWT creates
>> CGraphicsDevice instances matching all the detected display devices
>> (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any
>> platform window behind it, AWT can't match JLF to the exact device it's
>> currently displayed on. So, on the one hand, AWT doesn't know which
>> device is current and what is the current scale (the host passes this
>> value), but from the other hand, AWT has a list of all the
>> CGraphicsDevice instances.
>>
>> I tried to leverage from that fact. The
>> CPlatformLWView.getGraphicsDevice() method takes the current scale from
>> the JLF instance, and then tries to match it to an existent device from
>> the list. In case it can't find a device with the specified scale (which
>> should not actually happen, unless the host passes an arbitrary scale
>> value, which is not the case for SwingNode) it takes a default device
>> and changes its scale forcedly. I'm not sure if I should create a new
>> dummy device instance instead. The scale factor of the device (which is
>> then propagated to CGLSurfaceData on its creation) is the only info that
>> JLF will take from the device to create a scaled volatile image.
>>
>> The following changes:
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html 
>>
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html 
>>
>>
>>
>> were made to map a backing store image to a scale factor.
>>
>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on
>> scrolling. The method was not implemented for a graphics with a scale
>> transform and a BufImgSurfaceData (it threw exceptions). I took that
>> code, copied it to the BufImgSurfaceData.copyArea(...) and added a
>> general translation for the coords:
>>
>> -
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html 
>>
>>
>>
>> It works, but I'm not sure the implementation is eligible (I don't know
>> the details of the Blit class, at least it warns not to use the same
>> source and dest).
>>
>> The rest of the changes (not covered here) should be clear.
>>
>> Testing:
>>
>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode &
>> embedded into SwingNode [1]).
>> - Testing both Nimbus and Aqua L&F.
>> - Setting swing.volatileImageBufferEnabled=false/true for all combinations.
>>
>> Currently, I see no regressions and no visual issues comparing a
>> standalone mode and a SwingSet mode.
>>
>> At the end, I suspect there may be some intersection b/w this fix and
>> the fix which introduced MultiResolutionToolkitImage. Unfortunately, I
>> didn't yet read that review saga... Please tell me if I should
>> incorporate anything from that fix.
>>
>> Thanks,
>> Anton.
>>
>> [1] There's a SwingSet part of the fix which I'm going to post to the
>> jfx alias separately.
>>


From artem.ananiev at oracle.com  Wed Dec 11 05:17:53 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Wed, 11 Dec 2013 17:17:53 +0400
Subject: <AWT Dev> 8029886: Change SecurityManager check{TopLevelWindow,
 SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A71C7A.4050404@oracle.com>
References: <52A71C7A.4050404@oracle.com>
Message-ID: <52A86601.2010308@oracle.com>

Hi, Alan,

the changes look fine to me.

A short quick question: what is the reason to introduce a new 
AWTPermissions class as a holder for various AWTPermission constants? We 
can have the same fields directly in AWTPermission. The only difference 
is that AWTPermission is in java.awt, while the new class is in sun.awt, 
but such a change seem to require a CCC request anyway...

Thanks,

Artem

On 12/10/2013 5:51 PM, Alan Bateman wrote:
>
> In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods
> checkTopLevelWindow, checkSystemClipboard and
> checkAccessAwtEventQueueAccess with a warning that they would be changed
> in a future release to check AllPermission. At the same time we changed
> the java.awt.Window and Toolkit methods to use checkPermission directly
> so that the legacy methods aren't used. The motive for all this is
> modules of course and the strong desire to remove the dependency on
> java.awt.AWTPermission.
>
> I'd like to get the second phase of this work into JDK 9 early to give
> every opportunity to find any potential issues. The second phase of this
> work changes the SecurityManager methods to check AllPermission and
> updates the implementation to remove the reflection hackery that was
> used to allow this code work without AWT being present (something that
> was needed for the profiles build).
>
> The webrev with the changes is here:
>    http://cr.openjdk.java.net/~alanb/8029886/webrev/
>
> The main thing that I'd like to get agreement on is the wording for the
> updated methods and also agreement from the AWT group to move the
> permission constants to a new class sun.awt.AWTPermissions.
>
> -Alan.

From anthony.petrov at oracle.com  Wed Dec 11 05:29:41 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 11 Dec 2013 17:29:41 +0400
Subject: <AWT Dev> [8] Review Request: 8027778 [macosx] Full screen not
 working properly on 7u45 with 10.7
In-Reply-To: <52A85C11.4010902@oracle.com>
References: <52A7B5F0.5000208@oracle.com>
	<6052F96A-08C5-49FC-A7D2-60DA2CA42E3F@oracle.com>
	<52A84330.6090904@oracle.com>
	<5486494E-87BA-4FD4-BA9C-D6AFD7E18F33@oracle.com>
	<52A85C11.4010902@oracle.com>
Message-ID: <52A868C5.3030704@oracle.com>

Hi Sergey,

The fix looks good to me.

--
best regards,
Anthony

On 12/11/2013 04:35 PM, Sergey Bylokhov wrote:
> On 11.12.2013 15:46, Petr Pchelko wrote:
>> Hello, Sergey.
>>
>>>> I make the fix as simple as possible and use max(SCREEN_SIZE,
>>>> GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native
>>>> application on 10.9
>>>> This is not 100% true. If you create a big window on a big screen
>>>> and then drag it to the smaller screen - you'll get a window which
>>>> is bigger than the screen.
>>>> So with your fix in case the GL_MAX_TEXTURE_SIZE/2 < SCREEN_SIZE,
>>>> wouldn't the frame automatically constrain itself to the bounds of
>>>> the smaller screen
>>>> when dragged from the bigger screen?
>>> The question is about do we trust to the GL_MAX_TEXTURE_SIZE or not,
>>> if we assume that GL_MAX_TEXTURE_SIZE/2 is a maximum supported opengl
>>> texture size, and it less than a screen-> we could assume that the
>>> screen size is supported only or... what size?
>> I agree that the we should better trust the screen size than
>> GL_MAX_TEXTURE_SIZE, as the latter have proved that it's unreliable.
>> In an offline discusion Sergey told me that the frame will not
>> autoresize when it is moved to a different screen, so I'm OK with the
>> fix now.
> I checked it on a native application and at least on my configuration
> osx changes the size of window, if it was moved from big screen to the
> small screen.
>>
>> So, the fix look good to me.
>>
>> With best regards. Petr.
>>
>> On 11.12.2013, at 14:49, Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
>> wrote:
>>
>>> On 11.12.2013 11:23, Petr Pchelko wrote:
>>>> Hello, Sergey.
>>>> I make the fix as simple as possible and use max(SCREEN_SIZE,
>>>> GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native
>>>> application on 10.9
>>>> This is not 100% true. If you create a big window on a big screen
>>>> and then drag it to the smaller screen - you'll get a window which
>>>> is bigger than the screen.
>>>> So with your fix in case the GL_MAX_TEXTURE_SIZE/2 < SCREEN_SIZE,
>>>> wouldn't the frame automatically constrain itself to the bounds of
>>>> the smaller screen
>>>> when dragged from the bigger screen?
>>> The question is about do we trust to the GL_MAX_TEXTURE_SIZE or not,
>>> if we assume that GL_MAX_TEXTURE_SIZE/2 is a maximum supported opengl
>>> texture size, and it less than a screen-> we could assume that the
>>> screen size is supported only or... what size?
>>>> With best regards. Petr.
>>>>
>>>> On 11.12.2013, at 4:46, Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
>>>> wrote:
>>>>
>>>>> Hello.
>>>>> Please review the fix for jdk 8.
>>>>> Some history of the bug:
>>>>> - Initially we did not constrain size of the window and got
>>>>> JDK-7160609
>>>>> - Then we try to use a union of the screens to constrain of the
>>>>> window and got JDK-8015100.
>>>>> - Then we start to use GL_MAX_TEXTURE_SIZE/2. But for some systems
>>>>> it was too big JDK-8023159 OR too small JDK-8027778.
>>>>> But on macosx 10.9 the windows are constrained automatically by the
>>>>> size of the screen(Petr please confirm).
>>>>> I make the fix as simple as possible and use max(SCREEN_SIZE,
>>>>> GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native
>>>>> application on 10.9
>>>>> nativeGetMaxTextureSize was moved under the render lock, where
>>>>> other related opengl data are initialized(see
>>>>> CGLGraphicsConfig.getCGLConfigInfo()). To me it seems safe because
>>>>> it works in similar way in jdk7 and CGLGraphicsConfig is recreated
>>>>> on the each event related to the screen(new resolution, new video
>>>>> card, etc).
>>>>> Also I adds updateMinimumSize to the displayChanged and
>>>>> notifyReshape, to reapply a new constrain to the window.
>>>>> Any suggestion are welcome.
>>>>>
>>>>>
>>>>> Bugs which are covered by this fix:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8027778- after the fix the
>>>>> maximum size is not less than the screen
>>>>> https://bugs.openjdk.java.net/browse/JDK-8015100 - we use half of
>>>>> the GL_MAX_TEXTURE_SIZE if supported by the system, and usually it
>>>>> is larger than the screen
>>>>> https://bugs.openjdk.java.net/browse/JDK-8010999 - the maximum
>>>>> possible size of the window is 8192
>>>>> Webrev can be found at:
>>>>> http://cr.openjdk.java.net/~serb/8027778/webrev.00
>>>>>
>>>>> --
>>>>> Best regards, Sergey.
>>>>>
>>>
>>> --
>>> Best regards, Sergey.
>>>
>
>

From Alan.Bateman at oracle.com  Wed Dec 11 05:53:27 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Dec 2013 13:53:27 +0000
Subject: <AWT Dev> 8029886: Change SecurityManager check{TopLevelWindow,
 SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A86601.2010308@oracle.com>
References: <52A71C7A.4050404@oracle.com> <52A86601.2010308@oracle.com>
Message-ID: <52A86E57.1090300@oracle.com>

On 11/12/2013 13:17, Artem Ananiev wrote:
> Hi, Alan,
>
> the changes look fine to me.
>
> A short quick question: what is the reason to introduce a new 
> AWTPermissions class as a holder for various AWTPermission constants? 
> We can have the same fields directly in AWTPermission. The only 
> difference is that AWTPermission is in java.awt, while the new class 
> is in sun.awt, but such a change seem to require a CCC request anyway...
>
Thanks Artem. Adding them to AWTPermission would bring them into Java SE 
/ public API and that doesn't seem to be worth it. The main thing is 
that we move them out of sun.security.util.SecurityConstants so that we 
can finally eliminate the execution-time dependency (what we have in the 
jdk8 forest is okay for profiles but we need to do better with modules).

-Alan.

From sean.mullan at oracle.com  Wed Dec 11 08:16:04 2013
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 11 Dec 2013 11:16:04 -0500
Subject: <AWT Dev> 8029886: Change SecurityManager check{TopLevelWindow,
 SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A71C7A.4050404@oracle.com>
References: <52A71C7A.4050404@oracle.com>
Message-ID: <52A88FC4.8030203@oracle.com>

On 12/10/2013 08:51 AM, Alan Bateman wrote:
>
> In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods
> checkTopLevelWindow, checkSystemClipboard and
> checkAccessAwtEventQueueAccess with a warning that they would be changed
> in a future release to check AllPermission. At the same time we changed
> the java.awt.Window and Toolkit methods to use checkPermission directly
> so that the legacy methods aren't used. The motive for all this is
> modules of course and the strong desire to remove the dependency on
> java.awt.AWTPermission.
>
> I'd like to get the second phase of this work into JDK 9 early to give
> every opportunity to find any potential issues. The second phase of this
> work changes the SecurityManager methods to check AllPermission and
> updates the implementation to remove the reflection hackery that was
> used to allow this code work without AWT being present (something that
> was needed for the profiles build).
>
> The webrev with the changes is here:
>    http://cr.openjdk.java.net/~alanb/8029886/webrev/
>
> The main thing that I'd like to get agreement on is the wording for the
> updated methods and also agreement from the AWT group to move the
> permission constants to a new class sun.awt.AWTPermissions.

The code changes and suggested wording for the updated methods look fine 
to me. Please add a release-note=yes label to the issue. The permissions 
security guide will also need to be updated with the new behavior of 
these methods: 
http://download.java.net/jdk8/docs/technotes/guides/security/permissions.html#PermsAndMethods 
-- I suggest adding a comment indicating that so we remember to update 
the docs as part of writing the release notes task.

--Sean



From anton.tarasov at oracle.com  Wed Dec 11 08:23:17 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Wed, 11 Dec 2013 20:23:17 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A840AE.2010000@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
Message-ID: <52A89175.5030704@oracle.com>

On 11.12.2013 14:38, Sergey Bylokhov wrote:
> On 11.12.2013 13:18, Anton V. Tarasov wrote:
>> Hi Sergey,
>>
>> On 11.12.2013 3:26, Sergey Bylokhov wrote:
>>> Hi, Anton.
>>> My expectation was that everything should work automatically, if you get correct CGraphicsDevice 
>>> for the embedded swing window + some tweaks in the code related to the peer and CGLSurfaceData/
>>>
>>> Why we need all this change in 
>>> CGraphicsDevice,CGLGraphicsConfig,OffScreenImage,CPlatformLWView,JViewport,RepaintManager.
>>
>> With Nimus, at some moment, when the nimbus.AbstractRegionPainter.paint(Graphics2D g, ...) method 
>> is called it is passed the graphics instance created by JLF.createGraphics() which derives it 
>> from the JLF's root buffered image. Then, somewhere up the stack the method calls for 
>> getImage(g.getDeviceConfiguration(),..),
> Yes, correct. But you can created double sized surface for you buffered image(in the same way as 
> it was done for volatile) and provide correct DeviceConfiguration for it.

Ok, I see what you're talking about, let me try it.

>> where the graphics conf is of BufferdeImageGraphicsConfig type. This flows into 
>> GraphicsConfiguration.createCompatibleVolatileImage(int w, int h, ...) and then into 
>> BufImgVolatileSurfaceManager which doesn't support acceleration, and eventually into 
>> BufferedImageGraphicsConfig.createCompatibleImage(int w, int h, ...). The [w, h] values passed 
>> here represent a logical size of a Nimbus ui element. Unless I scale the size of the requested 
>> image here, the ui element is shown stretched. That's why the changes in 
>> BufferedImageGraphicsConfig.
>>
>> With Aqua, I don't observe calls into BufImgVolatileSurfaceManager. I suppose the reason is that 
>> a GraphicsConfiguration instance is always taken from a component (from the JLF's hierarchy) 
>> which is tight to a CGraphicsDevice and has a CGLGraphicsConfig, not BufferdeImageGraphicsConfig. 
>> CGLVolatileSurfaceManager enables acceleration, and so the process of a volatile image creation 
>> never falls back to CLGGraphicsConfig.createCompatibleImage(...). By "never" I mean that I didn't 
>> catch it with the tests I ran. However, "find usages" shows that these methods are directly 
>> called from CTrayIcon, CDragSourceContextPeer, CCustomCursor, at least. I rather should cover 
>> those areas with some tests as well. Anyway, I've made these methods 
>> (CLGGraphicsConfig.createCompatibleImage(...)) consistent with the 
>> BufferedImageGraphicsConfig.createCompatibleImage(...) methods and with the general idea I've 
>> described before.
>>
>> Then, the other files you're referring to:
>>
>> - CPlatformLWView
>>
>> As I explained before, AWT in the lw embedding mode can't match a window to the display it is 
>> showing on, simply because it doesn't have a platform window underneath. 
>> CPlatformView.nativeGetNSViewDisplayID(getAWTView()) returns zero, and so 
>> CPlatformView.getGraphicsDevice() returns default device, not necessarily matching the scale 
>> factor of the current device.
> Why? You can try to check it youseft via CGLGraphicsConfig.getBounds()+Peer.getBounds(); You need 
> to override CPlatformWindow.getGraphicsDevice() and return correct device.  I see that the similar 
> bug exists in applets where CPlatformEmbeddedFrame.getGraphicsDevice always return  default device.

Probably, I could override CPlatformWindow.getGraphicsDevice() instead of 
CPlatformView.getGraphicsDevice() (the former calls the latter). But even then, how can I use the 
CGLGraphicsConfig.getBounds() which uses a display id which I don't have? And why it's better to 
pick the device via bounds than pick the device via a scale factor (the property I only need)?

>
> Same question about Component.getLocationOnScreen() is working in SwingNode?

SwingNode updates JLF location every time it changes on the fx side. So, the location as well as the 
scale is what the host (SwingNode) provides.

>>
>> - CGraphicsDevice
>>
>> This setter is only called from CPlatformLWView.getGraphicsDevice(). I've explained it in my 
>> previous message. It's needed to change the scale factor of the default device when no device in 
>> the list fits. The case is impossible with the current implementation of SwingNode (which only 
>> passes JLF a scale factor matching one of a real display), however, as JLF provides a generic lw 
>> embedding API, I should cover that case as well.
>>
>> - OffScreenImage
>>
>> I've put a BufferedImage accessor there, nothing else. I didn't find a better place... (I'd 
>> appreciate showing it).
>>
>> - JViewport, RepaintManager
>>
>> These classes create a double buffer. In case the buffer is backed by a BufferedImage, it will be 
>> created with the current scale factor set. The buffer won't be changed when a user moves the host 
>> window across multiple screens with different scales. I see two options. 1) Drop the double 
>> buffer reference every time the scale changes (in that case, the buffer will be recreated every 
>> time, I cross a screen) 2) Create a map which will cache the buffers (say, for 1 and 2 scale 
>> factors for double screen env). I think the second approach is better.
>>
>> > Probably it will be better to disable doublebuffering and SwingPaintEventDispatcher 
>> completely(see swing.showFromDoubleBuffer)?
>>
>> Why? If we can manage it for JLF/SwingNode, why should we downgrade performance?
> You have 1 buffere on fx side, buffer in SwingNode, buffer in jviewport, and swing itself use 
> double buffering.

Ok, this is a good point. But still I can't simply switch off double buffering w/o doing any 
benchmarking. SwingNode perf analisys & improvement is in plans...
So far, unless it requires lots of coding (but it doesn't) I'd prefer to keep that option working.

>>
>>> Actually I still do not understand why JViewport works in the standalone application.
>>
>> Could you please clarify, I don't understand this question...
> I see that JViewport use Offscreen image as a double buffer, is that true that it use it in the 
> standalone swing application? If yes why it works.

JViewport.paint() is not called with its default blit mode, and so it doesn't actually use an 
OffscreenBuffer. For JLF, the mode is set to backing store. If I set the backing store mode in 
standalone swing, JViewport stops scaling on Retina. So, it didn't work before.

>>
>>>
>>> One unrelated question. Did you try to use CALayer's embedding mechanics? Probably it is 
>>> possible to add CAlayer which is used by the swing and awt to the FX CAlayer? In this case all 
>>> problems related to the painting goes away and it will be much faster, only events should be 
>>> generated(The same way our plugin works see CPlatformEmbeddedFrame).
>>
>> This is in plans (interop "unified rendering" for d3d, ogl). At least, there are plans to 
>> investigate it....
> I guess it could be simpler than the current solution, because different layers will have 
> different context which will be used by the swing and fx independently.

I can't estimate the complexity without any investigations done... So I can't say if it may be 
simpler than it is now, I'd anticipate pitfalls.

Thanks,
Anton.

>
>>
>> Thanks for the review!
>>
>> Anton.
>>
>>>
>>> On 10.12.2013 18:22, Anton V. Tarasov wrote:
>>>> Hi Jim, Sergey and All,
>>>>
>>>> Please review the fix that adds support of Retina displays to JLightweightFrame (which javafx 
>>>> SwingNode is based on).
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>>>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>>>
>>>> (After the fix goes into jdk9 it should be ported to 8u20 as well, because the functionality is 
>>>> essential for SwingNode.)
>>>>
>>>> The general idea of the fix is as follows.
>>>>
>>>> A BufferedImage instance, being created in the context in which the scale factor is determined 
>>>> and is different from one, is automatically created with appropriately extended size. The image 
>>>> itself becomes a scaled image (a "scale" private field is set on it). By the "context" I mean 
>>>> the circumstances where the BufferedImage is related to a JLightweightFrame, a 
>>>> GraphicsConfiguration, a SurfaceData, or a GraphicsDevice which determine the scale factor.
>>>>
>>>> Here are the related changes:
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
>>>> (the resizeBuffer method)
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>>>>
>>>> The "scale" value of a BufferedImage is used when 1) BufferedImageGraphicsConfig is created 2) 
>>>> BufImgSurfaceData.getDefaultScale() is called:
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>
>>>> The former is used in the GraphicsConfiguration.createCompatibleImage() calls, and the latter 
>>>> is used in SurfaceManager.getImageScale(Image):
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>>>>
>>>> A scaled BufferedImage is supported by the SunGraphics2D.drawImage() primitives. Here's the 
>>>> pattern of how the image may be created and drawn:
>>>>
>>>> int scale = <get the scale factor from the context>;
>>>> BufferedImage img = new BufferedImage(width * scale, height * scale, ...);
>>>> img.setScale(scale); // an accessor is currently used instead
>>>> <...>
>>>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
>>>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a specified rect
>>>>
>>>> In the first case, if the BufferedImage is created with an extended size, the "scale" value of 
>>>> the image matters, it should be drawn as a HiDPI image.
>>>> In the second case, if the BufferedImage is created with an extended size, the "scale" value of 
>>>> the image doesn't matter (it may not be evidently set) as the image will anyway be scaled from 
>>>> its physical bounds into provided logical bounds. This all should (as I suppose) provide 
>>>> backward compatibility for buffered images that were created in their logical bounds or without 
>>>> setting the "scale" field. For instance, the AquaPainter.paintFromSingleCachedImage(...) method 
>>>> creates & draws an image as follows:
>>>>
>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>> int imgW = bounds.width * scale;
>>>> int imgH = bounds.height * scale;
>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>> <paint into the img>
>>>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);
>>>>
>>>> Here, the img.scale value is not set (I didn't modify this code), and SunGraphics2D doesn't 
>>>> treat the image as a HiDPI image, however it is drawn as expected. An alternative way to draw 
>>>> the image would be:
>>>>
>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>> int imgW = bounds.width * scale;
>>>> int imgH = bounds.height * scale;
>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>> img.setScale(scale);
>>>> <paint into the img>
>>>> g.drawImage(img, bounds.x, bounds.y, ...);
>>>>
>>>> The result would be the same.
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>>>>
>>>> The following changes:
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>>>>
>>>> are defined by this logic. Running Swing via JLightweightFrame (JLF) makes it "display 
>>>> agnostic". Swing is painted to an off-screen buffer and it's the host (e.g. SwingNode) that 
>>>> renders the buffer on a particular device. So, the host should detect the scale of the current 
>>>> display and set it on JLF.
>>> Does it mean that all methods related to the Component.getLocationOnScreen() does not work?
>>>>
>>>> However, AWT in order to paint to a volatile image requires CGraphicsDevice and CGLSurfaceData 
>>>> to be created. By default AWT creates CGraphicsDevice instances matching all the detected 
>>>> display devices (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any platform 
>>>> window behind it, AWT can't match JLF to the exact device it's currently displayed on.
>>> Why? You can try to check it youseft via CGLGraphicsConfig.getBounds()+Peer.getBounds();
>>>> So, on the one hand, AWT doesn't know which device is current and what is the current scale 
>>>> (the host passes this value), but from the other hand, AWT has a list of all the 
>>>> CGraphicsDevice instances.
>>>>
>>>> I tried to leverage from that fact. The CPlatformLWView.getGraphicsDevice() method takes the 
>>>> current scale from the JLF instance, and then tries to match it to an existent device from the 
>>>> list. In case it can't find a device with the specified scale (which should not actually 
>>>> happen, unless the host passes an arbitrary scale value, which is not the case for SwingNode) 
>>>> it takes a default device and changes its scale forcedly. I'm not sure if I should create a new 
>>>> dummy device instance instead. The scale factor of the device (which is then propagated to 
>>>> CGLSurfaceData on its creation) is the only info that JLF will take from the device to create a 
>>>> scaled volatile image.
>>>>
>>>> The following changes:
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>>>>
>>>> were made to map a backing store image to a scale factor.
>>>>
>>>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on scrolling. The method was 
>>>> not implemented for a graphics with a scale transform and a BufImgSurfaceData (it threw 
>>>> exceptions). I took that code, copied it to the BufImgSurfaceData.copyArea(...) and added a 
>>>> general translation for the coords:
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>
>>>> It works, but I'm not sure the implementation is eligible (I don't know the details of the Blit 
>>>> class, at least it warns not to use the same source and dest).
>>>>
>>>> The rest of the changes (not covered here) should be clear.
>>>>
>>>> Testing:
>>>>
>>>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & embedded into SwingNode [1]).
>>>> - Testing both Nimbus and Aqua L&F.
>>>> - Setting swing.volatileImageBufferEnabled=false/true for all combinations.
>>>>
>>>> Currently, I see no regressions and no visual issues comparing a standalone mode and a SwingSet 
>>>> mode.
>>>>
>>>> At the end, I suspect there may be some intersection b/w this fix and the fix which introduced 
>>>> MultiResolutionToolkitImage. Unfortunately, I didn't yet read that review saga... Please tell 
>>>> me if I should incorporate anything from that fix.
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>> [1] There's a SwingSet part of the fix which I'm going to post to the jfx alias separately.
>>>>
>>>
>>>
>>
>
>


From Alan.Bateman at oracle.com  Wed Dec 11 08:23:55 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Dec 2013 16:23:55 +0000
Subject: <AWT Dev> 8029886: Change SecurityManager check{TopLevelWindow,
 SystemClipboardAccessAwtEventQueueAccess} to check AllPermission
In-Reply-To: <52A88FC4.8030203@oracle.com>
References: <52A71C7A.4050404@oracle.com> <52A88FC4.8030203@oracle.com>
Message-ID: <52A8919B.8020407@oracle.com>

On 11/12/2013 16:16, Sean Mullan wrote:
>
> The code changes and suggested wording for the updated methods look 
> fine to me. Please add a release-note=yes label to the issue. The 
> permissions security guide will also need to be updated with the new 
> behavior of these methods: 
> http://download.java.net/jdk8/docs/technotes/guides/security/permissions.html#PermsAndMethods 
> -- I suggest adding a comment indicating that so we remember to update 
> the docs as part of writing the release notes task.
Thanks for the pointer to that guide, I wasn't aware for it (and now 
that I read it then I see that it is out of date, the changes that are 
you suggesting we need to remember are required now because those 
methods had their spec changes in 8 to use checkPermission directly).

-Alan

From alexander.zvegintsev at oracle.com  Wed Dec 11 08:31:22 2013
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 11 Dec 2013 20:31:22 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029923 Many Swing tests and
 SwingSet2 are failing under Solaris using GTK LaF - "Unable to load native
 GTK libraries"
Message-ID: <52A8935A.1030408@oracle.com>

Hello, AWT Team.

Please review the fix
http://cr.openjdk.java.net/~azvegint/jdk/8/8029923/webrev.00/
for the issue
https://bugs.openjdk.java.net/browse/JDK-8029923

Solaris 10 have glib 2.4.1 installed by default and glib_check_version() 
is available since 2.6 [1]. So the fix is to ignore "symbol not found" 
error.

[1] 
https://developer.gnome.org/glib/2.32/glib-Version-Information.html#glib-check-version



-- 
--
Thanks,
Alexander.


From Sergey.Bylokhov at oracle.com  Wed Dec 11 09:29:30 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 11 Dec 2013 21:29:30 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A89175.5030704@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A89175.5030704@oracle.com>
Message-ID: <52A8A0FA.30804@oracle.com>

On 11.12.2013 20:23, Anton V. Tarasov wrote:
>
>>> - CGraphicsDevice
>>>
>>> This setter is only called from CPlatformLWView.getGraphicsDevice(). 
>>> I've explained it in my previous message. It's needed to change the 
>>> scale factor of the default device when no device in the list fits. 
>>> The case is impossible with the current implementation of SwingNode 
>>> (which only passes JLF a scale factor matching one of a real 
>>> display), however, as JLF provides a generic lw embedding API, I 
>>> should cover that case as well.
Not sure that matching fx to awt devices via scale is not a good idea. 
Note that it is expected that fields in the CGraphicsDevice chenges only 
if the screen is changed/added/removed.
Probably Instead of notifyScaleFactorChanged you can notify about 
screens changes?
>>>
>>> - OffScreenImage
>>>
>>> I've put a BufferedImage accessor there, nothing else. I didn't find 
>>> a better place... (I'd appreciate showing it).
>>>
>>> - JViewport, RepaintManager
>>>
>>> These classes create a double buffer. In case the buffer is backed 
>>> by a BufferedImage, it will be created with the current scale factor 
>>> set. The buffer won't be changed when a user moves the host window 
>>> across multiple screens with different scales. I see two options. 1) 
>>> Drop the double buffer reference every time the scale changes (in 
>>> that case, the buffer will be recreated every time, I cross a 
>>> screen) 2) Create a map which will cache the buffers (say, for 1 and 
>>> 2 scale factors for double screen env). I think the second approach 
>>> is better.
>>>
>>> > Probably it will be better to disable doublebuffering and 
>>> SwingPaintEventDispatcher completely(see swing.showFromDoubleBuffer)?
>>>
>>> Why? If we can manage it for JLF/SwingNode, why should we downgrade 
>>> performance?
>> You have 1 buffere on fx side, buffer in SwingNode, buffer in 
>> jviewport, and swing itself use double buffering.
>
> Ok, this is a good point. But still I can't simply switch off double 
> buffering w/o doing any benchmarking. SwingNode perf analisys & 
> improvement is in plans...
It would be good to know results of the benchmarks.
> So far, unless it requires lots of coding (but it doesn't) I'd prefer 
> to keep that option working.
>
>>>
>>>> Actually I still do not understand why JViewport works in the 
>>>> standalone application.
>>>
>>> Could you please clarify, I don't understand this question...
>> I see that JViewport use Offscreen image as a double buffer, is that 
>> true that it use it in the standalone swing application? If yes why 
>> it works.
>
> JViewport.paint() is not called with its default blit mode, and so it 
> doesn't actually use an OffscreenBuffer. For JLF, the mode is set to 
> backing store. If I set the backing store mode in standalone swing, 
> JViewport stops scaling on Retina. So, it didn't work before.
Is this related to the JDK-8023966?
>
>
> Thanks,
> Anton.
>
>>
>>>
>>> Thanks for the review!
>>>
>>> Anton.
>>>
>>>>
>>>> On 10.12.2013 18:22, Anton V. Tarasov wrote:
>>>>> Hi Jim, Sergey and All,
>>>>>
>>>>> Please review the fix that adds support of Retina displays to 
>>>>> JLightweightFrame (which javafx SwingNode is based on).
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>>>>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>>>>
>>>>> (After the fix goes into jdk9 it should be ported to 8u20 as well, 
>>>>> because the functionality is essential for SwingNode.)
>>>>>
>>>>> The general idea of the fix is as follows.
>>>>>
>>>>> A BufferedImage instance, being created in the context in which 
>>>>> the scale factor is determined and is different from one, is 
>>>>> automatically created with appropriately extended size. The image 
>>>>> itself becomes a scaled image (a "scale" private field is set on 
>>>>> it). By the "context" I mean the circumstances where the 
>>>>> BufferedImage is related to a JLightweightFrame, a 
>>>>> GraphicsConfiguration, a SurfaceData, or a GraphicsDevice which 
>>>>> determine the scale factor.
>>>>>
>>>>> Here are the related changes:
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
>>>>> (the resizeBuffer method)
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>>>>>
>>>>> The "scale" value of a BufferedImage is used when 1) 
>>>>> BufferedImageGraphicsConfig is created 2) 
>>>>> BufImgSurfaceData.getDefaultScale() is called:
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>>
>>>>> The former is used in the 
>>>>> GraphicsConfiguration.createCompatibleImage() calls, and the 
>>>>> latter is used in SurfaceManager.getImageScale(Image):
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>>>>>
>>>>> A scaled BufferedImage is supported by the 
>>>>> SunGraphics2D.drawImage() primitives. Here's the pattern of how 
>>>>> the image may be created and drawn:
>>>>>
>>>>> int scale = <get the scale factor from the context>;
>>>>> BufferedImage img = new BufferedImage(width * scale, height * 
>>>>> scale, ...);
>>>>> img.setScale(scale); // an accessor is currently used instead
>>>>> <...>
>>>>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
>>>>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a 
>>>>> specified rect
>>>>>
>>>>> In the first case, if the BufferedImage is created with an 
>>>>> extended size, the "scale" value of the image matters, it should 
>>>>> be drawn as a HiDPI image.
>>>>> In the second case, if the BufferedImage is created with an 
>>>>> extended size, the "scale" value of the image doesn't matter (it 
>>>>> may not be evidently set) as the image will anyway be scaled from 
>>>>> its physical bounds into provided logical bounds. This all should 
>>>>> (as I suppose) provide backward compatibility for buffered images 
>>>>> that were created in their logical bounds or without setting the 
>>>>> "scale" field. For instance, the 
>>>>> AquaPainter.paintFromSingleCachedImage(...) method creates & draws 
>>>>> an image as follows:
>>>>>
>>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>>> int imgW = bounds.width * scale;
>>>>> int imgH = bounds.height * scale;
>>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>>> <paint into the img>
>>>>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, 
>>>>> null);
>>>>>
>>>>> Here, the img.scale value is not set (I didn't modify this code), 
>>>>> and SunGraphics2D doesn't treat the image as a HiDPI image, 
>>>>> however it is drawn as expected. An alternative way to draw the 
>>>>> image would be:
>>>>>
>>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>>> int imgW = bounds.width * scale;
>>>>> int imgH = bounds.height * scale;
>>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>>> img.setScale(scale);
>>>>> <paint into the img>
>>>>> g.drawImage(img, bounds.x, bounds.y, ...);
>>>>>
>>>>> The result would be the same.
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>>>>>
>>>>> The following changes:
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>>>>>
>>>>> are defined by this logic. Running Swing via JLightweightFrame 
>>>>> (JLF) makes it "display agnostic". Swing is painted to an 
>>>>> off-screen buffer and it's the host (e.g. SwingNode) that renders 
>>>>> the buffer on a particular device. So, the host should detect the 
>>>>> scale of the current display and set it on JLF.
>>>> Does it mean that all methods related to the 
>>>> Component.getLocationOnScreen() does not work?
>>>>>
>>>>> However, AWT in order to paint to a volatile image requires 
>>>>> CGraphicsDevice and CGLSurfaceData to be created. By default AWT 
>>>>> creates CGraphicsDevice instances matching all the detected 
>>>>> display devices (CGraphicsEnvironment.initDevices()). But, as JLF 
>>>>> doesn't have any platform window behind it, AWT can't match JLF to 
>>>>> the exact device it's currently displayed on.
>>>> Why? You can try to check it youseft via 
>>>> CGLGraphicsConfig.getBounds()+Peer.getBounds();
>>>>> So, on the one hand, AWT doesn't know which device is current and 
>>>>> what is the current scale (the host passes this value), but from 
>>>>> the other hand, AWT has a list of all the CGraphicsDevice instances.
>>>>>
>>>>> I tried to leverage from that fact. The 
>>>>> CPlatformLWView.getGraphicsDevice() method takes the current scale 
>>>>> from the JLF instance, and then tries to match it to an existent 
>>>>> device from the list. In case it can't find a device with the 
>>>>> specified scale (which should not actually happen, unless the host 
>>>>> passes an arbitrary scale value, which is not the case for 
>>>>> SwingNode) it takes a default device and changes its scale 
>>>>> forcedly. I'm not sure if I should create a new dummy device 
>>>>> instance instead. The scale factor of the device (which is then 
>>>>> propagated to CGLSurfaceData on its creation) is the only info 
>>>>> that JLF will take from the device to create a scaled volatile image.
>>>>>
>>>>> The following changes:
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>>>>>
>>>>> were made to map a backing store image to a scale factor.
>>>>>
>>>>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) 
>>>>> on scrolling. The method was not implemented for a graphics with a 
>>>>> scale transform and a BufImgSurfaceData (it threw exceptions). I 
>>>>> took that code, copied it to the BufImgSurfaceData.copyArea(...) 
>>>>> and added a general translation for the coords:
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>>
>>>>> It works, but I'm not sure the implementation is eligible (I don't 
>>>>> know the details of the Blit class, at least it warns not to use 
>>>>> the same source and dest).
>>>>>
>>>>> The rest of the changes (not covered here) should be clear.
>>>>>
>>>>> Testing:
>>>>>
>>>>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & 
>>>>> embedded into SwingNode [1]).
>>>>> - Testing both Nimbus and Aqua L&F.
>>>>> - Setting swing.volatileImageBufferEnabled=false/true for all 
>>>>> combinations.
>>>>>
>>>>> Currently, I see no regressions and no visual issues comparing a 
>>>>> standalone mode and a SwingSet mode.
>>>>>
>>>>> At the end, I suspect there may be some intersection b/w this fix 
>>>>> and the fix which introduced MultiResolutionToolkitImage. 
>>>>> Unfortunately, I didn't yet read that review saga... Please tell 
>>>>> me if I should incorporate anything from that fix.
>>>>>
>>>>> Thanks,
>>>>> Anton.
>>>>>
>>>>> [1] There's a SwingSet part of the fix which I'm going to post to 
>>>>> the jfx alias separately.
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Wed Dec 11 10:21:26 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 11 Dec 2013 22:21:26 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029923 Many Swing tests
 and SwingSet2 are failing under Solaris using GTK LaF - "Unable to load
 native GTK libraries"
In-Reply-To: <52A8935A.1030408@oracle.com>
References: <52A8935A.1030408@oracle.com>
Message-ID: <52A8AD26.8020908@oracle.com>

Hi Alexander,

It appears we have to use the same pattern for every call to the 
glib_check_version(), and you're repeating it twice already. I suggest 
to introduce a helper macro (or inline function) that would return the 
result of:

(fp_glib_check_version && fp_glib_check_version(X, Y, Z) == NULL)

It may be useful in the future, and even with your fix it would avoid 
code replication.

--
best regards,
Anthony

On 12/11/2013 08:31 PM, Alexander Zvegintsev wrote:
> Hello, AWT Team.
>
> Please review the fix
> http://cr.openjdk.java.net/~azvegint/jdk/8/8029923/webrev.00/
> for the issue
> https://bugs.openjdk.java.net/browse/JDK-8029923
>
> Solaris 10 have glib 2.4.1 installed by default and glib_check_version()
> is available since 2.6 [1]. So the fix is to ignore "symbol not found"
> error.
>
> [1]
> https://developer.gnome.org/glib/2.32/glib-Version-Information.html#glib-check-version
>
>
>
>

From sergey.bylokhov at oracle.com  Wed Dec 11 10:18:41 2013
From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com)
Date: Wed, 11 Dec 2013 18:18:41 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 8029045: Regression - Unsatisfied Link
	Error when	the Java Access Bridge is started
Message-ID: <20131211181908.0EE4C62BF9@hg.openjdk.java.net>

Changeset: 152cf399f16f
Author:    serb
Date:      2013-12-11 22:17 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/152cf399f16f

8029045: Regression - Unsatisfied Link Error when the Java Access Bridge is started
Summary: Rename native function name; fix make to rebuild jni header file
Reviewed-by: erikj, tbell
Contributed-by: peter.brunet at oracle.com

! make/CompileJavaClasses.gmk


From anthony.petrov at oracle.com  Wed Dec 11 11:14:01 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 11 Dec 2013 23:14:01 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A84104.9040400@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A77231.1030902@oracle.com>
	<52A84104.9040400@oracle.com>
Message-ID: <52A8B979.5040400@oracle.com>

Hi Anton,

On 12/11/2013 02:40 PM, Anton V. Tarasov wrote:
>> 2. I'm not sure if adding the scale field to the BI is a good idea. I
>> think that the image shouldn't be aware of any scale. After all, it's
>> just an image, a bitmap. It has its real dimensions corresponding to
>> the actual size of the image stored in RAM. Whether this image is
>> going to be represented as a scaled image is something that a code
>> that uses the image should be concerned with, not the image itself.
>
> There are two options. 1) Follow to your logic, that is to fix every
> place in AWT/Swing where BufferedImage is created. In which case in
> every such place we will have to get a current scale factor from the
> context. 2) Don't touch that code, but solve the task in some generic
> way, the way I tried to implement, when a buffered image is created with
> an extended size right in the factory methods.
>
> The logic of the first approach is simpler. However, it would require
> lots of modifications (in the L&F code, and not only there). And it
> would require to take into account the scale factor every time a new
> buffered image case is added to the code. Still, this is possible.
>
> With the scond approach I don't need to bother about that code, I just
> create scaled images "on the fly".
>
>  > I think that the image shouldn't be aware of any scale.
>
> The "scale" field put into the BufferedImage class means that an image
> instance should (or shouldn't) be treated as a HiDPI image by the
> Graphics.drawImage(). So, this is a kind of a special "scale" case,
> aimed at supporting Retina technology. Probably it deserves a better
> name, "hidpiScale" or something. So, it's not that the image has been
> scaled by the user to be drawn on a lager area, but that the image
> should (or shouldn't) be scaled just to "look smoothly" on a Retina
> display. That's what I was thinking about...

Thanks for the clarification. The idea sounds reasonable indeed.

I've also read your reply to Jim and I'm now concerned about the fact 
that scaled images can report larger dimensions than a Graphics created 
for them would allow one to draw to them. This may be a problem for some 
apps that perform rendering based on the dimensions of a BI object 
passed to them.

Shouldn't the BI.getWidth/Height() methods always report the logical 
size of the image, which is equal to the physical one for scale == 1?

--
best regards,
Anthony

>
>>
>>
>>
>> 3. src/share/classes/java/awt/peer/FramePeer.java
>>>  139     default void notifyScaleFactorChanged() {}
>>
>> I think this deserves to be declared in WindowPeer so that we could
>> use it w/o additional modifications in the future if we add support
>> for public notifications about the scale factor changes.
>
> Ok.
>
>>
>>
>> 4. I'm CC'ing swing-dev@ and Alexander Scherbatiy to review changes in
>> the JViewport class and other Swing classes.
>
> Thanks for the review!
>
> Anton.
>
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/10/2013 06:22 PM, Anton V. Tarasov wrote:
>>> Hi Jim, Sergey and All,
>>>
>>> Please review the fix that adds support of Retina displays to
>>> JLightweightFrame (which javafx SwingNode is based on).
>>>
>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>>
>>> (After the fix goes into jdk9 it should be ported to 8u20 as well,
>>> because the functionality is essential for SwingNode.)
>>>
>>> The general idea of the fix is as follows.
>>>
>>> A BufferedImage instance, being created in the context in which the
>>> scale factor is determined and is different from one, is automatically
>>> created with appropriately extended size. The image itself becomes a
>>> scaled image (a "scale" private field is set on it). By the "context" I
>>> mean the circumstances where the BufferedImage is related to a
>>> JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a
>>> GraphicsDevice which determine the scale factor.
>>>
>>> Here are the related changes:
>>>
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
>>>
>>>
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
>>>
>>>
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html
>>>
>>> (the resizeBuffer method)
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
>>>
>>>
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>
>>>
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>>>
>>>
>>>
>>> The "scale" value of a BufferedImage is used when 1)
>>> BufferedImageGraphicsConfig is created 2)
>>> BufImgSurfaceData.getDefaultScale() is called:
>>>
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>
>>>
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>
>>>
>>>
>>> The former is used in the GraphicsConfiguration.createCompatibleImage()
>>> calls, and the latter is used in SurfaceManager.getImageScale(Image):
>>>
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>>>
>>>
>>>
>>> A scaled BufferedImage is supported by the SunGraphics2D.drawImage()
>>> primitives. Here's the pattern of how the image may be created and
>>> drawn:
>>>
>>> int scale = <get the scale factor from the context>;
>>> BufferedImage img = new BufferedImage(width * scale, height * scale,
>>> ...);
>>> img.setScale(scale); // an accessor is currently used instead
>>> <...>
>>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
>>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a
>>> specified rect
>>>
>>> In the first case, if the BufferedImage is created with an extended
>>> size, the "scale" value of the image matters, it should be drawn as a
>>> HiDPI image.
>>> In the second case, if the BufferedImage is created with an extended
>>> size, the "scale" value of the image doesn't matter (it may not be
>>> evidently set) as the image will anyway be scaled from its physical
>>> bounds into provided logical bounds. This all should (as I suppose)
>>> provide backward compatibility for buffered images that were created in
>>> their logical bounds or without setting the "scale" field. For instance,
>>> the AquaPainter.paintFromSingleCachedImage(...) method creates & draws
>>> an image as follows:
>>>
>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>> int imgW = bounds.width * scale;
>>> int imgH = bounds.height * scale;
>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>> <paint into the img>
>>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);
>>>
>>> Here, the img.scale value is not set (I didn't modify this code), and
>>> SunGraphics2D doesn't treat the image as a HiDPI image, however it is
>>> drawn as expected. An alternative way to draw the image would be:
>>>
>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>> int imgW = bounds.width * scale;
>>> int imgH = bounds.height * scale;
>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>> img.setScale(scale);
>>> <paint into the img>
>>> g.drawImage(img, bounds.x, bounds.y, ...);
>>>
>>> The result would be the same.
>>>
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>>>
>>>
>>>
>>> The following changes:
>>>
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>>>
>>>
>>>
>>> are defined by this logic. Running Swing via JLightweightFrame (JLF)
>>> makes it "display agnostic". Swing is painted to an off-screen buffer
>>> and it's the host (e.g. SwingNode) that renders the buffer on a
>>> particular device. So, the host should detect the scale of the current
>>> display and set it on JLF.
>>>
>>> However, AWT in order to paint to a volatile image requires
>>> CGraphicsDevice and CGLSurfaceData to be created. By default AWT creates
>>> CGraphicsDevice instances matching all the detected display devices
>>> (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any
>>> platform window behind it, AWT can't match JLF to the exact device it's
>>> currently displayed on. So, on the one hand, AWT doesn't know which
>>> device is current and what is the current scale (the host passes this
>>> value), but from the other hand, AWT has a list of all the
>>> CGraphicsDevice instances.
>>>
>>> I tried to leverage from that fact. The
>>> CPlatformLWView.getGraphicsDevice() method takes the current scale from
>>> the JLF instance, and then tries to match it to an existent device from
>>> the list. In case it can't find a device with the specified scale (which
>>> should not actually happen, unless the host passes an arbitrary scale
>>> value, which is not the case for SwingNode) it takes a default device
>>> and changes its scale forcedly. I'm not sure if I should create a new
>>> dummy device instance instead. The scale factor of the device (which is
>>> then propagated to CGLSurfaceData on its creation) is the only info that
>>> JLF will take from the device to create a scaled volatile image.
>>>
>>> The following changes:
>>>
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
>>>
>>>
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>>>
>>>
>>>
>>> were made to map a backing store image to a scale factor.
>>>
>>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on
>>> scrolling. The method was not implemented for a graphics with a scale
>>> transform and a BufImgSurfaceData (it threw exceptions). I took that
>>> code, copied it to the BufImgSurfaceData.copyArea(...) and added a
>>> general translation for the coords:
>>>
>>> -
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>
>>>
>>>
>>> It works, but I'm not sure the implementation is eligible (I don't know
>>> the details of the Blit class, at least it warns not to use the same
>>> source and dest).
>>>
>>> The rest of the changes (not covered here) should be clear.
>>>
>>> Testing:
>>>
>>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode &
>>> embedded into SwingNode [1]).
>>> - Testing both Nimbus and Aqua L&F.
>>> - Setting swing.volatileImageBufferEnabled=false/true for all
>>> combinations.
>>>
>>> Currently, I see no regressions and no visual issues comparing a
>>> standalone mode and a SwingSet mode.
>>>
>>> At the end, I suspect there may be some intersection b/w this fix and
>>> the fix which introduced MultiResolutionToolkitImage. Unfortunately, I
>>> didn't yet read that review saga... Please tell me if I should
>>> incorporate anything from that fix.
>>>
>>> Thanks,
>>> Anton.
>>>
>>> [1] There's a SwingSet part of the fix which I'm going to post to the
>>> jfx alias separately.
>>>
>

From james.graham at oracle.com  Wed Dec 11 13:30:46 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 11 Dec 2013 13:30:46 -0800
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A84104.9040400@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A77231.1030902@oracle.com>
	<52A84104.9040400@oracle.com>
Message-ID: <52A8D986.20206@oracle.com>



On 12/11/13 2:40 AM, Anton V. Tarasov wrote:
> On 10.12.2013 23:57, Anthony Petrov wrote:
>> I think that the image shouldn't be aware of any scale.
>
> The "scale" field put into the BufferedImage class means that an image
> instance should (or shouldn't) be treated as a HiDPI image by the
> Graphics.drawImage(). So, this is a kind of a special "scale" case,
> aimed at supporting Retina technology. Probably it deserves a better
> name, "hidpiScale" or something. So, it's not that the image has been
> scaled by the user to be drawn on a lager area, but that the image
> should (or shouldn't) be scaled just to "look smoothly" on a Retina
> display. That's what I was thinking about...

The problem with this, to me, is that a developer may make the 
assumption in layout that the image will take "getWidth(null), 
getHeight(null)" size in the output when rendered with the default 
"drawImage(img, x, y, obs)" call.  You are going to violate that 
assumption here.

Another conflicting issue is that a developer would assume that if an 
image is "instanceof BufferedImage" then those same dimensions are going 
to define how much data they can read when they call getRGB(x, y) or get 
the raster.

Something is going to break when trying to use buffered images for 
auto-scaled output.

Perhaps we need a "hidden image type based on buffered image internally" 
image to use in these cases?  Or some sort of "render buffer object" 
which contains a reference to the image to render into and a concept of 
the scale it will be rendered to and from rather than baking those 
concepts directly into BufferedImage...?

(Note that we already have this problem in FX as well when we introduced 
reading from images and HiDPI in the same release, but we want the 
public object to return the layout sizes - for now we average 4 pixels 
in the readback to solve the problem, but we do not expose the pixels 
like BufferedImage and we are going to have to introduce API at some 
point to allow them to get a pixel readback from a particular scaled 
version of the image...)

If these images are not at all exposed to the developer in any way then 
I would encourage some solution/mechanism that did not insert itself 
into BufferedImage.  Perhaps we could have SwingBI class that extends 
BImg and introduces the scale factor at that level, only to be dealt 
with internally?  Or does Swing have a bunch of "new BufferedImage()" 
calls sprinkled throughout?

			...jim

From james.graham at oracle.com  Wed Dec 11 13:44:40 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 11 Dec 2013 13:44:40 -0800
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A86508.3030803@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A82CEB.3010203@oracle.com>
	<52A86508.3030803@oracle.com>
Message-ID: <52A8DCC8.1070405@oracle.com>

Hi Anton,

On 12/11/13 5:13 AM, Anton V. Tarasov wrote:
> Hi Jim,
>
> On 11.12.2013 13:14, Jim Graham wrote:
>>
>> In BufferedImage, the private fields and methods will require an
>> accessor method for the inner class to access them.  Is there a reason
>> they can't be left package-accessible?
>
> Sorry, I don't clearly understand what you mean... The "scale" private
> field and the new methods are accessed from other packages, so I can't
> make them package-private. I've added the accessor which I put into
> OffscreenImage (an internal class).

This is entirely an internal detail related to how inner classes are 
implemented (like the class that you use to allow OffscreenImage to 
access the BI methods).

The inner "accessor helper" class is technically outside the class scope 
of the BufferedImage class - it is a separate class and it is restricted 
in the byte code interpreter to the same access privileges as any other 
"separate class", but the methods it calls on BI are private.  The 
runtime does not allow this, but the compiler wants you to think this is 
possible for convenience of writing inner classes.  As a result, it 
injects fake accessor calls into the BI class that allow the inner 
classes to call private methods on BI.  Dump the byte codes of the 
relevant classes with javap and you will see the shadow calls that break 
the privacy of those methods.  Those methods are not allowed from java 
code, only the inner class magic can use them.  It is byte-code magic to 
enable the syntactic sugar of inner classes.

I believe if you just make the new methods on BI package-private instead 
of fully class-private, then those helper inner-class-only accessor 
methods aren't needed.

>> In JViewport, is there a reason why a map of various scaled backing
>> stores are kept rather than just validating the existing backing store
>> against the new desired scale and replacing it when it changes?  Does
>> the scale on the backing store ping-pong back and forth between scales
>> much?
>
> This doesn't ping-pong much, indeed. So you want to say using a cache
> here is not justified? Ok, why I did that is probably to mimic the logic
> used by RepaintManager which does use a map b/w graphic configs and
> volatile images (the volatileMap field), whereas changes of the
> GraphicsConfig shouldn't occur often.
>
> Anyway, this indeed doesn't increase performance but increases a
> footprint, so I'm ok not to use cache here.

I just wanted an analysis of whether the new complexity had any value. 
It sounds like it mirrors what was done in other places and that is 
fine, but perhaps this particular variant of that similar mechanism is 
premature?  In general, I'd wait to add complexity until a problem is 
demonstrated that makes it worthwhile.

>> BufImgSurfaceData - you have to validate the transform as not flipping
>> or rotating (even quadrant rotation will violate your conditions.  I
>> believe that testing the transform type with a mask consisting of the
>> TRANSLATE and SCALE_MASK flags should be fine. Also, do we wan to set
>> a precedent of allowing copyArea under an arbitrary scale, or should
>> we test it to make sure it is specifically the same scale as the
>> device scale factor?
>
> Ok, I'll check the transform for TRANSLATE/SCALE only. The same scale as
> the device works for me, so I'll limit it to that case.

Though, I do think we should eventually have copyarea work with scales.

BTW, this same code appears in SG2D, but it is rejected by a test on the 
transform type.  Have you thought about simply inserting your transform 
code into the test for the transform type in SG2D rather than shadowing 
the entire method?

>> SG2D - I'm worried about the performance impliciations of adding a new
>> method in that creates and returns an array on every drawImage call.
>> Did you do a performance test with J2DBench to verify the impact of
>> these operations?
>
> Well, this was done just to make the code more clear. I can remove that
> method (and do the instanceof check in every place I called it), or as
> an alternative I can cache the array so that not to create it (out of
> the stack) every time. Does this make sense to you? (I didn't run
> J2DBench yet).

A single SG2D should be single threaded (calling from multiple threads 
is not supported and results are not guaranteed) so caching the array in 
the instance would be fine.  Also, we are discussing the issue of 
getWidth(null) not matching the logical size of the image in another 
thread.  Depending on what we decide there, it may make sense to move 
the scaling logic inside the getWidth() methods of the scaled buffered 
images and then we need far fewer mods to SG2D.  But, I think that would 
only work reasonably if such "scaled buffered images" are never leaked 
to the developer until we come up with a reasonable external API that 
makes sense for them.

I'm going to save the rest of the reply for another message since it 
gets involved...

			...jim

From james.graham at oracle.com  Wed Dec 11 13:48:03 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 11 Dec 2013 13:48:03 -0800
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A86508.3030803@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A82CEB.3010203@oracle.com>
	<52A86508.3030803@oracle.com>
Message-ID: <52A8DD93.3000703@oracle.com>



On 12/11/13 5:13 AM, Anton V. Tarasov wrote:
> On 11.12.2013 13:14, Jim Graham wrote:
>>   Could this be implemented by having the code that renders the backing store state its expliciton-screen size so that we don't need to add any computations to the use
> of getWidth/Height(null) to SG2D?
>
> The computations we do in SG2D, namely the getLogicalSize(Image) method,
> is the way to get the "logical" size of a BufferedImage (the size it
> would have not being scaled) which returns its physical size via its
> getWidth/Height methods. So, the problem is that the image doesn't keep
> its logical size, but its physical (prescaled) width/height values and
> the scale factor.
>
> Thanks for the review!

The point I was trying to make is that if the code that renders a Swing 
back buffer only ever calls "drawImage(img, x, y, w, h, obs)" then the 
"logical size" of the image is irrelevant and we don't really need to 
sprinkle that code throughout SG2D (yet? or ever?).  We also don't need 
to teach BI's about their scale/scaled size...

			...jim

From james.graham at oracle.com  Wed Dec 11 13:54:54 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 11 Dec 2013 13:54:54 -0800
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A86508.3030803@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A82CEB.3010203@oracle.com>
	<52A86508.3030803@oracle.com>
Message-ID: <52A8DF2E.2030207@oracle.com>



On 12/11/13 5:13 AM, Anton V. Tarasov wrote:
> On 11.12.2013 13:14, Jim Graham wrote:
>> With the new support for scaled BufferedImages we now have a situation
>> where some images return their logical dimensions from
>> getWidth/Height(null) and some return physical dimensions.  That's a
>> little dicey as the method now has two meanings depending on how the
>> images were created.  We're sort of between a rock and a hard place in
>> that BufferedImage objects have a historical context for how their
>> values relate to the pixels you can access, but we also have a
>> relationship between how the return values of
>> getWidth/Height(observer) relate to the size the image is drawn on the
>> screen.  Is this only ever done for the backing store objects?  Do we
>> ever expose them to developers?
>
> Well, this is the question I was waiting for... The methods
> getWidth/Height will continue to return the physical size of an image,
> regardless of was it scaled or not. However, for a scaled image the
> physical size, and so the returned values will be auto-scaled. This is
> applicable to the following "factory" methods I've overriden:
>
> 1) BufferedImageGraphicsConfig.createCompatibleImage(...)
> 2) CGLGraphicsConfig.createCompatibleImage(...)
> 3) LWLightweightFramePeer.createImage(...)
>
> The 1st depend on the scale factor of the GC instance the method is
> called on. The scale factor of BufferedImageGraphicsConfig is taken from
> the BI instance passed to its ctor. So, this won't affect any third
> party code, as the BI.scale field has a private access.
>
> The 2nd depend on the scale factor of the device, which is set either by
> the platform or by me (in case when I set it to the default device in
> CPlatformLWView.java). So, theoretically it is possible for a user to
> call this method on a Retina display and get a scaled image.

We are subtly changing the meaning of createCompatibleImage() in both of 
those circumstances.  It's hard to understand the impact of that subtle 
change.  It looks like this fix is targeted at JDK9 so we have time to 
vet it, but my initial gut feel on this is that we are going to confuse 
some developers here unless we create a special 
"createCompatibleImage()" method variant (with perhaps a different name) 
that specifically requests an image with an appropriate scale.  If we 
are then going to service those requests with BufferedImage return 
values then we add an additional issue in that we have conflicting needs 
for the various methods on BI in that case.

> The 3rd depend on the scale factor taken from the JLightweightFrame
> instance. This affects only the code run inside the JLF, however a user
> is able to call this method (on any of a component from the JLF's
> hierarchy) and get a scaled image.
>
> So, we have situations when a user might create a BufferedImage with w*h

Are they specifically creating a BufferedImage, or an Image that happens 
to be an instance of BI in most current cases?

> size but get back an image with w*h*4 size (on a Retina display). And
> this might be unexpected. However, this image will produce a "context"
> with the same scale factor. A BufferedImageGraphicsConfig will be
> created with the same scale (see its ctor), a BufImgSurfaceData will be
> created with the same scale (see its getDefaultScale() method), and a
> SunGraphics2D will be created with the same scale ("devScale =
> sd.getDefaultScale();" in its ctor). In this case, all drawings into the
> image will take the scale into account, and should be correct. The only
> concern is the size of the image itself. At least, this is not
> documented...

My big worry here is that we currently have 2 consumers of 
BI.getWidth(null) - one group that expects the answer to relate to 
layout, and another that expects the answer to relate to pixel access.

Here is where someone dons their "genius hat" and comes up with a 
creative solution that works for both groups.  Mine is unfortunately at 
the cleaners right now and they don't know when they'll have it done... :(

But, I feel there is a good common ground to be found there once we wrap 
our heads around the problem the right way (and with the right "genius 
hat").  Also, perhaps we need to engage the 2d-dev list as well here, 
since the results will affect them as well?

			...jim

From alexander.zvegintsev at oracle.com  Thu Dec 12 02:35:05 2013
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 12 Dec 2013 14:35:05 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029923 Many Swing tests
 and SwingSet2 are failing under Solaris using GTK LaF - "Unable to load
 native GTK libraries"
In-Reply-To: <52A8AD26.8020908@oracle.com>
References: <52A8935A.1030408@oracle.com> <52A8AD26.8020908@oracle.com>
Message-ID: <52A99159.4080409@oracle.com>

Hi Anthony,

Sure, here is the updated webrev:
http://cr.openjdk.java.net/~azvegint/jdk/8/8029923/webrev.01/

Thanks,

Alexander.

On 12/11/2013 10:21 PM, Anthony Petrov wrote:
> Hi Alexander,
>
> It appears we have to use the same pattern for every call to the 
> glib_check_version(), and you're repeating it twice already. I suggest 
> to introduce a helper macro (or inline function) that would return the 
> result of:
>
> (fp_glib_check_version && fp_glib_check_version(X, Y, Z) == NULL)
>
> It may be useful in the future, and even with your fix it would avoid 
> code replication.
>
> -- 
> best regards,
> Anthony
>
> On 12/11/2013 08:31 PM, Alexander Zvegintsev wrote:
>> Hello, AWT Team.
>>
>> Please review the fix
>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029923/webrev.00/
>> for the issue
>> https://bugs.openjdk.java.net/browse/JDK-8029923
>>
>> Solaris 10 have glib 2.4.1 installed by default and glib_check_version()
>> is available since 2.6 [1]. So the fix is to ignore "symbol not found"
>> error.
>>
>> [1]
>> https://developer.gnome.org/glib/2.32/glib-Version-Information.html#glib-check-version 
>>
>>
>>
>>
>>


From anthony.petrov at oracle.com  Thu Dec 12 02:40:57 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 12 Dec 2013 14:40:57 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029923 Many Swing tests
 and SwingSet2 are failing under Solaris using GTK LaF - "Unable to load
 native GTK libraries"
In-Reply-To: <52A99159.4080409@oracle.com>
References: <52A8935A.1030408@oracle.com> <52A8AD26.8020908@oracle.com>
	<52A99159.4080409@oracle.com>
Message-ID: <52A992B9.7060005@oracle.com>

The fix looks fine to me. Thanks.

--
best regards,
Anthony

On 12/12/2013 02:35 PM, Alexander Zvegintsev wrote:
> Hi Anthony,
>
> Sure, here is the updated webrev:
> http://cr.openjdk.java.net/~azvegint/jdk/8/8029923/webrev.01/
>
> Thanks,
>
> Alexander.
>
> On 12/11/2013 10:21 PM, Anthony Petrov wrote:
>> Hi Alexander,
>>
>> It appears we have to use the same pattern for every call to the
>> glib_check_version(), and you're repeating it twice already. I suggest
>> to introduce a helper macro (or inline function) that would return the
>> result of:
>>
>> (fp_glib_check_version && fp_glib_check_version(X, Y, Z) == NULL)
>>
>> It may be useful in the future, and even with your fix it would avoid
>> code replication.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/11/2013 08:31 PM, Alexander Zvegintsev wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix
>>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029923/webrev.00/
>>> for the issue
>>> https://bugs.openjdk.java.net/browse/JDK-8029923
>>>
>>> Solaris 10 have glib 2.4.1 installed by default and glib_check_version()
>>> is available since 2.6 [1]. So the fix is to ignore "symbol not found"
>>> error.
>>>
>>> [1]
>>> https://developer.gnome.org/glib/2.32/glib-Version-Information.html#glib-check-version
>>>
>>>
>>>
>>>
>>>
>

From sergey.bylokhov at oracle.com  Thu Dec 12 04:32:41 2013
From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com)
Date: Thu, 12 Dec 2013 12:32:41 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 8001472: api/java_awt/Window/indexTGF_*
	tests fail	because expected colors aren't equal
Message-ID: <20131212123344.4BCA162C24@hg.openjdk.java.net>

Changeset: 06c655658b89
Author:    serb
Date:      2013-12-12 16:30 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/06c655658b89

8001472: api/java_awt/Window/indexTGF_* tests fail because expected colors aren't equal
Reviewed-by: anthony, azvegint

! src/solaris/classes/sun/awt/X11/XWindow.java
+ test/java/awt/Window/BackgroundIsNotUpdated/BackgroundIsNotUpdated.java


From Sergey.Bylokhov at oracle.com  Thu Dec 12 05:22:36 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 12 Dec 2013 17:22:36 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029923 Many Swing tests
 and SwingSet2 are failing under Solaris using GTK LaF - "Unable to load
 native GTK libraries"
In-Reply-To: <52A992B9.7060005@oracle.com>
References: <52A8935A.1030408@oracle.com>
	<52A8AD26.8020908@oracle.com>	<52A99159.4080409@oracle.com>
	<52A992B9.7060005@oracle.com>
Message-ID: <52A9B89C.5060104@oracle.com>

Hi, Alexander.
The fix looks good to me too.

On 12.12.2013 14:40, Anthony Petrov wrote:
> The fix looks fine to me. Thanks.
>
> -- 
> best regards,
> Anthony
>
> On 12/12/2013 02:35 PM, Alexander Zvegintsev wrote:
>> Hi Anthony,
>>
>> Sure, here is the updated webrev:
>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029923/webrev.01/
>>
>> Thanks,
>>
>> Alexander.
>>
>> On 12/11/2013 10:21 PM, Anthony Petrov wrote:
>>> Hi Alexander,
>>>
>>> It appears we have to use the same pattern for every call to the
>>> glib_check_version(), and you're repeating it twice already. I suggest
>>> to introduce a helper macro (or inline function) that would return the
>>> result of:
>>>
>>> (fp_glib_check_version && fp_glib_check_version(X, Y, Z) == NULL)
>>>
>>> It may be useful in the future, and even with your fix it would avoid
>>> code replication.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 12/11/2013 08:31 PM, Alexander Zvegintsev wrote:
>>>> Hello, AWT Team.
>>>>
>>>> Please review the fix
>>>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029923/webrev.00/
>>>> for the issue
>>>> https://bugs.openjdk.java.net/browse/JDK-8029923
>>>>
>>>> Solaris 10 have glib 2.4.1 installed by default and 
>>>> glib_check_version()
>>>> is available since 2.6 [1]. So the fix is to ignore "symbol not found"
>>>> error.
>>>>
>>>> [1]
>>>> https://developer.gnome.org/glib/2.32/glib-Version-Information.html#glib-check-version 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>


-- 
Best regards, Sergey.


From anton.tarasov at oracle.com  Thu Dec 12 07:16:17 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 12 Dec 2013 19:16:17 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A840AE.2010000@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
Message-ID: <52A9D341.2070008@oracle.com>

[cc'ing to j2d]

On 11.12.2013 14:38, Sergey Bylokhov wrote:
> On 11.12.2013 13:18, Anton V. Tarasov wrote:
>> Hi Sergey,
>>
>> On 11.12.2013 3:26, Sergey Bylokhov wrote:
>>> Hi, Anton.
>>> My expectation was that everything should work automatically, if you get correct CGraphicsDevice 
>>> for the embedded swing window + some tweaks in the code related to the peer and CGLSurfaceData/
>>>
>>> Why we need all this change in 
>>> CGraphicsDevice,CGLGraphicsConfig,OffScreenImage,CPlatformLWView,JViewport,RepaintManager.
>>
>> With Nimus, at some moment, when the nimbus.AbstractRegionPainter.paint(Graphics2D g, ...) method 
>> is called it is passed the graphics instance created by JLF.createGraphics() which derives it 
>> from the JLF's root buffered image. Then, somewhere up the stack the method calls for 
>> getImage(g.getDeviceConfiguration(),..),
> Yes, correct. But you can created double sized surface for you buffered image(in the same way as 
> it was done for volatile) and provide correct DeviceConfiguration for it.

Sergey,

It seems I didn't yet understand you. Could you please clarify? What "double sized" surface do you 
mean for a BufferedImage, and what do you mean by the "correct" DeviceConfiguration for it? (I can't 
put a CGLSurfaceData into a BufferedImage).

Thanks,
Anton.

>> where the graphics conf is of BufferdeImageGraphicsConfig type. This flows into 
>> GraphicsConfiguration.createCompatibleVolatileImage(int w, int h, ...) and then into 
>> BufImgVolatileSurfaceManager which doesn't support acceleration, and eventually into 
>> BufferedImageGraphicsConfig.createCompatibleImage(int w, int h, ...). The [w, h] values passed 
>> here represent a logical size of a Nimbus ui element. Unless I scale the size of the requested 
>> image here, the ui element is shown stretched. That's why the changes in 
>> BufferedImageGraphicsConfig.
>>
>> With Aqua, I don't observe calls into BufImgVolatileSurfaceManager. I suppose the reason is that 
>> a GraphicsConfiguration instance is always taken from a component (from the JLF's hierarchy) 
>> which is tight to a CGraphicsDevice and has a CGLGraphicsConfig, not BufferdeImageGraphicsConfig. 
>> CGLVolatileSurfaceManager enables acceleration, and so the process of a volatile image creation 
>> never falls back to CLGGraphicsConfig.createCompatibleImage(...). By "never" I mean that I didn't 
>> catch it with the tests I ran. However, "find usages" shows that these methods are directly 
>> called from CTrayIcon, CDragSourceContextPeer, CCustomCursor, at least. I rather should cover 
>> those areas with some tests as well. Anyway, I've made these methods 
>> (CLGGraphicsConfig.createCompatibleImage(...)) consistent with the 
>> BufferedImageGraphicsConfig.createCompatibleImage(...) methods and with the general idea I've 
>> described before.
>>
>> Then, the other files you're referring to:
>>
>> - CPlatformLWView
>>
>> As I explained before, AWT in the lw embedding mode can't match a window to the display it is 
>> showing on, simply because it doesn't have a platform window underneath. 
>> CPlatformView.nativeGetNSViewDisplayID(getAWTView()) returns zero, and so 
>> CPlatformView.getGraphicsDevice() returns default device, not necessarily matching the scale 
>> factor of the current device.
> Why? You can try to check it youseft via CGLGraphicsConfig.getBounds()+Peer.getBounds(); You need 
> to override CPlatformWindow.getGraphicsDevice() and return correct device.  I see that the similar 
> bug exists in applets where CPlatformEmbeddedFrame.getGraphicsDevice always return  default device.
> Same question about Component.getLocationOnScreen() is working in SwingNode?
>>
>> - CGraphicsDevice
>>
>> This setter is only called from CPlatformLWView.getGraphicsDevice(). I've explained it in my 
>> previous message. It's needed to change the scale factor of the default device when no device in 
>> the list fits. The case is impossible with the current implementation of SwingNode (which only 
>> passes JLF a scale factor matching one of a real display), however, as JLF provides a generic lw 
>> embedding API, I should cover that case as well.
>>
>> - OffScreenImage
>>
>> I've put a BufferedImage accessor there, nothing else. I didn't find a better place... (I'd 
>> appreciate showing it).
>>
>> - JViewport, RepaintManager
>>
>> These classes create a double buffer. In case the buffer is backed by a BufferedImage, it will be 
>> created with the current scale factor set. The buffer won't be changed when a user moves the host 
>> window across multiple screens with different scales. I see two options. 1) Drop the double 
>> buffer reference every time the scale changes (in that case, the buffer will be recreated every 
>> time, I cross a screen) 2) Create a map which will cache the buffers (say, for 1 and 2 scale 
>> factors for double screen env). I think the second approach is better.
>>
>> > Probably it will be better to disable doublebuffering and SwingPaintEventDispatcher 
>> completely(see swing.showFromDoubleBuffer)?
>>
>> Why? If we can manage it for JLF/SwingNode, why should we downgrade performance?
> You have 1 buffere on fx side, buffer in SwingNode, buffer in jviewport, and swing itself use 
> double buffering.
>>
>>> Actually I still do not understand why JViewport works in the standalone application.
>>
>> Could you please clarify, I don't understand this question...
> I see that JViewport use Offscreen image as a double buffer, is that true that it use it in the 
> standalone swing application? If yes why it works.
>>
>>>
>>> One unrelated question. Did you try to use CALayer's embedding mechanics? Probably it is 
>>> possible to add CAlayer which is used by the swing and awt to the FX CAlayer? In this case all 
>>> problems related to the painting goes away and it will be much faster, only events should be 
>>> generated(The same way our plugin works see CPlatformEmbeddedFrame).
>>
>> This is in plans (interop "unified rendering" for d3d, ogl). At least, there are plans to 
>> investigate it....
> I guess it could be simpler than the current solution, because different layers will have 
> different context which will be used by the swing and fx independently.
>>
>> Thanks for the review!
>>
>> Anton.
>>
>>>
>>> On 10.12.2013 18:22, Anton V. Tarasov wrote:
>>>> Hi Jim, Sergey and All,
>>>>
>>>> Please review the fix that adds support of Retina displays to JLightweightFrame (which javafx 
>>>> SwingNode is based on).
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>>>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>>>
>>>> (After the fix goes into jdk9 it should be ported to 8u20 as well, because the functionality is 
>>>> essential for SwingNode.)
>>>>
>>>> The general idea of the fix is as follows.
>>>>
>>>> A BufferedImage instance, being created in the context in which the scale factor is determined 
>>>> and is different from one, is automatically created with appropriately extended size. The image 
>>>> itself becomes a scaled image (a "scale" private field is set on it). By the "context" I mean 
>>>> the circumstances where the BufferedImage is related to a JLightweightFrame, a 
>>>> GraphicsConfiguration, a SurfaceData, or a GraphicsDevice which determine the scale factor.
>>>>
>>>> Here are the related changes:
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
>>>> (the resizeBuffer method)
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>>>>
>>>> The "scale" value of a BufferedImage is used when 1) BufferedImageGraphicsConfig is created 2) 
>>>> BufImgSurfaceData.getDefaultScale() is called:
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>
>>>> The former is used in the GraphicsConfiguration.createCompatibleImage() calls, and the latter 
>>>> is used in SurfaceManager.getImageScale(Image):
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>>>>
>>>> A scaled BufferedImage is supported by the SunGraphics2D.drawImage() primitives. Here's the 
>>>> pattern of how the image may be created and drawn:
>>>>
>>>> int scale = <get the scale factor from the context>;
>>>> BufferedImage img = new BufferedImage(width * scale, height * scale, ...);
>>>> img.setScale(scale); // an accessor is currently used instead
>>>> <...>
>>>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
>>>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a specified rect
>>>>
>>>> In the first case, if the BufferedImage is created with an extended size, the "scale" value of 
>>>> the image matters, it should be drawn as a HiDPI image.
>>>> In the second case, if the BufferedImage is created with an extended size, the "scale" value of 
>>>> the image doesn't matter (it may not be evidently set) as the image will anyway be scaled from 
>>>> its physical bounds into provided logical bounds. This all should (as I suppose) provide 
>>>> backward compatibility for buffered images that were created in their logical bounds or without 
>>>> setting the "scale" field. For instance, the AquaPainter.paintFromSingleCachedImage(...) method 
>>>> creates & draws an image as follows:
>>>>
>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>> int imgW = bounds.width * scale;
>>>> int imgH = bounds.height * scale;
>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>> <paint into the img>
>>>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);
>>>>
>>>> Here, the img.scale value is not set (I didn't modify this code), and SunGraphics2D doesn't 
>>>> treat the image as a HiDPI image, however it is drawn as expected. An alternative way to draw 
>>>> the image would be:
>>>>
>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>> int imgW = bounds.width * scale;
>>>> int imgH = bounds.height * scale;
>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>> img.setScale(scale);
>>>> <paint into the img>
>>>> g.drawImage(img, bounds.x, bounds.y, ...);
>>>>
>>>> The result would be the same.
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>>>>
>>>> The following changes:
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>>>>
>>>> are defined by this logic. Running Swing via JLightweightFrame (JLF) makes it "display 
>>>> agnostic". Swing is painted to an off-screen buffer and it's the host (e.g. SwingNode) that 
>>>> renders the buffer on a particular device. So, the host should detect the scale of the current 
>>>> display and set it on JLF.
>>> Does it mean that all methods related to the Component.getLocationOnScreen() does not work?
>>>>
>>>> However, AWT in order to paint to a volatile image requires CGraphicsDevice and CGLSurfaceData 
>>>> to be created. By default AWT creates CGraphicsDevice instances matching all the detected 
>>>> display devices (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any platform 
>>>> window behind it, AWT can't match JLF to the exact device it's currently displayed on.
>>> Why? You can try to check it youseft via CGLGraphicsConfig.getBounds()+Peer.getBounds();
>>>> So, on the one hand, AWT doesn't know which device is current and what is the current scale 
>>>> (the host passes this value), but from the other hand, AWT has a list of all the 
>>>> CGraphicsDevice instances.
>>>>
>>>> I tried to leverage from that fact. The CPlatformLWView.getGraphicsDevice() method takes the 
>>>> current scale from the JLF instance, and then tries to match it to an existent device from the 
>>>> list. In case it can't find a device with the specified scale (which should not actually 
>>>> happen, unless the host passes an arbitrary scale value, which is not the case for SwingNode) 
>>>> it takes a default device and changes its scale forcedly. I'm not sure if I should create a new 
>>>> dummy device instance instead. The scale factor of the device (which is then propagated to 
>>>> CGLSurfaceData on its creation) is the only info that JLF will take from the device to create a 
>>>> scaled volatile image.
>>>>
>>>> The following changes:
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>>>>
>>>> were made to map a backing store image to a scale factor.
>>>>
>>>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on scrolling. The method was 
>>>> not implemented for a graphics with a scale transform and a BufImgSurfaceData (it threw 
>>>> exceptions). I took that code, copied it to the BufImgSurfaceData.copyArea(...) and added a 
>>>> general translation for the coords:
>>>>
>>>> - 
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>
>>>> It works, but I'm not sure the implementation is eligible (I don't know the details of the Blit 
>>>> class, at least it warns not to use the same source and dest).
>>>>
>>>> The rest of the changes (not covered here) should be clear.
>>>>
>>>> Testing:
>>>>
>>>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & embedded into SwingNode [1]).
>>>> - Testing both Nimbus and Aqua L&F.
>>>> - Setting swing.volatileImageBufferEnabled=false/true for all combinations.
>>>>
>>>> Currently, I see no regressions and no visual issues comparing a standalone mode and a SwingSet 
>>>> mode.
>>>>
>>>> At the end, I suspect there may be some intersection b/w this fix and the fix which introduced 
>>>> MultiResolutionToolkitImage. Unfortunately, I didn't yet read that review saga... Please tell 
>>>> me if I should incorporate anything from that fix.
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>> [1] There's a SwingSet part of the fix which I'm going to post to the jfx alias separately.
>>>>
>>>
>>>
>>
>
>


From anton.tarasov at oracle.com  Thu Dec 12 07:18:18 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 12 Dec 2013 19:18:18 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A8A0FA.30804@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A89175.5030704@oracle.com> <52A8A0FA.30804@oracle.com>
Message-ID: <52A9D3BA.5050903@oracle.com>

[cc'ing to j2d alias]

On 11.12.2013 21:29, Sergey Bylokhov wrote:
> On 11.12.2013 20:23, Anton V. Tarasov wrote:
>>
>>>> - CGraphicsDevice
>>>>
>>>> This setter is only called from CPlatformLWView.getGraphicsDevice(). I've explained it in my 
>>>> previous message. It's needed to change the scale factor of the default device when no device 
>>>> in the list fits. The case is impossible with the current implementation of SwingNode (which 
>>>> only passes JLF a scale factor matching one of a real display), however, as JLF provides a 
>>>> generic lw embedding API, I should cover that case as well.
> Not sure that matching fx to awt devices via scale is not a good idea. Note that it is expected 
> that fields in the CGraphicsDevice chenges only if the screen is changed/added/removed.
> Probably Instead of notifyScaleFactorChanged you can notify about screens changes?

JLightweightFrame is a toplevel that paints its content to an off-screen buffer, so it is 
conceptually not associated with any screen. The host (SwingNode) application communicates with JLF 
on an API level. Introducing a notion of a "screen" to the API doesn't correlate with the JLF's 
concept, imho.

Why I'm still picking the device is because this seemed to me an acceptable approach that integrates 
with LWAWT smoothly. But I agree with you that matching the device via a scale factor is not a good 
idea. Theoretically I can pickup wrong device, but even then it won't change anything for me. I just 
need a device with the requested scale.

What do you think then if we always use default device, for which we will change the scale?

>
>>>>
>>>> - OffScreenImage
>>>>
>>>> I've put a BufferedImage accessor there, nothing else. I didn't find a better place... (I'd 
>>>> appreciate showing it).
>>>>
>>>> - JViewport, RepaintManager
>>>>
>>>> These classes create a double buffer. In case the buffer is backed by a BufferedImage, it will 
>>>> be created with the current scale factor set. The buffer won't be changed when a user moves the 
>>>> host window across multiple screens with different scales. I see two options. 1) Drop the 
>>>> double buffer reference every time the scale changes (in that case, the buffer will be 
>>>> recreated every time, I cross a screen) 2) Create a map which will cache the buffers (say, for 
>>>> 1 and 2 scale factors for double screen env). I think the second approach is better.
>>>>
>>>> > Probably it will be better to disable doublebuffering and SwingPaintEventDispatcher 
>>>> completely(see swing.showFromDoubleBuffer)?
>>>>
>>>> Why? If we can manage it for JLF/SwingNode, why should we downgrade performance?
>>> You have 1 buffere on fx side, buffer in SwingNode, buffer in jviewport, and swing itself use 
>>> double buffering.
>>
>> Ok, this is a good point. But still I can't simply switch off double buffering w/o doing any 
>> benchmarking. SwingNode perf analisys & improvement is in plans...
> It would be good to know results of the benchmarks.

Ok, but as this is a separate task I'd like to know what we're fighting for. Is the goal to avoid 
creating BufferedImage's at all?

>> So far, unless it requires lots of coding (but it doesn't) I'd prefer to keep that option working.
>>
>>>>
>>>>> Actually I still do not understand why JViewport works in the standalone application.
>>>>
>>>> Could you please clarify, I don't understand this question...
>>> I see that JViewport use Offscreen image as a double buffer, is that true that it use it in the 
>>> standalone swing application? If yes why it works.
>>
>> JViewport.paint() is not called with its default blit mode, and so it doesn't actually use an 
>> OffscreenBuffer. For JLF, the mode is set to backing store. If I set the backing store mode in 
>> standalone swing, JViewport stops scaling on Retina. So, it didn't work before.
> Is this related to the JDK-8023966?

Right.

Thanks,
Anton.

>>
>>
>> Thanks,
>> Anton.
>>
>>>
>>>>
>>>> Thanks for the review!
>>>>
>>>> Anton.
>>>>
>>>>>
>>>>> On 10.12.2013 18:22, Anton V. Tarasov wrote:
>>>>>> Hi Jim, Sergey and All,
>>>>>>
>>>>>> Please review the fix that adds support of Retina displays to JLightweightFrame (which javafx 
>>>>>> SwingNode is based on).
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>>>>>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>>>>>
>>>>>> (After the fix goes into jdk9 it should be ported to 8u20 as well, because the functionality 
>>>>>> is essential for SwingNode.)
>>>>>>
>>>>>> The general idea of the fix is as follows.
>>>>>>
>>>>>> A BufferedImage instance, being created in the context in which the scale factor is 
>>>>>> determined and is different from one, is automatically created with appropriately extended 
>>>>>> size. The image itself becomes a scaled image (a "scale" private field is set on it). By the 
>>>>>> "context" I mean the circumstances where the BufferedImage is related to a JLightweightFrame, 
>>>>>> a GraphicsConfiguration, a SurfaceData, or a GraphicsDevice which determine the scale factor.
>>>>>>
>>>>>> Here are the related changes:
>>>>>>
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
>>>>>> (the resizeBuffer method)
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>>>>>>
>>>>>> The "scale" value of a BufferedImage is used when 1) BufferedImageGraphicsConfig is created 
>>>>>> 2) BufImgSurfaceData.getDefaultScale() is called:
>>>>>>
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>>>
>>>>>> The former is used in the GraphicsConfiguration.createCompatibleImage() calls, and the latter 
>>>>>> is used in SurfaceManager.getImageScale(Image):
>>>>>>
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>>>>>>
>>>>>> A scaled BufferedImage is supported by the SunGraphics2D.drawImage() primitives. Here's the 
>>>>>> pattern of how the image may be created and drawn:
>>>>>>
>>>>>> int scale = <get the scale factor from the context>;
>>>>>> BufferedImage img = new BufferedImage(width * scale, height * scale, ...);
>>>>>> img.setScale(scale); // an accessor is currently used instead
>>>>>> <...>
>>>>>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
>>>>>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a specified rect
>>>>>>
>>>>>> In the first case, if the BufferedImage is created with an extended size, the "scale" value 
>>>>>> of the image matters, it should be drawn as a HiDPI image.
>>>>>> In the second case, if the BufferedImage is created with an extended size, the "scale" value 
>>>>>> of the image doesn't matter (it may not be evidently set) as the image will anyway be scaled 
>>>>>> from its physical bounds into provided logical bounds. This all should (as I suppose) provide 
>>>>>> backward compatibility for buffered images that were created in their logical bounds or 
>>>>>> without setting the "scale" field. For instance, the 
>>>>>> AquaPainter.paintFromSingleCachedImage(...) method creates & draws an image as follows:
>>>>>>
>>>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>>>> int imgW = bounds.width * scale;
>>>>>> int imgH = bounds.height * scale;
>>>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>>>> <paint into the img>
>>>>>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);
>>>>>>
>>>>>> Here, the img.scale value is not set (I didn't modify this code), and SunGraphics2D doesn't 
>>>>>> treat the image as a HiDPI image, however it is drawn as expected. An alternative way to draw 
>>>>>> the image would be:
>>>>>>
>>>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>>>> int imgW = bounds.width * scale;
>>>>>> int imgH = bounds.height * scale;
>>>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>>>> img.setScale(scale);
>>>>>> <paint into the img>
>>>>>> g.drawImage(img, bounds.x, bounds.y, ...);
>>>>>>
>>>>>> The result would be the same.
>>>>>>
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>>>>>>
>>>>>> The following changes:
>>>>>>
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>>>>>>
>>>>>> are defined by this logic. Running Swing via JLightweightFrame (JLF) makes it "display 
>>>>>> agnostic". Swing is painted to an off-screen buffer and it's the host (e.g. SwingNode) that 
>>>>>> renders the buffer on a particular device. So, the host should detect the scale of the 
>>>>>> current display and set it on JLF.
>>>>> Does it mean that all methods related to the Component.getLocationOnScreen() does not work?
>>>>>>
>>>>>> However, AWT in order to paint to a volatile image requires CGraphicsDevice and 
>>>>>> CGLSurfaceData to be created. By default AWT creates CGraphicsDevice instances matching all 
>>>>>> the detected display devices (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have 
>>>>>> any platform window behind it, AWT can't match JLF to the exact device it's currently 
>>>>>> displayed on.
>>>>> Why? You can try to check it youseft via CGLGraphicsConfig.getBounds()+Peer.getBounds();
>>>>>> So, on the one hand, AWT doesn't know which device is current and what is the current scale 
>>>>>> (the host passes this value), but from the other hand, AWT has a list of all the 
>>>>>> CGraphicsDevice instances.
>>>>>>
>>>>>> I tried to leverage from that fact. The CPlatformLWView.getGraphicsDevice() method takes the 
>>>>>> current scale from the JLF instance, and then tries to match it to an existent device from 
>>>>>> the list. In case it can't find a device with the specified scale (which should not actually 
>>>>>> happen, unless the host passes an arbitrary scale value, which is not the case for SwingNode) 
>>>>>> it takes a default device and changes its scale forcedly. I'm not sure if I should create a 
>>>>>> new dummy device instance instead. The scale factor of the device (which is then propagated 
>>>>>> to CGLSurfaceData on its creation) is the only info that JLF will take from the device to 
>>>>>> create a scaled volatile image.
>>>>>>
>>>>>> The following changes:
>>>>>>
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>>>>>>
>>>>>> were made to map a backing store image to a scale factor.
>>>>>>
>>>>>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on scrolling. The method 
>>>>>> was not implemented for a graphics with a scale transform and a BufImgSurfaceData (it threw 
>>>>>> exceptions). I took that code, copied it to the BufImgSurfaceData.copyArea(...) and added a 
>>>>>> general translation for the coords:
>>>>>>
>>>>>> - 
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>>>
>>>>>> It works, but I'm not sure the implementation is eligible (I don't know the details of the 
>>>>>> Blit class, at least it warns not to use the same source and dest).
>>>>>>
>>>>>> The rest of the changes (not covered here) should be clear.
>>>>>>
>>>>>> Testing:
>>>>>>
>>>>>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & embedded into SwingNode [1]).
>>>>>> - Testing both Nimbus and Aqua L&F.
>>>>>> - Setting swing.volatileImageBufferEnabled=false/true for all combinations.
>>>>>>
>>>>>> Currently, I see no regressions and no visual issues comparing a standalone mode and a 
>>>>>> SwingSet mode.
>>>>>>
>>>>>> At the end, I suspect there may be some intersection b/w this fix and the fix which 
>>>>>> introduced MultiResolutionToolkitImage. Unfortunately, I didn't yet read that review saga... 
>>>>>> Please tell me if I should incorporate anything from that fix.
>>>>>>
>>>>>> Thanks,
>>>>>> Anton.
>>>>>>
>>>>>> [1] There's a SwingSet part of the fix which I'm going to post to the jfx alias separately.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From anton.tarasov at oracle.com  Thu Dec 12 07:21:04 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 12 Dec 2013 19:21:04 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A8B979.5040400@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A77231.1030902@oracle.com>
	<52A84104.9040400@oracle.com> <52A8B979.5040400@oracle.com>
Message-ID: <52A9D460.1090102@oracle.com>

[cc'ing to j2d]

On 11.12.2013 23:14, Anthony Petrov wrote:
> Hi Anton,
>
> On 12/11/2013 02:40 PM, Anton V. Tarasov wrote:
>>> 2. I'm not sure if adding the scale field to the BI is a good idea. I
>>> think that the image shouldn't be aware of any scale. After all, it's
>>> just an image, a bitmap. It has its real dimensions corresponding to
>>> the actual size of the image stored in RAM. Whether this image is
>>> going to be represented as a scaled image is something that a code
>>> that uses the image should be concerned with, not the image itself.
>>
>> There are two options. 1) Follow to your logic, that is to fix every
>> place in AWT/Swing where BufferedImage is created. In which case in
>> every such place we will have to get a current scale factor from the
>> context. 2) Don't touch that code, but solve the task in some generic
>> way, the way I tried to implement, when a buffered image is created with
>> an extended size right in the factory methods.
>>
>> The logic of the first approach is simpler. However, it would require
>> lots of modifications (in the L&F code, and not only there). And it
>> would require to take into account the scale factor every time a new
>> buffered image case is added to the code. Still, this is possible.
>>
>> With the scond approach I don't need to bother about that code, I just
>> create scaled images "on the fly".
>>
>>  > I think that the image shouldn't be aware of any scale.
>>
>> The "scale" field put into the BufferedImage class means that an image
>> instance should (or shouldn't) be treated as a HiDPI image by the
>> Graphics.drawImage(). So, this is a kind of a special "scale" case,
>> aimed at supporting Retina technology. Probably it deserves a better
>> name, "hidpiScale" or something. So, it's not that the image has been
>> scaled by the user to be drawn on a lager area, but that the image
>> should (or shouldn't) be scaled just to "look smoothly" on a Retina
>> display. That's what I was thinking about...
>
> Thanks for the clarification. The idea sounds reasonable indeed.
>
> I've also read your reply to Jim and I'm now concerned about the fact that scaled images can 
> report larger dimensions than a Graphics created for them would allow one to draw to them. This 
> may be a problem for some apps that perform rendering based on the dimensions of a BI object 
> passed to them.
>
> Shouldn't the BI.getWidth/Height() methods always report the logical size of the image, which is 
> equal to the physical one for scale == 1?

That's probably worth discussing. Let me move this discussion to another thread.

Thanks,
Anton.

>
> -- 
> best regards,
> Anthony
>
>>
>>>
>>>
>>>
>>> 3. src/share/classes/java/awt/peer/FramePeer.java
>>>>  139     default void notifyScaleFactorChanged() {}
>>>
>>> I think this deserves to be declared in WindowPeer so that we could
>>> use it w/o additional modifications in the future if we add support
>>> for public notifications about the scale factor changes.
>>
>> Ok.
>>
>>>
>>>
>>> 4. I'm CC'ing swing-dev@ and Alexander Scherbatiy to review changes in
>>> the JViewport class and other Swing classes.
>>
>> Thanks for the review!
>>
>> Anton.
>>
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 12/10/2013 06:22 PM, Anton V. Tarasov wrote:
>>>> Hi Jim, Sergey and All,
>>>>
>>>> Please review the fix that adds support of Retina displays to
>>>> JLightweightFrame (which javafx SwingNode is based on).
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>>>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>>>
>>>> (After the fix goes into jdk9 it should be ported to 8u20 as well,
>>>> because the functionality is essential for SwingNode.)
>>>>
>>>> The general idea of the fix is as follows.
>>>>
>>>> A BufferedImage instance, being created in the context in which the
>>>> scale factor is determined and is different from one, is automatically
>>>> created with appropriately extended size. The image itself becomes a
>>>> scaled image (a "scale" private field is set on it). By the "context" I
>>>> mean the circumstances where the BufferedImage is related to a
>>>> JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a
>>>> GraphicsDevice which determine the scale factor.
>>>>
>>>> Here are the related changes:
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html 
>>>>
>>>>
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html 
>>>>
>>>>
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
>>>>
>>>>
>>>> (the resizeBuffer method)
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html 
>>>>
>>>>
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html 
>>>>
>>>>
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html 
>>>>
>>>>
>>>>
>>>>
>>>> The "scale" value of a BufferedImage is used when 1)
>>>> BufferedImageGraphicsConfig is created 2)
>>>> BufImgSurfaceData.getDefaultScale() is called:
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html 
>>>>
>>>>
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html 
>>>>
>>>>
>>>>
>>>>
>>>> The former is used in the GraphicsConfiguration.createCompatibleImage()
>>>> calls, and the latter is used in SurfaceManager.getImageScale(Image):
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html 
>>>>
>>>>
>>>>
>>>>
>>>> A scaled BufferedImage is supported by the SunGraphics2D.drawImage()
>>>> primitives. Here's the pattern of how the image may be created and
>>>> drawn:
>>>>
>>>> int scale = <get the scale factor from the context>;
>>>> BufferedImage img = new BufferedImage(width * scale, height * scale,
>>>> ...);
>>>> img.setScale(scale); // an accessor is currently used instead
>>>> <...>
>>>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
>>>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a
>>>> specified rect
>>>>
>>>> In the first case, if the BufferedImage is created with an extended
>>>> size, the "scale" value of the image matters, it should be drawn as a
>>>> HiDPI image.
>>>> In the second case, if the BufferedImage is created with an extended
>>>> size, the "scale" value of the image doesn't matter (it may not be
>>>> evidently set) as the image will anyway be scaled from its physical
>>>> bounds into provided logical bounds. This all should (as I suppose)
>>>> provide backward compatibility for buffered images that were created in
>>>> their logical bounds or without setting the "scale" field. For instance,
>>>> the AquaPainter.paintFromSingleCachedImage(...) method creates & draws
>>>> an image as follows:
>>>>
>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>> int imgW = bounds.width * scale;
>>>> int imgH = bounds.height * scale;
>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>> <paint into the img>
>>>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);
>>>>
>>>> Here, the img.scale value is not set (I didn't modify this code), and
>>>> SunGraphics2D doesn't treat the image as a HiDPI image, however it is
>>>> drawn as expected. An alternative way to draw the image would be:
>>>>
>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>> int imgW = bounds.width * scale;
>>>> int imgH = bounds.height * scale;
>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>> img.setScale(scale);
>>>> <paint into the img>
>>>> g.drawImage(img, bounds.x, bounds.y, ...);
>>>>
>>>> The result would be the same.
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html 
>>>>
>>>>
>>>>
>>>>
>>>> The following changes:
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html 
>>>>
>>>>
>>>>
>>>>
>>>> are defined by this logic. Running Swing via JLightweightFrame (JLF)
>>>> makes it "display agnostic". Swing is painted to an off-screen buffer
>>>> and it's the host (e.g. SwingNode) that renders the buffer on a
>>>> particular device. So, the host should detect the scale of the current
>>>> display and set it on JLF.
>>>>
>>>> However, AWT in order to paint to a volatile image requires
>>>> CGraphicsDevice and CGLSurfaceData to be created. By default AWT creates
>>>> CGraphicsDevice instances matching all the detected display devices
>>>> (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any
>>>> platform window behind it, AWT can't match JLF to the exact device it's
>>>> currently displayed on. So, on the one hand, AWT doesn't know which
>>>> device is current and what is the current scale (the host passes this
>>>> value), but from the other hand, AWT has a list of all the
>>>> CGraphicsDevice instances.
>>>>
>>>> I tried to leverage from that fact. The
>>>> CPlatformLWView.getGraphicsDevice() method takes the current scale from
>>>> the JLF instance, and then tries to match it to an existent device from
>>>> the list. In case it can't find a device with the specified scale (which
>>>> should not actually happen, unless the host passes an arbitrary scale
>>>> value, which is not the case for SwingNode) it takes a default device
>>>> and changes its scale forcedly. I'm not sure if I should create a new
>>>> dummy device instance instead. The scale factor of the device (which is
>>>> then propagated to CGLSurfaceData on its creation) is the only info that
>>>> JLF will take from the device to create a scaled volatile image.
>>>>
>>>> The following changes:
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html 
>>>>
>>>>
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html 
>>>>
>>>>
>>>>
>>>>
>>>> were made to map a backing store image to a scale factor.
>>>>
>>>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on
>>>> scrolling. The method was not implemented for a graphics with a scale
>>>> transform and a BufImgSurfaceData (it threw exceptions). I took that
>>>> code, copied it to the BufImgSurfaceData.copyArea(...) and added a
>>>> general translation for the coords:
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html 
>>>>
>>>>
>>>>
>>>>
>>>> It works, but I'm not sure the implementation is eligible (I don't know
>>>> the details of the Blit class, at least it warns not to use the same
>>>> source and dest).
>>>>
>>>> The rest of the changes (not covered here) should be clear.
>>>>
>>>> Testing:
>>>>
>>>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode &
>>>> embedded into SwingNode [1]).
>>>> - Testing both Nimbus and Aqua L&F.
>>>> - Setting swing.volatileImageBufferEnabled=false/true for all
>>>> combinations.
>>>>
>>>> Currently, I see no regressions and no visual issues comparing a
>>>> standalone mode and a SwingSet mode.
>>>>
>>>> At the end, I suspect there may be some intersection b/w this fix and
>>>> the fix which introduced MultiResolutionToolkitImage. Unfortunately, I
>>>> didn't yet read that review saga... Please tell me if I should
>>>> incorporate anything from that fix.
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>> [1] There's a SwingSet part of the fix which I'm going to post to the
>>>> jfx alias separately.
>>>>
>>


From anton.tarasov at oracle.com  Thu Dec 12 07:23:09 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 12 Dec 2013 19:23:09 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A8B979.5040400@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A77231.1030902@oracle.com>
	<52A84104.9040400@oracle.com> <52A8B979.5040400@oracle.com>
Message-ID: <52A9D4DD.6010502@oracle.com>

[cc'ing to j2d]

On 11.12.2013 23:14, Anthony Petrov wrote:
> Hi Anton,
>
> On 12/11/2013 02:40 PM, Anton V. Tarasov wrote:
>>> 2. I'm not sure if adding the scale field to the BI is a good idea. I
>>> think that the image shouldn't be aware of any scale. After all, it's
>>> just an image, a bitmap. It has its real dimensions corresponding to
>>> the actual size of the image stored in RAM. Whether this image is
>>> going to be represented as a scaled image is something that a code
>>> that uses the image should be concerned with, not the image itself.
>>
>> There are two options. 1) Follow to your logic, that is to fix every
>> place in AWT/Swing where BufferedImage is created. In which case in
>> every such place we will have to get a current scale factor from the
>> context. 2) Don't touch that code, but solve the task in some generic
>> way, the way I tried to implement, when a buffered image is created with
>> an extended size right in the factory methods.
>>
>> The logic of the first approach is simpler. However, it would require
>> lots of modifications (in the L&F code, and not only there). And it
>> would require to take into account the scale factor every time a new
>> buffered image case is added to the code. Still, this is possible.
>>
>> With the scond approach I don't need to bother about that code, I just
>> create scaled images "on the fly".
>>
>>  > I think that the image shouldn't be aware of any scale.
>>
>> The "scale" field put into the BufferedImage class means that an image
>> instance should (or shouldn't) be treated as a HiDPI image by the
>> Graphics.drawImage(). So, this is a kind of a special "scale" case,
>> aimed at supporting Retina technology. Probably it deserves a better
>> name, "hidpiScale" or something. So, it's not that the image has been
>> scaled by the user to be drawn on a lager area, but that the image
>> should (or shouldn't) be scaled just to "look smoothly" on a Retina
>> display. That's what I was thinking about...
>
> Thanks for the clarification. The idea sounds reasonable indeed.
>
> I've also read your reply to Jim and I'm now concerned about the fact that scaled images can
> report larger dimensions than a Graphics created for them would allow one to draw to them. This
> may be a problem for some apps that perform rendering based on the dimensions of a BI object
> passed to them.
>
> Shouldn't the BI.getWidth/Height() methods always report the logical size of the image, which is
> equal to the physical one for scale == 1?

That's probably worth discussing. Let me move this discussion to another thread.

Thanks,
Anton.

>
> --
> best regards,
> Anthony
>
>>
>>>
>>>
>>>
>>> 3. src/share/classes/java/awt/peer/FramePeer.java
>>>>  139     default void notifyScaleFactorChanged() {}
>>>
>>> I think this deserves to be declared in WindowPeer so that we could
>>> use it w/o additional modifications in the future if we add support
>>> for public notifications about the scale factor changes.
>>
>> Ok.
>>
>>>
>>>
>>> 4. I'm CC'ing swing-dev@ and Alexander Scherbatiy to review changes in
>>> the JViewport class and other Swing classes.
>>
>> Thanks for the review!
>>
>> Anton.
>>
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 12/10/2013 06:22 PM, Anton V. Tarasov wrote:
>>>> Hi Jim, Sergey and All,
>>>>
>>>> Please review the fix that adds support of Retina displays to
>>>> JLightweightFrame (which javafx SwingNode is based on).
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>>>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>>>
>>>> (After the fix goes into jdk9 it should be ported to 8u20 as well,
>>>> because the functionality is essential for SwingNode.)
>>>>
>>>> The general idea of the fix is as follows.
>>>>
>>>> A BufferedImage instance, being created in the context in which the
>>>> scale factor is determined and is different from one, is automatically
>>>> created with appropriately extended size. The image itself becomes a
>>>> scaled image (a "scale" private field is set on it). By the "context" I
>>>> mean the circumstances where the BufferedImage is related to a
>>>> JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a
>>>> GraphicsDevice which determine the scale factor.
>>>>
>>>> Here are the related changes:
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
>>>>
>>>>
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
>>>>
>>>>
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html
>>>>
>>>>
>>>> (the resizeBuffer method)
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
>>>>
>>>>
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>>
>>>>
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>>>>
>>>>
>>>>
>>>>
>>>> The "scale" value of a BufferedImage is used when 1)
>>>> BufferedImageGraphicsConfig is created 2)
>>>> BufImgSurfaceData.getDefaultScale() is called:
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>>
>>>>
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>
>>>>
>>>>
>>>>
>>>> The former is used in the GraphicsConfiguration.createCompatibleImage()
>>>> calls, and the latter is used in SurfaceManager.getImageScale(Image):
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>>>>
>>>>
>>>>
>>>>
>>>> A scaled BufferedImage is supported by the SunGraphics2D.drawImage()
>>>> primitives. Here's the pattern of how the image may be created and
>>>> drawn:
>>>>
>>>> int scale = <get the scale factor from the context>;
>>>> BufferedImage img = new BufferedImage(width * scale, height * scale,
>>>> ...);
>>>> img.setScale(scale); // an accessor is currently used instead
>>>> <...>
>>>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
>>>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a
>>>> specified rect
>>>>
>>>> In the first case, if the BufferedImage is created with an extended
>>>> size, the "scale" value of the image matters, it should be drawn as a
>>>> HiDPI image.
>>>> In the second case, if the BufferedImage is created with an extended
>>>> size, the "scale" value of the image doesn't matter (it may not be
>>>> evidently set) as the image will anyway be scaled from its physical
>>>> bounds into provided logical bounds. This all should (as I suppose)
>>>> provide backward compatibility for buffered images that were created in
>>>> their logical bounds or without setting the "scale" field. For instance,
>>>> the AquaPainter.paintFromSingleCachedImage(...) method creates & draws
>>>> an image as follows:
>>>>
>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>> int imgW = bounds.width * scale;
>>>> int imgH = bounds.height * scale;
>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>> <paint into the img>
>>>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);
>>>>
>>>> Here, the img.scale value is not set (I didn't modify this code), and
>>>> SunGraphics2D doesn't treat the image as a HiDPI image, however it is
>>>> drawn as expected. An alternative way to draw the image would be:
>>>>
>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>> int imgW = bounds.width * scale;
>>>> int imgH = bounds.height * scale;
>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>> img.setScale(scale);
>>>> <paint into the img>
>>>> g.drawImage(img, bounds.x, bounds.y, ...);
>>>>
>>>> The result would be the same.
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>>>>
>>>>
>>>>
>>>>
>>>> The following changes:
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>>>>
>>>>
>>>>
>>>>
>>>> are defined by this logic. Running Swing via JLightweightFrame (JLF)
>>>> makes it "display agnostic". Swing is painted to an off-screen buffer
>>>> and it's the host (e.g. SwingNode) that renders the buffer on a
>>>> particular device. So, the host should detect the scale of the current
>>>> display and set it on JLF.
>>>>
>>>> However, AWT in order to paint to a volatile image requires
>>>> CGraphicsDevice and CGLSurfaceData to be created. By default AWT creates
>>>> CGraphicsDevice instances matching all the detected display devices
>>>> (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have any
>>>> platform window behind it, AWT can't match JLF to the exact device it's
>>>> currently displayed on. So, on the one hand, AWT doesn't know which
>>>> device is current and what is the current scale (the host passes this
>>>> value), but from the other hand, AWT has a list of all the
>>>> CGraphicsDevice instances.
>>>>
>>>> I tried to leverage from that fact. The
>>>> CPlatformLWView.getGraphicsDevice() method takes the current scale from
>>>> the JLF instance, and then tries to match it to an existent device from
>>>> the list. In case it can't find a device with the specified scale (which
>>>> should not actually happen, unless the host passes an arbitrary scale
>>>> value, which is not the case for SwingNode) it takes a default device
>>>> and changes its scale forcedly. I'm not sure if I should create a new
>>>> dummy device instance instead. The scale factor of the device (which is
>>>> then propagated to CGLSurfaceData on its creation) is the only info that
>>>> JLF will take from the device to create a scaled volatile image.
>>>>
>>>> The following changes:
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
>>>>
>>>>
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>>>>
>>>>
>>>>
>>>>
>>>> were made to map a backing store image to a scale factor.
>>>>
>>>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on
>>>> scrolling. The method was not implemented for a graphics with a scale
>>>> transform and a BufImgSurfaceData (it threw exceptions). I took that
>>>> code, copied it to the BufImgSurfaceData.copyArea(...) and added a
>>>> general translation for the coords:
>>>>
>>>> -
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>
>>>>
>>>>
>>>>
>>>> It works, but I'm not sure the implementation is eligible (I don't know
>>>> the details of the Blit class, at least it warns not to use the same
>>>> source and dest).
>>>>
>>>> The rest of the changes (not covered here) should be clear.
>>>>
>>>> Testing:
>>>>
>>>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode &
>>>> embedded into SwingNode [1]).
>>>> - Testing both Nimbus and Aqua L&F.
>>>> - Setting swing.volatileImageBufferEnabled=false/true for all
>>>> combinations.
>>>>
>>>> Currently, I see no regressions and no visual issues comparing a
>>>> standalone mode and a SwingSet mode.
>>>>
>>>> At the end, I suspect there may be some intersection b/w this fix and
>>>> the fix which introduced MultiResolutionToolkitImage. Unfortunately, I
>>>> didn't yet read that review saga... Please tell me if I should
>>>> incorporate anything from that fix.
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>> [1] There's a SwingSet part of the fix which I'm going to post to the
>>>> jfx alias separately.
>>>>
>>


From anton.tarasov at oracle.com  Thu Dec 12 07:50:30 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 12 Dec 2013 19:50:30 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A8D986.20206@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A77231.1030902@oracle.com>
	<52A84104.9040400@oracle.com> <52A8D986.20206@oracle.com>
Message-ID: <52A9DB46.6090304@oracle.com>

[cc'ing to j2d]

On 12.12.2013 1:30, Jim Graham wrote:
>
>
> On 12/11/13 2:40 AM, Anton V. Tarasov wrote:
>> On 10.12.2013 23:57, Anthony Petrov wrote:
>>> I think that the image shouldn't be aware of any scale.
>>
>> The "scale" field put into the BufferedImage class means that an image
>> instance should (or shouldn't) be treated as a HiDPI image by the
>> Graphics.drawImage(). So, this is a kind of a special "scale" case,
>> aimed at supporting Retina technology. Probably it deserves a better
>> name, "hidpiScale" or something. So, it's not that the image has been
>> scaled by the user to be drawn on a lager area, but that the image
>> should (or shouldn't) be scaled just to "look smoothly" on a Retina
>> display. That's what I was thinking about...
>
> The problem with this, to me, is that a developer may make the assumption in layout that the image 
> will take "getWidth(null), getHeight(null)" size in the output when rendered with the default 
> "drawImage(img, x, y, obs)" call.  You are going to violate that assumption here.
>
> Another conflicting issue is that a developer would assume that if an image is "instanceof 
> BufferedImage" then those same dimensions are going to define how much data they can read when 
> they call getRGB(x, y) or get the raster.
>
> Something is going to break when trying to use buffered images for auto-scaled output.

Ok, there's another option, it's to return a layout size from getWidth/getHeight (as Anthony 
suggested). But this doesn't solve the problem with the raster and the backing array which will be 
of scaled length...

>
> Perhaps we need a "hidden image type based on buffered image internally" image to use in these 
> cases?  Or some sort of "render buffer object" which contains a reference to the image to render 
> into and a concept of the scale it will be rendered to and from rather than baking those concepts 
> directly into BufferedImage...?
>
> (Note that we already have this problem in FX as well when we introduced reading from images and 
> HiDPI in the same release, but we want the public object to return the layout sizes - for now we 
> average 4 pixels in the readback to solve the problem, but we do not expose the pixels like 
> BufferedImage and we are going to have to introduce API at some point to allow them to get a pixel 
> readback from a particular scaled version of the image...)
>
> If these images are not at all exposed to the developer in any way then I would encourage some 
> solution/mechanism that did not insert itself into BufferedImage.  Perhaps we could have SwingBI 
> class that extends BImg and introduces the scale factor at that level, only to be dealt with 
> internally?  Or does Swing have a bunch of "new BufferedImage()" calls sprinkled throughout?

Swing indirectly creates a BufferedImage via the factory methods: 
createCompatibleVolatileImage/createCompatibleImage/createImage. The question is if we can't export 
a scaled version of a BufferedImage, then what options do we have? What comes to my mind is this:

1) In every place such a method is called, call for a (internal private) "scaled version" of the method.
2) Somehow detect when the method is called by Swing and return a scaled BufferedImage or otherwise 
return a plain image. Not sure if a good solution exists.

Thanks,
Anton.

>
>             ...jim


From anton.tarasov at oracle.com  Thu Dec 12 07:52:58 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 12 Dec 2013 19:52:58 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A8DCC8.1070405@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A82CEB.3010203@oracle.com>
	<52A86508.3030803@oracle.com> <52A8DCC8.1070405@oracle.com>
Message-ID: <52A9DBDA.1020704@oracle.com>

[cc'ing to j2d]

Jim, let me continue this thread later when a general agreement about a scaled BufferedImage is made.

Thanks,
Anton.

On 12.12.2013 1:44, Jim Graham wrote:
> Hi Anton,
>
> On 12/11/13 5:13 AM, Anton V. Tarasov wrote:
>> Hi Jim,
>>
>> On 11.12.2013 13:14, Jim Graham wrote:
>>>
>>> In BufferedImage, the private fields and methods will require an
>>> accessor method for the inner class to access them.  Is there a reason
>>> they can't be left package-accessible?
>>
>> Sorry, I don't clearly understand what you mean... The "scale" private
>> field and the new methods are accessed from other packages, so I can't
>> make them package-private. I've added the accessor which I put into
>> OffscreenImage (an internal class).
>
> This is entirely an internal detail related to how inner classes are implemented (like the class 
> that you use to allow OffscreenImage to access the BI methods).
>
> The inner "accessor helper" class is technically outside the class scope of the BufferedImage 
> class - it is a separate class and it is restricted in the byte code interpreter to the same 
> access privileges as any other "separate class", but the methods it calls on BI are private.  The 
> runtime does not allow this, but the compiler wants you to think this is possible for convenience 
> of writing inner classes.  As a result, it injects fake accessor calls into the BI class that 
> allow the inner classes to call private methods on BI.  Dump the byte codes of the relevant 
> classes with javap and you will see the shadow calls that break the privacy of those methods.  
> Those methods are not allowed from java code, only the inner class magic can use them.  It is 
> byte-code magic to enable the syntactic sugar of inner classes.
>
> I believe if you just make the new methods on BI package-private instead of fully class-private, 
> then those helper inner-class-only accessor methods aren't needed.
>
>>> In JViewport, is there a reason why a map of various scaled backing
>>> stores are kept rather than just validating the existing backing store
>>> against the new desired scale and replacing it when it changes?  Does
>>> the scale on the backing store ping-pong back and forth between scales
>>> much?
>>
>> This doesn't ping-pong much, indeed. So you want to say using a cache
>> here is not justified? Ok, why I did that is probably to mimic the logic
>> used by RepaintManager which does use a map b/w graphic configs and
>> volatile images (the volatileMap field), whereas changes of the
>> GraphicsConfig shouldn't occur often.
>>
>> Anyway, this indeed doesn't increase performance but increases a
>> footprint, so I'm ok not to use cache here.
>
> I just wanted an analysis of whether the new complexity had any value. It sounds like it mirrors 
> what was done in other places and that is fine, but perhaps this particular variant of that 
> similar mechanism is premature?  In general, I'd wait to add complexity until a problem is 
> demonstrated that makes it worthwhile.
>
>>> BufImgSurfaceData - you have to validate the transform as not flipping
>>> or rotating (even quadrant rotation will violate your conditions.  I
>>> believe that testing the transform type with a mask consisting of the
>>> TRANSLATE and SCALE_MASK flags should be fine. Also, do we wan to set
>>> a precedent of allowing copyArea under an arbitrary scale, or should
>>> we test it to make sure it is specifically the same scale as the
>>> device scale factor?
>>
>> Ok, I'll check the transform for TRANSLATE/SCALE only. The same scale as
>> the device works for me, so I'll limit it to that case.
>
> Though, I do think we should eventually have copyarea work with scales.
>
> BTW, this same code appears in SG2D, but it is rejected by a test on the transform type.  Have you 
> thought about simply inserting your transform code into the test for the transform type in SG2D 
> rather than shadowing the entire method?
>
>>> SG2D - I'm worried about the performance impliciations of adding a new
>>> method in that creates and returns an array on every drawImage call.
>>> Did you do a performance test with J2DBench to verify the impact of
>>> these operations?
>>
>> Well, this was done just to make the code more clear. I can remove that
>> method (and do the instanceof check in every place I called it), or as
>> an alternative I can cache the array so that not to create it (out of
>> the stack) every time. Does this make sense to you? (I didn't run
>> J2DBench yet).
>
> A single SG2D should be single threaded (calling from multiple threads is not supported and 
> results are not guaranteed) so caching the array in the instance would be fine.  Also, we are 
> discussing the issue of getWidth(null) not matching the logical size of the image in another 
> thread.  Depending on what we decide there, it may make sense to move the scaling logic inside the 
> getWidth() methods of the scaled buffered images and then we need far fewer mods to SG2D.  But, I 
> think that would only work reasonably if such "scaled buffered images" are never leaked to the 
> developer until we come up with a reasonable external API that makes sense for them.
>
> I'm going to save the rest of the reply for another message since it gets involved...
>
>             ...jim


From anton.tarasov at oracle.com  Thu Dec 12 08:06:37 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 12 Dec 2013 20:06:37 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A8DF2E.2030207@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A82CEB.3010203@oracle.com>
	<52A86508.3030803@oracle.com> <52A8DF2E.2030207@oracle.com>
Message-ID: <52A9DF0D.3010400@oracle.com>

[cc'ing to j2d]

On 12.12.2013 1:54, Jim Graham wrote:
>
>
> On 12/11/13 5:13 AM, Anton V. Tarasov wrote:
>> On 11.12.2013 13:14, Jim Graham wrote:
>>> With the new support for scaled BufferedImages we now have a situation
>>> where some images return their logical dimensions from
>>> getWidth/Height(null) and some return physical dimensions. That's a
>>> little dicey as the method now has two meanings depending on how the
>>> images were created.  We're sort of between a rock and a hard place in
>>> that BufferedImage objects have a historical context for how their
>>> values relate to the pixels you can access, but we also have a
>>> relationship between how the return values of
>>> getWidth/Height(observer) relate to the size the image is drawn on the
>>> screen.  Is this only ever done for the backing store objects?  Do we
>>> ever expose them to developers?
>>
>> Well, this is the question I was waiting for... The methods
>> getWidth/Height will continue to return the physical size of an image,
>> regardless of was it scaled or not. However, for a scaled image the
>> physical size, and so the returned values will be auto-scaled. This is
>> applicable to the following "factory" methods I've overriden:
>>
>> 1) BufferedImageGraphicsConfig.createCompatibleImage(...)
>> 2) CGLGraphicsConfig.createCompatibleImage(...)
>> 3) LWLightweightFramePeer.createImage(...)
>>
>> The 1st depend on the scale factor of the GC instance the method is
>> called on. The scale factor of BufferedImageGraphicsConfig is taken from
>> the BI instance passed to its ctor. So, this won't affect any third
>> party code, as the BI.scale field has a private access.
>>
>> The 2nd depend on the scale factor of the device, which is set either by
>> the platform or by me (in case when I set it to the default device in
>> CPlatformLWView.java). So, theoretically it is possible for a user to
>> call this method on a Retina display and get a scaled image.
>
> We are subtly changing the meaning of createCompatibleImage() in both of those circumstances.  
> It's hard to understand the impact of that subtle change.  It looks like this fix is targeted at 
> JDK9 so we have time to vet it, but my initial gut feel on this is that we are going to confuse 
> some developers here unless we create a special "createCompatibleImage()" method variant (with 
> perhaps a different name) that specifically requests an image with an appropriate scale.  If we 
> are then going to service those requests with BufferedImage return values then we add an 
> additional issue in that we have conflicting needs for the various methods on BI in that case.

I rather agree with you. Another problem is that we need a solution for jdk8u20 as well...

>
>> The 3rd depend on the scale factor taken from the JLightweightFrame
>> instance. This affects only the code run inside the JLF, however a user
>> is able to call this method (on any of a component from the JLF's
>> hierarchy) and get a scaled image.
>>
>> So, we have situations when a user might create a BufferedImage with w*h
>
> Are they specifically creating a BufferedImage, or an Image that happens to be an instance of BI 
> in most current cases?

Component.createImage(..) is currently used by Swing in only two cases: as a double buffer factory 
method (by JViewport and RepaintManager). The javadoc for the method says just that: "an Image for 
double buffering". I don't know if this method is used by a third party code... Still, it is public.

GraphicsConfiguration.createCompatibleImage(..) returns BufferedImage. It's used 1) as a fallback 
for a createCompatibleVolatileImage when acceleration is not supported 2) directly from a number of 
places: d&d, custom cursor, tray icon, printing, 2/3 more minor cases.

Again, I don't know what's the rating of these methods among developers...

>
>> size but get back an image with w*h*4 size (on a Retina display). And
>> this might be unexpected. However, this image will produce a "context"
>> with the same scale factor. A BufferedImageGraphicsConfig will be
>> created with the same scale (see its ctor), a BufImgSurfaceData will be
>> created with the same scale (see its getDefaultScale() method), and a
>> SunGraphics2D will be created with the same scale ("devScale =
>> sd.getDefaultScale();" in its ctor). In this case, all drawings into the
>> image will take the scale into account, and should be correct. The only
>> concern is the size of the image itself. At least, this is not
>> documented...
>
> My big worry here is that we currently have 2 consumers of BI.getWidth(null) - one group that 
> expects the answer to relate to layout, and another that expects the answer to relate to pixel 
> access.
>
> Here is where someone dons their "genius hat" and comes up with a creative solution that works for 
> both groups.  Mine is unfortunately at the cleaners right now and they don't know when they'll 
> have it done... :(
>
> But, I feel there is a good common ground to be found there once we wrap our heads around the 
> problem the right way (and with the right "genius hat").  Also, perhaps we need to engage the 
> 2d-dev list as well here, since the results will affect them as well?

Well, let's find that right way :)

Thanks,
Anton.

>
>
>             ...jim


From alexander.zvegintsev at oracle.com  Thu Dec 12 09:03:56 2013
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 12 Dec 2013 21:03:56 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029263, ,
 The user's default browser can not launch after we click the button,
 and there is an IOException shown in the log txt (java.io.IOException)
Message-ID: <52A9EC7C.6000200@oracle.com>

Hello AWT team,

Please review fix
http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8029263

This issue can be observed on Solaris 11 (sparcv9 or x86_64).

gtk_show_uri() documentation[1] says:
> The uri must be of a form understood by GIO (i.e. you need to install 
> gvfs to get support for uri schemes such as http:// or ftp://, as only 
> local files are handled by GIO itself).
However it looks like that Solaris 11 supports gvfs for 32-bit 
applications only by default. gtk_show_uri() returns "Operation not 
supported" error message  for 64-bit applications
for schemes other than file://.

Since b110 we don't have 32-bit JDK for Solaris anymore, so in most 
cases only an OPEN action is available(file://).

Currently I am unable to find any robust way to determine do we have 
full gvfs support to handle URIs like mail:, http:// or not.

We can use g_vfs_get_supported_uri_schemes()[2] and assume that we have 
full gvfs support if  http:// scheme is present.
But this function depends on a DBUS_SESSION_BUS_ADDRESS environment 
variable, which can be stripped off in some tests
(in this case only file:// scheme will be returned).


Old gnome_url_show() will not work  too due to lack of 64-bit 
libgnomevfs-2.0 library.



[1] 
https://developer.gnome.org/gtk2/stable/gtk2-Filesystem-utilities.html#gtk-show-uri
[2] 
https://developer.gnome.org/gio/stable/GVfs.html#g-vfs-get-supported-uri-schemes 


-- 
Thanks,

Alexander.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131212/47dcced5/attachment.html 

From Sergey.Bylokhov at oracle.com  Thu Dec 12 11:19:14 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 12 Dec 2013 23:19:14 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A9D341.2070008@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com>
Message-ID: <52AA0C32.504@oracle.com>

On 12/12/13 7:16 PM, Anton V. Tarasov wrote:
> [cc'ing to j2d]
>
> On 11.12.2013 14:38, Sergey Bylokhov wrote:
>> On 11.12.2013 13:18, Anton V. Tarasov wrote:
>>> Hi Sergey,
>>>
>>> On 11.12.2013 3:26, Sergey Bylokhov wrote:
>>>> Hi, Anton.
>>>> My expectation was that everything should work automatically, if 
>>>> you get correct CGraphicsDevice for the embedded swing window + 
>>>> some tweaks in the code related to the peer and CGLSurfaceData/
>>>>
>>>> Why we need all this change in 
>>>> CGraphicsDevice,CGLGraphicsConfig,OffScreenImage,CPlatformLWView,JViewport,RepaintManager.
>>>
>>> With Nimus, at some moment, when the 
>>> nimbus.AbstractRegionPainter.paint(Graphics2D g, ...) method is 
>>> called it is passed the graphics instance created by 
>>> JLF.createGraphics() which derives it from the JLF's root buffered 
>>> image. Then, somewhere up the stack the method calls for 
>>> getImage(g.getDeviceConfiguration(),..),
>> Yes, correct. But you can created double sized surface for you 
>> buffered image(in the same way as it was done for volatile) and 
>> provide correct DeviceConfiguration for it.
>
> Sergey,
>
> It seems I didn't yet understand you. Could you please clarify? What 
> "double sized" surface do you mean for a BufferedImage, and what do 
> you mean by the "correct" DeviceConfiguration for it? (I can't put a 
> CGLSurfaceData into a BufferedImage).
When retina support was added to the volatile images, there were the 
same problems with the mixing of "logical" and "real" sizes. And 
volatile image(logical view) was not changed, but its surface was. When 
the volatile image is created we check the native scale and use it to 
create the surface, then in SG2D we take the difference between an image 
and its surface into account.
Why we cannot do the same thing for OffscreenImage? We control when it 
is created, we control when its used, offscrenimage is created for the 
component-> we know what GraphicConfigs should be used for the scale 
checking. Probably we can reuse/extract some code which was added to the 
cglsurface?

>
> Thanks,
> Anton.
>
>>> where the graphics conf is of BufferdeImageGraphicsConfig type. This 
>>> flows into GraphicsConfiguration.createCompatibleVolatileImage(int 
>>> w, int h, ...) and then into BufImgVolatileSurfaceManager which 
>>> doesn't support acceleration, and eventually into 
>>> BufferedImageGraphicsConfig.createCompatibleImage(int w, int h, 
>>> ...). The [w, h] values passed here represent a logical size of a 
>>> Nimbus ui element. Unless I scale the size of the requested image 
>>> here, the ui element is shown stretched. That's why the changes in 
>>> BufferedImageGraphicsConfig.
>>>
>>> With Aqua, I don't observe calls into BufImgVolatileSurfaceManager. 
>>> I suppose the reason is that a GraphicsConfiguration instance is 
>>> always taken from a component (from the JLF's hierarchy) which is 
>>> tight to a CGraphicsDevice and has a CGLGraphicsConfig, not 
>>> BufferdeImageGraphicsConfig. CGLVolatileSurfaceManager enables 
>>> acceleration, and so the process of a volatile image creation never 
>>> falls back to CLGGraphicsConfig.createCompatibleImage(...). By 
>>> "never" I mean that I didn't catch it with the tests I ran. However, 
>>> "find usages" shows that these methods are directly called from 
>>> CTrayIcon, CDragSourceContextPeer, CCustomCursor, at least. I rather 
>>> should cover those areas with some tests as well. Anyway, I've made 
>>> these methods (CLGGraphicsConfig.createCompatibleImage(...)) 
>>> consistent with the 
>>> BufferedImageGraphicsConfig.createCompatibleImage(...) methods and 
>>> with the general idea I've described before.
>>>
>>> Then, the other files you're referring to:
>>>
>>> - CPlatformLWView
>>>
>>> As I explained before, AWT in the lw embedding mode can't match a 
>>> window to the display it is showing on, simply because it doesn't 
>>> have a platform window underneath. 
>>> CPlatformView.nativeGetNSViewDisplayID(getAWTView()) returns zero, 
>>> and so CPlatformView.getGraphicsDevice() returns default device, not 
>>> necessarily matching the scale factor of the current device.
>> Why? You can try to check it youseft via 
>> CGLGraphicsConfig.getBounds()+Peer.getBounds(); You need to override 
>> CPlatformWindow.getGraphicsDevice() and return correct device.  I see 
>> that the similar bug exists in applets where 
>> CPlatformEmbeddedFrame.getGraphicsDevice always return  default device.
>> Same question about Component.getLocationOnScreen() is working in 
>> SwingNode?
>>>
>>> - CGraphicsDevice
>>>
>>> This setter is only called from CPlatformLWView.getGraphicsDevice(). 
>>> I've explained it in my previous message. It's needed to change the 
>>> scale factor of the default device when no device in the list fits. 
>>> The case is impossible with the current implementation of SwingNode 
>>> (which only passes JLF a scale factor matching one of a real 
>>> display), however, as JLF provides a generic lw embedding API, I 
>>> should cover that case as well.
>>>
>>> - OffScreenImage
>>>
>>> I've put a BufferedImage accessor there, nothing else. I didn't find 
>>> a better place... (I'd appreciate showing it).
>>>
>>> - JViewport, RepaintManager
>>>
>>> These classes create a double buffer. In case the buffer is backed 
>>> by a BufferedImage, it will be created with the current scale factor 
>>> set. The buffer won't be changed when a user moves the host window 
>>> across multiple screens with different scales. I see two options. 1) 
>>> Drop the double buffer reference every time the scale changes (in 
>>> that case, the buffer will be recreated every time, I cross a 
>>> screen) 2) Create a map which will cache the buffers (say, for 1 and 
>>> 2 scale factors for double screen env). I think the second approach 
>>> is better.
>>>
>>> > Probably it will be better to disable doublebuffering and 
>>> SwingPaintEventDispatcher completely(see swing.showFromDoubleBuffer)?
>>>
>>> Why? If we can manage it for JLF/SwingNode, why should we downgrade 
>>> performance?
>> You have 1 buffere on fx side, buffer in SwingNode, buffer in 
>> jviewport, and swing itself use double buffering.
>>>
>>>> Actually I still do not understand why JViewport works in the 
>>>> standalone application.
>>>
>>> Could you please clarify, I don't understand this question...
>> I see that JViewport use Offscreen image as a double buffer, is that 
>> true that it use it in the standalone swing application? If yes why 
>> it works.
>>>
>>>>
>>>> One unrelated question. Did you try to use CALayer's embedding 
>>>> mechanics? Probably it is possible to add CAlayer which is used by 
>>>> the swing and awt to the FX CAlayer? In this case all problems 
>>>> related to the painting goes away and it will be much faster, only 
>>>> events should be generated(The same way our plugin works see 
>>>> CPlatformEmbeddedFrame).
>>>
>>> This is in plans (interop "unified rendering" for d3d, ogl). At 
>>> least, there are plans to investigate it....
>> I guess it could be simpler than the current solution, because 
>> different layers will have different context which will be used by 
>> the swing and fx independently.
>>>
>>> Thanks for the review!
>>>
>>> Anton.
>>>
>>>>
>>>> On 10.12.2013 18:22, Anton V. Tarasov wrote:
>>>>> Hi Jim, Sergey and All,
>>>>>
>>>>> Please review the fix that adds support of Retina displays to 
>>>>> JLightweightFrame (which javafx SwingNode is based on).
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>>>>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>>>>
>>>>> (After the fix goes into jdk9 it should be ported to 8u20 as well, 
>>>>> because the functionality is essential for SwingNode.)
>>>>>
>>>>> The general idea of the fix is as follows.
>>>>>
>>>>> A BufferedImage instance, being created in the context in which 
>>>>> the scale factor is determined and is different from one, is 
>>>>> automatically created with appropriately extended size. The image 
>>>>> itself becomes a scaled image (a "scale" private field is set on 
>>>>> it). By the "context" I mean the circumstances where the 
>>>>> BufferedImage is related to a JLightweightFrame, a 
>>>>> GraphicsConfiguration, a SurfaceData, or a GraphicsDevice which 
>>>>> determine the scale factor.
>>>>>
>>>>> Here are the related changes:
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
>>>>> (the resizeBuffer method)
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>>>>>
>>>>> The "scale" value of a BufferedImage is used when 1) 
>>>>> BufferedImageGraphicsConfig is created 2) 
>>>>> BufImgSurfaceData.getDefaultScale() is called:
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>>
>>>>> The former is used in the 
>>>>> GraphicsConfiguration.createCompatibleImage() calls, and the 
>>>>> latter is used in SurfaceManager.getImageScale(Image):
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>>>>>
>>>>> A scaled BufferedImage is supported by the 
>>>>> SunGraphics2D.drawImage() primitives. Here's the pattern of how 
>>>>> the image may be created and drawn:
>>>>>
>>>>> int scale = <get the scale factor from the context>;
>>>>> BufferedImage img = new BufferedImage(width * scale, height * 
>>>>> scale, ...);
>>>>> img.setScale(scale); // an accessor is currently used instead
>>>>> <...>
>>>>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
>>>>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a 
>>>>> specified rect
>>>>>
>>>>> In the first case, if the BufferedImage is created with an 
>>>>> extended size, the "scale" value of the image matters, it should 
>>>>> be drawn as a HiDPI image.
>>>>> In the second case, if the BufferedImage is created with an 
>>>>> extended size, the "scale" value of the image doesn't matter (it 
>>>>> may not be evidently set) as the image will anyway be scaled from 
>>>>> its physical bounds into provided logical bounds. This all should 
>>>>> (as I suppose) provide backward compatibility for buffered images 
>>>>> that were created in their logical bounds or without setting the 
>>>>> "scale" field. For instance, the 
>>>>> AquaPainter.paintFromSingleCachedImage(...) method creates & draws 
>>>>> an image as follows:
>>>>>
>>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>>> int imgW = bounds.width * scale;
>>>>> int imgH = bounds.height * scale;
>>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>>> <paint into the img>
>>>>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, 
>>>>> null);
>>>>>
>>>>> Here, the img.scale value is not set (I didn't modify this code), 
>>>>> and SunGraphics2D doesn't treat the image as a HiDPI image, 
>>>>> however it is drawn as expected. An alternative way to draw the 
>>>>> image would be:
>>>>>
>>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>>> int imgW = bounds.width * scale;
>>>>> int imgH = bounds.height * scale;
>>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>>> img.setScale(scale);
>>>>> <paint into the img>
>>>>> g.drawImage(img, bounds.x, bounds.y, ...);
>>>>>
>>>>> The result would be the same.
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>>>>>
>>>>> The following changes:
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>>>>>
>>>>> are defined by this logic. Running Swing via JLightweightFrame 
>>>>> (JLF) makes it "display agnostic". Swing is painted to an 
>>>>> off-screen buffer and it's the host (e.g. SwingNode) that renders 
>>>>> the buffer on a particular device. So, the host should detect the 
>>>>> scale of the current display and set it on JLF.
>>>> Does it mean that all methods related to the 
>>>> Component.getLocationOnScreen() does not work?
>>>>>
>>>>> However, AWT in order to paint to a volatile image requires 
>>>>> CGraphicsDevice and CGLSurfaceData to be created. By default AWT 
>>>>> creates CGraphicsDevice instances matching all the detected 
>>>>> display devices (CGraphicsEnvironment.initDevices()). But, as JLF 
>>>>> doesn't have any platform window behind it, AWT can't match JLF to 
>>>>> the exact device it's currently displayed on.
>>>> Why? You can try to check it youseft via 
>>>> CGLGraphicsConfig.getBounds()+Peer.getBounds();
>>>>> So, on the one hand, AWT doesn't know which device is current and 
>>>>> what is the current scale (the host passes this value), but from 
>>>>> the other hand, AWT has a list of all the CGraphicsDevice instances.
>>>>>
>>>>> I tried to leverage from that fact. The 
>>>>> CPlatformLWView.getGraphicsDevice() method takes the current scale 
>>>>> from the JLF instance, and then tries to match it to an existent 
>>>>> device from the list. In case it can't find a device with the 
>>>>> specified scale (which should not actually happen, unless the host 
>>>>> passes an arbitrary scale value, which is not the case for 
>>>>> SwingNode) it takes a default device and changes its scale 
>>>>> forcedly. I'm not sure if I should create a new dummy device 
>>>>> instance instead. The scale factor of the device (which is then 
>>>>> propagated to CGLSurfaceData on its creation) is the only info 
>>>>> that JLF will take from the device to create a scaled volatile image.
>>>>>
>>>>> The following changes:
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>>>>>
>>>>> were made to map a backing store image to a scale factor.
>>>>>
>>>>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) 
>>>>> on scrolling. The method was not implemented for a graphics with a 
>>>>> scale transform and a BufImgSurfaceData (it threw exceptions). I 
>>>>> took that code, copied it to the BufImgSurfaceData.copyArea(...) 
>>>>> and added a general translation for the coords:
>>>>>
>>>>> - 
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>>
>>>>> It works, but I'm not sure the implementation is eligible (I don't 
>>>>> know the details of the Blit class, at least it warns not to use 
>>>>> the same source and dest).
>>>>>
>>>>> The rest of the changes (not covered here) should be clear.
>>>>>
>>>>> Testing:
>>>>>
>>>>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & 
>>>>> embedded into SwingNode [1]).
>>>>> - Testing both Nimbus and Aqua L&F.
>>>>> - Setting swing.volatileImageBufferEnabled=false/true for all 
>>>>> combinations.
>>>>>
>>>>> Currently, I see no regressions and no visual issues comparing a 
>>>>> standalone mode and a SwingSet mode.
>>>>>
>>>>> At the end, I suspect there may be some intersection b/w this fix 
>>>>> and the fix which introduced MultiResolutionToolkitImage. 
>>>>> Unfortunately, I didn't yet read that review saga... Please tell 
>>>>> me if I should incorporate anything from that fix.
>>>>>
>>>>> Thanks,
>>>>> Anton.
>>>>>
>>>>> [1] There's a SwingSet part of the fix which I'm going to post to 
>>>>> the jfx alias separately.
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From james.graham at oracle.com  Thu Dec 12 11:27:13 2013
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 12 Dec 2013 11:27:13 -0800
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52AA0C32.504@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
Message-ID: <52AA0E11.3060706@oracle.com>



On 12/12/13 11:19 AM, Sergey Bylokhov wrote:
> On 12/12/13 7:16 PM, Anton V. Tarasov wrote:
>> On 11.12.2013 14:38, Sergey Bylokhov wrote:
>>> On 11.12.2013 13:18, Anton V. Tarasov wrote:
>>>> With Nimus, at some moment, when the
>>>> nimbus.AbstractRegionPainter.paint(Graphics2D g, ...) method is
>>>> called it is passed the graphics instance created by
>>>> JLF.createGraphics() which derives it from the JLF's root buffered
>>>> image. Then, somewhere up the stack the method calls for
>>>> getImage(g.getDeviceConfiguration(),..),
>>> Yes, correct. But you can created double sized surface for you
>>> buffered image(in the same way as it was done for volatile) and
>>> provide correct DeviceConfiguration for it.
>>
>> Sergey,
>>
>> It seems I didn't yet understand you. Could you please clarify? What
>> "double sized" surface do you mean for a BufferedImage, and what do
>> you mean by the "correct" DeviceConfiguration for it? (I can't put a
>> CGLSurfaceData into a BufferedImage).
> When retina support was added to the volatile images, there were the
> same problems with the mixing of "logical" and "real" sizes. And
> volatile image(logical view) was not changed, but its surface was. When
> the volatile image is created we check the native scale and use it to
> create the surface, then in SG2D we take the difference between an image
> and its surface into account.
> Why we cannot do the same thing for OffscreenImage? We control when it
> is created, we control when its used, offscrenimage is created for the
> component-> we know what GraphicConfigs should be used for the scale
> checking. Probably we can reuse/extract some code which was added to the
> cglsurface?

The only real difference here is that BufferedImages have multiple 
definitions of width and height.  For VolatileImage objects there is no 
view of the pixels so the dimensions are the layout size and the 
expected renderable area and the returned graphics is pre-scaled.  For 
BufferedImage we can do all of that, but the dimensions have the added 
implication that they define the valid range of values for getRGB(x, y) 
and grabbing the rasters/data buffers/arrays and digging out pixels 
manually.

If it were just getRGB(x, y) we could simply do a 2x2 average of 
underlying pixels to return an RGB value, but I don't think there is any 
amount of workaround that we can apply to make the digging out of the 
rasters and storage arrays work for those who manually access pixels...  :(

			...jim

From anthony.petrov at oracle.com  Thu Dec 12 12:30:49 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 13 Dec 2013 00:30:49 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029263, ,
 The user's default browser can not launch after we click the button,
 and there is an IOException shown in the log txt (java.io.IOException)
In-Reply-To: <52A9EC7C.6000200@oracle.com>
References: <52A9EC7C.6000200@oracle.com>
Message-ID: <52AA1CF9.8010203@oracle.com>

Hi Alexander,

1. Please add your evaluation to the bug report.

2. In gtk2_interface.c: can we declare the i variable somewhere closer 
to where it is used? What's the point with all these forward 
declarations? We don't compile with C89, do we?

3. Checking for http: to enable the BROWSE action looks reasonable to 
me. And I suggest to check for the mailto: scheme separately, so that 
the MAIL action is only enabled if it's supported.

4.
>  534 #ifdef __solaris__
>  535             update_supported_actions(env);
>  536 #endif

Have you tested this on Linux with your patch applied? How is the list 
of supported actions supposed to be populated on that platform?

5. In XDesktopPeer.java: please move the comment at line 51 above the 
field that it describes.

--
best regards,
Anthony

On 12/12/2013 09:03 PM, Alexander Zvegintsev wrote:
> Hello AWT team,
>
> Please review fix
> http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.00/
> for
> https://bugs.openjdk.java.net/browse/JDK-8029263
>
> This issue can be observed on Solaris 11 (sparcv9 or x86_64).
>
> gtk_show_uri() documentation[1] says:
>> The uri must be of a form understood by GIO (i.e. you need to install
>> gvfs to get support for uri schemes such as http:// or ftp://, as only
>> local files are handled by GIO itself).
> However it looks like that Solaris 11 supports gvfs for 32-bit
> applications only by default. gtk_show_uri() returns "Operation not
> supported" error message  for 64-bit applications
> for schemes other than file://.
>
> Since b110 we don't have 32-bit JDK for Solaris anymore, so in most
> cases only an OPEN action is available(file://).
>
> Currently I am unable to find any robust way to determine do we have
> full gvfs support to handle URIs like mail:, http:// or not.
>
> We can use g_vfs_get_supported_uri_schemes()[2] and assume that we have
> full gvfs support if http:// scheme is present.
> But this function depends on a DBUS_SESSION_BUS_ADDRESS environment
> variable, which can be stripped off in some tests
> (in this case only file:// scheme will be returned).
>
>
> Old gnome_url_show() will not work  too due to lack of 64-bit
> libgnomevfs-2.0 library.
>
>
>
> [1]
> https://developer.gnome.org/gtk2/stable/gtk2-Filesystem-utilities.html#gtk-show-uri
> [2]
> https://developer.gnome.org/gio/stable/GVfs.html#g-vfs-get-supported-uri-schemes
>
>
> --
> Thanks,
>
> Alexander.
>

From alexander.zvegintsev at oracle.com  Thu Dec 12 13:32:26 2013
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 13 Dec 2013 01:32:26 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029263, ,
 The user's default browser can not launch after we click the button,
 and there is an IOException shown in the log txt (java.io.IOException)
In-Reply-To: <52AA1CF9.8010203@oracle.com>
References: <52A9EC7C.6000200@oracle.com> <52AA1CF9.8010203@oracle.com>
Message-ID: <52AA2B6A.902@oracle.com>

Hi Anthony,

Please see inline
13.12.2013 0:30, Anthony Petrov wrote:
> Hi Alexander,
>
> 1. Please add your evaluation to the bug report.
>
> 2. In gtk2_interface.c: can we declare the i variable somewhere closer 
> to where it is used? What's the point with all these forward 
> declarations? We don't compile with C89, do we?
Sure.
>
> 3. Checking for http: to enable the BROWSE action looks reasonable to 
> me. And I suggest to check for the mailto: scheme separately, so that 
> the MAIL action is only enabled if it's supported.
 From my testing if we have http scheme in this list(list of supported 
URI schemes) we are able to open https://, ftp:// and mail: URIs (BTW 
there is no https:// and mail: schemes in this list, and mail: is not 
actually a valid URI).
If we have only file scheme in this list all other URIs will not work 
and gtk_show_uri() will return "Operation not supported" message for 
such URIs.
So this part of code is just an educated guess to check is gvfs 
supported or not. It may be fragile(it depends on environment variables 
set) but it is better then nothing.

Most of machines with Solaris 11 installed which I tested always return 
only file scheme in this list for 64-bit, so in general case we will 
support only an OPEN action.

> 4.
>>  534 #ifdef __solaris__
>>  535             update_supported_actions(env);
>>  536 #endif
>
> Have you tested this on Linux with your patch applied? How is the list 
> of supported actions supposed to be populated on that platform?
Linux behaves as before the fix:
For Linux this list is already populated in initializer and remains 
untouched from native:
> +    private static final List<Action> supportedActions
> +            = new ArrayList<>(Arrays.asList(Action.OPEN, Action.MAIL, Action.BROWSE))
The list of supported actions is the same as before the patch (OPEN, 
MAIL, BROWSE). I tested this on OEL 5, 6, Ubuntu 13.04 all works as 
expected.
So only for Solaris we clear this list and populate it from a native.

>
> 5. In XDesktopPeer.java: please move the comment at line 51 above the 
> field that it describes.

--
Thanks,
Alexander.
> -- 
> best regards,
> Anthony
>
> On 12/12/2013 09:03 PM, Alexander Zvegintsev wrote:
>> Hello AWT team,
>>
>> Please review fix
>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.00/
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8029263
>>
>> This issue can be observed on Solaris 11 (sparcv9 or x86_64).
>>
>> gtk_show_uri() documentation[1] says:
>>> The uri must be of a form understood by GIO (i.e. you need to install
>>> gvfs to get support for uri schemes such as http:// or ftp://, as only
>>> local files are handled by GIO itself).
>> However it looks like that Solaris 11 supports gvfs for 32-bit
>> applications only by default. gtk_show_uri() returns "Operation not
>> supported" error message  for 64-bit applications
>> for schemes other than file://.
>>
>> Since b110 we don't have 32-bit JDK for Solaris anymore, so in most
>> cases only an OPEN action is available(file://).
>>
>> Currently I am unable to find any robust way to determine do we have
>> full gvfs support to handle URIs like mail:, http:// or not.
>>
>> We can use g_vfs_get_supported_uri_schemes()[2] and assume that we have
>> full gvfs support if http:// scheme is present.
>> But this function depends on a DBUS_SESSION_BUS_ADDRESS environment
>> variable, which can be stripped off in some tests
>> (in this case only file:// scheme will be returned).
>>
>>
>> Old gnome_url_show() will not work  too due to lack of 64-bit
>> libgnomevfs-2.0 library.
>>
>>
>>
>> [1]
>> https://developer.gnome.org/gtk2/stable/gtk2-Filesystem-utilities.html#gtk-show-uri 
>>
>> [2]
>> https://developer.gnome.org/gio/stable/GVfs.html#g-vfs-get-supported-uri-schemes 
>>
>>
>>
>> -- 
>> Thanks,
>>
>> Alexander.
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131213/6305c080/attachment.html 

From anthony.petrov at oracle.com  Thu Dec 12 13:49:24 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 13 Dec 2013 01:49:24 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029263, ,
 The user's default browser can not launch after we click the button,
 and there is an IOException shown in the log txt (java.io.IOException)
In-Reply-To: <52AA2B6A.902@oracle.com>
References: <52A9EC7C.6000200@oracle.com> <52AA1CF9.8010203@oracle.com>
	<52AA2B6A.902@oracle.com>
Message-ID: <52AA2F64.8000101@oracle.com>

Thanks for the clarifications, Alexander. Looking forward to an updated 
webrev.

As for #4, I understand that we want to minimize the risk for this fix 
now, so late in the release. And I'm fine with that. However, I still 
suggest to file an RFE targeted for 9 to enable this behavior for Linux 
as well. I reckon a Linux system can also be configured not to support 
additional URI schemes, so in general, I see no reason to skip this 
check on Linux.

A follow-up question regarding #3: do you know which specific 
library/software module needs to be installed in order to support those 
other URI schemes? It might be useful to add this info to the bug report 
so that people know what they need to install additionally if they need 
to access such URIs.

--
best regards,
Anthony

On 12/13/2013 01:32 AM, Alexander Zvegintsev wrote:
> Hi Anthony,
>
> Please see inline
> 13.12.2013 0:30, Anthony Petrov wrote:
>> Hi Alexander,
>>
>> 1. Please add your evaluation to the bug report.
>>
>> 2. In gtk2_interface.c: can we declare the i variable somewhere closer
>> to where it is used? What's the point with all these forward
>> declarations? We don't compile with C89, do we?
> Sure.
>>
>> 3. Checking for http: to enable the BROWSE action looks reasonable to
>> me. And I suggest to check for the mailto: scheme separately, so that
>> the MAIL action is only enabled if it's supported.
>  From my testing if we have http scheme in this list(list of supported
> URI schemes) we are able to open https://, ftp:// and mail: URIs (BTW
> there is no https:// and mail: schemes in this list, and mail: is not
> actually a valid URI).
> If we have only file scheme in this list all other URIs will not work
> and gtk_show_uri() will return "Operation not supported" message for
> such URIs.
> So this part of code is just an educated guess to check is gvfs
> supported or not. It may be fragile(it depends on environment variables
> set) but it is better then nothing.
>
> Most of machines with Solaris 11 installed which I tested always return
> only file scheme in this list for 64-bit, so in general case we will
> support only an OPEN action.
>
>> 4.
>>>  534 #ifdef __solaris__
>>>  535             update_supported_actions(env);
>>>  536 #endif
>>
>> Have you tested this on Linux with your patch applied? How is the list
>> of supported actions supposed to be populated on that platform?
> Linux behaves as before the fix:
> For Linux this list is already populated in initializer and remains
> untouched from native:
>> +    private static final List<Action> supportedActions
>> +            = new ArrayList<>(Arrays.asList(Action.OPEN, Action.MAIL, Action.BROWSE))
> The list of supported actions is the same as before the patch (OPEN,
> MAIL, BROWSE). I tested this on OEL 5, 6, Ubuntu 13.04 all works as
> expected.
> So only for Solaris we clear this list and populate it from a native.
>
>>
>> 5. In XDesktopPeer.java: please move the comment at line 51 above the
>> field that it describes.
>
> --
> Thanks,
> Alexander.
>> --
>> best regards,
>> Anthony
>>
>> On 12/12/2013 09:03 PM, Alexander Zvegintsev wrote:
>>> Hello AWT team,
>>>
>>> Please review fix
>>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.00/
>>> for
>>> https://bugs.openjdk.java.net/browse/JDK-8029263
>>>
>>> This issue can be observed on Solaris 11 (sparcv9 or x86_64).
>>>
>>> gtk_show_uri() documentation[1] says:
>>>> The uri must be of a form understood by GIO (i.e. you need to install
>>>> gvfs to get support for uri schemes such as http:// or ftp://, as only
>>>> local files are handled by GIO itself).
>>> However it looks like that Solaris 11 supports gvfs for 32-bit
>>> applications only by default. gtk_show_uri() returns "Operation not
>>> supported" error message  for 64-bit applications
>>> for schemes other than file://.
>>>
>>> Since b110 we don't have 32-bit JDK for Solaris anymore, so in most
>>> cases only an OPEN action is available(file://).
>>>
>>> Currently I am unable to find any robust way to determine do we have
>>> full gvfs support to handle URIs like mail:, http:// or not.
>>>
>>> We can use g_vfs_get_supported_uri_schemes()[2] and assume that we have
>>> full gvfs support if http:// scheme is present.
>>> But this function depends on a DBUS_SESSION_BUS_ADDRESS environment
>>> variable, which can be stripped off in some tests
>>> (in this case only file:// scheme will be returned).
>>>
>>>
>>> Old gnome_url_show() will not work  too due to lack of 64-bit
>>> libgnomevfs-2.0 library.
>>>
>>>
>>>
>>> [1]
>>> https://developer.gnome.org/gtk2/stable/gtk2-Filesystem-utilities.html#gtk-show-uri
>>>
>>> [2]
>>> https://developer.gnome.org/gio/stable/GVfs.html#g-vfs-get-supported-uri-schemes
>>>
>>>
>>>
>>> --
>>> Thanks,
>>>
>>> Alexander.
>>>
>

From anthony.petrov at oracle.com  Thu Dec 12 14:05:22 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 13 Dec 2013 02:05:22 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A9D3BA.5050903@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A89175.5030704@oracle.com> <52A8A0FA.30804@oracle.com>
	<52A9D3BA.5050903@oracle.com>
Message-ID: <52AA3322.3020302@oracle.com>

On 12/12/2013 07:18 PM, Anton V. Tarasov wrote:
> [cc'ing to j2d alias]
>
> On 11.12.2013 21:29, Sergey Bylokhov wrote:
>> On 11.12.2013 20:23, Anton V. Tarasov wrote:
>>>
>>>>> - CGraphicsDevice
>>>>>
>>>>> This setter is only called from
>>>>> CPlatformLWView.getGraphicsDevice(). I've explained it in my
>>>>> previous message. It's needed to change the scale factor of the
>>>>> default device when no device in the list fits. The case is
>>>>> impossible with the current implementation of SwingNode (which only
>>>>> passes JLF a scale factor matching one of a real display), however,
>>>>> as JLF provides a generic lw embedding API, I should cover that
>>>>> case as well.
>> Not sure that matching fx to awt devices via scale is not a good idea.
>> Note that it is expected that fields in the CGraphicsDevice chenges
>> only if the screen is changed/added/removed.
>> Probably Instead of notifyScaleFactorChanged you can notify about
>> screens changes?
>
> JLightweightFrame is a toplevel that paints its content to an off-screen
> buffer, so it is conceptually not associated with any screen. The host
> (SwingNode) application communicates with JLF on an API level.
> Introducing a notion of a "screen" to the API doesn't correlate with the
> JLF's concept, imho.

Why? IMO, this would simplify the code significantly as Swing is already 
HiDPI-aware. It only needs to be able to determine the scale factor of a 
screen device its top-level is on. Of course, the code in the JLF 
implementation needs to know that too, so that it's able to create a BI 
of appropriate dimensions. So making JLF tracking its current 
GraphicsConfiguration looks like a reasonable idea to me. As Sergey 
suggested, this could be done easily by checking intersections between 
JLF's bounds in screen coordinates and the bounds of all the available 
GraphicsDevices.

--
best regards,
Anthony



>
> Why I'm still picking the device is because this seemed to me an
> acceptable approach that integrates with LWAWT smoothly. But I agree
> with you that matching the device via a scale factor is not a good idea.
> Theoretically I can pickup wrong device, but even then it won't change
> anything for me. I just need a device with the requested scale.
>
> What do you think then if we always use default device, for which we
> will change the scale?
>
>>
>>>>>
>>>>> - OffScreenImage
>>>>>
>>>>> I've put a BufferedImage accessor there, nothing else. I didn't
>>>>> find a better place... (I'd appreciate showing it).
>>>>>
>>>>> - JViewport, RepaintManager
>>>>>
>>>>> These classes create a double buffer. In case the buffer is backed
>>>>> by a BufferedImage, it will be created with the current scale
>>>>> factor set. The buffer won't be changed when a user moves the host
>>>>> window across multiple screens with different scales. I see two
>>>>> options. 1) Drop the double buffer reference every time the scale
>>>>> changes (in that case, the buffer will be recreated every time, I
>>>>> cross a screen) 2) Create a map which will cache the buffers (say,
>>>>> for 1 and 2 scale factors for double screen env). I think the
>>>>> second approach is better.
>>>>>
>>>>> > Probably it will be better to disable doublebuffering and
>>>>> SwingPaintEventDispatcher completely(see swing.showFromDoubleBuffer)?
>>>>>
>>>>> Why? If we can manage it for JLF/SwingNode, why should we downgrade
>>>>> performance?
>>>> You have 1 buffere on fx side, buffer in SwingNode, buffer in
>>>> jviewport, and swing itself use double buffering.
>>>
>>> Ok, this is a good point. But still I can't simply switch off double
>>> buffering w/o doing any benchmarking. SwingNode perf analisys &
>>> improvement is in plans...
>> It would be good to know results of the benchmarks.
>
> Ok, but as this is a separate task I'd like to know what we're fighting
> for. Is the goal to avoid creating BufferedImage's at all?
>
>>> So far, unless it requires lots of coding (but it doesn't) I'd prefer
>>> to keep that option working.
>>>
>>>>>
>>>>>> Actually I still do not understand why JViewport works in the
>>>>>> standalone application.
>>>>>
>>>>> Could you please clarify, I don't understand this question...
>>>> I see that JViewport use Offscreen image as a double buffer, is that
>>>> true that it use it in the standalone swing application? If yes why
>>>> it works.
>>>
>>> JViewport.paint() is not called with its default blit mode, and so it
>>> doesn't actually use an OffscreenBuffer. For JLF, the mode is set to
>>> backing store. If I set the backing store mode in standalone swing,
>>> JViewport stops scaling on Retina. So, it didn't work before.
>> Is this related to the JDK-8023966?
>
> Right.
>
> Thanks,
> Anton.
>
>>>
>>>
>>> Thanks,
>>> Anton.
>>>
>>>>
>>>>>
>>>>> Thanks for the review!
>>>>>
>>>>> Anton.
>>>>>
>>>>>>
>>>>>> On 10.12.2013 18:22, Anton V. Tarasov wrote:
>>>>>>> Hi Jim, Sergey and All,
>>>>>>>
>>>>>>> Please review the fix that adds support of Retina displays to
>>>>>>> JLightweightFrame (which javafx SwingNode is based on).
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>>>>>>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>>>>>>
>>>>>>> (After the fix goes into jdk9 it should be ported to 8u20 as
>>>>>>> well, because the functionality is essential for SwingNode.)
>>>>>>>
>>>>>>> The general idea of the fix is as follows.
>>>>>>>
>>>>>>> A BufferedImage instance, being created in the context in which
>>>>>>> the scale factor is determined and is different from one, is
>>>>>>> automatically created with appropriately extended size. The image
>>>>>>> itself becomes a scaled image (a "scale" private field is set on
>>>>>>> it). By the "context" I mean the circumstances where the
>>>>>>> BufferedImage is related to a JLightweightFrame, a
>>>>>>> GraphicsConfiguration, a SurfaceData, or a GraphicsDevice which
>>>>>>> determine the scale factor.
>>>>>>>
>>>>>>> Here are the related changes:
>>>>>>>
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
>>>>>>>
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
>>>>>>>
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html
>>>>>>> (the resizeBuffer method)
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
>>>>>>>
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>>>>>
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>>>>>>>
>>>>>>>
>>>>>>> The "scale" value of a BufferedImage is used when 1)
>>>>>>> BufferedImageGraphicsConfig is created 2)
>>>>>>> BufImgSurfaceData.getDefaultScale() is called:
>>>>>>>
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
>>>>>>>
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>>>>
>>>>>>>
>>>>>>> The former is used in the
>>>>>>> GraphicsConfiguration.createCompatibleImage() calls, and the
>>>>>>> latter is used in SurfaceManager.getImageScale(Image):
>>>>>>>
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>>>>>>>
>>>>>>>
>>>>>>> A scaled BufferedImage is supported by the
>>>>>>> SunGraphics2D.drawImage() primitives. Here's the pattern of how
>>>>>>> the image may be created and drawn:
>>>>>>>
>>>>>>> int scale = <get the scale factor from the context>;
>>>>>>> BufferedImage img = new BufferedImage(width * scale, height *
>>>>>>> scale, ...);
>>>>>>> img.setScale(scale); // an accessor is currently used instead
>>>>>>> <...>
>>>>>>> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
>>>>>>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a
>>>>>>> specified rect
>>>>>>>
>>>>>>> In the first case, if the BufferedImage is created with an
>>>>>>> extended size, the "scale" value of the image matters, it should
>>>>>>> be drawn as a HiDPI image.
>>>>>>> In the second case, if the BufferedImage is created with an
>>>>>>> extended size, the "scale" value of the image doesn't matter (it
>>>>>>> may not be evidently set) as the image will anyway be scaled from
>>>>>>> its physical bounds into provided logical bounds. This all should
>>>>>>> (as I suppose) provide backward compatibility for buffered images
>>>>>>> that were created in their logical bounds or without setting the
>>>>>>> "scale" field. For instance, the
>>>>>>> AquaPainter.paintFromSingleCachedImage(...) method creates &
>>>>>>> draws an image as follows:
>>>>>>>
>>>>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>>>>> int imgW = bounds.width * scale;
>>>>>>> int imgH = bounds.height * scale;
>>>>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>>>>> <paint into the img>
>>>>>>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height,
>>>>>>> null);
>>>>>>>
>>>>>>> Here, the img.scale value is not set (I didn't modify this code),
>>>>>>> and SunGraphics2D doesn't treat the image as a HiDPI image,
>>>>>>> however it is drawn as expected. An alternative way to draw the
>>>>>>> image would be:
>>>>>>>
>>>>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>>>>> int imgW = bounds.width * scale;
>>>>>>> int imgH = bounds.height * scale;
>>>>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>>>>> img.setScale(scale);
>>>>>>> <paint into the img>
>>>>>>> g.drawImage(img, bounds.x, bounds.y, ...);
>>>>>>>
>>>>>>> The result would be the same.
>>>>>>>
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>>>>>>>
>>>>>>>
>>>>>>> The following changes:
>>>>>>>
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>>>>>>>
>>>>>>>
>>>>>>> are defined by this logic. Running Swing via JLightweightFrame
>>>>>>> (JLF) makes it "display agnostic". Swing is painted to an
>>>>>>> off-screen buffer and it's the host (e.g. SwingNode) that renders
>>>>>>> the buffer on a particular device. So, the host should detect the
>>>>>>> scale of the current display and set it on JLF.
>>>>>> Does it mean that all methods related to the
>>>>>> Component.getLocationOnScreen() does not work?
>>>>>>>
>>>>>>> However, AWT in order to paint to a volatile image requires
>>>>>>> CGraphicsDevice and CGLSurfaceData to be created. By default AWT
>>>>>>> creates CGraphicsDevice instances matching all the detected
>>>>>>> display devices (CGraphicsEnvironment.initDevices()). But, as JLF
>>>>>>> doesn't have any platform window behind it, AWT can't match JLF
>>>>>>> to the exact device it's currently displayed on.
>>>>>> Why? You can try to check it youseft via
>>>>>> CGLGraphicsConfig.getBounds()+Peer.getBounds();
>>>>>>> So, on the one hand, AWT doesn't know which device is current and
>>>>>>> what is the current scale (the host passes this value), but from
>>>>>>> the other hand, AWT has a list of all the CGraphicsDevice instances.
>>>>>>>
>>>>>>> I tried to leverage from that fact. The
>>>>>>> CPlatformLWView.getGraphicsDevice() method takes the current
>>>>>>> scale from the JLF instance, and then tries to match it to an
>>>>>>> existent device from the list. In case it can't find a device
>>>>>>> with the specified scale (which should not actually happen,
>>>>>>> unless the host passes an arbitrary scale value, which is not the
>>>>>>> case for SwingNode) it takes a default device and changes its
>>>>>>> scale forcedly. I'm not sure if I should create a new dummy
>>>>>>> device instance instead. The scale factor of the device (which is
>>>>>>> then propagated to CGLSurfaceData on its creation) is the only
>>>>>>> info that JLF will take from the device to create a scaled
>>>>>>> volatile image.
>>>>>>>
>>>>>>> The following changes:
>>>>>>>
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
>>>>>>>
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>>>>>>>
>>>>>>>
>>>>>>> were made to map a backing store image to a scale factor.
>>>>>>>
>>>>>>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...)
>>>>>>> on scrolling. The method was not implemented for a graphics with
>>>>>>> a scale transform and a BufImgSurfaceData (it threw exceptions).
>>>>>>> I took that code, copied it to the
>>>>>>> BufImgSurfaceData.copyArea(...) and added a general translation
>>>>>>> for the coords:
>>>>>>>
>>>>>>> -
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>>>>>>>
>>>>>>>
>>>>>>> It works, but I'm not sure the implementation is eligible (I
>>>>>>> don't know the details of the Blit class, at least it warns not
>>>>>>> to use the same source and dest).
>>>>>>>
>>>>>>> The rest of the changes (not covered here) should be clear.
>>>>>>>
>>>>>>> Testing:
>>>>>>>
>>>>>>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode
>>>>>>> & embedded into SwingNode [1]).
>>>>>>> - Testing both Nimbus and Aqua L&F.
>>>>>>> - Setting swing.volatileImageBufferEnabled=false/true for all
>>>>>>> combinations.
>>>>>>>
>>>>>>> Currently, I see no regressions and no visual issues comparing a
>>>>>>> standalone mode and a SwingSet mode.
>>>>>>>
>>>>>>> At the end, I suspect there may be some intersection b/w this fix
>>>>>>> and the fix which introduced MultiResolutionToolkitImage.
>>>>>>> Unfortunately, I didn't yet read that review saga... Please tell
>>>>>>> me if I should incorporate anything from that fix.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Anton.
>>>>>>>
>>>>>>> [1] There's a SwingSet part of the fix which I'm going to post to
>>>>>>> the jfx alias separately.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

From Sergey.Bylokhov at oracle.com  Thu Dec 12 14:33:06 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 13 Dec 2013 02:33:06 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52AA0E11.3060706@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com>
Message-ID: <52AA39A2.4060503@oracle.com>

On 12/12/13 11:27 PM, Jim Graham wrote:
>
>
> On 12/12/13 11:19 AM, Sergey Bylokhov wrote:
>> On 12/12/13 7:16 PM, Anton V. Tarasov wrote:
>>> On 11.12.2013 14:38, Sergey Bylokhov wrote:
>>>> On 11.12.2013 13:18, Anton V. Tarasov wrote:
>>>>> With Nimus, at some moment, when the
>>>>> nimbus.AbstractRegionPainter.paint(Graphics2D g, ...) method is
>>>>> called it is passed the graphics instance created by
>>>>> JLF.createGraphics() which derives it from the JLF's root buffered
>>>>> image. Then, somewhere up the stack the method calls for
>>>>> getImage(g.getDeviceConfiguration(),..),
>>>> Yes, correct. But you can created double sized surface for you
>>>> buffered image(in the same way as it was done for volatile) and
>>>> provide correct DeviceConfiguration for it.
>>>
>>> Sergey,
>>>
>>> It seems I didn't yet understand you. Could you please clarify? What
>>> "double sized" surface do you mean for a BufferedImage, and what do
>>> you mean by the "correct" DeviceConfiguration for it? (I can't put a
>>> CGLSurfaceData into a BufferedImage).
>> When retina support was added to the volatile images, there were the
>> same problems with the mixing of "logical" and "real" sizes. And
>> volatile image(logical view) was not changed, but its surface was. When
>> the volatile image is created we check the native scale and use it to
>> create the surface, then in SG2D we take the difference between an image
>> and its surface into account.
>> Why we cannot do the same thing for OffscreenImage? We control when it
>> is created, we control when its used, offscrenimage is created for the
>> component-> we know what GraphicConfigs should be used for the scale
>> checking. Probably we can reuse/extract some code which was added to the
>> cglsurface?
>
> The only real difference here is that BufferedImages have multiple 
> definitions of width and height.  For VolatileImage objects there is 
> no view of the pixels so the dimensions are the layout size and the 
> expected renderable area and the returned graphics is pre-scaled.  For 
> BufferedImage we can do all of that, but the dimensions have the added 
> implication that they define the valid range of values for getRGB(x, 
> y) and grabbing the rasters/data buffers/arrays and digging out pixels 
> manually.
>
> If it were just getRGB(x, y) we could simply do a 2x2 average of 
> underlying pixels to return an RGB value, but I don't think there is 
> any amount of workaround that we can apply to make the digging out of 
> the rasters and storage arrays work for those who manually access 
> pixels...  :(
But I am talking about OffScreenImage(or we can add new one), which is 
not public so we can try to block/change operations in our code. Not 
sure that our backbuffers leaked to the users.

>
>             ...jim


-- 
Best regards, Sergey.


From james.graham at oracle.com  Thu Dec 12 14:54:10 2013
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 12 Dec 2013 14:54:10 -0800
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52AA39A2.4060503@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
Message-ID: <52AA3E92.7040302@oracle.com>



On 12/12/13 2:33 PM, Sergey Bylokhov wrote:
> On 12/12/13 11:27 PM, Jim Graham wrote:
>> The only real difference here is that BufferedImages have multiple
>> definitions of width and height.  For VolatileImage objects there is
>> no view of the pixels so the dimensions are the layout size and the
>> expected renderable area and the returned graphics is pre-scaled.  For
>> BufferedImage we can do all of that, but the dimensions have the added
>> implication that they define the valid range of values for getRGB(x,
>> y) and grabbing the rasters/data buffers/arrays and digging out pixels
>> manually.
>>
>> If it were just getRGB(x, y) we could simply do a 2x2 average of
>> underlying pixels to return an RGB value, but I don't think there is
>> any amount of workaround that we can apply to make the digging out of
>> the rasters and storage arrays work for those who manually access
>> pixels...  :(
> But I am talking about OffScreenImage(or we can add new one), which is
> not public so we can try to block/change operations in our code. Not
> sure that our backbuffers leaked to the users.

OffscreenImage is a subclass of BufferedImage so if a developer ever 
gets their hands on it then they may get confused by our use of the 
getWidth/Height.  But, if there is no way for them to get a reference to 
it, then we can play games internally.

This will not help us with the return value of getCompatibleImage(), 
though, which is specified to return a BufferedImage so we are somewhat 
restricted in any use of logical dimensions there.

Also, if we are entirely managing the buffer internally, then we have 
the option to just use a regular BufferedImage.  We don't need any extra 
magic if we render it with drawImage(x, y, w, h) since the "logical" or 
"real" dimensions of the image have no impact on the results there.  If 
it is double-sized then those pixels will fit into the appropriate space 
on the destination without any need to special case them in SG2D...

				...jim

From lana.steuck at oracle.com  Thu Dec 12 21:30:04 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:30:04 +0000
Subject: <AWT Dev> hg: jdk8/awt: 5 new changesets
Message-ID: <20131213053007.5806862C92@hg.openjdk.java.net>

Changeset: 6c9cfee19264
Author:    katleman
Date:      2013-12-04 23:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/6c9cfee19264

Added tag jdk8-b119 for changeset 9e90215673be

! .hgtags

Changeset: c009462c1e92
Author:    erikj
Date:      2013-12-04 12:45 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/c009462c1e92

8027963: Create unlimited policy jars.
Reviewed-by: wetmore, ihse

! common/autoconf/spec.gmk.in

Changeset: f204455b60cc
Author:    lana
Date:      2013-12-05 10:32 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/f204455b60cc

Merge


Changeset: cd3825b29830
Author:    ihse
Date:      2013-12-09 14:43 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/cd3825b29830

8029515: Building multiple configurations fails after removal of old build system
Reviewed-by: erikj

! Makefile
! make/MakeHelpers.gmk

Changeset: 1e1f86d5d4e2
Author:    katleman
Date:      2013-12-12 05:20 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/1e1f86d5d4e2

Added tag jdk8-b120 for changeset cd3825b29830

! .hgtags


From lana.steuck at oracle.com  Thu Dec 12 21:30:07 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:30:07 +0000
Subject: <AWT Dev> hg: jdk8/awt/jaxws: 2 new changesets
Message-ID: <20131213053037.507AC62C95@hg.openjdk.java.net>

Changeset: 6c152deb600d
Author:    katleman
Date:      2013-12-04 23:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/6c152deb600d

Added tag jdk8-b119 for changeset 172b8e056ff2

! .hgtags

Changeset: 32050ab53c8a
Author:    katleman
Date:      2013-12-12 05:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/32050ab53c8a

Added tag jdk8-b120 for changeset 6c152deb600d

! .hgtags


From lana.steuck at oracle.com  Thu Dec 12 21:30:02 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:30:02 +0000
Subject: <AWT Dev> hg: jdk8/awt/corba: 2 new changesets
Message-ID: <20131213053010.9DCB762C93@hg.openjdk.java.net>

Changeset: 53fd772d28c8
Author:    katleman
Date:      2013-12-04 23:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/53fd772d28c8

Added tag jdk8-b119 for changeset 379fc7609beb

! .hgtags

Changeset: a7d3638deb2f
Author:    katleman
Date:      2013-12-12 05:20 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/a7d3638deb2f

Added tag jdk8-b120 for changeset 53fd772d28c8

! .hgtags


From lana.steuck at oracle.com  Thu Dec 12 21:30:07 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:30:07 +0000
Subject: <AWT Dev> hg: jdk8/awt/nashorn: 5 new changesets
Message-ID: <20131213053033.0003862C94@hg.openjdk.java.net>

Changeset: 7fa32e7d755f
Author:    katleman
Date:      2013-12-04 23:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/7fa32e7d755f

Added tag jdk8-b119 for changeset c3343930c73c

! .hgtags

Changeset: e0b4483668a7
Author:    jlaskey
Date:      2013-11-26 11:58 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/e0b4483668a7

8029173: Debugger support doesn't handle ConsString
Reviewed-by: lagergren, hannesw, sundar
Contributed-by: james.laskey at oracle.com

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

Changeset: c14fe3f90616
Author:    sundar
Date:      2013-12-04 14:37 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/c14fe3f90616

Merge


Changeset: 55cbc2d00c93
Author:    lana
Date:      2013-12-05 10:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/55cbc2d00c93

Merge


Changeset: 32631eed0fad
Author:    katleman
Date:      2013-12-12 05:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/32631eed0fad

Added tag jdk8-b120 for changeset 55cbc2d00c93

! .hgtags


From lana.steuck at oracle.com  Thu Dec 12 21:30:07 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:30:07 +0000
Subject: <AWT Dev> hg: jdk8/awt/jaxp: 4 new changesets
Message-ID: <20131213053045.51ACC62C96@hg.openjdk.java.net>

Changeset: 9b4fac40124d
Author:    katleman
Date:      2013-12-04 23:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/9b4fac40124d

Added tag jdk8-b119 for changeset 69a930376c70

! .hgtags

Changeset: aed9ca4d33ec
Author:    joehw
Date:      2013-12-04 00:17 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/aed9ca4d33ec

8027973: Error in the documentation for newFactory method of the javax.xml.stream factories
Reviewed-by: alanb, dfuchs, lancea, rriggs

! src/javax/xml/stream/FactoryFinder.java
! src/javax/xml/stream/XMLEventFactory.java
! src/javax/xml/stream/XMLInputFactory.java
! src/javax/xml/stream/XMLOutputFactory.java

Changeset: 64d8b228a72c
Author:    lana
Date:      2013-12-05 10:32 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/64d8b228a72c

Merge


Changeset: 4045edd35e8b
Author:    katleman
Date:      2013-12-12 05:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/4045edd35e8b

Added tag jdk8-b120 for changeset 64d8b228a72c

! .hgtags


From lana.steuck at oracle.com  Thu Dec 12 21:30:29 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:30:29 +0000
Subject: <AWT Dev> hg: jdk8/awt/langtools: 8 new changesets
Message-ID: <20131213053129.610DF62C97@hg.openjdk.java.net>

Changeset: 1670108bec25
Author:    katleman
Date:      2013-12-04 23:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/1670108bec25

Added tag jdk8-b119 for changeset 43a80d75d06e

! .hgtags

Changeset: a746587a1ff1
Author:    jlahoda
Date:      2013-12-03 18:50 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/a746587a1ff1

8028699: Compiler crash during speculative attribution of annotated type
Summary: Moving the checkForDeclarationAnnotations check into Attr.TypeAnnotationsValidator
Reviewed-by: jjg
Contributed-by: wdietl at gmail.com

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/annotations/typeAnnotations/failures/CheckForDeclAnnoNPE.java
! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.java
! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.out

Changeset: fb8c59cf26c8
Author:    vromero
Date:      2013-12-03 18:13 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/fb8c59cf26c8

8029179: javac produces a compile error for valid boolean expressions
Reviewed-by: jjg, jlahoda

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/T8029179/CompileErrorForValidBooleanExpTest.java

Changeset: 4cb9de4dd420
Author:    bpatel
Date:      2013-12-03 14:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/4cb9de4dd420

8025416: doclet not substituting {@docRoot} in some cases
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! test/com/sun/javadoc/testDocRootLink/TestDocRootLink.java
! test/com/sun/javadoc/testDocRootLink/pkg1/C1.java
! test/com/sun/javadoc/testDocRootLink/pkg1/package.html
! test/com/sun/javadoc/testDocRootLink/pkg2/C2.java
! test/com/sun/javadoc/testDocRootLink/pkg2/package.html

Changeset: 1b69023743be
Author:    lana
Date:      2013-12-03 23:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/1b69023743be

Merge


Changeset: 4a2ed1900428
Author:    mchung
Date:      2013-12-04 15:39 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/4a2ed1900428

8029216: (jdeps) Provide a specific option to report JDK internal APIs
Reviewed-by: alanb

! src/share/classes/com/sun/tools/jdeps/JdepsTask.java
! src/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
! test/tools/jdeps/APIDeps.java

Changeset: b3d7e86a0647
Author:    lana
Date:      2013-12-05 10:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/b3d7e86a0647

Merge


Changeset: afe63d41c699
Author:    katleman
Date:      2013-12-12 05:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/afe63d41c699

Added tag jdk8-b120 for changeset b3d7e86a0647

! .hgtags


From lana.steuck at oracle.com  Thu Dec 12 21:30:40 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:30:40 +0000
Subject: <AWT Dev> hg: jdk8/awt/hotspot: 22 new changesets
Message-ID: <20131213053158.4119762C98@hg.openjdk.java.net>

Changeset: a3dc98dc4d21
Author:    katleman
Date:      2013-12-04 23:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a3dc98dc4d21

Added tag jdk8-b119 for changeset ce42d815dd21

! .hgtags

Changeset: b6b9a5d4cda0
Author:    amurillo
Date:      2013-11-29 11:20 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b6b9a5d4cda0

8029367: new hotspot build - hs25-b62
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 77b028ba548c
Author:    jprovino
Date:      2013-11-19 16:26 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/77b028ba548c

8028396: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE
Summary: Minimal VM doesn't run
Reviewed-by: coleenp, dholmes

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

Changeset: 3fbb71fdc6e5
Author:    vladidan
Date:      2013-12-01 22:35 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3fbb71fdc6e5

Merge


Changeset: 8a42e81e2f9d
Author:    dsamersoff
Date:      2013-11-27 14:26 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8a42e81e2f9d

7050685: jsdbproc64.sh has a typo in the package name
Summary: fixed typeo
Reviewed-by: sla, kmo, sspitsyn

! agent/make/jsdbproc64.sh

Changeset: 6ce6a0d23467
Author:    mgronlun
Date:      2013-12-02 11:42 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6ce6a0d23467

Merge

- test/compiler/jsr292/methodHandleExceptions/C.java
- test/compiler/jsr292/methodHandleExceptions/I.java

Changeset: 7a58803b5069
Author:    acorn
Date:      2013-12-03 08:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7a58803b5069

8026066: ICCE for invokeinterface static
Reviewed-by: coleenp, lfoltan, hseigel

! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! test/TEST.groups
! test/runtime/8024804/RegisterNatives.java

Changeset: 379f11bc04fc
Author:    acorn
Date:      2013-12-03 11:13 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/379f11bc04fc

8028438: static superclass method masks default methods
Reviewed-by: hseigel, lfoltan, coleenp

! src/share/vm/classfile/defaultMethods.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klassVtable.cpp

Changeset: c8c2d6b82499
Author:    sspitsyn
Date:      2013-12-03 15:41 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c8c2d6b82499

8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers
Summary: Fix a race between VMOp_GetCurrentLocation reaching a safepoint and arget thread exiting from Java execution
Reviewed-by: sla, dholmes, dsamersoff
Contributed-by: serguei.spitsyn at oracle.com

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

Changeset: e84d2afb2fb0
Author:    sspitsyn
Date:      2013-12-03 13:56 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e84d2afb2fb0

Merge


Changeset: 55a0da3d420b
Author:    sjohanss
Date:      2013-11-26 14:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/55a0da3d420b

8027675: Full collections with Serial slower in JDK 8 compared to 7u40
Summary: Reduced the number of calls to follow_class_loader and instead marked and pushed the klass holder directly. Also removed unneeded calls to adjust_klass.
Reviewed-by: coleenp, jmasa, mgerdin, tschatzl

! src/share/vm/gc_implementation/shared/markSweep.cpp
! src/share/vm/gc_implementation/shared/markSweep.hpp
! src/share/vm/gc_implementation/shared/markSweep.inline.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceMirrorKlass.cpp
! src/share/vm/oops/objArrayKlass.cpp

Changeset: 9fc985481d78
Author:    ehelin
Date:      2013-12-02 15:43 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9fc985481d78

Merge

! src/share/vm/oops/instanceKlass.cpp
- test/compiler/jsr292/methodHandleExceptions/C.java
- test/compiler/jsr292/methodHandleExceptions/I.java

Changeset: 50287b659eb8
Author:    sjohanss
Date:      2013-12-03 12:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/50287b659eb8

8029329: tmtools tests fail with NPE (in the tool) when run with G1 and FlightRecorder
Summary: Now iterating over all committed (used) G1 regions instead of all reserved.
Reviewed-by: brutisso, dsamersoff, mgerdin

! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1HeapRegionTable.java
! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java

Changeset: 816c89d5957d
Author:    ehelin
Date:      2013-12-05 17:49 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/816c89d5957d

Merge

! src/share/vm/oops/instanceKlass.cpp

Changeset: 9949533a8623
Author:    rbackman
Date:      2013-11-22 14:14 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9949533a8623

8028997: mathexact intrinsics are unstable
Reviewed-by: iveresov, kvn

! src/share/vm/opto/c2_globals.hpp
! 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/CompareTest.java
! test/compiler/intrinsics/mathexact/DecExactITest.java
! test/compiler/intrinsics/mathexact/DecExactLTest.java
! test/compiler/intrinsics/mathexact/GVNTest.java
! test/compiler/intrinsics/mathexact/IncExactITest.java
! test/compiler/intrinsics/mathexact/IncExactLTest.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/NestedMathExactTest.java
! test/compiler/intrinsics/mathexact/SplitThruPhiTest.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

Changeset: 55dd6e77b399
Author:    rbackman
Date:      2013-11-22 15:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/55dd6e77b399

8028624: [TESTBUG] compiler/intrinsics/mathexact/DecExactLTest executes DecExactITest
Reviewed-by: kvn, twisti

! test/compiler/intrinsics/mathexact/DecExactLTest.java

Changeset: eae426d683f6
Author:    simonis
Date:      2013-12-02 11:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/eae426d683f6

8029190: VM_Version::determine_features() asserts on Fujitsu Sparc64 CPUs
Summary: fix code to allow testing on Fujitsu Sparc64 CPUs
Reviewed-by: kvn

! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/sparc/vm/vm_version_sparc.hpp
! src/share/vm/runtime/arguments.cpp

Changeset: 61746b5f0ed3
Author:    anoll
Date:      2013-12-04 09:31 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/61746b5f0ed3

8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline
Summary: Use non-relocatable code to load byte_map_base
Reviewed-by: kvn, roland

! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp

Changeset: 6a8941dbd26f
Author:    anoll
Date:      2013-12-05 12:49 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6a8941dbd26f

Merge


Changeset: 05fedd51e40d
Author:    amurillo
Date:      2013-12-06 09:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/05fedd51e40d

Merge


Changeset: fca262db9c43
Author:    amurillo
Date:      2013-12-06 09:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/fca262db9c43

Added tag hs25-b62 for changeset 05fedd51e40d

! .hgtags

Changeset: ce2d7e46f3c7
Author:    katleman
Date:      2013-12-12 05:20 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ce2d7e46f3c7

Added tag jdk8-b120 for changeset fca262db9c43

! .hgtags


From lana.steuck at oracle.com  Thu Dec 12 21:32:23 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 13 Dec 2013 05:32:23 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 52 new changesets
Message-ID: <20131213054533.A8C4262CA2@hg.openjdk.java.net>

Changeset: 92ce9338bec4
Author:    katleman
Date:      2013-12-04 23:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/92ce9338bec4

Added tag jdk8-b119 for changeset e4499a6529e8

! .hgtags

Changeset: d30a92b7a0b5
Author:    prr
Date:      2013-12-03 09:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d30a92b7a0b5

8029204: Printing a GlyphVector on Windows ignores position of first glyph
Reviewed-by: jgodinez, bae

! src/windows/classes/sun/awt/windows/WPathGraphics.java
+ test/java/awt/print/PrinterJob/PrintGlyphVectorTest.java

Changeset: b6bd334ebc4e
Author:    lana
Date:      2013-12-03 17:58 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b6bd334ebc4e

Merge

- make/PatchList.solaris
- make/altclasses/Makefile
- make/apple/Makefile
- make/apple/applescript/Makefile
- make/bridge/AccessBridgeJava/Makefile
- make/bridge/JAWTAccessBridge/Files_cpp.gmk
- make/bridge/JAWTAccessBridge/Makefile
- make/bridge/Jabswitch/Makefile
- make/bridge/Jaccess/Makefile
- make/bridge/JavaAccessBridge/Files_cpp.gmk
- make/bridge/JavaAccessBridge/Makefile
- make/bridge/Makefile
- make/bridge/WindowsAccessBridge/Files_cpp.gmk
- make/bridge/WindowsAccessBridge/Makefile
- make/com/Makefile
- make/com/apple/Makefile
- make/com/apple/osx/Makefile
- make/com/apple/osxui/Makefile
- make/com/oracle/Makefile
- make/com/oracle/jfr/Makefile
- make/com/oracle/net/Makefile
- make/com/oracle/nio/Makefile
- make/com/oracle/security/ucrypto/FILES_c.gmk
- make/com/oracle/security/ucrypto/Makefile
- make/com/oracle/security/ucrypto/mapfile-vers
- make/com/oracle/util/Makefile
- make/com/sun/Makefile
- make/com/sun/crypto/provider/Makefile
- make/com/sun/demo/Makefile
- make/com/sun/demo/jvmti/Makefile
- make/com/sun/demo/jvmti/hprof/Makefile
- make/com/sun/image/Makefile
- make/com/sun/jarsigner/Makefile
- make/com/sun/java/Makefile
- make/com/sun/java/browser/Makefile
- make/com/sun/java/browser/dom/Makefile
- make/com/sun/java/browser/net/Makefile
- make/com/sun/java/pack/FILES_cpp.gmk
- make/com/sun/java/pack/Makefile
- make/com/sun/java/pack/mapfile-vers
- make/com/sun/java/pack/mapfile-vers-unpack200
- make/com/sun/java/pack/prop/Makefile
- make/com/sun/jmx/Makefile
- make/com/sun/jmx/snmp/Makefile
- make/com/sun/jndi/Makefile
- make/com/sun/jndi/cosnaming/Makefile
- make/com/sun/jndi/dns/Makefile
- make/com/sun/jndi/ldap/Makefile
- make/com/sun/jndi/rmi/Makefile
- make/com/sun/jndi/rmi/registry/Makefile
- make/com/sun/jndi/toolkit/Makefile
- make/com/sun/net/httpserver/Makefile
- make/com/sun/net/ssl/Makefile
- make/com/sun/nio/Makefile
- make/com/sun/nio/sctp/Exportedfiles.gmk
- make/com/sun/nio/sctp/FILES_c.gmk
- make/com/sun/nio/sctp/FILES_java.gmk
- make/com/sun/nio/sctp/Makefile
- make/com/sun/nio/sctp/mapfile-vers
- make/com/sun/org/Makefile
- make/com/sun/org/apache/Makefile
- make/com/sun/org/apache/xml/Makefile
- make/com/sun/rowset/Makefile
- make/com/sun/security/Makefile
- make/com/sun/security/auth/FILES_java.gmk
- make/com/sun/security/auth/Makefile
- make/com/sun/security/auth/module/FILES_c_solaris.gmk
- make/com/sun/security/auth/module/FILES_c_unix.gmk
- make/com/sun/security/auth/module/FILES_c_windows.gmk
- make/com/sun/security/auth/module/FILES_export_solaris.gmk
- make/com/sun/security/auth/module/FILES_export_unix.gmk
- make/com/sun/security/auth/module/FILES_export_windows.gmk
- make/com/sun/security/auth/module/FILES_java.gmk
- make/com/sun/security/auth/module/Makefile
- make/com/sun/security/auth/module/mapfile-vers
- make/com/sun/security/jgss/Makefile
- make/com/sun/security/ntlm/Makefile
- make/com/sun/security/sasl/Makefile
- make/com/sun/sql/FILES_java.gmk
- make/com/sun/sql/Makefile
- make/com/sun/tools/Makefile
- make/com/sun/tools/attach/Exportedfiles.gmk
- make/com/sun/tools/attach/FILES_c.gmk
- make/com/sun/tools/attach/FILES_java.gmk
- make/com/sun/tools/attach/Makefile
- make/com/sun/tools/attach/mapfile-bsd
- make/com/sun/tools/attach/mapfile-linux
- make/com/sun/tools/attach/mapfile-solaris
- make/com/sun/tracing/Makefile
- make/com/sun/tracing/dtrace/Makefile
- make/common/BuildToolJar.gmk
- make/common/CancelImplicits.gmk
- make/common/Classes.gmk
- make/common/Cscope.gmk
- make/common/Defs-linux.gmk
- make/common/Defs-macosx.gmk
- make/common/Defs-solaris.gmk
- make/common/Defs-windows.gmk
- make/common/Defs.gmk
- make/common/Demo.gmk
- make/common/Library.gmk
- make/common/Mapfile-vers.gmk
- make/common/Program.gmk
- make/common/Release-macosx.gmk
- make/common/Release.gmk
- make/common/Rules.gmk
- make/common/Sanity.gmk
- make/common/Subdirs.gmk
- make/common/internal/Defs-corba.gmk
- make/common/internal/Defs-jaxp.gmk
- make/common/internal/Defs-jaxws.gmk
- make/common/internal/Defs-langtools.gmk
- make/common/internal/ImportComponents.gmk
- make/common/internal/NativeCompileRules.gmk
- make/common/internal/Resources.gmk
- make/common/shared/Compiler-gcc.gmk
- make/common/shared/Compiler-llvm.gmk
- make/common/shared/Compiler-msvc.gmk
- make/common/shared/Compiler-sun.gmk
- make/common/shared/Defs-control.gmk
- make/common/shared/Defs-java.gmk
- make/common/shared/Defs-javadoc.gmk
- make/common/shared/Defs-linux.gmk
- make/common/shared/Defs-macosx.gmk
- make/common/shared/Defs-solaris.gmk
- make/common/shared/Defs-utils.gmk
- make/common/shared/Defs-versions.gmk
- make/common/shared/Defs-windows.gmk
- make/common/shared/Defs.gmk
- make/common/shared/Platform.gmk
- make/common/shared/PrivateDefs.gmk-example
- make/common/shared/Sanity-Settings.gmk
- make/common/shared/Sanity.gmk
- make/docs/CORE_PKGS.gmk
- make/docs/Makefile
- make/docs/NON_CORE_PKGS.gmk
- make/docs/Notes.html
- make/java/Makefile
- make/java/applet/Makefile
- make/java/awt/Makefile
- make/java/beans/Makefile
- make/java/fdlibm/FILES_c.gmk
- make/java/fdlibm/Makefile
- make/java/instrument/Makefile
- make/java/instrument/mapfile-vers
- make/java/invoke/Makefile
- make/java/jar/Makefile
- make/java/java/Exportedfiles.gmk
- make/java/java/FILES_c.gmk
- make/java/java/FILES_java.gmk
- make/java/java/Makefile
- make/java/java/genlocales.gmk
- make/java/java/localegen.sh
- make/java/java/localelist.sh
- make/java/java/mapfile-vers
- make/java/java/reflect/Makefile
- make/java/java/reorder-i586
- make/java/java/reorder-sparc
- make/java/java/reorder-sparcv9
- make/java/java_crw_demo/Makefile
- make/java/java_crw_demo/mapfile-vers
- make/java/java_hprof_demo/Makefile
- make/java/java_hprof_demo/mapfile-vers
- make/java/jexec/Makefile
- make/java/jli/Makefile
- make/java/jli/mapfile-vers
- make/java/jobjc/Makefile
- make/java/jvm/Makefile
- make/java/logging/Makefile
- make/java/main/Makefile
- make/java/main/java/Makefile
- make/java/main/java/mapfile-amd64
- make/java/main/java/mapfile-i586
- make/java/main/java/mapfile-sparc
- make/java/main/java/mapfile-sparcv9
- make/java/main/javaw/Makefile
- make/java/management/Exportedfiles.gmk
- make/java/management/FILES_c.gmk
- make/java/management/Makefile
- make/java/management/mapfile-vers
- make/java/math/Makefile
- make/java/net/FILES_c.gmk
- make/java/net/Makefile
- make/java/net/mapfile-vers
- make/java/nio/Exportedfiles.gmk
- make/java/nio/FILES_c.gmk
- make/java/nio/FILES_java.gmk
- make/java/nio/Makefile
- make/java/nio/addNotices.sh
- make/java/nio/genBuffer.sh
- make/java/nio/genCharsetProvider.sh
- make/java/nio/genCoder.sh
- make/java/nio/genExceptions.sh
- make/java/nio/mapfile-bsd
- make/java/nio/mapfile-linux
- make/java/nio/mapfile-solaris
- make/java/nio/reorder-i586
- make/java/nio/reorder-sparc
- make/java/nio/reorder-sparcv9
- make/java/npt/Makefile
- make/java/npt/mapfile-vers
- make/java/redist/Makefile
- make/java/redist/fonts/Makefile
- make/java/redist/sajdi/Makefile
- make/java/rmi/Makefile
- make/java/security/Makefile
- make/java/sql/Makefile
- make/java/sun_nio/FILES_java.gmk
- make/java/sun_nio/Makefile
- make/java/text/Makefile
- make/java/text/base/FILES_java.gmk
- make/java/text/base/Makefile
- make/java/text/bidi/Makefile
- make/java/time/Makefile
- make/java/util/FILES_java.gmk
- make/java/util/FILES_properties.gmk
- make/java/util/Makefile
- make/java/verify/Makefile
- make/java/verify/mapfile-vers
- make/java/verify/reorder-i586
- make/java/verify/reorder-sparc
- make/java/verify/reorder-sparcv9
- make/java/version/Makefile
- make/java/zip/FILES_c.gmk
- make/java/zip/FILES_java.gmk
- make/java/zip/Makefile
- make/java/zip/mapfile-vers
- make/java/zip/reorder-i586
- make/java/zip/reorder-sparc
- make/java/zip/reorder-sparcv9
- make/javax/Makefile
- make/javax/accessibility/Makefile
- make/javax/crypto/Defs-jce.gmk
- make/javax/crypto/Makefile
- make/javax/crypto/policy/limited/LIMITED
- make/javax/crypto/policy/limited/default_local.policy
- make/javax/crypto/policy/limited/exempt_local.policy
- make/javax/crypto/policy/unlimited/UNLIMITED
- make/javax/crypto/policy/unlimited/default_US_export.policy
- make/javax/crypto/policy/unlimited/default_local.policy
- make/javax/imageio/Makefile
- make/javax/management/Makefile
- make/javax/others/Makefile
- make/javax/print/Makefile
- make/javax/rmi/Makefile
- make/javax/rmi/ssl/Makefile
- make/javax/security/Makefile
- make/javax/sound/FILES_c.gmk
- make/javax/sound/Makefile
- make/javax/sound/SoundDefs.gmk
- make/javax/sound/jsoundalsa/Makefile
- make/javax/sound/jsoundalsa/mapfile-vers
- make/javax/sound/jsoundds/Makefile
- make/javax/sound/mapfile-vers
- make/javax/sql/Makefile
- make/javax/swing/FILES.gmk
- make/javax/swing/Makefile
- make/javax/swing/beaninfo/FILES.gmk
- make/javax/swing/beaninfo/Makefile
- make/javax/swing/beaninfo/SwingBeans.gmk
- make/javax/swing/beaninfo/manifest
- make/javax/swing/html32dtd/Makefile
- make/javax/swing/plaf/FILES.gmk
- make/javax/swing/plaf/Makefile
- make/jdk/Makefile
- make/jdk_generic_profile.sh
- make/jpda/Makefile
- make/jpda/back/Makefile
- make/jpda/back/mapfile-vers
- make/jpda/bdi/Makefile
- make/jpda/expr/Makefile
- make/jpda/front/Makefile
- make/jpda/gui/Makefile
- make/jpda/jdwp/Makefile
- make/jpda/jdwp/jdwp.spec
- make/jpda/transport/Makefile
- make/jpda/transport/shmem/Makefile
- make/jpda/transport/shmem/mapfile-vers
- make/jpda/transport/socket/Makefile
- make/jpda/transport/socket/mapfile-vers
- make/jpda/tty/Makefile
- make/jprt.gmk
- make/jprt.properties
- make/launchers/Makefile
- make/launchers/Makefile.launcher
- make/mkdemo/Makefile
- make/mkdemo/applets/Animator/Makefile
- make/mkdemo/applets/ArcTest/Makefile
- make/mkdemo/applets/BarChart/Makefile
- make/mkdemo/applets/Blink/Makefile
- make/mkdemo/applets/CardTest/Makefile
- make/mkdemo/applets/Clock/Makefile
- make/mkdemo/applets/DitherTest/Makefile
- make/mkdemo/applets/DrawTest/Makefile
- make/mkdemo/applets/Fractal/Makefile
- make/mkdemo/applets/GraphLayout/Makefile
- make/mkdemo/applets/GraphicsTest/Makefile
- make/mkdemo/applets/JumpingBox/Makefile
- make/mkdemo/applets/Makefile
- make/mkdemo/applets/MoleculeViewer/Makefile
- make/mkdemo/applets/NervousText/Makefile
- make/mkdemo/applets/SimpleGraph/Makefile
- make/mkdemo/applets/SortDemo/Makefile
- make/mkdemo/applets/SpreadSheet/Makefile
- make/mkdemo/applets/TicTacToe/Makefile
- make/mkdemo/applets/WireFrame/Makefile
- make/mkdemo/jfc/CodePointIM/Makefile
- make/mkdemo/jfc/FileChooserDemo/Makefile
- make/mkdemo/jfc/Font2DTest/Makefile
- make/mkdemo/jfc/Java2D/Makefile
- make/mkdemo/jfc/Laffy/Makefile
- make/mkdemo/jfc/Makefile
- make/mkdemo/jfc/Metalworks/Makefile
- make/mkdemo/jfc/Notepad/Makefile
- make/mkdemo/jfc/SampleTree/Makefile
- make/mkdemo/jfc/Stylepad/Makefile
- make/mkdemo/jfc/SwingApplet/Makefile
- make/mkdemo/jfc/SwingSet2/Makefile
- make/mkdemo/jfc/SwingSet3/Makefile
- make/mkdemo/jfc/TableExample/Makefile
- make/mkdemo/jfc/TransparentRuler/Makefile
- make/mkdemo/jni/Makefile
- make/mkdemo/jni/Poller/Makefile
- make/mkdemo/jpda/Makefile
- make/mkdemo/jvmti/Makefile
- make/mkdemo/jvmti/README.txt
- make/mkdemo/jvmti/compiledMethodLoad/Makefile
- make/mkdemo/jvmti/gctest/Makefile
- make/mkdemo/jvmti/heapTracker/Makefile
- make/mkdemo/jvmti/heapViewer/Makefile
- make/mkdemo/jvmti/hprof/Makefile
- make/mkdemo/jvmti/mapfile-vers
- make/mkdemo/jvmti/minst/Makefile
- make/mkdemo/jvmti/mtrace/Makefile
- make/mkdemo/jvmti/versionCheck/Makefile
- make/mkdemo/jvmti/waiters/Makefile
- make/mkdemo/management/FullThreadDump/Makefile
- make/mkdemo/management/JTop/Makefile
- make/mkdemo/management/Makefile
- make/mkdemo/management/MemoryMonitor/Makefile
- make/mkdemo/management/README.txt
- make/mkdemo/management/VerboseGC/Makefile
- make/mkdemo/nio/Makefile
- make/mkdemo/nio/zipfs/Makefile
- make/mkdemo/scripting/Makefile
- make/mkdemo/scripting/jconsole-plugin/Makefile
- make/mksample/Makefile
- make/mksample/dtrace/Makefile
- make/mksample/forkjoin/Makefile
- make/mksample/forkjoin/mergesort/Makefile
- make/mksample/jmx/Makefile
- make/mksample/jmx/jmx-scandir/Makefile
- make/mksample/nbproject/Makefile
- make/mksample/nio/Makefile
- make/mksample/nio/chatserver/Makefile
- make/mksample/nio/file/Makefile
- make/mksample/nio/multicast/Makefile
- make/mksample/nio/server/Makefile
- make/mksample/scripting/Makefile
- make/mksample/scripting/scriptpad/Makefile
- make/mksample/webservices/EbayClient/Makefile
- make/mksample/webservices/EbayServer/Makefile
- make/mksample/webservices/Makefile
- make/org/Makefile
- make/org/ietf/Makefile
- make/org/ietf/jgss/FILES_java.gmk
- make/org/ietf/jgss/Makefile
- make/org/jcp/Makefile
- make/sun/Makefile
- make/sun/applet/Makefile
- make/sun/audio/Makefile
- make/sun/awt/CondenseRules.awk
- make/sun/awt/Depend.mak
- make/sun/awt/Depend.sed
- make/sun/awt/FILES_c_unix.gmk
- make/sun/awt/FILES_c_windows.gmk
- make/sun/awt/FILES_export_unix.gmk
- make/sun/awt/FILES_export_windows.gmk
- make/sun/awt/Makefile
- make/sun/awt/README
- make/sun/awt/ToBin.java
- make/sun/awt/make.depend
- make/sun/awt/mapfile-mawt-vers
- make/sun/awt/mapfile-vers
- make/sun/awt/mapfile-vers-bsd
- make/sun/awt/mapfile-vers-linux
- make/sun/awt/mawt.gmk
- make/sun/cldr/Makefile
- make/sun/cmm/Makefile
- make/sun/cmm/kcms/FILES_c_unix.gmk
- make/sun/cmm/kcms/FILES_c_windows.gmk
- make/sun/cmm/kcms/Makefile
- make/sun/cmm/kcms/mapfile-vers
- make/sun/cmm/lcms/FILES_c_unix.gmk
- make/sun/cmm/lcms/FILES_c_windows.gmk
- make/sun/cmm/lcms/Makefile
- make/sun/cmm/lcms/mapfile-vers
- make/sun/dcpr/FILES_c.gmk
- make/sun/dcpr/Makefile
- make/sun/dcpr/mapfile-vers
- make/sun/font/FILES_c.gmk
- make/sun/font/Makefile
- make/sun/font/mapfile-vers
- make/sun/font/mapfile-vers.openjdk
- make/sun/font/reorder-i586
- make/sun/font/reorder-sparc
- make/sun/font/reorder-sparcv9
- make/sun/font/t2k/FILES_c.gmk
- make/sun/font/t2k/Makefile
- make/sun/font/t2k/mapfile-vers
- make/sun/headless/Makefile
- make/sun/headless/mapfile-vers
- make/sun/headless/reorder-i586
- make/sun/headless/reorder-sparc
- make/sun/headless/reorder-sparcv9
- make/sun/image/Makefile
- make/sun/image/generic/FILES_c.gmk
- make/sun/image/generic/Makefile
- make/sun/image/generic/mapfile-vers
- make/sun/image/vis/FILES_c.gmk
- make/sun/image/vis/Makefile
- make/sun/jar/Makefile
- make/sun/javazic/Makefile
- make/sun/javazic/javatz/fullset.txt
- make/sun/javazic/javatz/java_11_ids.txt
- make/sun/javazic/javatz/java_us_ids.txt
- make/sun/javazic/javatz/java_win_ids.txt
- make/sun/javazic/javatz/java_zone_ids.txt
- make/sun/javazic/javatz/jdk1.1.x_zone_ids.txt
- make/sun/javazic/tzdata/VERSION
- make/sun/javazic/tzdata/africa
- make/sun/javazic/tzdata/antarctica
- make/sun/javazic/tzdata/asia
- make/sun/javazic/tzdata/australasia
- make/sun/javazic/tzdata/backward
- make/sun/javazic/tzdata/etcetera
- make/sun/javazic/tzdata/europe
- make/sun/javazic/tzdata/factory
- make/sun/javazic/tzdata/gmt
- make/sun/javazic/tzdata/iso3166.tab
- make/sun/javazic/tzdata/jdk11_backward
- make/sun/javazic/tzdata/leapseconds
- make/sun/javazic/tzdata/northamerica
- make/sun/javazic/tzdata/pacificnew
- make/sun/javazic/tzdata/solar87
- make/sun/javazic/tzdata/solar88
- make/sun/javazic/tzdata/solar89
- make/sun/javazic/tzdata/southamerica
- make/sun/javazic/tzdata/systemv
- make/sun/javazic/tzdata/zone.tab
- make/sun/javazic/tzdata_jdk/gmt
- make/sun/javazic/tzdata_jdk/jdk11_backward
- make/sun/javazic/tzdata_jdk/jdk11_full_backward
- make/sun/jawt/Depend.mak
- make/sun/jawt/Depend.sed
- make/sun/jawt/Makefile
- make/sun/jawt/make.depend
- make/sun/jawt/mapfile-vers
- make/sun/jconsole/FILES.gmk
- make/sun/jconsole/Makefile
- make/sun/jdga/Makefile
- make/sun/jdga/mapfile-vers
- make/sun/jpeg/FILES_c.gmk
- make/sun/jpeg/Makefile
- make/sun/jpeg/mapfile-vers
- make/sun/jpeg/mapfile-vers-closed
- make/sun/jpeg/reorder-i586
- make/sun/jpeg/reorder-sparc
- make/sun/jpeg/reorder-sparcv9
- make/sun/launcher/Makefile
- make/sun/lwawt/FILES_c_macosx.gmk
- make/sun/lwawt/FILES_export_macosx.gmk
- make/sun/lwawt/Makefile
- make/sun/management/Makefile
- make/sun/management/jmxremote/Makefile
- make/sun/management/snmp/Makefile
- make/sun/misc/Makefile
- make/sun/native2ascii/Makefile
- make/sun/net/FILES_java.gmk
- make/sun/net/Makefile
- make/sun/net/others/Makefile
- make/sun/net/spi/Makefile
- make/sun/net/spi/nameservice/Makefile
- make/sun/net/spi/nameservice/dns/Makefile
- make/sun/nio/Makefile
- make/sun/nio/cs/FILES_java.gmk
- make/sun/nio/cs/Makefile
- make/sun/osxapp/Makefile
- make/sun/osxapp/ToBin.java
- make/sun/pisces/Makefile
- make/sun/rmi/Makefile
- make/sun/rmi/cgi/Makefile
- make/sun/rmi/oldtools/FILES_java.gmk
- make/sun/rmi/oldtools/Makefile
- make/sun/rmi/registry/Makefile
- make/sun/rmi/rmi/Makefile
- make/sun/rmi/rmi/mapfile-vers
- make/sun/rmi/rmic/FILES.gmk
- make/sun/rmi/rmic/Makefile
- make/sun/rmi/rmid/Makefile
- make/sun/security/Makefile
- make/sun/security/action/Makefile
- make/sun/security/ec/FILES_c.gmk
- make/sun/security/ec/Makefile
- make/sun/security/ec/mapfile-vers
- make/sun/security/jgss/Makefile
- make/sun/security/jgss/wrapper/FILES_c.gmk
- make/sun/security/jgss/wrapper/Makefile
- make/sun/security/jgss/wrapper/mapfile-vers
- make/sun/security/krb5/FILES_c_windows.gmk
- make/sun/security/krb5/Makefile
- make/sun/security/mscapi/FILES_cpp.gmk
- make/sun/security/mscapi/Makefile
- make/sun/security/other/Makefile
- make/sun/security/pkcs11/FILES_c.gmk
- make/sun/security/pkcs11/Makefile
- make/sun/security/pkcs11/mapfile-vers
- make/sun/security/smartcardio/FILES_c.gmk
- make/sun/security/smartcardio/Makefile
- make/sun/security/smartcardio/mapfile-vers
- make/sun/security/tools/Makefile
- make/sun/security/util/Makefile
- make/sun/serialver/Makefile
- make/sun/splashscreen/FILES_c.gmk
- make/sun/splashscreen/Makefile
- make/sun/splashscreen/mapfile-vers
- make/sun/text/FILES_java.gmk
- make/sun/text/FILES_properties.gmk
- make/sun/text/Makefile
- make/sun/tools/Makefile
- make/sun/tracing/Makefile
- make/sun/tracing/dtrace/Makefile
- make/sun/tracing/dtrace/mapfile-vers
- make/sun/tzdb/Makefile
- make/sun/usagetracker/Makefile
- make/sun/util/Makefile
- make/sun/xawt/FILES_c_unix.gmk
- make/sun/xawt/FILES_export_unix.gmk
- make/sun/xawt/Makefile
- make/sun/xawt/mapfile-vers
- make/templates/bsd-header
- make/templates/gpl-cp-header
- make/templates/gpl-header
- make/tools/CharsetMapping/Big5.map
- make/tools/CharsetMapping/Big5.nr
- make/tools/CharsetMapping/DoubleByte-X.java.template
- make/tools/CharsetMapping/EUC_CN.map
- make/tools/CharsetMapping/EUC_KR.map
- make/tools/CharsetMapping/GBK.map
- make/tools/CharsetMapping/HKSCS2001.c2b
- make/tools/CharsetMapping/HKSCS2001.map
- make/tools/CharsetMapping/HKSCS2008.c2b
- make/tools/CharsetMapping/HKSCS2008.map
- make/tools/CharsetMapping/HKSCS_XP.c2b
- make/tools/CharsetMapping/HKSCS_XP.map
- make/tools/CharsetMapping/IBM037.c2b
- make/tools/CharsetMapping/IBM037.map
- make/tools/CharsetMapping/IBM037.nr
- make/tools/CharsetMapping/IBM1006.map
- make/tools/CharsetMapping/IBM1025.c2b
- make/tools/CharsetMapping/IBM1025.map
- make/tools/CharsetMapping/IBM1025.nr
- make/tools/CharsetMapping/IBM1026.c2b
- make/tools/CharsetMapping/IBM1026.map
- make/tools/CharsetMapping/IBM1026.nr
- make/tools/CharsetMapping/IBM1046.map
- make/tools/CharsetMapping/IBM1047.map
- make/tools/CharsetMapping/IBM1097.map
- make/tools/CharsetMapping/IBM1098.map
- make/tools/CharsetMapping/IBM1112.c2b
- make/tools/CharsetMapping/IBM1112.map
- make/tools/CharsetMapping/IBM1112.nr
- make/tools/CharsetMapping/IBM1122.c2b
- make/tools/CharsetMapping/IBM1122.map
- make/tools/CharsetMapping/IBM1122.nr
- make/tools/CharsetMapping/IBM1123.c2b
- make/tools/CharsetMapping/IBM1123.map
- make/tools/CharsetMapping/IBM1123.nr
- make/tools/CharsetMapping/IBM1124.map
- make/tools/CharsetMapping/IBM1140.c2b
- make/tools/CharsetMapping/IBM1140.map
- make/tools/CharsetMapping/IBM1141.c2b
- make/tools/CharsetMapping/IBM1141.map
- make/tools/CharsetMapping/IBM1142.c2b
- make/tools/CharsetMapping/IBM1142.map
- make/tools/CharsetMapping/IBM1143.c2b
- make/tools/CharsetMapping/IBM1143.map
- make/tools/CharsetMapping/IBM1144.c2b
- make/tools/CharsetMapping/IBM1144.map
- make/tools/CharsetMapping/IBM1145.c2b
- make/tools/CharsetMapping/IBM1145.map
- make/tools/CharsetMapping/IBM1146.c2b
- make/tools/CharsetMapping/IBM1146.map
- make/tools/CharsetMapping/IBM1147.c2b
- make/tools/CharsetMapping/IBM1147.map
- make/tools/CharsetMapping/IBM1148.c2b
- make/tools/CharsetMapping/IBM1148.map
- make/tools/CharsetMapping/IBM1149.c2b
- make/tools/CharsetMapping/IBM1149.map
- make/tools/CharsetMapping/IBM1364.c2b
- make/tools/CharsetMapping/IBM1364.map
- make/tools/CharsetMapping/IBM1381.c2b
- make/tools/CharsetMapping/IBM1381.map
- make/tools/CharsetMapping/IBM1383.c2b
- make/tools/CharsetMapping/IBM1383.map
- make/tools/CharsetMapping/IBM1383.nr
- make/tools/CharsetMapping/IBM273.c2b
- make/tools/CharsetMapping/IBM273.map
- make/tools/CharsetMapping/IBM273.nr
- make/tools/CharsetMapping/IBM277.c2b
- make/tools/CharsetMapping/IBM277.map
- make/tools/CharsetMapping/IBM277.nr
- make/tools/CharsetMapping/IBM278.c2b
- make/tools/CharsetMapping/IBM278.map
- make/tools/CharsetMapping/IBM278.nr
- make/tools/CharsetMapping/IBM280.c2b
- make/tools/CharsetMapping/IBM280.map
- make/tools/CharsetMapping/IBM280.nr
- make/tools/CharsetMapping/IBM284.c2b
- make/tools/CharsetMapping/IBM284.map
- make/tools/CharsetMapping/IBM284.nr
- make/tools/CharsetMapping/IBM285.c2b
- make/tools/CharsetMapping/IBM285.map
- make/tools/CharsetMapping/IBM285.nr
- make/tools/CharsetMapping/IBM290.c2b
- make/tools/CharsetMapping/IBM290.map
- make/tools/CharsetMapping/IBM297.c2b
- make/tools/CharsetMapping/IBM297.map
- make/tools/CharsetMapping/IBM297.nr
- make/tools/CharsetMapping/IBM300.c2b
- make/tools/CharsetMapping/IBM300.map
- make/tools/CharsetMapping/IBM420.c2b
- make/tools/CharsetMapping/IBM420.map
- make/tools/CharsetMapping/IBM420.nr
- make/tools/CharsetMapping/IBM424.c2b
- make/tools/CharsetMapping/IBM424.map
- make/tools/CharsetMapping/IBM424.nr
- make/tools/CharsetMapping/IBM437.map
- make/tools/CharsetMapping/IBM500.c2b
- make/tools/CharsetMapping/IBM500.map
- make/tools/CharsetMapping/IBM500.nr
- make/tools/CharsetMapping/IBM737.map
- make/tools/CharsetMapping/IBM775.map
- make/tools/CharsetMapping/IBM833.c2b
- make/tools/CharsetMapping/IBM833.map
- make/tools/CharsetMapping/IBM838.c2b
- make/tools/CharsetMapping/IBM838.map
- make/tools/CharsetMapping/IBM838.nr
- make/tools/CharsetMapping/IBM850.map
- make/tools/CharsetMapping/IBM852.map
- make/tools/CharsetMapping/IBM855.map
- make/tools/CharsetMapping/IBM856.map
- make/tools/CharsetMapping/IBM857.map
- make/tools/CharsetMapping/IBM858.map
- make/tools/CharsetMapping/IBM860.map
- make/tools/CharsetMapping/IBM861.map
- make/tools/CharsetMapping/IBM862.map
- make/tools/CharsetMapping/IBM863.map
- make/tools/CharsetMapping/IBM864.map
- make/tools/CharsetMapping/IBM865.map
- make/tools/CharsetMapping/IBM866.map
- make/tools/CharsetMapping/IBM868.map
- make/tools/CharsetMapping/IBM869.map
- make/tools/CharsetMapping/IBM870.c2b
- make/tools/CharsetMapping/IBM870.map
- make/tools/CharsetMapping/IBM870.nr
- make/tools/CharsetMapping/IBM871.c2b
- make/tools/CharsetMapping/IBM871.map
- make/tools/CharsetMapping/IBM871.nr
- make/tools/CharsetMapping/IBM874.map
- make/tools/CharsetMapping/IBM874.nr
- make/tools/CharsetMapping/IBM875.c2b
- make/tools/CharsetMapping/IBM875.map
- make/tools/CharsetMapping/IBM875.nr
- make/tools/CharsetMapping/IBM918.c2b
- make/tools/CharsetMapping/IBM918.map
- make/tools/CharsetMapping/IBM918.nr
- make/tools/CharsetMapping/IBM921.map
- make/tools/CharsetMapping/IBM922.map
- make/tools/CharsetMapping/IBM930.c2b
- make/tools/CharsetMapping/IBM930.map
- make/tools/CharsetMapping/IBM930.nr
- make/tools/CharsetMapping/IBM933.c2b
- make/tools/CharsetMapping/IBM933.map
- make/tools/CharsetMapping/IBM935.c2b
- make/tools/CharsetMapping/IBM935.map
- make/tools/CharsetMapping/IBM935.nr
- make/tools/CharsetMapping/IBM937.c2b
- make/tools/CharsetMapping/IBM937.map
- make/tools/CharsetMapping/IBM937.nr
- make/tools/CharsetMapping/IBM939.c2b
- make/tools/CharsetMapping/IBM939.map
- make/tools/CharsetMapping/IBM939.nr
- make/tools/CharsetMapping/IBM942.c2b
- make/tools/CharsetMapping/IBM942.map
- make/tools/CharsetMapping/IBM943.map
- make/tools/CharsetMapping/IBM943.nr
- make/tools/CharsetMapping/IBM948.c2b
- make/tools/CharsetMapping/IBM948.map
- make/tools/CharsetMapping/IBM949.map
- make/tools/CharsetMapping/IBM950.c2b
- make/tools/CharsetMapping/IBM950.map
- make/tools/CharsetMapping/IBM970.c2b
- make/tools/CharsetMapping/IBM970.map
- make/tools/CharsetMapping/ISO_8859_11.map
- make/tools/CharsetMapping/ISO_8859_13.map
- make/tools/CharsetMapping/ISO_8859_15.map
- make/tools/CharsetMapping/ISO_8859_2.map
- make/tools/CharsetMapping/ISO_8859_3.map
- make/tools/CharsetMapping/ISO_8859_4.map
- make/tools/CharsetMapping/ISO_8859_5.map
- make/tools/CharsetMapping/ISO_8859_6.map
- make/tools/CharsetMapping/ISO_8859_7.map
- make/tools/CharsetMapping/ISO_8859_8.map
- make/tools/CharsetMapping/ISO_8859_9.map
- make/tools/CharsetMapping/JIS_X_0201.c2b
- make/tools/CharsetMapping/JIS_X_0201.map
- make/tools/CharsetMapping/JIS_X_0208.map
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b
- make/tools/CharsetMapping/JIS_X_0208_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.map
- make/tools/CharsetMapping/JIS_X_0208_MS932.nr
- make/tools/CharsetMapping/JIS_X_0208_Solaris.map
- make/tools/CharsetMapping/JIS_X_0208_Solaris.nr
- make/tools/CharsetMapping/JIS_X_0212.map
- make/tools/CharsetMapping/JIS_X_0212_MS5022X.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.map
- make/tools/CharsetMapping/JIS_X_0212_Solaris.nr
- make/tools/CharsetMapping/Johab.map
- make/tools/CharsetMapping/KOI8_R.map
- make/tools/CharsetMapping/KOI8_U.map
- make/tools/CharsetMapping/MS1250.map
- make/tools/CharsetMapping/MS1251.map
- make/tools/CharsetMapping/MS1252.map
- make/tools/CharsetMapping/MS1253.map
- make/tools/CharsetMapping/MS1254.map
- make/tools/CharsetMapping/MS1255.map
- make/tools/CharsetMapping/MS1256.map
- make/tools/CharsetMapping/MS1257.map
- make/tools/CharsetMapping/MS1258.map
- make/tools/CharsetMapping/MS874.map
- make/tools/CharsetMapping/MS932.c2b
- make/tools/CharsetMapping/MS932.map
- make/tools/CharsetMapping/MS932.nr
- make/tools/CharsetMapping/MS936.map
- make/tools/CharsetMapping/MS949.map
- make/tools/CharsetMapping/MS950.map
- make/tools/CharsetMapping/MS950.nr
- make/tools/CharsetMapping/MacArabic.map
- make/tools/CharsetMapping/MacCentralEurope.map
- make/tools/CharsetMapping/MacCroatian.map
- make/tools/CharsetMapping/MacCyrillic.map
- make/tools/CharsetMapping/MacDingbat.map
- make/tools/CharsetMapping/MacGreek.map
- make/tools/CharsetMapping/MacHebrew.map
- make/tools/CharsetMapping/MacIceland.map
- make/tools/CharsetMapping/MacRoman.map
- make/tools/CharsetMapping/MacRomania.map
- make/tools/CharsetMapping/MacSymbol.map
- make/tools/CharsetMapping/MacThai.map
- make/tools/CharsetMapping/MacTurkish.map
- make/tools/CharsetMapping/MacUkraine.map
- make/tools/CharsetMapping/Makefile
- make/tools/CharsetMapping/PCK.c2b
- make/tools/CharsetMapping/PCK.map
- make/tools/CharsetMapping/PCK.nr
- make/tools/CharsetMapping/SJIS.c2b
- make/tools/CharsetMapping/SJIS.map
- make/tools/CharsetMapping/SingleByte-X.java.template
- make/tools/CharsetMapping/TIS_620.map
- make/tools/CharsetMapping/dbcs
- make/tools/CharsetMapping/euc_tw.map
- make/tools/CharsetMapping/extsbcs
- make/tools/CharsetMapping/sbcs
- make/tools/CharsetMapping/sjis0213.map
- make/tools/GenerateCharacter/Character.c.template
- make/tools/GenerateCharacter/CharacterData00.java.template
- make/tools/GenerateCharacter/CharacterData01.java.template
- make/tools/GenerateCharacter/CharacterData02.java.template
- make/tools/GenerateCharacter/CharacterData0E.java.template
- make/tools/GenerateCharacter/CharacterDataLatin1.java.template
- make/tools/GenerateCharacter/CharacterDataPrivateUse.java.template
- make/tools/GenerateCharacter/CharacterDataUndefined.java.template
- make/tools/GenerateCharacter/Makefile
- make/tools/GenerateCharacter/check_class.c.template
- make/tools/Makefile
- make/tools/README.txt
- make/tools/UnicodeData/PropList.txt
- make/tools/UnicodeData/Scripts.txt
- make/tools/UnicodeData/SpecialCasing.txt
- make/tools/UnicodeData/UnicodeData.txt
- make/tools/UnicodeData/VERSION
- make/tools/add_gnu_debuglink/Makefile
- make/tools/add_gnu_debuglink/add_gnu_debuglink.c
- make/tools/addjsum/Makefile
- make/tools/addtorestrictedpkgs/Makefile
- make/tools/buildmetaindex/Makefile
- make/tools/cldrconverter/Makefile
- make/tools/commentchecker/Makefile
- make/tools/compile_font_config/Makefile
- make/tools/compile_properties/Makefile
- make/tools/dir_diff/Makefile
- make/tools/dtdbuilder/Makefile
- make/tools/dtdbuilder/dtds/HTMLlat1.sgml
- make/tools/dtdbuilder/dtds/HTMLspecial.sgml
- make/tools/dtdbuilder/dtds/HTMLsymbol.sgml
- make/tools/dtdbuilder/dtds/html32.dtd
- make/tools/dtdbuilder/dtds/public.map
- make/tools/fix_empty_sec_hdr_flags/Makefile
- make/tools/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c
- make/tools/freetypecheck/Makefile
- make/tools/freetypecheck/freetypecheck.c
- make/tools/generate_break_iterator/Makefile
- make/tools/generate_nimbus/Makefile
- make/tools/generatecurrencydata/Makefile
- make/tools/hasher_classes/Makefile
- make/tools/jarreorder/Makefile
- make/tools/jarsplit/Makefile
- make/tools/jdwpgen/Makefile
- make/tools/makeclasslist/Makefile
- make/tools/manifest.mf
- make/tools/msys_build_scripts/dospath.sh
- make/tools/msys_build_scripts/dospath.vbs
- make/tools/reorder/Makefile
- make/tools/reorder/tests/Exit.java
- make/tools/reorder/tests/Hello.java
- make/tools/reorder/tests/IntToString.java
- make/tools/reorder/tests/JHello.java
- make/tools/reorder/tests/LoadFrame.java
- make/tools/reorder/tests/LoadJFrame.java
- make/tools/reorder/tests/LoadToolkit.java
- make/tools/reorder/tests/Null.java
- make/tools/reorder/tests/Sleep.java
- make/tools/reorder/tools/Combine.java
- make/tools/reorder/tools/MaxTime.java
- make/tools/reorder/tools/mcount.c
- make/tools/reorder/tools/remove_mcount.c
- make/tools/reorder/tools/util-i586.il
- make/tools/reorder/tools/util-sparc.il
- make/tools/reorder/tools/util-sparcv9.il
- make/tools/sharing/README.txt
- make/tools/sharing/classlist.linux
- make/tools/sharing/classlist.macosx
- make/tools/sharing/classlist.solaris
- make/tools/sharing/classlist.windows
- make/tools/sharing/tests/GHello.java
- make/tools/sharing/tests/Hello.java
- make/tools/sharing/tests/JHello.java
- make/tools/spp/Makefile
- make/tools/src/build/tools/addjsum/AddJsum.java
- make/tools/src/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java
- make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java
- make/tools/src/build/tools/charsetmapping/DBCS.java
- make/tools/src/build/tools/charsetmapping/EUC_TW.java
- make/tools/src/build/tools/charsetmapping/HKSCS.java
- make/tools/src/build/tools/charsetmapping/JIS0213.java
- make/tools/src/build/tools/charsetmapping/Main.java
- make/tools/src/build/tools/charsetmapping/SBCS.java
- make/tools/src/build/tools/charsetmapping/Utils.java
- make/tools/src/build/tools/classfile/RemoveMethods.java
- make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java
- make/tools/src/build/tools/cldrconverter/Bundle.java
- make/tools/src/build/tools/cldrconverter/BundleGenerator.java
- make/tools/src/build/tools/cldrconverter/CLDRConverter.java
- make/tools/src/build/tools/cldrconverter/CalendarType.java
- make/tools/src/build/tools/cldrconverter/Container.java
- make/tools/src/build/tools/cldrconverter/CopyrightHeaders.java
- make/tools/src/build/tools/cldrconverter/Entry.java
- make/tools/src/build/tools/cldrconverter/IgnoredContainer.java
- make/tools/src/build/tools/cldrconverter/KeyContainer.java
- make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java
- make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java
- make/tools/src/build/tools/cldrconverter/NumberingSystemsParseHandler.java
- make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java
- make/tools/src/build/tools/cldrconverter/StringArrayElement.java
- make/tools/src/build/tools/cldrconverter/StringArrayEntry.java
- make/tools/src/build/tools/cldrconverter/StringEntry.java
- make/tools/src/build/tools/cldrconverter/SupplementDataParseHandler.java
- make/tools/src/build/tools/commentchecker/CommentChecker.java
- make/tools/src/build/tools/compilefontconfig/CompileFontConfig.java
- make/tools/src/build/tools/compileproperties/CompileProperties.java
- make/tools/src/build/tools/deps/CheckDeps.java
- make/tools/src/build/tools/deps/refs.allowed
- make/tools/src/build/tools/dirdiff/DirDiff.java
- make/tools/src/build/tools/dtdbuilder/DTDBuilder.java
- make/tools/src/build/tools/dtdbuilder/DTDInputStream.java
- make/tools/src/build/tools/dtdbuilder/DTDParser.java
- make/tools/src/build/tools/dtdbuilder/PublicMapping.java
- make/tools/src/build/tools/dtdbuilder/README.txt
- make/tools/src/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java
- make/tools/src/build/tools/generatebreakiteratordata/CharSet.java
- make/tools/src/build/tools/generatebreakiteratordata/CharacterCategory.java
- make/tools/src/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java
- make/tools/src/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
- make/tools/src/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java
- make/tools/src/build/tools/generatecharacter/CharacterName.java
- make/tools/src/build/tools/generatecharacter/CharacterScript.java
- make/tools/src/build/tools/generatecharacter/GenerateCharacter.java
- make/tools/src/build/tools/generatecharacter/PrintCharacterRanges.java
- make/tools/src/build/tools/generatecharacter/PropList.java
- make/tools/src/build/tools/generatecharacter/SpecialCaseMap.java
- make/tools/src/build/tools/generatecharacter/UnicodeSpec.java
- make/tools/src/build/tools/generatecharacter/Utility.java
- make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java
- make/tools/src/build/tools/generatenimbus/AbstractGradient.java
- make/tools/src/build/tools/generatenimbus/Border.java
- make/tools/src/build/tools/generatenimbus/Canvas.java
- make/tools/src/build/tools/generatenimbus/ComponentColor.java
- make/tools/src/build/tools/generatenimbus/Dimension.java
- make/tools/src/build/tools/generatenimbus/Ellipse.java
- make/tools/src/build/tools/generatenimbus/Generator.java
- make/tools/src/build/tools/generatenimbus/Gradient.java
- make/tools/src/build/tools/generatenimbus/GradientStop.java
- make/tools/src/build/tools/generatenimbus/Insets.java
- make/tools/src/build/tools/generatenimbus/Layer.java
- make/tools/src/build/tools/generatenimbus/Matte.java
- make/tools/src/build/tools/generatenimbus/ObjectFactory.java
- make/tools/src/build/tools/generatenimbus/Paint.java
- make/tools/src/build/tools/generatenimbus/PainterGenerator.java
- make/tools/src/build/tools/generatenimbus/Path.java
- make/tools/src/build/tools/generatenimbus/Point.java
- make/tools/src/build/tools/generatenimbus/RadialGradient.java
- make/tools/src/build/tools/generatenimbus/Rectangle.java
- make/tools/src/build/tools/generatenimbus/Shape.java
- make/tools/src/build/tools/generatenimbus/SynthModel.java
- make/tools/src/build/tools/generatenimbus/Typeface.java
- make/tools/src/build/tools/generatenimbus/UIColor.java
- make/tools/src/build/tools/generatenimbus/UIComponent.java
- make/tools/src/build/tools/generatenimbus/UIDefault.java
- make/tools/src/build/tools/generatenimbus/UIFont.java
- make/tools/src/build/tools/generatenimbus/UIIconRegion.java
- make/tools/src/build/tools/generatenimbus/UIProperty.java
- make/tools/src/build/tools/generatenimbus/UIRegion.java
- make/tools/src/build/tools/generatenimbus/UIState.java
- make/tools/src/build/tools/generatenimbus/UIStateType.java
- make/tools/src/build/tools/generatenimbus/UIStyle.java
- make/tools/src/build/tools/generatenimbus/Utils.java
- make/tools/src/build/tools/hasher/Hasher.java
- make/tools/src/build/tools/jarreorder/JarReorder.java
- make/tools/src/build/tools/jarsplit/JarSplit.java
- make/tools/src/build/tools/jdwpgen/AbstractCommandNode.java
- make/tools/src/build/tools/jdwpgen/AbstractGroupNode.java
- make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleNode.java
- make/tools/src/build/tools/jdwpgen/AbstractSimpleTypeNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeListNode.java
- make/tools/src/build/tools/jdwpgen/AbstractTypeNode.java
- make/tools/src/build/tools/jdwpgen/AltNode.java
- make/tools/src/build/tools/jdwpgen/ArrayObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java
- make/tools/src/build/tools/jdwpgen/ArrayTypeNode.java
- make/tools/src/build/tools/jdwpgen/BooleanTypeNode.java
- make/tools/src/build/tools/jdwpgen/ByteTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ClassTypeNode.java
- make/tools/src/build/tools/jdwpgen/CommandNode.java
- make/tools/src/build/tools/jdwpgen/CommandSetNode.java
- make/tools/src/build/tools/jdwpgen/CommentNode.java
- make/tools/src/build/tools/jdwpgen/ConstantNode.java
- make/tools/src/build/tools/jdwpgen/ConstantSetNode.java
- make/tools/src/build/tools/jdwpgen/Context.java
- make/tools/src/build/tools/jdwpgen/ErrorNode.java
- make/tools/src/build/tools/jdwpgen/ErrorSetNode.java
- make/tools/src/build/tools/jdwpgen/EventNode.java
- make/tools/src/build/tools/jdwpgen/FieldTypeNode.java
- make/tools/src/build/tools/jdwpgen/FrameTypeNode.java
- make/tools/src/build/tools/jdwpgen/GroupNode.java
- make/tools/src/build/tools/jdwpgen/IntTypeNode.java
- make/tools/src/build/tools/jdwpgen/InterfaceTypeNode.java
- make/tools/src/build/tools/jdwpgen/LocationTypeNode.java
- make/tools/src/build/tools/jdwpgen/LongTypeNode.java
- make/tools/src/build/tools/jdwpgen/Main.java
- make/tools/src/build/tools/jdwpgen/MethodTypeNode.java
- make/tools/src/build/tools/jdwpgen/NameNode.java
- make/tools/src/build/tools/jdwpgen/NameValueNode.java
- make/tools/src/build/tools/jdwpgen/Node.java
- make/tools/src/build/tools/jdwpgen/ObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/OutNode.java
- make/tools/src/build/tools/jdwpgen/Parse.java
- make/tools/src/build/tools/jdwpgen/ReferenceIDTypeNode.java
- make/tools/src/build/tools/jdwpgen/ReferenceTypeNode.java
- make/tools/src/build/tools/jdwpgen/RepeatNode.java
- make/tools/src/build/tools/jdwpgen/ReplyNode.java
- make/tools/src/build/tools/jdwpgen/RootNode.java
- make/tools/src/build/tools/jdwpgen/SelectNode.java
- make/tools/src/build/tools/jdwpgen/StringObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/StringTypeNode.java
- make/tools/src/build/tools/jdwpgen/TaggedObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/ThreadObjectTypeNode.java
- make/tools/src/build/tools/jdwpgen/TypeNode.java
- make/tools/src/build/tools/jdwpgen/UntaggedValueTypeNode.java
- make/tools/src/build/tools/jdwpgen/ValueTypeNode.java
- make/tools/src/build/tools/makeclasslist/MakeClasslist.java
- make/tools/src/build/tools/spp/Spp.java
- make/tools/src/build/tools/stripproperties/StripProperties.java
- make/tools/src/build/tools/tzdb/ChronoField.java
- make/tools/src/build/tools/tzdb/DateTimeException.java
- make/tools/src/build/tools/tzdb/LocalDate.java
- make/tools/src/build/tools/tzdb/LocalDateTime.java
- make/tools/src/build/tools/tzdb/LocalTime.java
- make/tools/src/build/tools/tzdb/TimeDefinition.java
- make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java
- make/tools/src/build/tools/tzdb/Utils.java
- make/tools/src/build/tools/tzdb/ZoneOffset.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransition.java
- make/tools/src/build/tools/tzdb/ZoneOffsetTransitionRule.java
- make/tools/src/build/tools/tzdb/ZoneRules.java
- make/tools/src/build/tools/tzdb/ZoneRulesBuilder.java
- make/tools/strip_properties/Makefile
- make/tools/swing-beans/DocBeanInfo.java
- make/tools/swing-beans/GenDocletBeanInfo.java
- make/tools/swing-beans/GenSwingBeanInfo.java
- make/tools/swing-beans/SwingBeanInfo.template
- make/tools/swing-beans/beaninfo/images/AbstractButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/BorderColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor16.gif
- make/tools/swing-beans/beaninfo/images/BoxColor32.gif
- make/tools/swing-beans/beaninfo/images/BoxMono16.gif
- make/tools/swing-beans/beaninfo/images/BoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor16.gif
- make/tools/swing-beans/beaninfo/images/JAppletColor32.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono16.gif
- make/tools/swing-beans/beaninfo/images/JAppletMono32.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JCheckBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JColorChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxColor32.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono16.gif
- make/tools/swing-beans/beaninfo/images/JComboBoxMono32.gif
- make/tools/swing-beans/beaninfo/images/JComponentColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JDesktopPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor16.gif
- make/tools/swing-beans/beaninfo/images/JDialogColor32.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono16.gif
- make/tools/swing-beans/beaninfo/images/JDialogMono32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JEditorPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserColor32.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono16.gif
- make/tools/swing-beans/beaninfo/images/JFileChooserMono32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameColor32.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono16.gif
- make/tools/swing-beans/beaninfo/images/JInternalFrameMono32.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor16.gif
- make/tools/swing-beans/beaninfo/images/JLabelColor32.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono16.gif
- make/tools/swing-beans/beaninfo/images/JLabelMono32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JLayeredPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JListColor16.gif
- make/tools/swing-beans/beaninfo/images/JListColor32.gif
- make/tools/swing-beans/beaninfo/images/JListMono16.gif
- make/tools/swing-beans/beaninfo/images/JListMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JOptionPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor16.gif
- make/tools/swing-beans/beaninfo/images/JPanelColor32.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono16.gif
- make/tools/swing-beans/beaninfo/images/JPanelMono32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JPasswordFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuColor32.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono16.gif
- make/tools/swing-beans/beaninfo/images/JPopupMenuMono32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JProgressBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono32.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JRadioButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JRootPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JScrollPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorColor32.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono16.gif
- make/tools/swing-beans/beaninfo/images/JSeparatorMono32.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor16.gif
- make/tools/swing-beans/beaninfo/images/JSliderColor32.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono16.gif
- make/tools/swing-beans/beaninfo/images/JSliderMono32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerColor32.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono16.gif
- make/tools/swing-beans/beaninfo/images/JSpinnerMono32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JSplitPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTabbedPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JTableColor16.gif
- make/tools/swing-beans/beaninfo/images/JTableColor32.gif
- make/tools/swing-beans/beaninfo/images/JTableMono16.gif
- make/tools/swing-beans/beaninfo/images/JTableMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextAreaMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextFieldMono32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneColor32.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono16.gif
- make/tools/swing-beans/beaninfo/images/JTextPaneMono32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonColor32.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono16.gif
- make/tools/swing-beans/beaninfo/images/JToggleButtonMono32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarColor32.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono16.gif
- make/tools/swing-beans/beaninfo/images/JToolBarMono32.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor16.gif
- make/tools/swing-beans/beaninfo/images/JTreeColor32.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono16.gif
- make/tools/swing-beans/beaninfo/images/JTreeMono32.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor16.gif
- make/tools/swing-beans/beaninfo/images/JViewportColor32.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono16.gif
- make/tools/swing-beans/beaninfo/images/JViewportMono32.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor16.gif
- make/tools/swing-beans/beaninfo/images/JWindowColor32.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono16.gif
- make/tools/swing-beans/beaninfo/images/JWindowMono32.gif
- make/tools/swing-beans/javax/swing/SwingBeanInfoBase.java
- make/tools/swing-beans/sun/swing/BeanInfoUtils.java
- make/tools/tzdb/Makefile
- makefiles/BuildJdk.gmk
- makefiles/Bundles.gmk
- makefiles/CompileDemos.gmk
- makefiles/CompileJavaClasses.gmk
- makefiles/CompileLaunchers.gmk
- makefiles/CompileNativeLibraries.gmk
- makefiles/CopyFiles.gmk
- makefiles/CopyIntoClasses.gmk
- makefiles/CopySamples.gmk
- makefiles/CreateJars.gmk
- makefiles/CreateSecurityJars.gmk
- makefiles/GenerateClasses.gmk
- makefiles/GenerateData.gmk
- makefiles/GenerateSources.gmk
- makefiles/Images.gmk
- makefiles/Import.gmk
- makefiles/Makefile
- makefiles/PatchList.solaris
- makefiles/ProfileNames.gmk
- makefiles/Profiles.gmk
- makefiles/Setup.gmk
- makefiles/SignJars.gmk
- makefiles/Tools.gmk
- makefiles/gendata/GendataBreakIterator.gmk
- makefiles/gendata/GendataFontConfig.gmk
- makefiles/gendata/GendataHtml32dtd.gmk
- makefiles/gendata/GendataTZDB.gmk
- makefiles/gendata/GendataTimeZone.gmk
- makefiles/gensrc/GensrcBuffer.gmk
- makefiles/gensrc/GensrcCLDR.gmk
- makefiles/gensrc/GensrcCharacterData.gmk
- makefiles/gensrc/GensrcCharsetCoder.gmk
- makefiles/gensrc/GensrcCharsetMapping.gmk
- makefiles/gensrc/GensrcExceptions.gmk
- makefiles/gensrc/GensrcIcons.gmk
- makefiles/gensrc/GensrcJDWP.gmk
- makefiles/gensrc/GensrcJObjC.gmk
- makefiles/gensrc/GensrcLocaleDataMetaInfo.gmk
- makefiles/gensrc/GensrcMisc.gmk
- makefiles/gensrc/GensrcProperties.gmk
- makefiles/gensrc/GensrcSwing.gmk
- makefiles/gensrc/GensrcX11Wrappers.gmk
- makefiles/jpda/jdwp/jdwp.spec
- makefiles/jprt.gmk
- makefiles/jprt.properties
- makefiles/lib/Awt2dLibraries.gmk
- makefiles/lib/CoreLibraries.gmk
- makefiles/lib/NetworkingLibraries.gmk
- makefiles/lib/NioLibraries.gmk
- makefiles/lib/PlatformLibraries.gmk
- makefiles/lib/SecurityLibraries.gmk
- makefiles/lib/ServiceabilityLibraries.gmk
- makefiles/lib/SoundLibraries.gmk
- makefiles/mapfiles/launchers/mapfile-sparc
- makefiles/mapfiles/launchers/mapfile-sparcv9
- makefiles/mapfiles/launchers/mapfile-x86
- makefiles/mapfiles/launchers/mapfile-x86_64
- makefiles/mapfiles/libattach/mapfile-linux
- makefiles/mapfiles/libattach/mapfile-solaris
- makefiles/mapfiles/libattach/reorder-windows-x86
- makefiles/mapfiles/libattach/reorder-windows-x86_64
- makefiles/mapfiles/libawt/mapfile-mawt-vers
- makefiles/mapfiles/libawt/mapfile-vers
- makefiles/mapfiles/libawt/mapfile-vers-linux
- makefiles/mapfiles/libawt_headless/mapfile-vers
- makefiles/mapfiles/libawt_headless/reorder-sparc
- makefiles/mapfiles/libawt_headless/reorder-sparcv9
- makefiles/mapfiles/libawt_headless/reorder-x86
- makefiles/mapfiles/libawt_xawt/mapfile-vers
- makefiles/mapfiles/libdcpr/mapfile-vers
- makefiles/mapfiles/libdt_socket/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers
- makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk
- makefiles/mapfiles/libhprof/mapfile-vers
- makefiles/mapfiles/libinstrument/mapfile-vers
- makefiles/mapfiles/libj2gss/mapfile-vers
- makefiles/mapfiles/libj2pcsc/mapfile-vers
- makefiles/mapfiles/libj2pkcs11/mapfile-vers
- makefiles/mapfiles/libj2ucrypto/mapfile-vers
- makefiles/mapfiles/libjaas/mapfile-vers
- makefiles/mapfiles/libjava/mapfile-vers
- makefiles/mapfiles/libjava/reorder-sparc
- makefiles/mapfiles/libjava/reorder-sparcv9
- makefiles/mapfiles/libjava/reorder-x86
- makefiles/mapfiles/libjava_crw_demo/mapfile-vers
- makefiles/mapfiles/libjawt/mapfile-vers
- makefiles/mapfiles/libjdga/mapfile-vers
- makefiles/mapfiles/libjdwp/mapfile-vers
- makefiles/mapfiles/libjfr/mapfile-vers
- makefiles/mapfiles/libjli/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers
- makefiles/mapfiles/libjpeg/mapfile-vers-closed
- makefiles/mapfiles/libjpeg/reorder-sparc
- makefiles/mapfiles/libjpeg/reorder-sparcv9
- makefiles/mapfiles/libjpeg/reorder-x86
- makefiles/mapfiles/libjsdt/mapfile-vers
- makefiles/mapfiles/libjsound/mapfile-vers
- makefiles/mapfiles/libjsoundalsa/mapfile-vers
- makefiles/mapfiles/libkcms/mapfile-vers
- makefiles/mapfiles/liblcms/mapfile-vers
- makefiles/mapfiles/libmanagement/mapfile-vers
- makefiles/mapfiles/libmlib_image/mapfile-vers
- makefiles/mapfiles/libnet/mapfile-vers
- makefiles/mapfiles/libnio/mapfile-linux
- makefiles/mapfiles/libnio/mapfile-macosx
- makefiles/mapfiles/libnio/mapfile-solaris
- makefiles/mapfiles/libnio/reorder-sparc
- makefiles/mapfiles/libnio/reorder-sparcv9
- makefiles/mapfiles/libnio/reorder-x86
- makefiles/mapfiles/libnpt/mapfile-vers
- makefiles/mapfiles/libsctp/mapfile-vers
- makefiles/mapfiles/libsplashscreen/mapfile-vers
- makefiles/mapfiles/libsunec/mapfile-vers
- makefiles/mapfiles/libt2k/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers
- makefiles/mapfiles/libunpack/mapfile-vers-unpack200
- makefiles/mapfiles/libverify/mapfile-vers
- makefiles/mapfiles/libverify/reorder-sparc
- makefiles/mapfiles/libverify/reorder-sparcv9
- makefiles/mapfiles/libverify/reorder-x86
- makefiles/mapfiles/libzip/mapfile-vers
- makefiles/mapfiles/libzip/reorder-sparc
- makefiles/mapfiles/libzip/reorder-sparcv9
- makefiles/mapfiles/libzip/reorder-x86
- makefiles/profile-includes.txt
- makefiles/profile-rtjar-includes.txt
- makefiles/scripts/addNotices.sh
- makefiles/scripts/genCharsetProvider.sh
- makefiles/scripts/genExceptions.sh
- makefiles/scripts/localelist.sh
- makefiles/sun/awt/ToBin.java
- makefiles/sun/osxapp/ToBin.java
- test/java/lang/instrument/PremainClass/NoPremainAgent.sh
- test/java/lang/instrument/PremainClass/PremainClassTest.sh
- test/java/lang/instrument/PremainClass/ZeroArgPremainAgent.sh
- test/java/text/Bidi/Bug6665028.java
- 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
- test/sun/management/jmxremote/bootstrap/solaris-i586/launcher
- test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher

Changeset: ddf4d1c3385d
Author:    lana
Date:      2013-12-05 10:30 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ddf4d1c3385d

Merge


Changeset: 68a64d582d1a
Author:    lana
Date:      2013-12-05 10:32 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/68a64d582d1a

Merge


Changeset: 5ac7cd164300
Author:    juh
Date:      2013-11-27 15:25 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5ac7cd164300

8021418: Intermittent: SSLSocketSSLEngineTemplate.java test fails with timeout
Reviewed-by: xuelei, wetmore
Contributed-by: rajan.halade at oracle.com

! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java

Changeset: 4afe1281c837
Author:    jbachorik
Date:      2013-11-28 09:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4afe1281c837

6987597: ManagementFactory.getGarbageCollectorMXBeans() returns empty list with CMS
Reviewed-by: mchung

! test/com/sun/management/GarbageCollectorMXBean/LastGCInfo.java
! test/java/lang/management/GarbageCollectorMXBean/GcInfoCompositeType.java

Changeset: 5bcaf730ceb8
Author:    tyan
Date:      2013-11-29 09:29 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5bcaf730ceb8

8029348: ProblemList.txt updates (11/2013)
Reviewed-by: chegar

! test/ProblemList.txt

Changeset: ca911e383e26
Author:    darcy
Date:      2013-12-01 23:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ca911e383e26

8006572: DoubleStream.sum() & DoubleSummaryStats implementations that reduce numerical errors
Reviewed-by: psandoz, mduigou

! src/share/classes/java/util/DoubleSummaryStatistics.java
! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/DoublePipeline.java
+ test/java/util/stream/TestDoubleSumAverage.java

Changeset: 39b3b0e77af5
Author:    msheppar
Date:      2013-12-02 14:01 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/39b3b0e77af5

8025211: Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java
Summary: modified test to execute in a single thread to eliminate potential race condition
Reviewed-by: alanb, chegar, dfuchs

! test/java/net/DatagramSocket/PortUnreachable.java

Changeset: 4ca1027a130a
Author:    vinnie
Date:      2013-12-02 14:19 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4ca1027a130a

8029369: Shell tests in sun/security/pkcs11/ do not compile PKCS11Test
Reviewed-by: mullan

! test/sun/security/pkcs11/KeyStore/Basic.sh
! test/sun/security/pkcs11/KeyStore/ClientAuth.sh
! test/sun/security/pkcs11/KeyStore/Solaris.sh
! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh
! test/sun/security/pkcs11/Provider/Login.sh

Changeset: 5b5ee2288306
Author:    naoto
Date:      2013-12-02 11:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5b5ee2288306

8028368: There is no description whether or not java.util.ResourceBundle is thread-safe
Reviewed-by: okutsu

! src/share/classes/java/util/ListResourceBundle.java
! src/share/classes/java/util/PropertyResourceBundle.java
! src/share/classes/java/util/ResourceBundle.java

Changeset: bcf5fa5e9509
Author:    lancea
Date:      2013-12-02 16:06 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bcf5fa5e9509

8029417: JDBC 4.2 javadoc updates
Reviewed-by: darcy

! src/share/classes/java/sql/CallableStatement.java
! src/share/classes/java/sql/DriverManager.java
! src/share/classes/java/sql/JDBCType.java
! src/share/classes/java/sql/PreparedStatement.java
! src/share/classes/java/sql/ResultSet.java
! src/share/classes/java/sql/SQLPermission.java

Changeset: c11553506228
Author:    sjiang
Date:      2013-12-03 08:53 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c11553506228

8029063: test/com/sun/jmx/snmp/NoInfoLeakTest.java does not compile with OpenJDK builds
Reviewed-by: alanb, dfuchs

- test/com/sun/jmx/snmp/NoInfoLeakTest.java

Changeset: e01c6e0bf8ae
Author:    michaelm
Date:      2013-12-03 17:29 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e01c6e0bf8ae

8029127: Redirected POST request throws IllegalStateException on HttpURLConnection.getInputStream
Reviewed-by: alanb, chegar

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/sun/net/www/protocol/http/RedirectOnPost.java

Changeset: 1c3d58caa7da
Author:    darcy
Date:      2013-12-03 10:07 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1c3d58caa7da

8029478: Fix more doclint issues in javax.script
Reviewed-by: chegar, mduigou

! src/share/classes/javax/script/ScriptEngineFactory.java

Changeset: 1061f4d085b5
Author:    henryjen
Date:      2013-12-03 11:37 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1061f4d085b5

8029483: BufferedReader.lines() javadoc typo should be fixed
Reviewed-by: mduigou

! src/share/classes/java/io/BufferedReader.java

Changeset: cd4aabc40f72
Author:    darcy
Date:      2013-12-03 11:52 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/cd4aabc40f72

8029475: Fix more doclint issues in javax.security
Reviewed-by: juh

! src/share/classes/javax/crypto/Cipher.java
! src/share/classes/javax/crypto/CipherSpi.java
! src/share/classes/javax/crypto/KeyGenerator.java
! src/share/classes/javax/crypto/SealedObject.java
! src/share/classes/javax/net/ssl/SSLEngine.java
! src/share/classes/javax/net/ssl/SSLPermission.java
! src/share/classes/javax/security/auth/PrivateCredentialPermission.java
! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java
! src/share/classes/javax/security/auth/kerberos/ServicePermission.java
! src/share/classes/javax/security/auth/login/LoginContext.java
! src/share/classes/javax/security/auth/x500/X500Principal.java

Changeset: c138b0d33980
Author:    bpb
Date:      2013-12-03 12:25 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c138b0d33980

8022181: Tune algorithm crossover thresholds in BigInteger
Summary: Change multiplication, squaring, division, and base conversion thresholds to values which retain performance improvement in most cases but with a a lower overall risk of regression.
Reviewed-by: darcy

! src/share/classes/java/math/BigInteger.java

Changeset: 3e95aadb479f
Author:    rriggs
Date:      2013-12-03 16:20 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3e95aadb479f

8028019: AWT Doclint warning/error cleanup
Summary: Fix numerious javadoc and html errors and warnings
Reviewed-by: yan

! src/share/classes/java/applet/Applet.java
! src/share/classes/java/applet/AppletContext.java
! src/share/classes/java/awt/AWTPermission.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/Button.java
! src/share/classes/java/awt/Checkbox.java
! src/share/classes/java/awt/CheckboxGroup.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/EventFilter.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/FileDialog.java
! src/share/classes/java/awt/FlowLayout.java
! src/share/classes/java/awt/Font.java
! src/share/classes/java/awt/Graphics.java
! src/share/classes/java/awt/GridBagConstraints.java
! src/share/classes/java/awt/GridBagLayout.java
! src/share/classes/java/awt/GridLayout.java
! src/share/classes/java/awt/Label.java
! src/share/classes/java/awt/LinearGradientPaint.java
! src/share/classes/java/awt/LinearGradientPaintContext.java
! src/share/classes/java/awt/List.java
! src/share/classes/java/awt/MenuItem.java
! src/share/classes/java/awt/RadialGradientPaint.java
! src/share/classes/java/awt/Scrollbar.java
! src/share/classes/java/awt/SystemColor.java
! src/share/classes/java/awt/SystemTray.java
! src/share/classes/java/awt/TextArea.java
! src/share/classes/java/awt/TextField.java
! src/share/classes/java/awt/Toolkit.java
! src/share/classes/java/awt/WaitDispatchSupport.java
! src/share/classes/java/awt/Window.java
! src/share/classes/java/awt/color/CMMException.java
! src/share/classes/java/awt/color/ColorSpace.java
! src/share/classes/java/awt/color/ICC_ColorSpace.java
! src/share/classes/java/awt/color/ICC_Profile.java
! src/share/classes/java/awt/color/ICC_ProfileGray.java
! src/share/classes/java/awt/color/ICC_ProfileRGB.java
! src/share/classes/java/awt/dnd/DnDEventMulticaster.java
! src/share/classes/java/awt/dnd/DragSourceDropEvent.java
! src/share/classes/java/awt/dnd/DropTarget.java
! src/share/classes/java/awt/event/MouseAdapter.java
! src/share/classes/java/awt/font/FontRenderContext.java
! src/share/classes/java/awt/font/StyledParagraph.java
! src/share/classes/java/awt/geom/AffineTransform.java
! src/share/classes/java/awt/geom/QuadCurve2D.java
! src/share/classes/java/awt/image/BufferStrategy.java
! src/share/classes/java/awt/image/BufferedImage.java
! src/share/classes/java/awt/image/ColorConvertOp.java
! src/share/classes/java/awt/peer/CheckboxPeer.java
! src/share/classes/java/awt/peer/DesktopPeer.java

Changeset: df819e356901
Author:    tyan
Date:      2013-12-03 14:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/df819e356901

7190106: java/rmi/reliability/benchmark fails intermittently because of use of fixed port
Reviewed-by: smarks, mduigou

! test/ProblemList.txt
! test/java/rmi/reliability/benchmark/bench/rmi/Main.java
! test/java/rmi/reliability/benchmark/bench/serial/Main.java
- test/java/rmi/reliability/benchmark/runRmiBench.sh
- test/java/rmi/reliability/benchmark/runSerialBench.sh

Changeset: accd6ffd4b3f
Author:    smarks
Date:      2013-12-03 15:52 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/accd6ffd4b3f

8028757: CharSequence.subSequence improperly requires a "new" CharSequence be returned
Reviewed-by: alanb, darcy, mduigou

! src/share/classes/java/lang/CharSequence.java
! src/share/classes/java/lang/String.java

Changeset: 9f624e115c6b
Author:    dfuchs
Date:      2013-12-04 01:58 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9f624e115c6b

8029281: Synchronization issues in Logger and LogManager
Summary: Fixes several race conditions in logging which have been at the root cause of intermittent test failures.
Reviewed-by: mchung, plevart

! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/logging/Logger.java
+ test/java/util/logging/TestLogConfigurationDeadLock.java
+ test/java/util/logging/TestLoggerBundleSync.java

Changeset: e1bc55ddf1ad
Author:    weijun
Date:      2013-12-04 09:14 +0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e1bc55ddf1ad

8028351: JWS doesn't get authenticated when using kerberos auth proxy
Reviewed-by: xuelei

! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
! test/sun/security/krb5/auto/KDC.java
+ test/sun/security/krb5/auto/LoginNoPass.java

Changeset: d922c8aba2f8
Author:    valeriep
Date:      2013-12-03 17:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d922c8aba2f8

8029158: sun/security/pkcs11/Signature/TestDSAKeyLength.java does not compile (or run)
Summary: Add the missing library path and skip testing against NSS 1.14 or later due to known NSS issue
Reviewed-by: vinnie, ascarpino

! test/sun/security/pkcs11/Signature/TestDSAKeyLength.java

Changeset: 75165f6c1c50
Author:    valeriep
Date:      2013-12-03 17:25 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/75165f6c1c50

Merge


Changeset: 301d76b8cb55
Author:    sherman
Date:      2013-12-03 17:44 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/301d76b8cb55

8028397: Undo the lenient MIME BASE64 decoder support change (JDK-8025003) and remove methods de/encode(buf, buf)
Summary: updated the spec and implementation as requested
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: c6b6b515cf4f
Author:    smarks
Date:      2013-12-03 18:19 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c6b6b515cf4f

8029489: StringJoiner spec for setEmptyValue() and length() is malformatted
Reviewed-by: darcy, lancea, mduigou

! src/share/classes/java/util/StringJoiner.java

Changeset: 2aae624bb833
Author:    briangoetz
Date:      2013-12-03 21:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2aae624bb833

8028816: Add value-type notice to Optional* classes
Reviewed-by: mduigou, smarks
Contributed-by: bitterfoxc at gmail.com

+ src/share/classes/java/lang/doc-files/ValueBased.html
! src/share/classes/java/util/Optional.java
! src/share/classes/java/util/OptionalDouble.java
! src/share/classes/java/util/OptionalInt.java
! src/share/classes/java/util/OptionalLong.java

Changeset: a5b8506f418a
Author:    lana
Date:      2013-12-03 23:09 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a5b8506f418a

Merge

! src/share/classes/java/awt/Container.java
! src/share/classes/java/awt/Font.java
! test/ProblemList.txt

Changeset: d30f49aa2d01
Author:    sla
Date:      2013-12-03 17:06 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d30f49aa2d01

6461635: [TESTBUG] BasicTests.sh test fails intermittently
Summary: Transform dummy class instead of BigInteger to avoid complication by -Xshare. Ported from script to java.
Reviewed-by: alanb
Contributed-by: mattias.tobiasson at oracle.com

! test/ProblemList.txt
- test/com/sun/tools/attach/AgentSetup.sh
! test/com/sun/tools/attach/Application.java
- test/com/sun/tools/attach/ApplicationSetup.sh
! test/com/sun/tools/attach/BasicTests.java
- test/com/sun/tools/attach/BasicTests.sh
- test/com/sun/tools/attach/CommonSetup.sh
! test/com/sun/tools/attach/PermissionTest.java
- test/com/sun/tools/attach/PermissionTests.sh
! test/com/sun/tools/attach/ProviderTest.java
- test/com/sun/tools/attach/ProviderTests.sh
! test/com/sun/tools/attach/RedefineAgent.java
+ test/com/sun/tools/attach/RedefineDummy.java
+ test/com/sun/tools/attach/RunnerUtil.java
! test/lib/testlibrary/jdk/testlibrary/ProcessThread.java
! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java
! test/lib/testlibrary/jdk/testlibrary/Utils.java
! test/sun/tools/jstatd/JstatdTest.java

Changeset: 2aa455506c49
Author:    psandoz
Date:      2013-12-04 10:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2aa455506c49

8029164: Race condition in CompletableFuture.thenCompose with asynchronous task
Reviewed-by: dl, chegar, mduigou

! src/share/classes/java/util/concurrent/CompletableFuture.java
+ test/java/util/concurrent/CompletableFuture/ThenComposeAsyncTest.java

Changeset: e984e2871bf7
Author:    jfranck
Date:      2013-12-04 11:04 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e984e2871bf7

8029117: (reflect) clarify javadoc for getMethod(...) and getMethods()
Reviewed-by: darcy

! src/share/classes/java/lang/Class.java

Changeset: 6d583b9d99e1
Author:    henryjen
Date:      2013-12-04 08:12 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6d583b9d99e1

8029434: Spliterator of Stream returned by BufferedReader.lines() should have NONNULL characteristic
Reviewed-by: mduigou

! src/share/classes/java/io/BufferedReader.java
! test/java/io/BufferedReader/Lines.java

Changeset: 0f1332dd805c
Author:    coffeys
Date:      2013-12-04 17:03 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0f1332dd805c

8029347: sun/rmi/runtime/Log/checkLogging/CheckLogging.java fails in nightly intermittently
Reviewed-by: alanb

! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java

Changeset: a3b804e3d5f7
Author:    mchung
Date:      2013-12-04 09:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a3b804e3d5f7

7067973: test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java hanging intermittently
Reviewed-by: mchung
Contributed-by: yiming.wang at oracle.com

! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh

Changeset: 6a5a54193118
Author:    mfang
Date:      2013-12-04 09:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6a5a54193118

8027244: Need to translate new error message and usage information for jar tool
Reviewed-by: naoto, yhuang

! src/share/classes/sun/tools/jar/resources/jar_de.properties
! src/share/classes/sun/tools/jar/resources/jar_es.properties
! src/share/classes/sun/tools/jar/resources/jar_fr.properties
! 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_ko.properties
! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties
! src/share/classes/sun/tools/jar/resources/jar_sv.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties

Changeset: bfe3a26a2c5e
Author:    mfang
Date:      2013-12-04 09:32 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bfe3a26a2c5e

Merge

- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh

Changeset: 2a6611ebfb6c
Author:    smarks
Date:      2013-12-04 18:02 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2a6611ebfb6c

8029141: Add @FunctionalInterface annotation to Callable interface
Reviewed-by: chegar, alanb

! src/share/classes/java/util/concurrent/Callable.java

Changeset: 6deabb82f72b
Author:    ascarpino
Date:      2013-12-04 10:59 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6deabb82f72b

8027218: TEST_BUG: sun/security/pkcs11/ec tests fail because of ever-changing key size restrictions
Reviewed-by: vinnie

! test/sun/security/pkcs11/PKCS11Test.java
! test/sun/security/pkcs11/ec/ReadCertificates.java
! test/sun/security/pkcs11/ec/TestCurves.java

Changeset: 4345e3e82c55
Author:    mchung
Date:      2013-12-04 13:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4345e3e82c55

8029552: Remove java/lang/management/MemoryMXBean/CollectionUsageThreshold.java from ProblemList.txt
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: 014c04fd7460
Author:    ascarpino
Date:      2013-12-04 17:37 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/014c04fd7460

8029550: javadoc since tag for recent Hashtable updates
Reviewed-by: mullan

! src/share/classes/java/security/Provider.java

Changeset: 427c78c88229
Author:    erikj
Date:      2013-12-05 09:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/427c78c88229

8027963: Create unlimited policy jars.
Reviewed-by: wetmore, ihse

! make/CreateSecurityJars.gmk
! make/SignJars.gmk
- make/data/cryptopolicy/limited/LIMITED
- make/data/cryptopolicy/unlimited/UNLIMITED

Changeset: dc2f0c40399a
Author:    psandoz
Date:      2013-12-05 09:44 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dc2f0c40399a

8028564: Concurrent calls to CHM.put can fail to add the key/value to the map
Reviewed-by: psandoz, chegar, alanb
Contributed-by: Doug Lea <dl at cs.oswego.edu>

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
+ test/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java
+ test/java/util/concurrent/ConcurrentHashMap/ConcurrentContainsKeyTest.java

Changeset: 8534e297484d
Author:    yan
Date:      2013-12-05 18:04 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8534e297484d

8029264: [doclint] more doclint and tidy cleanup
Reviewed-by: alexsch, serb, malenkov

! src/share/classes/javax/swing/Action.java
! src/share/classes/javax/swing/DefaultComboBoxModel.java
! src/share/classes/javax/swing/GroupLayout.java
! src/share/classes/javax/swing/InputVerifier.java
! src/share/classes/javax/swing/JComponent.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/JLayeredPane.java
! src/share/classes/javax/swing/JList.java
! src/share/classes/javax/swing/JOptionPane.java
! src/share/classes/javax/swing/JScrollBar.java
! src/share/classes/javax/swing/JScrollPane.java
! src/share/classes/javax/swing/JTable.java
! src/share/classes/javax/swing/JTextArea.java
! src/share/classes/javax/swing/JTextPane.java
! src/share/classes/javax/swing/JTree.java
! src/share/classes/javax/swing/LookAndFeel.java
! src/share/classes/javax/swing/Painter.java
! src/share/classes/javax/swing/RowFilter.java
! src/share/classes/javax/swing/SizeSequence.java
! src/share/classes/javax/swing/Spring.java
! src/share/classes/javax/swing/SpringLayout.java
! src/share/classes/javax/swing/SwingWorker.java
! src/share/classes/javax/swing/border/CompoundBorder.java
! src/share/classes/javax/swing/event/TableModelEvent.java
! src/share/classes/javax/swing/event/TreeModelListener.java
! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java
! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java
! src/share/classes/javax/swing/table/DefaultTableModel.java
! src/share/classes/javax/swing/table/TableModel.java
! src/share/classes/javax/swing/text/AbstractDocument.java
! src/share/classes/javax/swing/text/DefaultEditorKit.java
! src/share/classes/javax/swing/text/Document.java
! src/share/classes/javax/swing/text/JTextComponent.java
! src/share/classes/javax/swing/text/View.java
! src/share/classes/javax/swing/text/html/HTMLDocument.java
! src/share/classes/javax/swing/text/html/HTMLEditorKit.java
! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java

Changeset: d3c4e8fe98c3
Author:    bpb
Date:      2013-12-05 07:44 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d3c4e8fe98c3

8029514: java/math/BigInteger/BigIntegerTest.java failing since thresholds adjusted in 8022181
Summary: Ensure the value returned by getLower() is unsigned.
Reviewed-by: darcy

! src/share/classes/java/math/BigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java

Changeset: 303f4bccfca2
Author:    bpb
Date:      2013-12-05 07:45 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/303f4bccfca2

8029501: BigInteger division algorithm selection heuristic is incorrect
Summary: Change Burnikel-Ziegler division heuristic to require that the dividend int-length exceed that of the divisor by a minimum amount.
Reviewed-by: darcy

! src/share/classes/java/math/BigInteger.java
! src/share/classes/java/math/MutableBigInteger.java

Changeset: 72ea199e3e1b
Author:    robm
Date:      2013-12-05 16:19 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/72ea199e3e1b

8029525: java/lang/ProcessBuilder/Basic.java fails intermittently
Reviewed-by: alanb, chegar
Contributed-by: roger.riggs at oracle.com

! test/java/lang/ProcessBuilder/Basic.java

Changeset: 7ecaa4402c4e
Author:    lana
Date:      2013-12-05 10:33 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7ecaa4402c4e

Merge

- make/data/cryptopolicy/limited/LIMITED
- make/data/cryptopolicy/unlimited/UNLIMITED
- test/com/sun/jmx/snmp/NoInfoLeakTest.java
- test/com/sun/tools/attach/AgentSetup.sh
- test/com/sun/tools/attach/ApplicationSetup.sh
- test/com/sun/tools/attach/BasicTests.sh
- test/com/sun/tools/attach/CommonSetup.sh
- test/com/sun/tools/attach/PermissionTests.sh
- test/com/sun/tools/attach/ProviderTests.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh
- test/java/rmi/reliability/benchmark/runRmiBench.sh
- test/java/rmi/reliability/benchmark/runSerialBench.sh

Changeset: d31cd980e1da
Author:    rgallard
Date:      2013-12-10 15:20 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d31cd980e1da

8029616: Update jdeps man page to include a new -jdkinternals option
Reviewed-by: mchung

! src/bsd/doc/man/jdeps.1
! src/linux/doc/man/jdeps.1
! src/solaris/doc/sun/man/man1/jdeps.1

Changeset: 27b384262cba
Author:    katleman
Date:      2013-12-12 05:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/27b384262cba

Added tag jdk8-b120 for changeset d31cd980e1da

! .hgtags

Changeset: 78d395c7c479
Author:    lana
Date:      2013-12-12 20:04 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/78d395c7c479

Merge

- make/data/cryptopolicy/limited/LIMITED
- make/data/cryptopolicy/unlimited/UNLIMITED
- test/com/sun/jmx/snmp/NoInfoLeakTest.java
- test/com/sun/tools/attach/AgentSetup.sh
- test/com/sun/tools/attach/ApplicationSetup.sh
- test/com/sun/tools/attach/BasicTests.sh
- test/com/sun/tools/attach/CommonSetup.sh
- test/com/sun/tools/attach/PermissionTests.sh
- test/com/sun/tools/attach/ProviderTests.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh
- test/java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh
- test/java/rmi/reliability/benchmark/runRmiBench.sh
- test/java/rmi/reliability/benchmark/runSerialBench.sh


From alexander.zvegintsev at oracle.com  Fri Dec 13 02:16:36 2013
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 13 Dec 2013 14:16:36 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029263, ,
 The user's default browser can not launch after we click the button,
 and there is an IOException shown in the log txt (java.io.IOException)
In-Reply-To: <52AA2F64.8000101@oracle.com>
References: <52A9EC7C.6000200@oracle.com> <52AA1CF9.8010203@oracle.com>
	<52AA2B6A.902@oracle.com> <52AA2F64.8000101@oracle.com>
Message-ID: <52AADE84.3080601@oracle.com>

Hi Anthony,

the updated webrev is here:
http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.01/
I also removed a redundant null check in XDesktopPeer.isSupported()

The new RFE for 9 is here:
https://bugs.openjdk.java.net/browse/JDK-8030100

> A follow-up question regarding #3: do you know which specific 
> library/software module needs to be installed in order to support 
> those other URI schemes? It might be useful to add this info to the 
> bug report so that people know what they need to install additionally 
> if they need to access such URIs. 
Unfortunately I don't know currently. But I think this info can be added 
later, when I will investigate a new RFE.

Thanks,

Alexander.

On 12/13/2013 01:49 AM, Anthony Petrov wrote:
> Thanks for the clarifications, Alexander. Looking forward to an 
> updated webrev.
>
> As for #4, I understand that we want to minimize the risk for this fix 
> now, so late in the release. And I'm fine with that. However, I still 
> suggest to file an RFE targeted for 9 to enable this behavior for 
> Linux as well. I reckon a Linux system can also be configured not to 
> support additional URI schemes, so in general, I see no reason to skip 
> this check on Linux.
>
> A follow-up question regarding #3: do you know which specific 
> library/software module needs to be installed in order to support 
> those other URI schemes? It might be useful to add this info to the 
> bug report so that people know what they need to install additionally 
> if they need to access such URIs.
>
> -- 
> best regards,
> Anthony
>
> On 12/13/2013 01:32 AM, Alexander Zvegintsev wrote:
>> Hi Anthony,
>>
>> Please see inline
>> 13.12.2013 0:30, Anthony Petrov wrote:
>>> Hi Alexander,
>>>
>>> 1. Please add your evaluation to the bug report.
>>>
>>> 2. In gtk2_interface.c: can we declare the i variable somewhere closer
>>> to where it is used? What's the point with all these forward
>>> declarations? We don't compile with C89, do we?
>> Sure.
>>>
>>> 3. Checking for http: to enable the BROWSE action looks reasonable to
>>> me. And I suggest to check for the mailto: scheme separately, so that
>>> the MAIL action is only enabled if it's supported.
>>  From my testing if we have http scheme in this list(list of supported
>> URI schemes) we are able to open https://, ftp:// and mail: URIs (BTW
>> there is no https:// and mail: schemes in this list, and mail: is not
>> actually a valid URI).
>> If we have only file scheme in this list all other URIs will not work
>> and gtk_show_uri() will return "Operation not supported" message for
>> such URIs.
>> So this part of code is just an educated guess to check is gvfs
>> supported or not. It may be fragile(it depends on environment variables
>> set) but it is better then nothing.
>>
>> Most of machines with Solaris 11 installed which I tested always return
>> only file scheme in this list for 64-bit, so in general case we will
>> support only an OPEN action.
>>
>>> 4.
>>>>  534 #ifdef __solaris__
>>>>  535             update_supported_actions(env);
>>>>  536 #endif
>>>
>>> Have you tested this on Linux with your patch applied? How is the list
>>> of supported actions supposed to be populated on that platform?
>> Linux behaves as before the fix:
>> For Linux this list is already populated in initializer and remains
>> untouched from native:
>>> +    private static final List<Action> supportedActions
>>> +            = new ArrayList<>(Arrays.asList(Action.OPEN, 
>>> Action.MAIL, Action.BROWSE))
>> The list of supported actions is the same as before the patch (OPEN,
>> MAIL, BROWSE). I tested this on OEL 5, 6, Ubuntu 13.04 all works as
>> expected.
>> So only for Solaris we clear this list and populate it from a native.
>>
>>>
>>> 5. In XDesktopPeer.java: please move the comment at line 51 above the
>>> field that it describes.
>>
>> -- 
>> Thanks,
>> Alexander.
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 12/12/2013 09:03 PM, Alexander Zvegintsev wrote:
>>>> Hello AWT team,
>>>>
>>>> Please review fix
>>>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.00/
>>>> for
>>>> https://bugs.openjdk.java.net/browse/JDK-8029263
>>>>
>>>> This issue can be observed on Solaris 11 (sparcv9 or x86_64).
>>>>
>>>> gtk_show_uri() documentation[1] says:
>>>>> The uri must be of a form understood by GIO (i.e. you need to install
>>>>> gvfs to get support for uri schemes such as http:// or ftp://, as 
>>>>> only
>>>>> local files are handled by GIO itself).
>>>> However it looks like that Solaris 11 supports gvfs for 32-bit
>>>> applications only by default. gtk_show_uri() returns "Operation not
>>>> supported" error message  for 64-bit applications
>>>> for schemes other than file://.
>>>>
>>>> Since b110 we don't have 32-bit JDK for Solaris anymore, so in most
>>>> cases only an OPEN action is available(file://).
>>>>
>>>> Currently I am unable to find any robust way to determine do we have
>>>> full gvfs support to handle URIs like mail:, http:// or not.
>>>>
>>>> We can use g_vfs_get_supported_uri_schemes()[2] and assume that we 
>>>> have
>>>> full gvfs support if http:// scheme is present.
>>>> But this function depends on a DBUS_SESSION_BUS_ADDRESS environment
>>>> variable, which can be stripped off in some tests
>>>> (in this case only file:// scheme will be returned).
>>>>
>>>>
>>>> Old gnome_url_show() will not work  too due to lack of 64-bit
>>>> libgnomevfs-2.0 library.
>>>>
>>>>
>>>>
>>>> [1]
>>>> https://developer.gnome.org/gtk2/stable/gtk2-Filesystem-utilities.html#gtk-show-uri 
>>>>
>>>>
>>>> [2]
>>>> https://developer.gnome.org/gio/stable/GVfs.html#g-vfs-get-supported-uri-schemes 
>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Thanks,
>>>>
>>>> Alexander.
>>>>
>>


From artem.ananiev at oracle.com  Fri Dec 13 02:32:21 2013
From: artem.ananiev at oracle.com (artem.ananiev at oracle.com)
Date: Fri, 13 Dec 2013 10:32:21 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 8029923: Many Swing tests and SwingSet2
	are failing	under Solaris using GTK LaF - "Unable to load
	native GTK libraries"
Message-ID: <20131213103350.8968F62CB8@hg.openjdk.java.net>

Changeset: 20d504a20a87
Author:    azvegint
Date:      2013-12-13 14:29 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/20d504a20a87

8029923: Many Swing tests and SwingSet2 are failing under Solaris using GTK LaF - "Unable to load native GTK libraries"
Reviewed-by: anthony, serb

! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h


From anthony.petrov at oracle.com  Fri Dec 13 04:33:11 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 13 Dec 2013 16:33:11 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029263, ,
 The user's default browser can not launch after we click the button,
 and there is an IOException shown in the log txt (java.io.IOException)
In-Reply-To: <52AADE84.3080601@oracle.com>
References: <52A9EC7C.6000200@oracle.com> <52AA1CF9.8010203@oracle.com>
	<52AA2B6A.902@oracle.com> <52AA2F64.8000101@oracle.com>
	<52AADE84.3080601@oracle.com>
Message-ID: <52AAFE87.4020203@oracle.com>

Hi Alexander,

The fix looks much better. Though I still don't understand why you 
declare the i variable in update_supported_actions() so far from the 
place where it is used. What would go wrong if you moved the declaration 
inside the if() block just above your while() loop? It's not referenced 
from anywhere else, is it?

Thanks for filing a new RFE. Please update its Description with some 
meaningful text that would describe what actually is requested/needs to 
be investigated.

--
best regards,
Anthony

On 12/13/2013 02:16 PM, Alexander Zvegintsev wrote:
> Hi Anthony,
>
> the updated webrev is here:
> http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.01/
> I also removed a redundant null check in XDesktopPeer.isSupported()
>
> The new RFE for 9 is here:
> https://bugs.openjdk.java.net/browse/JDK-8030100
>
>> A follow-up question regarding #3: do you know which specific
>> library/software module needs to be installed in order to support
>> those other URI schemes? It might be useful to add this info to the
>> bug report so that people know what they need to install additionally
>> if they need to access such URIs.
> Unfortunately I don't know currently. But I think this info can be added
> later, when I will investigate a new RFE.
>
> Thanks,
>
> Alexander.
>
> On 12/13/2013 01:49 AM, Anthony Petrov wrote:
>> Thanks for the clarifications, Alexander. Looking forward to an
>> updated webrev.
>>
>> As for #4, I understand that we want to minimize the risk for this fix
>> now, so late in the release. And I'm fine with that. However, I still
>> suggest to file an RFE targeted for 9 to enable this behavior for
>> Linux as well. I reckon a Linux system can also be configured not to
>> support additional URI schemes, so in general, I see no reason to skip
>> this check on Linux.
>>
>> A follow-up question regarding #3: do you know which specific
>> library/software module needs to be installed in order to support
>> those other URI schemes? It might be useful to add this info to the
>> bug report so that people know what they need to install additionally
>> if they need to access such URIs.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/13/2013 01:32 AM, Alexander Zvegintsev wrote:
>>> Hi Anthony,
>>>
>>> Please see inline
>>> 13.12.2013 0:30, Anthony Petrov wrote:
>>>> Hi Alexander,
>>>>
>>>> 1. Please add your evaluation to the bug report.
>>>>
>>>> 2. In gtk2_interface.c: can we declare the i variable somewhere closer
>>>> to where it is used? What's the point with all these forward
>>>> declarations? We don't compile with C89, do we?
>>> Sure.
>>>>
>>>> 3. Checking for http: to enable the BROWSE action looks reasonable to
>>>> me. And I suggest to check for the mailto: scheme separately, so that
>>>> the MAIL action is only enabled if it's supported.
>>>  From my testing if we have http scheme in this list(list of supported
>>> URI schemes) we are able to open https://, ftp:// and mail: URIs (BTW
>>> there is no https:// and mail: schemes in this list, and mail: is not
>>> actually a valid URI).
>>> If we have only file scheme in this list all other URIs will not work
>>> and gtk_show_uri() will return "Operation not supported" message for
>>> such URIs.
>>> So this part of code is just an educated guess to check is gvfs
>>> supported or not. It may be fragile(it depends on environment variables
>>> set) but it is better then nothing.
>>>
>>> Most of machines with Solaris 11 installed which I tested always return
>>> only file scheme in this list for 64-bit, so in general case we will
>>> support only an OPEN action.
>>>
>>>> 4.
>>>>>  534 #ifdef __solaris__
>>>>>  535             update_supported_actions(env);
>>>>>  536 #endif
>>>>
>>>> Have you tested this on Linux with your patch applied? How is the list
>>>> of supported actions supposed to be populated on that platform?
>>> Linux behaves as before the fix:
>>> For Linux this list is already populated in initializer and remains
>>> untouched from native:
>>>> +    private static final List<Action> supportedActions
>>>> +            = new ArrayList<>(Arrays.asList(Action.OPEN,
>>>> Action.MAIL, Action.BROWSE))
>>> The list of supported actions is the same as before the patch (OPEN,
>>> MAIL, BROWSE). I tested this on OEL 5, 6, Ubuntu 13.04 all works as
>>> expected.
>>> So only for Solaris we clear this list and populate it from a native.
>>>
>>>>
>>>> 5. In XDesktopPeer.java: please move the comment at line 51 above the
>>>> field that it describes.
>>>
>>> --
>>> Thanks,
>>> Alexander.
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 12/12/2013 09:03 PM, Alexander Zvegintsev wrote:
>>>>> Hello AWT team,
>>>>>
>>>>> Please review fix
>>>>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.00/
>>>>> for
>>>>> https://bugs.openjdk.java.net/browse/JDK-8029263
>>>>>
>>>>> This issue can be observed on Solaris 11 (sparcv9 or x86_64).
>>>>>
>>>>> gtk_show_uri() documentation[1] says:
>>>>>> The uri must be of a form understood by GIO (i.e. you need to install
>>>>>> gvfs to get support for uri schemes such as http:// or ftp://, as
>>>>>> only
>>>>>> local files are handled by GIO itself).
>>>>> However it looks like that Solaris 11 supports gvfs for 32-bit
>>>>> applications only by default. gtk_show_uri() returns "Operation not
>>>>> supported" error message  for 64-bit applications
>>>>> for schemes other than file://.
>>>>>
>>>>> Since b110 we don't have 32-bit JDK for Solaris anymore, so in most
>>>>> cases only an OPEN action is available(file://).
>>>>>
>>>>> Currently I am unable to find any robust way to determine do we have
>>>>> full gvfs support to handle URIs like mail:, http:// or not.
>>>>>
>>>>> We can use g_vfs_get_supported_uri_schemes()[2] and assume that we
>>>>> have
>>>>> full gvfs support if http:// scheme is present.
>>>>> But this function depends on a DBUS_SESSION_BUS_ADDRESS environment
>>>>> variable, which can be stripped off in some tests
>>>>> (in this case only file:// scheme will be returned).
>>>>>
>>>>>
>>>>> Old gnome_url_show() will not work  too due to lack of 64-bit
>>>>> libgnomevfs-2.0 library.
>>>>>
>>>>>
>>>>>
>>>>> [1]
>>>>> https://developer.gnome.org/gtk2/stable/gtk2-Filesystem-utilities.html#gtk-show-uri
>>>>>
>>>>>
>>>>> [2]
>>>>> https://developer.gnome.org/gio/stable/GVfs.html#g-vfs-get-supported-uri-schemes
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>>
>>>>> Alexander.
>>>>>
>>>
>

From alexander.zvegintsev at oracle.com  Fri Dec 13 04:44:30 2013
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 13 Dec 2013 16:44:30 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029263, ,
 The user's default browser can not launch after we click the button,
 and there is an IOException shown in the log txt (java.io.IOException)
In-Reply-To: <52AAFE87.4020203@oracle.com>
References: <52A9EC7C.6000200@oracle.com> <52AA1CF9.8010203@oracle.com>
	<52AA2B6A.902@oracle.com> <52AA2F64.8000101@oracle.com>
	<52AADE84.3080601@oracle.com> <52AAFE87.4020203@oracle.com>
Message-ID: <52AB012E.3040001@oracle.com>

Sure,  webrev updated in place.
I also updated the RFE description.

Thanks,

Alexander.

On 12/13/2013 04:33 PM, Anthony Petrov wrote:
> Hi Alexander,
>
> The fix looks much better. Though I still don't understand why you 
> declare the i variable in update_supported_actions() so far from the 
> place where it is used. What would go wrong if you moved the 
> declaration inside the if() block just above your while() loop? It's 
> not referenced from anywhere else, is it?
>
> Thanks for filing a new RFE. Please update its Description with some 
> meaningful text that would describe what actually is requested/needs 
> to be investigated.
>
> -- 
> best regards,
> Anthony
>
> On 12/13/2013 02:16 PM, Alexander Zvegintsev wrote:
>> Hi Anthony,
>>
>> the updated webrev is here:
>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.01/
>> I also removed a redundant null check in XDesktopPeer.isSupported()
>>
>> The new RFE for 9 is here:
>> https://bugs.openjdk.java.net/browse/JDK-8030100
>>
>>> A follow-up question regarding #3: do you know which specific
>>> library/software module needs to be installed in order to support
>>> those other URI schemes? It might be useful to add this info to the
>>> bug report so that people know what they need to install additionally
>>> if they need to access such URIs.
>> Unfortunately I don't know currently. But I think this info can be added
>> later, when I will investigate a new RFE.
>>
>> Thanks,
>>
>> Alexander.
>>
>> On 12/13/2013 01:49 AM, Anthony Petrov wrote:
>>> Thanks for the clarifications, Alexander. Looking forward to an
>>> updated webrev.
>>>
>>> As for #4, I understand that we want to minimize the risk for this fix
>>> now, so late in the release. And I'm fine with that. However, I still
>>> suggest to file an RFE targeted for 9 to enable this behavior for
>>> Linux as well. I reckon a Linux system can also be configured not to
>>> support additional URI schemes, so in general, I see no reason to skip
>>> this check on Linux.
>>>
>>> A follow-up question regarding #3: do you know which specific
>>> library/software module needs to be installed in order to support
>>> those other URI schemes? It might be useful to add this info to the
>>> bug report so that people know what they need to install additionally
>>> if they need to access such URIs.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 12/13/2013 01:32 AM, Alexander Zvegintsev wrote:
>>>> Hi Anthony,
>>>>
>>>> Please see inline
>>>> 13.12.2013 0:30, Anthony Petrov wrote:
>>>>> Hi Alexander,
>>>>>
>>>>> 1. Please add your evaluation to the bug report.
>>>>>
>>>>> 2. In gtk2_interface.c: can we declare the i variable somewhere 
>>>>> closer
>>>>> to where it is used? What's the point with all these forward
>>>>> declarations? We don't compile with C89, do we?
>>>> Sure.
>>>>>
>>>>> 3. Checking for http: to enable the BROWSE action looks reasonable to
>>>>> me. And I suggest to check for the mailto: scheme separately, so that
>>>>> the MAIL action is only enabled if it's supported.
>>>>  From my testing if we have http scheme in this list(list of supported
>>>> URI schemes) we are able to open https://, ftp:// and mail: URIs (BTW
>>>> there is no https:// and mail: schemes in this list, and mail: is not
>>>> actually a valid URI).
>>>> If we have only file scheme in this list all other URIs will not work
>>>> and gtk_show_uri() will return "Operation not supported" message for
>>>> such URIs.
>>>> So this part of code is just an educated guess to check is gvfs
>>>> supported or not. It may be fragile(it depends on environment 
>>>> variables
>>>> set) but it is better then nothing.
>>>>
>>>> Most of machines with Solaris 11 installed which I tested always 
>>>> return
>>>> only file scheme in this list for 64-bit, so in general case we will
>>>> support only an OPEN action.
>>>>
>>>>> 4.
>>>>>>  534 #ifdef __solaris__
>>>>>>  535             update_supported_actions(env);
>>>>>>  536 #endif
>>>>>
>>>>> Have you tested this on Linux with your patch applied? How is the 
>>>>> list
>>>>> of supported actions supposed to be populated on that platform?
>>>> Linux behaves as before the fix:
>>>> For Linux this list is already populated in initializer and remains
>>>> untouched from native:
>>>>> +    private static final List<Action> supportedActions
>>>>> +            = new ArrayList<>(Arrays.asList(Action.OPEN,
>>>>> Action.MAIL, Action.BROWSE))
>>>> The list of supported actions is the same as before the patch (OPEN,
>>>> MAIL, BROWSE). I tested this on OEL 5, 6, Ubuntu 13.04 all works as
>>>> expected.
>>>> So only for Solaris we clear this list and populate it from a native.
>>>>
>>>>>
>>>>> 5. In XDesktopPeer.java: please move the comment at line 51 above the
>>>>> field that it describes.
>>>>
>>>> -- 
>>>> Thanks,
>>>> Alexander.
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 12/12/2013 09:03 PM, Alexander Zvegintsev wrote:
>>>>>> Hello AWT team,
>>>>>>
>>>>>> Please review fix
>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.00/
>>>>>> for
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8029263
>>>>>>
>>>>>> This issue can be observed on Solaris 11 (sparcv9 or x86_64).
>>>>>>
>>>>>> gtk_show_uri() documentation[1] says:
>>>>>>> The uri must be of a form understood by GIO (i.e. you need to 
>>>>>>> install
>>>>>>> gvfs to get support for uri schemes such as http:// or ftp://, as
>>>>>>> only
>>>>>>> local files are handled by GIO itself).
>>>>>> However it looks like that Solaris 11 supports gvfs for 32-bit
>>>>>> applications only by default. gtk_show_uri() returns "Operation not
>>>>>> supported" error message  for 64-bit applications
>>>>>> for schemes other than file://.
>>>>>>
>>>>>> Since b110 we don't have 32-bit JDK for Solaris anymore, so in most
>>>>>> cases only an OPEN action is available(file://).
>>>>>>
>>>>>> Currently I am unable to find any robust way to determine do we have
>>>>>> full gvfs support to handle URIs like mail:, http:// or not.
>>>>>>
>>>>>> We can use g_vfs_get_supported_uri_schemes()[2] and assume that we
>>>>>> have
>>>>>> full gvfs support if http:// scheme is present.
>>>>>> But this function depends on a DBUS_SESSION_BUS_ADDRESS environment
>>>>>> variable, which can be stripped off in some tests
>>>>>> (in this case only file:// scheme will be returned).
>>>>>>
>>>>>>
>>>>>> Old gnome_url_show() will not work  too due to lack of 64-bit
>>>>>> libgnomevfs-2.0 library.
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> https://developer.gnome.org/gtk2/stable/gtk2-Filesystem-utilities.html#gtk-show-uri 
>>>>>>
>>>>>>
>>>>>>
>>>>>> [2]
>>>>>> https://developer.gnome.org/gio/stable/GVfs.html#g-vfs-get-supported-uri-schemes 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Thanks,
>>>>>>
>>>>>> Alexander.
>>>>>>
>>>>
>>


From anthony.petrov at oracle.com  Fri Dec 13 04:49:16 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 13 Dec 2013 16:49:16 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029263, ,
 The user's default browser can not launch after we click the button,
 and there is an IOException shown in the log txt (java.io.IOException)
In-Reply-To: <52AB012E.3040001@oracle.com>
References: <52A9EC7C.6000200@oracle.com> <52AA1CF9.8010203@oracle.com>
	<52AA2B6A.902@oracle.com> <52AA2F64.8000101@oracle.com>
	<52AADE84.3080601@oracle.com> <52AAFE87.4020203@oracle.com>
	<52AB012E.3040001@oracle.com>
Message-ID: <52AB024C.8020902@oracle.com>

Thanks. The fix looks good to me now.

--
best regards,
Anthony

On 12/13/2013 04:44 PM, Alexander Zvegintsev wrote:
> Sure,  webrev updated in place.
> I also updated the RFE description.
>
> Thanks,
>
> Alexander.
>
> On 12/13/2013 04:33 PM, Anthony Petrov wrote:
>> Hi Alexander,
>>
>> The fix looks much better. Though I still don't understand why you
>> declare the i variable in update_supported_actions() so far from the
>> place where it is used. What would go wrong if you moved the
>> declaration inside the if() block just above your while() loop? It's
>> not referenced from anywhere else, is it?
>>
>> Thanks for filing a new RFE. Please update its Description with some
>> meaningful text that would describe what actually is requested/needs
>> to be investigated.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/13/2013 02:16 PM, Alexander Zvegintsev wrote:
>>> Hi Anthony,
>>>
>>> the updated webrev is here:
>>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.01/
>>> I also removed a redundant null check in XDesktopPeer.isSupported()
>>>
>>> The new RFE for 9 is here:
>>> https://bugs.openjdk.java.net/browse/JDK-8030100
>>>
>>>> A follow-up question regarding #3: do you know which specific
>>>> library/software module needs to be installed in order to support
>>>> those other URI schemes? It might be useful to add this info to the
>>>> bug report so that people know what they need to install additionally
>>>> if they need to access such URIs.
>>> Unfortunately I don't know currently. But I think this info can be added
>>> later, when I will investigate a new RFE.
>>>
>>> Thanks,
>>>
>>> Alexander.
>>>
>>> On 12/13/2013 01:49 AM, Anthony Petrov wrote:
>>>> Thanks for the clarifications, Alexander. Looking forward to an
>>>> updated webrev.
>>>>
>>>> As for #4, I understand that we want to minimize the risk for this fix
>>>> now, so late in the release. And I'm fine with that. However, I still
>>>> suggest to file an RFE targeted for 9 to enable this behavior for
>>>> Linux as well. I reckon a Linux system can also be configured not to
>>>> support additional URI schemes, so in general, I see no reason to skip
>>>> this check on Linux.
>>>>
>>>> A follow-up question regarding #3: do you know which specific
>>>> library/software module needs to be installed in order to support
>>>> those other URI schemes? It might be useful to add this info to the
>>>> bug report so that people know what they need to install additionally
>>>> if they need to access such URIs.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 12/13/2013 01:32 AM, Alexander Zvegintsev wrote:
>>>>> Hi Anthony,
>>>>>
>>>>> Please see inline
>>>>> 13.12.2013 0:30, Anthony Petrov wrote:
>>>>>> Hi Alexander,
>>>>>>
>>>>>> 1. Please add your evaluation to the bug report.
>>>>>>
>>>>>> 2. In gtk2_interface.c: can we declare the i variable somewhere
>>>>>> closer
>>>>>> to where it is used? What's the point with all these forward
>>>>>> declarations? We don't compile with C89, do we?
>>>>> Sure.
>>>>>>
>>>>>> 3. Checking for http: to enable the BROWSE action looks reasonable to
>>>>>> me. And I suggest to check for the mailto: scheme separately, so that
>>>>>> the MAIL action is only enabled if it's supported.
>>>>>  From my testing if we have http scheme in this list(list of supported
>>>>> URI schemes) we are able to open https://, ftp:// and mail: URIs (BTW
>>>>> there is no https:// and mail: schemes in this list, and mail: is not
>>>>> actually a valid URI).
>>>>> If we have only file scheme in this list all other URIs will not work
>>>>> and gtk_show_uri() will return "Operation not supported" message for
>>>>> such URIs.
>>>>> So this part of code is just an educated guess to check is gvfs
>>>>> supported or not. It may be fragile(it depends on environment
>>>>> variables
>>>>> set) but it is better then nothing.
>>>>>
>>>>> Most of machines with Solaris 11 installed which I tested always
>>>>> return
>>>>> only file scheme in this list for 64-bit, so in general case we will
>>>>> support only an OPEN action.
>>>>>
>>>>>> 4.
>>>>>>>  534 #ifdef __solaris__
>>>>>>>  535             update_supported_actions(env);
>>>>>>>  536 #endif
>>>>>>
>>>>>> Have you tested this on Linux with your patch applied? How is the
>>>>>> list
>>>>>> of supported actions supposed to be populated on that platform?
>>>>> Linux behaves as before the fix:
>>>>> For Linux this list is already populated in initializer and remains
>>>>> untouched from native:
>>>>>> +    private static final List<Action> supportedActions
>>>>>> +            = new ArrayList<>(Arrays.asList(Action.OPEN,
>>>>>> Action.MAIL, Action.BROWSE))
>>>>> The list of supported actions is the same as before the patch (OPEN,
>>>>> MAIL, BROWSE). I tested this on OEL 5, 6, Ubuntu 13.04 all works as
>>>>> expected.
>>>>> So only for Solaris we clear this list and populate it from a native.
>>>>>
>>>>>>
>>>>>> 5. In XDesktopPeer.java: please move the comment at line 51 above the
>>>>>> field that it describes.
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Alexander.
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 12/12/2013 09:03 PM, Alexander Zvegintsev wrote:
>>>>>>> Hello AWT team,
>>>>>>>
>>>>>>> Please review fix
>>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.00/
>>>>>>> for
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8029263
>>>>>>>
>>>>>>> This issue can be observed on Solaris 11 (sparcv9 or x86_64).
>>>>>>>
>>>>>>> gtk_show_uri() documentation[1] says:
>>>>>>>> The uri must be of a form understood by GIO (i.e. you need to
>>>>>>>> install
>>>>>>>> gvfs to get support for uri schemes such as http:// or ftp://, as
>>>>>>>> only
>>>>>>>> local files are handled by GIO itself).
>>>>>>> However it looks like that Solaris 11 supports gvfs for 32-bit
>>>>>>> applications only by default. gtk_show_uri() returns "Operation not
>>>>>>> supported" error message  for 64-bit applications
>>>>>>> for schemes other than file://.
>>>>>>>
>>>>>>> Since b110 we don't have 32-bit JDK for Solaris anymore, so in most
>>>>>>> cases only an OPEN action is available(file://).
>>>>>>>
>>>>>>> Currently I am unable to find any robust way to determine do we have
>>>>>>> full gvfs support to handle URIs like mail:, http:// or not.
>>>>>>>
>>>>>>> We can use g_vfs_get_supported_uri_schemes()[2] and assume that we
>>>>>>> have
>>>>>>> full gvfs support if http:// scheme is present.
>>>>>>> But this function depends on a DBUS_SESSION_BUS_ADDRESS environment
>>>>>>> variable, which can be stripped off in some tests
>>>>>>> (in this case only file:// scheme will be returned).
>>>>>>>
>>>>>>>
>>>>>>> Old gnome_url_show() will not work  too due to lack of 64-bit
>>>>>>> libgnomevfs-2.0 library.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1]
>>>>>>> https://developer.gnome.org/gtk2/stable/gtk2-Filesystem-utilities.html#gtk-show-uri
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [2]
>>>>>>> https://developer.gnome.org/gio/stable/GVfs.html#g-vfs-get-supported-uri-schemes
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Alexander.
>>>>>>>
>>>>>
>>>
>

From Sergey.Bylokhov at oracle.com  Fri Dec 13 05:30:29 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 13 Dec 2013 17:30:29 +0400
Subject: <AWT Dev> [8] Review request for JDK-8029263, ,
 The user's default browser can not launch after we click the button,
 and there is an IOException shown in the log txt (java.io.IOException)
In-Reply-To: <52AB024C.8020902@oracle.com>
References: <52A9EC7C.6000200@oracle.com>
	<52AA1CF9.8010203@oracle.com>	<52AA2B6A.902@oracle.com>
	<52AA2F64.8000101@oracle.com>	<52AADE84.3080601@oracle.com>
	<52AAFE87.4020203@oracle.com>	<52AB012E.3040001@oracle.com>
	<52AB024C.8020902@oracle.com>
Message-ID: <52AB0BF5.3040901@oracle.com>

Hi, Alexander.
The fix looks good to me too.

On 13.12.2013 16:49, Anthony Petrov wrote:
> Thanks. The fix looks good to me now.
>
> -- 
> best regards,
> Anthony
>
> On 12/13/2013 04:44 PM, Alexander Zvegintsev wrote:
>> Sure,  webrev updated in place.
>> I also updated the RFE description.
>>
>> Thanks,
>>
>> Alexander.
>>
>> On 12/13/2013 04:33 PM, Anthony Petrov wrote:
>>> Hi Alexander,
>>>
>>> The fix looks much better. Though I still don't understand why you
>>> declare the i variable in update_supported_actions() so far from the
>>> place where it is used. What would go wrong if you moved the
>>> declaration inside the if() block just above your while() loop? It's
>>> not referenced from anywhere else, is it?
>>>
>>> Thanks for filing a new RFE. Please update its Description with some
>>> meaningful text that would describe what actually is requested/needs
>>> to be investigated.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 12/13/2013 02:16 PM, Alexander Zvegintsev wrote:
>>>> Hi Anthony,
>>>>
>>>> the updated webrev is here:
>>>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.01/
>>>> I also removed a redundant null check in XDesktopPeer.isSupported()
>>>>
>>>> The new RFE for 9 is here:
>>>> https://bugs.openjdk.java.net/browse/JDK-8030100
>>>>
>>>>> A follow-up question regarding #3: do you know which specific
>>>>> library/software module needs to be installed in order to support
>>>>> those other URI schemes? It might be useful to add this info to the
>>>>> bug report so that people know what they need to install additionally
>>>>> if they need to access such URIs.
>>>> Unfortunately I don't know currently. But I think this info can be 
>>>> added
>>>> later, when I will investigate a new RFE.
>>>>
>>>> Thanks,
>>>>
>>>> Alexander.
>>>>
>>>> On 12/13/2013 01:49 AM, Anthony Petrov wrote:
>>>>> Thanks for the clarifications, Alexander. Looking forward to an
>>>>> updated webrev.
>>>>>
>>>>> As for #4, I understand that we want to minimize the risk for this 
>>>>> fix
>>>>> now, so late in the release. And I'm fine with that. However, I still
>>>>> suggest to file an RFE targeted for 9 to enable this behavior for
>>>>> Linux as well. I reckon a Linux system can also be configured not to
>>>>> support additional URI schemes, so in general, I see no reason to 
>>>>> skip
>>>>> this check on Linux.
>>>>>
>>>>> A follow-up question regarding #3: do you know which specific
>>>>> library/software module needs to be installed in order to support
>>>>> those other URI schemes? It might be useful to add this info to the
>>>>> bug report so that people know what they need to install additionally
>>>>> if they need to access such URIs.
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 12/13/2013 01:32 AM, Alexander Zvegintsev wrote:
>>>>>> Hi Anthony,
>>>>>>
>>>>>> Please see inline
>>>>>> 13.12.2013 0:30, Anthony Petrov wrote:
>>>>>>> Hi Alexander,
>>>>>>>
>>>>>>> 1. Please add your evaluation to the bug report.
>>>>>>>
>>>>>>> 2. In gtk2_interface.c: can we declare the i variable somewhere
>>>>>>> closer
>>>>>>> to where it is used? What's the point with all these forward
>>>>>>> declarations? We don't compile with C89, do we?
>>>>>> Sure.
>>>>>>>
>>>>>>> 3. Checking for http: to enable the BROWSE action looks 
>>>>>>> reasonable to
>>>>>>> me. And I suggest to check for the mailto: scheme separately, so 
>>>>>>> that
>>>>>>> the MAIL action is only enabled if it's supported.
>>>>>>  From my testing if we have http scheme in this list(list of 
>>>>>> supported
>>>>>> URI schemes) we are able to open https://, ftp:// and mail: URIs 
>>>>>> (BTW
>>>>>> there is no https:// and mail: schemes in this list, and mail: is 
>>>>>> not
>>>>>> actually a valid URI).
>>>>>> If we have only file scheme in this list all other URIs will not 
>>>>>> work
>>>>>> and gtk_show_uri() will return "Operation not supported" message for
>>>>>> such URIs.
>>>>>> So this part of code is just an educated guess to check is gvfs
>>>>>> supported or not. It may be fragile(it depends on environment
>>>>>> variables
>>>>>> set) but it is better then nothing.
>>>>>>
>>>>>> Most of machines with Solaris 11 installed which I tested always
>>>>>> return
>>>>>> only file scheme in this list for 64-bit, so in general case we will
>>>>>> support only an OPEN action.
>>>>>>
>>>>>>> 4.
>>>>>>>>  534 #ifdef __solaris__
>>>>>>>>  535             update_supported_actions(env);
>>>>>>>>  536 #endif
>>>>>>>
>>>>>>> Have you tested this on Linux with your patch applied? How is the
>>>>>>> list
>>>>>>> of supported actions supposed to be populated on that platform?
>>>>>> Linux behaves as before the fix:
>>>>>> For Linux this list is already populated in initializer and remains
>>>>>> untouched from native:
>>>>>>> +    private static final List<Action> supportedActions
>>>>>>> +            = new ArrayList<>(Arrays.asList(Action.OPEN,
>>>>>>> Action.MAIL, Action.BROWSE))
>>>>>> The list of supported actions is the same as before the patch (OPEN,
>>>>>> MAIL, BROWSE). I tested this on OEL 5, 6, Ubuntu 13.04 all works as
>>>>>> expected.
>>>>>> So only for Solaris we clear this list and populate it from a 
>>>>>> native.
>>>>>>
>>>>>>>
>>>>>>> 5. In XDesktopPeer.java: please move the comment at line 51 
>>>>>>> above the
>>>>>>> field that it describes.
>>>>>>
>>>>>> -- 
>>>>>> Thanks,
>>>>>> Alexander.
>>>>>>> -- 
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>> On 12/12/2013 09:03 PM, Alexander Zvegintsev wrote:
>>>>>>>> Hello AWT team,
>>>>>>>>
>>>>>>>> Please review fix
>>>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/8/8029263/webrev.00/
>>>>>>>> for
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8029263
>>>>>>>>
>>>>>>>> This issue can be observed on Solaris 11 (sparcv9 or x86_64).
>>>>>>>>
>>>>>>>> gtk_show_uri() documentation[1] says:
>>>>>>>>> The uri must be of a form understood by GIO (i.e. you need to
>>>>>>>>> install
>>>>>>>>> gvfs to get support for uri schemes such as http:// or ftp://, as
>>>>>>>>> only
>>>>>>>>> local files are handled by GIO itself).
>>>>>>>> However it looks like that Solaris 11 supports gvfs for 32-bit
>>>>>>>> applications only by default. gtk_show_uri() returns "Operation 
>>>>>>>> not
>>>>>>>> supported" error message  for 64-bit applications
>>>>>>>> for schemes other than file://.
>>>>>>>>
>>>>>>>> Since b110 we don't have 32-bit JDK for Solaris anymore, so in 
>>>>>>>> most
>>>>>>>> cases only an OPEN action is available(file://).
>>>>>>>>
>>>>>>>> Currently I am unable to find any robust way to determine do we 
>>>>>>>> have
>>>>>>>> full gvfs support to handle URIs like mail:, http:// or not.
>>>>>>>>
>>>>>>>> We can use g_vfs_get_supported_uri_schemes()[2] and assume that we
>>>>>>>> have
>>>>>>>> full gvfs support if http:// scheme is present.
>>>>>>>> But this function depends on a DBUS_SESSION_BUS_ADDRESS 
>>>>>>>> environment
>>>>>>>> variable, which can be stripped off in some tests
>>>>>>>> (in this case only file:// scheme will be returned).
>>>>>>>>
>>>>>>>>
>>>>>>>> Old gnome_url_show() will not work  too due to lack of 64-bit
>>>>>>>> libgnomevfs-2.0 library.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://developer.gnome.org/gtk2/stable/gtk2-Filesystem-utilities.html#gtk-show-uri 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [2]
>>>>>>>> https://developer.gnome.org/gio/stable/GVfs.html#g-vfs-get-supported-uri-schemes 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Alexander.
>>>>>>>>
>>>>>>
>>>>
>>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Fri Dec 13 08:53:52 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 13 Dec 2013 20:53:52 +0400
Subject: <AWT Dev> [9] Review request for 8029979: Allow multiple calls to
	DropTargetDropEvent.acceptDrop()
Message-ID: <52AB3BA0.4070805@oracle.com>

Hi Petr, Sergey,

Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8029979 at:

http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.0/

I enable calling SunDropTargetContextPeer.acceptDrop() as many times as 
needed, for as long as the DnD operation isn't complete yet. Running 
open and closed DnD regression tests revealed no new failures.

Note that later we will need to back-port this fix to 8u20.

--
best regards,
Anthony

From anton.tarasov at oracle.com  Fri Dec 13 10:13:49 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 13 Dec 2013 22:13:49 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52AA3E92.7040302@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com>
Message-ID: <52AB4E5D.30202@oracle.com>

Summarizing your comments. We can't export a scaled version of a 
BufferedImage in the bounds of the current API without violating the 
spec. Unless a scaled BufferedImage is used internally, in which case we 
are less constrained. Ok, let's try this approach. I searched the code 
for all the cases of calling those factory methods I mentioned which 
create (or may create) a BufferedImage: Component.createImage(..), 
GraphicsConfiguration.createCompatibleImage(..), 
GraphicsConfiguration.createCompatibleVolatileImage(..). I found 19 
cases, but only 3 of them matters (the cases in which JLF differs from 
standalone Swing). These are double buffers creation in JViewport and 
RepaintManager, and AbstractRegionPainter.getImage(). Plus 1 case when 
we create a root BufferedImage directly from JLightweightFrame. It's 
possible to replace them with internal versions of the factory methods 
which will return a scaled BufferedImage.

Then, the suggestion to return layout bounds from a scaled 
BufferedImage, and physical bounds from its BufImgSurfaceData (we don't 
bother about getRGB for now) eliminates the need to translate to layout 
bounds in SG2D and unifies the code.

So, I'm going this way...

Thanks,
Anton.

On 12/13/13 2:54 AM, Jim Graham wrote:
>
>
> On 12/12/13 2:33 PM, Sergey Bylokhov wrote:
>> On 12/12/13 11:27 PM, Jim Graham wrote:
>>> The only real difference here is that BufferedImages have multiple
>>> definitions of width and height.  For VolatileImage objects there is
>>> no view of the pixels so the dimensions are the layout size and the
>>> expected renderable area and the returned graphics is pre-scaled.  For
>>> BufferedImage we can do all of that, but the dimensions have the added
>>> implication that they define the valid range of values for getRGB(x,
>>> y) and grabbing the rasters/data buffers/arrays and digging out pixels
>>> manually.
>>>
>>> If it were just getRGB(x, y) we could simply do a 2x2 average of
>>> underlying pixels to return an RGB value, but I don't think there is
>>> any amount of workaround that we can apply to make the digging out of
>>> the rasters and storage arrays work for those who manually access
>>> pixels...  :(
>> But I am talking about OffScreenImage(or we can add new one), which is
>> not public so we can try to block/change operations in our code. Not
>> sure that our backbuffers leaked to the users.
>
> OffscreenImage is a subclass of BufferedImage so if a developer ever 
> gets their hands on it then they may get confused by our use of the 
> getWidth/Height.  But, if there is no way for them to get a reference 
> to it, then we can play games internally.
>
> This will not help us with the return value of getCompatibleImage(), 
> though, which is specified to return a BufferedImage so we are 
> somewhat restricted in any use of logical dimensions there.
>
> Also, if we are entirely managing the buffer internally, then we have 
> the option to just use a regular BufferedImage.  We don't need any 
> extra magic if we render it with drawImage(x, y, w, h) since the 
> "logical" or "real" dimensions of the image have no impact on the 
> results there.  If it is double-sized then those pixels will fit into 
> the appropriate space on the destination without any need to special 
> case them in SG2D...
>
>                 ...jim


From anton.tarasov at oracle.com  Fri Dec 13 10:17:30 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 13 Dec 2013 22:17:30 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52AA3322.3020302@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A89175.5030704@oracle.com> <52A8A0FA.30804@oracle.com>
	<52A9D3BA.5050903@oracle.com> <52AA3322.3020302@oracle.com>
Message-ID: <52AB4F3A.2000206@oracle.com>

On 12/13/13 2:05 AM, Anthony Petrov wrote:
> On 12/12/2013 07:18 PM, Anton V. Tarasov wrote:
>> [cc'ing to j2d alias]
>>
>> On 11.12.2013 21:29, Sergey Bylokhov wrote:
>>> On 11.12.2013 20:23, Anton V. Tarasov wrote:
>>>>
>>>>>> - CGraphicsDevice
>>>>>>
>>>>>> This setter is only called from
>>>>>> CPlatformLWView.getGraphicsDevice(). I've explained it in my
>>>>>> previous message. It's needed to change the scale factor of the
>>>>>> default device when no device in the list fits. The case is
>>>>>> impossible with the current implementation of SwingNode (which only
>>>>>> passes JLF a scale factor matching one of a real display), however,
>>>>>> as JLF provides a generic lw embedding API, I should cover that
>>>>>> case as well.
>>> Not sure that matching fx to awt devices via scale is not a good idea.
>>> Note that it is expected that fields in the CGraphicsDevice chenges
>>> only if the screen is changed/added/removed.
>>> Probably Instead of notifyScaleFactorChanged you can notify about
>>> screens changes?
>>
>> JLightweightFrame is a toplevel that paints its content to an off-screen
>> buffer, so it is conceptually not associated with any screen. The host
>> (SwingNode) application communicates with JLF on an API level.
>> Introducing a notion of a "screen" to the API doesn't correlate with the
>> JLF's concept, imho.
>
> Why? IMO, this would simplify the code significantly as Swing is 
> already HiDPI-aware. It only needs to be able to determine the scale 
> factor of a screen device its top-level is on. Of course, the code in 
> the JLF implementation needs to know that too, so that it's able to 
> create a BI of appropriate dimensions. So making JLF tracking its 
> current GraphicsConfiguration looks like a reasonable idea to me. As 
> Sergey suggested, this could be done easily by checking intersections 
> between JLF's bounds in screen coordinates and the bounds of all the 
> available GraphicsDevices.

I'm not against the idea of using the right device internally (I just 
don't like the idea to add a notifyScreenChanged method). If this really 
can be implemented by means of the comparing the coordinates, then I'll 
do that.

Thanks,
Anton.
>
> -- 
> best regards,
> Anthony
>
>
>
>>
>> Why I'm still picking the device is because this seemed to me an
>> acceptable approach that integrates with LWAWT smoothly. But I agree
>> with you that matching the device via a scale factor is not a good idea.
>> Theoretically I can pickup wrong device, but even then it won't change
>> anything for me. I just need a device with the requested scale.
>>
>> What do you think then if we always use default device, for which we
>> will change the scale?
>>
>>>
>>>>>>
>>>>>> - OffScreenImage
>>>>>>
>>>>>> I've put a BufferedImage accessor there, nothing else. I didn't
>>>>>> find a better place... (I'd appreciate showing it).
>>>>>>
>>>>>> - JViewport, RepaintManager
>>>>>>
>>>>>> These classes create a double buffer. In case the buffer is backed
>>>>>> by a BufferedImage, it will be created with the current scale
>>>>>> factor set. The buffer won't be changed when a user moves the host
>>>>>> window across multiple screens with different scales. I see two
>>>>>> options. 1) Drop the double buffer reference every time the scale
>>>>>> changes (in that case, the buffer will be recreated every time, I
>>>>>> cross a screen) 2) Create a map which will cache the buffers (say,
>>>>>> for 1 and 2 scale factors for double screen env). I think the
>>>>>> second approach is better.
>>>>>>
>>>>>> > Probably it will be better to disable doublebuffering and
>>>>>> SwingPaintEventDispatcher completely(see 
>>>>>> swing.showFromDoubleBuffer)?
>>>>>>
>>>>>> Why? If we can manage it for JLF/SwingNode, why should we downgrade
>>>>>> performance?
>>>>> You have 1 buffere on fx side, buffer in SwingNode, buffer in
>>>>> jviewport, and swing itself use double buffering.
>>>>
>>>> Ok, this is a good point. But still I can't simply switch off double
>>>> buffering w/o doing any benchmarking. SwingNode perf analisys &
>>>> improvement is in plans...
>>> It would be good to know results of the benchmarks.
>>
>> Ok, but as this is a separate task I'd like to know what we're fighting
>> for. Is the goal to avoid creating BufferedImage's at all?
>>
>>>> So far, unless it requires lots of coding (but it doesn't) I'd prefer
>>>> to keep that option working.
>>>>
>>>>>>
>>>>>>> Actually I still do not understand why JViewport works in the
>>>>>>> standalone application.
>>>>>>
>>>>>> Could you please clarify, I don't understand this question...
>>>>> I see that JViewport use Offscreen image as a double buffer, is that
>>>>> true that it use it in the standalone swing application? If yes why
>>>>> it works.
>>>>
>>>> JViewport.paint() is not called with its default blit mode, and so it
>>>> doesn't actually use an OffscreenBuffer. For JLF, the mode is set to
>>>> backing store. If I set the backing store mode in standalone swing,
>>>> JViewport stops scaling on Retina. So, it didn't work before.
>>> Is this related to the JDK-8023966?
>>
>> Right.
>>
>> Thanks,
>> Anton.
>>
>>>>
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>>>
>>>>>>
>>>>>> Thanks for the review!
>>>>>>
>>>>>> Anton.
>>>>>>
>>>>>>>
>>>>>>> On 10.12.2013 18:22, Anton V. Tarasov wrote:
>>>>>>>> Hi Jim, Sergey and All,
>>>>>>>>
>>>>>>>> Please review the fix that adds support of Retina displays to
>>>>>>>> JLightweightFrame (which javafx SwingNode is based on).
>>>>>>>>
>>>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
>>>>>>>> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>>>>>>>>
>>>>>>>> (After the fix goes into jdk9 it should be ported to 8u20 as
>>>>>>>> well, because the functionality is essential for SwingNode.)
>>>>>>>>
>>>>>>>> The general idea of the fix is as follows.
>>>>>>>>
>>>>>>>> A BufferedImage instance, being created in the context in which
>>>>>>>> the scale factor is determined and is different from one, is
>>>>>>>> automatically created with appropriately extended size. The image
>>>>>>>> itself becomes a scaled image (a "scale" private field is set on
>>>>>>>> it). By the "context" I mean the circumstances where the
>>>>>>>> BufferedImage is related to a JLightweightFrame, a
>>>>>>>> GraphicsConfiguration, a SurfaceData, or a GraphicsDevice which
>>>>>>>> determine the scale factor.
>>>>>>>>
>>>>>>>> Here are the related changes:
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
>>>>>>>>
>>>>>>>> (the resizeBuffer method)
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The "scale" value of a BufferedImage is used when 1)
>>>>>>>> BufferedImageGraphicsConfig is created 2)
>>>>>>>> BufImgSurfaceData.getDefaultScale() is called:
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The former is used in the
>>>>>>>> GraphicsConfiguration.createCompatibleImage() calls, and the
>>>>>>>> latter is used in SurfaceManager.getImageScale(Image):
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> A scaled BufferedImage is supported by the
>>>>>>>> SunGraphics2D.drawImage() primitives. Here's the pattern of how
>>>>>>>> the image may be created and drawn:
>>>>>>>>
>>>>>>>> int scale = <get the scale factor from the context>;
>>>>>>>> BufferedImage img = new BufferedImage(width * scale, height *
>>>>>>>> scale, ...);
>>>>>>>> img.setScale(scale); // an accessor is currently used instead
>>>>>>>> <...>
>>>>>>>> g2d.drawImage(img, x, y, ...); // 1) draw the image with 
>>>>>>>> auto-scale
>>>>>>>> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a
>>>>>>>> specified rect
>>>>>>>>
>>>>>>>> In the first case, if the BufferedImage is created with an
>>>>>>>> extended size, the "scale" value of the image matters, it should
>>>>>>>> be drawn as a HiDPI image.
>>>>>>>> In the second case, if the BufferedImage is created with an
>>>>>>>> extended size, the "scale" value of the image doesn't matter (it
>>>>>>>> may not be evidently set) as the image will anyway be scaled from
>>>>>>>> its physical bounds into provided logical bounds. This all should
>>>>>>>> (as I suppose) provide backward compatibility for buffered images
>>>>>>>> that were created in their logical bounds or without setting the
>>>>>>>> "scale" field. For instance, the
>>>>>>>> AquaPainter.paintFromSingleCachedImage(...) method creates &
>>>>>>>> draws an image as follows:
>>>>>>>>
>>>>>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>>>>>> int imgW = bounds.width * scale;
>>>>>>>> int imgH = bounds.height * scale;
>>>>>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>>>>>> <paint into the img>
>>>>>>>> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height,
>>>>>>>> null);
>>>>>>>>
>>>>>>>> Here, the img.scale value is not set (I didn't modify this code),
>>>>>>>> and SunGraphics2D doesn't treat the image as a HiDPI image,
>>>>>>>> however it is drawn as expected. An alternative way to draw the
>>>>>>>> image would be:
>>>>>>>>
>>>>>>>> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
>>>>>>>> int imgW = bounds.width * scale;
>>>>>>>> int imgH = bounds.height * scale;
>>>>>>>> BufferedImage img = new BufferedImage(imgW, imgH, ...);
>>>>>>>> img.setScale(scale);
>>>>>>>> <paint into the img>
>>>>>>>> g.drawImage(img, bounds.x, bounds.y, ...);
>>>>>>>>
>>>>>>>> The result would be the same.
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The following changes:
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> are defined by this logic. Running Swing via JLightweightFrame
>>>>>>>> (JLF) makes it "display agnostic". Swing is painted to an
>>>>>>>> off-screen buffer and it's the host (e.g. SwingNode) that renders
>>>>>>>> the buffer on a particular device. So, the host should detect the
>>>>>>>> scale of the current display and set it on JLF.
>>>>>>> Does it mean that all methods related to the
>>>>>>> Component.getLocationOnScreen() does not work?
>>>>>>>>
>>>>>>>> However, AWT in order to paint to a volatile image requires
>>>>>>>> CGraphicsDevice and CGLSurfaceData to be created. By default AWT
>>>>>>>> creates CGraphicsDevice instances matching all the detected
>>>>>>>> display devices (CGraphicsEnvironment.initDevices()). But, as JLF
>>>>>>>> doesn't have any platform window behind it, AWT can't match JLF
>>>>>>>> to the exact device it's currently displayed on.
>>>>>>> Why? You can try to check it youseft via
>>>>>>> CGLGraphicsConfig.getBounds()+Peer.getBounds();
>>>>>>>> So, on the one hand, AWT doesn't know which device is current and
>>>>>>>> what is the current scale (the host passes this value), but from
>>>>>>>> the other hand, AWT has a list of all the CGraphicsDevice 
>>>>>>>> instances.
>>>>>>>>
>>>>>>>> I tried to leverage from that fact. The
>>>>>>>> CPlatformLWView.getGraphicsDevice() method takes the current
>>>>>>>> scale from the JLF instance, and then tries to match it to an
>>>>>>>> existent device from the list. In case it can't find a device
>>>>>>>> with the specified scale (which should not actually happen,
>>>>>>>> unless the host passes an arbitrary scale value, which is not the
>>>>>>>> case for SwingNode) it takes a default device and changes its
>>>>>>>> scale forcedly. I'm not sure if I should create a new dummy
>>>>>>>> device instance instead. The scale factor of the device (which is
>>>>>>>> then propagated to CGLSurfaceData on its creation) is the only
>>>>>>>> info that JLF will take from the device to create a scaled
>>>>>>>> volatile image.
>>>>>>>>
>>>>>>>> The following changes:
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> were made to map a backing store image to a scale factor.
>>>>>>>>
>>>>>>>> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...)
>>>>>>>> on scrolling. The method was not implemented for a graphics with
>>>>>>>> a scale transform and a BufImgSurfaceData (it threw exceptions).
>>>>>>>> I took that code, copied it to the
>>>>>>>> BufImgSurfaceData.copyArea(...) and added a general translation
>>>>>>>> for the coords:
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> It works, but I'm not sure the implementation is eligible (I
>>>>>>>> don't know the details of the Blit class, at least it warns not
>>>>>>>> to use the same source and dest).
>>>>>>>>
>>>>>>>> The rest of the changes (not covered here) should be clear.
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>>
>>>>>>>> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode
>>>>>>>> & embedded into SwingNode [1]).
>>>>>>>> - Testing both Nimbus and Aqua L&F.
>>>>>>>> - Setting swing.volatileImageBufferEnabled=false/true for all
>>>>>>>> combinations.
>>>>>>>>
>>>>>>>> Currently, I see no regressions and no visual issues comparing a
>>>>>>>> standalone mode and a SwingSet mode.
>>>>>>>>
>>>>>>>> At the end, I suspect there may be some intersection b/w this fix
>>>>>>>> and the fix which introduced MultiResolutionToolkitImage.
>>>>>>>> Unfortunately, I didn't yet read that review saga... Please tell
>>>>>>>> me if I should incorporate anything from that fix.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Anton.
>>>>>>>>
>>>>>>>> [1] There's a SwingSet part of the fix which I'm going to post to
>>>>>>>> the jfx alias separately.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>


From Sergey.Bylokhov at oracle.com  Fri Dec 13 10:50:24 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 13 Dec 2013 22:50:24 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52AB4E5D.30202@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52AB4E5D.30202@oracle.com>
Message-ID: <52AB56F0.7080109@oracle.com>

Hi, Anton.
Please check performance w/o buffers too, to know the difference.

On 13.12.2013 22:13, Anton V. Tarasov wrote:
> Summarizing your comments. We can't export a scaled version of a 
> BufferedImage in the bounds of the current API without violating the 
> spec. Unless a scaled BufferedImage is used internally, in which case 
> we are less constrained. Ok, let's try this approach. I searched the 
> code for all the cases of calling those factory methods I mentioned 
> which create (or may create) a BufferedImage: 
> Component.createImage(..), 
> GraphicsConfiguration.createCompatibleImage(..), 
> GraphicsConfiguration.createCompatibleVolatileImage(..). I found 19 
> cases, but only 3 of them matters (the cases in which JLF differs from 
> standalone Swing). These are double buffers creation in JViewport and 
> RepaintManager, and AbstractRegionPainter.getImage(). Plus 1 case when 
> we create a root BufferedImage directly from JLightweightFrame. It's 
> possible to replace them with internal versions of the factory methods 
> which will return a scaled BufferedImage.
>
> Then, the suggestion to return layout bounds from a scaled 
> BufferedImage, and physical bounds from its BufImgSurfaceData (we 
> don't bother about getRGB for now) eliminates the need to translate to 
> layout bounds in SG2D and unifies the code.
>
> So, I'm going this way...
>
> Thanks,
> Anton.
>
> On 12/13/13 2:54 AM, Jim Graham wrote:
>>
>>
>> On 12/12/13 2:33 PM, Sergey Bylokhov wrote:
>>> On 12/12/13 11:27 PM, Jim Graham wrote:
>>>> The only real difference here is that BufferedImages have multiple
>>>> definitions of width and height.  For VolatileImage objects there is
>>>> no view of the pixels so the dimensions are the layout size and the
>>>> expected renderable area and the returned graphics is pre-scaled.  For
>>>> BufferedImage we can do all of that, but the dimensions have the added
>>>> implication that they define the valid range of values for getRGB(x,
>>>> y) and grabbing the rasters/data buffers/arrays and digging out pixels
>>>> manually.
>>>>
>>>> If it were just getRGB(x, y) we could simply do a 2x2 average of
>>>> underlying pixels to return an RGB value, but I don't think there is
>>>> any amount of workaround that we can apply to make the digging out of
>>>> the rasters and storage arrays work for those who manually access
>>>> pixels...  :(
>>> But I am talking about OffScreenImage(or we can add new one), which is
>>> not public so we can try to block/change operations in our code. Not
>>> sure that our backbuffers leaked to the users.
>>
>> OffscreenImage is a subclass of BufferedImage so if a developer ever 
>> gets their hands on it then they may get confused by our use of the 
>> getWidth/Height.  But, if there is no way for them to get a reference 
>> to it, then we can play games internally.
>>
>> This will not help us with the return value of getCompatibleImage(), 
>> though, which is specified to return a BufferedImage so we are 
>> somewhat restricted in any use of logical dimensions there.
>>
>> Also, if we are entirely managing the buffer internally, then we have 
>> the option to just use a regular BufferedImage.  We don't need any 
>> extra magic if we render it with drawImage(x, y, w, h) since the 
>> "logical" or "real" dimensions of the image have no impact on the 
>> results there.  If it is double-sized then those pixels will fit into 
>> the appropriate space on the destination without any need to special 
>> case them in SG2D...
>>
>>                 ...jim
>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Fri Dec 13 15:07:31 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Sat, 14 Dec 2013 03:07:31 +0400
Subject: <AWT Dev> [9] Review request for 8029979: Allow multiple calls
	to DropTargetDropEvent.acceptDrop()
In-Reply-To: <52AB3BA0.4070805@oracle.com>
References: <52AB3BA0.4070805@oracle.com>
Message-ID: <BF7D32EB-915B-431A-96D4-989F88411D94@oracle.com>

Hello, Anthony.

The code changes look good, but could you please add a reg test for this issue.

With best regards. Petr.

On Dec 13, 2013, at 8:53 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Petr, Sergey,
> 
> Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8029979 at:
> 
> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.0/
> 
> I enable calling SunDropTargetContextPeer.acceptDrop() as many times as needed, for as long as the DnD operation isn't complete yet. Running open and closed DnD regression tests revealed no new failures.
> 
> Note that later we will need to back-port this fix to 8u20.
> 
> --
> best regards,
> Anthony


From Sergey.Bylokhov at oracle.com  Fri Dec 13 15:14:48 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 14 Dec 2013 03:14:48 +0400
Subject: <AWT Dev> [9] Review request for 8029979: Allow multiple calls
	to DropTargetDropEvent.acceptDrop()
In-Reply-To: <52AB3BA0.4070805@oracle.com>
References: <52AB3BA0.4070805@oracle.com>
Message-ID: <52AB94E8.50405@oracle.com>

Hi, Anthony
Me surprises why fx calls this method several time.
Is it necessary to check !dropComplete? Probabbly acceptDrop should be 
noop in case of dropStatus  == STATUS_ACCEPT?
I guess the same change can be applied to the rejectDrop?

On 13.12.2013 20:53, Anthony Petrov wrote:
> Hi Petr, Sergey,
>
> Please review a fix for 
> https://bugs.openjdk.java.net/browse/JDK-8029979 at:
>
> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.0/
>
> I enable calling SunDropTargetContextPeer.acceptDrop() as many times 
> as needed, for as long as the DnD operation isn't complete yet. 
> Running open and closed DnD regression tests revealed no new failures.
>
> Note that later we will need to back-port this fix to 8u20.
>
> -- 
> best regards,
> Anthony


-- 
Best regards, Sergey.


From james.graham at oracle.com  Fri Dec 13 17:09:16 2013
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 13 Dec 2013 17:09:16 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <52AB4E5D.30202@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52AB4E5D.30202@oracle.com>
Message-ID: <52ABAFBC.2070404@oracle.com>

That sounds like a good plan.  Hopefully the resulting webrev will be 
short and sweet and easy to verify.

We still leave on the table any convenient way for a developer to get 
auto-scaled-double-buffering without going through these same pains in 
their own code, but hopefully everyone relies on Swing to do the major 
portion of their (retina) double buffering...

			...jim

On 12/13/13 10:13 AM, Anton V. Tarasov wrote:
> Summarizing your comments. We can't export a scaled version of a
> BufferedImage in the bounds of the current API without violating the
> spec. Unless a scaled BufferedImage is used internally, in which case we
> are less constrained. Ok, let's try this approach. I searched the code
> for all the cases of calling those factory methods I mentioned which
> create (or may create) a BufferedImage: Component.createImage(..),
> GraphicsConfiguration.createCompatibleImage(..),
> GraphicsConfiguration.createCompatibleVolatileImage(..). I found 19
> cases, but only 3 of them matters (the cases in which JLF differs from
> standalone Swing). These are double buffers creation in JViewport and
> RepaintManager, and AbstractRegionPainter.getImage(). Plus 1 case when
> we create a root BufferedImage directly from JLightweightFrame. It's
> possible to replace them with internal versions of the factory methods
> which will return a scaled BufferedImage.
>
> Then, the suggestion to return layout bounds from a scaled
> BufferedImage, and physical bounds from its BufImgSurfaceData (we don't
> bother about getRGB for now) eliminates the need to translate to layout
> bounds in SG2D and unifies the code.
>
> So, I'm going this way...
>
> Thanks,
> Anton.
>
> On 12/13/13 2:54 AM, Jim Graham wrote:
>>
>>
>> On 12/12/13 2:33 PM, Sergey Bylokhov wrote:
>>> On 12/12/13 11:27 PM, Jim Graham wrote:
>>>> The only real difference here is that BufferedImages have multiple
>>>> definitions of width and height.  For VolatileImage objects there is
>>>> no view of the pixels so the dimensions are the layout size and the
>>>> expected renderable area and the returned graphics is pre-scaled.  For
>>>> BufferedImage we can do all of that, but the dimensions have the added
>>>> implication that they define the valid range of values for getRGB(x,
>>>> y) and grabbing the rasters/data buffers/arrays and digging out pixels
>>>> manually.
>>>>
>>>> If it were just getRGB(x, y) we could simply do a 2x2 average of
>>>> underlying pixels to return an RGB value, but I don't think there is
>>>> any amount of workaround that we can apply to make the digging out of
>>>> the rasters and storage arrays work for those who manually access
>>>> pixels...  :(
>>> But I am talking about OffScreenImage(or we can add new one), which is
>>> not public so we can try to block/change operations in our code. Not
>>> sure that our backbuffers leaked to the users.
>>
>> OffscreenImage is a subclass of BufferedImage so if a developer ever
>> gets their hands on it then they may get confused by our use of the
>> getWidth/Height.  But, if there is no way for them to get a reference
>> to it, then we can play games internally.
>>
>> This will not help us with the return value of getCompatibleImage(),
>> though, which is specified to return a BufferedImage so we are
>> somewhat restricted in any use of logical dimensions there.
>>
>> Also, if we are entirely managing the buffer internally, then we have
>> the option to just use a regular BufferedImage.  We don't need any
>> extra magic if we render it with drawImage(x, y, w, h) since the
>> "logical" or "real" dimensions of the image have no impact on the
>> results there.  If it is double-sized then those pixels will fit into
>> the appropriate space on the destination without any need to special
>> case them in SG2D...
>>
>>                 ...jim
>

From petr.pchelko at oracle.com  Sun Dec 15 23:06:19 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 16 Dec 2013 11:06:19 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8026869 [macosx] Support
	apple.awt.use-file-dialog-packages property
Message-ID: <28800AD7-6975-4AC7-BE8F-6137A58488BD@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8026869
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8026869/webrev.00/

The fix is simple: we add support for the apple.awt.use-file-dialog-packages property. 
On the native side the code is ready for handling the property, it just was not initialized for some reason.
The fix also adds a manual test for the issue, creating an automatic test is impossible here.

With best regards. Petr.

From petr.pchelko at oracle.com  Mon Dec 16 00:36:29 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 16 Dec 2013 12:36:29 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8024185 [macosx] Fullscreen
	button freezes application when started with -splash
Message-ID: <6CF001F6-C0B0-4363-9798-4A208981AD55@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8024185
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8024185/webrev/
The fix also resolves the issue:
https://bugs.openjdk.java.net/browse/JDK-8009203

The problem:
When showing the splash screen the NSApplicationAWT runAWTLoopWithApp: was invoked from within the dispatch_async.
This is a blocking method, so it blocked the main dispatch queue which is used in Cocoa internally. So we've got different bugs.
The fix replaces the Grand Central Dispatch API with the JNFRunLoop performOnMainThreadWaiting which is used in other places in splashscreen.

The test verifies that the native FS support works after showing the splashscreen. Mac OS X specific APIs are accessed with reflection, so the test is compilable on other platforms.
The test.png is an image added to the test folder, it's not in the webrev as it does not support binary file diffs. I took the image from an existing 2d open test, so it should be fine from the legal point of view. 

With best regards. Petr.

From petr.pchelko at oracle.com  Mon Dec 16 01:56:49 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 16 Dec 2013 13:56:49 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8023148 [macosx]
	java.util.NoSuchElementException at java.util.LinkedList.getFirst
Message-ID: <2411C7FD-CFF4-4CBD-85F3-EB460C139E6C@oracle.com>

Hello, AWT Team.

Please review the fi for the issue:
https://bugs.openjdk.java.net/browse/JDK-8023148
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8023148/webrev/

The problem is simple: LinkedList throws an exception on getFirst if the list is empty. The fix is trivial, so no reg test.

With best regards. Petr.

From Sergey.Bylokhov at oracle.com  Mon Dec 16 02:57:34 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 16 Dec 2013 14:57:34 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8026869 [macosx] Support
 apple.awt.use-file-dialog-packages property
In-Reply-To: <28800AD7-6975-4AC7-BE8F-6137A58488BD@oracle.com>
References: <28800AD7-6975-4AC7-BE8F-6137A58488BD@oracle.com>
Message-ID: <52AEDC9E.3020808@oracle.com>

Hi, Petr.
The fix looks good.

On 16.12.2013 11:06, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8026869
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8026869/webrev.00/
>
> The fix is simple: we add support for the apple.awt.use-file-dialog-packages property.
> On the native side the code is ready for handling the property, it just was not initialized for some reason.
> The fix also adds a manual test for the issue, creating an automatic test is impossible here.
>
> With best regards. Petr.


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Dec 16 03:06:38 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 16 Dec 2013 15:06:38 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8023148 [macosx]
 java.util.NoSuchElementException at java.util.LinkedList.getFirst
In-Reply-To: <2411C7FD-CFF4-4CBD-85F3-EB460C139E6C@oracle.com>
References: <2411C7FD-CFF4-4CBD-85F3-EB460C139E6C@oracle.com>
Message-ID: <52AEDEBE.4000806@oracle.com>

Hi, Petr.
The fix looks good.

On 16.12.2013 13:56, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fi for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8023148
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8023148/webrev/
>
> The problem is simple: LinkedList throws an exception on getFirst if the list is empty. The fix is trivial, so no reg test.
>
> With best regards. Petr.


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Mon Dec 16 04:02:44 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 16 Dec 2013 16:02:44 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8007220 [macosx] Setting
	popupmenu on TrayIcon do not work if done *after* adding TrayIcon
Message-ID: <B73165E1-0CF0-47F8-B48D-3C064F82EEFA@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8007220
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8007220/webrev/

The problem: the CTrayIcon.popup field was set only in a constructor, but it should be updated every time the popup is opened.

With best regards. Petr.

From Sergey.Bylokhov at oracle.com  Mon Dec 16 04:38:33 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 16 Dec 2013 16:38:33 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8007220 [macosx] Setting
 popupmenu on TrayIcon do not work if done *after* adding TrayIcon
In-Reply-To: <B73165E1-0CF0-47F8-B48D-3C064F82EEFA@oracle.com>
References: <B73165E1-0CF0-47F8-B48D-3C064F82EEFA@oracle.com>
Message-ID: <52AEF449.8000705@oracle.com>

Hi, Petr.
Since you add new call to addNotify(), can you check that we call 
removeNotify when necessary?

On 16.12.2013 16:02, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8007220
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8007220/webrev/
>
> The problem: the CTrayIcon.popup field was set only in a constructor, but it should be updated every time the popup is opened.
>
> With best regards. Petr.


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Mon Dec 16 05:25:19 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 16 Dec 2013 17:25:19 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8007220 [macosx] Setting
	popupmenu on TrayIcon do not work if done *after* adding TrayIcon
In-Reply-To: <52AEF449.8000705@oracle.com>
References: <B73165E1-0CF0-47F8-B48D-3C064F82EEFA@oracle.com>
	<52AEF449.8000705@oracle.com>
Message-ID: <6596B350-7B46-4029-916D-CF96A408EB32@oracle.com>

Hello, Sergey.

> Since you add new call to addNotify(), can you check that we call removeNotify when necessary?

On Win and Linux we were calling it properly for popups, but on mac os x we haven't been doing that. The new version of the fix fixes that.

The new version is here:
http://cr.openjdk.java.net/~pchelko/9/8007220/webrev.01/

With best regards. Petr.

On 16.12.2013, at 16:38, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Petr.
> Since you add new call to addNotify(), can you check that we call removeNotify when necessary?
> 
> On 16.12.2013 16:02, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8007220
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8007220/webrev/
>> 
>> The problem: the CTrayIcon.popup field was set only in a constructor, but it should be updated every time the popup is opened.
>> 
>> With best regards. Petr.
> 
> 
> -- 
> Best regards, Sergey.
> 


From anthony.petrov at oracle.com  Mon Dec 16 06:19:37 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 16 Dec 2013 18:19:37 +0400
Subject: <AWT Dev> [9] Review request for 8029979: Allow multiple calls
	to DropTargetDropEvent.acceptDrop()
In-Reply-To: <52AB94E8.50405@oracle.com>
References: <52AB3BA0.4070805@oracle.com> <52AB94E8.50405@oracle.com>
Message-ID: <52AF0BF9.9080906@oracle.com>

Hi Sergey,

Thanks for the review.

On 12/14/2013 03:14 AM, Sergey Bylokhov wrote:
> Me surprises why fx calls this method several time.

It's all described in details at 
https://javafx-jira.kenai.com/browse/RT-34283
In a nutshell, we have to call acceptDrop() for the first time in order 
to retrieve the data from the DnD clipboard. However, the actual drop 
operation becomes known only after FX's event handler finishes its 
execution. Hence we have to call acceptDrop() another time to pass the 
final value to the AWT code before we call the dropComplete() method.

> Is it necessary to check !dropComplete?

Well, I wanted to add this case to my regression test, but it appears 
that the DropTargetContextPeer gets destroyed after user's code calls 
dropComplete(), and so this check is never performed actually. However, 
I'd like to keep it in place because it just doesn't make any sense to 
call acceptDrop() after the drop is complete. It looks safe to me.

> Probabbly acceptDrop should be
> noop in case of dropStatus  == STATUS_ACCEPT?

No. As I explained above, we do need to be able to redefine the drop 
operation. So this can't be a no-op.

> I guess the same change can be applied to the rejectDrop?

The current behavior of rejectDrop() doesn't cause any problems for FX. 
As long as there's no requests to allow this method to be called 
multiple times, I'd prefer to leave it as is. Should need arise, we can 
always revisit this later.

--
best regards,
Anthony

>
> On 13.12.2013 20:53, Anthony Petrov wrote:
>> Hi Petr, Sergey,
>>
>> Please review a fix for
>> https://bugs.openjdk.java.net/browse/JDK-8029979 at:
>>
>> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.0/
>>
>> I enable calling SunDropTargetContextPeer.acceptDrop() as many times
>> as needed, for as long as the DnD operation isn't complete yet.
>> Running open and closed DnD regression tests revealed no new failures.
>>
>> Note that later we will need to back-port this fix to 8u20.
>>
>> --
>> best regards,
>> Anthony
>
>

From anthony.petrov at oracle.com  Mon Dec 16 06:22:12 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 16 Dec 2013 18:22:12 +0400
Subject: <AWT Dev> [9] Review request for 8029979: Allow multiple calls
	to DropTargetDropEvent.acceptDrop()
In-Reply-To: <BF7D32EB-915B-431A-96D4-989F88411D94@oracle.com>
References: <52AB3BA0.4070805@oracle.com>
	<BF7D32EB-915B-431A-96D4-989F88411D94@oracle.com>
Message-ID: <52AF0C94.4060600@oracle.com>

Hi Petr,

Thank you for the review. Please find a webrev with a new regression 
test included at:

http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.1/

--
best regards,
Anthony

On 12/14/2013 03:07 AM, Petr Pchelko wrote:
> Hello, Anthony.
>
> The code changes look good, but could you please add a reg test for this issue.
>
> With best regards. Petr.
>
> On Dec 13, 2013, at 8:53 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hi Petr, Sergey,
>>
>> Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8029979 at:
>>
>> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.0/
>>
>> I enable calling SunDropTargetContextPeer.acceptDrop() as many times as needed, for as long as the DnD operation isn't complete yet. Running open and closed DnD regression tests revealed no new failures.
>>
>> Note that later we will need to back-port this fix to 8u20.
>>
>> --
>> best regards,
>> Anthony
>

From petr.pchelko at oracle.com  Mon Dec 16 06:30:34 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 16 Dec 2013 18:30:34 +0400
Subject: <AWT Dev> [9] Review request for 8029979: Allow multiple calls
	to DropTargetDropEvent.acceptDrop()
In-Reply-To: <52AF0C94.4060600@oracle.com>
References: <52AB3BA0.4070805@oracle.com>
	<BF7D32EB-915B-431A-96D4-989F88411D94@oracle.com>
	<52AF0C94.4060600@oracle.com>
Message-ID: <79885DF8-23AA-4225-8CCB-FCFF6A247655@oracle.com>

Hello, Anthony.

The fix look good.

With best regards. Petr.

On 16.12.2013, at 18:22, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Petr,
> 
> Thank you for the review. Please find a webrev with a new regression test included at:
> 
> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.1/
> 
> --
> best regards,
> Anthony
> 
> On 12/14/2013 03:07 AM, Petr Pchelko wrote:
>> Hello, Anthony.
>> 
>> The code changes look good, but could you please add a reg test for this issue.
>> 
>> With best regards. Petr.
>> 
>> On Dec 13, 2013, at 8:53 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>> 
>>> Hi Petr, Sergey,
>>> 
>>> Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8029979 at:
>>> 
>>> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.0/
>>> 
>>> I enable calling SunDropTargetContextPeer.acceptDrop() as many times as needed, for as long as the DnD operation isn't complete yet. Running open and closed DnD regression tests revealed no new failures.
>>> 
>>> Note that later we will need to back-port this fix to 8u20.
>>> 
>>> --
>>> best regards,
>>> Anthony
>> 


From peter.brunet at oracle.com  Mon Dec 16 08:02:13 2013
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 16 Dec 2013 10:02:13 -0600
Subject: <AWT Dev> Regression test failure loading a DLL
Message-ID: <52AF2405.5050107@oracle.com>

I'm writing a regression test and it is failing trying to load
bin\JAWTAccessBridge.DLL.  It was successful in loading
bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs are
in jre\bin.  Here's the failure:

java.lang.UnsatisfiedLinkError:
C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
Can't find dependent libraries
 at java.lang.ClassLoader$NativeLibrary.load(Native Method)
 at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
 at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
 at java.lang.Runtime.loadLibrary0(Runtime.java:870)
 at java.lang.System.loadLibrary(System.java:1119)
 at JABDLL$4.run(JABDLL.java:116)
 at java.security.AccessController.doPrivileged(Native Method)
 at JABDLL.foundLegacyDLLs(JABDLL.java:113)
 at JABDLL.main(JABDLL.java:67)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:483)
 at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
 at java.lang.Thread.run(Thread.java:744)

Here's the pertinent code:

private static boolean foundLegacyDLLs() {
            java.security.AccessController.doPrivileged(
                new java.security.PrivilegedAction() {
                    public Object run() {
                        System.loadLibrary("JavaAccessBridge");
                        return null;
                    }
                }, null, new
RuntimePermission("loadLibrary.JavaAccessBridge")
            );
            java.security.AccessController.doPrivileged(
                new java.security.PrivilegedAction() {
                    public Object run() {
                        System.loadLibrary("JAWTAccessBridge");  // line
116, fails here
                        return null;
                    }
                }, null, new
RuntimePermission("loadLibrary.JAWTAccessBridge")
            );
            return true;
    }

Here's the jtreg run:

$ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
-testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
-verbose:summary closed/com/sun/java/accessibility/JABDLL.java
C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
this can be ignored
FAILED: closed/com/sun/java/accessibility/JABDLL.java
Test results: failed: 1
Report written to
C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
Results written to C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
Error: Some tests failed or other problems occurred.

Here's the prolog to the test case:

/*
  * @test
  * @summary ...
  * @run main JABDLL
  */

The built image runs fine in normal use, i.e. I can run SwingSet2 with
the same image so I assume it's something I'm not doing right with
respect to jtreg.

The dependency walker reports jvm.dll which is in bin\server.  I tried
moving that to bin but that didn't help.   Also some Win DLLs were
reported most of which start with API-MS-WIN- but I assume those are
false negatives.  The sdk image I am testing is 32 bit and the DLL is
also 32 bit.  Hopefully it's just something I don't yet understand about
jprt, like maybe a missing @ tag in the prolog.

Any ideas on how to debug this?

Pete



From anthony.petrov at oracle.com  Mon Dec 16 11:04:41 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 16 Dec 2013 23:04:41 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8024185 [macosx] Fullscreen
 button freezes application when started with -splash
In-Reply-To: <6CF001F6-C0B0-4363-9798-4A208981AD55@oracle.com>
References: <6CF001F6-C0B0-4363-9798-4A208981AD55@oracle.com>
Message-ID: <52AF4EC9.5020109@oracle.com>

Hi Petr, Phil,

The fix looks fine to me. However, I'm not sure we want to add binary 
files to the repo, no matter how good they are from "legal" perspective.


Phil: what do you think about .png files in tests?


--
best regards,
Anthony

On 12/16/2013 12:36 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8024185
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8024185/webrev/
> The fix also resolves the issue:
> https://bugs.openjdk.java.net/browse/JDK-8009203
>
> The problem:
> When showing the splash screen the NSApplicationAWT runAWTLoopWithApp: was invoked from within the dispatch_async.
> This is a blocking method, so it blocked the main dispatch queue which is used in Cocoa internally. So we've got different bugs.
> The fix replaces the Grand Central Dispatch API with the JNFRunLoop performOnMainThreadWaiting which is used in other places in splashscreen.
>
> The test verifies that the native FS support works after showing the splashscreen. Mac OS X specific APIs are accessed with reflection, so the test is compilable on other platforms.
> The test.png is an image added to the test folder, it's not in the webrev as it does not support binary file diffs. I took the image from an existing 2d open test, so it should be fine from the legal point of view.
>
> With best regards. Petr.
>

From anthony.petrov at oracle.com  Mon Dec 16 11:19:02 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 16 Dec 2013 23:19:02 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8026869 [macosx] Support
 apple.awt.use-file-dialog-packages property
In-Reply-To: <28800AD7-6975-4AC7-BE8F-6137A58488BD@oracle.com>
References: <28800AD7-6975-4AC7-BE8F-6137A58488BD@oracle.com>
Message-ID: <52AF5226.6090603@oracle.com>

Looks fine.

--
best regards,
Anthony

On 12/16/2013 11:06 AM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8026869
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8026869/webrev.00/
>
> The fix is simple: we add support for the apple.awt.use-file-dialog-packages property.
> On the native side the code is ready for handling the property, it just was not initialized for some reason.
> The fix also adds a manual test for the issue, creating an automatic test is impossible here.
>
> With best regards. Petr.
>

From anthony.petrov at oracle.com  Mon Dec 16 11:27:45 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 16 Dec 2013 23:27:45 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8007220 [macosx] Setting
 popupmenu on TrayIcon do not work if done *after* adding TrayIcon
In-Reply-To: <6596B350-7B46-4029-916D-CF96A408EB32@oracle.com>
References: <B73165E1-0CF0-47F8-B48D-3C064F82EEFA@oracle.com>
	<52AEF449.8000705@oracle.com>
	<6596B350-7B46-4029-916D-CF96A408EB32@oracle.com>
Message-ID: <52AF5431.10706@oracle.com>

The fix looks good.

--
best regards,
Anthony

On 12/16/2013 05:25 PM, Petr Pchelko wrote:
> Hello, Sergey.
>
>> Since you add new call to addNotify(), can you check that we call removeNotify when necessary?
>
> On Win and Linux we were calling it properly for popups, but on mac os x we haven't been doing that. The new version of the fix fixes that.
>
> The new version is here:
> http://cr.openjdk.java.net/~pchelko/9/8007220/webrev.01/
>
> With best regards. Petr.
>
> On 16.12.2013, at 16:38, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Petr.
>> Since you add new call to addNotify(), can you check that we call removeNotify when necessary?
>>
>> On 16.12.2013 16:02, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8007220
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8007220/webrev/
>>>
>>> The problem: the CTrayIcon.popup field was set only in a constructor, but it should be updated every time the popup is opened.
>>>
>>> With best regards. Petr.
>>
>>
>> --
>> Best regards, Sergey.
>>
>

From anthony.petrov at oracle.com  Mon Dec 16 11:32:38 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 16 Dec 2013 23:32:38 +0400
Subject: <AWT Dev> Regression test failure loading a DLL
In-Reply-To: <52AF2405.5050107@oracle.com>
References: <52AF2405.5050107@oracle.com>
Message-ID: <52AF5556.3020004@oracle.com>

Hi Pete,

I see you've already tried the Dependency Walker.

1. Could you please clarify the following: if you compile two lists of 
dependencies, one for JavaAccessBridge.dll and another for 
JAWTAccessBridge.DLL, and compare them, are there any differences?

2. If you change the order of loading the libraries, will it fail right 
away w/o even loading the JavaAccessBridge.dll ?

3. If the above doesn't help, please post the full list of dependencies 
for JAWTAccessBridge.DLL as reported by the Dependency Walker.

--
best regards,
Anthony

On 12/16/2013 08:02 PM, Pete Brunet wrote:
> I'm writing a regression test and it is failing trying to load
> bin\JAWTAccessBridge.DLL.  It was successful in loading
> bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs are
> in jre\bin.  Here's the failure:
>
> java.lang.UnsatisfiedLinkError:
> C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
> Can't find dependent libraries
>   at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>   at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
>   at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
>   at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>   at java.lang.System.loadLibrary(System.java:1119)
>   at JABDLL$4.run(JABDLL.java:116)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at JABDLL.foundLegacyDLLs(JABDLL.java:113)
>   at JABDLL.main(JABDLL.java:67)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>   at java.lang.Thread.run(Thread.java:744)
>
> Here's the pertinent code:
>
> private static boolean foundLegacyDLLs() {
>              java.security.AccessController.doPrivileged(
>                  new java.security.PrivilegedAction() {
>                      public Object run() {
>                          System.loadLibrary("JavaAccessBridge");
>                          return null;
>                      }
>                  }, null, new
> RuntimePermission("loadLibrary.JavaAccessBridge")
>              );
>              java.security.AccessController.doPrivileged(
>                  new java.security.PrivilegedAction() {
>                      public Object run() {
>                          System.loadLibrary("JAWTAccessBridge");  // line
> 116, fails here
>                          return null;
>                      }
>                  }, null, new
> RuntimePermission("loadLibrary.JAWTAccessBridge")
>              );
>              return true;
>      }
>
> Here's the jtreg run:
>
> $ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
> -testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
> -verbose:summary closed/com/sun/java/accessibility/JABDLL.java
> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
> needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
> this can be ignored
> FAILED: closed/com/sun/java/accessibility/JABDLL.java
> Test results: failed: 1
> Report written to
> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
> Results written to C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
> Error: Some tests failed or other problems occurred.
>
> Here's the prolog to the test case:
>
> /*
>    * @test
>    * @summary ...
>    * @run main JABDLL
>    */
>
> The built image runs fine in normal use, i.e. I can run SwingSet2 with
> the same image so I assume it's something I'm not doing right with
> respect to jtreg.
>
> The dependency walker reports jvm.dll which is in bin\server.  I tried
> moving that to bin but that didn't help.   Also some Win DLLs were
> reported most of which start with API-MS-WIN- but I assume those are
> false negatives.  The sdk image I am testing is 32 bit and the DLL is
> also 32 bit.  Hopefully it's just something I don't yet understand about
> jprt, like maybe a missing @ tag in the prolog.
>
> Any ideas on how to debug this?
>
> Pete
>
>

From peter.brunet at oracle.com  Mon Dec 16 12:44:11 2013
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 16 Dec 2013 14:44:11 -0600
Subject: <AWT Dev> Regression test failure loading a DLL
In-Reply-To: <52AF5556.3020004@oracle.com>
References: <52AF2405.5050107@oracle.com> <52AF5556.3020004@oracle.com>
Message-ID: <52AF661B.4060602@oracle.com>

Hi Anthony, Thanks for helping...

On 12/16/13 1:32 PM, Anthony Petrov wrote:
> Hi Pete,
>
> I see you've already tried the Dependency Walker.
>
> 1. Could you please clarify the following: if you compile two lists of
> dependencies, one for JavaAccessBridge.dll and another for
> JAWTAccessBridge.DLL, and compare them, are there any differences?
Differences:

JAWT* has these extras
jvm.dll - error opening file
awt.dll - no problem with this and the following
java.dll
jawt.dll
verify.dll

Immediate load in JAWT*, delay load in Java*
ole32 - colored red, i.e. missing export function required by parent module
oleaut32.dll - no problem
>
> 2. If you change the order of loading the libraries, will it fail
> right away w/o even loading the JavaAccessBridge.dll ?
yes
>
> 3. If the above doesn't help, please post the full list of
> dependencies for JAWTAccessBridge.DLL as reported by the Dependency
> Walker.
Error opening file:
JVM.DLL
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
GPSVC.DLL
IESHIMS.DLL
Red (missing export function required by parent module):
API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
OLE32.DLL
Red, delay load:
DWMAPI.DLL
IEFRAME.DLL
IMM32.DLL
MFPLAT.DLL
NDFAPI.DLL
USERENV.DLL
UXTHEME.DLL
No problems:
ADVAPI32.DLL
API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
API-MS-WIN-CORE-FILE-L1-1-0.DLL
API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
API-MS-WIN-CORE-HEAP-L1-1-0.DLL
API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
API-MS-WIN-CORE-IO-L1-1-0.DLL
API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
API-MS-WIN-CORE-MISC-L1-1-0.DLL
API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
API-MS-WIN-CORE-STRING-L1-1-0.DLL
API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
API-MS-WIN-CORE-UTIL-L1-1-0.DLL
API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
AWT.DLL
CRYPTBASE.DLL
GDI32.DLL
JAVA.DLL
JAWT.DLL
JAWTACCESSBRIDGE.DLL
KERNEL32.DLL
KERNELBASE.DLL
LPK.DLL
MSVCR100.DLL
MSVCRT.DLL
NTDLL.DLL
OLEAUT32.DLL
RPCRT4.DLL
SSPICLI.DLL
USER32.DLL
USP10.DLL
VERIFY.DLL
ACLUI.DLL
ACTIVEDS.DLL
ADSLDPC.DLL
ADVPACK.DLL
API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
APPHELP.DLL
ATL.DLL
AUTHZ.DLL
AVRT.DLL
BCRYPT.DLL
BROWCLI.DLL
CABINET.DLL
CERTCLI.DLL
CERTENROLL.DLL
CFGMGR32.DLL
CLBCATQ.DLL
COMCTL32.DLL
COMCTL32.DLL
COMDLG32.DLL
CREDUI.DLL
CRYPT32.DLL
CRYPTSP.DLL
CRYPTUI.DLL
CSCAPI.DLL
D2D1.DLL
D3D11.DLL
DAVHLPR.DLL
DBGHELP.DLL
DEVMGR.DLL
DEVOBJ.DLL
DEVRTL.DLL
DFSCLI.DLL
DHCPCSVC.DLL
DHCPCSVC6.DLL
DNSAPI.DLL
DRVSTORE.DLL
DSROLE.DLL
DUI70.DLL
DUSER.DLL
DWRITE.DLL
DXGI.DLL
EAPPCFG.DLL
EAPPPRXY.DLL
EFSADU.DLL
EFSUTIL.DLL
ELSCORE.DLL
ESENT.DLL
FMS.DLL
GDIPLUS.DLL
GPAPI.DLL
HLINK.DLL
IEADVPACK.DLL
IERTUTIL.DLL
IEUI.DLL
IMAGEHLP.DLL
IMGUTIL.DLL
INETCOMM.DLL
IPHLPAPI.DLL
LINKINFO.DLL
LOGONCLI.DLL
MFC42U.DLL
MLANG.DLL
MMDEVAPI.DLL
MPR.DLL
MPRAPI.DLL
MPRMSG.DLL
MSASN1.DLL
MSCTF.DLL
MSFEEDS.DLL
MSHTML.DLL
MSI.DLL
MSILTCFG.DLL
MSIMG32.DLL
MSLS31.DLL
MSOERT2.DLL
MSRATING.DLL
MSSIGN32.DLL
NCRYPT.DLL
NETAPI32.DLL
NETBIOS.DLL
NETJOIN.DLL
NETPLWIZ.DLL
NETUTILS.DLL
NEWDEV.DLL
NORMALIZ.DLL
NSI.DLL
NTDSAPI.DLL
NTSHRUI.DLL
OCCACHE.DLL
ODBC32.DLL
OLEACC.DLL
OLEDLG.DLL
ONEX.DLL
PCWUM.DLL
POWRPROF.DLL
PRINTUI.DLL
PRNTVPT.DLL
PROFAPI.DLL
PROPSYS.DLL
PSAPI.DLL
PUIAPI.DLL
RASAPI32.DLL
RASDLG.DLL
RASMAN.DLL
REGAPI.DLL
RSTRTMGR.DLL
RTUTILS.DLL
SAMCLI.DLL
SAMLIB.DLL
SCECLI.DLL
SECUR32.DLL
SENSAPI.DLL
SETUPAPI.DLL
SHDOCVW.DLL
SHELL32.DLL
SHLWAPI.DLL
SLC.DLL
SPFILEQ.DLL
SPINF.DLL
SPPC.DLL
SRVCLI.DLL
TAPI32.DLL
UIAUTOMATIONCORE.DLL
URLMON.DLL
VAULTCLI.DLL
VERSION.DLL
VPNIKEAPI.DLL
W32TOPL.DLL
WDI.DLL
WEBIO.DLL
WEBSERVICES.DLL
WER.DLL
WERUI.DLL
WINBRAND.DLL
WINDOWSCODECS.DLL
WINHTTP.DLL
WININET.DLL
WINMM.DLL
WINNSI.DLL
WINSCARD.DLL
WINSPOOL.DRV
WINSTA.DLL
WINTRUST.DLL
WKSCLI.DLL
WLANAPI.DLL
WLANUTIL.DLL
WLDAP32.DLL
WS2_32.DLL
WTSAPI32.DLL
XMLLITE.DLL
>
> -- 
> best regards,
> Anthony
>
> On 12/16/2013 08:02 PM, Pete Brunet wrote:
>> I'm writing a regression test and it is failing trying to load
>> bin\JAWTAccessBridge.DLL.  It was successful in loading
>> bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs are
>> in jre\bin.  Here's the failure:
>>
>> java.lang.UnsatisfiedLinkError:
>> C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
>>
>> Can't find dependent libraries
>>   at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>   at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
>>   at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
>>   at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>   at java.lang.System.loadLibrary(System.java:1119)
>>   at JABDLL$4.run(JABDLL.java:116)
>>   at java.security.AccessController.doPrivileged(Native Method)
>>   at JABDLL.foundLegacyDLLs(JABDLL.java:113)
>>   at JABDLL.main(JABDLL.java:67)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>
>>   at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>
>>   at java.lang.reflect.Method.invoke(Method.java:483)
>>   at
>> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>>   at java.lang.Thread.run(Thread.java:744)
>>
>> Here's the pertinent code:
>>
>> private static boolean foundLegacyDLLs() {
>>              java.security.AccessController.doPrivileged(
>>                  new java.security.PrivilegedAction() {
>>                      public Object run() {
>>                          System.loadLibrary("JavaAccessBridge");
>>                          return null;
>>                      }
>>                  }, null, new
>> RuntimePermission("loadLibrary.JavaAccessBridge")
>>              );
>>              java.security.AccessController.doPrivileged(
>>                  new java.security.PrivilegedAction() {
>>                      public Object run() {
>>                          System.loadLibrary("JAWTAccessBridge");  //
>> line
>> 116, fails here
>>                          return null;
>>                      }
>>                  }, null, new
>> RuntimePermission("loadLibrary.JAWTAccessBridge")
>>              );
>>              return true;
>>      }
>>
>> Here's the jtreg run:
>>
>> $ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
>> -testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
>>
>> -verbose:summary closed/com/sun/java/accessibility/JABDLL.java
>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
>> needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
>> this can be ignored
>> FAILED: closed/com/sun/java/accessibility/JABDLL.java
>> Test results: failed: 1
>> Report written to
>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
>> Results written to C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
>> Error: Some tests failed or other problems occurred.
>>
>> Here's the prolog to the test case:
>>
>> /*
>>    * @test
>>    * @summary ...
>>    * @run main JABDLL
>>    */
>>
>> The built image runs fine in normal use, i.e. I can run SwingSet2 with
>> the same image so I assume it's something I'm not doing right with
>> respect to jtreg.
>>
>> The dependency walker reports jvm.dll which is in bin\server.  I tried
>> moving that to bin but that didn't help.   Also some Win DLLs were
>> reported most of which start with API-MS-WIN- but I assume those are
>> false negatives.  The sdk image I am testing is 32 bit and the DLL is
>> also 32 bit.  Hopefully it's just something I don't yet understand about
>> jprt, like maybe a missing @ tag in the prolog.
>>
>> Any ideas on how to debug this?
>>
>> Pete
>>
>>


From peter.brunet at oracle.com  Mon Dec 16 18:25:29 2013
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 16 Dec 2013 20:25:29 -0600
Subject: <AWT Dev> Regression test failure loading a DLL
In-Reply-To: <52AF661B.4060602@oracle.com>
References: <52AF2405.5050107@oracle.com> <52AF5556.3020004@oracle.com>
	<52AF661B.4060602@oracle.com>
Message-ID: <52AFB619.5000903@oracle.com>


On 12/16/13 2:44 PM, Pete Brunet wrote:
> Hi Anthony, Thanks for helping...
>
> On 12/16/13 1:32 PM, Anthony Petrov wrote:
>> Hi Pete,
>>
>> I see you've already tried the Dependency Walker.
>>
>> 1. Could you please clarify the following: if you compile two lists of
>> dependencies, one for JavaAccessBridge.dll and another for
>> JAWTAccessBridge.DLL, and compare them, are there any differences?
> Differences:
>
> JAWT* has these extras
> jvm.dll - error opening file
Artem had indicated earlier that this is a false negative, i.e. the JVM
will load it.
> awt.dll - no problem with this and the following
> java.dll
> jawt.dll
> verify.dll
>
> Immediate load in JAWT*, delay load in Java*
> ole32 - colored red, i.e. missing export function required by parent module
I looked into why this was colored red.  The problem, at least with
respect to Dependency Walker, is that mshtml.dll is expecting an export
in ole32.dll of CoDecrementMTAUsage.  I asssume this is not really an
issue since things work OK outside of jtreg.
> oleaut32.dll - no problem
>> 2. If you change the order of loading the libraries, will it fail
>> right away w/o even loading the JavaAccessBridge.dll ?
> yes
>> 3. If the above doesn't help, please post the full list of
>> dependencies for JAWTAccessBridge.DLL as reported by the Dependency
>> Walker.
> Error opening file:
> JVM.DLL
> API-MS-WIN-CORE-COM-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
> API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
> DCOMP.DLL
> GPSVC.DLL
> IESHIMS.DLL
> Red (missing export function required by parent module):
> API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
> OLE32.DLL
> Red, delay load:
> DWMAPI.DLL
> IEFRAME.DLL
> IMM32.DLL
> MFPLAT.DLL
> NDFAPI.DLL
> USERENV.DLL
> UXTHEME.DLL
> No problems:
> ADVAPI32.DLL
> API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
> API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
> API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
> API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
> API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
> API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
> API-MS-WIN-CORE-FILE-L1-1-0.DLL
> API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
> API-MS-WIN-CORE-HEAP-L1-1-0.DLL
> API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
> API-MS-WIN-CORE-IO-L1-1-0.DLL
> API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
> API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
> API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
> API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
> API-MS-WIN-CORE-MISC-L1-1-0.DLL
> API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
> API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
> API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
> API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
> API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
> API-MS-WIN-CORE-STRING-L1-1-0.DLL
> API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
> API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
> API-MS-WIN-CORE-UTIL-L1-1-0.DLL
> API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
> API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
> API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
> API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
> API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
> API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
> AWT.DLL
> CRYPTBASE.DLL
> GDI32.DLL
> JAVA.DLL
> JAWT.DLL
> JAWTACCESSBRIDGE.DLL
> KERNEL32.DLL
> KERNELBASE.DLL
> LPK.DLL
> MSVCR100.DLL
> MSVCRT.DLL
> NTDLL.DLL
> OLEAUT32.DLL
> RPCRT4.DLL
> SSPICLI.DLL
> USER32.DLL
> USP10.DLL
> VERIFY.DLL
> ACLUI.DLL
> ACTIVEDS.DLL
> ADSLDPC.DLL
> ADVPACK.DLL
> API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
> API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
> API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
> API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
> API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
> API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
> API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
> API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
> API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
> API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
> APPHELP.DLL
> ATL.DLL
> AUTHZ.DLL
> AVRT.DLL
> BCRYPT.DLL
> BROWCLI.DLL
> CABINET.DLL
> CERTCLI.DLL
> CERTENROLL.DLL
> CFGMGR32.DLL
> CLBCATQ.DLL
> COMCTL32.DLL
> COMCTL32.DLL
> COMDLG32.DLL
> CREDUI.DLL
> CRYPT32.DLL
> CRYPTSP.DLL
> CRYPTUI.DLL
> CSCAPI.DLL
> D2D1.DLL
> D3D11.DLL
> DAVHLPR.DLL
> DBGHELP.DLL
> DEVMGR.DLL
> DEVOBJ.DLL
> DEVRTL.DLL
> DFSCLI.DLL
> DHCPCSVC.DLL
> DHCPCSVC6.DLL
> DNSAPI.DLL
> DRVSTORE.DLL
> DSROLE.DLL
> DUI70.DLL
> DUSER.DLL
> DWRITE.DLL
> DXGI.DLL
> EAPPCFG.DLL
> EAPPPRXY.DLL
> EFSADU.DLL
> EFSUTIL.DLL
> ELSCORE.DLL
> ESENT.DLL
> FMS.DLL
> GDIPLUS.DLL
> GPAPI.DLL
> HLINK.DLL
> IEADVPACK.DLL
> IERTUTIL.DLL
> IEUI.DLL
> IMAGEHLP.DLL
> IMGUTIL.DLL
> INETCOMM.DLL
> IPHLPAPI.DLL
> LINKINFO.DLL
> LOGONCLI.DLL
> MFC42U.DLL
> MLANG.DLL
> MMDEVAPI.DLL
> MPR.DLL
> MPRAPI.DLL
> MPRMSG.DLL
> MSASN1.DLL
> MSCTF.DLL
> MSFEEDS.DLL
> MSHTML.DLL
> MSI.DLL
> MSILTCFG.DLL
> MSIMG32.DLL
> MSLS31.DLL
> MSOERT2.DLL
> MSRATING.DLL
> MSSIGN32.DLL
> NCRYPT.DLL
> NETAPI32.DLL
> NETBIOS.DLL
> NETJOIN.DLL
> NETPLWIZ.DLL
> NETUTILS.DLL
> NEWDEV.DLL
> NORMALIZ.DLL
> NSI.DLL
> NTDSAPI.DLL
> NTSHRUI.DLL
> OCCACHE.DLL
> ODBC32.DLL
> OLEACC.DLL
> OLEDLG.DLL
> ONEX.DLL
> PCWUM.DLL
> POWRPROF.DLL
> PRINTUI.DLL
> PRNTVPT.DLL
> PROFAPI.DLL
> PROPSYS.DLL
> PSAPI.DLL
> PUIAPI.DLL
> RASAPI32.DLL
> RASDLG.DLL
> RASMAN.DLL
> REGAPI.DLL
> RSTRTMGR.DLL
> RTUTILS.DLL
> SAMCLI.DLL
> SAMLIB.DLL
> SCECLI.DLL
> SECUR32.DLL
> SENSAPI.DLL
> SETUPAPI.DLL
> SHDOCVW.DLL
> SHELL32.DLL
> SHLWAPI.DLL
> SLC.DLL
> SPFILEQ.DLL
> SPINF.DLL
> SPPC.DLL
> SRVCLI.DLL
> TAPI32.DLL
> UIAUTOMATIONCORE.DLL
> URLMON.DLL
> VAULTCLI.DLL
> VERSION.DLL
> VPNIKEAPI.DLL
> W32TOPL.DLL
> WDI.DLL
> WEBIO.DLL
> WEBSERVICES.DLL
> WER.DLL
> WERUI.DLL
> WINBRAND.DLL
> WINDOWSCODECS.DLL
> WINHTTP.DLL
> WININET.DLL
> WINMM.DLL
> WINNSI.DLL
> WINSCARD.DLL
> WINSPOOL.DRV
> WINSTA.DLL
> WINTRUST.DLL
> WKSCLI.DLL
> WLANAPI.DLL
> WLANUTIL.DLL
> WLDAP32.DLL
> WS2_32.DLL
> WTSAPI32.DLL
> XMLLITE.DLL
>> -- 
>> best regards,
>> Anthony
>>
>> On 12/16/2013 08:02 PM, Pete Brunet wrote:
>>> I'm writing a regression test and it is failing trying to load
>>> bin\JAWTAccessBridge.DLL.  It was successful in loading
>>> bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs are
>>> in jre\bin.  Here's the failure:
>>>
>>> java.lang.UnsatisfiedLinkError:
>>> C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
>>>
>>> Can't find dependent libraries
>>>   at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>   at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
>>>   at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
>>>   at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>>   at java.lang.System.loadLibrary(System.java:1119)
>>>   at JABDLL$4.run(JABDLL.java:116)
>>>   at java.security.AccessController.doPrivileged(Native Method)
>>>   at JABDLL.foundLegacyDLLs(JABDLL.java:113)
>>>   at JABDLL.main(JABDLL.java:67)
>>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>   at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>
>>>   at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>
>>>   at java.lang.reflect.Method.invoke(Method.java:483)
>>>   at
>>> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>>>   at java.lang.Thread.run(Thread.java:744)
>>>
>>> Here's the pertinent code:
>>>
>>> private static boolean foundLegacyDLLs() {
>>>              java.security.AccessController.doPrivileged(
>>>                  new java.security.PrivilegedAction() {
>>>                      public Object run() {
>>>                          System.loadLibrary("JavaAccessBridge");
>>>                          return null;
>>>                      }
>>>                  }, null, new
>>> RuntimePermission("loadLibrary.JavaAccessBridge")
>>>              );
>>>              java.security.AccessController.doPrivileged(
>>>                  new java.security.PrivilegedAction() {
>>>                      public Object run() {
>>>                          System.loadLibrary("JAWTAccessBridge");  //
>>> line
>>> 116, fails here
>>>                          return null;
>>>                      }
>>>                  }, null, new
>>> RuntimePermission("loadLibrary.JAWTAccessBridge")
>>>              );
>>>              return true;
>>>      }
>>>
>>> Here's the jtreg run:
>>>
>>> $ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
>>> -testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
>>>
>>> -verbose:summary closed/com/sun/java/accessibility/JABDLL.java
>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
>>> needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
>>> this can be ignored
>>> FAILED: closed/com/sun/java/accessibility/JABDLL.java
>>> Test results: failed: 1
>>> Report written to
>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
>>> Results written to C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
>>> Error: Some tests failed or other problems occurred.
>>>
>>> Here's the prolog to the test case:
>>>
>>> /*
>>>    * @test
>>>    * @summary ...
>>>    * @run main JABDLL
>>>    */
>>>
>>> The built image runs fine in normal use, i.e. I can run SwingSet2 with
>>> the same image so I assume it's something I'm not doing right with
>>> respect to jtreg.
>>>
>>> The dependency walker reports jvm.dll which is in bin\server.  I tried
>>> moving that to bin but that didn't help.   Also some Win DLLs were
>>> reported most of which start with API-MS-WIN- but I assume those are
>>> false negatives.  The sdk image I am testing is 32 bit and the DLL is
>>> also 32 bit.  Hopefully it's just something I don't yet understand about
>>> jprt, like maybe a missing @ tag in the prolog.
>>>
>>> Any ideas on how to debug this?
>>>
>>> Pete
>>>
>>>


From anton.tarasov at oracle.com  Mon Dec 16 22:22:32 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Tue, 17 Dec 2013 10:22:32 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8023148 [macosx]
 java.util.NoSuchElementException at java.util.LinkedList.getFirst
In-Reply-To: <2411C7FD-CFF4-4CBD-85F3-EB460C139E6C@oracle.com>
References: <2411C7FD-CFF4-4CBD-85F3-EB460C139E6C@oracle.com>
Message-ID: <52AFEDA8.3060208@oracle.com>

Looks fine for me.

Thanks,
Anton.

On 16.12.2013 13:56, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fi for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8023148
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8023148/webrev/
>
> The problem is simple: LinkedList throws an exception on getFirst if the list is empty. The fix is trivial, so no reg test.
>
> With best regards. Petr.


From Sergey.Bylokhov at oracle.com  Tue Dec 17 02:52:41 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 17 Dec 2013 14:52:41 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8007220 [macosx] Setting
 popupmenu on TrayIcon do not work if done *after* adding TrayIcon
In-Reply-To: <6596B350-7B46-4029-916D-CF96A408EB32@oracle.com>
References: <B73165E1-0CF0-47F8-B48D-3C064F82EEFA@oracle.com>
	<52AEF449.8000705@oracle.com>
	<6596B350-7B46-4029-916D-CF96A408EB32@oracle.com>
Message-ID: <52B02CF9.2000609@oracle.com>

On 12/16/13 5:25 PM, Petr Pchelko wrote:
> Hello, Sergey.
>
>> Since you add new call to addNotify(), can you check that we call removeNotify when necessary?
> On Win and Linux we were calling it properly for popups, but on mac os x we haven't been doing that. The new version of the fix fixes that.
Thanks for this check. Is it possible to create a new test for this issue?
>
> The new version is here:
> http://cr.openjdk.java.net/~pchelko/9/8007220/webrev.01/
>
> With best regards. Petr.
>
> On 16.12.2013, at 16:38, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Petr.
>> Since you add new call to addNotify(), can you check that we call removeNotify when necessary?
>>
>> On 16.12.2013 16:02, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8007220
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8007220/webrev/
>>>
>>> The problem: the CTrayIcon.popup field was set only in a constructor, but it should be updated every time the popup is opened.
>>>
>>> With best regards. Petr.
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Dec 17 03:07:16 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 17 Dec 2013 15:07:16 +0400
Subject: <AWT Dev> [9] Review request for 8029979: Allow multiple calls
	to DropTargetDropEvent.acceptDrop()
In-Reply-To: <52AF0BF9.9080906@oracle.com>
References: <52AB3BA0.4070805@oracle.com> <52AB94E8.50405@oracle.com>
	<52AF0BF9.9080906@oracle.com>
Message-ID: <52B03064.4050707@oracle.com>

Hi, Anthony.
On 12/16/13 6:19 PM, Anthony Petrov wrote:
>> Is it necessary to check !dropComplete?
>
> Well, I wanted to add this case to my regression test, but it appears 
> that the DropTargetContextPeer gets destroyed after user's code calls 
> dropComplete(), and so this check is never performed actually. 
> However, I'd like to keep it in place because it just doesn't make any 
> sense to call acceptDrop() after the drop is complete. It looks safe 
> to me.
It will be strange to have dropStatus= ACCEPT and drop status complete 
at the same moment, No?
>
>
> -- 
> best regards,
> Anthony
>
>>
>> On 13.12.2013 20:53, Anthony Petrov wrote:
>>> Hi Petr, Sergey,
>>>
>>> Please review a fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8029979 at:
>>>
>>> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.0/
>>>
>>> I enable calling SunDropTargetContextPeer.acceptDrop() as many times
>>> as needed, for as long as the DnD operation isn't complete yet.
>>> Running open and closed DnD regression tests revealed no new failures.
>>>
>>> Note that later we will need to back-port this fix to 8u20.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>
>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Tue Dec 17 04:24:36 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 17 Dec 2013 16:24:36 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8007220 [macosx] Setting
	popupmenu on TrayIcon do not work if done *after* adding TrayIcon
In-Reply-To: <52B02CF9.2000609@oracle.com>
References: <B73165E1-0CF0-47F8-B48D-3C064F82EEFA@oracle.com>
	<52AEF449.8000705@oracle.com>
	<6596B350-7B46-4029-916D-CF96A408EB32@oracle.com>
	<52B02CF9.2000609@oracle.com>
Message-ID: <94D1565B-9312-4BA3-ABD8-E2A8922F011B@oracle.com>

Hello, Sergey.

> Thanks for this check. Is it possible to create a new test for this issue?

Everything is possible) Please see the updated webrev here: http://cr.openjdk.java.net/~pchelko/9/8007220/webrev.02/

I've added one more test: PopupMenuLeakTest - it's an automatic test to verify that the reference to PopupMenu is GCd after the TrayIcon was removed. 

With best regards. Petr.

On 17.12.2013, at 14:52, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> On 12/16/13 5:25 PM, Petr Pchelko wrote:
>> Hello, Sergey.
>> 
>>> Since you add new call to addNotify(), can you check that we call removeNotify when necessary?
>> On Win and Linux we were calling it properly for popups, but on mac os x we haven't been doing that. The new version of the fix fixes that.
> Thanks for this check. Is it possible to create a new test for this issue?
>> 
>> The new version is here:
>> http://cr.openjdk.java.net/~pchelko/9/8007220/webrev.01/
>> 
>> With best regards. Petr.
>> 
>> On 16.12.2013, at 16:38, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>> 
>>> Hi, Petr.
>>> Since you add new call to addNotify(), can you check that we call removeNotify when necessary?
>>> 
>>> On 16.12.2013 16:02, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>> 
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8007220
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/9/8007220/webrev/
>>>> 
>>>> The problem: the CTrayIcon.popup field was set only in a constructor, but it should be updated every time the popup is opened.
>>>> 
>>>> With best regards. Petr.
>>> 
>>> -- 
>>> Best regards, Sergey.
>>> 
> 
> 
> -- 
> Best regards, Sergey.
> 


From anthony.petrov at oracle.com  Tue Dec 17 04:37:36 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 17 Dec 2013 16:37:36 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8007220 [macosx] Setting
 popupmenu on TrayIcon do not work if done *after* adding TrayIcon
In-Reply-To: <94D1565B-9312-4BA3-ABD8-E2A8922F011B@oracle.com>
References: <B73165E1-0CF0-47F8-B48D-3C064F82EEFA@oracle.com>
	<52AEF449.8000705@oracle.com>
	<6596B350-7B46-4029-916D-CF96A408EB32@oracle.com>
	<52B02CF9.2000609@oracle.com>
	<94D1565B-9312-4BA3-ABD8-E2A8922F011B@oracle.com>
Message-ID: <52B04590.9010705@oracle.com>

The fix still looks fine to me.

--
best regards,
Anthony

On 12/17/2013 04:24 PM, Petr Pchelko wrote:
> Hello, Sergey.
>
>> Thanks for this check. Is it possible to create a new test for this issue?
>
> Everything is possible) Please see the updated webrev here: http://cr.openjdk.java.net/~pchelko/9/8007220/webrev.02/
>
> I've added one more test: PopupMenuLeakTest - it's an automatic test to verify that the reference to PopupMenu is GCd after the TrayIcon was removed.
>
> With best regards. Petr.
>
> On 17.12.2013, at 14:52, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> On 12/16/13 5:25 PM, Petr Pchelko wrote:
>>> Hello, Sergey.
>>>
>>>> Since you add new call to addNotify(), can you check that we call removeNotify when necessary?
>>> On Win and Linux we were calling it properly for popups, but on mac os x we haven't been doing that. The new version of the fix fixes that.
>> Thanks for this check. Is it possible to create a new test for this issue?
>>>
>>> The new version is here:
>>> http://cr.openjdk.java.net/~pchelko/9/8007220/webrev.01/
>>>
>>> With best regards. Petr.
>>>
>>> On 16.12.2013, at 16:38, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>>
>>>> Hi, Petr.
>>>> Since you add new call to addNotify(), can you check that we call removeNotify when necessary?
>>>>
>>>> On 16.12.2013 16:02, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>>
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8007220
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8007220/webrev/
>>>>>
>>>>> The problem: the CTrayIcon.popup field was set only in a constructor, but it should be updated every time the popup is opened.
>>>>>
>>>>> With best regards. Petr.
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>>
>>
>>
>> --
>> Best regards, Sergey.
>>
>

From anthony.petrov at oracle.com  Tue Dec 17 04:59:12 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 17 Dec 2013 16:59:12 +0400
Subject: <AWT Dev> [9] Review request for 8029979: Allow multiple calls
	to DropTargetDropEvent.acceptDrop()
In-Reply-To: <52B03064.4050707@oracle.com>
References: <52AB3BA0.4070805@oracle.com> <52AB94E8.50405@oracle.com>
	<52AF0BF9.9080906@oracle.com> <52B03064.4050707@oracle.com>
Message-ID: <52B04AA0.10600@oracle.com>

Hi Sergey,

Good point. You're right, it's just impossible to happen. So here's an 
updated webrev:

http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.2/

--
best regards,
Anthony

On 12/17/2013 03:07 PM, Sergey Bylokhov wrote:
> Hi, Anthony.
> On 12/16/13 6:19 PM, Anthony Petrov wrote:
>>> Is it necessary to check !dropComplete?
>>
>> Well, I wanted to add this case to my regression test, but it appears
>> that the DropTargetContextPeer gets destroyed after user's code calls
>> dropComplete(), and so this check is never performed actually.
>> However, I'd like to keep it in place because it just doesn't make any
>> sense to call acceptDrop() after the drop is complete. It looks safe
>> to me.
> It will be strange to have dropStatus= ACCEPT and drop status complete
> at the same moment, No?
>>
>>
>> --
>> best regards,
>> Anthony
>>
>>>
>>> On 13.12.2013 20:53, Anthony Petrov wrote:
>>>> Hi Petr, Sergey,
>>>>
>>>> Please review a fix for
>>>> https://bugs.openjdk.java.net/browse/JDK-8029979 at:
>>>>
>>>> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.0/
>>>>
>>>> I enable calling SunDropTargetContextPeer.acceptDrop() as many times
>>>> as needed, for as long as the DnD operation isn't complete yet.
>>>> Running open and closed DnD regression tests revealed no new failures.
>>>>
>>>> Note that later we will need to back-port this fix to 8u20.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>
>>>
>
>

From anthony.petrov at oracle.com  Tue Dec 17 05:29:49 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 17 Dec 2013 17:29:49 +0400
Subject: <AWT Dev> Regression test failure loading a DLL
In-Reply-To: <52AF661B.4060602@oracle.com>
References: <52AF2405.5050107@oracle.com> <52AF5556.3020004@oracle.com>
	<52AF661B.4060602@oracle.com>
Message-ID: <52B051CD.7070306@oracle.com>

> Immediate load in JAWT*, delay load in Java*

Why is that? Can you try re-linking the JAWTAccessBridge.DLL so that it 
uses delayed libs loading (which is always a good thing) and see if this 
changes anything?

Also,
> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL

JDK doesn't support WinRT currently. The JAWT* (or any binary in JDK) 
just shouldn't be linked against these libraries (and probably other 
API-MS-*, too). Where do the dependencies come from? What does your 
Makefile do to link the JAWT* lib?

--
best regards,
Anthony

On 12/17/2013 12:44 AM, Pete Brunet wrote:
> Hi Anthony, Thanks for helping...
>
> On 12/16/13 1:32 PM, Anthony Petrov wrote:
>> Hi Pete,
>>
>> I see you've already tried the Dependency Walker.
>>
>> 1. Could you please clarify the following: if you compile two lists of
>> dependencies, one for JavaAccessBridge.dll and another for
>> JAWTAccessBridge.DLL, and compare them, are there any differences?
> Differences:
>
> JAWT* has these extras
> jvm.dll - error opening file
> awt.dll - no problem with this and the following
> java.dll
> jawt.dll
> verify.dll
>
> Immediate load in JAWT*, delay load in Java*
> ole32 - colored red, i.e. missing export function required by parent module
> oleaut32.dll - no problem
>>
>> 2. If you change the order of loading the libraries, will it fail
>> right away w/o even loading the JavaAccessBridge.dll ?
> yes
>>
>> 3. If the above doesn't help, please post the full list of
>> dependencies for JAWTAccessBridge.DLL as reported by the Dependency
>> Walker.
> Error opening file:
> JVM.DLL
> API-MS-WIN-CORE-COM-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
> API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
> DCOMP.DLL
> GPSVC.DLL
> IESHIMS.DLL
> Red (missing export function required by parent module):
> API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
> OLE32.DLL
> Red, delay load:
> DWMAPI.DLL
> IEFRAME.DLL
> IMM32.DLL
> MFPLAT.DLL
> NDFAPI.DLL
> USERENV.DLL
> UXTHEME.DLL
> No problems:
> ADVAPI32.DLL
> API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
> API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
> API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
> API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
> API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
> API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
> API-MS-WIN-CORE-FILE-L1-1-0.DLL
> API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
> API-MS-WIN-CORE-HEAP-L1-1-0.DLL
> API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
> API-MS-WIN-CORE-IO-L1-1-0.DLL
> API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
> API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
> API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
> API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
> API-MS-WIN-CORE-MISC-L1-1-0.DLL
> API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
> API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
> API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
> API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
> API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
> API-MS-WIN-CORE-STRING-L1-1-0.DLL
> API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
> API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
> API-MS-WIN-CORE-UTIL-L1-1-0.DLL
> API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
> API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
> API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
> API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
> API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
> API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
> AWT.DLL
> CRYPTBASE.DLL
> GDI32.DLL
> JAVA.DLL
> JAWT.DLL
> JAWTACCESSBRIDGE.DLL
> KERNEL32.DLL
> KERNELBASE.DLL
> LPK.DLL
> MSVCR100.DLL
> MSVCRT.DLL
> NTDLL.DLL
> OLEAUT32.DLL
> RPCRT4.DLL
> SSPICLI.DLL
> USER32.DLL
> USP10.DLL
> VERIFY.DLL
> ACLUI.DLL
> ACTIVEDS.DLL
> ADSLDPC.DLL
> ADVPACK.DLL
> API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
> API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
> API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
> API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
> API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
> API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
> API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
> API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
> API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
> API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
> APPHELP.DLL
> ATL.DLL
> AUTHZ.DLL
> AVRT.DLL
> BCRYPT.DLL
> BROWCLI.DLL
> CABINET.DLL
> CERTCLI.DLL
> CERTENROLL.DLL
> CFGMGR32.DLL
> CLBCATQ.DLL
> COMCTL32.DLL
> COMCTL32.DLL
> COMDLG32.DLL
> CREDUI.DLL
> CRYPT32.DLL
> CRYPTSP.DLL
> CRYPTUI.DLL
> CSCAPI.DLL
> D2D1.DLL
> D3D11.DLL
> DAVHLPR.DLL
> DBGHELP.DLL
> DEVMGR.DLL
> DEVOBJ.DLL
> DEVRTL.DLL
> DFSCLI.DLL
> DHCPCSVC.DLL
> DHCPCSVC6.DLL
> DNSAPI.DLL
> DRVSTORE.DLL
> DSROLE.DLL
> DUI70.DLL
> DUSER.DLL
> DWRITE.DLL
> DXGI.DLL
> EAPPCFG.DLL
> EAPPPRXY.DLL
> EFSADU.DLL
> EFSUTIL.DLL
> ELSCORE.DLL
> ESENT.DLL
> FMS.DLL
> GDIPLUS.DLL
> GPAPI.DLL
> HLINK.DLL
> IEADVPACK.DLL
> IERTUTIL.DLL
> IEUI.DLL
> IMAGEHLP.DLL
> IMGUTIL.DLL
> INETCOMM.DLL
> IPHLPAPI.DLL
> LINKINFO.DLL
> LOGONCLI.DLL
> MFC42U.DLL
> MLANG.DLL
> MMDEVAPI.DLL
> MPR.DLL
> MPRAPI.DLL
> MPRMSG.DLL
> MSASN1.DLL
> MSCTF.DLL
> MSFEEDS.DLL
> MSHTML.DLL
> MSI.DLL
> MSILTCFG.DLL
> MSIMG32.DLL
> MSLS31.DLL
> MSOERT2.DLL
> MSRATING.DLL
> MSSIGN32.DLL
> NCRYPT.DLL
> NETAPI32.DLL
> NETBIOS.DLL
> NETJOIN.DLL
> NETPLWIZ.DLL
> NETUTILS.DLL
> NEWDEV.DLL
> NORMALIZ.DLL
> NSI.DLL
> NTDSAPI.DLL
> NTSHRUI.DLL
> OCCACHE.DLL
> ODBC32.DLL
> OLEACC.DLL
> OLEDLG.DLL
> ONEX.DLL
> PCWUM.DLL
> POWRPROF.DLL
> PRINTUI.DLL
> PRNTVPT.DLL
> PROFAPI.DLL
> PROPSYS.DLL
> PSAPI.DLL
> PUIAPI.DLL
> RASAPI32.DLL
> RASDLG.DLL
> RASMAN.DLL
> REGAPI.DLL
> RSTRTMGR.DLL
> RTUTILS.DLL
> SAMCLI.DLL
> SAMLIB.DLL
> SCECLI.DLL
> SECUR32.DLL
> SENSAPI.DLL
> SETUPAPI.DLL
> SHDOCVW.DLL
> SHELL32.DLL
> SHLWAPI.DLL
> SLC.DLL
> SPFILEQ.DLL
> SPINF.DLL
> SPPC.DLL
> SRVCLI.DLL
> TAPI32.DLL
> UIAUTOMATIONCORE.DLL
> URLMON.DLL
> VAULTCLI.DLL
> VERSION.DLL
> VPNIKEAPI.DLL
> W32TOPL.DLL
> WDI.DLL
> WEBIO.DLL
> WEBSERVICES.DLL
> WER.DLL
> WERUI.DLL
> WINBRAND.DLL
> WINDOWSCODECS.DLL
> WINHTTP.DLL
> WININET.DLL
> WINMM.DLL
> WINNSI.DLL
> WINSCARD.DLL
> WINSPOOL.DRV
> WINSTA.DLL
> WINTRUST.DLL
> WKSCLI.DLL
> WLANAPI.DLL
> WLANUTIL.DLL
> WLDAP32.DLL
> WS2_32.DLL
> WTSAPI32.DLL
> XMLLITE.DLL
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/16/2013 08:02 PM, Pete Brunet wrote:
>>> I'm writing a regression test and it is failing trying to load
>>> bin\JAWTAccessBridge.DLL.  It was successful in loading
>>> bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs are
>>> in jre\bin.  Here's the failure:
>>>
>>> java.lang.UnsatisfiedLinkError:
>>> C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
>>>
>>> Can't find dependent libraries
>>>    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
>>>    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
>>>    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>>    at java.lang.System.loadLibrary(System.java:1119)
>>>    at JABDLL$4.run(JABDLL.java:116)
>>>    at java.security.AccessController.doPrivileged(Native Method)
>>>    at JABDLL.foundLegacyDLLs(JABDLL.java:113)
>>>    at JABDLL.main(JABDLL.java:67)
>>>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>    at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>
>>>    at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>
>>>    at java.lang.reflect.Method.invoke(Method.java:483)
>>>    at
>>> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>>>    at java.lang.Thread.run(Thread.java:744)
>>>
>>> Here's the pertinent code:
>>>
>>> private static boolean foundLegacyDLLs() {
>>>               java.security.AccessController.doPrivileged(
>>>                   new java.security.PrivilegedAction() {
>>>                       public Object run() {
>>>                           System.loadLibrary("JavaAccessBridge");
>>>                           return null;
>>>                       }
>>>                   }, null, new
>>> RuntimePermission("loadLibrary.JavaAccessBridge")
>>>               );
>>>               java.security.AccessController.doPrivileged(
>>>                   new java.security.PrivilegedAction() {
>>>                       public Object run() {
>>>                           System.loadLibrary("JAWTAccessBridge");  //
>>> line
>>> 116, fails here
>>>                           return null;
>>>                       }
>>>                   }, null, new
>>> RuntimePermission("loadLibrary.JAWTAccessBridge")
>>>               );
>>>               return true;
>>>       }
>>>
>>> Here's the jtreg run:
>>>
>>> $ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
>>> -testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
>>>
>>> -verbose:summary closed/com/sun/java/accessibility/JABDLL.java
>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
>>> needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
>>> this can be ignored
>>> FAILED: closed/com/sun/java/accessibility/JABDLL.java
>>> Test results: failed: 1
>>> Report written to
>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
>>> Results written to C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
>>> Error: Some tests failed or other problems occurred.
>>>
>>> Here's the prolog to the test case:
>>>
>>> /*
>>>     * @test
>>>     * @summary ...
>>>     * @run main JABDLL
>>>     */
>>>
>>> The built image runs fine in normal use, i.e. I can run SwingSet2 with
>>> the same image so I assume it's something I'm not doing right with
>>> respect to jtreg.
>>>
>>> The dependency walker reports jvm.dll which is in bin\server.  I tried
>>> moving that to bin but that didn't help.   Also some Win DLLs were
>>> reported most of which start with API-MS-WIN- but I assume those are
>>> false negatives.  The sdk image I am testing is 32 bit and the DLL is
>>> also 32 bit.  Hopefully it's just something I don't yet understand about
>>> jprt, like maybe a missing @ tag in the prolog.
>>>
>>> Any ideas on how to debug this?
>>>
>>> Pete
>>>
>>>
>

From anthony.petrov at oracle.com  Tue Dec 17 05:31:45 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 17 Dec 2013 17:31:45 +0400
Subject: <AWT Dev> Regression test failure loading a DLL
In-Reply-To: <52B051CD.7070306@oracle.com>
References: <52AF2405.5050107@oracle.com> <52AF5556.3020004@oracle.com>
	<52AF661B.4060602@oracle.com> <52B051CD.7070306@oracle.com>
Message-ID: <52B05241.4060105@oracle.com>

One more question: you're not using VS2012, are you? I'm asking because 
I doubt VS2010 could ever link against the WINRT libs, it's only 
possible with VS2012 which we shouldn't use for JDK currently.

--
best regards,
Anthony

On 12/17/2013 05:29 PM, Anthony Petrov wrote:
>> Immediate load in JAWT*, delay load in Java*
>
> Why is that? Can you try re-linking the JAWTAccessBridge.DLL so that it
> uses delayed libs loading (which is always a good thing) and see if this
> changes anything?
>
> Also,
>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>
> JDK doesn't support WinRT currently. The JAWT* (or any binary in JDK)
> just shouldn't be linked against these libraries (and probably other
> API-MS-*, too). Where do the dependencies come from? What does your
> Makefile do to link the JAWT* lib?
>
> --
> best regards,
> Anthony
>
> On 12/17/2013 12:44 AM, Pete Brunet wrote:
>> Hi Anthony, Thanks for helping...
>>
>> On 12/16/13 1:32 PM, Anthony Petrov wrote:
>>> Hi Pete,
>>>
>>> I see you've already tried the Dependency Walker.
>>>
>>> 1. Could you please clarify the following: if you compile two lists of
>>> dependencies, one for JavaAccessBridge.dll and another for
>>> JAWTAccessBridge.DLL, and compare them, are there any differences?
>> Differences:
>>
>> JAWT* has these extras
>> jvm.dll - error opening file
>> awt.dll - no problem with this and the following
>> java.dll
>> jawt.dll
>> verify.dll
>>
>> Immediate load in JAWT*, delay load in Java*
>> ole32 - colored red, i.e. missing export function required by parent
>> module
>> oleaut32.dll - no problem
>>>
>>> 2. If you change the order of loading the libraries, will it fail
>>> right away w/o even loading the JavaAccessBridge.dll ?
>> yes
>>>
>>> 3. If the above doesn't help, please post the full list of
>>> dependencies for JAWTAccessBridge.DLL as reported by the Dependency
>>> Walker.
>> Error opening file:
>> JVM.DLL
>> API-MS-WIN-CORE-COM-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>> API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
>> DCOMP.DLL
>> GPSVC.DLL
>> IESHIMS.DLL
>> Red (missing export function required by parent module):
>> API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
>> OLE32.DLL
>> Red, delay load:
>> DWMAPI.DLL
>> IEFRAME.DLL
>> IMM32.DLL
>> MFPLAT.DLL
>> NDFAPI.DLL
>> USERENV.DLL
>> UXTHEME.DLL
>> No problems:
>> ADVAPI32.DLL
>> API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
>> API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
>> API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
>> API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
>> API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
>> API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
>> API-MS-WIN-CORE-FILE-L1-1-0.DLL
>> API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
>> API-MS-WIN-CORE-HEAP-L1-1-0.DLL
>> API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
>> API-MS-WIN-CORE-IO-L1-1-0.DLL
>> API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
>> API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
>> API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
>> API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
>> API-MS-WIN-CORE-MISC-L1-1-0.DLL
>> API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
>> API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
>> API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
>> API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
>> API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
>> API-MS-WIN-CORE-STRING-L1-1-0.DLL
>> API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
>> API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
>> API-MS-WIN-CORE-UTIL-L1-1-0.DLL
>> API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
>> API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
>> API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
>> API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
>> API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
>> API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
>> AWT.DLL
>> CRYPTBASE.DLL
>> GDI32.DLL
>> JAVA.DLL
>> JAWT.DLL
>> JAWTACCESSBRIDGE.DLL
>> KERNEL32.DLL
>> KERNELBASE.DLL
>> LPK.DLL
>> MSVCR100.DLL
>> MSVCRT.DLL
>> NTDLL.DLL
>> OLEAUT32.DLL
>> RPCRT4.DLL
>> SSPICLI.DLL
>> USER32.DLL
>> USP10.DLL
>> VERIFY.DLL
>> ACLUI.DLL
>> ACTIVEDS.DLL
>> ADSLDPC.DLL
>> ADVPACK.DLL
>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
>> API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
>> APPHELP.DLL
>> ATL.DLL
>> AUTHZ.DLL
>> AVRT.DLL
>> BCRYPT.DLL
>> BROWCLI.DLL
>> CABINET.DLL
>> CERTCLI.DLL
>> CERTENROLL.DLL
>> CFGMGR32.DLL
>> CLBCATQ.DLL
>> COMCTL32.DLL
>> COMCTL32.DLL
>> COMDLG32.DLL
>> CREDUI.DLL
>> CRYPT32.DLL
>> CRYPTSP.DLL
>> CRYPTUI.DLL
>> CSCAPI.DLL
>> D2D1.DLL
>> D3D11.DLL
>> DAVHLPR.DLL
>> DBGHELP.DLL
>> DEVMGR.DLL
>> DEVOBJ.DLL
>> DEVRTL.DLL
>> DFSCLI.DLL
>> DHCPCSVC.DLL
>> DHCPCSVC6.DLL
>> DNSAPI.DLL
>> DRVSTORE.DLL
>> DSROLE.DLL
>> DUI70.DLL
>> DUSER.DLL
>> DWRITE.DLL
>> DXGI.DLL
>> EAPPCFG.DLL
>> EAPPPRXY.DLL
>> EFSADU.DLL
>> EFSUTIL.DLL
>> ELSCORE.DLL
>> ESENT.DLL
>> FMS.DLL
>> GDIPLUS.DLL
>> GPAPI.DLL
>> HLINK.DLL
>> IEADVPACK.DLL
>> IERTUTIL.DLL
>> IEUI.DLL
>> IMAGEHLP.DLL
>> IMGUTIL.DLL
>> INETCOMM.DLL
>> IPHLPAPI.DLL
>> LINKINFO.DLL
>> LOGONCLI.DLL
>> MFC42U.DLL
>> MLANG.DLL
>> MMDEVAPI.DLL
>> MPR.DLL
>> MPRAPI.DLL
>> MPRMSG.DLL
>> MSASN1.DLL
>> MSCTF.DLL
>> MSFEEDS.DLL
>> MSHTML.DLL
>> MSI.DLL
>> MSILTCFG.DLL
>> MSIMG32.DLL
>> MSLS31.DLL
>> MSOERT2.DLL
>> MSRATING.DLL
>> MSSIGN32.DLL
>> NCRYPT.DLL
>> NETAPI32.DLL
>> NETBIOS.DLL
>> NETJOIN.DLL
>> NETPLWIZ.DLL
>> NETUTILS.DLL
>> NEWDEV.DLL
>> NORMALIZ.DLL
>> NSI.DLL
>> NTDSAPI.DLL
>> NTSHRUI.DLL
>> OCCACHE.DLL
>> ODBC32.DLL
>> OLEACC.DLL
>> OLEDLG.DLL
>> ONEX.DLL
>> PCWUM.DLL
>> POWRPROF.DLL
>> PRINTUI.DLL
>> PRNTVPT.DLL
>> PROFAPI.DLL
>> PROPSYS.DLL
>> PSAPI.DLL
>> PUIAPI.DLL
>> RASAPI32.DLL
>> RASDLG.DLL
>> RASMAN.DLL
>> REGAPI.DLL
>> RSTRTMGR.DLL
>> RTUTILS.DLL
>> SAMCLI.DLL
>> SAMLIB.DLL
>> SCECLI.DLL
>> SECUR32.DLL
>> SENSAPI.DLL
>> SETUPAPI.DLL
>> SHDOCVW.DLL
>> SHELL32.DLL
>> SHLWAPI.DLL
>> SLC.DLL
>> SPFILEQ.DLL
>> SPINF.DLL
>> SPPC.DLL
>> SRVCLI.DLL
>> TAPI32.DLL
>> UIAUTOMATIONCORE.DLL
>> URLMON.DLL
>> VAULTCLI.DLL
>> VERSION.DLL
>> VPNIKEAPI.DLL
>> W32TOPL.DLL
>> WDI.DLL
>> WEBIO.DLL
>> WEBSERVICES.DLL
>> WER.DLL
>> WERUI.DLL
>> WINBRAND.DLL
>> WINDOWSCODECS.DLL
>> WINHTTP.DLL
>> WININET.DLL
>> WINMM.DLL
>> WINNSI.DLL
>> WINSCARD.DLL
>> WINSPOOL.DRV
>> WINSTA.DLL
>> WINTRUST.DLL
>> WKSCLI.DLL
>> WLANAPI.DLL
>> WLANUTIL.DLL
>> WLDAP32.DLL
>> WS2_32.DLL
>> WTSAPI32.DLL
>> XMLLITE.DLL
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 12/16/2013 08:02 PM, Pete Brunet wrote:
>>>> I'm writing a regression test and it is failing trying to load
>>>> bin\JAWTAccessBridge.DLL.  It was successful in loading
>>>> bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs are
>>>> in jre\bin.  Here's the failure:
>>>>
>>>> java.lang.UnsatisfiedLinkError:
>>>> C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
>>>>
>>>>
>>>> Can't find dependent libraries
>>>>    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>>    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
>>>>    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
>>>>    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>>>    at java.lang.System.loadLibrary(System.java:1119)
>>>>    at JABDLL$4.run(JABDLL.java:116)
>>>>    at java.security.AccessController.doPrivileged(Native Method)
>>>>    at JABDLL.foundLegacyDLLs(JABDLL.java:113)
>>>>    at JABDLL.main(JABDLL.java:67)
>>>>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>    at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>
>>>>
>>>>    at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>
>>>>
>>>>    at java.lang.reflect.Method.invoke(Method.java:483)
>>>>    at
>>>> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>>>>
>>>>    at java.lang.Thread.run(Thread.java:744)
>>>>
>>>> Here's the pertinent code:
>>>>
>>>> private static boolean foundLegacyDLLs() {
>>>>               java.security.AccessController.doPrivileged(
>>>>                   new java.security.PrivilegedAction() {
>>>>                       public Object run() {
>>>>                           System.loadLibrary("JavaAccessBridge");
>>>>                           return null;
>>>>                       }
>>>>                   }, null, new
>>>> RuntimePermission("loadLibrary.JavaAccessBridge")
>>>>               );
>>>>               java.security.AccessController.doPrivileged(
>>>>                   new java.security.PrivilegedAction() {
>>>>                       public Object run() {
>>>>                           System.loadLibrary("JAWTAccessBridge");  //
>>>> line
>>>> 116, fails here
>>>>                           return null;
>>>>                       }
>>>>                   }, null, new
>>>> RuntimePermission("loadLibrary.JAWTAccessBridge")
>>>>               );
>>>>               return true;
>>>>       }
>>>>
>>>> Here's the jtreg run:
>>>>
>>>> $ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
>>>> -testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
>>>>
>>>>
>>>> -verbose:summary closed/com/sun/java/accessibility/JABDLL.java
>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
>>>> needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
>>>> this can be ignored
>>>> FAILED: closed/com/sun/java/accessibility/JABDLL.java
>>>> Test results: failed: 1
>>>> Report written to
>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
>>>> Results written to C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
>>>> Error: Some tests failed or other problems occurred.
>>>>
>>>> Here's the prolog to the test case:
>>>>
>>>> /*
>>>>     * @test
>>>>     * @summary ...
>>>>     * @run main JABDLL
>>>>     */
>>>>
>>>> The built image runs fine in normal use, i.e. I can run SwingSet2 with
>>>> the same image so I assume it's something I'm not doing right with
>>>> respect to jtreg.
>>>>
>>>> The dependency walker reports jvm.dll which is in bin\server.  I tried
>>>> moving that to bin but that didn't help.   Also some Win DLLs were
>>>> reported most of which start with API-MS-WIN- but I assume those are
>>>> false negatives.  The sdk image I am testing is 32 bit and the DLL is
>>>> also 32 bit.  Hopefully it's just something I don't yet understand
>>>> about
>>>> jprt, like maybe a missing @ tag in the prolog.
>>>>
>>>> Any ideas on how to debug this?
>>>>
>>>> Pete
>>>>
>>>>
>>

From Sergey.Bylokhov at oracle.com  Tue Dec 17 06:31:30 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 17 Dec 2013 18:31:30 +0400
Subject: <AWT Dev> [9] Review request for 8029979: Allow multiple calls
	to DropTargetDropEvent.acceptDrop()
In-Reply-To: <52B04AA0.10600@oracle.com>
References: <52AB3BA0.4070805@oracle.com> <52AB94E8.50405@oracle.com>
	<52AF0BF9.9080906@oracle.com> <52B03064.4050707@oracle.com>
	<52B04AA0.10600@oracle.com>
Message-ID: <52B06042.3000304@oracle.com>

Hi, Anthony.
The fix looks good.

On 17.12.2013 16:59, Anthony Petrov wrote:
> Hi Sergey,
>
> Good point. You're right, it's just impossible to happen. So here's an 
> updated webrev:
>
> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.2/
>
> -- 
> best regards,
> Anthony
>
> On 12/17/2013 03:07 PM, Sergey Bylokhov wrote:
>> Hi, Anthony.
>> On 12/16/13 6:19 PM, Anthony Petrov wrote:
>>>> Is it necessary to check !dropComplete?
>>>
>>> Well, I wanted to add this case to my regression test, but it appears
>>> that the DropTargetContextPeer gets destroyed after user's code calls
>>> dropComplete(), and so this check is never performed actually.
>>> However, I'd like to keep it in place because it just doesn't make any
>>> sense to call acceptDrop() after the drop is complete. It looks safe
>>> to me.
>> It will be strange to have dropStatus= ACCEPT and drop status complete
>> at the same moment, No?
>>>
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>>>
>>>> On 13.12.2013 20:53, Anthony Petrov wrote:
>>>>> Hi Petr, Sergey,
>>>>>
>>>>> Please review a fix for
>>>>> https://bugs.openjdk.java.net/browse/JDK-8029979 at:
>>>>>
>>>>> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.0/
>>>>>
>>>>> I enable calling SunDropTargetContextPeer.acceptDrop() as many times
>>>>> as needed, for as long as the DnD operation isn't complete yet.
>>>>> Running open and closed DnD regression tests revealed no new 
>>>>> failures.
>>>>>
>>>>> Note that later we will need to back-port this fix to 8u20.
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>
>>>>
>>
>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Tue Dec 17 06:40:07 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 17 Dec 2013 18:40:07 +0400
Subject: <AWT Dev> [9] Review request for 8029979: Allow multiple calls
	to DropTargetDropEvent.acceptDrop()
In-Reply-To: <52B06042.3000304@oracle.com>
References: <52AB3BA0.4070805@oracle.com> <52AB94E8.50405@oracle.com>
	<52AF0BF9.9080906@oracle.com> <52B03064.4050707@oracle.com>
	<52B04AA0.10600@oracle.com> <52B06042.3000304@oracle.com>
Message-ID: <5EA35A9E-BE10-4985-A132-E64202683458@oracle.com>

And still looks good to me.

With best regards. Petr.

On 17.12.2013, at 18:31, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Anthony.
> The fix looks good.
> 
> On 17.12.2013 16:59, Anthony Petrov wrote:
>> Hi Sergey,
>> 
>> Good point. You're right, it's just impossible to happen. So here's an updated webrev:
>> 
>> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.2/
>> 
>> -- 
>> best regards,
>> Anthony
>> 
>> On 12/17/2013 03:07 PM, Sergey Bylokhov wrote:
>>> Hi, Anthony.
>>> On 12/16/13 6:19 PM, Anthony Petrov wrote:
>>>>> Is it necessary to check !dropComplete?
>>>> 
>>>> Well, I wanted to add this case to my regression test, but it appears
>>>> that the DropTargetContextPeer gets destroyed after user's code calls
>>>> dropComplete(), and so this check is never performed actually.
>>>> However, I'd like to keep it in place because it just doesn't make any
>>>> sense to call acceptDrop() after the drop is complete. It looks safe
>>>> to me.
>>> It will be strange to have dropStatus= ACCEPT and drop status complete
>>> at the same moment, No?
>>>> 
>>>> 
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>> 
>>>>> 
>>>>> On 13.12.2013 20:53, Anthony Petrov wrote:
>>>>>> Hi Petr, Sergey,
>>>>>> 
>>>>>> Please review a fix for
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8029979 at:
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.0/
>>>>>> 
>>>>>> I enable calling SunDropTargetContextPeer.acceptDrop() as many times
>>>>>> as needed, for as long as the DnD operation isn't complete yet.
>>>>>> Running open and closed DnD regression tests revealed no new failures.
>>>>>> 
>>>>>> Note that later we will need to back-port this fix to 8u20.
>>>>>> 
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>> 
>>>>> 
>>> 
>>> 
> 
> 
> -- 
> Best regards, Sergey.
> 


From anton.tarasov at oracle.com  Tue Dec 17 10:21:56 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Tue, 17 Dec 2013 22:21:56 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52AA3E92.7040302@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com>
Message-ID: <52B09644.6050201@oracle.com>

Hi all,

Please look at the new version:

http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2

It contains the following changes:

- All the scale related stuff is moved to the new class: 
OffScreenHiDPIImage.java

- JViewport and RepaintManager no longer cache buffers.

- JLightweightFrame has new method: createHiDPIImage(w, h).

- JViewport, RepaintManager and AbstractRegionPainter goes the new path 
to create a HiDPI buffered image.

- A new internal property is added: "swing.jlf.hidpiImageEnabled". False 
by default. It makes JLF.createImage(w, h) forward the call to 
JLF.createHiDPIImage(w, h). This can be used by a third party code in 
case it creates a buffered image via Component.createImage(w, h) and 
uses the image so that it can benefit from being a HiDPI image on a 
Retina display.

For instance, SwingSet2 has an animating Bezier curve demo. Switching 
the property on makes the curve auto scale smoothly. Please, look at the 
screenshots:

-- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png
-- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png

- SunGraphics2D now draws a HiDPI buffered image the same way it draws a 
VolatileImage.

- I've removed the copyArea() method from the BufImgSurfaceData, and 
modified the original version. The only question I have is: do I need to 
check for "instanceof OffScreenHiDPIImage.SurfaceData" in case when 
"transformState == TRANSFORM_TRANSLATESCALE"? If this method is invoked 
with some other SD, and the transform is SCALE, will it do the job with 
the coordinates conversion done?

- I've left the new methods in FramePeer default... May yet we implement 
them in other peers when we really need it?

- CPlatformLWWindow.getGraphicsDevice() checks for an intersection + 
scale. This heuristic actually may fail when a Window is moved b/w three 
or four displays so that it intersects them all at some time. JFX will 
set a new scale factor in between and AWT may pick up a wrong device. I 
don't know any simple solution for that. For two monitors this will work.

Thanks,
Anton.

From peter.brunet at oracle.com  Tue Dec 17 10:42:45 2013
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 17 Dec 2013 12:42:45 -0600
Subject: <AWT Dev> Regression test failure loading a DLL
In-Reply-To: <52B051CD.7070306@oracle.com>
References: <52AF2405.5050107@oracle.com> <52AF5556.3020004@oracle.com>
	<52AF661B.4060602@oracle.com> <52B051CD.7070306@oracle.com>
Message-ID: <52B09B25.30409@oracle.com>

Hi Anthony, Thanks again for the assistance! 

On 12/17/13 7:29 AM, Anthony Petrov wrote:
>> Immediate load in JAWT*, delay load in Java*
>
> Why is that? Can you try re-linking the JAWTAccessBridge.DLL so that
> it uses delayed libs loading (which is always a good thing) and see if
> this changes anything?
Maybe it's a Dependency Walker anomaly?  I got that info from the fact
that Dependency Walker shows an hour glass next to the red icon for
ole32.dll for Java*.dll but not for ole32.dll for JAWT*.dll.  (Also when
I ran it today oleaut32.dll was delay load in both.)  I looked through
the ole32.dll entries in the trees for both DLLs and didn't find any
differences.

When I load JAWT*.dll Dependency Walker reports an error (and some
warnings).  If I add bin\server to its search list that error goes away
(and the warnings remain).

I found the build statements in jdk8\jdk\make\lib\PlatformLibraries.gmk
and Java* vs JAWT* are almost the same.  Here is are the statments in
the gmk file for JAWT* and Java* with the two significant difference noted.

$(call SetupNativeCompilation,BUILD_JAWTACCESSBRIDGE$1, \
          LIBRARY = JAWTAccessBridge$1, \
          OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
          SRC := $(ACCESSBRIDGE_SRCDIR), \
          INCLUDE_FILES := JAWTAccessBridge.cpp, \ <-- different list
for Java*
          LANG := C++, \
          OPTIMIZATION := LOW, \
          CFLAGS := $(CFLAGS_JDKLIB) \
              -DACCESSBRIDGE_ARCH_$3, \
          LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib gdi32.lib \
              winspool.lib jawt.lib comdlg32.lib advapi32.lib
shell32.lib \  <-- jawt.lib added
              ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
              -subsystem:windows -machine:$2 \
              -def:$(ACCESSBRIDGE_SRCDIR)/JAWTAccessBridge.DEF, \
          VERSIONINFO_RESOURCE :=
$(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
          RC_FLAGS := $(RC_FLAGS), \
          OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjawtaccessbridge$1, \
          DEBUG_SYMBOLS := true)

 $(call SetupNativeCompilation,BUILD_JAVAACCESSBRIDGE$1, \
          LIBRARY = JavaAccessBridge$1, \
          OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
          SRC := $(ACCESSBRIDGE_SRCDIR), \
          INCLUDE_FILES := AccessBridgeATInstance.cpp
AccessBridgeDebug.cpp \
              AccessBridgeJavaEntryPoints.cpp \
              AccessBridgeMessages.cpp JavaAccessBridge.cpp, \
          LANG := C++, \
          OPTIMIZATION := LOW, \
          CFLAGS := $(CFLAGS_JDKLIB) \
              -DACCESSBRIDGE_ARCH_$3, \
          LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib gdi32.lib \
              winspool.lib comdlg32.lib advapi32.lib shell32.lib \
              ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
              -subsystem:windows -machine:$2 \
              -def:$(ACCESSBRIDGE_SRCDIR)/JavaAccessBridge.DEF, \
          VERSIONINFO_RESOURCE :=
$(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
          RC_FLAGS := $(RC_FLAGS), \
          OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjavaaccessbridge$1, \
          DEBUG_SYMBOLS := true)

I wonder if the LDFLAGS lists are right.  Dependency Walker shows the
first level dependencies as follows:
- JAWT*.dll: jawt.dll, msvcr100.dll, kernel32.dll
- Java*.dll: msvcr100.dll, kernel32.dll, user32.dll
but the LDFLAGS lists are much longer and also both are missing msvcr100.lib

I ran the make in debug mode to get more output and the linker flags are
the same, except for the former including jawt.lib

For JAWT*:
LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
-libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
kernel32.lib user32.lib gdi32.lib winspool.lib jawt.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
odbccp32.lib -subsystem:windows -machine:I386
-def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JAWTAccessBridge.DEF

For Java*:
LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
-libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib
shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
-subsystem:windows -machine:I386
-def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JavaAccessBridge.DEF

Note that some builds have a LDFLAGS_SUFFIX_windows with -DELAYLOAD, but
these bridge builds don't.  I'll try adding this after lunch.

Regarding the source code JAWTAccessBridge.cpp doesn't load any DLLs. 
JavaAccessBridge.cpp has a loadlibrary of jawt.dll (and none of the
other included source files load DLLs).

In the middle of all these details I don't want to loose track of the
fact that the problem only occurs when using jtreg.  In normal use there
has never been a problem.
>
> Also,
>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>
> JDK doesn't support WinRT currently. The JAWT* (or any binary in JDK)
> just shouldn't be linked against these libraries (and probably other
> API-MS-*, too). Where do the dependencies come from? What does your
> Makefile do to link the JAWT* lib?
The JAWT* questions is answered above.

This is the tree I see for the WinRT DLLs you mentioned:
javaaccessbridge.dll
  user32.dll
    advapi32.dll
      wintrust.dll
        crypt32.dll
          userenv.dll
            shell32.dll
              wininet.dll
                iertutil.dll
                  API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL and
                  API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL

ditto to
  shell32.dll
    shdocvw.dll
      ieframe.dll
        mshtml.dll
          API-MS-WIN-CORE-WINRT-L1-1-0.DLL and
          API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>
> -- 
> best regards,
> Anthony
>
> On 12/17/2013 12:44 AM, Pete Brunet wrote:
>> Hi Anthony, Thanks for helping...
>>
>> On 12/16/13 1:32 PM, Anthony Petrov wrote:
>>> Hi Pete,
>>>
>>> I see you've already tried the Dependency Walker.
>>>
>>> 1. Could you please clarify the following: if you compile two lists of
>>> dependencies, one for JavaAccessBridge.dll and another for
>>> JAWTAccessBridge.DLL, and compare them, are there any differences?
>> Differences:
>>
>> JAWT* has these extras
>> jvm.dll - error opening file
>> awt.dll - no problem with this and the following
>> java.dll
>> jawt.dll
>> verify.dll
>>
>> Immediate load in JAWT*, delay load in Java*
>> ole32 - colored red, i.e. missing export function required by parent
>> module
>> oleaut32.dll - no problem
>>>
>>> 2. If you change the order of loading the libraries, will it fail
>>> right away w/o even loading the JavaAccessBridge.dll ?
>> yes
>>>
>>> 3. If the above doesn't help, please post the full list of
>>> dependencies for JAWTAccessBridge.DLL as reported by the Dependency
>>> Walker.
>> Error opening file:
>> JVM.DLL
>> API-MS-WIN-CORE-COM-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>> API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
>> DCOMP.DLL
>> GPSVC.DLL
>> IESHIMS.DLL
>> Red (missing export function required by parent module):
>> API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
>> OLE32.DLL
>> Red, delay load:
>> DWMAPI.DLL
>> IEFRAME.DLL
>> IMM32.DLL
>> MFPLAT.DLL
>> NDFAPI.DLL
>> USERENV.DLL
>> UXTHEME.DLL
>> No problems:
>> ADVAPI32.DLL
>> API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
>> API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
>> API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
>> API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
>> API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
>> API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
>> API-MS-WIN-CORE-FILE-L1-1-0.DLL
>> API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
>> API-MS-WIN-CORE-HEAP-L1-1-0.DLL
>> API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
>> API-MS-WIN-CORE-IO-L1-1-0.DLL
>> API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
>> API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
>> API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
>> API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
>> API-MS-WIN-CORE-MISC-L1-1-0.DLL
>> API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
>> API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
>> API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
>> API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
>> API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
>> API-MS-WIN-CORE-STRING-L1-1-0.DLL
>> API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
>> API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
>> API-MS-WIN-CORE-UTIL-L1-1-0.DLL
>> API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
>> API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
>> API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
>> API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
>> API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
>> API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
>> AWT.DLL
>> CRYPTBASE.DLL
>> GDI32.DLL
>> JAVA.DLL
>> JAWT.DLL
>> JAWTACCESSBRIDGE.DLL
>> KERNEL32.DLL
>> KERNELBASE.DLL
>> LPK.DLL
>> MSVCR100.DLL
>> MSVCRT.DLL
>> NTDLL.DLL
>> OLEAUT32.DLL
>> RPCRT4.DLL
>> SSPICLI.DLL
>> USER32.DLL
>> USP10.DLL
>> VERIFY.DLL
>> ACLUI.DLL
>> ACTIVEDS.DLL
>> ADSLDPC.DLL
>> ADVPACK.DLL
>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
>> API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
>> APPHELP.DLL
>> ATL.DLL
>> AUTHZ.DLL
>> AVRT.DLL
>> BCRYPT.DLL
>> BROWCLI.DLL
>> CABINET.DLL
>> CERTCLI.DLL
>> CERTENROLL.DLL
>> CFGMGR32.DLL
>> CLBCATQ.DLL
>> COMCTL32.DLL
>> COMCTL32.DLL
>> COMDLG32.DLL
>> CREDUI.DLL
>> CRYPT32.DLL
>> CRYPTSP.DLL
>> CRYPTUI.DLL
>> CSCAPI.DLL
>> D2D1.DLL
>> D3D11.DLL
>> DAVHLPR.DLL
>> DBGHELP.DLL
>> DEVMGR.DLL
>> DEVOBJ.DLL
>> DEVRTL.DLL
>> DFSCLI.DLL
>> DHCPCSVC.DLL
>> DHCPCSVC6.DLL
>> DNSAPI.DLL
>> DRVSTORE.DLL
>> DSROLE.DLL
>> DUI70.DLL
>> DUSER.DLL
>> DWRITE.DLL
>> DXGI.DLL
>> EAPPCFG.DLL
>> EAPPPRXY.DLL
>> EFSADU.DLL
>> EFSUTIL.DLL
>> ELSCORE.DLL
>> ESENT.DLL
>> FMS.DLL
>> GDIPLUS.DLL
>> GPAPI.DLL
>> HLINK.DLL
>> IEADVPACK.DLL
>> IERTUTIL.DLL
>> IEUI.DLL
>> IMAGEHLP.DLL
>> IMGUTIL.DLL
>> INETCOMM.DLL
>> IPHLPAPI.DLL
>> LINKINFO.DLL
>> LOGONCLI.DLL
>> MFC42U.DLL
>> MLANG.DLL
>> MMDEVAPI.DLL
>> MPR.DLL
>> MPRAPI.DLL
>> MPRMSG.DLL
>> MSASN1.DLL
>> MSCTF.DLL
>> MSFEEDS.DLL
>> MSHTML.DLL
>> MSI.DLL
>> MSILTCFG.DLL
>> MSIMG32.DLL
>> MSLS31.DLL
>> MSOERT2.DLL
>> MSRATING.DLL
>> MSSIGN32.DLL
>> NCRYPT.DLL
>> NETAPI32.DLL
>> NETBIOS.DLL
>> NETJOIN.DLL
>> NETPLWIZ.DLL
>> NETUTILS.DLL
>> NEWDEV.DLL
>> NORMALIZ.DLL
>> NSI.DLL
>> NTDSAPI.DLL
>> NTSHRUI.DLL
>> OCCACHE.DLL
>> ODBC32.DLL
>> OLEACC.DLL
>> OLEDLG.DLL
>> ONEX.DLL
>> PCWUM.DLL
>> POWRPROF.DLL
>> PRINTUI.DLL
>> PRNTVPT.DLL
>> PROFAPI.DLL
>> PROPSYS.DLL
>> PSAPI.DLL
>> PUIAPI.DLL
>> RASAPI32.DLL
>> RASDLG.DLL
>> RASMAN.DLL
>> REGAPI.DLL
>> RSTRTMGR.DLL
>> RTUTILS.DLL
>> SAMCLI.DLL
>> SAMLIB.DLL
>> SCECLI.DLL
>> SECUR32.DLL
>> SENSAPI.DLL
>> SETUPAPI.DLL
>> SHDOCVW.DLL
>> SHELL32.DLL
>> SHLWAPI.DLL
>> SLC.DLL
>> SPFILEQ.DLL
>> SPINF.DLL
>> SPPC.DLL
>> SRVCLI.DLL
>> TAPI32.DLL
>> UIAUTOMATIONCORE.DLL
>> URLMON.DLL
>> VAULTCLI.DLL
>> VERSION.DLL
>> VPNIKEAPI.DLL
>> W32TOPL.DLL
>> WDI.DLL
>> WEBIO.DLL
>> WEBSERVICES.DLL
>> WER.DLL
>> WERUI.DLL
>> WINBRAND.DLL
>> WINDOWSCODECS.DLL
>> WINHTTP.DLL
>> WININET.DLL
>> WINMM.DLL
>> WINNSI.DLL
>> WINSCARD.DLL
>> WINSPOOL.DRV
>> WINSTA.DLL
>> WINTRUST.DLL
>> WKSCLI.DLL
>> WLANAPI.DLL
>> WLANUTIL.DLL
>> WLDAP32.DLL
>> WS2_32.DLL
>> WTSAPI32.DLL
>> XMLLITE.DLL
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 12/16/2013 08:02 PM, Pete Brunet wrote:
>>>> I'm writing a regression test and it is failing trying to load
>>>> bin\JAWTAccessBridge.DLL.  It was successful in loading
>>>> bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs
>>>> are
>>>> in jre\bin.  Here's the failure:
>>>>
>>>> java.lang.UnsatisfiedLinkError:
>>>> C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
>>>>
>>>>
>>>> Can't find dependent libraries
>>>>    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>>    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
>>>>    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
>>>>    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>>>    at java.lang.System.loadLibrary(System.java:1119)
>>>>    at JABDLL$4.run(JABDLL.java:116)
>>>>    at java.security.AccessController.doPrivileged(Native Method)
>>>>    at JABDLL.foundLegacyDLLs(JABDLL.java:113)
>>>>    at JABDLL.main(JABDLL.java:67)
>>>>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>    at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>
>>>>
>>>>    at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>
>>>>
>>>>    at java.lang.reflect.Method.invoke(Method.java:483)
>>>>    at
>>>> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>>>>
>>>>    at java.lang.Thread.run(Thread.java:744)
>>>>
>>>> Here's the pertinent code:
>>>>
>>>> private static boolean foundLegacyDLLs() {
>>>>               java.security.AccessController.doPrivileged(
>>>>                   new java.security.PrivilegedAction() {
>>>>                       public Object run() {
>>>>                           System.loadLibrary("JavaAccessBridge");
>>>>                           return null;
>>>>                       }
>>>>                   }, null, new
>>>> RuntimePermission("loadLibrary.JavaAccessBridge")
>>>>               );
>>>>               java.security.AccessController.doPrivileged(
>>>>                   new java.security.PrivilegedAction() {
>>>>                       public Object run() {
>>>>                           System.loadLibrary("JAWTAccessBridge");  //
>>>> line
>>>> 116, fails here
>>>>                           return null;
>>>>                       }
>>>>                   }, null, new
>>>> RuntimePermission("loadLibrary.JAWTAccessBridge")
>>>>               );
>>>>               return true;
>>>>       }
>>>>
>>>> Here's the jtreg run:
>>>>
>>>> $ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
>>>> -testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
>>>>
>>>>
>>>> -verbose:summary closed/com/sun/java/accessibility/JABDLL.java
>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
>>>> needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
>>>> this can be ignored
>>>> FAILED: closed/com/sun/java/accessibility/JABDLL.java
>>>> Test results: failed: 1
>>>> Report written to
>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
>>>> Results written to C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
>>>> Error: Some tests failed or other problems occurred.
>>>>
>>>> Here's the prolog to the test case:
>>>>
>>>> /*
>>>>     * @test
>>>>     * @summary ...
>>>>     * @run main JABDLL
>>>>     */
>>>>
>>>> The built image runs fine in normal use, i.e. I can run SwingSet2 with
>>>> the same image so I assume it's something I'm not doing right with
>>>> respect to jtreg.
>>>>
>>>> The dependency walker reports jvm.dll which is in bin\server.  I tried
>>>> moving that to bin but that didn't help.   Also some Win DLLs were
>>>> reported most of which start with API-MS-WIN- but I assume those are
>>>> false negatives.  The sdk image I am testing is 32 bit and the DLL is
>>>> also 32 bit.  Hopefully it's just something I don't yet understand
>>>> about
>>>> jprt, like maybe a missing @ tag in the prolog.
>>>>
>>>> Any ideas on how to debug this?
>>>>
>>>> Pete
>>>>
>>>>
>>


From Sergey.Bylokhov at oracle.com  Tue Dec 17 11:38:44 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 17 Dec 2013 23:38:44 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52B09644.6050201@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
Message-ID: <52B0A844.6000302@oracle.com>

Hi, Anton.
Since OffScreenHiDPIImage looks similar to VolatileImage. Why we cannot 
use VolatileImage inside Swing everywhere?
What happens if the graphicsConfig for the particular offscreen image 
will be changed/remoed/disposed? I suppose Volatile should became 
invalid in this case.

CPlatformLWWindow :
Why  did you check scale when you try to find a necessary 
GraphicsDevice? Why not use the one correct device where the peer is 
located? Probably this code can be moved to the PlatformWindow interface?

FramePeer:
Do we realy need notifyScaleFactorChanged? Probably notification about 
replacing GC is better? In this case it should notify all listeners that 
GC was changed(as a result recreated all buffers). Volatile handle this 
automatically?

I suppose you disable volatile buffer in repaint manager. Why?

Note that we have a bug on Swing+retina+scroll, when we use volatiles as 
a buffer, I am not sure what we will get in case of BI.
https://bugs.openjdk.java.net/browse/JDK-8029253

On 17.12.2013 22:21, Anton V. Tarasov wrote:
> Hi all,
>
> Please look at the new version:
>
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2
>
> It contains the following changes:
>
> - All the scale related stuff is moved to the new class: 
> OffScreenHiDPIImage.java
>
> - JViewport and RepaintManager no longer cache buffers.
>
> - JLightweightFrame has new method: createHiDPIImage(w, h).
>
> - JViewport, RepaintManager and AbstractRegionPainter goes the new 
> path to create a HiDPI buffered image.
>
> - A new internal property is added: "swing.jlf.hidpiImageEnabled". 
> False by default. It makes JLF.createImage(w, h) forward the call to 
> JLF.createHiDPIImage(w, h). This can be used by a third party code in 
> case it creates a buffered image via Component.createImage(w, h) and 
> uses the image so that it can benefit from being a HiDPI image on a 
> Retina display.
>
> For instance, SwingSet2 has an animating Bezier curve demo. Switching 
> the property on makes the curve auto scale smoothly. Please, look at 
> the screenshots:
>
> -- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png
> -- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png
>
> - SunGraphics2D now draws a HiDPI buffered image the same way it draws 
> a VolatileImage.
>
> - I've removed the copyArea() method from the BufImgSurfaceData, and 
> modified the original version. The only question I have is: do I need 
> to check for "instanceof OffScreenHiDPIImage.SurfaceData" in case when 
> "transformState == TRANSFORM_TRANSLATESCALE"? If this method is 
> invoked with some other SD, and the transform is SCALE, will it do the 
> job with the coordinates conversion done?
>
> - I've left the new methods in FramePeer default... May yet we 
> implement them in other peers when we really need it?
>
> - CPlatformLWWindow.getGraphicsDevice() checks for an intersection + 
> scale. This heuristic actually may fail when a Window is moved b/w 
> three or four displays so that it intersects them all at some time. 
> JFX will set a new scale factor in between and AWT may pick up a wrong 
> device. I don't know any simple solution for that. For two monitors 
> this will work.
>
> Thanks,
> Anton.


-- 
Best regards, Sergey.


From james.graham at oracle.com  Tue Dec 17 17:03:03 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 17 Dec 2013 17:03:03 -0800
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52B09644.6050201@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
Message-ID: <52B0F447.2020207@oracle.com>

Hi Anton,

javax.swing.RepaintManager.getOffscreenBuffer is a public method that 
can now return one of the new HiDPI offscreen images which is a subclass 
of BufferedImage.  This was what I was worried about in terms of one of 
these internal double buffers leaking to developer code.  If they test 
the image using instanceof they will see that it is a BufferdImage and 
they may try to dig out the raster and get confused...

			...jim

On 12/17/13 10:21 AM, Anton V. Tarasov wrote:
> Hi all,
>
> Please look at the new version:
>
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2
>
> It contains the following changes:
>
> - All the scale related stuff is moved to the new class:
> OffScreenHiDPIImage.java
>
> - JViewport and RepaintManager no longer cache buffers.
>
> - JLightweightFrame has new method: createHiDPIImage(w, h).
>
> - JViewport, RepaintManager and AbstractRegionPainter goes the new path
> to create a HiDPI buffered image.
>
> - A new internal property is added: "swing.jlf.hidpiImageEnabled". False
> by default. It makes JLF.createImage(w, h) forward the call to
> JLF.createHiDPIImage(w, h). This can be used by a third party code in
> case it creates a buffered image via Component.createImage(w, h) and
> uses the image so that it can benefit from being a HiDPI image on a
> Retina display.
>
> For instance, SwingSet2 has an animating Bezier curve demo. Switching
> the property on makes the curve auto scale smoothly. Please, look at the
> screenshots:
>
> -- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png
> -- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png
>
> - SunGraphics2D now draws a HiDPI buffered image the same way it draws a
> VolatileImage.
>
> - I've removed the copyArea() method from the BufImgSurfaceData, and
> modified the original version. The only question I have is: do I need to
> check for "instanceof OffScreenHiDPIImage.SurfaceData" in case when
> "transformState == TRANSFORM_TRANSLATESCALE"? If this method is invoked
> with some other SD, and the transform is SCALE, will it do the job with
> the coordinates conversion done?
>
> - I've left the new methods in FramePeer default... May yet we implement
> them in other peers when we really need it?
>
> - CPlatformLWWindow.getGraphicsDevice() checks for an intersection +
> scale. This heuristic actually may fail when a Window is moved b/w three
> or four displays so that it intersects them all at some time. JFX will
> set a new scale factor in between and AWT may pick up a wrong device. I
> don't know any simple solution for that. For two monitors this will work.
>
> Thanks,
> Anton.

From peter.brunet at oracle.com  Tue Dec 17 21:06:32 2013
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 17 Dec 2013 23:06:32 -0600
Subject: <AWT Dev> Regression test failure loading a DLL
In-Reply-To: <52B051CD.7070306@oracle.com>
References: <52AF2405.5050107@oracle.com> <52AF5556.3020004@oracle.com>
	<52AF661B.4060602@oracle.com> <52B051CD.7070306@oracle.com>
Message-ID: <52B12D58.3030205@oracle.com>


On 12/17/13 7:29 AM, Anthony Petrov wrote:
>> Immediate load in JAWT*, delay load in Java*
>
> Why is that? Can you try re-linking the JAWTAccessBridge.DLL so that
> it uses delayed libs loading (which is always a good thing) and see if
> this changes anything?
I tried delayload on ole32.dll for JAWTAccessBridge-32.DLL but that
didn't change anything.
>
> Also,
>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>
> JDK doesn't support WinRT currently. The JAWT* (or any binary in JDK)
> just shouldn't be linked against these libraries (and probably other
> API-MS-*, too). Where do the dependencies come from? What does your
> Makefile do to link the JAWT* lib?
>
> -- 
> best regards,
> Anthony
>
> On 12/17/2013 12:44 AM, Pete Brunet wrote:
>> Hi Anthony, Thanks for helping...
>>
>> On 12/16/13 1:32 PM, Anthony Petrov wrote:
>>> Hi Pete,
>>>
>>> I see you've already tried the Dependency Walker.
>>>
>>> 1. Could you please clarify the following: if you compile two lists of
>>> dependencies, one for JavaAccessBridge.dll and another for
>>> JAWTAccessBridge.DLL, and compare them, are there any differences?
>> Differences:
>>
>> JAWT* has these extras
>> jvm.dll - error opening file
>> awt.dll - no problem with this and the following
>> java.dll
>> jawt.dll
>> verify.dll
>>
>> Immediate load in JAWT*, delay load in Java*
>> ole32 - colored red, i.e. missing export function required by parent
>> module
>> oleaut32.dll - no problem
>>>
>>> 2. If you change the order of loading the libraries, will it fail
>>> right away w/o even loading the JavaAccessBridge.dll ?
>> yes
>>>
>>> 3. If the above doesn't help, please post the full list of
>>> dependencies for JAWTAccessBridge.DLL as reported by the Dependency
>>> Walker.
>> Error opening file:
>> JVM.DLL
>> API-MS-WIN-CORE-COM-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>> API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
>> DCOMP.DLL
>> GPSVC.DLL
>> IESHIMS.DLL
>> Red (missing export function required by parent module):
>> API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
>> OLE32.DLL
>> Red, delay load:
>> DWMAPI.DLL
>> IEFRAME.DLL
>> IMM32.DLL
>> MFPLAT.DLL
>> NDFAPI.DLL
>> USERENV.DLL
>> UXTHEME.DLL
>> No problems:
>> ADVAPI32.DLL
>> API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
>> API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
>> API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
>> API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
>> API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
>> API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
>> API-MS-WIN-CORE-FILE-L1-1-0.DLL
>> API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
>> API-MS-WIN-CORE-HEAP-L1-1-0.DLL
>> API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
>> API-MS-WIN-CORE-IO-L1-1-0.DLL
>> API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
>> API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
>> API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
>> API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
>> API-MS-WIN-CORE-MISC-L1-1-0.DLL
>> API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
>> API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
>> API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
>> API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
>> API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
>> API-MS-WIN-CORE-STRING-L1-1-0.DLL
>> API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
>> API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
>> API-MS-WIN-CORE-UTIL-L1-1-0.DLL
>> API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
>> API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
>> API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
>> API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
>> API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
>> API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
>> AWT.DLL
>> CRYPTBASE.DLL
>> GDI32.DLL
>> JAVA.DLL
>> JAWT.DLL
>> JAWTACCESSBRIDGE.DLL
>> KERNEL32.DLL
>> KERNELBASE.DLL
>> LPK.DLL
>> MSVCR100.DLL
>> MSVCRT.DLL
>> NTDLL.DLL
>> OLEAUT32.DLL
>> RPCRT4.DLL
>> SSPICLI.DLL
>> USER32.DLL
>> USP10.DLL
>> VERIFY.DLL
>> ACLUI.DLL
>> ACTIVEDS.DLL
>> ADSLDPC.DLL
>> ADVPACK.DLL
>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
>> API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
>> API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
>> APPHELP.DLL
>> ATL.DLL
>> AUTHZ.DLL
>> AVRT.DLL
>> BCRYPT.DLL
>> BROWCLI.DLL
>> CABINET.DLL
>> CERTCLI.DLL
>> CERTENROLL.DLL
>> CFGMGR32.DLL
>> CLBCATQ.DLL
>> COMCTL32.DLL
>> COMCTL32.DLL
>> COMDLG32.DLL
>> CREDUI.DLL
>> CRYPT32.DLL
>> CRYPTSP.DLL
>> CRYPTUI.DLL
>> CSCAPI.DLL
>> D2D1.DLL
>> D3D11.DLL
>> DAVHLPR.DLL
>> DBGHELP.DLL
>> DEVMGR.DLL
>> DEVOBJ.DLL
>> DEVRTL.DLL
>> DFSCLI.DLL
>> DHCPCSVC.DLL
>> DHCPCSVC6.DLL
>> DNSAPI.DLL
>> DRVSTORE.DLL
>> DSROLE.DLL
>> DUI70.DLL
>> DUSER.DLL
>> DWRITE.DLL
>> DXGI.DLL
>> EAPPCFG.DLL
>> EAPPPRXY.DLL
>> EFSADU.DLL
>> EFSUTIL.DLL
>> ELSCORE.DLL
>> ESENT.DLL
>> FMS.DLL
>> GDIPLUS.DLL
>> GPAPI.DLL
>> HLINK.DLL
>> IEADVPACK.DLL
>> IERTUTIL.DLL
>> IEUI.DLL
>> IMAGEHLP.DLL
>> IMGUTIL.DLL
>> INETCOMM.DLL
>> IPHLPAPI.DLL
>> LINKINFO.DLL
>> LOGONCLI.DLL
>> MFC42U.DLL
>> MLANG.DLL
>> MMDEVAPI.DLL
>> MPR.DLL
>> MPRAPI.DLL
>> MPRMSG.DLL
>> MSASN1.DLL
>> MSCTF.DLL
>> MSFEEDS.DLL
>> MSHTML.DLL
>> MSI.DLL
>> MSILTCFG.DLL
>> MSIMG32.DLL
>> MSLS31.DLL
>> MSOERT2.DLL
>> MSRATING.DLL
>> MSSIGN32.DLL
>> NCRYPT.DLL
>> NETAPI32.DLL
>> NETBIOS.DLL
>> NETJOIN.DLL
>> NETPLWIZ.DLL
>> NETUTILS.DLL
>> NEWDEV.DLL
>> NORMALIZ.DLL
>> NSI.DLL
>> NTDSAPI.DLL
>> NTSHRUI.DLL
>> OCCACHE.DLL
>> ODBC32.DLL
>> OLEACC.DLL
>> OLEDLG.DLL
>> ONEX.DLL
>> PCWUM.DLL
>> POWRPROF.DLL
>> PRINTUI.DLL
>> PRNTVPT.DLL
>> PROFAPI.DLL
>> PROPSYS.DLL
>> PSAPI.DLL
>> PUIAPI.DLL
>> RASAPI32.DLL
>> RASDLG.DLL
>> RASMAN.DLL
>> REGAPI.DLL
>> RSTRTMGR.DLL
>> RTUTILS.DLL
>> SAMCLI.DLL
>> SAMLIB.DLL
>> SCECLI.DLL
>> SECUR32.DLL
>> SENSAPI.DLL
>> SETUPAPI.DLL
>> SHDOCVW.DLL
>> SHELL32.DLL
>> SHLWAPI.DLL
>> SLC.DLL
>> SPFILEQ.DLL
>> SPINF.DLL
>> SPPC.DLL
>> SRVCLI.DLL
>> TAPI32.DLL
>> UIAUTOMATIONCORE.DLL
>> URLMON.DLL
>> VAULTCLI.DLL
>> VERSION.DLL
>> VPNIKEAPI.DLL
>> W32TOPL.DLL
>> WDI.DLL
>> WEBIO.DLL
>> WEBSERVICES.DLL
>> WER.DLL
>> WERUI.DLL
>> WINBRAND.DLL
>> WINDOWSCODECS.DLL
>> WINHTTP.DLL
>> WININET.DLL
>> WINMM.DLL
>> WINNSI.DLL
>> WINSCARD.DLL
>> WINSPOOL.DRV
>> WINSTA.DLL
>> WINTRUST.DLL
>> WKSCLI.DLL
>> WLANAPI.DLL
>> WLANUTIL.DLL
>> WLDAP32.DLL
>> WS2_32.DLL
>> WTSAPI32.DLL
>> XMLLITE.DLL
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 12/16/2013 08:02 PM, Pete Brunet wrote:
>>>> I'm writing a regression test and it is failing trying to load
>>>> bin\JAWTAccessBridge.DLL.  It was successful in loading
>>>> bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs
>>>> are
>>>> in jre\bin.  Here's the failure:
>>>>
>>>> java.lang.UnsatisfiedLinkError:
>>>> C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
>>>>
>>>>
>>>> Can't find dependent libraries
>>>>    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>>    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
>>>>    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
>>>>    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>>>    at java.lang.System.loadLibrary(System.java:1119)
>>>>    at JABDLL$4.run(JABDLL.java:116)
>>>>    at java.security.AccessController.doPrivileged(Native Method)
>>>>    at JABDLL.foundLegacyDLLs(JABDLL.java:113)
>>>>    at JABDLL.main(JABDLL.java:67)
>>>>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>    at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>
>>>>
>>>>    at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>
>>>>
>>>>    at java.lang.reflect.Method.invoke(Method.java:483)
>>>>    at
>>>> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>>>>
>>>>    at java.lang.Thread.run(Thread.java:744)
>>>>
>>>> Here's the pertinent code:
>>>>
>>>> private static boolean foundLegacyDLLs() {
>>>>               java.security.AccessController.doPrivileged(
>>>>                   new java.security.PrivilegedAction() {
>>>>                       public Object run() {
>>>>                           System.loadLibrary("JavaAccessBridge");
>>>>                           return null;
>>>>                       }
>>>>                   }, null, new
>>>> RuntimePermission("loadLibrary.JavaAccessBridge")
>>>>               );
>>>>               java.security.AccessController.doPrivileged(
>>>>                   new java.security.PrivilegedAction() {
>>>>                       public Object run() {
>>>>                           System.loadLibrary("JAWTAccessBridge");  //
>>>> line
>>>> 116, fails here
>>>>                           return null;
>>>>                       }
>>>>                   }, null, new
>>>> RuntimePermission("loadLibrary.JAWTAccessBridge")
>>>>               );
>>>>               return true;
>>>>       }
>>>>
>>>> Here's the jtreg run:
>>>>
>>>> $ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
>>>> -testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
>>>>
>>>>
>>>> -verbose:summary closed/com/sun/java/accessibility/JABDLL.java
>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
>>>> needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
>>>> this can be ignored
>>>> FAILED: closed/com/sun/java/accessibility/JABDLL.java
>>>> Test results: failed: 1
>>>> Report written to
>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
>>>> Results written to C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
>>>> Error: Some tests failed or other problems occurred.
>>>>
>>>> Here's the prolog to the test case:
>>>>
>>>> /*
>>>>     * @test
>>>>     * @summary ...
>>>>     * @run main JABDLL
>>>>     */
>>>>
>>>> The built image runs fine in normal use, i.e. I can run SwingSet2 with
>>>> the same image so I assume it's something I'm not doing right with
>>>> respect to jtreg.
>>>>
>>>> The dependency walker reports jvm.dll which is in bin\server.  I tried
>>>> moving that to bin but that didn't help.   Also some Win DLLs were
>>>> reported most of which start with API-MS-WIN- but I assume those are
>>>> false negatives.  The sdk image I am testing is 32 bit and the DLL is
>>>> also 32 bit.  Hopefully it's just something I don't yet understand
>>>> about
>>>> jprt, like maybe a missing @ tag in the prolog.
>>>>
>>>> Any ideas on how to debug this?
>>>>
>>>> Pete
>>>>
>>>>
>>


From anton.tarasov at oracle.com  Wed Dec 18 00:55:27 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Wed, 18 Dec 2013 12:55:27 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52B0A844.6000302@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0A844.6000302@oracle.com>
Message-ID: <52B162FF.3020308@oracle.com>

Hi Sergey,

On 17.12.2013 23:38, Sergey Bylokhov wrote:
> Hi, Anton.
> Since OffScreenHiDPIImage looks similar to VolatileImage. Why we cannot use VolatileImage inside 
> Swing everywhere?

How Swing can use a VolatileImage when "swing.volatileImageBufferEnabled=false" is set? Could you 
please clarify your question?

Why there's the need to support that option is because of the SwingNode issue: 
https://javafx-jira.kenai.com/browse/RT-30035.

>
> What happens if the graphicsConfig for the particular offscreen image will be 
> changed/remoed/disposed? I suppose Volatile should became invalid in this case.

If you are asking about the OffScreenHiDPIImage.VolatileImage, then as I can see, we can rely on the 
VolatileSurfaceManager.validate(..) method. At the worst case, it will call the getBackupImage() 
which is overriden to return a new HiDPI buffer.

Also, I can't see any difference b/w how it behaved before, except for the getBackupImage call...

>
> CPlatformLWWindow :
> Why  did you check scale when you try to find a necessary GraphicsDevice?

When a Window is crossing the borders of two screens, FX switches to a new screen somewhere between 
and reports the scale factor change. At that moment the getGraphicsDevice is called and it finds the 
Window intersecting both the screens. However, as we know the scale factor has changed (otherwise, 
the method wouldn't be called) then we know the two devices have different scales, so we pick up the 
right device by additionally comparing the scale.

> Why not use the one correct device where the peer is located? Probably this code can be moved to 
> the PlatformWindow interface?

There's no a platform window for JLF, as I said. In the future, when (and if) we solve the problem 
with modality/z-order, JLF will be able to get the host window ID. But now it can't...

Also, why I think current approach is acceptable is because of the following:

- the configuration with three or four displays, when they are connected so that a Window can cross 
all of them at a time is a rare case
- it's still possible to move a Window to either of the screens only involving two of them when a 
border is crossed (as a workaround)
- even if a wrong device is picked up, it will work as JLF only needs its scale factor (so, the 
impact of the wrong behaviour is zero)

>
> FramePeer:
> Do we realy need notifyScaleFactorChanged? Probably notification about replacing GC is better? In 
> this case it should notify all listeners that GC was changed(as a result recreated all buffers). 
> Volatile handle this automatically?

But this still doesn't solve the problem I've described above... Until we have a platform Window ID. 
When (and if) we have it, the existing code can be easily adopted to it. The 
notifyScaleFactorChanged call will tell JLF that it should 1) just scale the buffer appropriately, 
or 2) ask for the the host window ID and match it to the device, thus pleasing the AWT machinary. 
The 2dn is just an implementation detail, which I think should not be exposed on the API level (via 
bringing there "screen" or "device" notions).

>
> I suppose you disable volatile buffer in repaint manager. Why?

If you mean the property: "swing.volatileImageBufferEnabled=false", then yes. The reason is the 
issue I've referred above: https://javafx-jira.kenai.com/browse/RT-30035.

>
> Note that we have a bug on Swing+retina+scroll, when we use volatiles as a buffer, I am not sure 
> what we will get in case of BI.
> https://bugs.openjdk.java.net/browse/JDK-8029253

Does switching off volatile makes any difference? I suppose SwingNode will experience the same 
slowness with "large text" scrolling. However, currently with volatile on, it performs badly even 
with a simple scroll (and not only with scroll, but with text typing as well). With buffered images, 
the perceived performance is quite close to a standalone Swing.

Thanks,
Anton.

>
> On 17.12.2013 22:21, Anton V. Tarasov wrote:
>> Hi all,
>>
>> Please look at the new version:
>>
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2
>>
>> It contains the following changes:
>>
>> - All the scale related stuff is moved to the new class: OffScreenHiDPIImage.java
>>
>> - JViewport and RepaintManager no longer cache buffers.
>>
>> - JLightweightFrame has new method: createHiDPIImage(w, h).
>>
>> - JViewport, RepaintManager and AbstractRegionPainter goes the new path to create a HiDPI 
>> buffered image.
>>
>> - A new internal property is added: "swing.jlf.hidpiImageEnabled". False by default. It makes 
>> JLF.createImage(w, h) forward the call to JLF.createHiDPIImage(w, h). This can be used by a third 
>> party code in case it creates a buffered image via Component.createImage(w, h) and uses the image 
>> so that it can benefit from being a HiDPI image on a Retina display.
>>
>> For instance, SwingSet2 has an animating Bezier curve demo. Switching the property on makes the 
>> curve auto scale smoothly. Please, look at the screenshots:
>>
>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png
>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png
>>
>> - SunGraphics2D now draws a HiDPI buffered image the same way it draws a VolatileImage.
>>
>> - I've removed the copyArea() method from the BufImgSurfaceData, and modified the original 
>> version. The only question I have is: do I need to check for "instanceof 
>> OffScreenHiDPIImage.SurfaceData" in case when "transformState == TRANSFORM_TRANSLATESCALE"? If 
>> this method is invoked with some other SD, and the transform is SCALE, will it do the job with 
>> the coordinates conversion done?
>>
>> - I've left the new methods in FramePeer default... May yet we implement them in other peers when 
>> we really need it?
>>
>> - CPlatformLWWindow.getGraphicsDevice() checks for an intersection + scale. This heuristic 
>> actually may fail when a Window is moved b/w three or four displays so that it intersects them 
>> all at some time. JFX will set a new scale factor in between and AWT may pick up a wrong device. 
>> I don't know any simple solution for that. For two monitors this will work.
>>
>> Thanks,
>> Anton.
>
>


From artem.ananiev at oracle.com  Wed Dec 18 01:24:04 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Wed, 18 Dec 2013 13:24:04 +0400
Subject: <AWT Dev> Regression test failure loading a DLL
In-Reply-To: <52B09B25.30409@oracle.com>
References: <52AF2405.5050107@oracle.com> <52AF5556.3020004@oracle.com>
	<52AF661B.4060602@oracle.com> <52B051CD.7070306@oracle.com>
	<52B09B25.30409@oracle.com>
Message-ID: <52B169B4.102@oracle.com>


On 12/17/2013 10:42 PM, Pete Brunet wrote:
> Hi Anthony, Thanks again for the assistance!
>
> On 12/17/13 7:29 AM, Anthony Petrov wrote:
>>> Immediate load in JAWT*, delay load in Java*
>>
>> Why is that? Can you try re-linking the JAWTAccessBridge.DLL so that
>> it uses delayed libs loading (which is always a good thing) and see if
>> this changes anything?
> Maybe it's a Dependency Walker anomaly?  I got that info from the fact
> that Dependency Walker shows an hour glass next to the red icon for
> ole32.dll for Java*.dll but not for ole32.dll for JAWT*.dll.  (Also when
> I ran it today oleaut32.dll was delay load in both.)  I looked through
> the ole32.dll entries in the trees for both DLLs and didn't find any
> differences.
>
> When I load JAWT*.dll Dependency Walker reports an error (and some
> warnings).  If I add bin\server to its search list that error goes away
> (and the warnings remain).
>
> I found the build statements in jdk8\jdk\make\lib\PlatformLibraries.gmk
> and Java* vs JAWT* are almost the same.  Here is are the statments in
> the gmk file for JAWT* and Java* with the two significant difference noted.
>
> $(call SetupNativeCompilation,BUILD_JAWTACCESSBRIDGE$1, \
>            LIBRARY = JAWTAccessBridge$1, \
>            OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>            SRC := $(ACCESSBRIDGE_SRCDIR), \
>            INCLUDE_FILES := JAWTAccessBridge.cpp, \ <-- different list
> for Java*
>            LANG := C++, \
>            OPTIMIZATION := LOW, \
>            CFLAGS := $(CFLAGS_JDKLIB) \
>                -DACCESSBRIDGE_ARCH_$3, \
>            LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib gdi32.lib \
>                winspool.lib jawt.lib comdlg32.lib advapi32.lib
> shell32.lib \  <-- jawt.lib added

Let me ask a stupid question: does pre-loading jawt.dll before 
JAWTAccessBridge.dll help?

>                ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>                -subsystem:windows -machine:$2 \
>                -def:$(ACCESSBRIDGE_SRCDIR)/JAWTAccessBridge.DEF, \
>            VERSIONINFO_RESOURCE :=
> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>            RC_FLAGS := $(RC_FLAGS), \
>            OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjawtaccessbridge$1, \
>            DEBUG_SYMBOLS := true)
>
>   $(call SetupNativeCompilation,BUILD_JAVAACCESSBRIDGE$1, \
>            LIBRARY = JavaAccessBridge$1, \
>            OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>            SRC := $(ACCESSBRIDGE_SRCDIR), \
>            INCLUDE_FILES := AccessBridgeATInstance.cpp
> AccessBridgeDebug.cpp \
>                AccessBridgeJavaEntryPoints.cpp \
>                AccessBridgeMessages.cpp JavaAccessBridge.cpp, \
>            LANG := C++, \
>            OPTIMIZATION := LOW, \
>            CFLAGS := $(CFLAGS_JDKLIB) \
>                -DACCESSBRIDGE_ARCH_$3, \
>            LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib gdi32.lib \
>                winspool.lib comdlg32.lib advapi32.lib shell32.lib \
>                ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>                -subsystem:windows -machine:$2 \
>                -def:$(ACCESSBRIDGE_SRCDIR)/JavaAccessBridge.DEF, \
>            VERSIONINFO_RESOURCE :=
> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>            RC_FLAGS := $(RC_FLAGS), \
>            OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjavaaccessbridge$1, \
>            DEBUG_SYMBOLS := true)
>
> I wonder if the LDFLAGS lists are right.  Dependency Walker shows the
> first level dependencies as follows:
> - JAWT*.dll: jawt.dll, msvcr100.dll, kernel32.dll
> - Java*.dll: msvcr100.dll, kernel32.dll, user32.dll
> but the LDFLAGS lists are much longer and also both are missing msvcr100.lib

msvcr100.dll is loaded by Java launcher from JRE/bin directory, so it's 
not a problem.

> I ran the make in debug mode to get more output and the linker flags are
> the same, except for the former including jawt.lib
>
> For JAWT*:
> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
> kernel32.lib user32.lib gdi32.lib winspool.lib jawt.lib comdlg32.lib
> advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
> odbccp32.lib -subsystem:windows -machine:I386
> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JAWTAccessBridge.DEF
>
> For Java*:
> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
> kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib
> shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
> -subsystem:windows -machine:I386
> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JavaAccessBridge.DEF
>
> Note that some builds have a LDFLAGS_SUFFIX_windows with -DELAYLOAD, but
> these bridge builds don't.  I'll try adding this after lunch.
>
> Regarding the source code JAWTAccessBridge.cpp doesn't load any DLLs.
> JavaAccessBridge.cpp has a loadlibrary of jawt.dll (and none of the
> other included source files load DLLs).
>
> In the middle of all these details I don't want to loose track of the
> fact that the problem only occurs when using jtreg.  In normal use there
> has never been a problem.
>>
>> Also,
>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL

These dependencies are also fine, at least I see the same dlls in the 
list of awt.dll dependencies, and it doesn't cause any troubles.

>> JDK doesn't support WinRT currently. The JAWT* (or any binary in JDK)
>> just shouldn't be linked against these libraries (and probably other
>> API-MS-*, too). Where do the dependencies come from? What does your
>> Makefile do to link the JAWT* lib?
> The JAWT* questions is answered above.
>
> This is the tree I see for the WinRT DLLs you mentioned:
> javaaccessbridge.dll
>    user32.dll
>      advapi32.dll
>        wintrust.dll
>          crypt32.dll
>            userenv.dll
>              shell32.dll
>                wininet.dll
>                  iertutil.dll
>                    API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL and
>                    API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>
> ditto to
>    shell32.dll
>      shdocvw.dll
>        ieframe.dll
>          mshtml.dll
>            API-MS-WIN-CORE-WINRT-L1-1-0.DLL and
>            API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL

Thanks,

Artem

>> --
>> best regards,
>> Anthony
>>
>> On 12/17/2013 12:44 AM, Pete Brunet wrote:
>>> Hi Anthony, Thanks for helping...
>>>
>>> On 12/16/13 1:32 PM, Anthony Petrov wrote:
>>>> Hi Pete,
>>>>
>>>> I see you've already tried the Dependency Walker.
>>>>
>>>> 1. Could you please clarify the following: if you compile two lists of
>>>> dependencies, one for JavaAccessBridge.dll and another for
>>>> JAWTAccessBridge.DLL, and compare them, are there any differences?
>>> Differences:
>>>
>>> JAWT* has these extras
>>> jvm.dll - error opening file
>>> awt.dll - no problem with this and the following
>>> java.dll
>>> jawt.dll
>>> verify.dll
>>>
>>> Immediate load in JAWT*, delay load in Java*
>>> ole32 - colored red, i.e. missing export function required by parent
>>> module
>>> oleaut32.dll - no problem
>>>>
>>>> 2. If you change the order of loading the libraries, will it fail
>>>> right away w/o even loading the JavaAccessBridge.dll ?
>>> yes
>>>>
>>>> 3. If the above doesn't help, please post the full list of
>>>> dependencies for JAWTAccessBridge.DLL as reported by the Dependency
>>>> Walker.
>>> Error opening file:
>>> JVM.DLL
>>> API-MS-WIN-CORE-COM-L1-1-0.DLL
>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>> API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
>>> DCOMP.DLL
>>> GPSVC.DLL
>>> IESHIMS.DLL
>>> Red (missing export function required by parent module):
>>> API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
>>> OLE32.DLL
>>> Red, delay load:
>>> DWMAPI.DLL
>>> IEFRAME.DLL
>>> IMM32.DLL
>>> MFPLAT.DLL
>>> NDFAPI.DLL
>>> USERENV.DLL
>>> UXTHEME.DLL
>>> No problems:
>>> ADVAPI32.DLL
>>> API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
>>> API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
>>> API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
>>> API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
>>> API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
>>> API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
>>> API-MS-WIN-CORE-FILE-L1-1-0.DLL
>>> API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
>>> API-MS-WIN-CORE-HEAP-L1-1-0.DLL
>>> API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
>>> API-MS-WIN-CORE-IO-L1-1-0.DLL
>>> API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
>>> API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
>>> API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
>>> API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
>>> API-MS-WIN-CORE-MISC-L1-1-0.DLL
>>> API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
>>> API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
>>> API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
>>> API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
>>> API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
>>> API-MS-WIN-CORE-STRING-L1-1-0.DLL
>>> API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
>>> API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
>>> API-MS-WIN-CORE-UTIL-L1-1-0.DLL
>>> API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
>>> API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
>>> API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
>>> API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
>>> API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
>>> API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
>>> AWT.DLL
>>> CRYPTBASE.DLL
>>> GDI32.DLL
>>> JAVA.DLL
>>> JAWT.DLL
>>> JAWTACCESSBRIDGE.DLL
>>> KERNEL32.DLL
>>> KERNELBASE.DLL
>>> LPK.DLL
>>> MSVCR100.DLL
>>> MSVCRT.DLL
>>> NTDLL.DLL
>>> OLEAUT32.DLL
>>> RPCRT4.DLL
>>> SSPICLI.DLL
>>> USER32.DLL
>>> USP10.DLL
>>> VERIFY.DLL
>>> ACLUI.DLL
>>> ACTIVEDS.DLL
>>> ADSLDPC.DLL
>>> ADVPACK.DLL
>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
>>> API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
>>> API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
>>> API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
>>> API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
>>> API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
>>> API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
>>> APPHELP.DLL
>>> ATL.DLL
>>> AUTHZ.DLL
>>> AVRT.DLL
>>> BCRYPT.DLL
>>> BROWCLI.DLL
>>> CABINET.DLL
>>> CERTCLI.DLL
>>> CERTENROLL.DLL
>>> CFGMGR32.DLL
>>> CLBCATQ.DLL
>>> COMCTL32.DLL
>>> COMCTL32.DLL
>>> COMDLG32.DLL
>>> CREDUI.DLL
>>> CRYPT32.DLL
>>> CRYPTSP.DLL
>>> CRYPTUI.DLL
>>> CSCAPI.DLL
>>> D2D1.DLL
>>> D3D11.DLL
>>> DAVHLPR.DLL
>>> DBGHELP.DLL
>>> DEVMGR.DLL
>>> DEVOBJ.DLL
>>> DEVRTL.DLL
>>> DFSCLI.DLL
>>> DHCPCSVC.DLL
>>> DHCPCSVC6.DLL
>>> DNSAPI.DLL
>>> DRVSTORE.DLL
>>> DSROLE.DLL
>>> DUI70.DLL
>>> DUSER.DLL
>>> DWRITE.DLL
>>> DXGI.DLL
>>> EAPPCFG.DLL
>>> EAPPPRXY.DLL
>>> EFSADU.DLL
>>> EFSUTIL.DLL
>>> ELSCORE.DLL
>>> ESENT.DLL
>>> FMS.DLL
>>> GDIPLUS.DLL
>>> GPAPI.DLL
>>> HLINK.DLL
>>> IEADVPACK.DLL
>>> IERTUTIL.DLL
>>> IEUI.DLL
>>> IMAGEHLP.DLL
>>> IMGUTIL.DLL
>>> INETCOMM.DLL
>>> IPHLPAPI.DLL
>>> LINKINFO.DLL
>>> LOGONCLI.DLL
>>> MFC42U.DLL
>>> MLANG.DLL
>>> MMDEVAPI.DLL
>>> MPR.DLL
>>> MPRAPI.DLL
>>> MPRMSG.DLL
>>> MSASN1.DLL
>>> MSCTF.DLL
>>> MSFEEDS.DLL
>>> MSHTML.DLL
>>> MSI.DLL
>>> MSILTCFG.DLL
>>> MSIMG32.DLL
>>> MSLS31.DLL
>>> MSOERT2.DLL
>>> MSRATING.DLL
>>> MSSIGN32.DLL
>>> NCRYPT.DLL
>>> NETAPI32.DLL
>>> NETBIOS.DLL
>>> NETJOIN.DLL
>>> NETPLWIZ.DLL
>>> NETUTILS.DLL
>>> NEWDEV.DLL
>>> NORMALIZ.DLL
>>> NSI.DLL
>>> NTDSAPI.DLL
>>> NTSHRUI.DLL
>>> OCCACHE.DLL
>>> ODBC32.DLL
>>> OLEACC.DLL
>>> OLEDLG.DLL
>>> ONEX.DLL
>>> PCWUM.DLL
>>> POWRPROF.DLL
>>> PRINTUI.DLL
>>> PRNTVPT.DLL
>>> PROFAPI.DLL
>>> PROPSYS.DLL
>>> PSAPI.DLL
>>> PUIAPI.DLL
>>> RASAPI32.DLL
>>> RASDLG.DLL
>>> RASMAN.DLL
>>> REGAPI.DLL
>>> RSTRTMGR.DLL
>>> RTUTILS.DLL
>>> SAMCLI.DLL
>>> SAMLIB.DLL
>>> SCECLI.DLL
>>> SECUR32.DLL
>>> SENSAPI.DLL
>>> SETUPAPI.DLL
>>> SHDOCVW.DLL
>>> SHELL32.DLL
>>> SHLWAPI.DLL
>>> SLC.DLL
>>> SPFILEQ.DLL
>>> SPINF.DLL
>>> SPPC.DLL
>>> SRVCLI.DLL
>>> TAPI32.DLL
>>> UIAUTOMATIONCORE.DLL
>>> URLMON.DLL
>>> VAULTCLI.DLL
>>> VERSION.DLL
>>> VPNIKEAPI.DLL
>>> W32TOPL.DLL
>>> WDI.DLL
>>> WEBIO.DLL
>>> WEBSERVICES.DLL
>>> WER.DLL
>>> WERUI.DLL
>>> WINBRAND.DLL
>>> WINDOWSCODECS.DLL
>>> WINHTTP.DLL
>>> WININET.DLL
>>> WINMM.DLL
>>> WINNSI.DLL
>>> WINSCARD.DLL
>>> WINSPOOL.DRV
>>> WINSTA.DLL
>>> WINTRUST.DLL
>>> WKSCLI.DLL
>>> WLANAPI.DLL
>>> WLANUTIL.DLL
>>> WLDAP32.DLL
>>> WS2_32.DLL
>>> WTSAPI32.DLL
>>> XMLLITE.DLL
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 12/16/2013 08:02 PM, Pete Brunet wrote:
>>>>> I'm writing a regression test and it is failing trying to load
>>>>> bin\JAWTAccessBridge.DLL.  It was successful in loading
>>>>> bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs
>>>>> are
>>>>> in jre\bin.  Here's the failure:
>>>>>
>>>>> java.lang.UnsatisfiedLinkError:
>>>>> C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
>>>>>
>>>>>
>>>>> Can't find dependent libraries
>>>>>     at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>>>     at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
>>>>>     at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
>>>>>     at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>>>>     at java.lang.System.loadLibrary(System.java:1119)
>>>>>     at JABDLL$4.run(JABDLL.java:116)
>>>>>     at java.security.AccessController.doPrivileged(Native Method)
>>>>>     at JABDLL.foundLegacyDLLs(JABDLL.java:113)
>>>>>     at JABDLL.main(JABDLL.java:67)
>>>>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>     at
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>
>>>>>
>>>>>     at
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>
>>>>>
>>>>>     at java.lang.reflect.Method.invoke(Method.java:483)
>>>>>     at
>>>>> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>>>>>
>>>>>     at java.lang.Thread.run(Thread.java:744)
>>>>>
>>>>> Here's the pertinent code:
>>>>>
>>>>> private static boolean foundLegacyDLLs() {
>>>>>                java.security.AccessController.doPrivileged(
>>>>>                    new java.security.PrivilegedAction() {
>>>>>                        public Object run() {
>>>>>                            System.loadLibrary("JavaAccessBridge");
>>>>>                            return null;
>>>>>                        }
>>>>>                    }, null, new
>>>>> RuntimePermission("loadLibrary.JavaAccessBridge")
>>>>>                );
>>>>>                java.security.AccessController.doPrivileged(
>>>>>                    new java.security.PrivilegedAction() {
>>>>>                        public Object run() {
>>>>>                            System.loadLibrary("JAWTAccessBridge");  //
>>>>> line
>>>>> 116, fails here
>>>>>                            return null;
>>>>>                        }
>>>>>                    }, null, new
>>>>> RuntimePermission("loadLibrary.JAWTAccessBridge")
>>>>>                );
>>>>>                return true;
>>>>>        }
>>>>>
>>>>> Here's the jtreg run:
>>>>>
>>>>> $ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
>>>>> -testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
>>>>>
>>>>>
>>>>> -verbose:summary closed/com/sun/java/accessibility/JABDLL.java
>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
>>>>> needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
>>>>> this can be ignored
>>>>> FAILED: closed/com/sun/java/accessibility/JABDLL.java
>>>>> Test results: failed: 1
>>>>> Report written to
>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
>>>>> Results written to C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
>>>>> Error: Some tests failed or other problems occurred.
>>>>>
>>>>> Here's the prolog to the test case:
>>>>>
>>>>> /*
>>>>>      * @test
>>>>>      * @summary ...
>>>>>      * @run main JABDLL
>>>>>      */
>>>>>
>>>>> The built image runs fine in normal use, i.e. I can run SwingSet2 with
>>>>> the same image so I assume it's something I'm not doing right with
>>>>> respect to jtreg.
>>>>>
>>>>> The dependency walker reports jvm.dll which is in bin\server.  I tried
>>>>> moving that to bin but that didn't help.   Also some Win DLLs were
>>>>> reported most of which start with API-MS-WIN- but I assume those are
>>>>> false negatives.  The sdk image I am testing is 32 bit and the DLL is
>>>>> also 32 bit.  Hopefully it's just something I don't yet understand
>>>>> about
>>>>> jprt, like maybe a missing @ tag in the prolog.
>>>>>
>>>>> Any ideas on how to debug this?
>>>>>
>>>>> Pete
>>>>>
>>>>>
>>>
>

From anton.tarasov at oracle.com  Wed Dec 18 01:25:44 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Wed, 18 Dec 2013 13:25:44 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52B0F447.2020207@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com>
Message-ID: <52B16A18.4060301@oracle.com>

Hi Jim,

Thanks for noticing (sorry, but I simply forgot to check we don't export the buffer...) What can we 
do about that? I have the following thoughts:

1) We can warn developers to be ready for a HiDPI raster when they call that method under the 
following conditions: 1) the interop mode, 2) MacOSX 3) a Retina display.
2) In case the method is called, we can create a "shadow  buffer" and start to sync it with the main 
buffer. The main buffer will be scaled to the shadow buffer on every repaint cycle.
3) We can introduce an internal property which will switch on/off the 2nd scenario. For instance, a 
developer may ask for the buffer and don't bother about its hidpi raster.

Yes, I understand the solutions are far from perfect, but please take into account, the interop is a 
special mode where we (and developers) should be ready for compromises...

What do you think? Do you have any better solutions in mind?

Thanks,
Anton.


On 18.12.2013 5:03, Jim Graham wrote:
> Hi Anton,
>
> javax.swing.RepaintManager.getOffscreenBuffer is a public method that can now return one of the 
> new HiDPI offscreen images which is a subclass of BufferedImage.  This was what I was worried 
> about in terms of one of these internal double buffers leaking to developer code.  If they test 
> the image using instanceof they will see that it is a BufferdImage and they may try to dig out the 
> raster and get confused...
>
>             ...jim
>
> On 12/17/13 10:21 AM, Anton V. Tarasov wrote:
>> Hi all,
>>
>> Please look at the new version:
>>
>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2
>>
>> It contains the following changes:
>>
>> - All the scale related stuff is moved to the new class:
>> OffScreenHiDPIImage.java
>>
>> - JViewport and RepaintManager no longer cache buffers.
>>
>> - JLightweightFrame has new method: createHiDPIImage(w, h).
>>
>> - JViewport, RepaintManager and AbstractRegionPainter goes the new path
>> to create a HiDPI buffered image.
>>
>> - A new internal property is added: "swing.jlf.hidpiImageEnabled". False
>> by default. It makes JLF.createImage(w, h) forward the call to
>> JLF.createHiDPIImage(w, h). This can be used by a third party code in
>> case it creates a buffered image via Component.createImage(w, h) and
>> uses the image so that it can benefit from being a HiDPI image on a
>> Retina display.
>>
>> For instance, SwingSet2 has an animating Bezier curve demo. Switching
>> the property on makes the curve auto scale smoothly. Please, look at the
>> screenshots:
>>
>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png
>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png
>>
>> - SunGraphics2D now draws a HiDPI buffered image the same way it draws a
>> VolatileImage.
>>
>> - I've removed the copyArea() method from the BufImgSurfaceData, and
>> modified the original version. The only question I have is: do I need to
>> check for "instanceof OffScreenHiDPIImage.SurfaceData" in case when
>> "transformState == TRANSFORM_TRANSLATESCALE"? If this method is invoked
>> with some other SD, and the transform is SCALE, will it do the job with
>> the coordinates conversion done?
>>
>> - I've left the new methods in FramePeer default... May yet we implement
>> them in other peers when we really need it?
>>
>> - CPlatformLWWindow.getGraphicsDevice() checks for an intersection +
>> scale. This heuristic actually may fail when a Window is moved b/w three
>> or four displays so that it intersects them all at some time. JFX will
>> set a new scale factor in between and AWT may pick up a wrong device. I
>> don't know any simple solution for that. For two monitors this will work.
>>
>> Thanks,
>> Anton.


From anton.tarasov at oracle.com  Wed Dec 18 01:38:00 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Wed, 18 Dec 2013 13:38:00 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52B16A18.4060301@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com> <52B16A18.4060301@oracle.com>
Message-ID: <52B16CF8.10803@oracle.com>

On 18.12.2013 13:25, Anton V. Tarasov wrote:
> Hi Jim,
>
> Thanks for noticing (sorry, but I simply forgot to check we don't export the buffer...) What can 
> we do about that? I have the following thoughts:
>
> 1) We can warn developers to be ready for a HiDPI raster when they call that method under the 
> following conditions: 1) the interop mode, 2) MacOSX 3) a Retina display.
> 2) In case the method is called, we can create a "shadow  buffer" and start to sync it with the 
> main buffer. The main buffer will be scaled to the shadow buffer on every repaint cycle.

Just wanted to add, that SunVolatileImage.getSnapshot does the same (it scales the volatile image to 
a buffer), however it doesn't need to keep it synchronised...

Thanks,
Anton.


> 3) We can introduce an internal property which will switch on/off the 2nd scenario. For instance, 
> a developer may ask for the buffer and don't bother about its hidpi raster.
>
> Yes, I understand the solutions are far from perfect, but please take into account, the interop is 
> a special mode where we (and developers) should be ready for compromises...
>
> What do you think? Do you have any better solutions in mind?
>
> Thanks,
> Anton.
>
>
> On 18.12.2013 5:03, Jim Graham wrote:
>> Hi Anton,
>>
>> javax.swing.RepaintManager.getOffscreenBuffer is a public method that can now return one of the 
>> new HiDPI offscreen images which is a subclass of BufferedImage.  This was what I was worried 
>> about in terms of one of these internal double buffers leaking to developer code.  If they test 
>> the image using instanceof they will see that it is a BufferdImage and they may try to dig out 
>> the raster and get confused...
>>
>>             ...jim
>>
>> On 12/17/13 10:21 AM, Anton V. Tarasov wrote:
>>> Hi all,
>>>
>>> Please look at the new version:
>>>
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2
>>>
>>> It contains the following changes:
>>>
>>> - All the scale related stuff is moved to the new class:
>>> OffScreenHiDPIImage.java
>>>
>>> - JViewport and RepaintManager no longer cache buffers.
>>>
>>> - JLightweightFrame has new method: createHiDPIImage(w, h).
>>>
>>> - JViewport, RepaintManager and AbstractRegionPainter goes the new path
>>> to create a HiDPI buffered image.
>>>
>>> - A new internal property is added: "swing.jlf.hidpiImageEnabled". False
>>> by default. It makes JLF.createImage(w, h) forward the call to
>>> JLF.createHiDPIImage(w, h). This can be used by a third party code in
>>> case it creates a buffered image via Component.createImage(w, h) and
>>> uses the image so that it can benefit from being a HiDPI image on a
>>> Retina display.
>>>
>>> For instance, SwingSet2 has an animating Bezier curve demo. Switching
>>> the property on makes the curve auto scale smoothly. Please, look at the
>>> screenshots:
>>>
>>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png
>>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png
>>>
>>> - SunGraphics2D now draws a HiDPI buffered image the same way it draws a
>>> VolatileImage.
>>>
>>> - I've removed the copyArea() method from the BufImgSurfaceData, and
>>> modified the original version. The only question I have is: do I need to
>>> check for "instanceof OffScreenHiDPIImage.SurfaceData" in case when
>>> "transformState == TRANSFORM_TRANSLATESCALE"? If this method is invoked
>>> with some other SD, and the transform is SCALE, will it do the job with
>>> the coordinates conversion done?
>>>
>>> - I've left the new methods in FramePeer default... May yet we implement
>>> them in other peers when we really need it?
>>>
>>> - CPlatformLWWindow.getGraphicsDevice() checks for an intersection +
>>> scale. This heuristic actually may fail when a Window is moved b/w three
>>> or four displays so that it intersects them all at some time. JFX will
>>> set a new scale factor in between and AWT may pick up a wrong device. I
>>> don't know any simple solution for that. For two monitors this will work.
>>>
>>> Thanks,
>>> Anton.
>


From petr.pchelko at oracle.com  Wed Dec 18 01:54:01 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 18 Dec 2013 13:54:01 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7159566 The choice positioned in
	the top of applet when clicking the choice.
Message-ID: <642D9E27-4144-49A7-A70F-3CCFC4A02E06@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-7159566
The fix is available at: 
http://cr.openjdk.java.net/~pchelko/9/7159566/webrev/

The problem: when showing the choice popup we need to use a choice as an invoker to process grab correctly. That's why we have the piece of code I'm fixing. 
However, we also need to set a correct location of the popup. A 'heavy' getLocationOnScreen is used because the choice might have already been moved by the 
window manager by this point to fit the screen and it's the only public way to get the location of the popup menu.

The added test checks that there's no popup on the top of the window by clicking there. 

With best regards. Petr.

From sergey.bylokhov at oracle.com  Wed Dec 18 03:12:16 2013
From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com)
Date: Wed, 18 Dec 2013 11:12:16 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 8029263: user's default browser can not
	launch	after we click the button,
	and there is an IOException shown in the log text
	(java.io.IOException)
Message-ID: <20131218111328.BC8DB62D99@hg.openjdk.java.net>

Changeset: c8ec5c070592
Author:    azvegint
Date:      2013-12-18 11:09 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c8ec5c070592

8029263: user's default browser can not launch after we click the button, and there is an IOException shown in the log text (java.io.IOException)
Reviewed-by: anthony, serb

! src/solaris/classes/sun/awt/X11/XDesktopPeer.java
! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h
! src/solaris/native/sun/xawt/awt_Desktop.c
! test/java/awt/Desktop/OpenByUNCPathNameTest/OpenByUNCPathNameTest.java


From anthony.petrov at oracle.com  Wed Dec 18 05:36:35 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 18 Dec 2013 17:36:35 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7159566 The choice positioned
 in the top of applet when clicking the choice.
In-Reply-To: <642D9E27-4144-49A7-A70F-3CCFC4A02E06@oracle.com>
References: <642D9E27-4144-49A7-A70F-3CCFC4A02E06@oracle.com>
Message-ID: <52B1A4E3.2050903@oracle.com>

Hi Petr,

The fix looks good to me. I'm concerned with the test a bit:

>  69             for (int y = locOnScreen.y + frame.getInsets().top + 10; y < locOnScreen.y + 150; y += 5) {

I'd suggest to infer this magic constant 150 from the frame size rather 
than hard-code the value to make sure the robot never clicks outside of 
the test frame.

--
best regards,
Anthony

On 12/18/2013 01:54 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-7159566
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/7159566/webrev/
>
> The problem: when showing the choice popup we need to use a choice as an invoker to process grab correctly. That's why we have the piece of code I'm fixing.
> However, we also need to set a correct location of the popup. A 'heavy' getLocationOnScreen is used because the choice might have already been moved by the
> window manager by this point to fit the screen and it's the only public way to get the location of the popup menu.
>
> The added test checks that there's no popup on the top of the window by clicking there.
>
> With best regards. Petr.
>

From petr.pchelko at oracle.com  Wed Dec 18 06:01:18 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 18 Dec 2013 18:01:18 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029250 [macosx] There is no tray
	icon shown in the system tray area when case starts
Message-ID: <2AA389C5-8723-49CE-8054-BC778BD3CDC4@oracle.com>

Hello, AWT and 2D teams.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8029250
It also resolves the issue:
https://bugs.openjdk.java.net/browse/JDK-6740321
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8029250/webrev/

The problem:
In AWT we use a MediaTracker to wait for the tray icon loading. However, if the TrayIcon is an animated gif the following happen:
The MediaTracker installs an ImageObserver to an image and starts loading. After the first frame is loaded (and it's really all we need)
the media tracker correctly exits and removes it's ImageObserver. And as it's the only observer the checkConsumption is called in an 
ImageRepresentation. As the availinfo is just FRAMEBITS the successfully loaded frame was immediately disposed and AWT failed 
to draw a tray icon.

With best regards. Petr.

From Sergey.Bylokhov at oracle.com  Wed Dec 18 06:03:39 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 18 Dec 2013 18:03:39 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7159566 The choice positioned
 in the top of applet when clicking the choice.
In-Reply-To: <642D9E27-4144-49A7-A70F-3CCFC4A02E06@oracle.com>
References: <642D9E27-4144-49A7-A70F-3CCFC4A02E06@oracle.com>
Message-ID: <52B1AB3B.3060907@oracle.com>

Hi, Petr.
The fix looks good. I have 2 suggestions :
1 LWChoicePeer.this prefix is unnecessary here?
2 Can you add a small description about this code as a comment?
Thanks.
On 18.12.2013 13:54, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-7159566
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/7159566/webrev/
>
> The problem: when showing the choice popup we need to use a choice as an invoker to process grab correctly. That's why we have the piece of code I'm fixing.
> However, we also need to set a correct location of the popup. A 'heavy' getLocationOnScreen is used because the choice might have already been moved by the
> window manager by this point to fit the screen and it's the only public way to get the location of the popup menu.
>
> The added test checks that there's no popup on the top of the window by clicking there.
>
> With best regards. Petr.


-- 
Best regards, Sergey.


From anton.tarasov at oracle.com  Wed Dec 18 07:19:51 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Wed, 18 Dec 2013 19:19:51 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52B16A18.4060301@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com> <52B16A18.4060301@oracle.com>
Message-ID: <52B1BD17.1070905@oracle.com>

The 4th option, previously suggested by Sergey, is to switch off double 
buffering at all. I'm investigating it.

Thanks,
Anton.

On 12/18/13 1:25 PM, Anton V. Tarasov wrote:
> Hi Jim,
>
> Thanks for noticing (sorry, but I simply forgot to check we don't 
> export the buffer...) What can we do about that? I have the following 
> thoughts:
>
> 1) We can warn developers to be ready for a HiDPI raster when they 
> call that method under the following conditions: 1) the interop mode, 
> 2) MacOSX 3) a Retina display.
> 2) In case the method is called, we can create a "shadow  buffer" and 
> start to sync it with the main buffer. The main buffer will be scaled 
> to the shadow buffer on every repaint cycle.
> 3) We can introduce an internal property which will switch on/off the 
> 2nd scenario. For instance, a developer may ask for the buffer and 
> don't bother about its hidpi raster.
>
> Yes, I understand the solutions are far from perfect, but please take 
> into account, the interop is a special mode where we (and developers) 
> should be ready for compromises...
>
> What do you think? Do you have any better solutions in mind?
>
> Thanks,
> Anton.
>
>
> On 18.12.2013 5:03, Jim Graham wrote:
>> Hi Anton,
>>
>> javax.swing.RepaintManager.getOffscreenBuffer is a public method that 
>> can now return one of the new HiDPI offscreen images which is a 
>> subclass of BufferedImage.  This was what I was worried about in 
>> terms of one of these internal double buffers leaking to developer 
>> code.  If they test the image using instanceof they will see that it 
>> is a BufferdImage and they may try to dig out the raster and get 
>> confused...
>>
>>             ...jim
>>
>> On 12/17/13 10:21 AM, Anton V. Tarasov wrote:
>>> Hi all,
>>>
>>> Please look at the new version:
>>>
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2
>>>
>>> It contains the following changes:
>>>
>>> - All the scale related stuff is moved to the new class:
>>> OffScreenHiDPIImage.java
>>>
>>> - JViewport and RepaintManager no longer cache buffers.
>>>
>>> - JLightweightFrame has new method: createHiDPIImage(w, h).
>>>
>>> - JViewport, RepaintManager and AbstractRegionPainter goes the new path
>>> to create a HiDPI buffered image.
>>>
>>> - A new internal property is added: "swing.jlf.hidpiImageEnabled". 
>>> False
>>> by default. It makes JLF.createImage(w, h) forward the call to
>>> JLF.createHiDPIImage(w, h). This can be used by a third party code in
>>> case it creates a buffered image via Component.createImage(w, h) and
>>> uses the image so that it can benefit from being a HiDPI image on a
>>> Retina display.
>>>
>>> For instance, SwingSet2 has an animating Bezier curve demo. Switching
>>> the property on makes the curve auto scale smoothly. Please, look at 
>>> the
>>> screenshots:
>>>
>>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png
>>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png
>>>
>>> - SunGraphics2D now draws a HiDPI buffered image the same way it 
>>> draws a
>>> VolatileImage.
>>>
>>> - I've removed the copyArea() method from the BufImgSurfaceData, and
>>> modified the original version. The only question I have is: do I 
>>> need to
>>> check for "instanceof OffScreenHiDPIImage.SurfaceData" in case when
>>> "transformState == TRANSFORM_TRANSLATESCALE"? If this method is invoked
>>> with some other SD, and the transform is SCALE, will it do the job with
>>> the coordinates conversion done?
>>>
>>> - I've left the new methods in FramePeer default... May yet we 
>>> implement
>>> them in other peers when we really need it?
>>>
>>> - CPlatformLWWindow.getGraphicsDevice() checks for an intersection +
>>> scale. This heuristic actually may fail when a Window is moved b/w 
>>> three
>>> or four displays so that it intersects them all at some time. JFX will
>>> set a new scale factor in between and AWT may pick up a wrong device. I
>>> don't know any simple solution for that. For two monitors this will 
>>> work.
>>>
>>> Thanks,
>>> Anton.
>


From peter.brunet at oracle.com  Wed Dec 18 11:15:28 2013
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 18 Dec 2013 13:15:28 -0600
Subject: <AWT Dev> Regression test failure loading a DLL
In-Reply-To: <52B169B4.102@oracle.com>
References: <52AF2405.5050107@oracle.com> <52AF5556.3020004@oracle.com>
	<52AF661B.4060602@oracle.com> <52B051CD.7070306@oracle.com>
	<52B09B25.30409@oracle.com> <52B169B4.102@oracle.com>
Message-ID: <52B1F450.1040903@oracle.com>


On 12/18/13 3:24 AM, Artem Ananiev wrote:
>
> On 12/17/2013 10:42 PM, Pete Brunet wrote:
>> Hi Anthony, Thanks again for the assistance!
>>
>> On 12/17/13 7:29 AM, Anthony Petrov wrote:
>>>> Immediate load in JAWT*, delay load in Java*
>>>
>>> Why is that? Can you try re-linking the JAWTAccessBridge.DLL so that
>>> it uses delayed libs loading (which is always a good thing) and see if
>>> this changes anything?
>> Maybe it's a Dependency Walker anomaly?  I got that info from the fact
>> that Dependency Walker shows an hour glass next to the red icon for
>> ole32.dll for Java*.dll but not for ole32.dll for JAWT*.dll.  (Also when
>> I ran it today oleaut32.dll was delay load in both.)  I looked through
>> the ole32.dll entries in the trees for both DLLs and didn't find any
>> differences.
>>
>> When I load JAWT*.dll Dependency Walker reports an error (and some
>> warnings).  If I add bin\server to its search list that error goes away
>> (and the warnings remain).
>>
>> I found the build statements in jdk8\jdk\make\lib\PlatformLibraries.gmk
>> and Java* vs JAWT* are almost the same.  Here is are the statments in
>> the gmk file for JAWT* and Java* with the two significant difference
>> noted.
>>
>> $(call SetupNativeCompilation,BUILD_JAWTACCESSBRIDGE$1, \
>>            LIBRARY = JAWTAccessBridge$1, \
>>            OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>>            SRC := $(ACCESSBRIDGE_SRCDIR), \
>>            INCLUDE_FILES := JAWTAccessBridge.cpp, \ <-- different list
>> for Java*
>>            LANG := C++, \
>>            OPTIMIZATION := LOW, \
>>            CFLAGS := $(CFLAGS_JDKLIB) \
>>                -DACCESSBRIDGE_ARCH_$3, \
>>            LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib
>> gdi32.lib \
>>                winspool.lib jawt.lib comdlg32.lib advapi32.lib
>> shell32.lib \  <-- jawt.lib added
>
> Let me ask a stupid question: does pre-loading jawt.dll before
> JAWTAccessBridge.dll help?
It didn't help but it's interesting that the failure now happens when
jawt.dll is loaded.
>
>>                ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>>                -subsystem:windows -machine:$2 \
>>                -def:$(ACCESSBRIDGE_SRCDIR)/JAWTAccessBridge.DEF, \
>>            VERSIONINFO_RESOURCE :=
>> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>>            RC_FLAGS := $(RC_FLAGS), \
>>            OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjawtaccessbridge$1, \
>>            DEBUG_SYMBOLS := true)
>>
>>   $(call SetupNativeCompilation,BUILD_JAVAACCESSBRIDGE$1, \
>>            LIBRARY = JavaAccessBridge$1, \
>>            OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>>            SRC := $(ACCESSBRIDGE_SRCDIR), \
>>            INCLUDE_FILES := AccessBridgeATInstance.cpp
>> AccessBridgeDebug.cpp \
>>                AccessBridgeJavaEntryPoints.cpp \
>>                AccessBridgeMessages.cpp JavaAccessBridge.cpp, \
>>            LANG := C++, \
>>            OPTIMIZATION := LOW, \
>>            CFLAGS := $(CFLAGS_JDKLIB) \
>>                -DACCESSBRIDGE_ARCH_$3, \
>>            LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib
>> gdi32.lib \
>>                winspool.lib comdlg32.lib advapi32.lib shell32.lib \
>>                ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>>                -subsystem:windows -machine:$2 \
>>                -def:$(ACCESSBRIDGE_SRCDIR)/JavaAccessBridge.DEF, \
>>            VERSIONINFO_RESOURCE :=
>> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>>            RC_FLAGS := $(RC_FLAGS), \
>>            OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjavaaccessbridge$1, \
>>            DEBUG_SYMBOLS := true)
>>
>> I wonder if the LDFLAGS lists are right.  Dependency Walker shows the
>> first level dependencies as follows:
>> - JAWT*.dll: jawt.dll, msvcr100.dll, kernel32.dll
>> - Java*.dll: msvcr100.dll, kernel32.dll, user32.dll
>> but the LDFLAGS lists are much longer and also both are missing
>> msvcr100.lib
>
> msvcr100.dll is loaded by Java launcher from JRE/bin directory, so
> it's not a problem.
>
>> I ran the make in debug mode to get more output and the linker flags are
>> the same, except for the former including jawt.lib
>>
>> For JAWT*:
>> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
>> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
>>
>> kernel32.lib user32.lib gdi32.lib winspool.lib jawt.lib comdlg32.lib
>> advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
>> odbccp32.lib -subsystem:windows -machine:I386
>> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JAWTAccessBridge.DEF
>>
>>
>> For Java*:
>> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
>> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
>>
>> kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib
>> shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
>> -subsystem:windows -machine:I386
>> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JavaAccessBridge.DEF
>>
>>
>> Note that some builds have a LDFLAGS_SUFFIX_windows with -DELAYLOAD, but
>> these bridge builds don't.  I'll try adding this after lunch.
>>
>> Regarding the source code JAWTAccessBridge.cpp doesn't load any DLLs.
>> JavaAccessBridge.cpp has a loadlibrary of jawt.dll (and none of the
>> other included source files load DLLs).
>>
>> In the middle of all these details I don't want to loose track of the
>> fact that the problem only occurs when using jtreg.  In normal use there
>> has never been a problem.
>>>
>>> Also,
>>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>
> These dependencies are also fine, at least I see the same dlls in the
> list of awt.dll dependencies, and it doesn't cause any troubles.
>
>>> JDK doesn't support WinRT currently. The JAWT* (or any binary in JDK)
>>> just shouldn't be linked against these libraries (and probably other
>>> API-MS-*, too). Where do the dependencies come from? What does your
>>> Makefile do to link the JAWT* lib?
>> The JAWT* questions is answered above.
>>
>> This is the tree I see for the WinRT DLLs you mentioned:
>> javaaccessbridge.dll
>>    user32.dll
>>      advapi32.dll
>>        wintrust.dll
>>          crypt32.dll
>>            userenv.dll
>>              shell32.dll
>>                wininet.dll
>>                  iertutil.dll
>>                    API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL and
>>                    API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>
>> ditto to
>>    shell32.dll
>>      shdocvw.dll
>>        ieframe.dll
>>          mshtml.dll
>>            API-MS-WIN-CORE-WINRT-L1-1-0.DLL and
>>            API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>
> Thanks,
>
> Artem
>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 12/17/2013 12:44 AM, Pete Brunet wrote:
>>>> Hi Anthony, Thanks for helping...
>>>>
>>>> On 12/16/13 1:32 PM, Anthony Petrov wrote:
>>>>> Hi Pete,
>>>>>
>>>>> I see you've already tried the Dependency Walker.
>>>>>
>>>>> 1. Could you please clarify the following: if you compile two
>>>>> lists of
>>>>> dependencies, one for JavaAccessBridge.dll and another for
>>>>> JAWTAccessBridge.DLL, and compare them, are there any differences?
>>>> Differences:
>>>>
>>>> JAWT* has these extras
>>>> jvm.dll - error opening file
>>>> awt.dll - no problem with this and the following
>>>> java.dll
>>>> jawt.dll
>>>> verify.dll
>>>>
>>>> Immediate load in JAWT*, delay load in Java*
>>>> ole32 - colored red, i.e. missing export function required by parent
>>>> module
>>>> oleaut32.dll - no problem
>>>>>
>>>>> 2. If you change the order of loading the libraries, will it fail
>>>>> right away w/o even loading the JavaAccessBridge.dll ?
>>>> yes
>>>>>
>>>>> 3. If the above doesn't help, please post the full list of
>>>>> dependencies for JAWTAccessBridge.DLL as reported by the Dependency
>>>>> Walker.
>>>> Error opening file:
>>>> JVM.DLL
>>>> API-MS-WIN-CORE-COM-L1-1-0.DLL
>>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>>> API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
>>>> DCOMP.DLL
>>>> GPSVC.DLL
>>>> IESHIMS.DLL
>>>> Red (missing export function required by parent module):
>>>> API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
>>>> OLE32.DLL
>>>> Red, delay load:
>>>> DWMAPI.DLL
>>>> IEFRAME.DLL
>>>> IMM32.DLL
>>>> MFPLAT.DLL
>>>> NDFAPI.DLL
>>>> USERENV.DLL
>>>> UXTHEME.DLL
>>>> No problems:
>>>> ADVAPI32.DLL
>>>> API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
>>>> API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
>>>> API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
>>>> API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
>>>> API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
>>>> API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
>>>> API-MS-WIN-CORE-FILE-L1-1-0.DLL
>>>> API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
>>>> API-MS-WIN-CORE-HEAP-L1-1-0.DLL
>>>> API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
>>>> API-MS-WIN-CORE-IO-L1-1-0.DLL
>>>> API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
>>>> API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
>>>> API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
>>>> API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
>>>> API-MS-WIN-CORE-MISC-L1-1-0.DLL
>>>> API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
>>>> API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
>>>> API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
>>>> API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
>>>> API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
>>>> API-MS-WIN-CORE-STRING-L1-1-0.DLL
>>>> API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
>>>> API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
>>>> API-MS-WIN-CORE-UTIL-L1-1-0.DLL
>>>> API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
>>>> API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
>>>> API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
>>>> API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
>>>> API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
>>>> API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
>>>> AWT.DLL
>>>> CRYPTBASE.DLL
>>>> GDI32.DLL
>>>> JAVA.DLL
>>>> JAWT.DLL
>>>> JAWTACCESSBRIDGE.DLL
>>>> KERNEL32.DLL
>>>> KERNELBASE.DLL
>>>> LPK.DLL
>>>> MSVCR100.DLL
>>>> MSVCRT.DLL
>>>> NTDLL.DLL
>>>> OLEAUT32.DLL
>>>> RPCRT4.DLL
>>>> SSPICLI.DLL
>>>> USER32.DLL
>>>> USP10.DLL
>>>> VERIFY.DLL
>>>> ACLUI.DLL
>>>> ACTIVEDS.DLL
>>>> ADSLDPC.DLL
>>>> ADVPACK.DLL
>>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
>>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
>>>> API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
>>>> API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
>>>> API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
>>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
>>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
>>>> API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
>>>> API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
>>>> API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
>>>> APPHELP.DLL
>>>> ATL.DLL
>>>> AUTHZ.DLL
>>>> AVRT.DLL
>>>> BCRYPT.DLL
>>>> BROWCLI.DLL
>>>> CABINET.DLL
>>>> CERTCLI.DLL
>>>> CERTENROLL.DLL
>>>> CFGMGR32.DLL
>>>> CLBCATQ.DLL
>>>> COMCTL32.DLL
>>>> COMCTL32.DLL
>>>> COMDLG32.DLL
>>>> CREDUI.DLL
>>>> CRYPT32.DLL
>>>> CRYPTSP.DLL
>>>> CRYPTUI.DLL
>>>> CSCAPI.DLL
>>>> D2D1.DLL
>>>> D3D11.DLL
>>>> DAVHLPR.DLL
>>>> DBGHELP.DLL
>>>> DEVMGR.DLL
>>>> DEVOBJ.DLL
>>>> DEVRTL.DLL
>>>> DFSCLI.DLL
>>>> DHCPCSVC.DLL
>>>> DHCPCSVC6.DLL
>>>> DNSAPI.DLL
>>>> DRVSTORE.DLL
>>>> DSROLE.DLL
>>>> DUI70.DLL
>>>> DUSER.DLL
>>>> DWRITE.DLL
>>>> DXGI.DLL
>>>> EAPPCFG.DLL
>>>> EAPPPRXY.DLL
>>>> EFSADU.DLL
>>>> EFSUTIL.DLL
>>>> ELSCORE.DLL
>>>> ESENT.DLL
>>>> FMS.DLL
>>>> GDIPLUS.DLL
>>>> GPAPI.DLL
>>>> HLINK.DLL
>>>> IEADVPACK.DLL
>>>> IERTUTIL.DLL
>>>> IEUI.DLL
>>>> IMAGEHLP.DLL
>>>> IMGUTIL.DLL
>>>> INETCOMM.DLL
>>>> IPHLPAPI.DLL
>>>> LINKINFO.DLL
>>>> LOGONCLI.DLL
>>>> MFC42U.DLL
>>>> MLANG.DLL
>>>> MMDEVAPI.DLL
>>>> MPR.DLL
>>>> MPRAPI.DLL
>>>> MPRMSG.DLL
>>>> MSASN1.DLL
>>>> MSCTF.DLL
>>>> MSFEEDS.DLL
>>>> MSHTML.DLL
>>>> MSI.DLL
>>>> MSILTCFG.DLL
>>>> MSIMG32.DLL
>>>> MSLS31.DLL
>>>> MSOERT2.DLL
>>>> MSRATING.DLL
>>>> MSSIGN32.DLL
>>>> NCRYPT.DLL
>>>> NETAPI32.DLL
>>>> NETBIOS.DLL
>>>> NETJOIN.DLL
>>>> NETPLWIZ.DLL
>>>> NETUTILS.DLL
>>>> NEWDEV.DLL
>>>> NORMALIZ.DLL
>>>> NSI.DLL
>>>> NTDSAPI.DLL
>>>> NTSHRUI.DLL
>>>> OCCACHE.DLL
>>>> ODBC32.DLL
>>>> OLEACC.DLL
>>>> OLEDLG.DLL
>>>> ONEX.DLL
>>>> PCWUM.DLL
>>>> POWRPROF.DLL
>>>> PRINTUI.DLL
>>>> PRNTVPT.DLL
>>>> PROFAPI.DLL
>>>> PROPSYS.DLL
>>>> PSAPI.DLL
>>>> PUIAPI.DLL
>>>> RASAPI32.DLL
>>>> RASDLG.DLL
>>>> RASMAN.DLL
>>>> REGAPI.DLL
>>>> RSTRTMGR.DLL
>>>> RTUTILS.DLL
>>>> SAMCLI.DLL
>>>> SAMLIB.DLL
>>>> SCECLI.DLL
>>>> SECUR32.DLL
>>>> SENSAPI.DLL
>>>> SETUPAPI.DLL
>>>> SHDOCVW.DLL
>>>> SHELL32.DLL
>>>> SHLWAPI.DLL
>>>> SLC.DLL
>>>> SPFILEQ.DLL
>>>> SPINF.DLL
>>>> SPPC.DLL
>>>> SRVCLI.DLL
>>>> TAPI32.DLL
>>>> UIAUTOMATIONCORE.DLL
>>>> URLMON.DLL
>>>> VAULTCLI.DLL
>>>> VERSION.DLL
>>>> VPNIKEAPI.DLL
>>>> W32TOPL.DLL
>>>> WDI.DLL
>>>> WEBIO.DLL
>>>> WEBSERVICES.DLL
>>>> WER.DLL
>>>> WERUI.DLL
>>>> WINBRAND.DLL
>>>> WINDOWSCODECS.DLL
>>>> WINHTTP.DLL
>>>> WININET.DLL
>>>> WINMM.DLL
>>>> WINNSI.DLL
>>>> WINSCARD.DLL
>>>> WINSPOOL.DRV
>>>> WINSTA.DLL
>>>> WINTRUST.DLL
>>>> WKSCLI.DLL
>>>> WLANAPI.DLL
>>>> WLANUTIL.DLL
>>>> WLDAP32.DLL
>>>> WS2_32.DLL
>>>> WTSAPI32.DLL
>>>> XMLLITE.DLL
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 12/16/2013 08:02 PM, Pete Brunet wrote:
>>>>>> I'm writing a regression test and it is failing trying to load
>>>>>> bin\JAWTAccessBridge.DLL.  It was successful in loading
>>>>>> bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs
>>>>>> are
>>>>>> in jre\bin.  Here's the failure:
>>>>>>
>>>>>> java.lang.UnsatisfiedLinkError:
>>>>>> C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Can't find dependent libraries
>>>>>>     at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>>>>     at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
>>>>>>     at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
>>>>>>     at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>>>>>     at java.lang.System.loadLibrary(System.java:1119)
>>>>>>     at JABDLL$4.run(JABDLL.java:116)
>>>>>>     at java.security.AccessController.doPrivileged(Native Method)
>>>>>>     at JABDLL.foundLegacyDLLs(JABDLL.java:113)
>>>>>>     at JABDLL.main(JABDLL.java:67)
>>>>>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>     at
>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>
>>>>>>
>>>>>>
>>>>>>     at
>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>
>>>>>>
>>>>>>
>>>>>>     at java.lang.reflect.Method.invoke(Method.java:483)
>>>>>>     at
>>>>>> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>>>>>>
>>>>>>
>>>>>>     at java.lang.Thread.run(Thread.java:744)
>>>>>>
>>>>>> Here's the pertinent code:
>>>>>>
>>>>>> private static boolean foundLegacyDLLs() {
>>>>>>                java.security.AccessController.doPrivileged(
>>>>>>                    new java.security.PrivilegedAction() {
>>>>>>                        public Object run() {
>>>>>>                            System.loadLibrary("JavaAccessBridge");
>>>>>>                            return null;
>>>>>>                        }
>>>>>>                    }, null, new
>>>>>> RuntimePermission("loadLibrary.JavaAccessBridge")
>>>>>>                );
>>>>>>                java.security.AccessController.doPrivileged(
>>>>>>                    new java.security.PrivilegedAction() {
>>>>>>                        public Object run() {
>>>>>>                           
>>>>>> System.loadLibrary("JAWTAccessBridge");  //
>>>>>> line
>>>>>> 116, fails here
>>>>>>                            return null;
>>>>>>                        }
>>>>>>                    }, null, new
>>>>>> RuntimePermission("loadLibrary.JAWTAccessBridge")
>>>>>>                );
>>>>>>                return true;
>>>>>>        }
>>>>>>
>>>>>> Here's the jtreg run:
>>>>>>
>>>>>> $ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
>>>>>> -testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
>>>>>>
>>>>>>
>>>>>>
>>>>>> -verbose:summary closed/com/sun/java/accessibility/JABDLL.java
>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
>>>>>> needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
>>>>>> this can be ignored
>>>>>> FAILED: closed/com/sun/java/accessibility/JABDLL.java
>>>>>> Test results: failed: 1
>>>>>> Report written to
>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
>>>>>>
>>>>>> Results written to
>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
>>>>>> Error: Some tests failed or other problems occurred.
>>>>>>
>>>>>> Here's the prolog to the test case:
>>>>>>
>>>>>> /*
>>>>>>      * @test
>>>>>>      * @summary ...
>>>>>>      * @run main JABDLL
>>>>>>      */
>>>>>>
>>>>>> The built image runs fine in normal use, i.e. I can run SwingSet2
>>>>>> with
>>>>>> the same image so I assume it's something I'm not doing right with
>>>>>> respect to jtreg.
>>>>>>
>>>>>> The dependency walker reports jvm.dll which is in bin\server.  I
>>>>>> tried
>>>>>> moving that to bin but that didn't help.   Also some Win DLLs were
>>>>>> reported most of which start with API-MS-WIN- but I assume those are
>>>>>> false negatives.  The sdk image I am testing is 32 bit and the
>>>>>> DLL is
>>>>>> also 32 bit.  Hopefully it's just something I don't yet understand
>>>>>> about
>>>>>> jprt, like maybe a missing @ tag in the prolog.
>>>>>>
>>>>>> Any ideas on how to debug this?
>>>>>>
>>>>>> Pete
>>>>>>
>>>>>>
>>>>
>>


From peter.brunet at oracle.com  Wed Dec 18 11:22:42 2013
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 18 Dec 2013 13:22:42 -0600
Subject: <AWT Dev> Regression test failure loading a DLL
In-Reply-To: <52B1F450.1040903@oracle.com>
References: <52AF2405.5050107@oracle.com> <52AF5556.3020004@oracle.com>
	<52AF661B.4060602@oracle.com> <52B051CD.7070306@oracle.com>
	<52B09B25.30409@oracle.com> <52B169B4.102@oracle.com>
	<52B1F450.1040903@oracle.com>
Message-ID: <52B1F602.40608@oracle.com>


On 12/18/13 1:15 PM, Pete Brunet wrote:
> On 12/18/13 3:24 AM, Artem Ananiev wrote:
>> On 12/17/2013 10:42 PM, Pete Brunet wrote:
>>> Hi Anthony, Thanks again for the assistance!
>>>
>>> On 12/17/13 7:29 AM, Anthony Petrov wrote:
>>>>> Immediate load in JAWT*, delay load in Java*
>>>> Why is that? Can you try re-linking the JAWTAccessBridge.DLL so that
>>>> it uses delayed libs loading (which is always a good thing) and see if
>>>> this changes anything?
>>> Maybe it's a Dependency Walker anomaly?  I got that info from the fact
>>> that Dependency Walker shows an hour glass next to the red icon for
>>> ole32.dll for Java*.dll but not for ole32.dll for JAWT*.dll.  (Also when
>>> I ran it today oleaut32.dll was delay load in both.)  I looked through
>>> the ole32.dll entries in the trees for both DLLs and didn't find any
>>> differences.
>>>
>>> When I load JAWT*.dll Dependency Walker reports an error (and some
>>> warnings).  If I add bin\server to its search list that error goes away
>>> (and the warnings remain).
>>>
>>> I found the build statements in jdk8\jdk\make\lib\PlatformLibraries.gmk
>>> and Java* vs JAWT* are almost the same.  Here is are the statments in
>>> the gmk file for JAWT* and Java* with the two significant difference
>>> noted.
>>>
>>> $(call SetupNativeCompilation,BUILD_JAWTACCESSBRIDGE$1, \
>>>            LIBRARY = JAWTAccessBridge$1, \
>>>            OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>>>            SRC := $(ACCESSBRIDGE_SRCDIR), \
>>>            INCLUDE_FILES := JAWTAccessBridge.cpp, \ <-- different list
>>> for Java*
>>>            LANG := C++, \
>>>            OPTIMIZATION := LOW, \
>>>            CFLAGS := $(CFLAGS_JDKLIB) \
>>>                -DACCESSBRIDGE_ARCH_$3, \
>>>            LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib
>>> gdi32.lib \
>>>                winspool.lib jawt.lib comdlg32.lib advapi32.lib
>>> shell32.lib \  <-- jawt.lib added
>> Let me ask a stupid question: does pre-loading jawt.dll before
>> JAWTAccessBridge.dll help?
> It didn't help but it's interesting that the failure now happens when
> jawt.dll is loaded.
Loading awt.dll before jawt.dll before JAWTAccessBridge-32.dll solved
the problem.  But why?
>>>                ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>>>                -subsystem:windows -machine:$2 \
>>>                -def:$(ACCESSBRIDGE_SRCDIR)/JAWTAccessBridge.DEF, \
>>>            VERSIONINFO_RESOURCE :=
>>> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>>>            RC_FLAGS := $(RC_FLAGS), \
>>>            OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjawtaccessbridge$1, \
>>>            DEBUG_SYMBOLS := true)
>>>
>>>   $(call SetupNativeCompilation,BUILD_JAVAACCESSBRIDGE$1, \
>>>            LIBRARY = JavaAccessBridge$1, \
>>>            OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>>>            SRC := $(ACCESSBRIDGE_SRCDIR), \
>>>            INCLUDE_FILES := AccessBridgeATInstance.cpp
>>> AccessBridgeDebug.cpp \
>>>                AccessBridgeJavaEntryPoints.cpp \
>>>                AccessBridgeMessages.cpp JavaAccessBridge.cpp, \
>>>            LANG := C++, \
>>>            OPTIMIZATION := LOW, \
>>>            CFLAGS := $(CFLAGS_JDKLIB) \
>>>                -DACCESSBRIDGE_ARCH_$3, \
>>>            LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib
>>> gdi32.lib \
>>>                winspool.lib comdlg32.lib advapi32.lib shell32.lib \
>>>                ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>>>                -subsystem:windows -machine:$2 \
>>>                -def:$(ACCESSBRIDGE_SRCDIR)/JavaAccessBridge.DEF, \
>>>            VERSIONINFO_RESOURCE :=
>>> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>>>            RC_FLAGS := $(RC_FLAGS), \
>>>            OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjavaaccessbridge$1, \
>>>            DEBUG_SYMBOLS := true)
>>>
>>> I wonder if the LDFLAGS lists are right.  Dependency Walker shows the
>>> first level dependencies as follows:
>>> - JAWT*.dll: jawt.dll, msvcr100.dll, kernel32.dll
>>> - Java*.dll: msvcr100.dll, kernel32.dll, user32.dll
>>> but the LDFLAGS lists are much longer and also both are missing
>>> msvcr100.lib
>> msvcr100.dll is loaded by Java launcher from JRE/bin directory, so
>> it's not a problem.
>>
>>> I ran the make in debug mode to get more output and the linker flags are
>>> the same, except for the former including jawt.lib
>>>
>>> For JAWT*:
>>> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
>>> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
>>>
>>> kernel32.lib user32.lib gdi32.lib winspool.lib jawt.lib comdlg32.lib
>>> advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
>>> odbccp32.lib -subsystem:windows -machine:I386
>>> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JAWTAccessBridge.DEF
>>>
>>>
>>> For Java*:
>>> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
>>> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
>>>
>>> kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib
>>> shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
>>> -subsystem:windows -machine:I386
>>> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JavaAccessBridge.DEF
>>>
>>>
>>> Note that some builds have a LDFLAGS_SUFFIX_windows with -DELAYLOAD, but
>>> these bridge builds don't.  I'll try adding this after lunch.
>>>
>>> Regarding the source code JAWTAccessBridge.cpp doesn't load any DLLs.
>>> JavaAccessBridge.cpp has a loadlibrary of jawt.dll (and none of the
>>> other included source files load DLLs).
>>>
>>> In the middle of all these details I don't want to loose track of the
>>> fact that the problem only occurs when using jtreg.  In normal use there
>>> has never been a problem.
>>>> Also,
>>>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>> These dependencies are also fine, at least I see the same dlls in the
>> list of awt.dll dependencies, and it doesn't cause any troubles.
>>
>>>> JDK doesn't support WinRT currently. The JAWT* (or any binary in JDK)
>>>> just shouldn't be linked against these libraries (and probably other
>>>> API-MS-*, too). Where do the dependencies come from? What does your
>>>> Makefile do to link the JAWT* lib?
>>> The JAWT* questions is answered above.
>>>
>>> This is the tree I see for the WinRT DLLs you mentioned:
>>> javaaccessbridge.dll
>>>    user32.dll
>>>      advapi32.dll
>>>        wintrust.dll
>>>          crypt32.dll
>>>            userenv.dll
>>>              shell32.dll
>>>                wininet.dll
>>>                  iertutil.dll
>>>                    API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL and
>>>                    API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>>
>>> ditto to
>>>    shell32.dll
>>>      shdocvw.dll
>>>        ieframe.dll
>>>          mshtml.dll
>>>            API-MS-WIN-CORE-WINRT-L1-1-0.DLL and
>>>            API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>> Thanks,
>>
>> Artem
>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 12/17/2013 12:44 AM, Pete Brunet wrote:
>>>>> Hi Anthony, Thanks for helping...
>>>>>
>>>>> On 12/16/13 1:32 PM, Anthony Petrov wrote:
>>>>>> Hi Pete,
>>>>>>
>>>>>> I see you've already tried the Dependency Walker.
>>>>>>
>>>>>> 1. Could you please clarify the following: if you compile two
>>>>>> lists of
>>>>>> dependencies, one for JavaAccessBridge.dll and another for
>>>>>> JAWTAccessBridge.DLL, and compare them, are there any differences?
>>>>> Differences:
>>>>>
>>>>> JAWT* has these extras
>>>>> jvm.dll - error opening file
>>>>> awt.dll - no problem with this and the following
>>>>> java.dll
>>>>> jawt.dll
>>>>> verify.dll
>>>>>
>>>>> Immediate load in JAWT*, delay load in Java*
>>>>> ole32 - colored red, i.e. missing export function required by parent
>>>>> module
>>>>> oleaut32.dll - no problem
>>>>>> 2. If you change the order of loading the libraries, will it fail
>>>>>> right away w/o even loading the JavaAccessBridge.dll ?
>>>>> yes
>>>>>> 3. If the above doesn't help, please post the full list of
>>>>>> dependencies for JAWTAccessBridge.DLL as reported by the Dependency
>>>>>> Walker.
>>>>> Error opening file:
>>>>> JVM.DLL
>>>>> API-MS-WIN-CORE-COM-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>>>> API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
>>>>> DCOMP.DLL
>>>>> GPSVC.DLL
>>>>> IESHIMS.DLL
>>>>> Red (missing export function required by parent module):
>>>>> API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
>>>>> OLE32.DLL
>>>>> Red, delay load:
>>>>> DWMAPI.DLL
>>>>> IEFRAME.DLL
>>>>> IMM32.DLL
>>>>> MFPLAT.DLL
>>>>> NDFAPI.DLL
>>>>> USERENV.DLL
>>>>> UXTHEME.DLL
>>>>> No problems:
>>>>> ADVAPI32.DLL
>>>>> API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-FILE-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-HEAP-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-IO-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-MISC-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-STRING-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
>>>>> API-MS-WIN-CORE-UTIL-L1-1-0.DLL
>>>>> API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
>>>>> API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
>>>>> API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
>>>>> API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
>>>>> API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
>>>>> API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
>>>>> AWT.DLL
>>>>> CRYPTBASE.DLL
>>>>> GDI32.DLL
>>>>> JAVA.DLL
>>>>> JAWT.DLL
>>>>> JAWTACCESSBRIDGE.DLL
>>>>> KERNEL32.DLL
>>>>> KERNELBASE.DLL
>>>>> LPK.DLL
>>>>> MSVCR100.DLL
>>>>> MSVCRT.DLL
>>>>> NTDLL.DLL
>>>>> OLEAUT32.DLL
>>>>> RPCRT4.DLL
>>>>> SSPICLI.DLL
>>>>> USER32.DLL
>>>>> USP10.DLL
>>>>> VERIFY.DLL
>>>>> ACLUI.DLL
>>>>> ACTIVEDS.DLL
>>>>> ADSLDPC.DLL
>>>>> ADVPACK.DLL
>>>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
>>>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
>>>>> API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
>>>>> API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
>>>>> API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
>>>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
>>>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
>>>>> API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
>>>>> API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
>>>>> API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
>>>>> APPHELP.DLL
>>>>> ATL.DLL
>>>>> AUTHZ.DLL
>>>>> AVRT.DLL
>>>>> BCRYPT.DLL
>>>>> BROWCLI.DLL
>>>>> CABINET.DLL
>>>>> CERTCLI.DLL
>>>>> CERTENROLL.DLL
>>>>> CFGMGR32.DLL
>>>>> CLBCATQ.DLL
>>>>> COMCTL32.DLL
>>>>> COMCTL32.DLL
>>>>> COMDLG32.DLL
>>>>> CREDUI.DLL
>>>>> CRYPT32.DLL
>>>>> CRYPTSP.DLL
>>>>> CRYPTUI.DLL
>>>>> CSCAPI.DLL
>>>>> D2D1.DLL
>>>>> D3D11.DLL
>>>>> DAVHLPR.DLL
>>>>> DBGHELP.DLL
>>>>> DEVMGR.DLL
>>>>> DEVOBJ.DLL
>>>>> DEVRTL.DLL
>>>>> DFSCLI.DLL
>>>>> DHCPCSVC.DLL
>>>>> DHCPCSVC6.DLL
>>>>> DNSAPI.DLL
>>>>> DRVSTORE.DLL
>>>>> DSROLE.DLL
>>>>> DUI70.DLL
>>>>> DUSER.DLL
>>>>> DWRITE.DLL
>>>>> DXGI.DLL
>>>>> EAPPCFG.DLL
>>>>> EAPPPRXY.DLL
>>>>> EFSADU.DLL
>>>>> EFSUTIL.DLL
>>>>> ELSCORE.DLL
>>>>> ESENT.DLL
>>>>> FMS.DLL
>>>>> GDIPLUS.DLL
>>>>> GPAPI.DLL
>>>>> HLINK.DLL
>>>>> IEADVPACK.DLL
>>>>> IERTUTIL.DLL
>>>>> IEUI.DLL
>>>>> IMAGEHLP.DLL
>>>>> IMGUTIL.DLL
>>>>> INETCOMM.DLL
>>>>> IPHLPAPI.DLL
>>>>> LINKINFO.DLL
>>>>> LOGONCLI.DLL
>>>>> MFC42U.DLL
>>>>> MLANG.DLL
>>>>> MMDEVAPI.DLL
>>>>> MPR.DLL
>>>>> MPRAPI.DLL
>>>>> MPRMSG.DLL
>>>>> MSASN1.DLL
>>>>> MSCTF.DLL
>>>>> MSFEEDS.DLL
>>>>> MSHTML.DLL
>>>>> MSI.DLL
>>>>> MSILTCFG.DLL
>>>>> MSIMG32.DLL
>>>>> MSLS31.DLL
>>>>> MSOERT2.DLL
>>>>> MSRATING.DLL
>>>>> MSSIGN32.DLL
>>>>> NCRYPT.DLL
>>>>> NETAPI32.DLL
>>>>> NETBIOS.DLL
>>>>> NETJOIN.DLL
>>>>> NETPLWIZ.DLL
>>>>> NETUTILS.DLL
>>>>> NEWDEV.DLL
>>>>> NORMALIZ.DLL
>>>>> NSI.DLL
>>>>> NTDSAPI.DLL
>>>>> NTSHRUI.DLL
>>>>> OCCACHE.DLL
>>>>> ODBC32.DLL
>>>>> OLEACC.DLL
>>>>> OLEDLG.DLL
>>>>> ONEX.DLL
>>>>> PCWUM.DLL
>>>>> POWRPROF.DLL
>>>>> PRINTUI.DLL
>>>>> PRNTVPT.DLL
>>>>> PROFAPI.DLL
>>>>> PROPSYS.DLL
>>>>> PSAPI.DLL
>>>>> PUIAPI.DLL
>>>>> RASAPI32.DLL
>>>>> RASDLG.DLL
>>>>> RASMAN.DLL
>>>>> REGAPI.DLL
>>>>> RSTRTMGR.DLL
>>>>> RTUTILS.DLL
>>>>> SAMCLI.DLL
>>>>> SAMLIB.DLL
>>>>> SCECLI.DLL
>>>>> SECUR32.DLL
>>>>> SENSAPI.DLL
>>>>> SETUPAPI.DLL
>>>>> SHDOCVW.DLL
>>>>> SHELL32.DLL
>>>>> SHLWAPI.DLL
>>>>> SLC.DLL
>>>>> SPFILEQ.DLL
>>>>> SPINF.DLL
>>>>> SPPC.DLL
>>>>> SRVCLI.DLL
>>>>> TAPI32.DLL
>>>>> UIAUTOMATIONCORE.DLL
>>>>> URLMON.DLL
>>>>> VAULTCLI.DLL
>>>>> VERSION.DLL
>>>>> VPNIKEAPI.DLL
>>>>> W32TOPL.DLL
>>>>> WDI.DLL
>>>>> WEBIO.DLL
>>>>> WEBSERVICES.DLL
>>>>> WER.DLL
>>>>> WERUI.DLL
>>>>> WINBRAND.DLL
>>>>> WINDOWSCODECS.DLL
>>>>> WINHTTP.DLL
>>>>> WININET.DLL
>>>>> WINMM.DLL
>>>>> WINNSI.DLL
>>>>> WINSCARD.DLL
>>>>> WINSPOOL.DRV
>>>>> WINSTA.DLL
>>>>> WINTRUST.DLL
>>>>> WKSCLI.DLL
>>>>> WLANAPI.DLL
>>>>> WLANUTIL.DLL
>>>>> WLDAP32.DLL
>>>>> WS2_32.DLL
>>>>> WTSAPI32.DLL
>>>>> XMLLITE.DLL
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 12/16/2013 08:02 PM, Pete Brunet wrote:
>>>>>>> I'm writing a regression test and it is failing trying to load
>>>>>>> bin\JAWTAccessBridge.DLL.  It was successful in loading
>>>>>>> bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs
>>>>>>> are
>>>>>>> in jre\bin.  Here's the failure:
>>>>>>>
>>>>>>> java.lang.UnsatisfiedLinkError:
>>>>>>> C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Can't find dependent libraries
>>>>>>>     at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>>>>>     at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
>>>>>>>     at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
>>>>>>>     at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>>>>>>     at java.lang.System.loadLibrary(System.java:1119)
>>>>>>>     at JABDLL$4.run(JABDLL.java:116)
>>>>>>>     at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>     at JABDLL.foundLegacyDLLs(JABDLL.java:113)
>>>>>>>     at JABDLL.main(JABDLL.java:67)
>>>>>>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>     at
>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     at
>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     at java.lang.reflect.Method.invoke(Method.java:483)
>>>>>>>     at
>>>>>>> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>>>>>>>
>>>>>>>
>>>>>>>     at java.lang.Thread.run(Thread.java:744)
>>>>>>>
>>>>>>> Here's the pertinent code:
>>>>>>>
>>>>>>> private static boolean foundLegacyDLLs() {
>>>>>>>                java.security.AccessController.doPrivileged(
>>>>>>>                    new java.security.PrivilegedAction() {
>>>>>>>                        public Object run() {
>>>>>>>                            System.loadLibrary("JavaAccessBridge");
>>>>>>>                            return null;
>>>>>>>                        }
>>>>>>>                    }, null, new
>>>>>>> RuntimePermission("loadLibrary.JavaAccessBridge")
>>>>>>>                );
>>>>>>>                java.security.AccessController.doPrivileged(
>>>>>>>                    new java.security.PrivilegedAction() {
>>>>>>>                        public Object run() {
>>>>>>>                           
>>>>>>> System.loadLibrary("JAWTAccessBridge");  //
>>>>>>> line
>>>>>>> 116, fails here
>>>>>>>                            return null;
>>>>>>>                        }
>>>>>>>                    }, null, new
>>>>>>> RuntimePermission("loadLibrary.JAWTAccessBridge")
>>>>>>>                );
>>>>>>>                return true;
>>>>>>>        }
>>>>>>>
>>>>>>> Here's the jtreg run:
>>>>>>>
>>>>>>> $ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
>>>>>>> -testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -verbose:summary closed/com/sun/java/accessibility/JABDLL.java
>>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
>>>>>>> needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
>>>>>>> this can be ignored
>>>>>>> FAILED: closed/com/sun/java/accessibility/JABDLL.java
>>>>>>> Test results: failed: 1
>>>>>>> Report written to
>>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
>>>>>>>
>>>>>>> Results written to
>>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
>>>>>>> Error: Some tests failed or other problems occurred.
>>>>>>>
>>>>>>> Here's the prolog to the test case:
>>>>>>>
>>>>>>> /*
>>>>>>>      * @test
>>>>>>>      * @summary ...
>>>>>>>      * @run main JABDLL
>>>>>>>      */
>>>>>>>
>>>>>>> The built image runs fine in normal use, i.e. I can run SwingSet2
>>>>>>> with
>>>>>>> the same image so I assume it's something I'm not doing right with
>>>>>>> respect to jtreg.
>>>>>>>
>>>>>>> The dependency walker reports jvm.dll which is in bin\server.  I
>>>>>>> tried
>>>>>>> moving that to bin but that didn't help.   Also some Win DLLs were
>>>>>>> reported most of which start with API-MS-WIN- but I assume those are
>>>>>>> false negatives.  The sdk image I am testing is 32 bit and the
>>>>>>> DLL is
>>>>>>> also 32 bit.  Hopefully it's just something I don't yet understand
>>>>>>> about
>>>>>>> jprt, like maybe a missing @ tag in the prolog.
>>>>>>>
>>>>>>> Any ideas on how to debug this?
>>>>>>>
>>>>>>> Pete
>>>>>>>
>>>>>>>


From peter.brunet at oracle.com  Wed Dec 18 12:01:45 2013
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 18 Dec 2013 14:01:45 -0600
Subject: <AWT Dev> Regression test failure loading a DLL
In-Reply-To: <52B1F602.40608@oracle.com>
References: <52AF2405.5050107@oracle.com>
	<52AF5556.3020004@oracle.com>	<52AF661B.4060602@oracle.com>
	<52B051CD.7070306@oracle.com>	<52B09B25.30409@oracle.com>
	<52B169B4.102@oracle.com>	<52B1F450.1040903@oracle.com>
	<52B1F602.40608@oracle.com>
Message-ID: <52B1FF29.7090006@oracle.com>


On 12/18/13 1:22 PM, Pete Brunet wrote:
> On 12/18/13 1:15 PM, Pete Brunet wrote:
>> On 12/18/13 3:24 AM, Artem Ananiev wrote:
>>> On 12/17/2013 10:42 PM, Pete Brunet wrote:
>>>> Hi Anthony, Thanks again for the assistance!
>>>>
>>>> On 12/17/13 7:29 AM, Anthony Petrov wrote:
>>>>>> Immediate load in JAWT*, delay load in Java*
>>>>> Why is that? Can you try re-linking the JAWTAccessBridge.DLL so that
>>>>> it uses delayed libs loading (which is always a good thing) and see if
>>>>> this changes anything?
>>>> Maybe it's a Dependency Walker anomaly?  I got that info from the fact
>>>> that Dependency Walker shows an hour glass next to the red icon for
>>>> ole32.dll for Java*.dll but not for ole32.dll for JAWT*.dll.  (Also when
>>>> I ran it today oleaut32.dll was delay load in both.)  I looked through
>>>> the ole32.dll entries in the trees for both DLLs and didn't find any
>>>> differences.
>>>>
>>>> When I load JAWT*.dll Dependency Walker reports an error (and some
>>>> warnings).  If I add bin\server to its search list that error goes away
>>>> (and the warnings remain).
>>>>
>>>> I found the build statements in jdk8\jdk\make\lib\PlatformLibraries.gmk
>>>> and Java* vs JAWT* are almost the same.  Here is are the statments in
>>>> the gmk file for JAWT* and Java* with the two significant difference
>>>> noted.
>>>>
>>>> $(call SetupNativeCompilation,BUILD_JAWTACCESSBRIDGE$1, \
>>>>            LIBRARY = JAWTAccessBridge$1, \
>>>>            OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>>>>            SRC := $(ACCESSBRIDGE_SRCDIR), \
>>>>            INCLUDE_FILES := JAWTAccessBridge.cpp, \ <-- different list
>>>> for Java*
>>>>            LANG := C++, \
>>>>            OPTIMIZATION := LOW, \
>>>>            CFLAGS := $(CFLAGS_JDKLIB) \
>>>>                -DACCESSBRIDGE_ARCH_$3, \
>>>>            LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib
>>>> gdi32.lib \
>>>>                winspool.lib jawt.lib comdlg32.lib advapi32.lib
>>>> shell32.lib \  <-- jawt.lib added
>>> Let me ask a stupid question: does pre-loading jawt.dll before
>>> JAWTAccessBridge.dll help?
>> It didn't help but it's interesting that the failure now happens when
>> jawt.dll is loaded.
> Loading awt.dll before jawt.dll before JAWTAccessBridge-32.dll solved
> the problem.  But why?
Normally JAWTAccessBridge-32.dll is loaded by this sequence:  the access
bridge class is loaded by the VM (if the users's
.accessibility.properties is set up for that), then that class loads
JAWTAccessBridge-32.dll which I assume then loads jawt.dll which loads
awt.dll.  The Win dll search algorithm found here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx
looks in the app directory which I assume in the normal case has been
set to the jre's bin directory.  In the case of running my test case
under jtreg the app directory and current directory are probably not the
jre's bin directory.  So I suppose it's OK with respect to what I want
to accomplish with my test case for me to preload awt.dll and jawt.dll
in the test case.
>>>>                ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>>>>                -subsystem:windows -machine:$2 \
>>>>                -def:$(ACCESSBRIDGE_SRCDIR)/JAWTAccessBridge.DEF, \
>>>>            VERSIONINFO_RESOURCE :=
>>>> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>>>>            RC_FLAGS := $(RC_FLAGS), \
>>>>            OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjawtaccessbridge$1, \
>>>>            DEBUG_SYMBOLS := true)
>>>>
>>>>   $(call SetupNativeCompilation,BUILD_JAVAACCESSBRIDGE$1, \
>>>>            LIBRARY = JavaAccessBridge$1, \
>>>>            OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>>>>            SRC := $(ACCESSBRIDGE_SRCDIR), \
>>>>            INCLUDE_FILES := AccessBridgeATInstance.cpp
>>>> AccessBridgeDebug.cpp \
>>>>                AccessBridgeJavaEntryPoints.cpp \
>>>>                AccessBridgeMessages.cpp JavaAccessBridge.cpp, \
>>>>            LANG := C++, \
>>>>            OPTIMIZATION := LOW, \
>>>>            CFLAGS := $(CFLAGS_JDKLIB) \
>>>>                -DACCESSBRIDGE_ARCH_$3, \
>>>>            LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib
>>>> gdi32.lib \
>>>>                winspool.lib comdlg32.lib advapi32.lib shell32.lib \
>>>>                ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>>>>                -subsystem:windows -machine:$2 \
>>>>                -def:$(ACCESSBRIDGE_SRCDIR)/JavaAccessBridge.DEF, \
>>>>            VERSIONINFO_RESOURCE :=
>>>> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>>>>            RC_FLAGS := $(RC_FLAGS), \
>>>>            OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjavaaccessbridge$1, \
>>>>            DEBUG_SYMBOLS := true)
>>>>
>>>> I wonder if the LDFLAGS lists are right.  Dependency Walker shows the
>>>> first level dependencies as follows:
>>>> - JAWT*.dll: jawt.dll, msvcr100.dll, kernel32.dll
>>>> - Java*.dll: msvcr100.dll, kernel32.dll, user32.dll
>>>> but the LDFLAGS lists are much longer and also both are missing
>>>> msvcr100.lib
>>> msvcr100.dll is loaded by Java launcher from JRE/bin directory, so
>>> it's not a problem.
>>>
>>>> I ran the make in debug mode to get more output and the linker flags are
>>>> the same, except for the former including jawt.lib
>>>>
>>>> For JAWT*:
>>>> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
>>>> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
>>>>
>>>> kernel32.lib user32.lib gdi32.lib winspool.lib jawt.lib comdlg32.lib
>>>> advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
>>>> odbccp32.lib -subsystem:windows -machine:I386
>>>> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JAWTAccessBridge.DEF
>>>>
>>>>
>>>> For Java*:
>>>> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
>>>> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
>>>>
>>>> kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib
>>>> shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
>>>> -subsystem:windows -machine:I386
>>>> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JavaAccessBridge.DEF
>>>>
>>>>
>>>> Note that some builds have a LDFLAGS_SUFFIX_windows with -DELAYLOAD, but
>>>> these bridge builds don't.  I'll try adding this after lunch.
>>>>
>>>> Regarding the source code JAWTAccessBridge.cpp doesn't load any DLLs.
>>>> JavaAccessBridge.cpp has a loadlibrary of jawt.dll (and none of the
>>>> other included source files load DLLs).
>>>>
>>>> In the middle of all these details I don't want to loose track of the
>>>> fact that the problem only occurs when using jtreg.  In normal use there
>>>> has never been a problem.
>>>>> Also,
>>>>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>> These dependencies are also fine, at least I see the same dlls in the
>>> list of awt.dll dependencies, and it doesn't cause any troubles.
>>>
>>>>> JDK doesn't support WinRT currently. The JAWT* (or any binary in JDK)
>>>>> just shouldn't be linked against these libraries (and probably other
>>>>> API-MS-*, too). Where do the dependencies come from? What does your
>>>>> Makefile do to link the JAWT* lib?
>>>> The JAWT* questions is answered above.
>>>>
>>>> This is the tree I see for the WinRT DLLs you mentioned:
>>>> javaaccessbridge.dll
>>>>    user32.dll
>>>>      advapi32.dll
>>>>        wintrust.dll
>>>>          crypt32.dll
>>>>            userenv.dll
>>>>              shell32.dll
>>>>                wininet.dll
>>>>                  iertutil.dll
>>>>                    API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL and
>>>>                    API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>>>
>>>> ditto to
>>>>    shell32.dll
>>>>      shdocvw.dll
>>>>        ieframe.dll
>>>>          mshtml.dll
>>>>            API-MS-WIN-CORE-WINRT-L1-1-0.DLL and
>>>>            API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>> Thanks,
>>>
>>> Artem
>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 12/17/2013 12:44 AM, Pete Brunet wrote:
>>>>>> Hi Anthony, Thanks for helping...
>>>>>>
>>>>>> On 12/16/13 1:32 PM, Anthony Petrov wrote:
>>>>>>> Hi Pete,
>>>>>>>
>>>>>>> I see you've already tried the Dependency Walker.
>>>>>>>
>>>>>>> 1. Could you please clarify the following: if you compile two
>>>>>>> lists of
>>>>>>> dependencies, one for JavaAccessBridge.dll and another for
>>>>>>> JAWTAccessBridge.DLL, and compare them, are there any differences?
>>>>>> Differences:
>>>>>>
>>>>>> JAWT* has these extras
>>>>>> jvm.dll - error opening file
>>>>>> awt.dll - no problem with this and the following
>>>>>> java.dll
>>>>>> jawt.dll
>>>>>> verify.dll
>>>>>>
>>>>>> Immediate load in JAWT*, delay load in Java*
>>>>>> ole32 - colored red, i.e. missing export function required by parent
>>>>>> module
>>>>>> oleaut32.dll - no problem
>>>>>>> 2. If you change the order of loading the libraries, will it fail
>>>>>>> right away w/o even loading the JavaAccessBridge.dll ?
>>>>>> yes
>>>>>>> 3. If the above doesn't help, please post the full list of
>>>>>>> dependencies for JAWTAccessBridge.DLL as reported by the Dependency
>>>>>>> Walker.
>>>>>> Error opening file:
>>>>>> JVM.DLL
>>>>>> API-MS-WIN-CORE-COM-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>>>>> API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
>>>>>> DCOMP.DLL
>>>>>> GPSVC.DLL
>>>>>> IESHIMS.DLL
>>>>>> Red (missing export function required by parent module):
>>>>>> API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
>>>>>> OLE32.DLL
>>>>>> Red, delay load:
>>>>>> DWMAPI.DLL
>>>>>> IEFRAME.DLL
>>>>>> IMM32.DLL
>>>>>> MFPLAT.DLL
>>>>>> NDFAPI.DLL
>>>>>> USERENV.DLL
>>>>>> UXTHEME.DLL
>>>>>> No problems:
>>>>>> ADVAPI32.DLL
>>>>>> API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-FILE-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-HEAP-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-IO-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-MISC-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-STRING-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-UTIL-L1-1-0.DLL
>>>>>> API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
>>>>>> API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
>>>>>> API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
>>>>>> API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
>>>>>> API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
>>>>>> API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
>>>>>> AWT.DLL
>>>>>> CRYPTBASE.DLL
>>>>>> GDI32.DLL
>>>>>> JAVA.DLL
>>>>>> JAWT.DLL
>>>>>> JAWTACCESSBRIDGE.DLL
>>>>>> KERNEL32.DLL
>>>>>> KERNELBASE.DLL
>>>>>> LPK.DLL
>>>>>> MSVCR100.DLL
>>>>>> MSVCRT.DLL
>>>>>> NTDLL.DLL
>>>>>> OLEAUT32.DLL
>>>>>> RPCRT4.DLL
>>>>>> SSPICLI.DLL
>>>>>> USER32.DLL
>>>>>> USP10.DLL
>>>>>> VERIFY.DLL
>>>>>> ACLUI.DLL
>>>>>> ACTIVEDS.DLL
>>>>>> ADSLDPC.DLL
>>>>>> ADVPACK.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
>>>>>> API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
>>>>>> APPHELP.DLL
>>>>>> ATL.DLL
>>>>>> AUTHZ.DLL
>>>>>> AVRT.DLL
>>>>>> BCRYPT.DLL
>>>>>> BROWCLI.DLL
>>>>>> CABINET.DLL
>>>>>> CERTCLI.DLL
>>>>>> CERTENROLL.DLL
>>>>>> CFGMGR32.DLL
>>>>>> CLBCATQ.DLL
>>>>>> COMCTL32.DLL
>>>>>> COMCTL32.DLL
>>>>>> COMDLG32.DLL
>>>>>> CREDUI.DLL
>>>>>> CRYPT32.DLL
>>>>>> CRYPTSP.DLL
>>>>>> CRYPTUI.DLL
>>>>>> CSCAPI.DLL
>>>>>> D2D1.DLL
>>>>>> D3D11.DLL
>>>>>> DAVHLPR.DLL
>>>>>> DBGHELP.DLL
>>>>>> DEVMGR.DLL
>>>>>> DEVOBJ.DLL
>>>>>> DEVRTL.DLL
>>>>>> DFSCLI.DLL
>>>>>> DHCPCSVC.DLL
>>>>>> DHCPCSVC6.DLL
>>>>>> DNSAPI.DLL
>>>>>> DRVSTORE.DLL
>>>>>> DSROLE.DLL
>>>>>> DUI70.DLL
>>>>>> DUSER.DLL
>>>>>> DWRITE.DLL
>>>>>> DXGI.DLL
>>>>>> EAPPCFG.DLL
>>>>>> EAPPPRXY.DLL
>>>>>> EFSADU.DLL
>>>>>> EFSUTIL.DLL
>>>>>> ELSCORE.DLL
>>>>>> ESENT.DLL
>>>>>> FMS.DLL
>>>>>> GDIPLUS.DLL
>>>>>> GPAPI.DLL
>>>>>> HLINK.DLL
>>>>>> IEADVPACK.DLL
>>>>>> IERTUTIL.DLL
>>>>>> IEUI.DLL
>>>>>> IMAGEHLP.DLL
>>>>>> IMGUTIL.DLL
>>>>>> INETCOMM.DLL
>>>>>> IPHLPAPI.DLL
>>>>>> LINKINFO.DLL
>>>>>> LOGONCLI.DLL
>>>>>> MFC42U.DLL
>>>>>> MLANG.DLL
>>>>>> MMDEVAPI.DLL
>>>>>> MPR.DLL
>>>>>> MPRAPI.DLL
>>>>>> MPRMSG.DLL
>>>>>> MSASN1.DLL
>>>>>> MSCTF.DLL
>>>>>> MSFEEDS.DLL
>>>>>> MSHTML.DLL
>>>>>> MSI.DLL
>>>>>> MSILTCFG.DLL
>>>>>> MSIMG32.DLL
>>>>>> MSLS31.DLL
>>>>>> MSOERT2.DLL
>>>>>> MSRATING.DLL
>>>>>> MSSIGN32.DLL
>>>>>> NCRYPT.DLL
>>>>>> NETAPI32.DLL
>>>>>> NETBIOS.DLL
>>>>>> NETJOIN.DLL
>>>>>> NETPLWIZ.DLL
>>>>>> NETUTILS.DLL
>>>>>> NEWDEV.DLL
>>>>>> NORMALIZ.DLL
>>>>>> NSI.DLL
>>>>>> NTDSAPI.DLL
>>>>>> NTSHRUI.DLL
>>>>>> OCCACHE.DLL
>>>>>> ODBC32.DLL
>>>>>> OLEACC.DLL
>>>>>> OLEDLG.DLL
>>>>>> ONEX.DLL
>>>>>> PCWUM.DLL
>>>>>> POWRPROF.DLL
>>>>>> PRINTUI.DLL
>>>>>> PRNTVPT.DLL
>>>>>> PROFAPI.DLL
>>>>>> PROPSYS.DLL
>>>>>> PSAPI.DLL
>>>>>> PUIAPI.DLL
>>>>>> RASAPI32.DLL
>>>>>> RASDLG.DLL
>>>>>> RASMAN.DLL
>>>>>> REGAPI.DLL
>>>>>> RSTRTMGR.DLL
>>>>>> RTUTILS.DLL
>>>>>> SAMCLI.DLL
>>>>>> SAMLIB.DLL
>>>>>> SCECLI.DLL
>>>>>> SECUR32.DLL
>>>>>> SENSAPI.DLL
>>>>>> SETUPAPI.DLL
>>>>>> SHDOCVW.DLL
>>>>>> SHELL32.DLL
>>>>>> SHLWAPI.DLL
>>>>>> SLC.DLL
>>>>>> SPFILEQ.DLL
>>>>>> SPINF.DLL
>>>>>> SPPC.DLL
>>>>>> SRVCLI.DLL
>>>>>> TAPI32.DLL
>>>>>> UIAUTOMATIONCORE.DLL
>>>>>> URLMON.DLL
>>>>>> VAULTCLI.DLL
>>>>>> VERSION.DLL
>>>>>> VPNIKEAPI.DLL
>>>>>> W32TOPL.DLL
>>>>>> WDI.DLL
>>>>>> WEBIO.DLL
>>>>>> WEBSERVICES.DLL
>>>>>> WER.DLL
>>>>>> WERUI.DLL
>>>>>> WINBRAND.DLL
>>>>>> WINDOWSCODECS.DLL
>>>>>> WINHTTP.DLL
>>>>>> WININET.DLL
>>>>>> WINMM.DLL
>>>>>> WINNSI.DLL
>>>>>> WINSCARD.DLL
>>>>>> WINSPOOL.DRV
>>>>>> WINSTA.DLL
>>>>>> WINTRUST.DLL
>>>>>> WKSCLI.DLL
>>>>>> WLANAPI.DLL
>>>>>> WLANUTIL.DLL
>>>>>> WLDAP32.DLL
>>>>>> WS2_32.DLL
>>>>>> WTSAPI32.DLL
>>>>>> XMLLITE.DLL
>>>>>>> -- 
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>> On 12/16/2013 08:02 PM, Pete Brunet wrote:
>>>>>>>> I'm writing a regression test and it is failing trying to load
>>>>>>>> bin\JAWTAccessBridge.DLL.  It was successful in loading
>>>>>>>> bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs
>>>>>>>> are
>>>>>>>> in jre\bin.  Here's the failure:
>>>>>>>>
>>>>>>>> java.lang.UnsatisfiedLinkError:
>>>>>>>> C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Can't find dependent libraries
>>>>>>>>     at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>>>>>>     at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
>>>>>>>>     at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
>>>>>>>>     at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>>>>>>>     at java.lang.System.loadLibrary(System.java:1119)
>>>>>>>>     at JABDLL$4.run(JABDLL.java:116)
>>>>>>>>     at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>>     at JABDLL.foundLegacyDLLs(JABDLL.java:113)
>>>>>>>>     at JABDLL.main(JABDLL.java:67)
>>>>>>>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>>     at
>>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     at
>>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     at java.lang.reflect.Method.invoke(Method.java:483)
>>>>>>>>     at
>>>>>>>> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>>>>>>>>
>>>>>>>>
>>>>>>>>     at java.lang.Thread.run(Thread.java:744)
>>>>>>>>
>>>>>>>> Here's the pertinent code:
>>>>>>>>
>>>>>>>> private static boolean foundLegacyDLLs() {
>>>>>>>>                java.security.AccessController.doPrivileged(
>>>>>>>>                    new java.security.PrivilegedAction() {
>>>>>>>>                        public Object run() {
>>>>>>>>                            System.loadLibrary("JavaAccessBridge");
>>>>>>>>                            return null;
>>>>>>>>                        }
>>>>>>>>                    }, null, new
>>>>>>>> RuntimePermission("loadLibrary.JavaAccessBridge")
>>>>>>>>                );
>>>>>>>>                java.security.AccessController.doPrivileged(
>>>>>>>>                    new java.security.PrivilegedAction() {
>>>>>>>>                        public Object run() {
>>>>>>>>                           
>>>>>>>> System.loadLibrary("JAWTAccessBridge");  //
>>>>>>>> line
>>>>>>>> 116, fails here
>>>>>>>>                            return null;
>>>>>>>>                        }
>>>>>>>>                    }, null, new
>>>>>>>> RuntimePermission("loadLibrary.JAWTAccessBridge")
>>>>>>>>                );
>>>>>>>>                return true;
>>>>>>>>        }
>>>>>>>>
>>>>>>>> Here's the jtreg run:
>>>>>>>>
>>>>>>>> $ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
>>>>>>>> -testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -verbose:summary closed/com/sun/java/accessibility/JABDLL.java
>>>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
>>>>>>>> needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
>>>>>>>> this can be ignored
>>>>>>>> FAILED: closed/com/sun/java/accessibility/JABDLL.java
>>>>>>>> Test results: failed: 1
>>>>>>>> Report written to
>>>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
>>>>>>>>
>>>>>>>> Results written to
>>>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
>>>>>>>> Error: Some tests failed or other problems occurred.
>>>>>>>>
>>>>>>>> Here's the prolog to the test case:
>>>>>>>>
>>>>>>>> /*
>>>>>>>>      * @test
>>>>>>>>      * @summary ...
>>>>>>>>      * @run main JABDLL
>>>>>>>>      */
>>>>>>>>
>>>>>>>> The built image runs fine in normal use, i.e. I can run SwingSet2
>>>>>>>> with
>>>>>>>> the same image so I assume it's something I'm not doing right with
>>>>>>>> respect to jtreg.
>>>>>>>>
>>>>>>>> The dependency walker reports jvm.dll which is in bin\server.  I
>>>>>>>> tried
>>>>>>>> moving that to bin but that didn't help.   Also some Win DLLs were
>>>>>>>> reported most of which start with API-MS-WIN- but I assume those are
>>>>>>>> false negatives.  The sdk image I am testing is 32 bit and the
>>>>>>>> DLL is
>>>>>>>> also 32 bit.  Hopefully it's just something I don't yet understand
>>>>>>>> about
>>>>>>>> jprt, like maybe a missing @ tag in the prolog.
>>>>>>>>
>>>>>>>> Any ideas on how to debug this?
>>>>>>>>
>>>>>>>> Pete
>>>>>>>>
>>>>>>>>


From peter.brunet at oracle.com  Wed Dec 18 12:51:13 2013
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 18 Dec 2013 14:51:13 -0600
Subject: <AWT Dev> Regression test failure loading a DLL
In-Reply-To: <52B1FF29.7090006@oracle.com>
References: <52AF2405.5050107@oracle.com>	<52AF5556.3020004@oracle.com>	<52AF661B.4060602@oracle.com>	<52B051CD.7070306@oracle.com>	<52B09B25.30409@oracle.com>	<52B169B4.102@oracle.com>	<52B1F450.1040903@oracle.com>	<52B1F602.40608@oracle.com>
	<52B1FF29.7090006@oracle.com>
Message-ID: <52B20AC1.10005@oracle.com>

Where is the right place to get a review of my test case?  I'll post it
here a bit later if there's not a better idea.

On 12/18/13 2:01 PM, Pete Brunet wrote:
> On 12/18/13 1:22 PM, Pete Brunet wrote:
>> On 12/18/13 1:15 PM, Pete Brunet wrote:
>>> On 12/18/13 3:24 AM, Artem Ananiev wrote:
>>>> On 12/17/2013 10:42 PM, Pete Brunet wrote:
>>>>> Hi Anthony, Thanks again for the assistance!
>>>>>
>>>>> On 12/17/13 7:29 AM, Anthony Petrov wrote:
>>>>>>> Immediate load in JAWT*, delay load in Java*
>>>>>> Why is that? Can you try re-linking the JAWTAccessBridge.DLL so that
>>>>>> it uses delayed libs loading (which is always a good thing) and see if
>>>>>> this changes anything?
>>>>> Maybe it's a Dependency Walker anomaly?  I got that info from the fact
>>>>> that Dependency Walker shows an hour glass next to the red icon for
>>>>> ole32.dll for Java*.dll but not for ole32.dll for JAWT*.dll.  (Also when
>>>>> I ran it today oleaut32.dll was delay load in both.)  I looked through
>>>>> the ole32.dll entries in the trees for both DLLs and didn't find any
>>>>> differences.
>>>>>
>>>>> When I load JAWT*.dll Dependency Walker reports an error (and some
>>>>> warnings).  If I add bin\server to its search list that error goes away
>>>>> (and the warnings remain).
>>>>>
>>>>> I found the build statements in jdk8\jdk\make\lib\PlatformLibraries.gmk
>>>>> and Java* vs JAWT* are almost the same.  Here is are the statments in
>>>>> the gmk file for JAWT* and Java* with the two significant difference
>>>>> noted.
>>>>>
>>>>> $(call SetupNativeCompilation,BUILD_JAWTACCESSBRIDGE$1, \
>>>>>            LIBRARY = JAWTAccessBridge$1, \
>>>>>            OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>>>>>            SRC := $(ACCESSBRIDGE_SRCDIR), \
>>>>>            INCLUDE_FILES := JAWTAccessBridge.cpp, \ <-- different list
>>>>> for Java*
>>>>>            LANG := C++, \
>>>>>            OPTIMIZATION := LOW, \
>>>>>            CFLAGS := $(CFLAGS_JDKLIB) \
>>>>>                -DACCESSBRIDGE_ARCH_$3, \
>>>>>            LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib
>>>>> gdi32.lib \
>>>>>                winspool.lib jawt.lib comdlg32.lib advapi32.lib
>>>>> shell32.lib \  <-- jawt.lib added
>>>> Let me ask a stupid question: does pre-loading jawt.dll before
>>>> JAWTAccessBridge.dll help?
>>> It didn't help but it's interesting that the failure now happens when
>>> jawt.dll is loaded.
>> Loading awt.dll before jawt.dll before JAWTAccessBridge-32.dll solved
>> the problem.  But why?
> Normally JAWTAccessBridge-32.dll is loaded by this sequence:  the access
> bridge class is loaded by the VM (if the users's
> .accessibility.properties is set up for that), then that class loads
> JAWTAccessBridge-32.dll which I assume then loads jawt.dll which loads
> awt.dll.  The Win dll search algorithm found here:
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx
> looks in the app directory which I assume in the normal case has been
> set to the jre's bin directory.  In the case of running my test case
> under jtreg the app directory and current directory are probably not the
> jre's bin directory.  So I suppose it's OK with respect to what I want
> to accomplish with my test case for me to preload awt.dll and jawt.dll
> in the test case.
>>>>>                ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>>>>>                -subsystem:windows -machine:$2 \
>>>>>                -def:$(ACCESSBRIDGE_SRCDIR)/JAWTAccessBridge.DEF, \
>>>>>            VERSIONINFO_RESOURCE :=
>>>>> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>>>>>            RC_FLAGS := $(RC_FLAGS), \
>>>>>            OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjawtaccessbridge$1, \
>>>>>            DEBUG_SYMBOLS := true)
>>>>>
>>>>>   $(call SetupNativeCompilation,BUILD_JAVAACCESSBRIDGE$1, \
>>>>>            LIBRARY = JavaAccessBridge$1, \
>>>>>            OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>>>>>            SRC := $(ACCESSBRIDGE_SRCDIR), \
>>>>>            INCLUDE_FILES := AccessBridgeATInstance.cpp
>>>>> AccessBridgeDebug.cpp \
>>>>>                AccessBridgeJavaEntryPoints.cpp \
>>>>>                AccessBridgeMessages.cpp JavaAccessBridge.cpp, \
>>>>>            LANG := C++, \
>>>>>            OPTIMIZATION := LOW, \
>>>>>            CFLAGS := $(CFLAGS_JDKLIB) \
>>>>>                -DACCESSBRIDGE_ARCH_$3, \
>>>>>            LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib
>>>>> gdi32.lib \
>>>>>                winspool.lib comdlg32.lib advapi32.lib shell32.lib \
>>>>>                ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>>>>>                -subsystem:windows -machine:$2 \
>>>>>                -def:$(ACCESSBRIDGE_SRCDIR)/JavaAccessBridge.DEF, \
>>>>>            VERSIONINFO_RESOURCE :=
>>>>> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>>>>>            RC_FLAGS := $(RC_FLAGS), \
>>>>>            OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjavaaccessbridge$1, \
>>>>>            DEBUG_SYMBOLS := true)
>>>>>
>>>>> I wonder if the LDFLAGS lists are right.  Dependency Walker shows the
>>>>> first level dependencies as follows:
>>>>> - JAWT*.dll: jawt.dll, msvcr100.dll, kernel32.dll
>>>>> - Java*.dll: msvcr100.dll, kernel32.dll, user32.dll
>>>>> but the LDFLAGS lists are much longer and also both are missing
>>>>> msvcr100.lib
>>>> msvcr100.dll is loaded by Java launcher from JRE/bin directory, so
>>>> it's not a problem.
>>>>
>>>>> I ran the make in debug mode to get more output and the linker flags are
>>>>> the same, except for the former including jawt.lib
>>>>>
>>>>> For JAWT*:
>>>>> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
>>>>> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
>>>>>
>>>>> kernel32.lib user32.lib gdi32.lib winspool.lib jawt.lib comdlg32.lib
>>>>> advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
>>>>> odbccp32.lib -subsystem:windows -machine:I386
>>>>> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JAWTAccessBridge.DEF
>>>>>
>>>>>
>>>>> For Java*:
>>>>> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
>>>>> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
>>>>>
>>>>> kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib
>>>>> shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
>>>>> -subsystem:windows -machine:I386
>>>>> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JavaAccessBridge.DEF
>>>>>
>>>>>
>>>>> Note that some builds have a LDFLAGS_SUFFIX_windows with -DELAYLOAD, but
>>>>> these bridge builds don't.  I'll try adding this after lunch.
>>>>>
>>>>> Regarding the source code JAWTAccessBridge.cpp doesn't load any DLLs.
>>>>> JavaAccessBridge.cpp has a loadlibrary of jawt.dll (and none of the
>>>>> other included source files load DLLs).
>>>>>
>>>>> In the middle of all these details I don't want to loose track of the
>>>>> fact that the problem only occurs when using jtreg.  In normal use there
>>>>> has never been a problem.
>>>>>> Also,
>>>>>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>>> These dependencies are also fine, at least I see the same dlls in the
>>>> list of awt.dll dependencies, and it doesn't cause any troubles.
>>>>
>>>>>> JDK doesn't support WinRT currently. The JAWT* (or any binary in JDK)
>>>>>> just shouldn't be linked against these libraries (and probably other
>>>>>> API-MS-*, too). Where do the dependencies come from? What does your
>>>>>> Makefile do to link the JAWT* lib?
>>>>> The JAWT* questions is answered above.
>>>>>
>>>>> This is the tree I see for the WinRT DLLs you mentioned:
>>>>> javaaccessbridge.dll
>>>>>    user32.dll
>>>>>      advapi32.dll
>>>>>        wintrust.dll
>>>>>          crypt32.dll
>>>>>            userenv.dll
>>>>>              shell32.dll
>>>>>                wininet.dll
>>>>>                  iertutil.dll
>>>>>                    API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL and
>>>>>                    API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>>>>
>>>>> ditto to
>>>>>    shell32.dll
>>>>>      shdocvw.dll
>>>>>        ieframe.dll
>>>>>          mshtml.dll
>>>>>            API-MS-WIN-CORE-WINRT-L1-1-0.DLL and
>>>>>            API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 12/17/2013 12:44 AM, Pete Brunet wrote:
>>>>>>> Hi Anthony, Thanks for helping...
>>>>>>>
>>>>>>> On 12/16/13 1:32 PM, Anthony Petrov wrote:
>>>>>>>> Hi Pete,
>>>>>>>>
>>>>>>>> I see you've already tried the Dependency Walker.
>>>>>>>>
>>>>>>>> 1. Could you please clarify the following: if you compile two
>>>>>>>> lists of
>>>>>>>> dependencies, one for JavaAccessBridge.dll and another for
>>>>>>>> JAWTAccessBridge.DLL, and compare them, are there any differences?
>>>>>>> Differences:
>>>>>>>
>>>>>>> JAWT* has these extras
>>>>>>> jvm.dll - error opening file
>>>>>>> awt.dll - no problem with this and the following
>>>>>>> java.dll
>>>>>>> jawt.dll
>>>>>>> verify.dll
>>>>>>>
>>>>>>> Immediate load in JAWT*, delay load in Java*
>>>>>>> ole32 - colored red, i.e. missing export function required by parent
>>>>>>> module
>>>>>>> oleaut32.dll - no problem
>>>>>>>> 2. If you change the order of loading the libraries, will it fail
>>>>>>>> right away w/o even loading the JavaAccessBridge.dll ?
>>>>>>> yes
>>>>>>>> 3. If the above doesn't help, please post the full list of
>>>>>>>> dependencies for JAWTAccessBridge.DLL as reported by the Dependency
>>>>>>>> Walker.
>>>>>>> Error opening file:
>>>>>>> JVM.DLL
>>>>>>> API-MS-WIN-CORE-COM-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>>>>>> API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
>>>>>>> DCOMP.DLL
>>>>>>> GPSVC.DLL
>>>>>>> IESHIMS.DLL
>>>>>>> Red (missing export function required by parent module):
>>>>>>> API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
>>>>>>> OLE32.DLL
>>>>>>> Red, delay load:
>>>>>>> DWMAPI.DLL
>>>>>>> IEFRAME.DLL
>>>>>>> IMM32.DLL
>>>>>>> MFPLAT.DLL
>>>>>>> NDFAPI.DLL
>>>>>>> USERENV.DLL
>>>>>>> UXTHEME.DLL
>>>>>>> No problems:
>>>>>>> ADVAPI32.DLL
>>>>>>> API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-FILE-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-HEAP-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-IO-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-MISC-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-STRING-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-UTIL-L1-1-0.DLL
>>>>>>> API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
>>>>>>> API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
>>>>>>> API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
>>>>>>> API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
>>>>>>> API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
>>>>>>> API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
>>>>>>> AWT.DLL
>>>>>>> CRYPTBASE.DLL
>>>>>>> GDI32.DLL
>>>>>>> JAVA.DLL
>>>>>>> JAWT.DLL
>>>>>>> JAWTACCESSBRIDGE.DLL
>>>>>>> KERNEL32.DLL
>>>>>>> KERNELBASE.DLL
>>>>>>> LPK.DLL
>>>>>>> MSVCR100.DLL
>>>>>>> MSVCRT.DLL
>>>>>>> NTDLL.DLL
>>>>>>> OLEAUT32.DLL
>>>>>>> RPCRT4.DLL
>>>>>>> SSPICLI.DLL
>>>>>>> USER32.DLL
>>>>>>> USP10.DLL
>>>>>>> VERIFY.DLL
>>>>>>> ACLUI.DLL
>>>>>>> ACTIVEDS.DLL
>>>>>>> ADSLDPC.DLL
>>>>>>> ADVPACK.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
>>>>>>> API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
>>>>>>> APPHELP.DLL
>>>>>>> ATL.DLL
>>>>>>> AUTHZ.DLL
>>>>>>> AVRT.DLL
>>>>>>> BCRYPT.DLL
>>>>>>> BROWCLI.DLL
>>>>>>> CABINET.DLL
>>>>>>> CERTCLI.DLL
>>>>>>> CERTENROLL.DLL
>>>>>>> CFGMGR32.DLL
>>>>>>> CLBCATQ.DLL
>>>>>>> COMCTL32.DLL
>>>>>>> COMCTL32.DLL
>>>>>>> COMDLG32.DLL
>>>>>>> CREDUI.DLL
>>>>>>> CRYPT32.DLL
>>>>>>> CRYPTSP.DLL
>>>>>>> CRYPTUI.DLL
>>>>>>> CSCAPI.DLL
>>>>>>> D2D1.DLL
>>>>>>> D3D11.DLL
>>>>>>> DAVHLPR.DLL
>>>>>>> DBGHELP.DLL
>>>>>>> DEVMGR.DLL
>>>>>>> DEVOBJ.DLL
>>>>>>> DEVRTL.DLL
>>>>>>> DFSCLI.DLL
>>>>>>> DHCPCSVC.DLL
>>>>>>> DHCPCSVC6.DLL
>>>>>>> DNSAPI.DLL
>>>>>>> DRVSTORE.DLL
>>>>>>> DSROLE.DLL
>>>>>>> DUI70.DLL
>>>>>>> DUSER.DLL
>>>>>>> DWRITE.DLL
>>>>>>> DXGI.DLL
>>>>>>> EAPPCFG.DLL
>>>>>>> EAPPPRXY.DLL
>>>>>>> EFSADU.DLL
>>>>>>> EFSUTIL.DLL
>>>>>>> ELSCORE.DLL
>>>>>>> ESENT.DLL
>>>>>>> FMS.DLL
>>>>>>> GDIPLUS.DLL
>>>>>>> GPAPI.DLL
>>>>>>> HLINK.DLL
>>>>>>> IEADVPACK.DLL
>>>>>>> IERTUTIL.DLL
>>>>>>> IEUI.DLL
>>>>>>> IMAGEHLP.DLL
>>>>>>> IMGUTIL.DLL
>>>>>>> INETCOMM.DLL
>>>>>>> IPHLPAPI.DLL
>>>>>>> LINKINFO.DLL
>>>>>>> LOGONCLI.DLL
>>>>>>> MFC42U.DLL
>>>>>>> MLANG.DLL
>>>>>>> MMDEVAPI.DLL
>>>>>>> MPR.DLL
>>>>>>> MPRAPI.DLL
>>>>>>> MPRMSG.DLL
>>>>>>> MSASN1.DLL
>>>>>>> MSCTF.DLL
>>>>>>> MSFEEDS.DLL
>>>>>>> MSHTML.DLL
>>>>>>> MSI.DLL
>>>>>>> MSILTCFG.DLL
>>>>>>> MSIMG32.DLL
>>>>>>> MSLS31.DLL
>>>>>>> MSOERT2.DLL
>>>>>>> MSRATING.DLL
>>>>>>> MSSIGN32.DLL
>>>>>>> NCRYPT.DLL
>>>>>>> NETAPI32.DLL
>>>>>>> NETBIOS.DLL
>>>>>>> NETJOIN.DLL
>>>>>>> NETPLWIZ.DLL
>>>>>>> NETUTILS.DLL
>>>>>>> NEWDEV.DLL
>>>>>>> NORMALIZ.DLL
>>>>>>> NSI.DLL
>>>>>>> NTDSAPI.DLL
>>>>>>> NTSHRUI.DLL
>>>>>>> OCCACHE.DLL
>>>>>>> ODBC32.DLL
>>>>>>> OLEACC.DLL
>>>>>>> OLEDLG.DLL
>>>>>>> ONEX.DLL
>>>>>>> PCWUM.DLL
>>>>>>> POWRPROF.DLL
>>>>>>> PRINTUI.DLL
>>>>>>> PRNTVPT.DLL
>>>>>>> PROFAPI.DLL
>>>>>>> PROPSYS.DLL
>>>>>>> PSAPI.DLL
>>>>>>> PUIAPI.DLL
>>>>>>> RASAPI32.DLL
>>>>>>> RASDLG.DLL
>>>>>>> RASMAN.DLL
>>>>>>> REGAPI.DLL
>>>>>>> RSTRTMGR.DLL
>>>>>>> RTUTILS.DLL
>>>>>>> SAMCLI.DLL
>>>>>>> SAMLIB.DLL
>>>>>>> SCECLI.DLL
>>>>>>> SECUR32.DLL
>>>>>>> SENSAPI.DLL
>>>>>>> SETUPAPI.DLL
>>>>>>> SHDOCVW.DLL
>>>>>>> SHELL32.DLL
>>>>>>> SHLWAPI.DLL
>>>>>>> SLC.DLL
>>>>>>> SPFILEQ.DLL
>>>>>>> SPINF.DLL
>>>>>>> SPPC.DLL
>>>>>>> SRVCLI.DLL
>>>>>>> TAPI32.DLL
>>>>>>> UIAUTOMATIONCORE.DLL
>>>>>>> URLMON.DLL
>>>>>>> VAULTCLI.DLL
>>>>>>> VERSION.DLL
>>>>>>> VPNIKEAPI.DLL
>>>>>>> W32TOPL.DLL
>>>>>>> WDI.DLL
>>>>>>> WEBIO.DLL
>>>>>>> WEBSERVICES.DLL
>>>>>>> WER.DLL
>>>>>>> WERUI.DLL
>>>>>>> WINBRAND.DLL
>>>>>>> WINDOWSCODECS.DLL
>>>>>>> WINHTTP.DLL
>>>>>>> WININET.DLL
>>>>>>> WINMM.DLL
>>>>>>> WINNSI.DLL
>>>>>>> WINSCARD.DLL
>>>>>>> WINSPOOL.DRV
>>>>>>> WINSTA.DLL
>>>>>>> WINTRUST.DLL
>>>>>>> WKSCLI.DLL
>>>>>>> WLANAPI.DLL
>>>>>>> WLANUTIL.DLL
>>>>>>> WLDAP32.DLL
>>>>>>> WS2_32.DLL
>>>>>>> WTSAPI32.DLL
>>>>>>> XMLLITE.DLL
>>>>>>>> -- 
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 12/16/2013 08:02 PM, Pete Brunet wrote:
>>>>>>>>> I'm writing a regression test and it is failing trying to load
>>>>>>>>> bin\JAWTAccessBridge.DLL.  It was successful in loading
>>>>>>>>> bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs
>>>>>>>>> are
>>>>>>>>> in jre\bin.  Here's the failure:
>>>>>>>>>
>>>>>>>>> java.lang.UnsatisfiedLinkError:
>>>>>>>>> C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Can't find dependent libraries
>>>>>>>>>     at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>>>>>>>     at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
>>>>>>>>>     at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
>>>>>>>>>     at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>>>>>>>>     at java.lang.System.loadLibrary(System.java:1119)
>>>>>>>>>     at JABDLL$4.run(JABDLL.java:116)
>>>>>>>>>     at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>>>     at JABDLL.foundLegacyDLLs(JABDLL.java:113)
>>>>>>>>>     at JABDLL.main(JABDLL.java:67)
>>>>>>>>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>>>     at
>>>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     at
>>>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     at java.lang.reflect.Method.invoke(Method.java:483)
>>>>>>>>>     at
>>>>>>>>> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     at java.lang.Thread.run(Thread.java:744)
>>>>>>>>>
>>>>>>>>> Here's the pertinent code:
>>>>>>>>>
>>>>>>>>> private static boolean foundLegacyDLLs() {
>>>>>>>>>                java.security.AccessController.doPrivileged(
>>>>>>>>>                    new java.security.PrivilegedAction() {
>>>>>>>>>                        public Object run() {
>>>>>>>>>                            System.loadLibrary("JavaAccessBridge");
>>>>>>>>>                            return null;
>>>>>>>>>                        }
>>>>>>>>>                    }, null, new
>>>>>>>>> RuntimePermission("loadLibrary.JavaAccessBridge")
>>>>>>>>>                );
>>>>>>>>>                java.security.AccessController.doPrivileged(
>>>>>>>>>                    new java.security.PrivilegedAction() {
>>>>>>>>>                        public Object run() {
>>>>>>>>>                           
>>>>>>>>> System.loadLibrary("JAWTAccessBridge");  //
>>>>>>>>> line
>>>>>>>>> 116, fails here
>>>>>>>>>                            return null;
>>>>>>>>>                        }
>>>>>>>>>                    }, null, new
>>>>>>>>> RuntimePermission("loadLibrary.JAWTAccessBridge")
>>>>>>>>>                );
>>>>>>>>>                return true;
>>>>>>>>>        }
>>>>>>>>>
>>>>>>>>> Here's the jtreg run:
>>>>>>>>>
>>>>>>>>> $ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
>>>>>>>>> -testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -verbose:summary closed/com/sun/java/accessibility/JABDLL.java
>>>>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
>>>>>>>>> needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
>>>>>>>>> this can be ignored
>>>>>>>>> FAILED: closed/com/sun/java/accessibility/JABDLL.java
>>>>>>>>> Test results: failed: 1
>>>>>>>>> Report written to
>>>>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
>>>>>>>>>
>>>>>>>>> Results written to
>>>>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
>>>>>>>>> Error: Some tests failed or other problems occurred.
>>>>>>>>>
>>>>>>>>> Here's the prolog to the test case:
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>      * @test
>>>>>>>>>      * @summary ...
>>>>>>>>>      * @run main JABDLL
>>>>>>>>>      */
>>>>>>>>>
>>>>>>>>> The built image runs fine in normal use, i.e. I can run SwingSet2
>>>>>>>>> with
>>>>>>>>> the same image so I assume it's something I'm not doing right with
>>>>>>>>> respect to jtreg.
>>>>>>>>>
>>>>>>>>> The dependency walker reports jvm.dll which is in bin\server.  I
>>>>>>>>> tried
>>>>>>>>> moving that to bin but that didn't help.   Also some Win DLLs were
>>>>>>>>> reported most of which start with API-MS-WIN- but I assume those are
>>>>>>>>> false negatives.  The sdk image I am testing is 32 bit and the
>>>>>>>>> DLL is
>>>>>>>>> also 32 bit.  Hopefully it's just something I don't yet understand
>>>>>>>>> about
>>>>>>>>> jprt, like maybe a missing @ tag in the prolog.
>>>>>>>>>
>>>>>>>>> Any ideas on how to debug this?
>>>>>>>>>
>>>>>>>>> Pete
>>>>>>>>>
>>>>>>>>>


From james.graham at oracle.com  Wed Dec 18 14:02:43 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 18 Dec 2013 14:02:43 -0800
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52B16A18.4060301@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com> <52B16A18.4060301@oracle.com>
Message-ID: <52B21B83.4090209@oracle.com>

Hi Anton,

I don't know enough about the overall architecture yet to be too 
specific about possible solutions at this point.  Here are some 
questions that I still don't know the answer to...

- I'm assuming that Swing gets its back buffer from the 
getOffscreenBuffer call because that was what you modified to return a 
HiDPI image.  When Swing calls it internally, does it ever leak that 
instance?  Could it use a different API to get that back buffer so that 
the public API doesn't change?

- The method returns Image.  If worse comes to worst then we could try 
to hide the identity of the BI that gets returned, but that would be an 
awkward wrapper object, so hopefully a different solution works.

- Do we need to provide "automatically scaled image buffers" to 
developers that request one?  I'm guessing that the standard practice 
for DB in Swing is that the Swing code manages the image used for the 
back buffer, but does the developer ever get involved in that process 
such that we need to have magically scaled images in their hands?

- My impression was that there is some code in Swing that allocates the 
backbuffer, tells the Swing tree of JComponents to render into it, then 
draws that image to the screen.  Logically it might look something like 
this:

backbuffer = createBackBuffer(w, h);
// ...
comp.paint(backbuffer.getGraphics());
// ...
screengraphics.drawImage(backbuffer, x, y, null);

(though those lines of code may be spread across a number of methods for 
all I know)

Instead if it did this:

backbuffer = createBackBuffer(w*scale, h*scale);
// backbuffer.getWidth,Height() return w*scale, h*scale, but we don't care
// ...
Graphics g = backbuffer.getGraphics();
g.scale(scale, scale);
comp.paint(g);
// ...
// this call forces the logical size of the image without any special
// processing or instance recognition in SG2D
screengraphics.drawImage(backbuffer, x, y, w, h, null);

then we don't need any fancy wrappers or anything.  This doesn't solve 
any "manual double buffering" that a developer would do, though, but it 
evades return values from public methods that have "mismatched 
BufferedImage objects"...

			...jim

On 12/18/13 1:25 AM, Anton V. Tarasov wrote:
> Hi Jim,
>
> Thanks for noticing (sorry, but I simply forgot to check we don't export
> the buffer...) What can we do about that? I have the following thoughts:
>
> 1) We can warn developers to be ready for a HiDPI raster when they call
> that method under the following conditions: 1) the interop mode, 2)
> MacOSX 3) a Retina display.
> 2) In case the method is called, we can create a "shadow  buffer" and
> start to sync it with the main buffer. The main buffer will be scaled to
> the shadow buffer on every repaint cycle.
> 3) We can introduce an internal property which will switch on/off the
> 2nd scenario. For instance, a developer may ask for the buffer and don't
> bother about its hidpi raster.
>
> Yes, I understand the solutions are far from perfect, but please take
> into account, the interop is a special mode where we (and developers)
> should be ready for compromises...
>
> What do you think? Do you have any better solutions in mind?
>
> Thanks,
> Anton.
>
>
> On 18.12.2013 5:03, Jim Graham wrote:
>> Hi Anton,
>>
>> javax.swing.RepaintManager.getOffscreenBuffer is a public method that
>> can now return one of the new HiDPI offscreen images which is a
>> subclass of BufferedImage.  This was what I was worried about in terms
>> of one of these internal double buffers leaking to developer code.  If
>> they test the image using instanceof they will see that it is a
>> BufferdImage and they may try to dig out the raster and get confused...
>>
>>             ...jim
>>
>> On 12/17/13 10:21 AM, Anton V. Tarasov wrote:
>>> Hi all,
>>>
>>> Please look at the new version:
>>>
>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2
>>>
>>> It contains the following changes:
>>>
>>> - All the scale related stuff is moved to the new class:
>>> OffScreenHiDPIImage.java
>>>
>>> - JViewport and RepaintManager no longer cache buffers.
>>>
>>> - JLightweightFrame has new method: createHiDPIImage(w, h).
>>>
>>> - JViewport, RepaintManager and AbstractRegionPainter goes the new path
>>> to create a HiDPI buffered image.
>>>
>>> - A new internal property is added: "swing.jlf.hidpiImageEnabled". False
>>> by default. It makes JLF.createImage(w, h) forward the call to
>>> JLF.createHiDPIImage(w, h). This can be used by a third party code in
>>> case it creates a buffered image via Component.createImage(w, h) and
>>> uses the image so that it can benefit from being a HiDPI image on a
>>> Retina display.
>>>
>>> For instance, SwingSet2 has an animating Bezier curve demo. Switching
>>> the property on makes the curve auto scale smoothly. Please, look at the
>>> screenshots:
>>>
>>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png
>>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png
>>>
>>> - SunGraphics2D now draws a HiDPI buffered image the same way it draws a
>>> VolatileImage.
>>>
>>> - I've removed the copyArea() method from the BufImgSurfaceData, and
>>> modified the original version. The only question I have is: do I need to
>>> check for "instanceof OffScreenHiDPIImage.SurfaceData" in case when
>>> "transformState == TRANSFORM_TRANSLATESCALE"? If this method is invoked
>>> with some other SD, and the transform is SCALE, will it do the job with
>>> the coordinates conversion done?
>>>
>>> - I've left the new methods in FramePeer default... May yet we implement
>>> them in other peers when we really need it?
>>>
>>> - CPlatformLWWindow.getGraphicsDevice() checks for an intersection +
>>> scale. This heuristic actually may fail when a Window is moved b/w three
>>> or four displays so that it intersects them all at some time. JFX will
>>> set a new scale factor in between and AWT may pick up a wrong device. I
>>> don't know any simple solution for that. For two monitors this will
>>> work.
>>>
>>> Thanks,
>>> Anton.
>

From james.graham at oracle.com  Wed Dec 18 14:21:24 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 18 Dec 2013 14:21:24 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [9] Review Request: JDK-8029250
 [macosx] There is no tray icon shown in the system tray area when case
 starts
In-Reply-To: <2AA389C5-8723-49CE-8054-BC778BD3CDC4@oracle.com>
References: <2AA389C5-8723-49CE-8054-BC778BD3CDC4@oracle.com>
Message-ID: <52B21FE4.6060503@oracle.com>

Hi Petr,

Have you verified that if someone draws an animated GIF and then later 
returns false from the observer that the associated ImageLoader thread 
goes away?  I think the dispose() method had a side effect of allowing 
the thread to go away and if you don't call it then the ImageLoader 
threads that serve the displayers of an animated GIF may run forever 
once triggered...

			...jim

On 12/18/13 6:01 AM, Petr Pchelko wrote:
> Hello, AWT and 2D teams.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8029250
> It also resolves the issue:
> https://bugs.openjdk.java.net/browse/JDK-6740321
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8029250/webrev/
>
> The problem:
> In AWT we use a MediaTracker to wait for the tray icon loading. However, if the TrayIcon is an animated gif the following happen:
> The MediaTracker installs an ImageObserver to an image and starts loading. After the first frame is loaded (and it's really all we need)
> the media tracker correctly exits and removes it's ImageObserver. And as it's the only observer the checkConsumption is called in an
> ImageRepresentation. As the availinfo is just FRAMEBITS the successfully loaded frame was immediately disposed and AWT failed
> to draw a tray icon.
>
> With best regards. Petr.
>

From james.graham at oracle.com  Wed Dec 18 16:12:23 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 18 Dec 2013 16:12:23 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [9] Review Request: JDK-8029250
 [macosx] There is no tray icon shown in the system tray area when case
 starts
In-Reply-To: <52B21FE4.6060503@oracle.com>
References: <2AA389C5-8723-49CE-8054-BC778BD3CDC4@oracle.com>
	<52B21FE4.6060503@oracle.com>
Message-ID: <52B239E7.1000408@oracle.com>

Also, currently we render animated GIFs by continually decoding them, 
which is a CPU waste, but it does save a little on memory.  That design 
also complicates this MediaTracker issue since the tracking and the 
loading and the frames are all equated under the covers in a way that 
makes it hard for MT to say "I'm OK now, but don't stop loading on my 
account" while at the same time allowing our ImageLoader threads to have 
some metric that lets them know when to stop decoding the GIF.  The MT 
also can't distinguish between frames that happen while still loading 
the file and those that happen after the file is loaded and are just 
repeating.

Given the relatively modest savings in memory, I think it might be 
better to find a way to decode every frame once and keep it around in 
the ToolkitImage, and then use just a simple "time to render the next 
frame" mechanism to periodically call the imageUpdate methods and switch 
to the next decoded frame.  If we moved to such a system, then this 
particular bug may have an alternate (and possibly easier) way to fix it 
since it wouldn't be side effecting the loading of images to trigger 
frame repainting and MT notices.  But...

Another complication is that animated GIFs send FRAMEBITS on every frame 
even if it is a repeat until the properties say that the animation is 
over and only then do they send ALLBITS.  As a result, MT has a choice 
between ending its interest at the first frame (as it currently does 
which causes us to dispose() internally), keeping interest forever which 
might turn into a long term CPU leak and means it will never answer 
"fully loaded now", or perhaps guessing at the number of frames?  There 
is no good answer there for MT.  If we had a way to communicate that the 
multi-frame image had loaded all of its frames and was now "fully 
loaded" even though it was still animating, then MT could use that 
instead - but that would involve new ImageObserver API - perhaps a new 
bit meaning "ALLFRAMESLOADED" that can get tacked on to FRAMEBITS, but 
doesn't mean "ALLBITS" (since ALLBITS currently means the animation has 
reached its end).  Even then, how does a MT know the difference between 
an image loader that supports this convention and one that doesn't? 
Perhaps "FRAMEBITS | NOTALLFRAMESLOADED" could mean the opposite (and 
would only be used for cases of a limited number of frames like an 
animated GIF, not cases where a custom Producer might produce an 
infinite number of frames).  MT would then unregister on the first 
FRAMEBITS that did not have NOTALLFRAMESLOADED or on the first ALLBITS?

(Note to self "NOTALLFRAMESLOADED" is a bad name for a new flag...)

			...jim

On 12/18/13 2:21 PM, Jim Graham wrote:
> Hi Petr,
>
> Have you verified that if someone draws an animated GIF and then later
> returns false from the observer that the associated ImageLoader thread
> goes away?  I think the dispose() method had a side effect of allowing
> the thread to go away and if you don't call it then the ImageLoader
> threads that serve the displayers of an animated GIF may run forever
> once triggered...
>
>              ...jim
>
> On 12/18/13 6:01 AM, Petr Pchelko wrote:
>> Hello, AWT and 2D teams.
>>
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8029250
>> It also resolves the issue:
>> https://bugs.openjdk.java.net/browse/JDK-6740321
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8029250/webrev/
>>
>> The problem:
>> In AWT we use a MediaTracker to wait for the tray icon loading.
>> However, if the TrayIcon is an animated gif the following happen:
>> The MediaTracker installs an ImageObserver to an image and starts
>> loading. After the first frame is loaded (and it's really all we need)
>> the media tracker correctly exits and removes it's ImageObserver. And
>> as it's the only observer the checkConsumption is called in an
>> ImageRepresentation. As the availinfo is just FRAMEBITS the
>> successfully loaded frame was immediately disposed and AWT failed
>> to draw a tray icon.
>>
>> With best regards. Petr.
>>

From petr.pchelko at oracle.com  Wed Dec 18 23:49:22 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 19 Dec 2013 11:49:22 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7159566 The choice positioned
	in the top of applet when clicking the choice.
In-Reply-To: <52B1AB3B.3060907@oracle.com>
References: <642D9E27-4144-49A7-A70F-3CCFC4A02E06@oracle.com>
	<52B1AB3B.3060907@oracle.com>
Message-ID: <8619740B-F033-43BA-90FD-1AB464D3D99D@oracle.com>

Hello, Anthony, Sergey.

Thank you for the review.
The new version could be found here:
http://cr.openjdk.java.net/~pchelko/9/7159566/webrev.01/

I've fixed it according to your comments.

With best regards. Petr.

On 18.12.2013, at 18:03, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Petr.
> The fix looks good. I have 2 suggestions :
> 1 LWChoicePeer.this prefix is unnecessary here?
> 2 Can you add a small description about this code as a comment?
> Thanks.
> On 18.12.2013 13:54, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-7159566
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/7159566/webrev/
>> 
>> The problem: when showing the choice popup we need to use a choice as an invoker to process grab correctly. That's why we have the piece of code I'm fixing.
>> However, we also need to set a correct location of the popup. A 'heavy' getLocationOnScreen is used because the choice might have already been moved by the
>> window manager by this point to fit the screen and it's the only public way to get the location of the popup menu.
>> 
>> The added test checks that there's no popup on the top of the window by clicking there.
>> 
>> With best regards. Petr.
> 
> 
> -- 
> Best regards, Sergey.
> 


From petr.pchelko at oracle.com  Thu Dec 19 00:06:53 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 19 Dec 2013 12:06:53 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8024185 [macosx] Fullscreen
	button freezes application when started with -splash
In-Reply-To: <52AF4EC9.5020109@oracle.com>
References: <6CF001F6-C0B0-4363-9798-4A208981AD55@oracle.com>
	<52AF4EC9.5020109@oracle.com>
Message-ID: <E0A024C6-F39B-4037-9FA3-E1DC56B9984F@oracle.com>

Hello, Anthony.

Thank you for the review.

Actually we have quite a lot of binary images in tests, but in this particular case the image could be generated on the fly.
Please review the updated version of the fix:
http://cr.openjdk.java.net/~pchelko/9/8024185/webrev.01/

Only test test is changed. We now generate an image for the splashscreen on the fly.

With best regards. Petr.

On 16.12.2013, at 23:04, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Petr, Phil,
> 
> The fix looks fine to me. However, I'm not sure we want to add binary files to the repo, no matter how good they are from "legal" perspective.
> 
> 
> Phil: what do you think about .png files in tests?
> 
> 
> --
> best regards,
> Anthony
> 
> On 12/16/2013 12:36 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8024185
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8024185/webrev/
>> The fix also resolves the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8009203
>> 
>> The problem:
>> When showing the splash screen the NSApplicationAWT runAWTLoopWithApp: was invoked from within the dispatch_async.
>> This is a blocking method, so it blocked the main dispatch queue which is used in Cocoa internally. So we've got different bugs.
>> The fix replaces the Grand Central Dispatch API with the JNFRunLoop performOnMainThreadWaiting which is used in other places in splashscreen.
>> 
>> The test verifies that the native FS support works after showing the splashscreen. Mac OS X specific APIs are accessed with reflection, so the test is compilable on other platforms.
>> The test.png is an image added to the test folder, it's not in the webrev as it does not support binary file diffs. I took the image from an existing 2d open test, so it should be fine from the legal point of view.
>> 
>> With best regards. Petr.
>> 


From anthony.petrov at oracle.com  Thu Dec 19 01:50:35 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 19 Dec 2013 13:50:35 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7159566 The choice positioned
 in the top of applet when clicking the choice.
In-Reply-To: <8619740B-F033-43BA-90FD-1AB464D3D99D@oracle.com>
References: <642D9E27-4144-49A7-A70F-3CCFC4A02E06@oracle.com>
	<52B1AB3B.3060907@oracle.com>
	<8619740B-F033-43BA-90FD-1AB464D3D99D@oracle.com>
Message-ID: <52B2C16B.4000805@oracle.com>

Looks fine to me. Thanks.

--
best regards,
Anthony

On 12/19/2013 11:49 AM, Petr Pchelko wrote:
> Hello, Anthony, Sergey.
>
> Thank you for the review.
> The new version could be found here:
> http://cr.openjdk.java.net/~pchelko/9/7159566/webrev.01/
>
> I've fixed it according to your comments.
>
> With best regards. Petr.
>
> On 18.12.2013, at 18:03, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Petr.
>> The fix looks good. I have 2 suggestions :
>> 1 LWChoicePeer.this prefix is unnecessary here?
>> 2 Can you add a small description about this code as a comment?
>> Thanks.
>> On 18.12.2013 13:54, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-7159566
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/7159566/webrev/
>>>
>>> The problem: when showing the choice popup we need to use a choice as an invoker to process grab correctly. That's why we have the piece of code I'm fixing.
>>> However, we also need to set a correct location of the popup. A 'heavy' getLocationOnScreen is used because the choice might have already been moved by the
>>> window manager by this point to fit the screen and it's the only public way to get the location of the popup menu.
>>>
>>> The added test checks that there's no popup on the top of the window by clicking there.
>>>
>>> With best regards. Petr.
>>
>>
>> --
>> Best regards, Sergey.
>>
>

From anthony.petrov at oracle.com  Thu Dec 19 01:53:16 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 19 Dec 2013 13:53:16 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8024185 [macosx] Fullscreen
 button freezes application when started with -splash
In-Reply-To: <E0A024C6-F39B-4037-9FA3-E1DC56B9984F@oracle.com>
References: <6CF001F6-C0B0-4363-9798-4A208981AD55@oracle.com>
	<52AF4EC9.5020109@oracle.com>
	<E0A024C6-F39B-4037-9FA3-E1DC56B9984F@oracle.com>
Message-ID: <52B2C20C.7000805@oracle.com>

Looks great. Thank you!

I suppose we might even want to put the GenerateTestImage.java file to 
the test/java/awt/SplashScreen/ directory so that we could use it for 
other splash screen tests in the future.

--
best regards,
Anthony

On 12/19/2013 12:06 PM, Petr Pchelko wrote:
> Hello, Anthony.
>
> Thank you for the review.
>
> Actually we have quite a lot of binary images in tests, but in this particular case the image could be generated on the fly.
> Please review the updated version of the fix:
> http://cr.openjdk.java.net/~pchelko/9/8024185/webrev.01/
>
> Only test test is changed. We now generate an image for the splashscreen on the fly.
>
> With best regards. Petr.
>
> On 16.12.2013, at 23:04, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hi Petr, Phil,
>>
>> The fix looks fine to me. However, I'm not sure we want to add binary files to the repo, no matter how good they are from "legal" perspective.
>>
>>
>> Phil: what do you think about .png files in tests?
>>
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/16/2013 12:36 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8024185
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8024185/webrev/
>>> The fix also resolves the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8009203
>>>
>>> The problem:
>>> When showing the splash screen the NSApplicationAWT runAWTLoopWithApp: was invoked from within the dispatch_async.
>>> This is a blocking method, so it blocked the main dispatch queue which is used in Cocoa internally. So we've got different bugs.
>>> The fix replaces the Grand Central Dispatch API with the JNFRunLoop performOnMainThreadWaiting which is used in other places in splashscreen.
>>>
>>> The test verifies that the native FS support works after showing the splashscreen. Mac OS X specific APIs are accessed with reflection, so the test is compilable on other platforms.
>>> The test.png is an image added to the test folder, it's not in the webrev as it does not support binary file diffs. I took the image from an existing 2d open test, so it should be fine from the legal point of view.
>>>
>>> With best regards. Petr.
>>>
>

From petr.pchelko at oracle.com  Thu Dec 19 01:58:00 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 19 Dec 2013 13:58:00 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8024185 [macosx] Fullscreen
	button freezes application when started with -splash
In-Reply-To: <52B2C20C.7000805@oracle.com>
References: <6CF001F6-C0B0-4363-9798-4A208981AD55@oracle.com>
	<52AF4EC9.5020109@oracle.com>
	<E0A024C6-F39B-4037-9FA3-E1DC56B9984F@oracle.com>
	<52B2C20C.7000805@oracle.com>
Message-ID: <05CD51A0-5D6F-4667-BAD4-D69E8B9912FC@oracle.com>

Hello, Anthony.

> I suppose we might even want to put the GenerateTestImage.java file to the test/java/awt/SplashScreen/ directory so that we could use it for other splash screen tests in the future.
Sure. I'll do that prior to the push.

With best regards. Petr.

On 19.12.2013, at 13:53, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Looks great. Thank you!
> 
> I suppose we might even want to put the GenerateTestImage.java file to the test/java/awt/SplashScreen/ directory so that we could use it for other splash screen tests in the future.
> 
> --
> best regards,
> Anthony
> 
> On 12/19/2013 12:06 PM, Petr Pchelko wrote:
>> Hello, Anthony.
>> 
>> Thank you for the review.
>> 
>> Actually we have quite a lot of binary images in tests, but in this particular case the image could be generated on the fly.
>> Please review the updated version of the fix:
>> http://cr.openjdk.java.net/~pchelko/9/8024185/webrev.01/
>> 
>> Only test test is changed. We now generate an image for the splashscreen on the fly.
>> 
>> With best regards. Petr.
>> 
>> On 16.12.2013, at 23:04, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>> 
>>> Hi Petr, Phil,
>>> 
>>> The fix looks fine to me. However, I'm not sure we want to add binary files to the repo, no matter how good they are from "legal" perspective.
>>> 
>>> 
>>> Phil: what do you think about .png files in tests?
>>> 
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 12/16/2013 12:36 PM, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>> 
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8024185
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/9/8024185/webrev/
>>>> The fix also resolves the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8009203
>>>> 
>>>> The problem:
>>>> When showing the splash screen the NSApplicationAWT runAWTLoopWithApp: was invoked from within the dispatch_async.
>>>> This is a blocking method, so it blocked the main dispatch queue which is used in Cocoa internally. So we've got different bugs.
>>>> The fix replaces the Grand Central Dispatch API with the JNFRunLoop performOnMainThreadWaiting which is used in other places in splashscreen.
>>>> 
>>>> The test verifies that the native FS support works after showing the splashscreen. Mac OS X specific APIs are accessed with reflection, so the test is compilable on other platforms.
>>>> The test.png is an image added to the test folder, it's not in the webrev as it does not support binary file diffs. I took the image from an existing 2d open test, so it should be fine from the legal point of view.
>>>> 
>>>> With best regards. Petr.
>>>> 
>> 


From alexander.zvegintsev at oracle.com  Thu Dec 19 02:46:39 2013
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 19 Dec 2013 14:46:39 +0400
Subject: <AWT Dev> [9] setMaximumSize() and setMaximizedBounds()
Message-ID: <52B2CE8F.1050205@oracle.com>

Hello AWT team,

I am currently looking at JDK-6464548 issue[1], and as you can see in 
javadoc[2]
we have only setMinimumSize() implemented in java.awt.Window and 
setMaximumSize() is not implemented.

So my question is about how setMaximumSize() (and setMinimumSize()) 
should interfere with setMaximizedBounds()[3]?

I see several options here:

1. setMaximizedBounds() refers to a different state and does not depend 
on setMaximumSize() and setMinimumSize()
2. setMaximizedBounds() respects setMaximumSize() and setMinimumSize(). 
If the window is maximized and maximized
bounds does not conform with maximum or minimum size then window will 
shrunk or enlarge to honor these sizes.
3. If maximum size is set then we deny window maximize operation and 
setMaximizedBounds() have no effect.

What do you think?

[1] https://bugs.openjdk.java.net/browse/JDK-6464548
[2] 
http://docs.oracle.com/javase/7/docs/api/java/awt/Window.html#setMinimumSize(java.awt.Dimension)
[3] 
http://docs.oracle.com/javase/7/docs/api/java/awt/Frame.html#setMaximizedBounds(java.awt.Rectangle)


-- 
Thanks,

Alexander.


From artem.ananiev at oracle.com  Thu Dec 19 03:58:38 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Thu, 19 Dec 2013 15:58:38 +0400
Subject: <AWT Dev> [9] setMaximumSize() and setMaximizedBounds()
In-Reply-To: <52B2CE8F.1050205@oracle.com>
References: <52B2CE8F.1050205@oracle.com>
Message-ID: <52B2DF6E.4000400@oracle.com>


On 12/19/2013 2:46 PM, Alexander Zvegintsev wrote:
> Hello AWT team,
>
> I am currently looking at JDK-6464548 issue[1], and as you can see in
> javadoc[2]
> we have only setMinimumSize() implemented in java.awt.Window and
> setMaximumSize() is not implemented.
>
> So my question is about how setMaximumSize() (and setMinimumSize())
> should interfere with setMaximizedBounds()[3]?
>
> I see several options here:
>
> 1. setMaximizedBounds() refers to a different state and does not depend
> on setMaximumSize() and setMinimumSize()
> 2. setMaximizedBounds() respects setMaximumSize() and setMinimumSize().
> If the window is maximized and maximized
> bounds does not conform with maximum or minimum size then window will
> shrunk or enlarge to honor these sizes.
> 3. If maximum size is set then we deny window maximize operation and
> setMaximizedBounds() have no effect.
>
> What do you think?

I would vote for #2 or #3. #3 seems to be slightly better than #2, 
because to implement #2 we'll need to track, what was called first, 
setMaximumSize() or setMaximizedBounds(). Another problem is that if we 
restrict the maximized bounds to conform to minimum/maximum size, when a 
window is maximized it won't occupy the right place as requested by the 
application. In other words, I think that in case #2 maximized bounds 
feature is broken anyway, so it doesn't make sense to allow window 
maximization at all (which is exactly #3).

Thanks,

Artem

> [1] https://bugs.openjdk.java.net/browse/JDK-6464548
> [2]
> http://docs.oracle.com/javase/7/docs/api/java/awt/Window.html#setMinimumSize(java.awt.Dimension)
>
> [3]
> http://docs.oracle.com/javase/7/docs/api/java/awt/Frame.html#setMaximizedBounds(java.awt.Rectangle)
>
>
>

From Sergey.Bylokhov at oracle.com  Thu Dec 19 04:11:57 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 19 Dec 2013 16:11:57 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7159566 The choice positioned
 in the top of applet when clicking the choice.
In-Reply-To: <8619740B-F033-43BA-90FD-1AB464D3D99D@oracle.com>
References: <642D9E27-4144-49A7-A70F-3CCFC4A02E06@oracle.com>
	<52B1AB3B.3060907@oracle.com>
	<8619740B-F033-43BA-90FD-1AB464D3D99D@oracle.com>
Message-ID: <52B2E28D.6030808@oracle.com>

Hi , Petr.
The fix looks fine.
ps:

  174 if (popupMenu != null && popupMenu.getInvoker() !=*LWChoicePeer.this.getTarget()*) {
  180     popupMenu.show(*getTarget()*, loc.x, loc.y);



On 19.12.2013 11:49, Petr Pchelko wrote:
> Hello, Anthony, Sergey.
>
> Thank you for the review.
> The new version could be found here:
> http://cr.openjdk.java.net/~pchelko/9/7159566/webrev.01/
>
> I've fixed it according to your comments.
>
> With best regards. Petr.
>
> On 18.12.2013, at 18:03, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Petr.
>> The fix looks good. I have 2 suggestions :
>> 1 LWChoicePeer.this prefix is unnecessary here?
>> 2 Can you add a small description about this code as a comment?
>> Thanks.
>> On 18.12.2013 13:54, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-7159566
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/7159566/webrev/
>>>
>>> The problem: when showing the choice popup we need to use a choice as an invoker to process grab correctly. That's why we have the piece of code I'm fixing.
>>> However, we also need to set a correct location of the popup. A 'heavy' getLocationOnScreen is used because the choice might have already been moved by the
>>> window manager by this point to fit the screen and it's the only public way to get the location of the popup menu.
>>>
>>> The added test checks that there's no popup on the top of the window by clicking there.
>>>
>>> With best regards. Petr.
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131219/12070cd1/attachment.html 

From Sergey.Bylokhov at oracle.com  Thu Dec 19 04:16:15 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 19 Dec 2013 16:16:15 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8024185 [macosx] Fullscreen
 button freezes application when started with -splash
In-Reply-To: <05CD51A0-5D6F-4667-BAD4-D69E8B9912FC@oracle.com>
References: <6CF001F6-C0B0-4363-9798-4A208981AD55@oracle.com>
	<52AF4EC9.5020109@oracle.com>
	<E0A024C6-F39B-4037-9FA3-E1DC56B9984F@oracle.com>
	<52B2C20C.7000805@oracle.com>
	<05CD51A0-5D6F-4667-BAD4-D69E8B9912FC@oracle.com>
Message-ID: <52B2E38F.9090009@oracle.com>

Hi, Petr.
The fix looks good.

On 19.12.2013 13:58, Petr Pchelko wrote:
> Hello, Anthony.
>
>> I suppose we might even want to put the GenerateTestImage.java file to the test/java/awt/SplashScreen/ directory so that we could use it for other splash screen tests in the future.
> Sure. I'll do that prior to the push.
>
> With best regards. Petr.
>
> On 19.12.2013, at 13:53, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Looks great. Thank you!
>>
>> I suppose we might even want to put the GenerateTestImage.java file to the test/java/awt/SplashScreen/ directory so that we could use it for other splash screen tests in the future.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/19/2013 12:06 PM, Petr Pchelko wrote:
>>> Hello, Anthony.
>>>
>>> Thank you for the review.
>>>
>>> Actually we have quite a lot of binary images in tests, but in this particular case the image could be generated on the fly.
>>> Please review the updated version of the fix:
>>> http://cr.openjdk.java.net/~pchelko/9/8024185/webrev.01/
>>>
>>> Only test test is changed. We now generate an image for the splashscreen on the fly.
>>>
>>> With best regards. Petr.
>>>
>>> On 16.12.2013, at 23:04, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>
>>>> Hi Petr, Phil,
>>>>
>>>> The fix looks fine to me. However, I'm not sure we want to add binary files to the repo, no matter how good they are from "legal" perspective.
>>>>
>>>>
>>>> Phil: what do you think about .png files in tests?
>>>>
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 12/16/2013 12:36 PM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>>
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8024185
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8024185/webrev/
>>>>> The fix also resolves the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8009203
>>>>>
>>>>> The problem:
>>>>> When showing the splash screen the NSApplicationAWT runAWTLoopWithApp: was invoked from within the dispatch_async.
>>>>> This is a blocking method, so it blocked the main dispatch queue which is used in Cocoa internally. So we've got different bugs.
>>>>> The fix replaces the Grand Central Dispatch API with the JNFRunLoop performOnMainThreadWaiting which is used in other places in splashscreen.
>>>>>
>>>>> The test verifies that the native FS support works after showing the splashscreen. Mac OS X specific APIs are accessed with reflection, so the test is compilable on other platforms.
>>>>> The test.png is an image added to the test folder, it's not in the webrev as it does not support binary file diffs. I took the image from an existing 2d open test, so it should be fine from the legal point of view.
>>>>>
>>>>> With best regards. Petr.
>>>>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Thu Dec 19 04:22:10 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 19 Dec 2013 16:22:10 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7159566 The choice positioned
	in the top of applet when clicking the choice.
In-Reply-To: <52B2E28D.6030808@oracle.com>
References: <642D9E27-4144-49A7-A70F-3CCFC4A02E06@oracle.com>
	<52B1AB3B.3060907@oracle.com>
	<8619740B-F033-43BA-90FD-1AB464D3D99D@oracle.com>
	<52B2E28D.6030808@oracle.com>
Message-ID: <B77480DE-6D08-4E70-8A52-A59669597533@oracle.com>

Hello, Sergey.

> 174 if (popupMenu != null && popupMenu.getInvoker() != LWChoicePeer.this.getTarget()) {
>  180     popupMenu.show(getTarget(), loc.x, loc.y);
Oh, just forgot to update it. Thank you.

With best regards. Petr.

On 19.12.2013, at 16:11, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi , Petr.
> The fix looks fine.
> ps:
>  174 if (popupMenu != null && popupMenu.getInvoker() != LWChoicePeer.this.getTarget()) {
>  180     popupMenu.show(getTarget(), loc.x, loc.y);
> 
> 
> On 19.12.2013 11:49, Petr Pchelko wrote:
>> Hello, Anthony, Sergey.
>> 
>> Thank you for the review.
>> The new version could be found here:
>> http://cr.openjdk.java.net/~pchelko/9/7159566/webrev.01/
>> 
>> I've fixed it according to your comments.
>> 
>> With best regards. Petr.
>> 
>> On 18.12.2013, at 18:03, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>> 
>>> Hi, Petr.
>>> The fix looks good. I have 2 suggestions :
>>> 1 LWChoicePeer.this prefix is unnecessary here?
>>> 2 Can you add a small description about this code as a comment?
>>> Thanks.
>>> On 18.12.2013 13:54, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>> 
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-7159566
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/9/7159566/webrev/
>>>> 
>>>> The problem: when showing the choice popup we need to use a choice as an invoker to process grab correctly. That's why we have the piece of code I'm fixing.
>>>> However, we also need to set a correct location of the popup. A 'heavy' getLocationOnScreen is used because the choice might have already been moved by the
>>>> window manager by this point to fit the screen and it's the only public way to get the location of the popup menu.
>>>> 
>>>> The added test checks that there's no popup on the top of the window by clicking there.
>>>> 
>>>> With best regards. Petr.
>>> 
>>> -- 
>>> Best regards, Sergey.
>>> 
> 
> 
> -- 
> Best regards, Sergey. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131219/67a1f1fd/attachment.html 

From anton.tarasov at oracle.com  Thu Dec 19 04:52:18 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 19 Dec 2013 16:52:18 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52B21B83.4090209@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com> <52B16A18.4060301@oracle.com>
	<52B21B83.4090209@oracle.com>
Message-ID: <52B2EC02.2070005@oracle.com>

Hi Jim and all,

Thinking of getting rid of the need to use BuffedImage at all for JLF, I'm facing the following 
obstacles:

1. We have to forse developers to use a buffered image as a double buffer (currently by means of 
setting the corresponding property), because of the performance issue I'd mentioned 
(https://javafx-jira.kenai.com/browse/RT-30035). I investigated it a little. My assumption was that 
the problem is in copying from a volatile image to a buffered image (which Swing performs to flush 
its double buffer to Graphics which is tight to the root BufferedImage, containing the pixels of the 
JLF'c content). And that's the case. Measurement showed that copying b/w volatile and buffered works 
up to 300 times slower than copying b/w buffered and buffered. (This is what I see on my Mac, where 
AWT uses OpenGL). It dropps performance drastically.

As an alternative, we can switch off double buffering at all. I checked how it affects the 
performance (theoretically, it should increase it). I didn't see any noticable difference... 
(perhaps, that's because there're so much buffers b/w fx & swing, that one buffer less doesn't 
change the picture radically). But switching off double buffering changes the default behavior. 
Theoretically it can surprise the code that relies on it.

2. JViewport, in the interop mode, is forsedly switched to BACKINGSTORE (that is a BufferedImage). 
(By the way, here we also change the default behavior). This probably will be resolved in the future.

3. nimbus.AbstractRegionPainter takes a GraphicsConfig from the Graphics (which is tight to the 
BufferedImage, the roor buffer for JLF) and creates an Image based on it. As the Graphics is derived 
from BI, the result is BI as well. So far, I don't know if we can change this behavior for the 
AbstractRegionPainter.

We could originally create a VolatileImage (the root image for JLF), however with a volatile buffer 
we will face the same performance issue when we extract pixels from it. The "unified rendering" 
(exchanging bits on GPU) is cool idea, but no one started it yet.

On 19.12.2013 2:02, Jim Graham wrote:
> Hi Anton,
>
> I don't know enough about the overall architecture yet to be too specific about possible solutions 
> at this point.  Here are some questions that I still don't know the answer to...
>
> - I'm assuming that Swing gets its back buffer from the getOffscreenBuffer call because that was 
> what you modified to return a HiDPI image.  When Swing calls it internally, does it ever leak that 
> instance?  Could it use a different API to get that back buffer so that the public API doesn't change?

I'm afraid it can't. It calls the public method to create a double buffer, so that a custom 
RepaintManager could override it for instance. However, here's what comments in the code says:

     // Support for both the standard and volatile offscreen buffers exists to
     // provide backwards compatibility for the [rare] programs which may be
     // calling getOffScreenBuffer() and not expecting to get a VolatileImage.
     // Swing internally is migrating to use *only* the volatile image buffer.

     // Support for standard offscreen buffer
     //
     DoubleBufferInfo standardDoubleBuffer;

"Rare programs" may be calling the method. Swing long ago migrated to volatile buffers, for which 
there's another public method: getVolatileOffscreenBuffer().  Also, the comments seem outdated 
saying that it supports both the standard and volatile buffers. Currently, it only supports standard 
offscreen buffer.

>
>
> - The method returns Image.  If worse comes to worst then we could try to hide the identity of the 
> BI that gets returned, but that would be an awkward wrapper object, so hopefully a different 
> solution works.
>
> - Do we need to provide "automatically scaled image buffers" to developers that request one?  I'm 
> guessing that the standard practice for DB in Swing is that the Swing code manages the image used 
> for the back buffer, but does the developer ever get involved in that process such that we need to 
> have magically scaled images in their hands?

A custom RepaintManager can theoretically interfere in the process of double buffer management. It 
can draw some additional pixels to it or something of the like (I'll ask Alexander Potochkin, a 
former Swing owner, who should know much about it).

>
>
> - My impression was that there is some code in Swing that allocates the backbuffer, tells the 
> Swing tree of JComponents to render into it, then draws that image to the screen.  Logically it 
> might look something like this:
>
> backbuffer = createBackBuffer(w, h);
> // ...
> comp.paint(backbuffer.getGraphics());
> // ...
> screengraphics.drawImage(backbuffer, x, y, null);
>
> (though those lines of code may be spread across a number of methods for all I know)
>
> Instead if it did this:
>
> backbuffer = createBackBuffer(w*scale, h*scale);
> // backbuffer.getWidth,Height() return w*scale, h*scale, but we don't care
> // ...
> Graphics g = backbuffer.getGraphics();
> g.scale(scale, scale);
> comp.paint(g);
> // ...
> // this call forces the logical size of the image without any special
> // processing or instance recognition in SG2D
> screengraphics.drawImage(backbuffer, x, y, w, h, null);
>
> then we don't need any fancy wrappers or anything.  This doesn't solve any "manual double 
> buffering" that a developer would do, though, but it evades return values from public methods that 
> have "mismatched BufferedImage objects"...

This is possible for RepaintManager and JViewport, but looks not direct for 
nimbus.AbstractRegionPainter where the moment of image creation is quite distant from its actual 
painting (the logic is spread across multiple calls)... But I can look at it deeper.

Thanks,
Anton.

>
>             ...jim
>
> On 12/18/13 1:25 AM, Anton V. Tarasov wrote:
>> Hi Jim,
>>
>> Thanks for noticing (sorry, but I simply forgot to check we don't export
>> the buffer...) What can we do about that? I have the following thoughts:
>>
>> 1) We can warn developers to be ready for a HiDPI raster when they call
>> that method under the following conditions: 1) the interop mode, 2)
>> MacOSX 3) a Retina display.
>> 2) In case the method is called, we can create a "shadow buffer" and
>> start to sync it with the main buffer. The main buffer will be scaled to
>> the shadow buffer on every repaint cycle.
>> 3) We can introduce an internal property which will switch on/off the
>> 2nd scenario. For instance, a developer may ask for the buffer and don't
>> bother about its hidpi raster.
>>
>> Yes, I understand the solutions are far from perfect, but please take
>> into account, the interop is a special mode where we (and developers)
>> should be ready for compromises...
>>
>> What do you think? Do you have any better solutions in mind?
>>
>> Thanks,
>> Anton.
>>
>>
>> On 18.12.2013 5:03, Jim Graham wrote:
>>> Hi Anton,
>>>
>>> javax.swing.RepaintManager.getOffscreenBuffer is a public method that
>>> can now return one of the new HiDPI offscreen images which is a
>>> subclass of BufferedImage.  This was what I was worried about in terms
>>> of one of these internal double buffers leaking to developer code.  If
>>> they test the image using instanceof they will see that it is a
>>> BufferdImage and they may try to dig out the raster and get confused...
>>>
>>>             ...jim
>>>
>>> On 12/17/13 10:21 AM, Anton V. Tarasov wrote:
>>>> Hi all,
>>>>
>>>> Please look at the new version:
>>>>
>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2
>>>>
>>>> It contains the following changes:
>>>>
>>>> - All the scale related stuff is moved to the new class:
>>>> OffScreenHiDPIImage.java
>>>>
>>>> - JViewport and RepaintManager no longer cache buffers.
>>>>
>>>> - JLightweightFrame has new method: createHiDPIImage(w, h).
>>>>
>>>> - JViewport, RepaintManager and AbstractRegionPainter goes the new path
>>>> to create a HiDPI buffered image.
>>>>
>>>> - A new internal property is added: "swing.jlf.hidpiImageEnabled". False
>>>> by default. It makes JLF.createImage(w, h) forward the call to
>>>> JLF.createHiDPIImage(w, h). This can be used by a third party code in
>>>> case it creates a buffered image via Component.createImage(w, h) and
>>>> uses the image so that it can benefit from being a HiDPI image on a
>>>> Retina display.
>>>>
>>>> For instance, SwingSet2 has an animating Bezier curve demo. Switching
>>>> the property on makes the curve auto scale smoothly. Please, look at the
>>>> screenshots:
>>>>
>>>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png
>>>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png
>>>>
>>>> - SunGraphics2D now draws a HiDPI buffered image the same way it draws a
>>>> VolatileImage.
>>>>
>>>> - I've removed the copyArea() method from the BufImgSurfaceData, and
>>>> modified the original version. The only question I have is: do I need to
>>>> check for "instanceof OffScreenHiDPIImage.SurfaceData" in case when
>>>> "transformState == TRANSFORM_TRANSLATESCALE"? If this method is invoked
>>>> with some other SD, and the transform is SCALE, will it do the job with
>>>> the coordinates conversion done?
>>>>
>>>> - I've left the new methods in FramePeer default... May yet we implement
>>>> them in other peers when we really need it?
>>>>
>>>> - CPlatformLWWindow.getGraphicsDevice() checks for an intersection +
>>>> scale. This heuristic actually may fail when a Window is moved b/w three
>>>> or four displays so that it intersects them all at some time. JFX will
>>>> set a new scale factor in between and AWT may pick up a wrong device. I
>>>> don't know any simple solution for that. For two monitors this will
>>>> work.
>>>>
>>>> Thanks,
>>>> Anton.
>>


From anthony.petrov at oracle.com  Thu Dec 19 11:18:07 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 19 Dec 2013 23:18:07 +0400
Subject: <AWT Dev> [9] setMaximumSize() and setMaximizedBounds()
In-Reply-To: <52B2DF6E.4000400@oracle.com>
References: <52B2CE8F.1050205@oracle.com> <52B2DF6E.4000400@oracle.com>
Message-ID: <52B3466F.1090601@oracle.com>

But users may still want to have a shortcut to "maximize" a window in 
case #3. How about we still allow for maximizing a window, but use its 
maximum size instead of the maximized bounds as the size for a maximized 
window? In other words, the maximum size (if set) has a precedence over 
the maximized bounds.

--
best regards,
Anthony

On 12/19/2013 03:58 PM, Artem Ananiev wrote:
>
> On 12/19/2013 2:46 PM, Alexander Zvegintsev wrote:
>> Hello AWT team,
>>
>> I am currently looking at JDK-6464548 issue[1], and as you can see in
>> javadoc[2]
>> we have only setMinimumSize() implemented in java.awt.Window and
>> setMaximumSize() is not implemented.
>>
>> So my question is about how setMaximumSize() (and setMinimumSize())
>> should interfere with setMaximizedBounds()[3]?
>>
>> I see several options here:
>>
>> 1. setMaximizedBounds() refers to a different state and does not depend
>> on setMaximumSize() and setMinimumSize()
>> 2. setMaximizedBounds() respects setMaximumSize() and setMinimumSize().
>> If the window is maximized and maximized
>> bounds does not conform with maximum or minimum size then window will
>> shrunk or enlarge to honor these sizes.
>> 3. If maximum size is set then we deny window maximize operation and
>> setMaximizedBounds() have no effect.
>>
>> What do you think?
>
> I would vote for #2 or #3. #3 seems to be slightly better than #2,
> because to implement #2 we'll need to track, what was called first,
> setMaximumSize() or setMaximizedBounds(). Another problem is that if we
> restrict the maximized bounds to conform to minimum/maximum size, when a
> window is maximized it won't occupy the right place as requested by the
> application. In other words, I think that in case #2 maximized bounds
> feature is broken anyway, so it doesn't make sense to allow window
> maximization at all (which is exactly #3).
>
> Thanks,
>
> Artem
>
>> [1] https://bugs.openjdk.java.net/browse/JDK-6464548
>> [2]
>> http://docs.oracle.com/javase/7/docs/api/java/awt/Window.html#setMinimumSize(java.awt.Dimension)
>>
>>
>> [3]
>> http://docs.oracle.com/javase/7/docs/api/java/awt/Frame.html#setMaximizedBounds(java.awt.Rectangle)
>>
>>
>>
>>

From Sergey.Bylokhov at oracle.com  Thu Dec 19 14:34:53 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 20 Dec 2013 02:34:53 +0400
Subject: <AWT Dev> [9] setMaximumSize() and setMaximizedBounds()
In-Reply-To: <52B3466F.1090601@oracle.com>
References: <52B2CE8F.1050205@oracle.com> <52B2DF6E.4000400@oracle.com>
	<52B3466F.1090601@oracle.com>
Message-ID: <52B3748D.1040606@oracle.com>

Hi.
Just my 2 cents. From my point of view the calls below  looks similar 
and should behave in the same way:
1 setMaximumSize/setMinimumSize + setBounds.
2 setMaximumSize/setMinimumSize + setMaximizedBounds+"setMaximumState".
3 setMaximumSize/setMinimumSize + resize by the user.
4 setMaximumSize/setMinimumSize + setMaximizedBounds+maximisation/zoom 
by the user.
No?
Similar question: how we should handle situation when max size is 
smaller than minimum size.

On 19.12.2013 23:18, Anthony Petrov wrote:
> But users may still want to have a shortcut to "maximize" a window in 
> case #3. How about we still allow for maximizing a window, but use its 
> maximum size instead of the maximized bounds as the size for a 
> maximized window? In other words, the maximum size (if set) has a 
> precedence over the maximized bounds.
>
> -- 
> best regards,
> Anthony
>
> On 12/19/2013 03:58 PM, Artem Ananiev wrote:
>>
>> On 12/19/2013 2:46 PM, Alexander Zvegintsev wrote:
>>> Hello AWT team,
>>>
>>> I am currently looking at JDK-6464548 issue[1], and as you can see in
>>> javadoc[2]
>>> we have only setMinimumSize() implemented in java.awt.Window and
>>> setMaximumSize() is not implemented.
>>>
>>> So my question is about how setMaximumSize() (and setMinimumSize())
>>> should interfere with setMaximizedBounds()[3]?
>>>
>>> I see several options here:
>>>
>>> 1. setMaximizedBounds() refers to a different state and does not depend
>>> on setMaximumSize() and setMinimumSize()
>>> 2. setMaximizedBounds() respects setMaximumSize() and setMinimumSize().
>>> If the window is maximized and maximized
>>> bounds does not conform with maximum or minimum size then window will
>>> shrunk or enlarge to honor these sizes.
>>> 3. If maximum size is set then we deny window maximize operation and
>>> setMaximizedBounds() have no effect.
>>>
>>> What do you think?
>>
>> I would vote for #2 or #3. #3 seems to be slightly better than #2,
>> because to implement #2 we'll need to track, what was called first,
>> setMaximumSize() or setMaximizedBounds(). Another problem is that if we
>> restrict the maximized bounds to conform to minimum/maximum size, when a
>> window is maximized it won't occupy the right place as requested by the
>> application. In other words, I think that in case #2 maximized bounds
>> feature is broken anyway, so it doesn't make sense to allow window
>> maximization at all (which is exactly #3).
>>
>> Thanks,
>>
>> Artem
>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-6464548
>>> [2]
>>> http://docs.oracle.com/javase/7/docs/api/java/awt/Window.html#setMinimumSize(java.awt.Dimension) 
>>>
>>>
>>>
>>> [3]
>>> http://docs.oracle.com/javase/7/docs/api/java/awt/Frame.html#setMaximizedBounds(java.awt.Rectangle) 
>>>
>>>
>>>
>>>
>>>


-- 
Best regards, Sergey.


From james.graham at oracle.com  Thu Dec 19 15:24:30 2013
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 19 Dec 2013 15:24:30 -0800
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52B2EC02.2070005@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com> <52B16A18.4060301@oracle.com>
	<52B21B83.4090209@oracle.com> <52B2EC02.2070005@oracle.com>
Message-ID: <52B3802E.8070304@oracle.com>

I'm starting to get the full picture now.  Certainly, if we could share 
bits via the FX/Swing bridge then we could avoid the BufferedImage in 
the middle.  There used to be support in Scenario for the "resource 
sharing" layer that Dmitri and Chris put into Java2D to grab texture IDs 
directly from Java2D.  Could that be re-leveraged more easily than 
fixing this bug?

One question about your non-double-buffered experiment below.  You said 
that it didn't have any noticeable affect on performance.  Is that "the 
same as using a VI and a VI->BI copy"?  Or is it "the same as using a BI 
the whole way"?  I didn't understand which other scenario you were 
comparing its performance to.

If we still find some value in using VI on the Swing side, then how does 
the performance of rendering VI->BI differ from a direct pixel readback 
on the VI?  I would hope that they were the same, but perhaps we are 
being stupid in the VI->BI copy loops.  If readback is faster, could we 
modify the bridge to do a more direct readback rather than a drawImage 
operation?  Have you traced the code to see where the performance is 
going when we use the current VI->BI copies?  Maybe we are just missing 
a more direct copy loop in our list of loops?

			...jim

On 12/19/13 4:52 AM, Anton V. Tarasov wrote:
> Hi Jim and all,
>
> Thinking of getting rid of the need to use BuffedImage at all for JLF,
> I'm facing the following obstacles:
>
> 1. We have to forse developers to use a buffered image as a double
> buffer (currently by means of setting the corresponding property),
> because of the performance issue I'd mentioned
> (https://javafx-jira.kenai.com/browse/RT-30035). I investigated it a
> little. My assumption was that the problem is in copying from a volatile
> image to a buffered image (which Swing performs to flush its double
> buffer to Graphics which is tight to the root BufferedImage, containing
> the pixels of the JLF'c content). And that's the case. Measurement
> showed that copying b/w volatile and buffered works up to 300 times
> slower than copying b/w buffered and buffered. (This is what I see on my
> Mac, where AWT uses OpenGL). It dropps performance drastically.
>
> As an alternative, we can switch off double buffering at all. I checked
> how it affects the performance (theoretically, it should increase it). I
> didn't see any noticable difference... (perhaps, that's because there're
> so much buffers b/w fx & swing, that one buffer less doesn't change the
> picture radically). But switching off double buffering changes the
> default behavior. Theoretically it can surprise the code that relies on it.
>
> 2. JViewport, in the interop mode, is forsedly switched to BACKINGSTORE
> (that is a BufferedImage). (By the way, here we also change the default
> behavior). This probably will be resolved in the future.
>
> 3. nimbus.AbstractRegionPainter takes a GraphicsConfig from the Graphics
> (which is tight to the BufferedImage, the roor buffer for JLF) and
> creates an Image based on it. As the Graphics is derived from BI, the
> result is BI as well. So far, I don't know if we can change this
> behavior for the AbstractRegionPainter.
>
> We could originally create a VolatileImage (the root image for JLF),
> however with a volatile buffer we will face the same performance issue
> when we extract pixels from it. The "unified rendering" (exchanging bits
> on GPU) is cool idea, but no one started it yet.
>
> On 19.12.2013 2:02, Jim Graham wrote:
>> Hi Anton,
>>
>> I don't know enough about the overall architecture yet to be too
>> specific about possible solutions at this point.  Here are some
>> questions that I still don't know the answer to...
>>
>> - I'm assuming that Swing gets its back buffer from the
>> getOffscreenBuffer call because that was what you modified to return a
>> HiDPI image.  When Swing calls it internally, does it ever leak that
>> instance?  Could it use a different API to get that back buffer so
>> that the public API doesn't change?
>
> I'm afraid it can't. It calls the public method to create a double
> buffer, so that a custom RepaintManager could override it for instance.
> However, here's what comments in the code says:
>
>      // Support for both the standard and volatile offscreen buffers
> exists to
>      // provide backwards compatibility for the [rare] programs which
> may be
>      // calling getOffScreenBuffer() and not expecting to get a
> VolatileImage.
>      // Swing internally is migrating to use *only* the volatile image
> buffer.
>
>      // Support for standard offscreen buffer
>      //
>      DoubleBufferInfo standardDoubleBuffer;
>
> "Rare programs" may be calling the method. Swing long ago migrated to
> volatile buffers, for which there's another public method:
> getVolatileOffscreenBuffer().  Also, the comments seem outdated saying
> that it supports both the standard and volatile buffers. Currently, it
> only supports standard offscreen buffer.
>
>>
>>
>> - The method returns Image.  If worse comes to worst then we could try
>> to hide the identity of the BI that gets returned, but that would be
>> an awkward wrapper object, so hopefully a different solution works.
>>
>> - Do we need to provide "automatically scaled image buffers" to
>> developers that request one?  I'm guessing that the standard practice
>> for DB in Swing is that the Swing code manages the image used for the
>> back buffer, but does the developer ever get involved in that process
>> such that we need to have magically scaled images in their hands?
>
> A custom RepaintManager can theoretically interfere in the process of
> double buffer management. It can draw some additional pixels to it or
> something of the like (I'll ask Alexander Potochkin, a former Swing
> owner, who should know much about it).
>
>>
>>
>> - My impression was that there is some code in Swing that allocates
>> the backbuffer, tells the Swing tree of JComponents to render into it,
>> then draws that image to the screen.  Logically it might look
>> something like this:
>>
>> backbuffer = createBackBuffer(w, h);
>> // ...
>> comp.paint(backbuffer.getGraphics());
>> // ...
>> screengraphics.drawImage(backbuffer, x, y, null);
>>
>> (though those lines of code may be spread across a number of methods
>> for all I know)
>>
>> Instead if it did this:
>>
>> backbuffer = createBackBuffer(w*scale, h*scale);
>> // backbuffer.getWidth,Height() return w*scale, h*scale, but we don't
>> care
>> // ...
>> Graphics g = backbuffer.getGraphics();
>> g.scale(scale, scale);
>> comp.paint(g);
>> // ...
>> // this call forces the logical size of the image without any special
>> // processing or instance recognition in SG2D
>> screengraphics.drawImage(backbuffer, x, y, w, h, null);
>>
>> then we don't need any fancy wrappers or anything.  This doesn't solve
>> any "manual double buffering" that a developer would do, though, but
>> it evades return values from public methods that have "mismatched
>> BufferedImage objects"...
>
> This is possible for RepaintManager and JViewport, but looks not direct
> for nimbus.AbstractRegionPainter where the moment of image creation is
> quite distant from its actual painting (the logic is spread across
> multiple calls)... But I can look at it deeper.
>
> Thanks,
> Anton.
>
>>
>>             ...jim
>>
>> On 12/18/13 1:25 AM, Anton V. Tarasov wrote:
>>> Hi Jim,
>>>
>>> Thanks for noticing (sorry, but I simply forgot to check we don't export
>>> the buffer...) What can we do about that? I have the following thoughts:
>>>
>>> 1) We can warn developers to be ready for a HiDPI raster when they call
>>> that method under the following conditions: 1) the interop mode, 2)
>>> MacOSX 3) a Retina display.
>>> 2) In case the method is called, we can create a "shadow buffer" and
>>> start to sync it with the main buffer. The main buffer will be scaled to
>>> the shadow buffer on every repaint cycle.
>>> 3) We can introduce an internal property which will switch on/off the
>>> 2nd scenario. For instance, a developer may ask for the buffer and don't
>>> bother about its hidpi raster.
>>>
>>> Yes, I understand the solutions are far from perfect, but please take
>>> into account, the interop is a special mode where we (and developers)
>>> should be ready for compromises...
>>>
>>> What do you think? Do you have any better solutions in mind?
>>>
>>> Thanks,
>>> Anton.
>>>
>>>
>>> On 18.12.2013 5:03, Jim Graham wrote:
>>>> Hi Anton,
>>>>
>>>> javax.swing.RepaintManager.getOffscreenBuffer is a public method that
>>>> can now return one of the new HiDPI offscreen images which is a
>>>> subclass of BufferedImage.  This was what I was worried about in terms
>>>> of one of these internal double buffers leaking to developer code.  If
>>>> they test the image using instanceof they will see that it is a
>>>> BufferdImage and they may try to dig out the raster and get confused...
>>>>
>>>>             ...jim
>>>>
>>>> On 12/17/13 10:21 AM, Anton V. Tarasov wrote:
>>>>> Hi all,
>>>>>
>>>>> Please look at the new version:
>>>>>
>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2
>>>>>
>>>>> It contains the following changes:
>>>>>
>>>>> - All the scale related stuff is moved to the new class:
>>>>> OffScreenHiDPIImage.java
>>>>>
>>>>> - JViewport and RepaintManager no longer cache buffers.
>>>>>
>>>>> - JLightweightFrame has new method: createHiDPIImage(w, h).
>>>>>
>>>>> - JViewport, RepaintManager and AbstractRegionPainter goes the new
>>>>> path
>>>>> to create a HiDPI buffered image.
>>>>>
>>>>> - A new internal property is added: "swing.jlf.hidpiImageEnabled".
>>>>> False
>>>>> by default. It makes JLF.createImage(w, h) forward the call to
>>>>> JLF.createHiDPIImage(w, h). This can be used by a third party code in
>>>>> case it creates a buffered image via Component.createImage(w, h) and
>>>>> uses the image so that it can benefit from being a HiDPI image on a
>>>>> Retina display.
>>>>>
>>>>> For instance, SwingSet2 has an animating Bezier curve demo. Switching
>>>>> the property on makes the curve auto scale smoothly. Please, look
>>>>> at the
>>>>> screenshots:
>>>>>
>>>>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png
>>>>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png
>>>>>
>>>>> - SunGraphics2D now draws a HiDPI buffered image the same way it
>>>>> draws a
>>>>> VolatileImage.
>>>>>
>>>>> - I've removed the copyArea() method from the BufImgSurfaceData, and
>>>>> modified the original version. The only question I have is: do I
>>>>> need to
>>>>> check for "instanceof OffScreenHiDPIImage.SurfaceData" in case when
>>>>> "transformState == TRANSFORM_TRANSLATESCALE"? If this method is
>>>>> invoked
>>>>> with some other SD, and the transform is SCALE, will it do the job
>>>>> with
>>>>> the coordinates conversion done?
>>>>>
>>>>> - I've left the new methods in FramePeer default... May yet we
>>>>> implement
>>>>> them in other peers when we really need it?
>>>>>
>>>>> - CPlatformLWWindow.getGraphicsDevice() checks for an intersection +
>>>>> scale. This heuristic actually may fail when a Window is moved b/w
>>>>> three
>>>>> or four displays so that it intersects them all at some time. JFX will
>>>>> set a new scale factor in between and AWT may pick up a wrong
>>>>> device. I
>>>>> don't know any simple solution for that. For two monitors this will
>>>>> work.
>>>>>
>>>>> Thanks,
>>>>> Anton.
>>>
>

From joe.darcy at oracle.com  Thu Dec 19 22:01:02 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 19 Dec 2013 22:01:02 -0800
Subject: <AWT Dev> JDK 9 RFR of 8030845: Fix doclint missing issues in
	java.awt.event
Message-ID: <52B3DD1E.8020204@oracle.com>

Hello,

Please review my changes to address

     8030845: Fix doclint missing issues in java.awt.event

in JDK 9. Webrev at

     http://cr.openjdk.java.net/~darcy/8030845.0/

patch below.

Thanks,

-Joe

--- old/src/share/classes/java/awt/event/AWTEventListener.java 
2013-12-19 21:48:44.000000000 -0800
+++ new/src/share/classes/java/awt/event/AWTEventListener.java 
2013-12-19 21:48:44.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1998, 2003, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -56,6 +56,7 @@

      /**
       * Invoked when an event is dispatched in the AWT.
+     * @param event the event to be processed
       */
      public void eventDispatched(AWTEvent event);

--- old/src/share/classes/java/awt/event/ActionListener.java 2013-12-19 
21:48:45.000000000 -0800
+++ new/src/share/classes/java/awt/event/ActionListener.java 2013-12-19 
21:48:44.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -46,6 +46,7 @@

      /**
       * Invoked when an action occurs.
+     * @param e the event to be processed
       */
      public void actionPerformed(ActionEvent e);

--- old/src/share/classes/java/awt/event/AdjustmentListener.java 
2013-12-19 21:48:45.000000000 -0800
+++ new/src/share/classes/java/awt/event/AdjustmentListener.java 
2013-12-19 21:48:45.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 1999, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -37,6 +37,7 @@

      /**
       * Invoked when the value of the adjustable has changed.
+     * @param e the event to be processed
       */
      public void adjustmentValueChanged(AdjustmentEvent e);

--- old/src/share/classes/java/awt/event/ComponentListener.java 
2013-12-19 21:48:46.000000000 -0800
+++ new/src/share/classes/java/awt/event/ComponentListener.java 
2013-12-19 21:48:46.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -54,21 +54,25 @@
  public interface ComponentListener extends EventListener {
      /**
       * Invoked when the component's size changes.
+     * @param e the event to be processed
       */
      public void componentResized(ComponentEvent e);

      /**
       * Invoked when the component's position changes.
+     * @param e the event to be processed
       */
      public void componentMoved(ComponentEvent e);

      /**
       * Invoked when the component has been made visible.
+     * @param e the event to be processed
       */
      public void componentShown(ComponentEvent e);

      /**
       * Invoked when the component has been made invisible.
+     * @param e the event to be processed
       */
      public void componentHidden(ComponentEvent e);
  }
--- old/src/share/classes/java/awt/event/ContainerListener.java 
2013-12-19 21:48:46.000000000 -0800
+++ new/src/share/classes/java/awt/event/ContainerListener.java 
2013-12-19 21:48:46.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -55,11 +55,13 @@
  public interface ContainerListener extends EventListener {
      /**
       * Invoked when a component has been added to the container.
+     * @param e the event to be processed
       */
      public void componentAdded(ContainerEvent e);

      /**
       * Invoked when a component has been removed from the container.
+     * @param e the event to be processed
       */
      public void componentRemoved(ContainerEvent e);

--- old/src/share/classes/java/awt/event/FocusListener.java 2013-12-19 
21:48:47.000000000 -0800
+++ new/src/share/classes/java/awt/event/FocusListener.java 2013-12-19 
21:48:46.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -51,11 +51,13 @@

      /**
       * Invoked when a component gains the keyboard focus.
+     * @param e the event to be processed
       */
      public void focusGained(FocusEvent e);

      /**
       * Invoked when a component loses the keyboard focus.
+     * @param e the event to be processed
       */
      public void focusLost(FocusEvent e);
  }
--- old/src/share/classes/java/awt/event/HierarchyBoundsListener.java 
2013-12-19 21:48:47.000000000 -0800
+++ new/src/share/classes/java/awt/event/HierarchyBoundsListener.java 
2013-12-19 21:48:47.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -52,11 +52,13 @@
  public interface HierarchyBoundsListener extends EventListener {
      /**
       * Called when an ancestor of the source is moved.
+     * @param e the event to be processed
       */
      public void ancestorMoved(HierarchyEvent e);

      /**
       * Called when an ancestor of the source is resized.
+     * @param e the event to be processed
       */
      public void ancestorResized(HierarchyEvent e);
  }
--- old/src/share/classes/java/awt/event/HierarchyListener.java 
2013-12-19 21:48:48.000000000 -0800
+++ new/src/share/classes/java/awt/event/HierarchyListener.java 
2013-12-19 21:48:47.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -51,6 +51,7 @@
       * Called when the hierarchy has been changed. To discern the actual
       * type of change, call <code>HierarchyEvent.getChangeFlags()</code>.
       *
+     * @param e the event to be processed
       * @see HierarchyEvent#getChangeFlags()
       */
      public void hierarchyChanged(HierarchyEvent e);
--- old/src/share/classes/java/awt/event/InputEvent.java 2013-12-19 
21:48:48.000000000 -0800
+++ new/src/share/classes/java/awt/event/InputEvent.java 2013-12-19 
21:48:48.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2010, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -233,7 +233,8 @@
       * This limit is defined by the relevant number
       * of buttons that may hypothetically exist on the mouse but it is 
greater than the
       * {@link java.awt.MouseInfo#getNumberOfButtons() 
MouseInfo.getNumberOfButtons()}.
-     * <p>
+     *
+     * @return a mask for an existing mouse button.
       * @throws IllegalArgumentException if {@code button} is less than 
zero or greater than the number
       *         of button masks reserved for buttons
       * @since 7.0
@@ -368,6 +369,7 @@

      /**
       * Returns whether or not the Shift modifier is down on this event.
+     * @return whether or not the Shift modifier is down on this event
       */
      public boolean isShiftDown() {
          return (modifiers & SHIFT_MASK) != 0;
@@ -375,6 +377,7 @@

      /**
       * Returns whether or not the Control modifier is down on this event.
+     * @return whether or not the Control modifier is down on this event
       */
      public boolean isControlDown() {
          return (modifiers & CTRL_MASK) != 0;
@@ -382,6 +385,7 @@

      /**
       * Returns whether or not the Meta modifier is down on this event.
+     * @return whether or not the Meta modifier is down on this event
       */
      public boolean isMetaDown() {
          return (modifiers & META_MASK) != 0;
@@ -389,6 +393,7 @@

      /**
       * Returns whether or not the Alt modifier is down on this event.
+     * @return whether or not the Alt modifier is down on this event
       */
      public boolean isAltDown() {
          return (modifiers & ALT_MASK) != 0;
@@ -396,6 +401,7 @@

      /**
       * Returns whether or not the AltGraph modifier is down on this event.
+     * @return whether or not the AltGraph modifier is down on this event
       */
      public boolean isAltGraphDown() {
          return (modifiers & ALT_GRAPH_MASK) != 0;
@@ -404,6 +410,7 @@
      /**
       * Returns the difference in milliseconds between the timestamp of 
when this event occurred and
       * midnight, January 1, 1970 UTC.
+     * @return the difference in milliseconds between the timestamp and 
midnight, January 1, 1970 UTC
       */
      public long getWhen() {
          return when;
@@ -411,6 +418,7 @@

      /**
       * Returns the modifier mask for this event.
+     * @return the modifier mask for this event
       */
      public int getModifiers() {
          return modifiers & (JDK_1_3_MODIFIERS | HIGH_MODIFIERS);
@@ -451,6 +459,7 @@
       * </PRE>
       * The above code will work even if new modifiers are added.
       *
+     * @return the extended modifier mask for this event
       * @since 1.4
       */
      public int getModifiersEx() {
@@ -467,6 +476,7 @@

      /**
       * Returns whether or not this event has been consumed.
+     * @return whether or not this event has been consumed
       * @see #consume
       */
      public boolean isConsumed() {
@@ -487,6 +497,9 @@
       * Zero parameter means that no modifiers were passed and will
       * cause the returning an empty string.
       *
+     * @return a String describing the extended modifier keys and
+     * mouse buttons
+     *
       * @param modifiers a modifier mask describing the extended
       *                modifier keys and mouse buttons for the event
       * @return a text description of the combination of extended
--- old/src/share/classes/java/awt/event/InputMethodEvent.java 
2013-12-19 21:48:48.000000000 -0800
+++ new/src/share/classes/java/awt/event/InputMethodEvent.java 
2013-12-19 21:48:48.000000000 -0800
@@ -277,6 +277,7 @@

      /**
       * Gets the number of committed characters in the text.
+     * @return the number of committed characters in the text
       */
      public int getCommittedCharacterCount() {
          return committedCharacterCount;
--- old/src/share/classes/java/awt/event/InputMethodListener.java 
2013-12-19 21:48:49.000000000 -0800
+++ new/src/share/classes/java/awt/event/InputMethodListener.java 
2013-12-19 21:48:49.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1997, 1999, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -40,17 +40,17 @@
   * @see java.awt.im.InputMethodRequests
   * @since 1.2
   */
-
  public interface InputMethodListener extends EventListener {

      /**
       * Invoked when the text entered through an input method has changed.
+     * @param event the event to be processed
       */
      void inputMethodTextChanged(InputMethodEvent event);

      /**
       * Invoked when the caret within composed text has changed.
+     * @param event the event to be processed
       */
      void caretPositionChanged(InputMethodEvent event);
-
  }
--- old/src/share/classes/java/awt/event/ItemListener.java 2013-12-19 
21:48:49.000000000 -0800
+++ new/src/share/classes/java/awt/event/ItemListener.java 2013-12-19 
21:48:49.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -50,6 +50,7 @@
       * Invoked when an item has been selected or deselected by the user.
       * The code written for this method performs the operations
       * that need to occur when an item is selected (or deselected).
+     * @param e the event to be processed
       */
      void itemStateChanged(ItemEvent e);

--- old/src/share/classes/java/awt/event/KeyEvent.java    2013-12-19 
21:48:50.000000000 -0800
+++ new/src/share/classes/java/awt/event/KeyEvent.java    2013-12-19 
21:48:50.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -132,7 +132,7 @@
   * <p>
   * WARNING: Aside from those keys that are defined by the Java language
   * (VK_ENTER, VK_BACK_SPACE, and VK_TAB), do not rely on the values of 
the VK_
- * constants.  Sun reserves the right to change these values as needed
+ * constants.  The platform steward reserves the right to change these 
values as needed
   * to accommodate a wider range of keyboards in the future.
   * <p>
   * An unspecified behavior will be caused if the {@code id} parameter
@@ -194,21 +194,52 @@

      /* Virtual key codes. */

+    /** Constant for the ENTER virtual key. */
      public static final int VK_ENTER          = '\n';
+
+    /** Constant for the BACK_SPACE virtual key. */
      public static final int VK_BACK_SPACE     = '\b';
+
+    /** Constant for the TAB virtual key. */
      public static final int VK_TAB            = '\t';
+
+    /** Constant for the CANCEL virtual key. */
      public static final int VK_CANCEL         = 0x03;
+
+    /** Constant for the CLEAR virtual key. */
      public static final int VK_CLEAR          = 0x0C;
+
+    /** Constant for the SHIFT virtual key. */
      public static final int VK_SHIFT          = 0x10;
+
+    /** Constant for the CONTROL virtual key. */
      public static final int VK_CONTROL        = 0x11;
+
+    /** Constant for the ALT. virtual key */
      public static final int VK_ALT            = 0x12;
+
+    /** Constant for the PAUSE virtual key. */
      public static final int VK_PAUSE          = 0x13;
+
+    /** Constant for the CAPS_LOCK virtual key. */
      public static final int VK_CAPS_LOCK      = 0x14;
+
+    /** Constant for the ESCAPE virtual key. */
      public static final int VK_ESCAPE         = 0x1B;
+
+    /** Constant for the SPACE virtual key. */
      public static final int VK_SPACE          = 0x20;
+
+    /** Constant for the PAGE_UP virtual key. */
      public static final int VK_PAGE_UP        = 0x21;
+
+    /** Constant for the PAGE_DOWN virtual key. */
      public static final int VK_PAGE_DOWN      = 0x22;
+
+    /** Constant for the END virtual key. */
      public static final int VK_END            = 0x23;
+
+    /** Constant for the HOME virtual key. */
      public static final int VK_HOME           = 0x24;

      /**
@@ -257,15 +288,35 @@
      public static final int VK_SLASH          = 0x2F;

      /** VK_0 thru VK_9 are the same as ASCII '0' thru '9' (0x30 - 0x39) */
+
+    /** Constant for the "0" key. */
      public static final int VK_0              = 0x30;
+
+    /** Constant for the "1" key. */
      public static final int VK_1              = 0x31;
+
+    /** Constant for the "2" key. */
      public static final int VK_2              = 0x32;
+
+    /** Constant for the "3" key. */
      public static final int VK_3              = 0x33;
+
+    /** Constant for the "4" key. */
      public static final int VK_4              = 0x34;
+
+    /** Constant for the "5" key. */
      public static final int VK_5              = 0x35;
+
+    /** Constant for the "6" key. */
      public static final int VK_6              = 0x36;
+
+    /** Constant for the "7" key. */
      public static final int VK_7              = 0x37;
+
+    /** Constant for the "8" key. */
      public static final int VK_8              = 0x38;
+
+    /** Constant for the "9" key. */
      public static final int VK_9              = 0x39;

      /**
@@ -279,31 +330,83 @@
      public static final int VK_EQUALS         = 0x3D;

      /** VK_A thru VK_Z are the same as ASCII 'A' thru 'Z' (0x41 - 0x5A) */
+
+    /** Constant for the "A" key. */
      public static final int VK_A              = 0x41;
+
+    /** Constant for the "B" key. */
      public static final int VK_B              = 0x42;
+
+    /** Constant for the "C" key. */
      public static final int VK_C              = 0x43;
+
+    /** Constant for the "D" key. */
      public static final int VK_D              = 0x44;
+
+    /** Constant for the "E" key. */
      public static final int VK_E              = 0x45;
+
+    /** Constant for the "F" key. */
      public static final int VK_F              = 0x46;
+
+    /** Constant for the "G" key. */
      public static final int VK_G              = 0x47;
+
+    /** Constant for the "H" key. */
      public static final int VK_H              = 0x48;
+
+    /** Constant for the "I" key. */
      public static final int VK_I              = 0x49;
+
+    /** Constant for the "J" key. */
      public static final int VK_J              = 0x4A;
+
+    /** Constant for the "K" key. */
      public static final int VK_K              = 0x4B;
+
+    /** Constant for the "L" key. */
      public static final int VK_L              = 0x4C;
+
+    /** Constant for the "M" key. */
      public static final int VK_M              = 0x4D;
+
+    /** Constant for the "N" key. */
      public static final int VK_N              = 0x4E;
+
+    /** Constant for the "O" key. */
      public static final int VK_O              = 0x4F;
+
+    /** Constant for the "P" key. */
      public static final int VK_P              = 0x50;
+
+    /** Constant for the "Q" key. */
      public static final int VK_Q              = 0x51;
+
+    /** Constant for the "R" key. */
      public static final int VK_R              = 0x52;
+
+    /** Constant for the "S" key. */
      public static final int VK_S              = 0x53;
+
+    /** Constant for the "T" key. */
      public static final int VK_T              = 0x54;
+
+    /** Constant for the "U" key. */
      public static final int VK_U              = 0x55;
+
+    /** Constant for the "V" key. */
      public static final int VK_V              = 0x56;
+
+    /** Constant for the "W" key. */
      public static final int VK_W              = 0x57;
+
+    /** Constant for the "X" key. */
      public static final int VK_X              = 0x58;
+
+    /** Constant for the "Y" key. */
      public static final int VK_Y              = 0x59;
+
+    /** Constant for the "Z" key. */
      public static final int VK_Z              = 0x5A;

      /**
@@ -321,17 +424,40 @@
       */
      public static final int VK_CLOSE_BRACKET  = 0x5D;

+    /** Constant for the number pad "0" key. */
      public static final int VK_NUMPAD0        = 0x60;
+
+    /** Constant for the number pad "1" key. */
      public static final int VK_NUMPAD1        = 0x61;
+
+    /** Constant for the number pad "2" key. */
      public static final int VK_NUMPAD2        = 0x62;
+
+    /** Constant for the number pad "3" key. */
      public static final int VK_NUMPAD3        = 0x63;
+
+    /** Constant for the number pad "4" key. */
      public static final int VK_NUMPAD4        = 0x64;
+
+    /** Constant for the number pad "5" key. */
      public static final int VK_NUMPAD5        = 0x65;
+
+    /** Constant for the number pad "6" key. */
      public static final int VK_NUMPAD6        = 0x66;
+
+    /** Constant for the number pad "7" key. */
      public static final int VK_NUMPAD7        = 0x67;
+
+    /** Constant for the number pad "8" key. */
      public static final int VK_NUMPAD8        = 0x68;
+
+    /** Constant for the number pad "9" key. */
      public static final int VK_NUMPAD9        = 0x69;
+
+    /** Constant for the number pad multiply key. */
      public static final int VK_MULTIPLY       = 0x6A;
+
+    /** Constant for the number pad add key. */
      public static final int VK_ADD            = 0x6B;

      /**
@@ -347,11 +473,22 @@
       */
      public static final int VK_SEPARATOR      = VK_SEPARATER;

+    /** Constant for the substract key. */
      public static final int VK_SUBTRACT       = 0x6D;
+
+    /** Constant for the decimal key. */
      public static final int VK_DECIMAL        = 0x6E;
+
+    /** Constant for the divide key. */
      public static final int VK_DIVIDE         = 0x6F;
+
+    /** Constant for the delete key. */
      public static final int VK_DELETE         = 0x7F; /* ASCII DEL */
+
+    /** Constant for the NUM_LOCK key. */
      public static final int VK_NUM_LOCK       = 0x90;
+
+    /** Constant for the SCROLL_LOCK key. */
      public static final int VK_SCROLL_LOCK    = 0x91;

      /** Constant for the F1 function key. */
@@ -463,12 +600,22 @@
       */
      public static final int VK_F24            = 0xF00B;

+    /**  Constant for the PRINTSCREEN key. */
      public static final int VK_PRINTSCREEN    = 0x9A;
+
+    /**  Constant for the INSERT key. */
      public static final int VK_INSERT         = 0x9B;
+
+    /**  Constant for the HELP key. */
      public static final int VK_HELP           = 0x9C;
+
+    /**  Constant for the META  key. */
      public static final int VK_META           = 0x9D;

+    /**  Constant for the BACK_QUOTE  key. */
      public static final int VK_BACK_QUOTE     = 0xC0;
+
+    /**  Constant for the QUOTE  key. */
      public static final int VK_QUOTE          = 0xDE;

      /**
@@ -638,6 +785,7 @@
      /* for input method support on Asian Keyboards */

      /* not clear what this means - listed in Microsoft Windows API */
+    /** Constant for the FINAL key, listed in the Microsoft Windows API. */
      public static final int VK_FINAL                    = 0x0018;

      /** Constant for the Convert function key. */
@@ -653,14 +801,23 @@
      public static final int VK_ACCEPT                   = 0x001E;

      /* not clear what this means - listed in Microsoft Windows API */
+    /** Constant for the MODECHANGE key, listed in the Microsoft 
Windows API. */
      public static final int VK_MODECHANGE               = 0x001F;

      /* replaced by VK_KANA_LOCK for Microsoft Windows and Solaris;
         might still be used on other platforms */
+    /**
+     * Constant for the KANA lock key.
+     * @see #VK_KANA_LOCK
+     **/
      public static final int VK_KANA                     = 0x0015;

      /* replaced by VK_INPUT_METHOD_ON_OFF for Microsoft Windows and 
Solaris;
         might still be used for other platforms */
+    /**
+     * Constant for KANJI.
+     * @see #VK_INPUT_METHOD_ON_OFF
+     */
      public static final int VK_KANJI                    = 0x0019;

      /**
@@ -1085,7 +1242,25 @@
      }

      /**
-     * @deprecated as of JDK1.1
+     * @deprecated as of JDK1.1; use {@link #KeyEvent(Component, int, 
long, int, int, char)} instead
+     * @param source    The <code>Component</code> that originated the 
event
+     * @param id              An integer indicating the type of event.
+     *                  For information on allowable values, see
+     *                  the class description for {@link KeyEvent}
+     * @param when      A long integer that specifies the time the event
+     *                  occurred.
+     *                     Passing negative or zero value
+     *                     is not recommended
+     * @param modifiers The modifier keys down during event (shift, ctrl,
+     *                  alt, meta).
+     *                     Passing negative value
+     *                     is not recommended.
+     *                     Zero value means that no modifiers were passed.
+     *                  Use either an extended _DOWN_MASK or old _MASK 
modifiers,
+     *                  however do not mix models in the one event.
+     *                  The extended modifiers are preferred for using
+     * @param keyCode   The integer code for an actual key, or VK_UNDEFINED
+     *                  (for a key-typed event)
       */
      @Deprecated
      public KeyEvent(Component source, int id, long when, int modifiers,
@@ -1184,6 +1359,7 @@
       * Returns a String describing the keyCode, such as "HOME", "F1" 
or "A".
       * These strings can be localized by changing the awt.properties file.
       *
+     * @param keyCode the key whose description is to be returned
       * @return a string containing a text description for a physical key,
       *         identified by its keyCode
       */
@@ -1376,6 +1552,7 @@
       * <code>InputEvent.BUTTON3_MASK</code> have the same value,
       * so the string "Meta" is returned for both modifiers.
       *
+     * @param modifiers the modifier mask to be processed
       * @return string a text description of the combination of modifier
       *                keys that were held down during the event
       * @see InputEvent#getModifiersExText(int)
@@ -1612,8 +1789,8 @@
       * Pressing the same key in a regular Russian layout gives another 
code, unique for the
       * letter "Cyrillic I short".
       *
+     * @return an extended key code for the event
       * @since 1.7
-     *
       */
      public  int getExtendedKeyCode() {
          return (int)extendedKeyCode;
@@ -1621,6 +1798,7 @@
      /**
       * Returns an extended key code for a unicode character.
       *
+     * @param c the unicode character to be processed
       * @return for a unicode character with a corresponding {@code 
VK_} constant -- this
       *   {@code VK_} constant; for a character appearing on the primary
       *   level of a known keyboard layout -- a unique integer.
@@ -1628,7 +1806,6 @@
       *   {@code VK_UNDEFINED} is returned.
       *
       * @since 1.7
-     *
       */
      public static int getExtendedKeyCodeForChar(int c) {
          // Return a keycode (if any) associated with a character.
--- old/src/share/classes/java/awt/event/KeyListener.java 2013-12-19 
21:48:50.000000000 -0800
+++ new/src/share/classes/java/awt/event/KeyListener.java 2013-12-19 
21:48:50.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -54,6 +54,7 @@
       * Invoked when a key has been typed.
       * See the class description for {@link KeyEvent} for a definition of
       * a key typed event.
+     * @param e the event to be processed
       */
      public void keyTyped(KeyEvent e);

@@ -61,6 +62,7 @@
       * Invoked when a key has been pressed.
       * See the class description for {@link KeyEvent} for a definition of
       * a key pressed event.
+     * @param e the event to be processed
       */
      public void keyPressed(KeyEvent e);

@@ -68,6 +70,7 @@
       * Invoked when a key has been released.
       * See the class description for {@link KeyEvent} for a definition of
       * a key released event.
+     * @param e the event to be processed
       */
      public void keyReleased(KeyEvent e);
  }
--- old/src/share/classes/java/awt/event/MouseListener.java 2013-12-19 
21:48:51.000000000 -0800
+++ new/src/share/classes/java/awt/event/MouseListener.java 2013-12-19 
21:48:51.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -59,26 +59,31 @@
      /**
       * Invoked when the mouse button has been clicked (pressed
       * and released) on a component.
+     * @param e the event to be processed
       */
      public void mouseClicked(MouseEvent e);

      /**
       * Invoked when a mouse button has been pressed on a component.
+     * @param e the event to be processed
       */
      public void mousePressed(MouseEvent e);

      /**
       * Invoked when a mouse button has been released on a component.
+     * @param e the event to be processed
       */
      public void mouseReleased(MouseEvent e);

      /**
       * Invoked when the mouse enters a component.
+     * @param e the event to be processed
       */
      public void mouseEntered(MouseEvent e);

      /**
       * Invoked when the mouse exits a component.
+     * @param e the event to be processed
       */
      public void mouseExited(MouseEvent e);
  }
--- old/src/share/classes/java/awt/event/MouseMotionListener.java 
2013-12-19 21:48:51.000000000 -0800
+++ new/src/share/classes/java/awt/event/MouseMotionListener.java 
2013-12-19 21:48:51.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -63,12 +63,14 @@
       * Due to platform-dependent Drag&amp;Drop implementations,
       * <code>MOUSE_DRAGGED</code> events may not be delivered during a 
native
       * Drag&amp;Drop operation.
+     * @param e the event to be processed
       */
      public void mouseDragged(MouseEvent e);

      /**
       * Invoked when the mouse cursor has been moved onto a component
       * but no buttons have been pushed.
+     * @param e the event to be processed
       */
      public void mouseMoved(MouseEvent e);

--- old/src/share/classes/java/awt/event/MouseWheelListener.java 
2013-12-19 21:48:52.000000000 -0800
+++ new/src/share/classes/java/awt/event/MouseWheelListener.java 
2013-12-19 21:48:52.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2000, 2003, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -52,6 +52,7 @@

      /**
       * Invoked when the mouse wheel is rotated.
+     * @param e the event to be processed
       * @see MouseWheelEvent
       */
      public void mouseWheelMoved(MouseWheelEvent e);
--- old/src/share/classes/java/awt/event/PaintEvent.java 2013-12-19 
21:48:52.000000000 -0800
+++ new/src/share/classes/java/awt/event/PaintEvent.java 2013-12-19 
21:48:52.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2008, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -108,6 +108,8 @@
      /**
       * Returns the rectangle representing the area which needs to be
       * repainted in response to this event.
+     * @return the rectangle representing the area which needs to be
+     * repainted in response to this event
       */
      public Rectangle getUpdateRect() {
          return updateRect;
--- old/src/share/classes/java/awt/event/TextListener.java 2013-12-19 
21:48:53.000000000 -0800
+++ new/src/share/classes/java/awt/event/TextListener.java 2013-12-19 
21:48:52.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2008, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -49,6 +49,8 @@
       * Invoked when the value of the text has changed.
       * The code written for this method performs the operations
       * that need to occur when text changes.
+     *
+     * @param e the event to be processed
       */
      public void textValueChanged(TextEvent e);

--- old/src/share/classes/java/awt/event/WindowFocusListener.java 
2013-12-19 21:48:53.000000000 -0800
+++ new/src/share/classes/java/awt/event/WindowFocusListener.java 
2013-12-19 21:48:53.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2000, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -57,6 +57,7 @@
       * Invoked when the Window is set to be the focused Window, which 
means
       * that the Window, or one of its subcomponents, will receive keyboard
       * events.
+     * @param e the event to be processed
       */
      public void windowGainedFocus(WindowEvent e);

@@ -64,6 +65,7 @@
       * Invoked when the Window is no longer the focused Window, which 
means
       * that keyboard events will no longer be delivered to the Window 
or any of
       * its subcomponents.
+     * @param e the event to be processed
       */
      public void windowLostFocus(WindowEvent e);
  }
--- old/src/share/classes/java/awt/event/WindowListener.java 2013-12-19 
21:48:53.000000000 -0800
+++ new/src/share/classes/java/awt/event/WindowListener.java 2013-12-19 
21:48:53.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2003, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -51,18 +51,21 @@
  public interface WindowListener extends EventListener {
      /**
       * Invoked the first time a window is made visible.
+     * @param e the event to be processed
       */
      public void windowOpened(WindowEvent e);

      /**
       * Invoked when the user attempts to close the window
       * from the window's system menu.
+     * @param e the event to be processed
       */
      public void windowClosing(WindowEvent e);

      /**
       * Invoked when a window has been closed as the result
       * of calling dispose on the window.
+     * @param e the event to be processed
       */
      public void windowClosed(WindowEvent e);

@@ -71,6 +74,7 @@
       * minimized state. For many platforms, a minimized window
       * is displayed as the icon specified in the window's
       * iconImage property.
+     * @param e the event to be processed
       * @see java.awt.Frame#setIconImage
       */
      public void windowIconified(WindowEvent e);
@@ -78,6 +82,7 @@
      /**
       * Invoked when a window is changed from a minimized
       * to a normal state.
+     * @param e the event to be processed
       */
      public void windowDeiconified(WindowEvent e);

@@ -88,6 +93,7 @@
       * as a highlighted title bar. The active Window is always either the
       * focused Window, or the first Frame or Dialog that is an owner 
of the
       * focused Window.
+     * @param e the event to be processed
       */
      public void windowActivated(WindowEvent e);

@@ -98,6 +104,7 @@
       * highlighted title bar. The active Window is always either the 
focused
       * Window, or the first Frame or Dialog that is an owner of the 
focused
       * Window.
+     * @param e the event to be processed
       */
      public void windowDeactivated(WindowEvent e);
  }
--- old/src/share/classes/java/awt/event/WindowStateListener.java 
2013-12-19 21:48:54.000000000 -0800
+++ new/src/share/classes/java/awt/event/WindowStateListener.java 
2013-12-19 21:48:54.000000000 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2001, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -50,6 +50,7 @@
  public interface WindowStateListener extends EventListener {
      /**
       * Invoked when window state is changed.
+     * @param e the event to be processed
       */
      public void windowStateChanged(WindowEvent e);
  }


From Sergey.Bylokhov at oracle.com  Fri Dec 20 02:23:56 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 20 Dec 2013 14:23:56 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8007220 [macosx] Setting
 popupmenu on TrayIcon do not work if done *after* adding TrayIcon
In-Reply-To: <94D1565B-9312-4BA3-ABD8-E2A8922F011B@oracle.com>
References: <B73165E1-0CF0-47F8-B48D-3C064F82EEFA@oracle.com>
	<52AEF449.8000705@oracle.com>
	<6596B350-7B46-4029-916D-CF96A408EB32@oracle.com>
	<52B02CF9.2000609@oracle.com>
	<94D1565B-9312-4BA3-ABD8-E2A8922F011B@oracle.com>
Message-ID: <52B41ABC.8010908@oracle.com>

Hi, Petr.
The fix looks good.

On 17.12.2013 16:24, Petr Pchelko wrote:
> Hello, Sergey.
>
>> Thanks for this check. Is it possible to create a new test for this issue?
> Everything is possible) Please see the updated webrev here: http://cr.openjdk.java.net/~pchelko/9/8007220/webrev.02/
>
> I've added one more test: PopupMenuLeakTest - it's an automatic test to verify that the reference to PopupMenu is GCd after the TrayIcon was removed.
>
> With best regards. Petr.
>
> On 17.12.2013, at 14:52, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> On 12/16/13 5:25 PM, Petr Pchelko wrote:
>>> Hello, Sergey.
>>>
>>>> Since you add new call to addNotify(), can you check that we call removeNotify when necessary?
>>> On Win and Linux we were calling it properly for popups, but on mac os x we haven't been doing that. The new version of the fix fixes that.
>> Thanks for this check. Is it possible to create a new test for this issue?
>>> The new version is here:
>>> http://cr.openjdk.java.net/~pchelko/9/8007220/webrev.01/
>>>
>>> With best regards. Petr.
>>>
>>> On 16.12.2013, at 16:38, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>>
>>>> Hi, Petr.
>>>> Since you add new call to addNotify(), can you check that we call removeNotify when necessary?
>>>>
>>>> On 16.12.2013 16:02, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>>
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8007220
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8007220/webrev/
>>>>>
>>>>> The problem: the CTrayIcon.popup field was set only in a constructor, but it should be updated every time the popup is opened.
>>>>>
>>>>> With best regards. Petr.
>>>> -- 
>>>> Best regards, Sergey.
>>>>
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From anton.tarasov at oracle.com  Fri Dec 20 06:29:30 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 20 Dec 2013 18:29:30 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52B3802E.8070304@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com> <52B16A18.4060301@oracle.com>
	<52B21B83.4090209@oracle.com> <52B2EC02.2070005@oracle.com>
	<52B3802E.8070304@oracle.com>
Message-ID: <52B4544A.7010008@oracle.com>

On 20.12.2013 3:24, Jim Graham wrote:
> I'm starting to get the full picture now.  Certainly, if we could share bits via the FX/Swing 
> bridge then we could avoid the BufferedImage in the middle.  There used to be support in Scenario 
> for the "resource sharing" layer that Dmitri and Chris put into Java2D to grab texture IDs 
> directly from Java2D.  Could that be re-leveraged more easily than fixing this bug?

This will require rewriting the whole fx/swing interface which is currently based on exchanging an 
int array of pixels (see the sun.swing.LightweightContent interface). Along with the "texture 
sharing" implementation (which I can't estimate as I don't have any good experience in OpenGL/D3D 
stuff), this is not going to be easier than the current fix. I'm afraid this is much more 
complicated task...

>
> One question about your non-double-buffered experiment below.  You said that it didn't have any 
> noticeable affect on performance.  Is that "the same as using a VI and a VI->BI copy"?  Or is it 
> "the same as using a BI the whole way"?  I didn't understand which other scenario you were 
> comparing its performance to.

I compared two scenarious:

1) Swing uses a BufferedImage as its double buffer (volatile off).
2) Swing doesn't use a double buffer at all, in which case all the drawings happen directly to the 
root Graphics (except that Nimbus uses some intermediate BI buffers to draw ui elements).

>
> If we still find some value in using VI on the Swing side, then how does the performance of 
> rendering VI->BI differ from a direct pixel readback on the VI?  I would hope that they were the 
> same, but perhaps we are being stupid in the VI->BI copy loops.  If readback is faster, could we 
> modify the bridge to do a more direct readback rather than a drawImage operation?  Have you traced 
> the code to see where the performance is going when we use the current VI->BI copies?  Maybe we 
> are just missing a more direct copy loop in our list of loops?

I debugged the java side of the drawImage call. What I saw is that it went into 
OGLSurfaceToSwBlit.Blit method with src == CGLOffScreenSurfaceData, dst == BufImgSurfaceData. It 
then created an OGLRenderQueue, prepared an op buffer, and eventually flushed the queue. The flush 
procedure took that long.

Thanks,
Anton.

>
>             ...jim
>
> On 12/19/13 4:52 AM, Anton V. Tarasov wrote:
>> Hi Jim and all,
>>
>> Thinking of getting rid of the need to use BuffedImage at all for JLF,
>> I'm facing the following obstacles:
>>
>> 1. We have to forse developers to use a buffered image as a double
>> buffer (currently by means of setting the corresponding property),
>> because of the performance issue I'd mentioned
>> (https://javafx-jira.kenai.com/browse/RT-30035). I investigated it a
>> little. My assumption was that the problem is in copying from a volatile
>> image to a buffered image (which Swing performs to flush its double
>> buffer to Graphics which is tight to the root BufferedImage, containing
>> the pixels of the JLF'c content). And that's the case. Measurement
>> showed that copying b/w volatile and buffered works up to 300 times
>> slower than copying b/w buffered and buffered. (This is what I see on my
>> Mac, where AWT uses OpenGL). It dropps performance drastically.
>>
>> As an alternative, we can switch off double buffering at all. I checked
>> how it affects the performance (theoretically, it should increase it). I
>> didn't see any noticable difference... (perhaps, that's because there're
>> so much buffers b/w fx & swing, that one buffer less doesn't change the
>> picture radically). But switching off double buffering changes the
>> default behavior. Theoretically it can surprise the code that relies on it.
>>
>> 2. JViewport, in the interop mode, is forsedly switched to BACKINGSTORE
>> (that is a BufferedImage). (By the way, here we also change the default
>> behavior). This probably will be resolved in the future.
>>
>> 3. nimbus.AbstractRegionPainter takes a GraphicsConfig from the Graphics
>> (which is tight to the BufferedImage, the roor buffer for JLF) and
>> creates an Image based on it. As the Graphics is derived from BI, the
>> result is BI as well. So far, I don't know if we can change this
>> behavior for the AbstractRegionPainter.
>>
>> We could originally create a VolatileImage (the root image for JLF),
>> however with a volatile buffer we will face the same performance issue
>> when we extract pixels from it. The "unified rendering" (exchanging bits
>> on GPU) is cool idea, but no one started it yet.
>>
>> On 19.12.2013 2:02, Jim Graham wrote:
>>> Hi Anton,
>>>
>>> I don't know enough about the overall architecture yet to be too
>>> specific about possible solutions at this point.  Here are some
>>> questions that I still don't know the answer to...
>>>
>>> - I'm assuming that Swing gets its back buffer from the
>>> getOffscreenBuffer call because that was what you modified to return a
>>> HiDPI image.  When Swing calls it internally, does it ever leak that
>>> instance?  Could it use a different API to get that back buffer so
>>> that the public API doesn't change?
>>
>> I'm afraid it can't. It calls the public method to create a double
>> buffer, so that a custom RepaintManager could override it for instance.
>> However, here's what comments in the code says:
>>
>>      // Support for both the standard and volatile offscreen buffers
>> exists to
>>      // provide backwards compatibility for the [rare] programs which
>> may be
>>      // calling getOffScreenBuffer() and not expecting to get a
>> VolatileImage.
>>      // Swing internally is migrating to use *only* the volatile image
>> buffer.
>>
>>      // Support for standard offscreen buffer
>>      //
>>      DoubleBufferInfo standardDoubleBuffer;
>>
>> "Rare programs" may be calling the method. Swing long ago migrated to
>> volatile buffers, for which there's another public method:
>> getVolatileOffscreenBuffer().  Also, the comments seem outdated saying
>> that it supports both the standard and volatile buffers. Currently, it
>> only supports standard offscreen buffer.
>>
>>>
>>>
>>> - The method returns Image.  If worse comes to worst then we could try
>>> to hide the identity of the BI that gets returned, but that would be
>>> an awkward wrapper object, so hopefully a different solution works.
>>>
>>> - Do we need to provide "automatically scaled image buffers" to
>>> developers that request one?  I'm guessing that the standard practice
>>> for DB in Swing is that the Swing code manages the image used for the
>>> back buffer, but does the developer ever get involved in that process
>>> such that we need to have magically scaled images in their hands?
>>
>> A custom RepaintManager can theoretically interfere in the process of
>> double buffer management. It can draw some additional pixels to it or
>> something of the like (I'll ask Alexander Potochkin, a former Swing
>> owner, who should know much about it).
>>
>>>
>>>
>>> - My impression was that there is some code in Swing that allocates
>>> the backbuffer, tells the Swing tree of JComponents to render into it,
>>> then draws that image to the screen.  Logically it might look
>>> something like this:
>>>
>>> backbuffer = createBackBuffer(w, h);
>>> // ...
>>> comp.paint(backbuffer.getGraphics());
>>> // ...
>>> screengraphics.drawImage(backbuffer, x, y, null);
>>>
>>> (though those lines of code may be spread across a number of methods
>>> for all I know)
>>>
>>> Instead if it did this:
>>>
>>> backbuffer = createBackBuffer(w*scale, h*scale);
>>> // backbuffer.getWidth,Height() return w*scale, h*scale, but we don't
>>> care
>>> // ...
>>> Graphics g = backbuffer.getGraphics();
>>> g.scale(scale, scale);
>>> comp.paint(g);
>>> // ...
>>> // this call forces the logical size of the image without any special
>>> // processing or instance recognition in SG2D
>>> screengraphics.drawImage(backbuffer, x, y, w, h, null);
>>>
>>> then we don't need any fancy wrappers or anything.  This doesn't solve
>>> any "manual double buffering" that a developer would do, though, but
>>> it evades return values from public methods that have "mismatched
>>> BufferedImage objects"...
>>
>> This is possible for RepaintManager and JViewport, but looks not direct
>> for nimbus.AbstractRegionPainter where the moment of image creation is
>> quite distant from its actual painting (the logic is spread across
>> multiple calls)... But I can look at it deeper.
>>
>> Thanks,
>> Anton.
>>
>>>
>>>             ...jim
>>>
>>> On 12/18/13 1:25 AM, Anton V. Tarasov wrote:
>>>> Hi Jim,
>>>>
>>>> Thanks for noticing (sorry, but I simply forgot to check we don't export
>>>> the buffer...) What can we do about that? I have the following thoughts:
>>>>
>>>> 1) We can warn developers to be ready for a HiDPI raster when they call
>>>> that method under the following conditions: 1) the interop mode, 2)
>>>> MacOSX 3) a Retina display.
>>>> 2) In case the method is called, we can create a "shadow buffer" and
>>>> start to sync it with the main buffer. The main buffer will be scaled to
>>>> the shadow buffer on every repaint cycle.
>>>> 3) We can introduce an internal property which will switch on/off the
>>>> 2nd scenario. For instance, a developer may ask for the buffer and don't
>>>> bother about its hidpi raster.
>>>>
>>>> Yes, I understand the solutions are far from perfect, but please take
>>>> into account, the interop is a special mode where we (and developers)
>>>> should be ready for compromises...
>>>>
>>>> What do you think? Do you have any better solutions in mind?
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>>
>>>> On 18.12.2013 5:03, Jim Graham wrote:
>>>>> Hi Anton,
>>>>>
>>>>> javax.swing.RepaintManager.getOffscreenBuffer is a public method that
>>>>> can now return one of the new HiDPI offscreen images which is a
>>>>> subclass of BufferedImage.  This was what I was worried about in terms
>>>>> of one of these internal double buffers leaking to developer code.  If
>>>>> they test the image using instanceof they will see that it is a
>>>>> BufferdImage and they may try to dig out the raster and get confused...
>>>>>
>>>>>             ...jim
>>>>>
>>>>> On 12/17/13 10:21 AM, Anton V. Tarasov wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Please look at the new version:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2
>>>>>>
>>>>>> It contains the following changes:
>>>>>>
>>>>>> - All the scale related stuff is moved to the new class:
>>>>>> OffScreenHiDPIImage.java
>>>>>>
>>>>>> - JViewport and RepaintManager no longer cache buffers.
>>>>>>
>>>>>> - JLightweightFrame has new method: createHiDPIImage(w, h).
>>>>>>
>>>>>> - JViewport, RepaintManager and AbstractRegionPainter goes the new
>>>>>> path
>>>>>> to create a HiDPI buffered image.
>>>>>>
>>>>>> - A new internal property is added: "swing.jlf.hidpiImageEnabled".
>>>>>> False
>>>>>> by default. It makes JLF.createImage(w, h) forward the call to
>>>>>> JLF.createHiDPIImage(w, h). This can be used by a third party code in
>>>>>> case it creates a buffered image via Component.createImage(w, h) and
>>>>>> uses the image so that it can benefit from being a HiDPI image on a
>>>>>> Retina display.
>>>>>>
>>>>>> For instance, SwingSet2 has an animating Bezier curve demo. Switching
>>>>>> the property on makes the curve auto scale smoothly. Please, look
>>>>>> at the
>>>>>> screenshots:
>>>>>>
>>>>>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/RoughtCurve.png
>>>>>> -- http://cr.openjdk.java.net/~ant/JDK-8029455/SmoothCurve.png
>>>>>>
>>>>>> - SunGraphics2D now draws a HiDPI buffered image the same way it
>>>>>> draws a
>>>>>> VolatileImage.
>>>>>>
>>>>>> - I've removed the copyArea() method from the BufImgSurfaceData, and
>>>>>> modified the original version. The only question I have is: do I
>>>>>> need to
>>>>>> check for "instanceof OffScreenHiDPIImage.SurfaceData" in case when
>>>>>> "transformState == TRANSFORM_TRANSLATESCALE"? If this method is
>>>>>> invoked
>>>>>> with some other SD, and the transform is SCALE, will it do the job
>>>>>> with
>>>>>> the coordinates conversion done?
>>>>>>
>>>>>> - I've left the new methods in FramePeer default... May yet we
>>>>>> implement
>>>>>> them in other peers when we really need it?
>>>>>>
>>>>>> - CPlatformLWWindow.getGraphicsDevice() checks for an intersection +
>>>>>> scale. This heuristic actually may fail when a Window is moved b/w
>>>>>> three
>>>>>> or four displays so that it intersects them all at some time. JFX will
>>>>>> set a new scale factor in between and AWT may pick up a wrong
>>>>>> device. I
>>>>>> don't know any simple solution for that. For two monitors this will
>>>>>> work.
>>>>>>
>>>>>> Thanks,
>>>>>> Anton.
>>>>
>>


From christophe.cornu at gmail.com  Fri Dec 20 06:41:09 2013
From: christophe.cornu at gmail.com (Christophe Cornu)
Date: Fri, 20 Dec 2013 09:41:09 -0500
Subject: <AWT Dev> Embedding native widgets into AWT Canvas on Mac - NSView
 / CALayer pb in JDK1.7
Message-ID: <CAE1C_g8=LBXUdQ-sbemXaz3jsUQW2N8VYAZ7gaPcNM17CaWjbA@mail.gmail.com>

Hello:

Since JDK1.7, Canvas is no longer backed up by an NSView. This broke a few
projects, e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=418245. It's
no longer possible to embed inside AWT things like SWT widgets, Apple
WebView component (which extends NSView).

What do the AWT committers think going forward? Will it be possible to have
an internal Canvas class that would be backed up by NSView, to be used by
embedders? Or should we give up the idea of plugging in native widgets into
AWT through NSView and treat CALayer as the way forward?

Thanks for any thoughts you have on this,

Chrix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131220/14b9f493/attachment.html 

From philip.race at oracle.com  Fri Dec 20 12:58:28 2013
From: philip.race at oracle.com (Phil Race)
Date: Fri, 20 Dec 2013 12:58:28 -0800
Subject: <AWT Dev> JDK 9 RFR of 8030845: Fix doclint missing issues in
 java.awt.event
In-Reply-To: <52B3DD1E.8020204@oracle.com>
References: <52B3DD1E.8020204@oracle.com>
Message-ID: <52B4AF74.60106@oracle.com>


> /** Constant for the substract key. */

I think you can subtract an s here :-)

actually I'd call it "number pad subtract key" like you did
with add and do the same for  multiply and divide too.

  /** Constant for the decimal key. */

could we call this "decimal point key" ?


There's an extra space in these two :

  /**  Constant for the META  key. */

  /**  Constant for the QUOTE  key. */



/* not clear what this means - listed in Microsoft Windows API */
/** Constant for the FINAL key, listed in the Microsoft Windows API. */
public static final int VK_FINAL                    = 0x0018;

I can't find this listed in any Windows API.
So I am not sure I want to promote this comment to javadoc.
This and MODECHANGE have the same issue, so this is getting a tad
beyond doclint and into spec.

Some one from AWT who is familiar with keyboard mappings needs to comment.

-phil

On 12/19/2013 10:01 PM, Joe Darcy wrote:
> Hello,
>
> Please review my changes to address
>
>     8030845: Fix doclint missing issues in java.awt.event
>
> in JDK 9. Webrev at
>
>     http://cr.openjdk.java.net/~darcy/8030845.0/
>
> patch below.
>
> Thanks,
>
> -Joe
>
> --- old/src/share/classes/java/awt/event/AWTEventListener.java 
> 2013-12-19 21:48:44.000000000 -0800
> +++ new/src/share/classes/java/awt/event/AWTEventListener.java 
> 2013-12-19 21:48:44.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1998, 2003, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -56,6 +56,7 @@
>
>      /**
>       * Invoked when an event is dispatched in the AWT.
> +     * @param event the event to be processed
>       */
>      public void eventDispatched(AWTEvent event);
>
> --- old/src/share/classes/java/awt/event/ActionListener.java 
> 2013-12-19 21:48:45.000000000 -0800
> +++ new/src/share/classes/java/awt/event/ActionListener.java 
> 2013-12-19 21:48:44.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -46,6 +46,7 @@
>
>      /**
>       * Invoked when an action occurs.
> +     * @param e the event to be processed
>       */
>      public void actionPerformed(ActionEvent e);
>
> --- old/src/share/classes/java/awt/event/AdjustmentListener.java 
> 2013-12-19 21:48:45.000000000 -0800
> +++ new/src/share/classes/java/awt/event/AdjustmentListener.java 
> 2013-12-19 21:48:45.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 1999, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -37,6 +37,7 @@
>
>      /**
>       * Invoked when the value of the adjustable has changed.
> +     * @param e the event to be processed
>       */
>      public void adjustmentValueChanged(AdjustmentEvent e);
>
> --- old/src/share/classes/java/awt/event/ComponentListener.java 
> 2013-12-19 21:48:46.000000000 -0800
> +++ new/src/share/classes/java/awt/event/ComponentListener.java 
> 2013-12-19 21:48:46.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -54,21 +54,25 @@
>  public interface ComponentListener extends EventListener {
>      /**
>       * Invoked when the component's size changes.
> +     * @param e the event to be processed
>       */
>      public void componentResized(ComponentEvent e);
>
>      /**
>       * Invoked when the component's position changes.
> +     * @param e the event to be processed
>       */
>      public void componentMoved(ComponentEvent e);
>
>      /**
>       * Invoked when the component has been made visible.
> +     * @param e the event to be processed
>       */
>      public void componentShown(ComponentEvent e);
>
>      /**
>       * Invoked when the component has been made invisible.
> +     * @param e the event to be processed
>       */
>      public void componentHidden(ComponentEvent e);
>  }
> --- old/src/share/classes/java/awt/event/ContainerListener.java 
> 2013-12-19 21:48:46.000000000 -0800
> +++ new/src/share/classes/java/awt/event/ContainerListener.java 
> 2013-12-19 21:48:46.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -55,11 +55,13 @@
>  public interface ContainerListener extends EventListener {
>      /**
>       * Invoked when a component has been added to the container.
> +     * @param e the event to be processed
>       */
>      public void componentAdded(ContainerEvent e);
>
>      /**
>       * Invoked when a component has been removed from the container.
> +     * @param e the event to be processed
>       */
>      public void componentRemoved(ContainerEvent e);
>
> --- old/src/share/classes/java/awt/event/FocusListener.java 2013-12-19 
> 21:48:47.000000000 -0800
> +++ new/src/share/classes/java/awt/event/FocusListener.java 2013-12-19 
> 21:48:46.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -51,11 +51,13 @@
>
>      /**
>       * Invoked when a component gains the keyboard focus.
> +     * @param e the event to be processed
>       */
>      public void focusGained(FocusEvent e);
>
>      /**
>       * Invoked when a component loses the keyboard focus.
> +     * @param e the event to be processed
>       */
>      public void focusLost(FocusEvent e);
>  }
> --- old/src/share/classes/java/awt/event/HierarchyBoundsListener.java 
> 2013-12-19 21:48:47.000000000 -0800
> +++ new/src/share/classes/java/awt/event/HierarchyBoundsListener.java 
> 2013-12-19 21:48:47.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1999, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -52,11 +52,13 @@
>  public interface HierarchyBoundsListener extends EventListener {
>      /**
>       * Called when an ancestor of the source is moved.
> +     * @param e the event to be processed
>       */
>      public void ancestorMoved(HierarchyEvent e);
>
>      /**
>       * Called when an ancestor of the source is resized.
> +     * @param e the event to be processed
>       */
>      public void ancestorResized(HierarchyEvent e);
>  }
> --- old/src/share/classes/java/awt/event/HierarchyListener.java 
> 2013-12-19 21:48:48.000000000 -0800
> +++ new/src/share/classes/java/awt/event/HierarchyListener.java 
> 2013-12-19 21:48:47.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1999, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -51,6 +51,7 @@
>       * Called when the hierarchy has been changed. To discern the actual
>       * type of change, call 
> <code>HierarchyEvent.getChangeFlags()</code>.
>       *
> +     * @param e the event to be processed
>       * @see HierarchyEvent#getChangeFlags()
>       */
>      public void hierarchyChanged(HierarchyEvent e);
> --- old/src/share/classes/java/awt/event/InputEvent.java 2013-12-19 
> 21:48:48.000000000 -0800
> +++ new/src/share/classes/java/awt/event/InputEvent.java 2013-12-19 
> 21:48:48.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2010, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -233,7 +233,8 @@
>       * This limit is defined by the relevant number
>       * of buttons that may hypothetically exist on the mouse but it 
> is greater than the
>       * {@link java.awt.MouseInfo#getNumberOfButtons() 
> MouseInfo.getNumberOfButtons()}.
> -     * <p>
> +     *
> +     * @return a mask for an existing mouse button.
>       * @throws IllegalArgumentException if {@code button} is less 
> than zero or greater than the number
>       *         of button masks reserved for buttons
>       * @since 7.0
> @@ -368,6 +369,7 @@
>
>      /**
>       * Returns whether or not the Shift modifier is down on this event.
> +     * @return whether or not the Shift modifier is down on this event
>       */
>      public boolean isShiftDown() {
>          return (modifiers & SHIFT_MASK) != 0;
> @@ -375,6 +377,7 @@
>
>      /**
>       * Returns whether or not the Control modifier is down on this 
> event.
> +     * @return whether or not the Control modifier is down on this event
>       */
>      public boolean isControlDown() {
>          return (modifiers & CTRL_MASK) != 0;
> @@ -382,6 +385,7 @@
>
>      /**
>       * Returns whether or not the Meta modifier is down on this event.
> +     * @return whether or not the Meta modifier is down on this event
>       */
>      public boolean isMetaDown() {
>          return (modifiers & META_MASK) != 0;
> @@ -389,6 +393,7 @@
>
>      /**
>       * Returns whether or not the Alt modifier is down on this event.
> +     * @return whether or not the Alt modifier is down on this event
>       */
>      public boolean isAltDown() {
>          return (modifiers & ALT_MASK) != 0;
> @@ -396,6 +401,7 @@
>
>      /**
>       * Returns whether or not the AltGraph modifier is down on this 
> event.
> +     * @return whether or not the AltGraph modifier is down on this 
> event
>       */
>      public boolean isAltGraphDown() {
>          return (modifiers & ALT_GRAPH_MASK) != 0;
> @@ -404,6 +410,7 @@
>      /**
>       * Returns the difference in milliseconds between the timestamp 
> of when this event occurred and
>       * midnight, January 1, 1970 UTC.
> +     * @return the difference in milliseconds between the timestamp 
> and midnight, January 1, 1970 UTC
>       */
>      public long getWhen() {
>          return when;
> @@ -411,6 +418,7 @@
>
>      /**
>       * Returns the modifier mask for this event.
> +     * @return the modifier mask for this event
>       */
>      public int getModifiers() {
>          return modifiers & (JDK_1_3_MODIFIERS | HIGH_MODIFIERS);
> @@ -451,6 +459,7 @@
>       * </PRE>
>       * The above code will work even if new modifiers are added.
>       *
> +     * @return the extended modifier mask for this event
>       * @since 1.4
>       */
>      public int getModifiersEx() {
> @@ -467,6 +476,7 @@
>
>      /**
>       * Returns whether or not this event has been consumed.
> +     * @return whether or not this event has been consumed
>       * @see #consume
>       */
>      public boolean isConsumed() {
> @@ -487,6 +497,9 @@
>       * Zero parameter means that no modifiers were passed and will
>       * cause the returning an empty string.
>       *
> +     * @return a String describing the extended modifier keys and
> +     * mouse buttons
> +     *
>       * @param modifiers a modifier mask describing the extended
>       *                modifier keys and mouse buttons for the event
>       * @return a text description of the combination of extended
> --- old/src/share/classes/java/awt/event/InputMethodEvent.java 
> 2013-12-19 21:48:48.000000000 -0800
> +++ new/src/share/classes/java/awt/event/InputMethodEvent.java 
> 2013-12-19 21:48:48.000000000 -0800
> @@ -277,6 +277,7 @@
>
>      /**
>       * Gets the number of committed characters in the text.
> +     * @return the number of committed characters in the text
>       */
>      public int getCommittedCharacterCount() {
>          return committedCharacterCount;
> --- old/src/share/classes/java/awt/event/InputMethodListener.java 
> 2013-12-19 21:48:49.000000000 -0800
> +++ new/src/share/classes/java/awt/event/InputMethodListener.java 
> 2013-12-19 21:48:49.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1997, 1999, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -40,17 +40,17 @@
>   * @see java.awt.im.InputMethodRequests
>   * @since 1.2
>   */
> -
>  public interface InputMethodListener extends EventListener {
>
>      /**
>       * Invoked when the text entered through an input method has 
> changed.
> +     * @param event the event to be processed
>       */
>      void inputMethodTextChanged(InputMethodEvent event);
>
>      /**
>       * Invoked when the caret within composed text has changed.
> +     * @param event the event to be processed
>       */
>      void caretPositionChanged(InputMethodEvent event);
> -
>  }
> --- old/src/share/classes/java/awt/event/ItemListener.java 2013-12-19 
> 21:48:49.000000000 -0800
> +++ new/src/share/classes/java/awt/event/ItemListener.java 2013-12-19 
> 21:48:49.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -50,6 +50,7 @@
>       * Invoked when an item has been selected or deselected by the user.
>       * The code written for this method performs the operations
>       * that need to occur when an item is selected (or deselected).
> +     * @param e the event to be processed
>       */
>      void itemStateChanged(ItemEvent e);
>
> --- old/src/share/classes/java/awt/event/KeyEvent.java 2013-12-19 
> 21:48:50.000000000 -0800
> +++ new/src/share/classes/java/awt/event/KeyEvent.java 2013-12-19 
> 21:48:50.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -132,7 +132,7 @@
>   * <p>
>   * WARNING: Aside from those keys that are defined by the Java language
>   * (VK_ENTER, VK_BACK_SPACE, and VK_TAB), do not rely on the values 
> of the VK_
> - * constants.  Sun reserves the right to change these values as needed
> + * constants.  The platform steward reserves the right to change 
> these values as needed
>   * to accommodate a wider range of keyboards in the future.
>   * <p>
>   * An unspecified behavior will be caused if the {@code id} parameter
> @@ -194,21 +194,52 @@
>
>      /* Virtual key codes. */
>
> +    /** Constant for the ENTER virtual key. */
>      public static final int VK_ENTER          = '\n';
> +
> +    /** Constant for the BACK_SPACE virtual key. */
>      public static final int VK_BACK_SPACE     = '\b';
> +
> +    /** Constant for the TAB virtual key. */
>      public static final int VK_TAB            = '\t';
> +
> +    /** Constant for the CANCEL virtual key. */
>      public static final int VK_CANCEL         = 0x03;
> +
> +    /** Constant for the CLEAR virtual key. */
>      public static final int VK_CLEAR          = 0x0C;
> +
> +    /** Constant for the SHIFT virtual key. */
>      public static final int VK_SHIFT          = 0x10;
> +
> +    /** Constant for the CONTROL virtual key. */
>      public static final int VK_CONTROL        = 0x11;
> +
> +    /** Constant for the ALT. virtual key */
>      public static final int VK_ALT            = 0x12;
> +
> +    /** Constant for the PAUSE virtual key. */
>      public static final int VK_PAUSE          = 0x13;
> +
> +    /** Constant for the CAPS_LOCK virtual key. */
>      public static final int VK_CAPS_LOCK      = 0x14;
> +
> +    /** Constant for the ESCAPE virtual key. */
>      public static final int VK_ESCAPE         = 0x1B;
> +
> +    /** Constant for the SPACE virtual key. */
>      public static final int VK_SPACE          = 0x20;
> +
> +    /** Constant for the PAGE_UP virtual key. */
>      public static final int VK_PAGE_UP        = 0x21;
> +
> +    /** Constant for the PAGE_DOWN virtual key. */
>      public static final int VK_PAGE_DOWN      = 0x22;
> +
> +    /** Constant for the END virtual key. */
>      public static final int VK_END            = 0x23;
> +
> +    /** Constant for the HOME virtual key. */
>      public static final int VK_HOME           = 0x24;
>
>      /**
> @@ -257,15 +288,35 @@
>      public static final int VK_SLASH          = 0x2F;
>
>      /** VK_0 thru VK_9 are the same as ASCII '0' thru '9' (0x30 - 
> 0x39) */
> +
> +    /** Constant for the "0" key. */
>      public static final int VK_0              = 0x30;
> +
> +    /** Constant for the "1" key. */
>      public static final int VK_1              = 0x31;
> +
> +    /** Constant for the "2" key. */
>      public static final int VK_2              = 0x32;
> +
> +    /** Constant for the "3" key. */
>      public static final int VK_3              = 0x33;
> +
> +    /** Constant for the "4" key. */
>      public static final int VK_4              = 0x34;
> +
> +    /** Constant for the "5" key. */
>      public static final int VK_5              = 0x35;
> +
> +    /** Constant for the "6" key. */
>      public static final int VK_6              = 0x36;
> +
> +    /** Constant for the "7" key. */
>      public static final int VK_7              = 0x37;
> +
> +    /** Constant for the "8" key. */
>      public static final int VK_8              = 0x38;
> +
> +    /** Constant for the "9" key. */
>      public static final int VK_9              = 0x39;
>
>      /**
> @@ -279,31 +330,83 @@
>      public static final int VK_EQUALS         = 0x3D;
>
>      /** VK_A thru VK_Z are the same as ASCII 'A' thru 'Z' (0x41 - 
> 0x5A) */
> +
> +    /** Constant for the "A" key. */
>      public static final int VK_A              = 0x41;
> +
> +    /** Constant for the "B" key. */
>      public static final int VK_B              = 0x42;
> +
> +    /** Constant for the "C" key. */
>      public static final int VK_C              = 0x43;
> +
> +    /** Constant for the "D" key. */
>      public static final int VK_D              = 0x44;
> +
> +    /** Constant for the "E" key. */
>      public static final int VK_E              = 0x45;
> +
> +    /** Constant for the "F" key. */
>      public static final int VK_F              = 0x46;
> +
> +    /** Constant for the "G" key. */
>      public static final int VK_G              = 0x47;
> +
> +    /** Constant for the "H" key. */
>      public static final int VK_H              = 0x48;
> +
> +    /** Constant for the "I" key. */
>      public static final int VK_I              = 0x49;
> +
> +    /** Constant for the "J" key. */
>      public static final int VK_J              = 0x4A;
> +
> +    /** Constant for the "K" key. */
>      public static final int VK_K              = 0x4B;
> +
> +    /** Constant for the "L" key. */
>      public static final int VK_L              = 0x4C;
> +
> +    /** Constant for the "M" key. */
>      public static final int VK_M              = 0x4D;
> +
> +    /** Constant for the "N" key. */
>      public static final int VK_N              = 0x4E;
> +
> +    /** Constant for the "O" key. */
>      public static final int VK_O              = 0x4F;
> +
> +    /** Constant for the "P" key. */
>      public static final int VK_P              = 0x50;
> +
> +    /** Constant for the "Q" key. */
>      public static final int VK_Q              = 0x51;
> +
> +    /** Constant for the "R" key. */
>      public static final int VK_R              = 0x52;
> +
> +    /** Constant for the "S" key. */
>      public static final int VK_S              = 0x53;
> +
> +    /** Constant for the "T" key. */
>      public static final int VK_T              = 0x54;
> +
> +    /** Constant for the "U" key. */
>      public static final int VK_U              = 0x55;
> +
> +    /** Constant for the "V" key. */
>      public static final int VK_V              = 0x56;
> +
> +    /** Constant for the "W" key. */
>      public static final int VK_W              = 0x57;
> +
> +    /** Constant for the "X" key. */
>      public static final int VK_X              = 0x58;
> +
> +    /** Constant for the "Y" key. */
>      public static final int VK_Y              = 0x59;
> +
> +    /** Constant for the "Z" key. */
>      public static final int VK_Z              = 0x5A;
>
>      /**
> @@ -321,17 +424,40 @@
>       */
>      public static final int VK_CLOSE_BRACKET  = 0x5D;
>
> +    /** Constant for the number pad "0" key. */
>      public static final int VK_NUMPAD0        = 0x60;
> +
> +    /** Constant for the number pad "1" key. */
>      public static final int VK_NUMPAD1        = 0x61;
> +
> +    /** Constant for the number pad "2" key. */
>      public static final int VK_NUMPAD2        = 0x62;
> +
> +    /** Constant for the number pad "3" key. */
>      public static final int VK_NUMPAD3        = 0x63;
> +
> +    /** Constant for the number pad "4" key. */
>      public static final int VK_NUMPAD4        = 0x64;
> +
> +    /** Constant for the number pad "5" key. */
>      public static final int VK_NUMPAD5        = 0x65;
> +
> +    /** Constant for the number pad "6" key. */
>      public static final int VK_NUMPAD6        = 0x66;
> +
> +    /** Constant for the number pad "7" key. */
>      public static final int VK_NUMPAD7        = 0x67;
> +
> +    /** Constant for the number pad "8" key. */
>      public static final int VK_NUMPAD8        = 0x68;
> +
> +    /** Constant for the number pad "9" key. */
>      public static final int VK_NUMPAD9        = 0x69;
> +
> +    /** Constant for the number pad multiply key. */
>      public static final int VK_MULTIPLY       = 0x6A;
> +
> +    /** Constant for the number pad add key. */
>      public static final int VK_ADD            = 0x6B;
>
>      /**
> @@ -347,11 +473,22 @@
>       */
>      public static final int VK_SEPARATOR      = VK_SEPARATER;
>
> +    /** Constant for the substract key. */
>      public static final int VK_SUBTRACT       = 0x6D;
> +
> +    /** Constant for the decimal key. */
>      public static final int VK_DECIMAL        = 0x6E;
> +
> +    /** Constant for the divide key. */
>      public static final int VK_DIVIDE         = 0x6F;
> +
> +    /** Constant for the delete key. */
>      public static final int VK_DELETE         = 0x7F; /* ASCII DEL */
> +
> +    /** Constant for the NUM_LOCK key. */
>      public static final int VK_NUM_LOCK       = 0x90;
> +
> +    /** Constant for the SCROLL_LOCK key. */
>      public static final int VK_SCROLL_LOCK    = 0x91;
>
>      /** Constant for the F1 function key. */
> @@ -463,12 +600,22 @@
>       */
>      public static final int VK_F24            = 0xF00B;
>
> +    /**  Constant for the PRINTSCREEN key. */
>      public static final int VK_PRINTSCREEN    = 0x9A;
> +
> +    /**  Constant for the INSERT key. */
>      public static final int VK_INSERT         = 0x9B;
> +
> +    /**  Constant for the HELP key. */
>      public static final int VK_HELP           = 0x9C;
> +
> +    /**  Constant for the META  key. */
>      public static final int VK_META           = 0x9D;
>
> +    /**  Constant for the BACK_QUOTE  key. */
>      public static final int VK_BACK_QUOTE     = 0xC0;
> +
> +    /**  Constant for the QUOTE  key. */
>      public static final int VK_QUOTE          = 0xDE;
>
>      /**
> @@ -638,6 +785,7 @@
>      /* for input method support on Asian Keyboards */
>
>      /* not clear what this means - listed in Microsoft Windows API */
> +    /** Constant for the FINAL key, listed in the Microsoft Windows 
> API. */
>      public static final int VK_FINAL                    = 0x0018;
>
>      /** Constant for the Convert function key. */
> @@ -653,14 +801,23 @@
>      public static final int VK_ACCEPT                   = 0x001E;
>
>      /* not clear what this means - listed in Microsoft Windows API */
> +    /** Constant for the MODECHANGE key, listed in the Microsoft 
> Windows API. */
>      public static final int VK_MODECHANGE               = 0x001F;
>
>      /* replaced by VK_KANA_LOCK for Microsoft Windows and Solaris;
>         might still be used on other platforms */
> +    /**
> +     * Constant for the KANA lock key.
> +     * @see #VK_KANA_LOCK
> +     **/
>      public static final int VK_KANA                     = 0x0015;
>
>      /* replaced by VK_INPUT_METHOD_ON_OFF for Microsoft Windows and 
> Solaris;
>         might still be used for other platforms */
> +    /**
> +     * Constant for KANJI.
> +     * @see #VK_INPUT_METHOD_ON_OFF
> +     */
>      public static final int VK_KANJI                    = 0x0019;
>
>      /**
> @@ -1085,7 +1242,25 @@
>      }
>
>      /**
> -     * @deprecated as of JDK1.1
> +     * @deprecated as of JDK1.1; use {@link #KeyEvent(Component, int, 
> long, int, int, char)} instead
> +     * @param source    The <code>Component</code> that originated 
> the event
> +     * @param id              An integer indicating the type of event.
> +     *                  For information on allowable values, see
> +     *                  the class description for {@link KeyEvent}
> +     * @param when      A long integer that specifies the time the event
> +     *                  occurred.
> +     *                     Passing negative or zero value
> +     *                     is not recommended
> +     * @param modifiers The modifier keys down during event (shift, 
> ctrl,
> +     *                  alt, meta).
> +     *                     Passing negative value
> +     *                     is not recommended.
> +     *                     Zero value means that no modifiers were 
> passed.
> +     *                  Use either an extended _DOWN_MASK or old 
> _MASK modifiers,
> +     *                  however do not mix models in the one event.
> +     *                  The extended modifiers are preferred for using
> +     * @param keyCode   The integer code for an actual key, or 
> VK_UNDEFINED
> +     *                  (for a key-typed event)
>       */
>      @Deprecated
>      public KeyEvent(Component source, int id, long when, int modifiers,
> @@ -1184,6 +1359,7 @@
>       * Returns a String describing the keyCode, such as "HOME", "F1" 
> or "A".
>       * These strings can be localized by changing the awt.properties 
> file.
>       *
> +     * @param keyCode the key whose description is to be returned
>       * @return a string containing a text description for a physical 
> key,
>       *         identified by its keyCode
>       */
> @@ -1376,6 +1552,7 @@
>       * <code>InputEvent.BUTTON3_MASK</code> have the same value,
>       * so the string "Meta" is returned for both modifiers.
>       *
> +     * @param modifiers the modifier mask to be processed
>       * @return string a text description of the combination of modifier
>       *                keys that were held down during the event
>       * @see InputEvent#getModifiersExText(int)
> @@ -1612,8 +1789,8 @@
>       * Pressing the same key in a regular Russian layout gives 
> another code, unique for the
>       * letter "Cyrillic I short".
>       *
> +     * @return an extended key code for the event
>       * @since 1.7
> -     *
>       */
>      public  int getExtendedKeyCode() {
>          return (int)extendedKeyCode;
> @@ -1621,6 +1798,7 @@
>      /**
>       * Returns an extended key code for a unicode character.
>       *
> +     * @param c the unicode character to be processed
>       * @return for a unicode character with a corresponding {@code 
> VK_} constant -- this
>       *   {@code VK_} constant; for a character appearing on the primary
>       *   level of a known keyboard layout -- a unique integer.
> @@ -1628,7 +1806,6 @@
>       *   {@code VK_UNDEFINED} is returned.
>       *
>       * @since 1.7
> -     *
>       */
>      public static int getExtendedKeyCodeForChar(int c) {
>          // Return a keycode (if any) associated with a character.
> --- old/src/share/classes/java/awt/event/KeyListener.java 2013-12-19 
> 21:48:50.000000000 -0800
> +++ new/src/share/classes/java/awt/event/KeyListener.java 2013-12-19 
> 21:48:50.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -54,6 +54,7 @@
>       * Invoked when a key has been typed.
>       * See the class description for {@link KeyEvent} for a 
> definition of
>       * a key typed event.
> +     * @param e the event to be processed
>       */
>      public void keyTyped(KeyEvent e);
>
> @@ -61,6 +62,7 @@
>       * Invoked when a key has been pressed.
>       * See the class description for {@link KeyEvent} for a 
> definition of
>       * a key pressed event.
> +     * @param e the event to be processed
>       */
>      public void keyPressed(KeyEvent e);
>
> @@ -68,6 +70,7 @@
>       * Invoked when a key has been released.
>       * See the class description for {@link KeyEvent} for a 
> definition of
>       * a key released event.
> +     * @param e the event to be processed
>       */
>      public void keyReleased(KeyEvent e);
>  }
> --- old/src/share/classes/java/awt/event/MouseListener.java 2013-12-19 
> 21:48:51.000000000 -0800
> +++ new/src/share/classes/java/awt/event/MouseListener.java 2013-12-19 
> 21:48:51.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -59,26 +59,31 @@
>      /**
>       * Invoked when the mouse button has been clicked (pressed
>       * and released) on a component.
> +     * @param e the event to be processed
>       */
>      public void mouseClicked(MouseEvent e);
>
>      /**
>       * Invoked when a mouse button has been pressed on a component.
> +     * @param e the event to be processed
>       */
>      public void mousePressed(MouseEvent e);
>
>      /**
>       * Invoked when a mouse button has been released on a component.
> +     * @param e the event to be processed
>       */
>      public void mouseReleased(MouseEvent e);
>
>      /**
>       * Invoked when the mouse enters a component.
> +     * @param e the event to be processed
>       */
>      public void mouseEntered(MouseEvent e);
>
>      /**
>       * Invoked when the mouse exits a component.
> +     * @param e the event to be processed
>       */
>      public void mouseExited(MouseEvent e);
>  }
> --- old/src/share/classes/java/awt/event/MouseMotionListener.java 
> 2013-12-19 21:48:51.000000000 -0800
> +++ new/src/share/classes/java/awt/event/MouseMotionListener.java 
> 2013-12-19 21:48:51.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -63,12 +63,14 @@
>       * Due to platform-dependent Drag&amp;Drop implementations,
>       * <code>MOUSE_DRAGGED</code> events may not be delivered during 
> a native
>       * Drag&amp;Drop operation.
> +     * @param e the event to be processed
>       */
>      public void mouseDragged(MouseEvent e);
>
>      /**
>       * Invoked when the mouse cursor has been moved onto a component
>       * but no buttons have been pushed.
> +     * @param e the event to be processed
>       */
>      public void mouseMoved(MouseEvent e);
>
> --- old/src/share/classes/java/awt/event/MouseWheelListener.java 
> 2013-12-19 21:48:52.000000000 -0800
> +++ new/src/share/classes/java/awt/event/MouseWheelListener.java 
> 2013-12-19 21:48:52.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2000, 2003, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -52,6 +52,7 @@
>
>      /**
>       * Invoked when the mouse wheel is rotated.
> +     * @param e the event to be processed
>       * @see MouseWheelEvent
>       */
>      public void mouseWheelMoved(MouseWheelEvent e);
> --- old/src/share/classes/java/awt/event/PaintEvent.java 2013-12-19 
> 21:48:52.000000000 -0800
> +++ new/src/share/classes/java/awt/event/PaintEvent.java 2013-12-19 
> 21:48:52.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2008, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -108,6 +108,8 @@
>      /**
>       * Returns the rectangle representing the area which needs to be
>       * repainted in response to this event.
> +     * @return the rectangle representing the area which needs to be
> +     * repainted in response to this event
>       */
>      public Rectangle getUpdateRect() {
>          return updateRect;
> --- old/src/share/classes/java/awt/event/TextListener.java 2013-12-19 
> 21:48:53.000000000 -0800
> +++ new/src/share/classes/java/awt/event/TextListener.java 2013-12-19 
> 21:48:52.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2008, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -49,6 +49,8 @@
>       * Invoked when the value of the text has changed.
>       * The code written for this method performs the operations
>       * that need to occur when text changes.
> +     *
> +     * @param e the event to be processed
>       */
>      public void textValueChanged(TextEvent e);
>
> --- old/src/share/classes/java/awt/event/WindowFocusListener.java 
> 2013-12-19 21:48:53.000000000 -0800
> +++ new/src/share/classes/java/awt/event/WindowFocusListener.java 
> 2013-12-19 21:48:53.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2000, 2006, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -57,6 +57,7 @@
>       * Invoked when the Window is set to be the focused Window, which 
> means
>       * that the Window, or one of its subcomponents, will receive 
> keyboard
>       * events.
> +     * @param e the event to be processed
>       */
>      public void windowGainedFocus(WindowEvent e);
>
> @@ -64,6 +65,7 @@
>       * Invoked when the Window is no longer the focused Window, which 
> means
>       * that keyboard events will no longer be delivered to the Window 
> or any of
>       * its subcomponents.
> +     * @param e the event to be processed
>       */
>      public void windowLostFocus(WindowEvent e);
>  }
> --- old/src/share/classes/java/awt/event/WindowListener.java 
> 2013-12-19 21:48:53.000000000 -0800
> +++ new/src/share/classes/java/awt/event/WindowListener.java 
> 2013-12-19 21:48:53.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2003, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -51,18 +51,21 @@
>  public interface WindowListener extends EventListener {
>      /**
>       * Invoked the first time a window is made visible.
> +     * @param e the event to be processed
>       */
>      public void windowOpened(WindowEvent e);
>
>      /**
>       * Invoked when the user attempts to close the window
>       * from the window's system menu.
> +     * @param e the event to be processed
>       */
>      public void windowClosing(WindowEvent e);
>
>      /**
>       * Invoked when a window has been closed as the result
>       * of calling dispose on the window.
> +     * @param e the event to be processed
>       */
>      public void windowClosed(WindowEvent e);
>
> @@ -71,6 +74,7 @@
>       * minimized state. For many platforms, a minimized window
>       * is displayed as the icon specified in the window's
>       * iconImage property.
> +     * @param e the event to be processed
>       * @see java.awt.Frame#setIconImage
>       */
>      public void windowIconified(WindowEvent e);
> @@ -78,6 +82,7 @@
>      /**
>       * Invoked when a window is changed from a minimized
>       * to a normal state.
> +     * @param e the event to be processed
>       */
>      public void windowDeiconified(WindowEvent e);
>
> @@ -88,6 +93,7 @@
>       * as a highlighted title bar. The active Window is always either 
> the
>       * focused Window, or the first Frame or Dialog that is an owner 
> of the
>       * focused Window.
> +     * @param e the event to be processed
>       */
>      public void windowActivated(WindowEvent e);
>
> @@ -98,6 +104,7 @@
>       * highlighted title bar. The active Window is always either the 
> focused
>       * Window, or the first Frame or Dialog that is an owner of the 
> focused
>       * Window.
> +     * @param e the event to be processed
>       */
>      public void windowDeactivated(WindowEvent e);
>  }
> --- old/src/share/classes/java/awt/event/WindowStateListener.java 
> 2013-12-19 21:48:54.000000000 -0800
> +++ new/src/share/classes/java/awt/event/WindowStateListener.java 
> 2013-12-19 21:48:54.000000000 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2001, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -50,6 +50,7 @@
>  public interface WindowStateListener extends EventListener {
>      /**
>       * Invoked when window state is changed.
> +     * @param e the event to be processed
>       */
>      public void windowStateChanged(WindowEvent e);
>  }
>


From swingler at apple.com  Fri Dec 20 16:19:58 2013
From: swingler at apple.com (Mike Swingler)
Date: Fri, 20 Dec 2013 16:19:58 -0800
Subject: <AWT Dev> Embedding native widgets into AWT Canvas on Mac -
 NSView / CALayer pb in JDK1.7
In-Reply-To: <CAE1C_g8=LBXUdQ-sbemXaz3jsUQW2N8VYAZ7gaPcNM17CaWjbA@mail.gmail.com>
References: <CAE1C_g8=LBXUdQ-sbemXaz3jsUQW2N8VYAZ7gaPcNM17CaWjbA@mail.gmail.com>
Message-ID: <A22D01DB-56E0-4BF6-953B-4A5528A0E418@apple.com>

On Dec 20, 2013, at 6:41 AM, Christophe Cornu <christophe.cornu at gmail.com> wrote:

> Hello:
> 
> Since JDK1.7, Canvas is no longer backed up by an NSView. This broke a few projects, e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=418245. It's no longer possible to embed inside AWT things like SWT widgets, Apple WebView component (which extends NSView).
> 
> What do the AWT committers think going forward? Will it be possible to have an internal Canvas class that would be backed up by NSView, to be used by embedders? Or should we give up the idea of plugging in native widgets into AWT through NSView and treat CALayer as the way forward?

The crux of the problem has to do with the applet embedding case, where the underlying primitive provided by the browser is a CALayer, and there is no underlying NSView, and all events are synthetic and re-dispatched through the NPAPI. This enables the sandboxing and cross process rendering that applets require. The entirety of the Java 2D graphics stack in Java 7 now renders using pure OpenGL onto a single canvas, and there is no (significant) NSView or CALayer hierarchy.

To re-introduce an NSView hierarchy, you'd have to split the OpenGL rendering layers between the components that should be atop each JAWT NSView and the components that should be below. The task is not without complexity, but the payoff would be quite significant with respect to event dispatch, and re-enabling all the old embedding designs.

If you'd like to take this on, I'm sure many people would appreciate it, but I want you to be aware of the full complexity of the task. There certainly have been no volunteers thus far.

Regards,
Mike Swingler
Apple Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131220/0f2f2962/attachment.html 

From Sergey.Bylokhov at oracle.com  Mon Dec 23 04:02:28 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 23 Dec 2013 16:02:28 +0400
Subject: <AWT Dev> [9] Review Request: 8030953 SelectionVisible test should
 test multiline selection in case of TextArea
Message-ID: <52B82654.9030100@oracle.com>

Hello.
Please review the fix for jdk 8.
The test for TextArea was copied from the version of 
TextField(JDK-7150100), but TextArea supports multiline selection it 
would be good to test it to increase coverage.

Bug: https://bugs.openjdk.java.net/browse/JDK-8030953
Webrev can be found at: http://cr.openjdk.java.net/~serb/8030953/webrev.00/

-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Mon Dec 23 04:13:40 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 23 Dec 2013 16:13:40 +0400
Subject: <AWT Dev> [9] Review Request: 8030953 SelectionVisible test
	should test multiline selection in case of TextArea
In-Reply-To: <52B82654.9030100@oracle.com>
References: <52B82654.9030100@oracle.com>
Message-ID: <AC66D8B3-FC15-4665-B605-5804DB8EA8D2@oracle.com>

Hello, Sergey.

> Please review the fix for jdk 8.
I assume this should be 9?

The fix looks good.

With best regards. Petr.

On 23.12.2013, at 16:02, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hello.
> Please review the fix for jdk 8.
> The test for TextArea was copied from the version of TextField(JDK-7150100), but TextArea supports multiline selection it would be good to test it to increase coverage.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8030953
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8030953/webrev.00/
> 
> -- 
> Best regards, Sergey.
> 


From Sergey.Bylokhov at oracle.com  Mon Dec 23 04:18:14 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 23 Dec 2013 16:18:14 +0400
Subject: <AWT Dev> [9] Review Request: 8030953 SelectionVisible test
 should test multiline selection in case of TextArea
In-Reply-To: <AC66D8B3-FC15-4665-B605-5804DB8EA8D2@oracle.com>
References: <52B82654.9030100@oracle.com>
	<AC66D8B3-FC15-4665-B605-5804DB8EA8D2@oracle.com>
Message-ID: <52B82A06.60004@oracle.com>

On 23.12.2013 16:13, Petr Pchelko wrote:
> Hello, Sergey.
>
>> Please review the fix for jdk 8.
> I assume this should be 9?
Yes. You are right.
>
> The fix looks good.
>
> With best regards. Petr.
>
> On 23.12.2013, at 16:02, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hello.
>> Please review the fix for jdk 8.
>> The test for TextArea was copied from the version of TextField(JDK-7150100), but TextArea supports multiline selection it would be good to test it to increase coverage.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030953
>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8030953/webrev.00/
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From alexander.zvegintsev at oracle.com  Mon Dec 23 04:17:36 2013
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 23 Dec 2013 16:17:36 +0400
Subject: <AWT Dev> [9] Review Request: 8030953 SelectionVisible test
 should test multiline selection in case of TextArea
In-Reply-To: <52B82654.9030100@oracle.com>
References: <52B82654.9030100@oracle.com>
Message-ID: <52B829E0.4060904@oracle.com>

Hi Sergey,

looks good to me too

Thanks,

Alexander.

On 12/23/2013 04:02 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 8.
> The test for TextArea was copied from the version of 
> TextField(JDK-7150100), but TextArea supports multiline selection it 
> would be good to test it to increase coverage.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8030953
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8030953/webrev.00/
>


From david.buck at oracle.com  Mon Dec 23 04:21:42 2013
From: david.buck at oracle.com (david buck)
Date: Mon, 23 Dec 2013 21:21:42 +0900
Subject: <AWT Dev> review request: JNI use results in UnsatisfiedLinkError
 looking for libmawt.so
Message-ID: <52B82AD6.4030602@oracle.com>

Hi!

I would like to please request a review of my fix for the following issue:

[ JDK-6571600 JNI use results in UnsatisfiedLinkError looking for 
libmawt.so ]
https://bugs.openjdk.java.net/browse/JDK-657160

The root cause of this issue is a name conflict with JNI_OnLoad provided 
by awt_LoadLibrary.c and code loaded manually by the user (usually their 
own JNI libraries). The fix is to use a different name for calling 
dladdr that is much less likely to conflict with any names used by 
customer code.

http://cr.openjdk.java.net/~dbuck/6571600/webrev.01/

Best Regards,
-Buck

From petr.pchelko at oracle.com  Mon Dec 23 04:54:09 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 23 Dec 2013 16:54:09 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7185258 [macosx] Deadlock in
	SunToolKit.realSync()
Message-ID: <E7783763-0169-45FE-94C2-1B0F549068D3@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-7185258
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/7185258/webrev/

The problem:
nativeSyncQueue synchronizes the native event queue. However, there are several situations when a dummy event posted to the native queue is not dispatched. These are our own nested loop in doAWTRunLoop and Cocoa's internal nested loop in NSView:dragImage.

Solution:

1. The interruptNativeSyncQueue was introduced. In case we are waiting for the native event queue this method interrupts waiting, otherwise it's a no-op. This is needed for the following reason: suppose the nativeSyncQueue is called on EDT. While the queue is flushed some event was processed which caused us to call doAWTRunLoop. As EDT is blocked we would have got a deadlock. Interrupting the wait lets EDT flush it's events and lets AppKit exit a nested loop. When the nativeSyncQueue is interrupted we do not immediately exit realSync, but flush EDT and try to sync native queue again. Most likely in this case we would not be in a nested loop and will successfully sync a native queue.

2. A lightweight version of nativeSyncQueue was introduced. This one does not flush the event queue, it only flushes a selector queue. This is needed to not deadlock when realSync was called during DnD. Suppose nativeSyncQueue is called while the app is in the native nested dragging loop. Until dragging operation finishes only dragging-related events will be processed. So we have no opportunity to flush the queue as our dummy event will be blocked by a dragging nested loop.

I've tested it by running almost all awt and swing tests. No new failures, some tests start to pass after the fix.

With best regards. Petr.



From petr.pchelko at oracle.com  Mon Dec 23 04:28:33 2013
From: petr.pchelko at oracle.com (petr.pchelko at oracle.com)
Date: Mon, 23 Dec 2013 12:28:33 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 8030118: Document listeners fired
	outside document	lock
Message-ID: <20131223123055.A149A62E96@hg.openjdk.java.net>

Changeset: 75142ce752da
Author:    malenkov
Date:      2013-12-23 16:24 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/75142ce752da

8030118: Document listeners fired outside document lock
Reviewed-by: art, serb

! src/share/classes/javax/swing/text/AbstractDocument.java
- test/javax/swing/text/AbstractDocument/7146146/bug7146146.java
+ test/javax/swing/text/AbstractDocument/8030118/Test8030118.java


From anton.tarasov at oracle.com  Mon Dec 23 06:20:46 2013
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Mon, 23 Dec 2013 18:20:46 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame:
 support scaled painting
In-Reply-To: <52A723B8.7090705@oracle.com>
References: <52A723B8.7090705@oracle.com>
Message-ID: <52B846BE.8040201@oracle.com>

Unfortunately, I have to suspend the request, as I'm taking a vacation 
for the rest of this year...

Thanks,
Anton.

On 12/10/13 6:22 PM, Anton V. Tarasov wrote:
> Hi Jim, Sergey and All,
>
> Please review the fix that adds support of Retina displays to 
> JLightweightFrame (which javafx SwingNode is based on).
>
> webrev: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1
> jira: https://bugs.openjdk.java.net/browse/JDK-8029455
>
> (After the fix goes into jdk9 it should be ported to 8u20 as well, 
> because the functionality is essential for SwingNode.)
>
> The general idea of the fix is as follows.
>
> A BufferedImage instance, being created in the context in which the 
> scale factor is determined and is different from one, is automatically 
> created with appropriately extended size. The image itself becomes a 
> scaled image (a "scale" private field is set on it). By the "context" 
> I mean the circumstances where the BufferedImage is related to a  
> JLightweightFrame, a GraphicsConfiguration, a SurfaceData, or a 
> GraphicsDevice which determine the scale factor.
>
> Here are the related changes:
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/java/awt/image/BufferedImage.java.udiff.html
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/OffScreenImage.java.udiff.html
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/swing/JLightweightFrame.java.udiff.html 
> (the resizeBuffer method)
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java.udiff.html
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java.udiff.html
>
> The "scale" value of a BufferedImage is used when 1) 
> BufferedImageGraphicsConfig is created 2) 
> BufImgSurfaceData.getDefaultScale() is called:
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java.udiff.html
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>
> The former is used in the 
> GraphicsConfiguration.createCompatibleImage() calls, and the latter is 
> used in SurfaceManager.getImageScale(Image):
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/SurfaceManager.java.udiff.html
>
> A scaled BufferedImage is supported by the SunGraphics2D.drawImage() 
> primitives. Here's the pattern of how the image may be created and drawn:
>
> int scale = <get the scale factor from the context>;
> BufferedImage img = new BufferedImage(width * scale, height * scale, 
> ...);
> img.setScale(scale); // an accessor is currently used instead
> <...>
> g2d.drawImage(img, x, y, ...); // 1) draw the image with auto-scale
> g2d.drawImage(img, x, y, dw, dh, ...) // 2) draw the image into a 
> specified rect
>
> In the first case, if the BufferedImage is created with an extended 
> size, the "scale" value of the image matters, it should be drawn as a 
> HiDPI image.
> In the second case, if the BufferedImage is created with an extended 
> size, the "scale" value of the image doesn't matter (it may not be 
> evidently set) as the image will anyway be scaled from its physical 
> bounds into provided logical bounds. This all should (as I suppose) 
> provide backward compatibility for buffered images that were created 
> in their logical bounds or without setting the "scale" field. For 
> instance, the AquaPainter.paintFromSingleCachedImage(...) method 
> creates & draws an image as follows:
>
> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
> int imgW = bounds.width * scale;
> int imgH = bounds.height * scale;
> BufferedImage img = new BufferedImage(imgW, imgH, ...);
> <paint into the img>
> g.drawImage(img, bounds.x, bounds.y, bounds.width, bounds.height, null);
>
> Here, the img.scale value is not set (I didn't modify this code), and 
> SunGraphics2D doesn't treat the image as a HiDPI image, however it is 
> drawn as expected. An alternative way to draw the image would be:
>
> int scale = ((SunGraphics2D) g).surfaceData.getDefaultScale();
> int imgW = bounds.width * scale;
> int imgH = bounds.height * scale;
> BufferedImage img = new BufferedImage(imgW, imgH, ...);
> img.setScale(scale);
> <paint into the img>
> g.drawImage(img, bounds.x, bounds.y, ...);
>
> The result would be the same.
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/java2d/SunGraphics2D.java.sdiff.html
>
> The following changes:
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java.udiff.html
>
> are defined by this logic. Running Swing via JLightweightFrame (JLF) 
> makes it "display agnostic". Swing is painted to an off-screen buffer 
> and it's the host (e.g. SwingNode) that renders the buffer on a 
> particular device. So, the host should detect the scale of the current 
> display and set it on JLF.
>
> However, AWT in order to paint to a volatile image requires 
> CGraphicsDevice and CGLSurfaceData to be created. By default AWT 
> creates CGraphicsDevice instances matching all the detected display 
> devices (CGraphicsEnvironment.initDevices()). But, as JLF doesn't have 
> any platform window behind it, AWT can't match JLF to the exact device 
> it's currently displayed on. So, on the one hand, AWT doesn't know 
> which device is current and what is the current scale (the host passes 
> this value), but from the other hand, AWT has a list of all the 
> CGraphicsDevice instances.
>
> I tried to leverage from that fact. The 
> CPlatformLWView.getGraphicsDevice() method takes the current scale 
> from the JLF instance, and then tries to match it to an existent 
> device from the list. In case it can't find a device with the 
> specified scale (which should not actually happen, unless the host 
> passes an arbitrary scale value, which is not the case for SwingNode) 
> it takes a default device and changes its scale forcedly. I'm not sure 
> if I should create a new dummy device instance instead. The scale 
> factor of the device (which is then propagated to CGLSurfaceData on 
> its creation) is the only info that JLF will take from the device to 
> create a scaled volatile image.
>
> The following changes:
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/JViewport.java.udiff.html
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/javax/swing/RepaintManager.java.udiff.html
>
> were made to map a backing store image to a scale factor.
>
> The JViewPort.paint(...) method calls SunGraphics2D.copyArea(...) on 
> scrolling. The method was not implemented for a graphics with a scale 
> transform and a BufImgSurfaceData (it threw exceptions). I took that 
> code, copied it to the BufImgSurfaceData.copyArea(...) and added a 
> general translation for the coords:
>
> - 
> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.1/src/share/classes/sun/awt/image/BufImgSurfaceData.java.udiff.html
>
> It works, but I'm not sure the implementation is eligible (I don't 
> know the details of the Blit class, at least it warns not to use the 
> same source and dest).
>
> The rest of the changes (not covered here) should be clear.
>
> Testing:
>
> - Using jfc/SwingSet2 and jfc/Java2D demos (in a standalone mode & 
> embedded into SwingNode [1]).
> - Testing both Nimbus and Aqua L&F.
> - Setting swing.volatileImageBufferEnabled=false/true for all 
> combinations.
>
> Currently, I see no regressions and no visual issues comparing a 
> standalone mode and a SwingSet mode.
>
> At the end, I suspect there may be some intersection b/w this fix and 
> the fix which introduced MultiResolutionToolkitImage. Unfortunately, I 
> didn't yet read that review saga... Please tell me if I should 
> incorporate anything from that fix.
>
> Thanks,
> Anton.
>
> [1] There's a SwingSet part of the fix which I'm going to post to the 
> jfx alias separately.
>


From Sergey.Bylokhov at oracle.com  Mon Dec 23 06:35:51 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 23 Dec 2013 18:35:51 +0400
Subject: <AWT Dev> review request: JNI use results in
 UnsatisfiedLinkError looking for libmawt.so
In-Reply-To: <52B82AD6.4030602@oracle.com>
References: <52B82AD6.4030602@oracle.com>
Message-ID: <52B84A47.7070006@oracle.com>

Hi, David.
The fix looks good to me. I assume that it was tested in the environment 
where the problem was reproduced.

On 23.12.2013 16:21, david buck wrote:
> Hi!
>
> I would like to please request a review of my fix for the following 
> issue:
>
> [ JDK-6571600 JNI use results in UnsatisfiedLinkError looking for 
> libmawt.so ]
> https://bugs.openjdk.java.net/browse/JDK-657160
>
> The root cause of this issue is a name conflict with JNI_OnLoad 
> provided by awt_LoadLibrary.c and code loaded manually by the user 
> (usually their own JNI libraries). The fix is to use a different name 
> for calling dladdr that is much less likely to conflict with any names 
> used by customer code.
>
> http://cr.openjdk.java.net/~dbuck/6571600/webrev.01/
>
> Best Regards,
> -Buck


-- 
Best regards, Sergey.


From david.buck at oracle.com  Mon Dec 23 06:41:23 2013
From: david.buck at oracle.com (david buck)
Date: Mon, 23 Dec 2013 23:41:23 +0900
Subject: <AWT Dev> review request: JNI use results in
 UnsatisfiedLinkError looking for libmawt.so
In-Reply-To: <52B84A47.7070006@oracle.com>
References: <52B82AD6.4030602@oracle.com> <52B84A47.7070006@oracle.com>
Message-ID: <52B84B93.4060009@oracle.com>

Hi Sergey!

Thank you for looking at this fix. Yes, I can reproduce the issue at 
will and have confirmed that this change resolves the problem on both 
Linux and Solaris.

Cheers,
-Buck

(2013/12/23 23:35), Sergey Bylokhov wrote:
> Hi, David.
> The fix looks good to me. I assume that it was tested in the environment
> where the problem was reproduced.
>
> On 23.12.2013 16:21, david buck wrote:
>> Hi!
>>
>> I would like to please request a review of my fix for the following
>> issue:
>>
>> [ JDK-6571600 JNI use results in UnsatisfiedLinkError looking for
>> libmawt.so ]
>> https://bugs.openjdk.java.net/browse/JDK-657160
>>
>> The root cause of this issue is a name conflict with JNI_OnLoad
>> provided by awt_LoadLibrary.c and code loaded manually by the user
>> (usually their own JNI libraries). The fix is to use a different name
>> for calling dladdr that is much less likely to conflict with any names
>> used by customer code.
>>
>> http://cr.openjdk.java.net/~dbuck/6571600/webrev.01/
>>
>> Best Regards,
>> -Buck
>
>

From petr.pchelko at oracle.com  Mon Dec 23 07:21:39 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 23 Dec 2013 19:21:39 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7154841 [macosx] Popups appear
	behind taskbar
Message-ID: <22834E0B-0F8D-4686-827A-725CBD755C68@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-7154841
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/7154841/webrev/

The fix is simple: for popup windows we should use an NSPopupMenuWindowLevel level.

With best regards. Petr.

From anthony.petrov at oracle.com  Mon Dec 23 07:18:53 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 23 Dec 2013 19:18:53 +0400
Subject: <AWT Dev> [9] setMaximumSize() and setMaximizedBounds()
In-Reply-To: <52B3748D.1040606@oracle.com>
References: <52B2CE8F.1050205@oracle.com> <52B2DF6E.4000400@oracle.com>
	<52B3466F.1090601@oracle.com> <52B3748D.1040606@oracle.com>
Message-ID: <52B8545D.60506@oracle.com>

> Similar question: how we should handle situation when max size is smaller than minimum size.

The setters should ensure the sizes are always reasonable (i.e. minimum 
<= maximum && minimum <= maximized).
As for maximum vs. maximized - this is what we're discussing in this thread.

--
best regards,
Anthony

On 12/20/2013 02:34 AM, Sergey Bylokhov wrote:
> Hi.
> Just my 2 cents. From my point of view the calls below  looks similar
> and should behave in the same way:
> 1 setMaximumSize/setMinimumSize + setBounds.
> 2 setMaximumSize/setMinimumSize + setMaximizedBounds+"setMaximumState".
> 3 setMaximumSize/setMinimumSize + resize by the user.
> 4 setMaximumSize/setMinimumSize + setMaximizedBounds+maximisation/zoom
> by the user.
> No?
> Similar question: how we should handle situation when max size is
> smaller than minimum size.
>
> On 19.12.2013 23:18, Anthony Petrov wrote:
>> But users may still want to have a shortcut to "maximize" a window in
>> case #3. How about we still allow for maximizing a window, but use its
>> maximum size instead of the maximized bounds as the size for a
>> maximized window? In other words, the maximum size (if set) has a
>> precedence over the maximized bounds.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/19/2013 03:58 PM, Artem Ananiev wrote:
>>>
>>> On 12/19/2013 2:46 PM, Alexander Zvegintsev wrote:
>>>> Hello AWT team,
>>>>
>>>> I am currently looking at JDK-6464548 issue[1], and as you can see in
>>>> javadoc[2]
>>>> we have only setMinimumSize() implemented in java.awt.Window and
>>>> setMaximumSize() is not implemented.
>>>>
>>>> So my question is about how setMaximumSize() (and setMinimumSize())
>>>> should interfere with setMaximizedBounds()[3]?
>>>>
>>>> I see several options here:
>>>>
>>>> 1. setMaximizedBounds() refers to a different state and does not depend
>>>> on setMaximumSize() and setMinimumSize()
>>>> 2. setMaximizedBounds() respects setMaximumSize() and setMinimumSize().
>>>> If the window is maximized and maximized
>>>> bounds does not conform with maximum or minimum size then window will
>>>> shrunk or enlarge to honor these sizes.
>>>> 3. If maximum size is set then we deny window maximize operation and
>>>> setMaximizedBounds() have no effect.
>>>>
>>>> What do you think?
>>>
>>> I would vote for #2 or #3. #3 seems to be slightly better than #2,
>>> because to implement #2 we'll need to track, what was called first,
>>> setMaximumSize() or setMaximizedBounds(). Another problem is that if we
>>> restrict the maximized bounds to conform to minimum/maximum size, when a
>>> window is maximized it won't occupy the right place as requested by the
>>> application. In other words, I think that in case #2 maximized bounds
>>> feature is broken anyway, so it doesn't make sense to allow window
>>> maximization at all (which is exactly #3).
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-6464548
>>>> [2]
>>>> http://docs.oracle.com/javase/7/docs/api/java/awt/Window.html#setMinimumSize(java.awt.Dimension)
>>>>
>>>>
>>>>
>>>> [3]
>>>> http://docs.oracle.com/javase/7/docs/api/java/awt/Frame.html#setMaximizedBounds(java.awt.Rectangle)
>>>>
>>>>
>>>>
>>>>
>>>>
>
>

From anthony.petrov at oracle.com  Mon Dec 23 10:38:15 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 23 Dec 2013 22:38:15 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7185258 [macosx] Deadlock in
	SunToolKit.realSync()
In-Reply-To: <E7783763-0169-45FE-94C2-1B0F549068D3@oracle.com>
References: <E7783763-0169-45FE-94C2-1B0F549068D3@oracle.com>
Message-ID: <52B88317.1090407@oracle.com>

Hi Petr,

1. Please add some javadoc to explain the difference between the 
"lightweight" sync and the heavyweight one.

2. src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
>  749     static void doAWTRunLoop(long mediator, boolean processEvents) {
>  750         notifyEnterNestedAppKitLoop();
>  751         doAWTRunLoopImpl(mediator, processEvents, inAWT);
>  752     }

I think we should use try/finally here.

3. Why do you interrupt the waiting for the first nested loop only? Why 
is it not a problem for subsequent nested loops?

4. What's the reason for the INTERRUPTED state in NSApplicationAWT? You 
don't really care if you got the event or the waiting has been 
interrupted - you stop waiting either way. So why do we care about the 
exact state? Looks like an unnecessary complication.

5. Note that realSync() doesn't actually guarantee anything. It only 
claims to make the best effort to try to sync the queue. Sending the 
event itself is already good as it makes things moving in the Cocoa 
framework. Should we actually bother with interrupting it? Can we simply 
introduce some reasonable timeout (500ms?) and simply return if the 
dummy event hasn't been received yet?

--
best regards,
Anthony

On 12/23/2013 04:54 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-7185258
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/7185258/webrev/
>
> The problem:
> nativeSyncQueue synchronizes the native event queue. However, there are several situations when a dummy event posted to the native queue is not dispatched. These are our own nested loop in doAWTRunLoop and Cocoa's internal nested loop in NSView:dragImage.
>
> Solution:
>
> 1. The interruptNativeSyncQueue was introduced. In case we are waiting for the native event queue this method interrupts waiting, otherwise it's a no-op. This is needed for the following reason: suppose the nativeSyncQueue is called on EDT. While the queue is flushed some event was processed which caused us to call doAWTRunLoop. As EDT is blocked we would have got a deadlock. Interrupting the wait lets EDT flush it's events and lets AppKit exit a nested loop. When the nativeSyncQueue is interrupted we do not immediately exit realSync, but flush EDT and try to sync native queue again. Most likely in this case we would not be in a nested loop and will successfully sync a native queue.
>
> 2. A lightweight version of nativeSyncQueue was introduced. This one does not flush the event queue, it only flushes a selector queue. This is needed to not deadlock when realSync was called during DnD. Suppose nativeSyncQueue is called while the app is in the native nested dragging loop. Until dragging operation finishes only dragging-related events will be processed. So we have no opportunity to flush the queue as our dummy event will be blocked by a dragging nested loop.
>
> I've tested it by running almost all awt and swing tests. No new failures, some tests start to pass after the fix.
>
> With best regards. Petr.
>
>

From petr.pchelko at oracle.com  Mon Dec 23 11:00:08 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 23 Dec 2013 23:00:08 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7185258 [macosx] Deadlock in
	SunToolKit.realSync()
In-Reply-To: <52B88317.1090407@oracle.com>
References: <E7783763-0169-45FE-94C2-1B0F549068D3@oracle.com>
	<52B88317.1090407@oracle.com>
Message-ID: <78E3DFE9-7CA8-43C5-818E-381022EA2F6B@oracle.com>

Hello, Anthony.

Thank you for the review. Please see my comments inline.

> 5. Note that realSync() doesn't actually guarantee anything. It only claims to make the best effort to try to sync the queue. Sending the event itself is already good as it makes things moving in the Cocoa framework. Should we actually bother with interrupting it? Can we simply introduce some reasonable timeout (500ms?) and simply return if the dummy event hasn't been received yet?
That would be a way simpler option. In my opinion the pros of this fix are:
1. This fix should make things a bit faster in tests (we immediately interrupt if we?ve detected a bad situation and we know it will block). 
2. realSync should have as low impact on the running app as possible, but in case of doAWTRunLoop nested loops realSync could block the Appkit and EDT for this timeout completely. This could affect the running tests and may not let us catch some issues we would have seen without this blocking.
The only disadvantage is complexity. Not sure if these advantages outweigh the complexity of this fix? What do you think? 
The idea with a timeout is good and I think I should add it to the fix (or reimplement the fix if we decide it?s too complex and doesn?t worth it).

> 1. Please add some javadoc to explain the difference between the "lightweight" sync and the heavyweight one.
Sure. I?ll fix it in the next version.

> 2. src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
>> 749     static void doAWTRunLoop(long mediator, boolean processEvents) {
>> 750         notifyEnterNestedAppKitLoop();
>> 751         doAWTRunLoopImpl(mediator, processEvents, inAWT);
>> 752     }
> 
> I think we should use try/finally here.
Why? The notifyEnterNestedAppKitLoop call could never throw an exception and we cannot reverse the order of calling here, because we should notify before actually entering to nested loop.

> 3. Why do you interrupt the waiting for the first nested loop only? Why is it not a problem for subsequent nested loops?
For the nested loops we could never already be inside the heavy native queue synchronization, because when we enter the first nestle loop we would already interrupt the nativeSyncQueue and for all the subsequent nested loops we would never enter the nativeSyncQueue with heavy loop.

> 4. What's the reason for the INTERRUPTED state in NSApplicationAWT? You don't really care if you got the event or the waiting has been interrupted - you stop waiting either way. So why do we care about the exact state? Looks like an unnecessary complication.

When the state is INTERRUPTED we return ?false? from the nativeSyncQueue making realSync immediately flush the EDT without making more attempt to call nativeSyncQueue as we know that this would not succeed.

On Dec 23, 2013, at 10:38 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Petr,
> 
> 1. Please add some javadoc to explain the difference between the "lightweight" sync and the heavyweight one.
> 
> 2. src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
>> 749     static void doAWTRunLoop(long mediator, boolean processEvents) {
>> 750         notifyEnterNestedAppKitLoop();
>> 751         doAWTRunLoopImpl(mediator, processEvents, inAWT);
>> 752     }
> 
> I think we should use try/finally here.
> 
> 3. Why do you interrupt the waiting for the first nested loop only? Why is it not a problem for subsequent nested loops?
> 
> 4. What's the reason for the INTERRUPTED state in NSApplicationAWT? You don't really care if you got the event or the waiting has been interrupted - you stop waiting either way. So why do we care about the exact state? Looks like an unnecessary complication.
> 
> 5. Note that realSync() doesn't actually guarantee anything. It only claims to make the best effort to try to sync the queue. Sending the event itself is already good as it makes things moving in the Cocoa framework. Should we actually bother with interrupting it? Can we simply introduce some reasonable timeout (500ms?) and simply return if the dummy event hasn't been received yet?
> 
> --
> best regards,
> Anthony
> 
> On 12/23/2013 04:54 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-7185258
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/7185258/webrev/
>> 
>> The problem:
>> nativeSyncQueue synchronizes the native event queue. However, there are several situations when a dummy event posted to the native queue is not dispatched. These are our own nested loop in doAWTRunLoop and Cocoa's internal nested loop in NSView:dragImage.
>> 
>> Solution:
>> 
>> 1. The interruptNativeSyncQueue was introduced. In case we are waiting for the native event queue this method interrupts waiting, otherwise it's a no-op. This is needed for the following reason: suppose the nativeSyncQueue is called on EDT. While the queue is flushed some event was processed which caused us to call doAWTRunLoop. As EDT is blocked we would have got a deadlock. Interrupting the wait lets EDT flush it's events and lets AppKit exit a nested loop. When the nativeSyncQueue is interrupted we do not immediately exit realSync, but flush EDT and try to sync native queue again. Most likely in this case we would not be in a nested loop and will successfully sync a native queue.
>> 
>> 2. A lightweight version of nativeSyncQueue was introduced. This one does not flush the event queue, it only flushes a selector queue. This is needed to not deadlock when realSync was called during DnD. Suppose nativeSyncQueue is called while the app is in the native nested dragging loop. Until dragging operation finishes only dragging-related events will be processed. So we have no opportunity to flush the queue as our dummy event will be blocked by a dragging nested loop.
>> 
>> I've tested it by running almost all awt and swing tests. No new failures, some tests start to pass after the fix.
>> 
>> With best regards. Petr.
>> 
>> 


From anthony.petrov at oracle.com  Mon Dec 23 11:05:07 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 23 Dec 2013 23:05:07 +0400
Subject: <AWT Dev> review request: JNI use results in
 UnsatisfiedLinkError looking for libmawt.so
In-Reply-To: <52B84B93.4060009@oracle.com>
References: <52B82AD6.4030602@oracle.com> <52B84A47.7070006@oracle.com>
	<52B84B93.4060009@oracle.com>
Message-ID: <52B88963.4080606@oracle.com>

Hi David,

The fix looks fine to me as well.

--
best regards,
Anthony

On 12/23/2013 06:41 PM, david buck wrote:
> Hi Sergey!
>
> Thank you for looking at this fix. Yes, I can reproduce the issue at
> will and have confirmed that this change resolves the problem on both
> Linux and Solaris.
>
> Cheers,
> -Buck
>
> (2013/12/23 23:35), Sergey Bylokhov wrote:
>> Hi, David.
>> The fix looks good to me. I assume that it was tested in the environment
>> where the problem was reproduced.
>>
>> On 23.12.2013 16:21, david buck wrote:
>>> Hi!
>>>
>>> I would like to please request a review of my fix for the following
>>> issue:
>>>
>>> [ JDK-6571600 JNI use results in UnsatisfiedLinkError looking for
>>> libmawt.so ]
>>> https://bugs.openjdk.java.net/browse/JDK-657160
>>>
>>> The root cause of this issue is a name conflict with JNI_OnLoad
>>> provided by awt_LoadLibrary.c and code loaded manually by the user
>>> (usually their own JNI libraries). The fix is to use a different name
>>> for calling dladdr that is much less likely to conflict with any names
>>> used by customer code.
>>>
>>> http://cr.openjdk.java.net/~dbuck/6571600/webrev.01/
>>>
>>> Best Regards,
>>> -Buck
>>
>>

From anthony.petrov at oracle.com  Mon Dec 23 11:10:52 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 23 Dec 2013 23:10:52 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7154841 [macosx] Popups
 appear behind taskbar
In-Reply-To: <22834E0B-0F8D-4686-827A-725CBD755C68@oracle.com>
References: <22834E0B-0F8D-4686-827A-725CBD755C68@oracle.com>
Message-ID: <52B88ABC.3040505@oracle.com>

Hi Petr,

src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
> 621                         applyWindowLevel();

Here the applyWindowLevel() method should be invoked on the 'pw' 
instance rather than on 'this'.

--
best regards,
Anthony

On 12/23/2013 07:21 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-7154841
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/7154841/webrev/
>
> The fix is simple: for popup windows we should use an NSPopupMenuWindowLevel level.
>
> With best regards. Petr.
>

From anthony.petrov at oracle.com  Mon Dec 23 11:19:41 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 23 Dec 2013 23:19:41 +0400
Subject: <AWT Dev> JDK 9 RFR of 8030845: Fix doclint missing issues in
 java.awt.event
In-Reply-To: <52B4AF74.60106@oracle.com>
References: <52B3DD1E.8020204@oracle.com> <52B4AF74.60106@oracle.com>
Message-ID: <52B88CCD.5070802@oracle.com>

> /* not clear what this means - listed in Microsoft Windows API */
> /** Constant for the FINAL key, listed in the Microsoft Windows API. */
> public static final int VK_FINAL                    = 0x0018;
>
> I can't find this listed in any Windows API.

Here it is: 
http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx

> So I am not sure I want to promote this comment to javadoc.
> This and MODECHANGE have the same issue, so this is getting a tad
> beyond doclint and into spec.

However, I agree with Phil. I don't think we should mention Windows API 
(or any native API for that matter) in the javadoc. I propose to use the 
following wording:

"Constant for the FINAL key."

w/o any additional references. The same applies to VK_MODECHANGE.

PS. I'm not familiar with keyboard mappings.

--
best regards,
Anthony

On 12/21/2013 12:58 AM, Phil Race wrote:
>
>> /** Constant for the substract key. */
>
> I think you can subtract an s here :-)
>
> actually I'd call it "number pad subtract key" like you did
> with add and do the same for  multiply and divide too.
>
>   /** Constant for the decimal key. */
>
> could we call this "decimal point key" ?
>
>
> There's an extra space in these two :
>
>   /**  Constant for the META  key. */
>
>   /**  Constant for the QUOTE  key. */
>
>
>
> /* not clear what this means - listed in Microsoft Windows API */
> /** Constant for the FINAL key, listed in the Microsoft Windows API. */
> public static final int VK_FINAL                    = 0x0018;
>
> I can't find this listed in any Windows API.
> So I am not sure I want to promote this comment to javadoc.
> This and MODECHANGE have the same issue, so this is getting a tad
> beyond doclint and into spec.
>
> Some one from AWT who is familiar with keyboard mappings needs to comment.
>
> -phil
>
> On 12/19/2013 10:01 PM, Joe Darcy wrote:
>> Hello,
>>
>> Please review my changes to address
>>
>>     8030845: Fix doclint missing issues in java.awt.event
>>
>> in JDK 9. Webrev at
>>
>>     http://cr.openjdk.java.net/~darcy/8030845.0/
>>
>> patch below.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/src/share/classes/java/awt/event/AWTEventListener.java
>> 2013-12-19 21:48:44.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/AWTEventListener.java
>> 2013-12-19 21:48:44.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1998, 2003, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -56,6 +56,7 @@
>>
>>      /**
>>       * Invoked when an event is dispatched in the AWT.
>> +     * @param event the event to be processed
>>       */
>>      public void eventDispatched(AWTEvent event);
>>
>> --- old/src/share/classes/java/awt/event/ActionListener.java
>> 2013-12-19 21:48:45.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/ActionListener.java
>> 2013-12-19 21:48:44.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -46,6 +46,7 @@
>>
>>      /**
>>       * Invoked when an action occurs.
>> +     * @param e the event to be processed
>>       */
>>      public void actionPerformed(ActionEvent e);
>>
>> --- old/src/share/classes/java/awt/event/AdjustmentListener.java
>> 2013-12-19 21:48:45.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/AdjustmentListener.java
>> 2013-12-19 21:48:45.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 1999, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -37,6 +37,7 @@
>>
>>      /**
>>       * Invoked when the value of the adjustable has changed.
>> +     * @param e the event to be processed
>>       */
>>      public void adjustmentValueChanged(AdjustmentEvent e);
>>
>> --- old/src/share/classes/java/awt/event/ComponentListener.java
>> 2013-12-19 21:48:46.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/ComponentListener.java
>> 2013-12-19 21:48:46.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -54,21 +54,25 @@
>>  public interface ComponentListener extends EventListener {
>>      /**
>>       * Invoked when the component's size changes.
>> +     * @param e the event to be processed
>>       */
>>      public void componentResized(ComponentEvent e);
>>
>>      /**
>>       * Invoked when the component's position changes.
>> +     * @param e the event to be processed
>>       */
>>      public void componentMoved(ComponentEvent e);
>>
>>      /**
>>       * Invoked when the component has been made visible.
>> +     * @param e the event to be processed
>>       */
>>      public void componentShown(ComponentEvent e);
>>
>>      /**
>>       * Invoked when the component has been made invisible.
>> +     * @param e the event to be processed
>>       */
>>      public void componentHidden(ComponentEvent e);
>>  }
>> --- old/src/share/classes/java/awt/event/ContainerListener.java
>> 2013-12-19 21:48:46.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/ContainerListener.java
>> 2013-12-19 21:48:46.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -55,11 +55,13 @@
>>  public interface ContainerListener extends EventListener {
>>      /**
>>       * Invoked when a component has been added to the container.
>> +     * @param e the event to be processed
>>       */
>>      public void componentAdded(ContainerEvent e);
>>
>>      /**
>>       * Invoked when a component has been removed from the container.
>> +     * @param e the event to be processed
>>       */
>>      public void componentRemoved(ContainerEvent e);
>>
>> --- old/src/share/classes/java/awt/event/FocusListener.java 2013-12-19
>> 21:48:47.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/FocusListener.java 2013-12-19
>> 21:48:46.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -51,11 +51,13 @@
>>
>>      /**
>>       * Invoked when a component gains the keyboard focus.
>> +     * @param e the event to be processed
>>       */
>>      public void focusGained(FocusEvent e);
>>
>>      /**
>>       * Invoked when a component loses the keyboard focus.
>> +     * @param e the event to be processed
>>       */
>>      public void focusLost(FocusEvent e);
>>  }
>> --- old/src/share/classes/java/awt/event/HierarchyBoundsListener.java
>> 2013-12-19 21:48:47.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/HierarchyBoundsListener.java
>> 2013-12-19 21:48:47.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1999, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -52,11 +52,13 @@
>>  public interface HierarchyBoundsListener extends EventListener {
>>      /**
>>       * Called when an ancestor of the source is moved.
>> +     * @param e the event to be processed
>>       */
>>      public void ancestorMoved(HierarchyEvent e);
>>
>>      /**
>>       * Called when an ancestor of the source is resized.
>> +     * @param e the event to be processed
>>       */
>>      public void ancestorResized(HierarchyEvent e);
>>  }
>> --- old/src/share/classes/java/awt/event/HierarchyListener.java
>> 2013-12-19 21:48:48.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/HierarchyListener.java
>> 2013-12-19 21:48:47.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1999, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -51,6 +51,7 @@
>>       * Called when the hierarchy has been changed. To discern the actual
>>       * type of change, call
>> <code>HierarchyEvent.getChangeFlags()</code>.
>>       *
>> +     * @param e the event to be processed
>>       * @see HierarchyEvent#getChangeFlags()
>>       */
>>      public void hierarchyChanged(HierarchyEvent e);
>> --- old/src/share/classes/java/awt/event/InputEvent.java 2013-12-19
>> 21:48:48.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/InputEvent.java 2013-12-19
>> 21:48:48.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2010, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -233,7 +233,8 @@
>>       * This limit is defined by the relevant number
>>       * of buttons that may hypothetically exist on the mouse but it
>> is greater than the
>>       * {@link java.awt.MouseInfo#getNumberOfButtons()
>> MouseInfo.getNumberOfButtons()}.
>> -     * <p>
>> +     *
>> +     * @return a mask for an existing mouse button.
>>       * @throws IllegalArgumentException if {@code button} is less
>> than zero or greater than the number
>>       *         of button masks reserved for buttons
>>       * @since 7.0
>> @@ -368,6 +369,7 @@
>>
>>      /**
>>       * Returns whether or not the Shift modifier is down on this event.
>> +     * @return whether or not the Shift modifier is down on this event
>>       */
>>      public boolean isShiftDown() {
>>          return (modifiers & SHIFT_MASK) != 0;
>> @@ -375,6 +377,7 @@
>>
>>      /**
>>       * Returns whether or not the Control modifier is down on this
>> event.
>> +     * @return whether or not the Control modifier is down on this event
>>       */
>>      public boolean isControlDown() {
>>          return (modifiers & CTRL_MASK) != 0;
>> @@ -382,6 +385,7 @@
>>
>>      /**
>>       * Returns whether or not the Meta modifier is down on this event.
>> +     * @return whether or not the Meta modifier is down on this event
>>       */
>>      public boolean isMetaDown() {
>>          return (modifiers & META_MASK) != 0;
>> @@ -389,6 +393,7 @@
>>
>>      /**
>>       * Returns whether or not the Alt modifier is down on this event.
>> +     * @return whether or not the Alt modifier is down on this event
>>       */
>>      public boolean isAltDown() {
>>          return (modifiers & ALT_MASK) != 0;
>> @@ -396,6 +401,7 @@
>>
>>      /**
>>       * Returns whether or not the AltGraph modifier is down on this
>> event.
>> +     * @return whether or not the AltGraph modifier is down on this
>> event
>>       */
>>      public boolean isAltGraphDown() {
>>          return (modifiers & ALT_GRAPH_MASK) != 0;
>> @@ -404,6 +410,7 @@
>>      /**
>>       * Returns the difference in milliseconds between the timestamp
>> of when this event occurred and
>>       * midnight, January 1, 1970 UTC.
>> +     * @return the difference in milliseconds between the timestamp
>> and midnight, January 1, 1970 UTC
>>       */
>>      public long getWhen() {
>>          return when;
>> @@ -411,6 +418,7 @@
>>
>>      /**
>>       * Returns the modifier mask for this event.
>> +     * @return the modifier mask for this event
>>       */
>>      public int getModifiers() {
>>          return modifiers & (JDK_1_3_MODIFIERS | HIGH_MODIFIERS);
>> @@ -451,6 +459,7 @@
>>       * </PRE>
>>       * The above code will work even if new modifiers are added.
>>       *
>> +     * @return the extended modifier mask for this event
>>       * @since 1.4
>>       */
>>      public int getModifiersEx() {
>> @@ -467,6 +476,7 @@
>>
>>      /**
>>       * Returns whether or not this event has been consumed.
>> +     * @return whether or not this event has been consumed
>>       * @see #consume
>>       */
>>      public boolean isConsumed() {
>> @@ -487,6 +497,9 @@
>>       * Zero parameter means that no modifiers were passed and will
>>       * cause the returning an empty string.
>>       *
>> +     * @return a String describing the extended modifier keys and
>> +     * mouse buttons
>> +     *
>>       * @param modifiers a modifier mask describing the extended
>>       *                modifier keys and mouse buttons for the event
>>       * @return a text description of the combination of extended
>> --- old/src/share/classes/java/awt/event/InputMethodEvent.java
>> 2013-12-19 21:48:48.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/InputMethodEvent.java
>> 2013-12-19 21:48:48.000000000 -0800
>> @@ -277,6 +277,7 @@
>>
>>      /**
>>       * Gets the number of committed characters in the text.
>> +     * @return the number of committed characters in the text
>>       */
>>      public int getCommittedCharacterCount() {
>>          return committedCharacterCount;
>> --- old/src/share/classes/java/awt/event/InputMethodListener.java
>> 2013-12-19 21:48:49.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/InputMethodListener.java
>> 2013-12-19 21:48:49.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1997, 1999, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -40,17 +40,17 @@
>>   * @see java.awt.im.InputMethodRequests
>>   * @since 1.2
>>   */
>> -
>>  public interface InputMethodListener extends EventListener {
>>
>>      /**
>>       * Invoked when the text entered through an input method has
>> changed.
>> +     * @param event the event to be processed
>>       */
>>      void inputMethodTextChanged(InputMethodEvent event);
>>
>>      /**
>>       * Invoked when the caret within composed text has changed.
>> +     * @param event the event to be processed
>>       */
>>      void caretPositionChanged(InputMethodEvent event);
>> -
>>  }
>> --- old/src/share/classes/java/awt/event/ItemListener.java 2013-12-19
>> 21:48:49.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/ItemListener.java 2013-12-19
>> 21:48:49.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -50,6 +50,7 @@
>>       * Invoked when an item has been selected or deselected by the user.
>>       * The code written for this method performs the operations
>>       * that need to occur when an item is selected (or deselected).
>> +     * @param e the event to be processed
>>       */
>>      void itemStateChanged(ItemEvent e);
>>
>> --- old/src/share/classes/java/awt/event/KeyEvent.java 2013-12-19
>> 21:48:50.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/KeyEvent.java 2013-12-19
>> 21:48:50.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -132,7 +132,7 @@
>>   * <p>
>>   * WARNING: Aside from those keys that are defined by the Java language
>>   * (VK_ENTER, VK_BACK_SPACE, and VK_TAB), do not rely on the values
>> of the VK_
>> - * constants.  Sun reserves the right to change these values as needed
>> + * constants.  The platform steward reserves the right to change
>> these values as needed
>>   * to accommodate a wider range of keyboards in the future.
>>   * <p>
>>   * An unspecified behavior will be caused if the {@code id} parameter
>> @@ -194,21 +194,52 @@
>>
>>      /* Virtual key codes. */
>>
>> +    /** Constant for the ENTER virtual key. */
>>      public static final int VK_ENTER          = '\n';
>> +
>> +    /** Constant for the BACK_SPACE virtual key. */
>>      public static final int VK_BACK_SPACE     = '\b';
>> +
>> +    /** Constant for the TAB virtual key. */
>>      public static final int VK_TAB            = '\t';
>> +
>> +    /** Constant for the CANCEL virtual key. */
>>      public static final int VK_CANCEL         = 0x03;
>> +
>> +    /** Constant for the CLEAR virtual key. */
>>      public static final int VK_CLEAR          = 0x0C;
>> +
>> +    /** Constant for the SHIFT virtual key. */
>>      public static final int VK_SHIFT          = 0x10;
>> +
>> +    /** Constant for the CONTROL virtual key. */
>>      public static final int VK_CONTROL        = 0x11;
>> +
>> +    /** Constant for the ALT. virtual key */
>>      public static final int VK_ALT            = 0x12;
>> +
>> +    /** Constant for the PAUSE virtual key. */
>>      public static final int VK_PAUSE          = 0x13;
>> +
>> +    /** Constant for the CAPS_LOCK virtual key. */
>>      public static final int VK_CAPS_LOCK      = 0x14;
>> +
>> +    /** Constant for the ESCAPE virtual key. */
>>      public static final int VK_ESCAPE         = 0x1B;
>> +
>> +    /** Constant for the SPACE virtual key. */
>>      public static final int VK_SPACE          = 0x20;
>> +
>> +    /** Constant for the PAGE_UP virtual key. */
>>      public static final int VK_PAGE_UP        = 0x21;
>> +
>> +    /** Constant for the PAGE_DOWN virtual key. */
>>      public static final int VK_PAGE_DOWN      = 0x22;
>> +
>> +    /** Constant for the END virtual key. */
>>      public static final int VK_END            = 0x23;
>> +
>> +    /** Constant for the HOME virtual key. */
>>      public static final int VK_HOME           = 0x24;
>>
>>      /**
>> @@ -257,15 +288,35 @@
>>      public static final int VK_SLASH          = 0x2F;
>>
>>      /** VK_0 thru VK_9 are the same as ASCII '0' thru '9' (0x30 -
>> 0x39) */
>> +
>> +    /** Constant for the "0" key. */
>>      public static final int VK_0              = 0x30;
>> +
>> +    /** Constant for the "1" key. */
>>      public static final int VK_1              = 0x31;
>> +
>> +    /** Constant for the "2" key. */
>>      public static final int VK_2              = 0x32;
>> +
>> +    /** Constant for the "3" key. */
>>      public static final int VK_3              = 0x33;
>> +
>> +    /** Constant for the "4" key. */
>>      public static final int VK_4              = 0x34;
>> +
>> +    /** Constant for the "5" key. */
>>      public static final int VK_5              = 0x35;
>> +
>> +    /** Constant for the "6" key. */
>>      public static final int VK_6              = 0x36;
>> +
>> +    /** Constant for the "7" key. */
>>      public static final int VK_7              = 0x37;
>> +
>> +    /** Constant for the "8" key. */
>>      public static final int VK_8              = 0x38;
>> +
>> +    /** Constant for the "9" key. */
>>      public static final int VK_9              = 0x39;
>>
>>      /**
>> @@ -279,31 +330,83 @@
>>      public static final int VK_EQUALS         = 0x3D;
>>
>>      /** VK_A thru VK_Z are the same as ASCII 'A' thru 'Z' (0x41 -
>> 0x5A) */
>> +
>> +    /** Constant for the "A" key. */
>>      public static final int VK_A              = 0x41;
>> +
>> +    /** Constant for the "B" key. */
>>      public static final int VK_B              = 0x42;
>> +
>> +    /** Constant for the "C" key. */
>>      public static final int VK_C              = 0x43;
>> +
>> +    /** Constant for the "D" key. */
>>      public static final int VK_D              = 0x44;
>> +
>> +    /** Constant for the "E" key. */
>>      public static final int VK_E              = 0x45;
>> +
>> +    /** Constant for the "F" key. */
>>      public static final int VK_F              = 0x46;
>> +
>> +    /** Constant for the "G" key. */
>>      public static final int VK_G              = 0x47;
>> +
>> +    /** Constant for the "H" key. */
>>      public static final int VK_H              = 0x48;
>> +
>> +    /** Constant for the "I" key. */
>>      public static final int VK_I              = 0x49;
>> +
>> +    /** Constant for the "J" key. */
>>      public static final int VK_J              = 0x4A;
>> +
>> +    /** Constant for the "K" key. */
>>      public static final int VK_K              = 0x4B;
>> +
>> +    /** Constant for the "L" key. */
>>      public static final int VK_L              = 0x4C;
>> +
>> +    /** Constant for the "M" key. */
>>      public static final int VK_M              = 0x4D;
>> +
>> +    /** Constant for the "N" key. */
>>      public static final int VK_N              = 0x4E;
>> +
>> +    /** Constant for the "O" key. */
>>      public static final int VK_O              = 0x4F;
>> +
>> +    /** Constant for the "P" key. */
>>      public static final int VK_P              = 0x50;
>> +
>> +    /** Constant for the "Q" key. */
>>      public static final int VK_Q              = 0x51;
>> +
>> +    /** Constant for the "R" key. */
>>      public static final int VK_R              = 0x52;
>> +
>> +    /** Constant for the "S" key. */
>>      public static final int VK_S              = 0x53;
>> +
>> +    /** Constant for the "T" key. */
>>      public static final int VK_T              = 0x54;
>> +
>> +    /** Constant for the "U" key. */
>>      public static final int VK_U              = 0x55;
>> +
>> +    /** Constant for the "V" key. */
>>      public static final int VK_V              = 0x56;
>> +
>> +    /** Constant for the "W" key. */
>>      public static final int VK_W              = 0x57;
>> +
>> +    /** Constant for the "X" key. */
>>      public static final int VK_X              = 0x58;
>> +
>> +    /** Constant for the "Y" key. */
>>      public static final int VK_Y              = 0x59;
>> +
>> +    /** Constant for the "Z" key. */
>>      public static final int VK_Z              = 0x5A;
>>
>>      /**
>> @@ -321,17 +424,40 @@
>>       */
>>      public static final int VK_CLOSE_BRACKET  = 0x5D;
>>
>> +    /** Constant for the number pad "0" key. */
>>      public static final int VK_NUMPAD0        = 0x60;
>> +
>> +    /** Constant for the number pad "1" key. */
>>      public static final int VK_NUMPAD1        = 0x61;
>> +
>> +    /** Constant for the number pad "2" key. */
>>      public static final int VK_NUMPAD2        = 0x62;
>> +
>> +    /** Constant for the number pad "3" key. */
>>      public static final int VK_NUMPAD3        = 0x63;
>> +
>> +    /** Constant for the number pad "4" key. */
>>      public static final int VK_NUMPAD4        = 0x64;
>> +
>> +    /** Constant for the number pad "5" key. */
>>      public static final int VK_NUMPAD5        = 0x65;
>> +
>> +    /** Constant for the number pad "6" key. */
>>      public static final int VK_NUMPAD6        = 0x66;
>> +
>> +    /** Constant for the number pad "7" key. */
>>      public static final int VK_NUMPAD7        = 0x67;
>> +
>> +    /** Constant for the number pad "8" key. */
>>      public static final int VK_NUMPAD8        = 0x68;
>> +
>> +    /** Constant for the number pad "9" key. */
>>      public static final int VK_NUMPAD9        = 0x69;
>> +
>> +    /** Constant for the number pad multiply key. */
>>      public static final int VK_MULTIPLY       = 0x6A;
>> +
>> +    /** Constant for the number pad add key. */
>>      public static final int VK_ADD            = 0x6B;
>>
>>      /**
>> @@ -347,11 +473,22 @@
>>       */
>>      public static final int VK_SEPARATOR      = VK_SEPARATER;
>>
>> +    /** Constant for the substract key. */
>>      public static final int VK_SUBTRACT       = 0x6D;
>> +
>> +    /** Constant for the decimal key. */
>>      public static final int VK_DECIMAL        = 0x6E;
>> +
>> +    /** Constant for the divide key. */
>>      public static final int VK_DIVIDE         = 0x6F;
>> +
>> +    /** Constant for the delete key. */
>>      public static final int VK_DELETE         = 0x7F; /* ASCII DEL */
>> +
>> +    /** Constant for the NUM_LOCK key. */
>>      public static final int VK_NUM_LOCK       = 0x90;
>> +
>> +    /** Constant for the SCROLL_LOCK key. */
>>      public static final int VK_SCROLL_LOCK    = 0x91;
>>
>>      /** Constant for the F1 function key. */
>> @@ -463,12 +600,22 @@
>>       */
>>      public static final int VK_F24            = 0xF00B;
>>
>> +    /**  Constant for the PRINTSCREEN key. */
>>      public static final int VK_PRINTSCREEN    = 0x9A;
>> +
>> +    /**  Constant for the INSERT key. */
>>      public static final int VK_INSERT         = 0x9B;
>> +
>> +    /**  Constant for the HELP key. */
>>      public static final int VK_HELP           = 0x9C;
>> +
>> +    /**  Constant for the META  key. */
>>      public static final int VK_META           = 0x9D;
>>
>> +    /**  Constant for the BACK_QUOTE  key. */
>>      public static final int VK_BACK_QUOTE     = 0xC0;
>> +
>> +    /**  Constant for the QUOTE  key. */
>>      public static final int VK_QUOTE          = 0xDE;
>>
>>      /**
>> @@ -638,6 +785,7 @@
>>      /* for input method support on Asian Keyboards */
>>
>>      /* not clear what this means - listed in Microsoft Windows API */
>> +    /** Constant for the FINAL key, listed in the Microsoft Windows
>> API. */
>>      public static final int VK_FINAL                    = 0x0018;
>>
>>      /** Constant for the Convert function key. */
>> @@ -653,14 +801,23 @@
>>      public static final int VK_ACCEPT                   = 0x001E;
>>
>>      /* not clear what this means - listed in Microsoft Windows API */
>> +    /** Constant for the MODECHANGE key, listed in the Microsoft
>> Windows API. */
>>      public static final int VK_MODECHANGE               = 0x001F;
>>
>>      /* replaced by VK_KANA_LOCK for Microsoft Windows and Solaris;
>>         might still be used on other platforms */
>> +    /**
>> +     * Constant for the KANA lock key.
>> +     * @see #VK_KANA_LOCK
>> +     **/
>>      public static final int VK_KANA                     = 0x0015;
>>
>>      /* replaced by VK_INPUT_METHOD_ON_OFF for Microsoft Windows and
>> Solaris;
>>         might still be used for other platforms */
>> +    /**
>> +     * Constant for KANJI.
>> +     * @see #VK_INPUT_METHOD_ON_OFF
>> +     */
>>      public static final int VK_KANJI                    = 0x0019;
>>
>>      /**
>> @@ -1085,7 +1242,25 @@
>>      }
>>
>>      /**
>> -     * @deprecated as of JDK1.1
>> +     * @deprecated as of JDK1.1; use {@link #KeyEvent(Component, int,
>> long, int, int, char)} instead
>> +     * @param source    The <code>Component</code> that originated
>> the event
>> +     * @param id              An integer indicating the type of event.
>> +     *                  For information on allowable values, see
>> +     *                  the class description for {@link KeyEvent}
>> +     * @param when      A long integer that specifies the time the event
>> +     *                  occurred.
>> +     *                     Passing negative or zero value
>> +     *                     is not recommended
>> +     * @param modifiers The modifier keys down during event (shift,
>> ctrl,
>> +     *                  alt, meta).
>> +     *                     Passing negative value
>> +     *                     is not recommended.
>> +     *                     Zero value means that no modifiers were
>> passed.
>> +     *                  Use either an extended _DOWN_MASK or old
>> _MASK modifiers,
>> +     *                  however do not mix models in the one event.
>> +     *                  The extended modifiers are preferred for using
>> +     * @param keyCode   The integer code for an actual key, or
>> VK_UNDEFINED
>> +     *                  (for a key-typed event)
>>       */
>>      @Deprecated
>>      public KeyEvent(Component source, int id, long when, int modifiers,
>> @@ -1184,6 +1359,7 @@
>>       * Returns a String describing the keyCode, such as "HOME", "F1"
>> or "A".
>>       * These strings can be localized by changing the awt.properties
>> file.
>>       *
>> +     * @param keyCode the key whose description is to be returned
>>       * @return a string containing a text description for a physical
>> key,
>>       *         identified by its keyCode
>>       */
>> @@ -1376,6 +1552,7 @@
>>       * <code>InputEvent.BUTTON3_MASK</code> have the same value,
>>       * so the string "Meta" is returned for both modifiers.
>>       *
>> +     * @param modifiers the modifier mask to be processed
>>       * @return string a text description of the combination of modifier
>>       *                keys that were held down during the event
>>       * @see InputEvent#getModifiersExText(int)
>> @@ -1612,8 +1789,8 @@
>>       * Pressing the same key in a regular Russian layout gives
>> another code, unique for the
>>       * letter "Cyrillic I short".
>>       *
>> +     * @return an extended key code for the event
>>       * @since 1.7
>> -     *
>>       */
>>      public  int getExtendedKeyCode() {
>>          return (int)extendedKeyCode;
>> @@ -1621,6 +1798,7 @@
>>      /**
>>       * Returns an extended key code for a unicode character.
>>       *
>> +     * @param c the unicode character to be processed
>>       * @return for a unicode character with a corresponding {@code
>> VK_} constant -- this
>>       *   {@code VK_} constant; for a character appearing on the primary
>>       *   level of a known keyboard layout -- a unique integer.
>> @@ -1628,7 +1806,6 @@
>>       *   {@code VK_UNDEFINED} is returned.
>>       *
>>       * @since 1.7
>> -     *
>>       */
>>      public static int getExtendedKeyCodeForChar(int c) {
>>          // Return a keycode (if any) associated with a character.
>> --- old/src/share/classes/java/awt/event/KeyListener.java 2013-12-19
>> 21:48:50.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/KeyListener.java 2013-12-19
>> 21:48:50.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -54,6 +54,7 @@
>>       * Invoked when a key has been typed.
>>       * See the class description for {@link KeyEvent} for a
>> definition of
>>       * a key typed event.
>> +     * @param e the event to be processed
>>       */
>>      public void keyTyped(KeyEvent e);
>>
>> @@ -61,6 +62,7 @@
>>       * Invoked when a key has been pressed.
>>       * See the class description for {@link KeyEvent} for a
>> definition of
>>       * a key pressed event.
>> +     * @param e the event to be processed
>>       */
>>      public void keyPressed(KeyEvent e);
>>
>> @@ -68,6 +70,7 @@
>>       * Invoked when a key has been released.
>>       * See the class description for {@link KeyEvent} for a
>> definition of
>>       * a key released event.
>> +     * @param e the event to be processed
>>       */
>>      public void keyReleased(KeyEvent e);
>>  }
>> --- old/src/share/classes/java/awt/event/MouseListener.java 2013-12-19
>> 21:48:51.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/MouseListener.java 2013-12-19
>> 21:48:51.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -59,26 +59,31 @@
>>      /**
>>       * Invoked when the mouse button has been clicked (pressed
>>       * and released) on a component.
>> +     * @param e the event to be processed
>>       */
>>      public void mouseClicked(MouseEvent e);
>>
>>      /**
>>       * Invoked when a mouse button has been pressed on a component.
>> +     * @param e the event to be processed
>>       */
>>      public void mousePressed(MouseEvent e);
>>
>>      /**
>>       * Invoked when a mouse button has been released on a component.
>> +     * @param e the event to be processed
>>       */
>>      public void mouseReleased(MouseEvent e);
>>
>>      /**
>>       * Invoked when the mouse enters a component.
>> +     * @param e the event to be processed
>>       */
>>      public void mouseEntered(MouseEvent e);
>>
>>      /**
>>       * Invoked when the mouse exits a component.
>> +     * @param e the event to be processed
>>       */
>>      public void mouseExited(MouseEvent e);
>>  }
>> --- old/src/share/classes/java/awt/event/MouseMotionListener.java
>> 2013-12-19 21:48:51.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/MouseMotionListener.java
>> 2013-12-19 21:48:51.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -63,12 +63,14 @@
>>       * Due to platform-dependent Drag&amp;Drop implementations,
>>       * <code>MOUSE_DRAGGED</code> events may not be delivered during
>> a native
>>       * Drag&amp;Drop operation.
>> +     * @param e the event to be processed
>>       */
>>      public void mouseDragged(MouseEvent e);
>>
>>      /**
>>       * Invoked when the mouse cursor has been moved onto a component
>>       * but no buttons have been pushed.
>> +     * @param e the event to be processed
>>       */
>>      public void mouseMoved(MouseEvent e);
>>
>> --- old/src/share/classes/java/awt/event/MouseWheelListener.java
>> 2013-12-19 21:48:52.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/MouseWheelListener.java
>> 2013-12-19 21:48:52.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 2000, 2003, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -52,6 +52,7 @@
>>
>>      /**
>>       * Invoked when the mouse wheel is rotated.
>> +     * @param e the event to be processed
>>       * @see MouseWheelEvent
>>       */
>>      public void mouseWheelMoved(MouseWheelEvent e);
>> --- old/src/share/classes/java/awt/event/PaintEvent.java 2013-12-19
>> 21:48:52.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/PaintEvent.java 2013-12-19
>> 21:48:52.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2008, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -108,6 +108,8 @@
>>      /**
>>       * Returns the rectangle representing the area which needs to be
>>       * repainted in response to this event.
>> +     * @return the rectangle representing the area which needs to be
>> +     * repainted in response to this event
>>       */
>>      public Rectangle getUpdateRect() {
>>          return updateRect;
>> --- old/src/share/classes/java/awt/event/TextListener.java 2013-12-19
>> 21:48:53.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/TextListener.java 2013-12-19
>> 21:48:52.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2008, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -49,6 +49,8 @@
>>       * Invoked when the value of the text has changed.
>>       * The code written for this method performs the operations
>>       * that need to occur when text changes.
>> +     *
>> +     * @param e the event to be processed
>>       */
>>      public void textValueChanged(TextEvent e);
>>
>> --- old/src/share/classes/java/awt/event/WindowFocusListener.java
>> 2013-12-19 21:48:53.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/WindowFocusListener.java
>> 2013-12-19 21:48:53.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 2000, 2006, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -57,6 +57,7 @@
>>       * Invoked when the Window is set to be the focused Window, which
>> means
>>       * that the Window, or one of its subcomponents, will receive
>> keyboard
>>       * events.
>> +     * @param e the event to be processed
>>       */
>>      public void windowGainedFocus(WindowEvent e);
>>
>> @@ -64,6 +65,7 @@
>>       * Invoked when the Window is no longer the focused Window, which
>> means
>>       * that keyboard events will no longer be delivered to the Window
>> or any of
>>       * its subcomponents.
>> +     * @param e the event to be processed
>>       */
>>      public void windowLostFocus(WindowEvent e);
>>  }
>> --- old/src/share/classes/java/awt/event/WindowListener.java
>> 2013-12-19 21:48:53.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/WindowListener.java
>> 2013-12-19 21:48:53.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2003, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -51,18 +51,21 @@
>>  public interface WindowListener extends EventListener {
>>      /**
>>       * Invoked the first time a window is made visible.
>> +     * @param e the event to be processed
>>       */
>>      public void windowOpened(WindowEvent e);
>>
>>      /**
>>       * Invoked when the user attempts to close the window
>>       * from the window's system menu.
>> +     * @param e the event to be processed
>>       */
>>      public void windowClosing(WindowEvent e);
>>
>>      /**
>>       * Invoked when a window has been closed as the result
>>       * of calling dispose on the window.
>> +     * @param e the event to be processed
>>       */
>>      public void windowClosed(WindowEvent e);
>>
>> @@ -71,6 +74,7 @@
>>       * minimized state. For many platforms, a minimized window
>>       * is displayed as the icon specified in the window's
>>       * iconImage property.
>> +     * @param e the event to be processed
>>       * @see java.awt.Frame#setIconImage
>>       */
>>      public void windowIconified(WindowEvent e);
>> @@ -78,6 +82,7 @@
>>      /**
>>       * Invoked when a window is changed from a minimized
>>       * to a normal state.
>> +     * @param e the event to be processed
>>       */
>>      public void windowDeiconified(WindowEvent e);
>>
>> @@ -88,6 +93,7 @@
>>       * as a highlighted title bar. The active Window is always either
>> the
>>       * focused Window, or the first Frame or Dialog that is an owner
>> of the
>>       * focused Window.
>> +     * @param e the event to be processed
>>       */
>>      public void windowActivated(WindowEvent e);
>>
>> @@ -98,6 +104,7 @@
>>       * highlighted title bar. The active Window is always either the
>> focused
>>       * Window, or the first Frame or Dialog that is an owner of the
>> focused
>>       * Window.
>> +     * @param e the event to be processed
>>       */
>>      public void windowDeactivated(WindowEvent e);
>>  }
>> --- old/src/share/classes/java/awt/event/WindowStateListener.java
>> 2013-12-19 21:48:54.000000000 -0800
>> +++ new/src/share/classes/java/awt/event/WindowStateListener.java
>> 2013-12-19 21:48:54.000000000 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 2001, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -50,6 +50,7 @@
>>  public interface WindowStateListener extends EventListener {
>>      /**
>>       * Invoked when window state is changed.
>> +     * @param e the event to be processed
>>       */
>>      public void windowStateChanged(WindowEvent e);
>>  }
>>
>

From Sergey.Bylokhov at oracle.com  Mon Dec 23 13:41:02 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 24 Dec 2013 01:41:02 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7185258 [macosx] Deadlock in
	SunToolKit.realSync()
In-Reply-To: <E7783763-0169-45FE-94C2-1B0F549068D3@oracle.com>
References: <E7783763-0169-45FE-94C2-1B0F549068D3@oracle.com>
Message-ID: <52B8ADEE.90409@oracle.com>

Hi, Petr.
On 23.12.2013 16:54, Petr Pchelko wrote:
> The problem:
> nativeSyncQueue synchronizes the native event queue. However, there are several situations when a dummy event posted to the native queue is not dispatched. These are our own nested loop in doAWTRunLoop and Cocoa's internal nested loop in NSView:dragImage.
As I remember  doAWTRunLoop  process events and selectors in case of 
drags/DnD otherwise how we got mouse events?  Or I have missed something?

>
> Solution:
>
> 1. The interruptNativeSyncQueue was introduced. In case we are waiting for the native event queue this method interrupts waiting, otherwise it's a no-op. This is needed for the following reason: suppose the nativeSyncQueue is called on EDT. While the queue is flushed some event was processed which caused us to call doAWTRunLoop. As EDT is blocked we would have got a deadlock. Interrupting the wait lets EDT flush it's events and lets AppKit exit a nested loop. When the nativeSyncQueue is interrupted we do not immediately exit realSync, but flush EDT and try to sync native queue again. Most likely in this case we would not be in a nested loop and will successfully sync a native queue.
>
> 2. A lightweight version of nativeSyncQueue was introduced. This one does not flush the event queue, it only flushes a selector queue. This is needed to not deadlock when realSync was called during DnD. Suppose nativeSyncQueue is called while the app is in the native nested dragging loop. Until dragging operation finishes only dragging-related events will be processed. So we have no opportunity to flush the queue as our dummy event will be blocked by a dragging nested loop.
>
> I've tested it by running almost all awt and swing tests. No new failures, some tests start to pass after the fix.
>
> With best regards. Petr.
>
>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Mon Dec 23 23:57:22 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 24 Dec 2013 11:57:22 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7185258 [macosx] Deadlock in
	SunToolKit.realSync()
In-Reply-To: <52B8ADEE.90409@oracle.com>
References: <E7783763-0169-45FE-94C2-1B0F549068D3@oracle.com>
	<52B8ADEE.90409@oracle.com>
Message-ID: <F9840FE9-1AF0-4C5F-97F3-5C28FE5C52AE@oracle.com>

Hello, Sergey.

> As I remember  doAWTRunLoop  process events and selectors in case of drags/DnD otherwise how we got mouse events?  Or I have missed something?
In case of DnD we have several nested loops in place:
1. The native Cocoa DnD nested loop. It's started within the NSView dragImage:... call. It processes only the DnD-related events - some mouse events, some key events and flag changed events. This is for the DragSource.
2. To dispatch some DropTarget events on EDT synchronously we start our own nested loop in doAWTRunLoop using the ToolkitThreadBlockedHandler. In this case we do process the events in a nested runLoop. 
This case might actually be a bug, because we are short-circuiting normal event processing and could "steal" some events from Cocoa. But I would not address this it in this fix.

Without the DnD we use a doAWTRunLoop which does not process events. (Except the case with Single-Threaded Interop with FX).

Actually, after some more thinking I believe I should reimplement the fix and follow Anthony's suggestion with a timeout, because my fix is too complex. I'll send a new webrev later today.

With best regards. Petr.

On 24.12.2013, at 1:41, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Petr.
> On 23.12.2013 16:54, Petr Pchelko wrote:
>> The problem:
>> nativeSyncQueue synchronizes the native event queue. However, there are several situations when a dummy event posted to the native queue is not dispatched. These are our own nested loop in doAWTRunLoop and Cocoa's internal nested loop in NSView:dragImage.
> As I remember  doAWTRunLoop  process events and selectors in case of drags/DnD otherwise how we got mouse events?  Or I have missed something?
> 
>> 
>> Solution:
>> 
>> 1. The interruptNativeSyncQueue was introduced. In case we are waiting for the native event queue this method interrupts waiting, otherwise it's a no-op. This is needed for the following reason: suppose the nativeSyncQueue is called on EDT. While the queue is flushed some event was processed which caused us to call doAWTRunLoop. As EDT is blocked we would have got a deadlock. Interrupting the wait lets EDT flush it's events and lets AppKit exit a nested loop. When the nativeSyncQueue is interrupted we do not immediately exit realSync, but flush EDT and try to sync native queue again. Most likely in this case we would not be in a nested loop and will successfully sync a native queue.
>> 
>> 2. A lightweight version of nativeSyncQueue was introduced. This one does not flush the event queue, it only flushes a selector queue. This is needed to not deadlock when realSync was called during DnD. Suppose nativeSyncQueue is called while the app is in the native nested dragging loop. Until dragging operation finishes only dragging-related events will be processed. So we have no opportunity to flush the queue as our dummy event will be blocked by a dragging nested loop.
>> 
>> I've tested it by running almost all awt and swing tests. No new failures, some tests start to pass after the fix.
>> 
>> With best regards. Petr.
>> 
>> 
> 
> 
> -- 
> Best regards, Sergey.
> 


From Sergey.Bylokhov at oracle.com  Tue Dec 24 00:21:03 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 24 Dec 2013 12:21:03 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7185258 [macosx] Deadlock in
	SunToolKit.realSync()
In-Reply-To: <F9840FE9-1AF0-4C5F-97F3-5C28FE5C52AE@oracle.com>
References: <E7783763-0169-45FE-94C2-1B0F549068D3@oracle.com>
	<52B8ADEE.90409@oracle.com>
	<F9840FE9-1AF0-4C5F-97F3-5C28FE5C52AE@oracle.com>
Message-ID: <52B943EF.8060700@oracle.com>

On 12/24/13 11:57 AM, Petr Pchelko wrote:
> Hello, Sergey.
>
>> As I remember  doAWTRunLoop  process events and selectors in case of drags/DnD otherwise how we got mouse events?  Or I have missed something?
> In case of DnD we have several nested loops in place:
> 1. The native Cocoa DnD nested loop. It's started within the NSView dragImage:... call. It processes only the DnD-related events - some mouse events, some key events and flag changed events. This is for the DragSource.
And we cannot emulate such event in postDummyevent?
> 2. To dispatch some DropTarget events on EDT synchronously we start our own nested loop in doAWTRunLoop using the ToolkitThreadBlockedHandler. In this case we do process the events in a nested runLoop.
> This case might actually be a bug, because we are short-circuiting normal event processing and could "steal" some events from Cocoa. But I would not address this it in this fix.
Probably it is a good time to realize how it should work? Since the fix 
adds complexity which can not be necessary in the future.
>
> Without the DnD we use a doAWTRunLoop which does not process events. (Except the case with Single-Threaded Interop with FX).
>
> Actually, after some more thinking I believe I should reimplement the fix and follow Anthony's suggestion with a timeout, because my fix is too complex. I'll send a new webrev later today.
>
> With best regards. Petr.
>
> On 24.12.2013, at 1:41, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Petr.
>> On 23.12.2013 16:54, Petr Pchelko wrote:
>>> The problem:
>>> nativeSyncQueue synchronizes the native event queue. However, there are several situations when a dummy event posted to the native queue is not dispatched. These are our own nested loop in doAWTRunLoop and Cocoa's internal nested loop in NSView:dragImage.
>> As I remember  doAWTRunLoop  process events and selectors in case of drags/DnD otherwise how we got mouse events?  Or I have missed something?
>>
>>> Solution:
>>>
>>> 1. The interruptNativeSyncQueue was introduced. In case we are waiting for the native event queue this method interrupts waiting, otherwise it's a no-op. This is needed for the following reason: suppose the nativeSyncQueue is called on EDT. While the queue is flushed some event was processed which caused us to call doAWTRunLoop. As EDT is blocked we would have got a deadlock. Interrupting the wait lets EDT flush it's events and lets AppKit exit a nested loop. When the nativeSyncQueue is interrupted we do not immediately exit realSync, but flush EDT and try to sync native queue again. Most likely in this case we would not be in a nested loop and will successfully sync a native queue.
>>>
>>> 2. A lightweight version of nativeSyncQueue was introduced. This one does not flush the event queue, it only flushes a selector queue. This is needed to not deadlock when realSync was called during DnD. Suppose nativeSyncQueue is called while the app is in the native nested dragging loop. Until dragging operation finishes only dragging-related events will be processed. So we have no opportunity to flush the queue as our dummy event will be blocked by a dragging nested loop.
>>>
>>> I've tested it by running almost all awt and swing tests. No new failures, some tests start to pass after the fix.
>>>
>>> With best regards. Petr.
>>>
>>>
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Tue Dec 24 00:30:31 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 24 Dec 2013 12:30:31 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7185258 [macosx] Deadlock in
	SunToolKit.realSync()
In-Reply-To: <52B943EF.8060700@oracle.com>
References: <E7783763-0169-45FE-94C2-1B0F549068D3@oracle.com>
	<52B8ADEE.90409@oracle.com>
	<F9840FE9-1AF0-4C5F-97F3-5C28FE5C52AE@oracle.com>
	<52B943EF.8060700@oracle.com>
Message-ID: <DA46C243-16B7-4B57-99B1-C525254003C0@oracle.com>

Hello, Sergey.

>>> As I remember  doAWTRunLoop  process events and selectors in case of drags/DnD otherwise how we got mouse events?  Or I have missed something?
>> In case of DnD we have several nested loops in place:
>> 1. The native Cocoa DnD nested loop. It's started within the NSView dragImage:... call. It processes only the DnD-related events - some mouse events, some key events and flag changed events. This is for the DragSource.
> And we cannot emulate such event in postDummyevent?
We could post something like a dummy MouseUp event and get rid of it in the NSApplication sendEvent:..., but I don't like such a solution. 
May be Cocoa has more nested event loops we do not know about yet which do not accept MouseUp. The same would be valid for any event type.

>> 2. To dispatch some DropTarget events on EDT synchronously we start our own nested loop in doAWTRunLoop using the ToolkitThreadBlockedHandler. In this case we do process the events in a nested runLoop.
>> This case might actually be a bug, because we are short-circuiting normal event processing and could "steal" some events from Cocoa. But I would not address this it in this fix.
> Probably it is a good time to realize how it should work? Since the fix adds complexity which can not be necessary in the future.
I agree. But this would be a long investigation, so let's leave this review until I find out how we should really work.

With best regards. Petr.

On 24.12.2013, at 12:21, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> On 12/24/13 11:57 AM, Petr Pchelko wrote:
>> Hello, Sergey.
>> 
>>> As I remember  doAWTRunLoop  process events and selectors in case of drags/DnD otherwise how we got mouse events?  Or I have missed something?
>> In case of DnD we have several nested loops in place:
>> 1. The native Cocoa DnD nested loop. It's started within the NSView dragImage:... call. It processes only the DnD-related events - some mouse events, some key events and flag changed events. This is for the DragSource.
> And we cannot emulate such event in postDummyevent?
>> 2. To dispatch some DropTarget events on EDT synchronously we start our own nested loop in doAWTRunLoop using the ToolkitThreadBlockedHandler. In this case we do process the events in a nested runLoop.
>> This case might actually be a bug, because we are short-circuiting normal event processing and could "steal" some events from Cocoa. But I would not address this it in this fix.
> Probably it is a good time to realize how it should work? Since the fix adds complexity which can not be necessary in the future.
>> 
>> Without the DnD we use a doAWTRunLoop which does not process events. (Except the case with Single-Threaded Interop with FX).
>> 
>> Actually, after some more thinking I believe I should reimplement the fix and follow Anthony's suggestion with a timeout, because my fix is too complex. I'll send a new webrev later today.
>> 
>> With best regards. Petr.
>> 
>> On 24.12.2013, at 1:41, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>> 
>>> Hi, Petr.
>>> On 23.12.2013 16:54, Petr Pchelko wrote:
>>>> The problem:
>>>> nativeSyncQueue synchronizes the native event queue. However, there are several situations when a dummy event posted to the native queue is not dispatched. These are our own nested loop in doAWTRunLoop and Cocoa's internal nested loop in NSView:dragImage.
>>> As I remember  doAWTRunLoop  process events and selectors in case of drags/DnD otherwise how we got mouse events?  Or I have missed something?
>>> 
>>>> Solution:
>>>> 
>>>> 1. The interruptNativeSyncQueue was introduced. In case we are waiting for the native event queue this method interrupts waiting, otherwise it's a no-op. This is needed for the following reason: suppose the nativeSyncQueue is called on EDT. While the queue is flushed some event was processed which caused us to call doAWTRunLoop. As EDT is blocked we would have got a deadlock. Interrupting the wait lets EDT flush it's events and lets AppKit exit a nested loop. When the nativeSyncQueue is interrupted we do not immediately exit realSync, but flush EDT and try to sync native queue again. Most likely in this case we would not be in a nested loop and will successfully sync a native queue.
>>>> 
>>>> 2. A lightweight version of nativeSyncQueue was introduced. This one does not flush the event queue, it only flushes a selector queue. This is needed to not deadlock when realSync was called during DnD. Suppose nativeSyncQueue is called while the app is in the native nested dragging loop. Until dragging operation finishes only dragging-related events will be processed. So we have no opportunity to flush the queue as our dummy event will be blocked by a dragging nested loop.
>>>> 
>>>> I've tested it by running almost all awt and swing tests. No new failures, some tests start to pass after the fix.
>>>> 
>>>> With best regards. Petr.
>>>> 
>>>> 
>>> 
>>> -- 
>>> Best regards, Sergey.
>>> 
> 
> 
> -- 
> Best regards, Sergey.
> 


From petr.pchelko at oracle.com  Tue Dec 24 00:50:45 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 24 Dec 2013 12:50:45 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7154841 [macosx] Popups
	appear behind taskbar
In-Reply-To: <52B88ABC.3040505@oracle.com>
References: <22834E0B-0F8D-4686-827A-725CBD755C68@oracle.com>
	<52B88ABC.3040505@oracle.com>
Message-ID: <A888160B-0AA2-43DD-AFF4-7311BBD1862A@oracle.com>

Hello, Anthony.

Thank you for the review.

The updated version could be found here: http://cr.openjdk.java.net/~pchelko/9/7154841/webrev.01/

With best regards. Petr.

On 23.12.2013, at 23:10, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Petr,
> 
> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
>> 621                         applyWindowLevel();
> 
> Here the applyWindowLevel() method should be invoked on the 'pw' instance rather than on 'this'.
> 
> --
> best regards,
> Anthony
> 
> On 12/23/2013 07:21 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-7154841
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/7154841/webrev/
>> 
>> The fix is simple: for popup windows we should use an NSPopupMenuWindowLevel level.
>> 
>> With best regards. Petr.
>> 


From Sergey.Bylokhov at oracle.com  Tue Dec 24 01:18:10 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 24 Dec 2013 13:18:10 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7154841 [macosx] Popups
 appear behind taskbar
In-Reply-To: <A888160B-0AA2-43DD-AFF4-7311BBD1862A@oracle.com>
References: <22834E0B-0F8D-4686-827A-725CBD755C68@oracle.com>
	<52B88ABC.3040505@oracle.com>
	<A888160B-0AA2-43DD-AFF4-7311BBD1862A@oracle.com>
Message-ID: <52B95152.8020404@oracle.com>

HI, Petr.
Is it possible to the window have a few levels? If not we can use ifelse 
in applyWindowLevel(). Should we update CWarningWindow.setVisible() also?

On 12/24/13 12:50 PM, Petr Pchelko wrote:
> Hello, Anthony.
>
> Thank you for the review.
>
> The updated version could be found here: http://cr.openjdk.java.net/~pchelko/9/7154841/webrev.01/
>
> With best regards. Petr.
>
> On 23.12.2013, at 23:10, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hi Petr,
>>
>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
>>> 621                         applyWindowLevel();
>> Here the applyWindowLevel() method should be invoked on the 'pw' instance rather than on 'this'.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 12/23/2013 07:21 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-7154841
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/7154841/webrev/
>>>
>>> The fix is simple: for popup windows we should use an NSPopupMenuWindowLevel level.
>>>
>>> With best regards. Petr.
>>>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131224/41a306d6/attachment-0001.html 

From petr.pchelko at oracle.com  Tue Dec 24 01:49:57 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 24 Dec 2013 13:49:57 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7154841 [macosx] Popups
	appear behind taskbar
In-Reply-To: <52B95152.8020404@oracle.com>
References: <22834E0B-0F8D-4686-827A-725CBD755C68@oracle.com>
	<52B88ABC.3040505@oracle.com>
	<A888160B-0AA2-43DD-AFF4-7311BBD1862A@oracle.com>
	<52B95152.8020404@oracle.com>
Message-ID: <D7315B58-9BBF-4FB6-8CF4-4174319135AA@oracle.com>

Hello, Sergey.

Please se the updated version: http://cr.openjdk.java.net/~pchelko/9/7154841/webrev.02/

> Is it possible to the window have a few levels? If not we can use ifelse in applyWindowLevel().
No, just one. But in case the window is simultaneously alwaysOnTop and popup the POPUP window level should take precedence.

> Should we update CWarningWindow.setVisible() also?
I couldn't think of an example when this would be needed, but let's update it also for consistency.

With best regards. Petr.

On 24.12.2013, at 13:18, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> HI, Petr.
> Is it possible to the window have a few levels? If not we can use ifelse in applyWindowLevel(). Should we update CWarningWindow.setVisible() also?
> 
> On 12/24/13 12:50 PM, Petr Pchelko wrote:
>> Hello, Anthony.
>> 
>> Thank you for the review.
>> 
>> The updated version could be found here: http://cr.openjdk.java.net/~pchelko/9/7154841/webrev.01/
>> 
>> With best regards. Petr.
>> 
>> On 23.12.2013, at 23:10, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>> 
>>> Hi Petr,
>>> 
>>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
>>>> 621                         applyWindowLevel();
>>> Here the applyWindowLevel() method should be invoked on the 'pw' instance rather than on 'this'.
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 12/23/2013 07:21 PM, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>> 
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-7154841
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/9/7154841/webrev/
>>>> 
>>>> The fix is simple: for popup windows we should use an NSPopupMenuWindowLevel level.
>>>> 
>>>> With best regards. Petr.
>>>> 
> 
> 
> -- 
> Best regards, Sergey. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131224/4680194a/attachment.html 

From anthony.petrov at oracle.com  Tue Dec 24 04:23:00 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 24 Dec 2013 16:23:00 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7154841 [macosx] Popups
 appear behind taskbar
In-Reply-To: <D7315B58-9BBF-4FB6-8CF4-4174319135AA@oracle.com>
References: <22834E0B-0F8D-4686-827A-725CBD755C68@oracle.com>
	<52B88ABC.3040505@oracle.com>
	<A888160B-0AA2-43DD-AFF4-7311BBD1862A@oracle.com>
	<52B95152.8020404@oracle.com>
	<D7315B58-9BBF-4FB6-8CF4-4174319135AA@oracle.com>
Message-ID: <52B97CA4.4090808@oracle.com>

Hi Petr,

The fix looks fine to me.

--
best regards,
Anthony

On 12/24/2013 01:49 PM, Petr Pchelko wrote:
> Hello, Sergey.
>
> Please se the updated version:
> http://cr.openjdk.java.net/~pchelko/9/7154841/webrev.02/
>
>> Is it possible to the window have a few levels? If not we can use
>> ifelse in applyWindowLevel().
> No, just one. But in case the window is simultaneously alwaysOnTop and
> popup the POPUP window level should take precedence.
>
>> Should we update CWarningWindow.setVisible() also?
> I couldn't think of an example when this would be needed, but let's
> update it also for consistency.
>
> With best regards. Petr.
>
> On 24.12.2013, at 13:18, Sergey Bylokhov <Sergey.Bylokhov at oracle.com
> <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>> HI, Petr.
>> Is it possible to the window have a few levels? If not we can use
>> ifelse in applyWindowLevel(). Should we update
>> CWarningWindow.setVisible() also?
>>
>> On 12/24/13 12:50 PM, Petr Pchelko wrote:
>>> Hello, Anthony.
>>>
>>> Thank you for the review.
>>>
>>> The updated version could be found here:http://cr.openjdk.java.net/~pchelko/9/7154841/webrev.01/
>>>
>>> With best regards. Petr.
>>>
>>> On 23.12.2013, at 23:10, Anthony Petrov<anthony.petrov at oracle.com>  wrote:
>>>
>>>> Hi Petr,
>>>>
>>>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
>>>>> 621                         applyWindowLevel();
>>>> Here the applyWindowLevel() method should be invoked on the 'pw' instance rather than on 'this'.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 12/23/2013 07:21 PM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>>
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-7154841
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/9/7154841/webrev/
>>>>>
>>>>> The fix is simple: for popup windows we should use an NSPopupMenuWindowLevel level.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>
>>
>> --
>> Best regards, Sergey.
>

From Sergey.Bylokhov at oracle.com  Tue Dec 24 05:30:40 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 24 Dec 2013 17:30:40 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7154841 [macosx] Popups
 appear behind taskbar
In-Reply-To: <52B97CA4.4090808@oracle.com>
References: <22834E0B-0F8D-4686-827A-725CBD755C68@oracle.com>
	<52B88ABC.3040505@oracle.com>
	<A888160B-0AA2-43DD-AFF4-7311BBD1862A@oracle.com>
	<52B95152.8020404@oracle.com>
	<D7315B58-9BBF-4FB6-8CF4-4174319135AA@oracle.com>
	<52B97CA4.4090808@oracle.com>
Message-ID: <52B98C80.7080909@oracle.com>

Hi, Petr.
The fix looks good to me too.

On 12/24/13 4:23 PM, Anthony Petrov wrote:
> Hi Petr,
>
> The fix looks fine to me.
>
> -- 
> best regards,
> Anthony
>
> On 12/24/2013 01:49 PM, Petr Pchelko wrote:
>> Hello, Sergey.
>>
>> Please se the updated version:
>> http://cr.openjdk.java.net/~pchelko/9/7154841/webrev.02/
>>
>>> Is it possible to the window have a few levels? If not we can use
>>> ifelse in applyWindowLevel().
>> No, just one. But in case the window is simultaneously alwaysOnTop and
>> popup the POPUP window level should take precedence.
>>
>>> Should we update CWarningWindow.setVisible() also?
>> I couldn't think of an example when this would be needed, but let's
>> update it also for consistency.
>>
>> With best regards. Petr.
>>
>> On 24.12.2013, at 13:18, Sergey Bylokhov <Sergey.Bylokhov at oracle.com
>> <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>>> HI, Petr.
>>> Is it possible to the window have a few levels? If not we can use
>>> ifelse in applyWindowLevel(). Should we update
>>> CWarningWindow.setVisible() also?
>>>
>>> On 12/24/13 12:50 PM, Petr Pchelko wrote:
>>>> Hello, Anthony.
>>>>
>>>> Thank you for the review.
>>>>
>>>> The updated version could be found 
>>>> here:http://cr.openjdk.java.net/~pchelko/9/7154841/webrev.01/
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On 23.12.2013, at 23:10, Anthony Petrov<anthony.petrov at oracle.com>  
>>>> wrote:
>>>>
>>>>> Hi Petr,
>>>>>
>>>>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
>>>>>> 621 applyWindowLevel();
>>>>> Here the applyWindowLevel() method should be invoked on the 'pw' 
>>>>> instance rather than on 'this'.
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 12/23/2013 07:21 PM, Petr Pchelko wrote:
>>>>>> Hello, AWT Team.
>>>>>>
>>>>>> Please review the fix for the issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-7154841
>>>>>> The fix is available at:
>>>>>> http://cr.openjdk.java.net/~pchelko/9/7154841/webrev/
>>>>>>
>>>>>> The fix is simple: for popup windows we should use an 
>>>>>> NSPopupMenuWindowLevel level.
>>>>>>
>>>>>> With best regards. Petr.
>>>>>>
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Dec 25 10:20:24 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 25 Dec 2013 22:20:24 +0400
Subject: <AWT Dev> [9] Review Request: 8030987
 sun_awt_X11_GtkFileDialogPeer.h can be removed
Message-ID: <52BB21E8.1060705@oracle.com>

Hello.
Please review the fix for jdk 9.
  - sun_awt_X11_GtkFileDialogPeer.h was removed, because it is created 
during the build of jdk.
  - sun_awt_X11_GtkFileDialogPeer.c added copyright header
  - small cleanup in java file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8030987
Webrev can be found at: http://cr.openjdk.java.net/~serb/8030987/webrev.00

-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Wed Dec 25 10:28:04 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 25 Dec 2013 22:28:04 +0400
Subject: <AWT Dev> [9] Review Request: 8030987
	sun_awt_X11_GtkFileDialogPeer.h can be removed
In-Reply-To: <52BB21E8.1060705@oracle.com>
References: <52BB21E8.1060705@oracle.com>
Message-ID: <88901DE3-ED81-40EA-B871-54091134F193@oracle.com>

Hello, Sergey.

> - sun_awt_X11_GtkFileDialogPeer.c added copyright header
The copyright header says 2012. Should that be 2013?

All the rest look good.

With best regards. Petr.

25 ???. 2013 ?., ? 10:20 ????? ???????, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> ???????(?):

> Hello.
> Please review the fix for jdk 9.
> - sun_awt_X11_GtkFileDialogPeer.h was removed, because it is created during the build of jdk.
> - sun_awt_X11_GtkFileDialogPeer.c added copyright header
> - small cleanup in java file.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8030987
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8030987/webrev.00
> 
> -- 
> Best regards, Sergey.
> 


From Sergey.Bylokhov at oracle.com  Wed Dec 25 10:31:13 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 25 Dec 2013 22:31:13 +0400
Subject: <AWT Dev> [9] Review Request: 8030987
 sun_awt_X11_GtkFileDialogPeer.h can be removed
In-Reply-To: <88901DE3-ED81-40EA-B871-54091134F193@oracle.com>
References: <52BB21E8.1060705@oracle.com>
	<88901DE3-ED81-40EA-B871-54091134F193@oracle.com>
Message-ID: <52BB2471.7030004@oracle.com>

Hi, Petr.
Thanks for the quick review.
Usually the license header contains the date when the non-documentation 
change was done, and it was 2012 for this file.

On 25.12.2013 22:28, Petr Pchelko wrote:
> Hello, Sergey.
>
>> - sun_awt_X11_GtkFileDialogPeer.c added copyright header
> The copyright header says 2012. Should that be 2013?
>
> All the rest look good.
>
> With best regards. Petr.
>
> 25 ???. 2013 ?., ? 10:20 ????? ???????, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> ???????(?):
>
>> Hello.
>> Please review the fix for jdk 9.
>> - sun_awt_X11_GtkFileDialogPeer.h was removed, because it is created during the build of jdk.
>> - sun_awt_X11_GtkFileDialogPeer.c added copyright header
>> - small cleanup in java file.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030987
>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8030987/webrev.00
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Wed Dec 25 10:32:40 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 25 Dec 2013 22:32:40 +0400
Subject: <AWT Dev> [9] Review Request: 8030987
	sun_awt_X11_GtkFileDialogPeer.h can be removed
In-Reply-To: <52BB2471.7030004@oracle.com>
References: <52BB21E8.1060705@oracle.com>
	<88901DE3-ED81-40EA-B871-54091134F193@oracle.com>
	<52BB2471.7030004@oracle.com>
Message-ID: <84A2EF6F-5702-43D3-8CF3-5A0208495477@oracle.com>

> Usually the license header contains the date when the non-documentation change was done, and it was 2012 for this file.
Oh.. Sure. The fix looks good in this case.

With best regards. Petr.

25 ???. 2013 ?., ? 10:31 ????? ???????, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> ???????(?):

> Hi, Petr.
> Thanks for the quick review.
> Usually the license header contains the date when the non-documentation change was done, and it was 2012 for this file.
> 
> On 25.12.2013 22:28, Petr Pchelko wrote:
>> Hello, Sergey.
>> 
>>> - sun_awt_X11_GtkFileDialogPeer.c added copyright header
>> The copyright header says 2012. Should that be 2013?
>> 
>> All the rest look good.
>> 
>> With best regards. Petr.
>> 
>> 25 ???. 2013 ?., ? 10:20 ????? ???????, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> ???????(?):
>> 
>>> Hello.
>>> Please review the fix for jdk 9.
>>> - sun_awt_X11_GtkFileDialogPeer.h was removed, because it is created during the build of jdk.
>>> - sun_awt_X11_GtkFileDialogPeer.c added copyright header
>>> - small cleanup in java file.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030987
>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8030987/webrev.00
>>> 
>>> -- 
>>> Best regards, Sergey.
>>> 
> 
> 
> -- 
> Best regards, Sergey.
> 


From alexander.zvegintsev at oracle.com  Wed Dec 25 10:41:25 2013
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Wed, 25 Dec 2013 22:41:25 +0400
Subject: <AWT Dev> [9] Review Request: 8030987
 sun_awt_X11_GtkFileDialogPeer.h can be removed
In-Reply-To: <52BB21E8.1060705@oracle.com>
References: <52BB21E8.1060705@oracle.com>
Message-ID: <52BB26D5.1040505@oracle.com>

Hi Sergey,

this fix look fine to me.

--
Thanks,
Alexander.

25.12.2013 22:20, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9.
>  - sun_awt_X11_GtkFileDialogPeer.h was removed, because it is created 
> during the build of jdk.
>  - sun_awt_X11_GtkFileDialogPeer.c added copyright header
>  - small cleanup in java file.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8030987
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8030987/webrev.00
>


From lana.steuck at oracle.com  Wed Dec 25 12:52:12 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:52:12 +0000
Subject: <AWT Dev> hg: jdk8/awt/langtools: 10 new changesets
Message-ID: <20131225205256.5300C62F28@hg.openjdk.java.net>

Changeset: a42071a6d61f
Author:    katleman
Date:      2013-12-19 17:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/a42071a6d61f

Added tag jdk8-b121 for changeset afe63d41c699

! .hgtags

Changeset: 2d0a0ae7fa9c
Author:    ksrini
Date:      2013-12-06 09:07 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/2d0a0ae7fa9c

8029504: Regression: TestDocRootLink test fails on Windows
Reviewed-by: bpatel, jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! test/com/sun/javadoc/testDocRootLink/TestDocRootLink.java

Changeset: 5bf0af735c61
Author:    vromero
Date:      2013-12-09 19:29 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/5bf0af735c61

8029569: internal javac cast exception when resolving varargs ambiguity
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/T8029569/VarargsAmbiguityCrashTest.java
+ test/tools/javac/T8029569/VarargsAmbiguityCrashTest.out

Changeset: 847cc0cccfa1
Author:    rfield
Date:      2013-12-11 11:56 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/847cc0cccfa1

8029558: java.lang.VerifyError: Bad return type when lambda's body is in parentheses
Summary: properly type convert the body of a lambda expression
Reviewed-by: vromero

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/tools/javac/lambda/LambdaParenGeneric.java
+ test/tools/javac/lambda/LambdaParenGenericOrig.java

Changeset: d80c3d6f4f05
Author:    lana
Date:      2013-12-12 19:19 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/d80c3d6f4f05

Merge


Changeset: 8832b6048e65
Author:    vromero
Date:      2013-12-13 14:13 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/8832b6048e65

8029721: javac crash for annotated parameter type of lambda in a field
Reviewed-by: rfield, jfranck

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java
! test/tools/javac/lambda/LambdaScope05.out

Changeset: 6d1f9d1fd585
Author:    darcy
Date:      2013-12-17 10:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/6d1f9d1fd585

8030080: Correct misstatement in JSR 269 MR (in javax.lang.model)
Reviewed-by: jfranck

! src/share/classes/javax/lang/model/type/IntersectionType.java
! src/share/classes/javax/lang/model/util/Types.java

Changeset: f1be939b49f6
Author:    mfang
Date:      2013-12-17 23:32 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/f1be939b49f6

8026741: jdk8 l10n resource file translation update 5
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties
! src/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties
! src/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties
! src/share/classes/com/sun/tools/jdeps/resources/jdeps_ja.properties
! src/share/classes/com/sun/tools/jdeps/resources/jdeps_zh_CN.properties

Changeset: b8ebde062692
Author:    bpatel
Date:      2013-12-18 19:48 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/b8ebde062692

8016549: jdk7 javadocs are hard to read
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java
! test/com/sun/javadoc/AccessH1/AccessH1.java
! test/com/sun/javadoc/testStylesheet/TestStylesheet.java
! test/tools/javadoc/api/basic/APITest.java

Changeset: 56943b19c119
Author:    lana
Date:      2013-12-23 14:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/langtools/rev/56943b19c119

Merge

- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif
- src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif


From lana.steuck at oracle.com  Wed Dec 25 12:52:12 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:52:12 +0000
Subject: <AWT Dev> hg: jdk8/awt/jaxws: Added tag jdk8-b121 for changeset
	32050ab53c8a
Message-ID: <20131225205222.1CFAB62F25@hg.openjdk.java.net>

Changeset: bc622ba563f9
Author:    katleman
Date:      2013-12-19 17:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/bc622ba563f9

Added tag jdk8-b121 for changeset 32050ab53c8a

! .hgtags


From lana.steuck at oracle.com  Wed Dec 25 12:52:12 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:52:12 +0000
Subject: <AWT Dev> hg: jdk8/awt/corba: 3 new changesets
Message-ID: <20131225205216.614F362F24@hg.openjdk.java.net>

Changeset: 15a9cdd9d64e
Author:    katleman
Date:      2013-12-19 17:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/15a9cdd9d64e

Added tag jdk8-b121 for changeset a7d3638deb2f

! .hgtags

Changeset: eb5d3f8ca0ca
Author:    mfang
Date:      2013-12-17 22:03 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/eb5d3f8ca0ca

8026741: jdk8 l10n resource file translation update 5
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp

Changeset: 2a8fa4da6ad3
Author:    lana
Date:      2013-12-23 14:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/2a8fa4da6ad3

Merge



From lana.steuck at oracle.com  Wed Dec 25 12:52:12 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:52:12 +0000
Subject: <AWT Dev> hg: jdk8/awt: Added tag jdk8-b121 for changeset
	1e1f86d5d4e2
Message-ID: <20131225205212.AC4E562F23@hg.openjdk.java.net>

Changeset: 347009c58816
Author:    katleman
Date:      2013-12-19 17:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/347009c58816

Added tag jdk8-b121 for changeset 1e1f86d5d4e2

! .hgtags


From lana.steuck at oracle.com  Wed Dec 25 12:52:12 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:52:12 +0000
Subject: <AWT Dev> hg: jdk8/awt/jaxp: 4 new changesets
Message-ID: <20131225205230.8EB7462F26@hg.openjdk.java.net>

Changeset: 51d5d5eef0d8
Author:    katleman
Date:      2013-12-19 17:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/51d5d5eef0d8

Added tag jdk8-b121 for changeset 4045edd35e8b

! .hgtags

Changeset: 3e5bf0372a93
Author:    joehw
Date:      2013-12-12 11:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/3e5bf0372a93

8029895: XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification
Reviewed-by: alanb, dfuchs, lancea

! src/javax/xml/stream/XMLOutputFactory.java

Changeset: 9c7e3a68dc77
Author:    lana
Date:      2013-12-12 19:13 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/9c7e3a68dc77

Merge


Changeset: fad4b4d28599
Author:    lana
Date:      2013-12-23 14:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/fad4b4d28599

Merge



From lana.steuck at oracle.com  Wed Dec 25 12:52:12 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:52:12 +0000
Subject: <AWT Dev> hg: jdk8/awt/nashorn: 8 new changesets
Message-ID: <20131225205231.2D02262F27@hg.openjdk.java.net>

Changeset: 7841feee13f5
Author:    katleman
Date:      2013-12-19 17:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/7841feee13f5

Added tag jdk8-b121 for changeset 32631eed0fad

! .hgtags

Changeset: 752554d45a07
Author:    sundar
Date:      2013-12-09 09:48 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/752554d45a07

8029612: the typeErrorThrower field in ScriptFunctionImpl cannot be static and common to all Globals
Reviewed-by: attila, hannesw

! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeStrictArguments.java
! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java

Changeset: 739f3abdfa55
Author:    sundar
Date:      2013-12-09 09:53 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/739f3abdfa55

Merge


Changeset: 4706897b4dec
Author:    attila
Date:      2013-12-09 10:52 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/4706897b4dec

8029467: Widening of booleans causes bad results
Reviewed-by: jlaskey, lagergren

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

Changeset: 18edd7a1b166
Author:    lagergren
Date:      2013-12-11 18:09 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/18edd7a1b166

8029780: "ant externals" broke our test harness with the latest version of the octane benchmarks
Reviewed-by: attila, sundar

! make/build-benchmark.xml
! test/script/basic/compile-octane-splitter.js.EXPECTED
! test/script/basic/compile-octane.js.EXPECTED
! test/script/basic/run-octane.js

Changeset: e452a3797290
Author:    sundar
Date:      2013-12-12 09:18 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/e452a3797290

Merge


Changeset: 0225a7ca37ab
Author:    lana
Date:      2013-12-12 19:19 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/0225a7ca37ab

Merge


Changeset: 9d112a0e7df7
Author:    lana
Date:      2013-12-23 14:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/9d112a0e7df7

Merge



From lana.steuck at oracle.com  Wed Dec 25 12:52:12 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:52:12 +0000
Subject: <AWT Dev> hg: jdk8/awt/hotspot: 34 new changesets
Message-ID: <20131225205337.A33BB62F29@hg.openjdk.java.net>

Changeset: 3aa20cee331a
Author:    amurillo
Date:      2013-12-06 09:41 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3aa20cee331a

8029693: new hotspot build - hs25-b63
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 9a60f4ac6a37
Author:    hseigel
Date:      2013-12-04 08:10 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9a60f4ac6a37

8027458: VM anonymous classes: wrong context for protected access checks
Summary: Use the anonymous class's host class for protected access checks
Reviewed-by: acorn, coleenp, lfoltan

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

Changeset: a4f036ef52e8
Author:    sla
Date:      2013-12-04 14:43 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a4f036ef52e8

8029395: SA: jstack throws WrongTypeException
Summary: SA missed some TLABs
Reviewed-by: dsamersoff, mgerdin, brutisso

! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java

Changeset: c586f8a7322f
Author:    mgronlun
Date:      2013-12-05 12:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c586f8a7322f

8028412: AsyncGetCallTrace() is broken on x86 in JDK 7u40
Reviewed-by: kvn, sspitsyn

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

Changeset: 769557390c43
Author:    hseigel
Date:      2013-12-06 11:33 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/769557390c43

8029415: java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java fails on all platforms with hs25-b61
Summary: Check first that a class is not a dynamically-generated bytecode associated with 1.4 reflection implementation, to emitting an ICCE of an invokespecial IMR of a method in an indirect superinterface.
Reviewed-by: acorn, hseigel
Contributed-by: lois.foltan at oracle.com

! src/share/vm/interpreter/linkResolver.cpp

Changeset: a150ff9e8efc
Author:    hseigel
Date:      2013-12-06 11:49 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a150ff9e8efc

Merge


Changeset: bf15208b72a5
Author:    mgronlun
Date:      2013-12-08 18:00 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/bf15208b72a5

Merge


Changeset: 9fbabcbb875b
Author:    hseigel
Date:      2013-12-10 16:18 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9fbabcbb875b

8028741: Interface Method Resolution should skip static and non-public methods in j.l.Object
Summary: Implementation of JDK 8 JVMS 5.4.3.4 specification change to skip static and non-public methods of java.lang.Object for interface method resolution.
Reviewed-by: acorn, coleenp
Contributed-by: lois.foltan at oracle.com

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

Changeset: 1de8e5356754
Author:    ehelin
Date:      2013-12-09 08:20 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/1de8e5356754

8029326: G1 does not check if threads gets created
Reviewed-by: brutisso, jmasa, jwilhelm

! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: ad72068ac41e
Author:    sjohanss
Date:      2013-12-10 10:31 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ad72068ac41e

8028993: Full collections with ParallelScavenge slower in JDK 8 compared to 7u40
Summary: Reducing the number of calls to follow_class_loader to speed up the marking phase. Also removed some unnecessary calls to adjust_klass.
Reviewed-by: stefank, jmasa, mgerdin

! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/oops/instanceClassLoaderKlass.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceMirrorKlass.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.pcgc.inline.hpp

Changeset: fa76dce60db7
Author:    stefank
Date:      2013-12-09 10:03 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/fa76dce60db7

8029106: JVM crashes in Metachunk::Metachunk during parallel class redefinition (PrivateMLetController, anonymous-simple_copy_1)
Summary: Fixed overflow bug in VirtualSpaceNode::is_available
Reviewed-by: mgerdin, brutisso, coleenp, jmasa

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

Changeset: e3995ab44393
Author:    ehelin
Date:      2013-12-12 16:13 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e3995ab44393

Merge


Changeset: df832bd8edb9
Author:    kvn
Date:      2013-12-06 12:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/df832bd8edb9

8028107: Kitchensink crashed with EAV
Summary: check the state of caller and callee nmethods and skip call site patching if any of them is not alive
Reviewed-by: jrose, twisti

! src/share/vm/code/compiledIC.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: b87211e33ebb
Author:    twisti
Date:      2013-12-06 16:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b87211e33ebb

8029366: ShouldNotReachHere error when creating an array with component type of void
Reviewed-by: kvn

! src/share/vm/opto/memnode.cpp
+ test/compiler/reflection/ArrayNewInstanceOfVoid.java

Changeset: ad45ebfba060
Author:    iignatyev
Date:      2013-12-11 01:04 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ad45ebfba060

8028122: [TESTBUG] compiler/regalloc/C1ObjectSpillInLogicOp.java
Reviewed-by: kvn, twisti

! test/compiler/regalloc/C1ObjectSpillInLogicOp.java

Changeset: 62084ffe573b
Author:    iignatyev
Date:      2013-12-11 01:09 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/62084ffe573b

8029153: [TESTBUG] test/compiler/7141637/SpreadNullArg.java fails because it expects NullPointerException
Reviewed-by: twisti

! test/compiler/7141637/SpreadNullArg.java

Changeset: bc8b01f98ae3
Author:    anoll
Date:      2013-12-12 11:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/bc8b01f98ae3

Merge


Changeset: fa6d364024c2
Author:    jprovino
Date:      2013-12-11 13:51 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/fa6d364024c2

8029566: PPC: OrderAccess::load_acquire(julong) is broken
Summary: JFR needs this fix to run on PPC
Reviewed-by: sla, mikael

! src/share/vm/utilities/globalDefinitions_gcc.hpp

Changeset: dc09e905db20
Author:    vladidan
Date:      2013-12-12 17:08 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/dc09e905db20

Merge


Changeset: 2a21bf819fea
Author:    vladidan
Date:      2013-12-12 14:06 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/2a21bf819fea

Merge


Changeset: 41f4cad94c58
Author:    amurillo
Date:      2013-12-13 09:40 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/41f4cad94c58

Merge


Changeset: 5f07ec8bb982
Author:    amurillo
Date:      2013-12-13 09:40 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/5f07ec8bb982

Added tag hs25-b63 for changeset 41f4cad94c58

! .hgtags

Changeset: 990e920dcec7
Author:    katleman
Date:      2013-12-19 17:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/990e920dcec7

Added tag jdk8-b121 for changeset 5f07ec8bb982

! .hgtags

Changeset: 7469c9ca967a
Author:    amurillo
Date:      2013-12-13 09:48 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7469c9ca967a

8030062: new hotspot build - hs25-b64
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 9ecf408d4568
Author:    iveresov
Date:      2013-12-12 11:25 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9ecf408d4568

8029668: Kithcensink crashed with guarantee(Assembler::is_simm13(disp)) failed: Do not match large constant offsets
Summary: Bailout if we try to reference a stack location that we can't encode
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/sparc.ad

Changeset: 68ec0a75ee22
Author:    iignatyev
Date:      2013-12-13 00:34 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/68ec0a75ee22

8026941: [TESTBUG] java.lang.ClassNotFoundException: java.lang.invoke.InvokeGeneric
Reviewed-by: kvn, vlivanov

! test/compiler/jsr292/ConcurrentClassLoadingTest.java

Changeset: 8beff993531a
Author:    iignatyev
Date:      2013-12-12 18:57 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8beff993531a

Merge


Changeset: 00bcb186fc5a
Author:    drchase
Date:      2013-12-12 15:11 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/00bcb186fc5a

8029351: assert(bt != T_OBJECT) failed: Guard is incorrect in VM:defmeth
Summary: replace test condition with reference to the proper predicate, encode folk wisdom into an assert
Reviewed-by: twisti, coleenp

! src/share/vm/oops/generateOopMap.cpp

Changeset: b00c6d846a0a
Author:    drchase
Date:      2013-12-12 18:00 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b00c6d846a0a

Merge


Changeset: ddcb2ac2900d
Author:    drchase
Date:      2013-12-12 20:55 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ddcb2ac2900d

Merge


Changeset: 22c88c127fa4
Author:    roland
Date:      2013-12-13 09:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/22c88c127fa4

8029383: assert(counter_changed) failed: failed dependencies, but counter didn't change
Summary: no call to SystemDictionary::notice_modification() when class is defined through Unsafe.defineAnonymousClass() can caused missed dependency change.
Reviewed-by: kvn, twisti

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

Changeset: a632dd6ef1f9
Author:    anoll
Date:      2013-12-16 00:44 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a632dd6ef1f9

Merge


Changeset: 61ee6bab0763
Author:    amurillo
Date:      2013-12-20 08:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/61ee6bab0763

Merge


Changeset: adcc814f792a
Author:    amurillo
Date:      2013-12-20 08:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/adcc814f792a

Added tag hs25-b64 for changeset 61ee6bab0763

! .hgtags


From lana.steuck at oracle.com  Wed Dec 25 12:52:49 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 25 Dec 2013 20:52:49 +0000
Subject: <AWT Dev> hg: jdk8/awt/jdk: 29 new changesets
Message-ID: <20131225205907.10D0162F2A@hg.openjdk.java.net>

Changeset: b822fa97c67a
Author:    rgallard
Date:      2013-12-12 22:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b822fa97c67a

8027844: Remove the JDK 1.1 compatibility part in jarsigner doc
Reviewed-by: weijun

! src/bsd/doc/man/jarsigner.1
! src/linux/doc/man/jarsigner.1
! src/solaris/doc/sun/man/man1/jarsigner.1

Changeset: 32cc35351303
Author:    rgallard
Date:      2013-12-13 14:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/32cc35351303

8027709: JDK8 docs on -XX:CompileOnly option are incorrect
Summary: Alexey Zhebel (azhebel) contributed these changes.
Reviewed-by: kvn

! src/bsd/doc/man/java.1
! src/linux/doc/man/java.1
! src/solaris/doc/sun/man/man1/java.1

Changeset: ce05e132b137
Author:    katleman
Date:      2013-12-17 12:02 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ce05e132b137

Merge


Changeset: f63994f1eab4
Author:    katleman
Date:      2013-12-19 17:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f63994f1eab4

Added tag jdk8-b121 for changeset ce05e132b137

! .hgtags

Changeset: c8c4aef922ff
Author:    vadim
Date:      2013-12-13 11:49 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c8c4aef922ff

8029628: Many graphic artifacts
Reviewed-by: prr, bae

! src/windows/native/sun/java2d/d3d/D3DBadHardware.h

Changeset: 6ecbfe5e211b
Author:    lana
Date:      2013-12-19 10:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6ecbfe5e211b

Merge


Changeset: 4ee27281d27d
Author:    lana
Date:      2013-12-19 10:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4ee27281d27d

Merge


Changeset: f8da1f34c65c
Author:    darcy
Date:      2013-12-06 11:28 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f8da1f34c65c

8023471: Add compatibility note to AnnotatedElement
Reviewed-by: smarks, jfranck, abuckley

! src/share/classes/java/lang/annotation/Annotation.java
! src/share/classes/java/lang/reflect/AnnotatedElement.java

Changeset: d6c4ae56c079
Author:    juh
Date:      2013-12-06 11:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d6c4ae56c079

8007967: Infinite loop can happen in sun.security.provider.certpath.SunCertPathBuilder.depthFirstSearchForward()
Reviewed-by: mullan

! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java

Changeset: 9e579a2329c0
Author:    michaelm
Date:      2013-12-09 13:05 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9e579a2329c0

8029354: URLPermission.<init> throws llegalArgumentException: Invalid characters in hostname
Reviewed-by: alanb, chegar

! src/share/classes/java/net/URLPermission.java
+ test/java/net/URLPermission/OpenURL.java
! test/java/net/URLPermission/URLPermissionTest.java

Changeset: 23a7524d930c
Author:    mfang
Date:      2013-12-09 15:01 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/23a7524d930c

8025974: l10n for policytool
Reviewed-by: naoto, leifs, yhuang

! src/share/classes/sun/security/tools/policytool/Resources_de.java
! src/share/classes/sun/security/tools/policytool/Resources_es.java
! src/share/classes/sun/security/tools/policytool/Resources_fr.java
! src/share/classes/sun/security/tools/policytool/Resources_it.java
! src/share/classes/sun/security/tools/policytool/Resources_ja.java
! src/share/classes/sun/security/tools/policytool/Resources_ko.java
! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java
! src/share/classes/sun/security/tools/policytool/Resources_sv.java
! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java
! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java

Changeset: fe3383582427
Author:    rriggs
Date:      2013-12-11 16:52 -0500
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/fe3383582427

8029551: Add value-type notice to java.time classes
Summary: Add warning about identity of value types and reference to ValueBased.html
Reviewed-by: briangoetz, smarks, scolebourne

! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! test/java/time/tck/java/time/TCKLocalDateTime.java

Changeset: 1298e476729c
Author:    michaelm
Date:      2013-12-11 15:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1298e476729c

8029944: Primitive Stream reduce method documentation pseudo code misidentifies apply method
Reviewed-by: mduigou
Contributed-by: michael.mcmahon at oracle.com

! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java

Changeset: 1970e3c3d202
Author:    michaelm
Date:      2013-12-11 15:27 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1970e3c3d202

8029696: Broken doc links to package-summary.html#NonInterference in java.util.stream
Reviewed-by: mduigou

! src/share/classes/java/util/stream/StreamSupport.java
! src/share/classes/java/util/stream/package-info.java

Changeset: 01b11184bcf9
Author:    mfang
Date:      2013-12-11 21:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/01b11184bcf9

8026115: [zh_CN] inproper translation in output of jarsigner command
Reviewed-by: naoto, yhuang

! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java

Changeset: 23b89bd740e9
Author:    lana
Date:      2013-12-12 19:17 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/23b89bd740e9

Merge


Changeset: a7ed72627c3f
Author:    mduigou
Date:      2013-12-13 13:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a7ed72627c3f

8029055: Map.merge implementations should refuse null value param
Reviewed-by: briangoetz, dl

! 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: 26028cb56c68
Author:    mduigou
Date:      2013-12-13 13:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/26028cb56c68

8030016: HashMap.computeIfAbsent generates spurious access event
Reviewed-by: psandoz, bchristi

! src/share/classes/java/util/HashMap.java
+ test/java/util/LinkedHashMap/ComputeIfAbsentAccessOrder.java
! test/java/util/Map/Defaults.java

Changeset: 6c343d3d2721
Author:    smarks
Date:      2013-12-13 18:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6c343d3d2721

8027536: rmic: add deprecation warning message when generating JRMP static stubs/skeletons
Reviewed-by: mchung, dmocek

! src/share/classes/sun/rmi/rmic/Main.java
! src/share/classes/sun/rmi/rmic/resources/rmic.properties

Changeset: 8e133b86b9f8
Author:    mduigou
Date:      2013-12-17 09:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8e133b86b9f8

8029795: LinkedHashMap.getOrDefault() doesn't update access order.
Reviewed-by: psandoz

! src/share/classes/java/util/LinkedHashMap.java
! test/java/util/LinkedHashMap/Basic.java

Changeset: 4fa27233a3e9
Author:    mfang
Date:      2013-12-17 14:13 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4fa27233a3e9

7090826: Newly added codes need to be localized into pt_BR in LocaleNames
Reviewed-by: okutsu

! src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties
- src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
! src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: 68c31754f925
Author:    vinnie
Date:      2013-12-17 23:03 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/68c31754f925

8029788: Certificate validation - java.lang.ClassCastException
Reviewed-by: xuelei, mullan, weijun

! src/share/classes/sun/security/provider/certpath/OCSPResponse.java

Changeset: 9211877b25ba
Author:    mfang
Date:      2013-12-17 23:33 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9211877b25ba

8026741: jdk8 l10n resource file translation update 5
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/java/util/jar/pack/DriverResource_ja.java
! src/share/classes/com/sun/java/util/jar/pack/DriverResource_zh_CN.java
! 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_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_TW.properties
! src/share/classes/sun/security/tools/keytool/Resources_de.java
! src/share/classes/sun/security/tools/keytool/Resources_es.java
! src/share/classes/sun/security/tools/keytool/Resources_fr.java
! src/share/classes/sun/security/tools/keytool/Resources_it.java
! src/share/classes/sun/security/tools/keytool/Resources_ja.java
! src/share/classes/sun/security/tools/keytool/Resources_ko.java
! src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java
! src/share/classes/sun/security/tools/keytool/Resources_sv.java
! src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java
! src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java
! src/share/classes/sun/tools/jar/resources/jar_es.properties
! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties
! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties
! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties

Changeset: 8d35f0985dd7
Author:    xuelei
Date:      2013-12-18 16:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8d35f0985dd7

7093640: Enable client-side TLS 1.2 by default
Reviewed-by: weijun, mullan, wetmore

! src/share/classes/sun/security/ssl/ProtocolVersion.java
! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/classes/sun/security/ssl/SunJSSE.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/DefaultEnabledProtocols.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/IllegalProtocolProperty.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NoOldVersionContext.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/SSLContextVersion.java
- test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java

Changeset: e2bdddb8bedf
Author:    dl
Date:      2013-12-19 10:31 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e2bdddb8bedf

8026155: Enhance ForkJoin pool
Reviewed-by: chegar, alanb, ahgross

! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java

Changeset: c841815be720
Author:    chegar
Date:      2013-12-19 10:38 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c841815be720

Merge


Changeset: a2339db970e0
Author:    lana
Date:      2013-12-19 10:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a2339db970e0

Merge

- src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
- test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java

Changeset: 2f31ddf65e74
Author:    lana
Date:      2013-12-23 14:45 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2f31ddf65e74

Merge

- src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
- test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java

Changeset: 8b5985f1a0b5
Author:    lana
Date:      2013-12-25 11:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8b5985f1a0b5

Merge

- src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
- test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java


From petr.pchelko at oracle.com  Thu Dec 26 01:06:46 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 26 Dec 2013 13:06:46 +0400
Subject: <AWT Dev> [9] Review Request: 8027561 [macosx] Cleanup "may not
	respond to selector" warnings in native code
Message-ID: <1E0E9CCA-9C68-4E75-9C3F-A2C81B31B252@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8027561
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8027561/webrev/

This is a little cleanup of "may not respond to selector" OBJC warnings in native code. I've already sent this out in 8, but it was too late to get it there, so I'm resending the updated fix for 9.

With best regards. Petr.

From Sergey.Bylokhov at oracle.com  Thu Dec 26 01:30:18 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 26 Dec 2013 13:30:18 +0400
Subject: <AWT Dev> [9] Review Request: 8027561 [macosx] Cleanup "may not
 respond to selector" warnings in native code
In-Reply-To: <1E0E9CCA-9C68-4E75-9C3F-A2C81B31B252@oracle.com>
References: <1E0E9CCA-9C68-4E75-9C3F-A2C81B31B252@oracle.com>
Message-ID: <52BBF72A.90001@oracle.com>

Hi, Petr.
The fix looks good. Please update the date in header in awtview h/m 
before the push.

On 26.12.2013 13:06, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8027561
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8027561/webrev/
>
> This is a little cleanup of "may not respond to selector" OBJC warnings in native code. I've already sent this out in 8, but it was too late to get it there, so I'm resending the updated fix for 9.
>
> With best regards. Petr.


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Thu Dec 26 01:35:05 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 26 Dec 2013 13:35:05 +0400
Subject: <AWT Dev> [9] Review Request: 8027561 [macosx] Cleanup "may not
	respond to selector" warnings in native code
In-Reply-To: <52BBF72A.90001@oracle.com>
References: <1E0E9CCA-9C68-4E75-9C3F-A2C81B31B252@oracle.com>
	<52BBF72A.90001@oracle.com>
Message-ID: <BE56622B-22B6-4A82-8D98-B1B06CA3B0B6@oracle.com>

Hello, Sergey.

> The fix looks good. Please update the date in header in awtview h/m before the push.
Sure. Thank you for the review.

With best regards. Petr.

On 26.12.2013, at 13:30, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Petr.
> The fix looks good. Please update the date in header in awtview h/m before the push.
> 
> On 26.12.2013 13:06, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8027561
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8027561/webrev/
>> 
>> This is a little cleanup of "may not respond to selector" OBJC warnings in native code. I've already sent this out in 8, but it was too late to get it there, so I'm resending the updated fix for 9.
>> 
>> With best regards. Petr.
> 
> 
> -- 
> Best regards, Sergey.
> 


From alexander.zvegintsev at oracle.com  Thu Dec 26 02:02:30 2013
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 26 Dec 2013 14:02:30 +0400
Subject: <AWT Dev> [9] Review Request: 8027561 [macosx] Cleanup "may not
 respond to selector" warnings in native code
In-Reply-To: <BE56622B-22B6-4A82-8D98-B1B06CA3B0B6@oracle.com>
References: <1E0E9CCA-9C68-4E75-9C3F-A2C81B31B252@oracle.com>
	<52BBF72A.90001@oracle.com>
	<BE56622B-22B6-4A82-8D98-B1B06CA3B0B6@oracle.com>
Message-ID: <52BBFEB6.6000909@oracle.com>

Hi Petr,

the fix looks good to me too.

Thanks,

Alexander.

On 12/26/2013 01:35 PM, Petr Pchelko wrote:
> Hello, Sergey.
>
>> The fix looks good. Please update the date in header in awtview h/m before the push.
> Sure. Thank you for the review.
>
> With best regards. Petr.
>
> On 26.12.2013, at 13:30, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
>> Hi, Petr.
>> The fix looks good. Please update the date in header in awtview h/m before the push.
>>
>> On 26.12.2013 13:06, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8027561
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8027561/webrev/
>>>
>>> This is a little cleanup of "may not respond to selector" OBJC warnings in native code. I've already sent this out in 8, but it was too late to get it there, so I'm resending the updated fix for 9.
>>>
>>> With best regards. Petr.
>>
>> -- 
>> Best regards, Sergey.
>>


From joe.darcy at oracle.com  Thu Dec 26 16:12:25 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 26 Dec 2013 16:12:25 -0800
Subject: <AWT Dev> JDK 9 RFR of 8030845: Fix doclint missing issues in
 java.awt.event
In-Reply-To: <52B4AF74.60106@oracle.com>
References: <52B3DD1E.8020204@oracle.com> <52B4AF74.60106@oracle.com>
Message-ID: <52BCC5E9.7070102@oracle.com>

Hello,

On 12/20/2013 12:58 PM, Phil Race wrote:
>
>> /** Constant for the substract key. */
>
> I think you can subtract an s here :-)

Quite right :-)

>
> actually I'd call it "number pad subtract key" like you did
> with add and do the same for  multiply and divide too.
>
>  /** Constant for the decimal key. */
>
> could we call this "decimal point key" ?
>
>
> There's an extra space in these two :
>
>  /**  Constant for the META  key. */
>
>  /**  Constant for the QUOTE  key. */

Changes made.

>
>
>
> /* not clear what this means - listed in Microsoft Windows API */
> /** Constant for the FINAL key, listed in the Microsoft Windows API. */
> public static final int VK_FINAL                    = 0x0018;
>
> I can't find this listed in any Windows API.
> So I am not sure I want to promote this comment to javadoc.
> This and MODECHANGE have the same issue, so this is getting a tad
> beyond doclint and into spec.
>
> Some one from AWT who is familiar with keyboard mappings needs to 
> comment.

Per the comments from you and Anthony, in those two cases changed to a 
comment like:

     /** Constant for the FINAL key. */

Revised patch for the KeyEvent file below.

Thanks,

-Joe

diff -r 7aa58a1362c8 src/share/classes/java/awt/event/KeyEvent.java
--- a/src/share/classes/java/awt/event/KeyEvent.java    Tue Dec 24 
20:07:12 2013 -0800
+++ b/src/share/classes/java/awt/event/KeyEvent.java    Thu Dec 26 
16:09:41 2013 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -132,7 +132,7 @@
   * <p>
   * WARNING: Aside from those keys that are defined by the Java language
   * (VK_ENTER, VK_BACK_SPACE, and VK_TAB), do not rely on the values of 
the VK_
- * constants.  Sun reserves the right to change these values as needed
+ * constants.  The platform steward reserves the right to change these 
values as needed
   * to accommodate a wider range of keyboards in the future.
   * <p>
   * An unspecified behavior will be caused if the {@code id} parameter
@@ -194,21 +194,52 @@

      /* Virtual key codes. */

+    /** Constant for the ENTER virtual key. */
      public static final int VK_ENTER          = '\n';
+
+    /** Constant for the BACK_SPACE virtual key. */
      public static final int VK_BACK_SPACE     = '\b';
+
+    /** Constant for the TAB virtual key. */
      public static final int VK_TAB            = '\t';
+
+    /** Constant for the CANCEL virtual key. */
      public static final int VK_CANCEL         = 0x03;
+
+    /** Constant for the CLEAR virtual key. */
      public static final int VK_CLEAR          = 0x0C;
+
+    /** Constant for the SHIFT virtual key. */
      public static final int VK_SHIFT          = 0x10;
+
+    /** Constant for the CONTROL virtual key. */
      public static final int VK_CONTROL        = 0x11;
+
+    /** Constant for the ALT. virtual key */
      public static final int VK_ALT            = 0x12;
+
+    /** Constant for the PAUSE virtual key. */
      public static final int VK_PAUSE          = 0x13;
+
+    /** Constant for the CAPS_LOCK virtual key. */
      public static final int VK_CAPS_LOCK      = 0x14;
+
+    /** Constant for the ESCAPE virtual key. */
      public static final int VK_ESCAPE         = 0x1B;
+
+    /** Constant for the SPACE virtual key. */
      public static final int VK_SPACE          = 0x20;
+
+    /** Constant for the PAGE_UP virtual key. */
      public static final int VK_PAGE_UP        = 0x21;
+
+    /** Constant for the PAGE_DOWN virtual key. */
      public static final int VK_PAGE_DOWN      = 0x22;
+
+    /** Constant for the END virtual key. */
      public static final int VK_END            = 0x23;
+
+    /** Constant for the HOME virtual key. */
      public static final int VK_HOME           = 0x24;

      /**
@@ -257,15 +288,35 @@
      public static final int VK_SLASH          = 0x2F;

      /** VK_0 thru VK_9 are the same as ASCII '0' thru '9' (0x30 - 0x39) */
+
+    /** Constant for the "0" key. */
      public static final int VK_0              = 0x30;
+
+    /** Constant for the "1" key. */
      public static final int VK_1              = 0x31;
+
+    /** Constant for the "2" key. */
      public static final int VK_2              = 0x32;
+
+    /** Constant for the "3" key. */
      public static final int VK_3              = 0x33;
+
+    /** Constant for the "4" key. */
      public static final int VK_4              = 0x34;
+
+    /** Constant for the "5" key. */
      public static final int VK_5              = 0x35;
+
+    /** Constant for the "6" key. */
      public static final int VK_6              = 0x36;
+
+    /** Constant for the "7" key. */
      public static final int VK_7              = 0x37;
+
+    /** Constant for the "8" key. */
      public static final int VK_8              = 0x38;
+
+    /** Constant for the "9" key. */
      public static final int VK_9              = 0x39;

      /**
@@ -279,31 +330,83 @@
      public static final int VK_EQUALS         = 0x3D;

      /** VK_A thru VK_Z are the same as ASCII 'A' thru 'Z' (0x41 - 0x5A) */
+
+    /** Constant for the "A" key. */
      public static final int VK_A              = 0x41;
+
+    /** Constant for the "B" key. */
      public static final int VK_B              = 0x42;
+
+    /** Constant for the "C" key. */
      public static final int VK_C              = 0x43;
+
+    /** Constant for the "D" key. */
      public static final int VK_D              = 0x44;
+
+    /** Constant for the "E" key. */
      public static final int VK_E              = 0x45;
+
+    /** Constant for the "F" key. */
      public static final int VK_F              = 0x46;
+
+    /** Constant for the "G" key. */
      public static final int VK_G              = 0x47;
+
+    /** Constant for the "H" key. */
      public static final int VK_H              = 0x48;
+
+    /** Constant for the "I" key. */
      public static final int VK_I              = 0x49;
+
+    /** Constant for the "J" key. */
      public static final int VK_J              = 0x4A;
+
+    /** Constant for the "K" key. */
      public static final int VK_K              = 0x4B;
+
+    /** Constant for the "L" key. */
      public static final int VK_L              = 0x4C;
+
+    /** Constant for the "M" key. */
      public static final int VK_M              = 0x4D;
+
+    /** Constant for the "N" key. */
      public static final int VK_N              = 0x4E;
+
+    /** Constant for the "O" key. */
      public static final int VK_O              = 0x4F;
+
+    /** Constant for the "P" key. */
      public static final int VK_P              = 0x50;
+
+    /** Constant for the "Q" key. */
      public static final int VK_Q              = 0x51;
+
+    /** Constant for the "R" key. */
      public static final int VK_R              = 0x52;
+
+    /** Constant for the "S" key. */
      public static final int VK_S              = 0x53;
+
+    /** Constant for the "T" key. */
      public static final int VK_T              = 0x54;
+
+    /** Constant for the "U" key. */
      public static final int VK_U              = 0x55;
+
+    /** Constant for the "V" key. */
      public static final int VK_V              = 0x56;
+
+    /** Constant for the "W" key. */
      public static final int VK_W              = 0x57;
+
+    /** Constant for the "X" key. */
      public static final int VK_X              = 0x58;
+
+    /** Constant for the "Y" key. */
      public static final int VK_Y              = 0x59;
+
+    /** Constant for the "Z" key. */
      public static final int VK_Z              = 0x5A;

      /**
@@ -321,17 +424,40 @@
       */
      public static final int VK_CLOSE_BRACKET  = 0x5D;

+    /** Constant for the number pad "0" key. */
      public static final int VK_NUMPAD0        = 0x60;
+
+    /** Constant for the number pad "1" key. */
      public static final int VK_NUMPAD1        = 0x61;
+
+    /** Constant for the number pad "2" key. */
      public static final int VK_NUMPAD2        = 0x62;
+
+    /** Constant for the number pad "3" key. */
      public static final int VK_NUMPAD3        = 0x63;
+
+    /** Constant for the number pad "4" key. */
      public static final int VK_NUMPAD4        = 0x64;
+
+    /** Constant for the number pad "5" key. */
      public static final int VK_NUMPAD5        = 0x65;
+
+    /** Constant for the number pad "6" key. */
      public static final int VK_NUMPAD6        = 0x66;
+
+    /** Constant for the number pad "7" key. */
      public static final int VK_NUMPAD7        = 0x67;
+
+    /** Constant for the number pad "8" key. */
      public static final int VK_NUMPAD8        = 0x68;
+
+    /** Constant for the number pad "9" key. */
      public static final int VK_NUMPAD9        = 0x69;
+
+    /** Constant for the number pad multiply key. */
      public static final int VK_MULTIPLY       = 0x6A;
+
+    /** Constant for the number pad add key. */
      public static final int VK_ADD            = 0x6B;

      /**
@@ -347,11 +473,22 @@
       */
      public static final int VK_SEPARATOR      = VK_SEPARATER;

+    /** Constant for the number pad subtract key. */
      public static final int VK_SUBTRACT       = 0x6D;
+
+    /** Constant for the number pad decimal point key. */
      public static final int VK_DECIMAL        = 0x6E;
+
+    /** Constant for the number pad divide key. */
      public static final int VK_DIVIDE         = 0x6F;
+
+    /** Constant for the delete key. */
      public static final int VK_DELETE         = 0x7F; /* ASCII DEL */
+
+    /** Constant for the NUM_LOCK key. */
      public static final int VK_NUM_LOCK       = 0x90;
+
+    /** Constant for the SCROLL_LOCK key. */
      public static final int VK_SCROLL_LOCK    = 0x91;

      /** Constant for the F1 function key. */
@@ -463,12 +600,22 @@
       */
      public static final int VK_F24            = 0xF00B;

+    /**  Constant for the PRINTSCREEN key. */
      public static final int VK_PRINTSCREEN    = 0x9A;
+
+    /**  Constant for the INSERT key. */
      public static final int VK_INSERT         = 0x9B;
+
+    /**  Constant for the HELP key. */
      public static final int VK_HELP           = 0x9C;
+
+    /**  Constant for the META key. */
      public static final int VK_META           = 0x9D;

+    /**  Constant for the BACK_QUOTE  key. */
      public static final int VK_BACK_QUOTE     = 0xC0;
+
+    /**  Constant for the QUOTE key. */
      public static final int VK_QUOTE          = 0xDE;

      /**
@@ -638,6 +785,7 @@
      /* for input method support on Asian Keyboards */

      /* not clear what this means - listed in Microsoft Windows API */
+    /** Constant for the FINAL key. */
      public static final int VK_FINAL                    = 0x0018;

      /** Constant for the Convert function key. */
@@ -653,14 +801,23 @@
      public static final int VK_ACCEPT                   = 0x001E;

      /* not clear what this means - listed in Microsoft Windows API */
+    /** Constant for the MODECHANGE key. */
      public static final int VK_MODECHANGE               = 0x001F;

      /* replaced by VK_KANA_LOCK for Microsoft Windows and Solaris;
         might still be used on other platforms */
+    /**
+     * Constant for the KANA lock key.
+     * @see #VK_KANA_LOCK
+     **/
      public static final int VK_KANA                     = 0x0015;

      /* replaced by VK_INPUT_METHOD_ON_OFF for Microsoft Windows and 
Solaris;
         might still be used for other platforms */
+    /**
+     * Constant for KANJI.
+     * @see #VK_INPUT_METHOD_ON_OFF
+     */
      public static final int VK_KANJI                    = 0x0019;

      /**
@@ -1085,7 +1242,25 @@
      }

      /**
-     * @deprecated as of JDK1.1
+     * @deprecated as of JDK1.1; use {@link #KeyEvent(Component, int, 
long, int, int, char)} instead
+     * @param source    The <code>Component</code> that originated the 
event
+     * @param id              An integer indicating the type of event.
+     *                  For information on allowable values, see
+     *                  the class description for {@link KeyEvent}
+     * @param when      A long integer that specifies the time the event
+     *                  occurred.
+     *                     Passing negative or zero value
+     *                     is not recommended
+     * @param modifiers The modifier keys down during event (shift, ctrl,
+     *                  alt, meta).
+     *                     Passing negative value
+     *                     is not recommended.
+     *                     Zero value means that no modifiers were passed.
+     *                  Use either an extended _DOWN_MASK or old _MASK 
modifiers,
+     *                  however do not mix models in the one event.
+     *                  The extended modifiers are preferred for using
+     * @param keyCode   The integer code for an actual key, or VK_UNDEFINED
+     *                  (for a key-typed event)
       */
      @Deprecated
      public KeyEvent(Component source, int id, long when, int modifiers,
@@ -1184,6 +1359,7 @@
       * Returns a String describing the keyCode, such as "HOME", "F1" 
or "A".
       * These strings can be localized by changing the awt.properties file.
       *
+     * @param keyCode the key whose description is to be returned
       * @return a string containing a text description for a physical key,
       *         identified by its keyCode
       */
@@ -1376,6 +1552,7 @@
       * <code>InputEvent.BUTTON3_MASK</code> have the same value,
       * so the string "Meta" is returned for both modifiers.
       *
+     * @param modifiers the modifier mask to be processed
       * @return string a text description of the combination of modifier
       *                keys that were held down during the event
       * @see InputEvent#getModifiersExText(int)
@@ -1612,8 +1789,8 @@
       * Pressing the same key in a regular Russian layout gives another 
code, unique for the
       * letter "Cyrillic I short".
       *
+     * @return an extended key code for the event
       * @since 1.7
-     *
       */
      public  int getExtendedKeyCode() {
          return (int)extendedKeyCode;
@@ -1621,6 +1798,7 @@
      /**
       * Returns an extended key code for a unicode character.
       *
+     * @param c the unicode character to be processed
       * @return for a unicode character with a corresponding {@code 
VK_} constant -- this
       *   {@code VK_} constant; for a character appearing on the primary
       *   level of a known keyboard layout -- a unique integer.
@@ -1628,7 +1806,6 @@
       *   {@code VK_UNDEFINED} is returned.
       *
       * @since 1.7
-     *
       */
      public static int getExtendedKeyCodeForChar(int c) {
          // Return a keycode (if any) associated with a character.


From Sergey.Bylokhov at oracle.com  Mon Dec 30 03:12:08 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 30 Dec 2013 15:12:08 +0400
Subject: <AWT Dev> [9] Review Request: JDK-7154841 [macosx] Popups
 appear behind taskbar
In-Reply-To: <52B95152.8020404@oracle.com>
References: <22834E0B-0F8D-4686-827A-725CBD755C68@oracle.com>	<52B88ABC.3040505@oracle.com>	<A888160B-0AA2-43DD-AFF4-7311BBD1862A@oracle.com>
	<52B95152.8020404@oracle.com>
Message-ID: <52C15508.1020800@oracle.com>

Hi, Petr.
One related question:
Is this change related to the SunToolkit.canPopupOverlapTaskBar()? Do 
you know why it always return false on macosx?

On 24.12.2013 13:18, Sergey Bylokhov wrote:
> HI, Petr.
> Is it possible to the window have a few levels? If not we can use 
> ifelse in applyWindowLevel(). Should we update 
> CWarningWindow.setVisible() also?
>
> On 12/24/13 12:50 PM, Petr Pchelko wrote:
>> Hello, Anthony.
>>
>> Thank you for the review.
>>
>> The updated version could be found here:http://cr.openjdk.java.net/~pchelko/9/7154841/webrev.01/
>>
>> With best regards. Petr.
>>
>> On 23.12.2013, at 23:10, Anthony Petrov<anthony.petrov at oracle.com>  wrote:
>>
>>> Hi Petr,
>>>
>>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
>>>> 621                         applyWindowLevel();
>>> Here the applyWindowLevel() method should be invoked on the 'pw' instance rather than on 'this'.
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 12/23/2013 07:21 PM, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>>
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-7154841
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/9/7154841/webrev/
>>>>
>>>> The fix is simple: for popup windows we should use an NSPopupMenuWindowLevel level.
>>>>
>>>> With best regards. Petr.
>>>>
>
>
> -- 
> Best regards, Sergey.


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131230/00441725/attachment.html 

From joe.darcy at oracle.com  Tue Dec 31 00:51:52 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 31 Dec 2013 00:51:52 -0800
Subject: <AWT Dev> JDK 9 RFR of JDK-8031082 Fix non-missing doclint problems
 in client libraries
Message-ID: <52C285A8.9060207@oracle.com>

Hello,

Please review my fix for

     JDK-8031082 Fix non-missing doclint problems in client libraries

The fix resolves nearly all of the outstanding doclint issues in the 
client libraries, others than the missing javadoc tags. The affected 
files are

src/share/classes/java/awt/Graphics2D.java
src/share/classes/java/awt/MediaTracker.java
src/share/classes/java/awt/font/TextAttribute.java
src/share/classes/java/awt/peer/ComponentPeer.java
src/share/classes/java/awt/peer/DialogPeer.java
src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java
src/share/classes/java/awt/peer/MouseInfoPeer.java
src/share/classes/java/awt/peer/PanelPeer.java
src/share/classes/java/awt/peer/TextAreaPeer.java
src/share/classes/java/awt/peer/WindowPeer.java
src/share/classes/java/awt/print/Paper.java
src/share/classes/java/awt/print/Printable.java
src/share/classes/java/beans/XMLEncoder.java
src/share/classes/javax/accessibility/AccessibleContext.java
src/share/classes/javax/imageio/ImageWriter.java
src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java
src/share/classes/javax/imageio/stream/ImageInputStream.java
src/share/classes/javax/imageio/stream/ImageOutputStream.java
src/share/classes/javax/print/Doc.java
src/share/classes/javax/print/DocFlavor.java
src/share/classes/javax/print/MultiDoc.java
src/share/classes/javax/print/MultiDocPrintJob.java
src/share/classes/javax/print/ServiceUI.java
src/share/classes/javax/print/StreamPrintServiceFactory.java
src/share/classes/javax/print/attribute/AttributeSet.java
src/share/classes/javax/print/attribute/standard/Chromaticity.java
src/share/classes/javax/print/attribute/standard/Copies.java
src/share/classes/javax/print/attribute/standard/Fidelity.java
src/share/classes/javax/print/attribute/standard/Finishings.java
src/share/classes/javax/print/attribute/standard/JobKOctets.java
src/share/classes/javax/print/attribute/standard/JobState.java
src/share/classes/javax/print/attribute/standard/MediaName.java
src/share/classes/javax/print/attribute/standard/MediaSize.java
src/share/classes/javax/print/attribute/standard/MediaSizeName.java
src/share/classes/javax/print/attribute/standard/MediaTray.java
src/share/classes/javax/print/attribute/standard/MultipleDocumentHandling.java
src/share/classes/javax/print/attribute/standard/NumberUp.java
src/share/classes/javax/print/attribute/standard/PageRanges.java
src/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java
src/share/classes/javax/print/attribute/standard/PrinterResolution.java
src/share/classes/javax/print/attribute/standard/SheetCollate.java
src/share/classes/javax/print/attribute/standard/Sides.java
src/share/classes/javax/sound/sampled/AudioInputStream.java
src/share/classes/javax/sound/sampled/AudioPermission.java
src/share/classes/javax/sound/sampled/ReverbType.java
src/share/classes/javax/swing/DefaultComboBoxModel.java
src/share/classes/javax/swing/JComboBox.java
src/share/classes/javax/swing/JEditorPane.java
src/share/classes/javax/swing/JLabel.java
src/share/classes/javax/swing/JLayeredPane.java
src/share/classes/javax/swing/JOptionPane.java
src/share/classes/javax/swing/JTextArea.java
src/share/classes/javax/swing/JTextPane.java
src/share/classes/javax/swing/plaf/TextUI.java
src/share/classes/javax/swing/plaf/basic/BasicTextUI.java
src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java
src/share/classes/javax/swing/text/CompositeView.java
src/share/classes/javax/swing/text/DefaultEditorKit.java
src/share/classes/javax/swing/text/Document.java
src/share/classes/javax/swing/text/GlyphView.java
src/share/classes/javax/swing/text/JTextComponent.java
src/share/classes/javax/swing/text/NavigationFilter.java
src/share/classes/javax/swing/text/html/HTMLDocument.java
src/share/classes/javax/swing/text/html/StyleSheet.java

and the full webrev is hosted at

     http://cr.openjdk.java.net/~darcy/8031082.0/

Thanks,

-Joe

From mikhail.cherkasov at oracle.com  Tue Dec 31 03:59:29 2013
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Tue, 31 Dec 2013 15:59:29 +0400
Subject: <AWT Dev> review request: focus disappears with shift+tab on
 dialogue having a focus component
Message-ID: <52C2B1A1.8060803@oracle.com>

Hello all,

Could you please review the following fix:
https://bugs.openjdk.java.net/browse/JDK-8031075
review request: focus disappears with shift+tab on dialogue having a 
focus component
http://cr.openjdk.java.net/~mcherkas/8031075/webrev.00/ 
<http://cr.openjdk.java.net/%7Emcherkas/8031075/webrev.00/>

Jdk8 already has it, also it was in jdk7 too, but was mistakenly 
reverted by other fix, so
I'm just returning it back.


Thanks,
Mikhail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131231/73aa6542/attachment.html