Hi Kevin,
Right, I just assumed we would need some coordination.
Thanks,
Anton.
On 30.03.2015 17:48, Kevin Rushforth wrote:
Hi Anton,
Yes, there are concerns regarding this, mainly due to the timing and build issues. After this week
we are no longer auto-syncing changes from 8u-dev into 9,
Hi Anton,
Yes, there are concerns regarding this, mainly due to the timing and
build issues. After this week we are no longer auto-syncing changes from
8u-dev into 9, so we are at a good point to do this, but it will need to
be done carefully. I expect that we will need at least 2 weeks to
Hi Sergey, Kevin,
This method is called from JFX/interop:
DropTargetContext.java
-public void addNotify(DropTargetContextPeer dtcp) {
An accessor is introduced. So, we will have to pick it up in JFX/interop once
the fix is in the ws.
This means we won't be able to run jfx9 atop of jdk8.
Hello,
Please review an updated version of the fix.
http://cr.openjdk.java.net/~serb/8074763/webrev.02
DropTargetContext.addNotify/removeNotify were renamed and access was
changed to a package private. A necessary methods were added to the
AWTAccessor.
18.03.15 23:47, Phil Race wrote:
I
Hi Sergey,
The only dependency on JFX/interop is this method in DropTargetContext.java:
98 public void addNotify(final Object dtcp) throws IllegalArgumentException
{
Was that the reason why you left the parameter?
Is it technically possible to retrieve the peer via the
Hi, Anton.
The problem is that this method is called when the peer itself change
the information in the DropTargetContext. So this method works like a
setter. I can make this method private, and get an access to it via
accessor. Will it be better?
18.03.15 8:27, Anton V. Tarasov wrote:
Hi
Hi, Anton.
The problem is that this method is called when the peer itself change
the information in the DropTargetContext. So this method works like a
setter. I can make this method private, and get an access to it via
accessor. Will it be better?
18.03.15 8:27, Anton V. Tarasov wrote:
Hi
I think its preferable to remove (hide) the method rather than leave one
that
no application code can (or should) call because they can't provide a
parameter
of the required type.
-phil.
On 03/18/2015 09:24 AM, Sergey Bylokhov wrote:
Hi, Anton.
The problem is that this method is called when
My first assumption was that we can get rid of the peer parameter at all
(like you did in DropTarget.java), however this doesn't seem possible
regardless of JFX/interop (AFAICS).
On 18/03/15 19:23, Sergey Bylokhov wrote:
Hi, Anton.
The problem is that this method is called when the peer
16.03.15 16:06, Kevin Rushforth wrote:
The change looks fine to me. I tried to apply the patch (to verify
that it doesn't affect JFXPanel) but got merge conflicts with the
latest (as of today) jdk9/client/jdk repo. As long as Anton has
verified that it doesn't break compatibility with JFXPanel
The change looks fine to me. I tried to apply the patch (to verify that
it doesn't affect JFXPanel) but got merge conflicts with the latest (as
of today) jdk9/client/jdk repo. As long as Anton has verified that it
doesn't break compatibility with JFXPanel I am OK with the change.
-- Kevin
Hello.
Please review the fix for jdk 9.
There are a number of public API which reference the unsupported
java.awt. dnd.peer interfaces.
protected
java.awt.dnd.DragSource.createDragSourceContext(java.awt.dnd.peer.DragSourceContextPeer,
...)
public
On 16/03/2015 18:30, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
There are a number of public API which reference the unsupported
java.awt. dnd.peer interfaces.
protected
java.awt.dnd.DragSource.createDragSourceContext(java.awt.dnd.peer.DragSourceContextPeer,
...)
public
13 matches
Mail list logo
