This is +1 from me.
Honestly I don't think it needs a re-review by Mandy too just to that
comment.
So go ahead and push.
-phil.
On 11/1/16, 4:21 PM, Pete Brunet wrote:
JPRT job ran OK. Just need +1s from Phil/Mandy for the comment change
shown below.
On 11/1/16 9:56 AM, Pete Brunet wrote:
JPRT job ran OK. Just need +1s from Phil/Mandy for the comment change
shown below.
On 11/1/16 9:56 AM, Pete Brunet wrote:
> Mandy and Phil, I thought it would be helpful to add this to the comment
> in AccesssBridgeCalls.h:
>
> *
> * Also note that the API is used in the jaccessinspector and
>
Mandy and Phil, I thought it would be helpful to add this to the comment
in AccesssBridgeCalls.h:
*
* Also note that the API is used in the jaccessinspector and
jaccesswalker tools.
* The source for those tools is available in the OpenJDK repository at
these links:
*
*
http://hg.openjdk.java.
Looks good.
/Erik
On 2016-10-31 15:36, Pete Brunet wrote:
On 10/28/16 8:14 PM, Mandy Chung wrote:
On Oct 28, 2016, at 1:59 PM, Philip Race wrote:
If it is not in the image then there is no point in the file existing.
Maybe this could just be a comment at the top of the include file.
This
On 10/31/16 11:38 AM, Phil Race wrote:
> +1.
>
> I am assuming you made sure AccessBridgeCalls.c is not being compiled
> during the JDK build as discussed earlier ...
I looked into this. The obj is needed to build
accessbridgeinspector/walker. Searching the built directories
AccessBridgeCalls.*
+1.
I am assuming you made sure AccessBridgeCalls.c is not being compiled
during the JDK build as discussed earlier ...
-phil.
On 10/31/2016 07:36 AM, Pete Brunet wrote:
On 10/28/16 8:14 PM, Mandy Chung wrote:
On Oct 28, 2016, at 1:59 PM, Philip Race wrote:
If it is not in the image then t
> On Oct 31, 2016, at 7:36 AM, Pete Brunet wrote:
>
>
>
> On 10/28/16 8:14 PM, Mandy Chung wrote:
>>> On Oct 28, 2016, at 1:59 PM, Philip Race wrote:
>>>
>>> If it is not in the image then there is no point in the file existing.
>>> Maybe this could just be a comment at the top of the includ
On 10/28/16 8:14 PM, Mandy Chung wrote:
>> On Oct 28, 2016, at 1:59 PM, Philip Race wrote:
>>
>> If it is not in the image then there is no point in the file existing.
>> Maybe this could just be a comment at the top of the include file.
>>
> This works for me.
Updated:
http://cr.openjdk.java.ne
> On Oct 28, 2016, at 1:59 PM, Philip Race wrote:
>
> If it is not in the image then there is no point in the file existing.
> Maybe this could just be a comment at the top of the include file.
>
This works for me.
Mandy
> -phil.
>
> On 10/28/16, 12:42 PM, Mandy Chung wrote:
>>> On Oct 28,
If it is not in the image then there is no point in the file existing.
Maybe this could just be a comment at the top of the include file.
-phil.
On 10/28/16, 12:42 PM, Mandy Chung wrote:
On Oct 28, 2016, at 11:32 AM, Pete Brunet wrote:
Hi Mandy, That simplifies things. The new patch is at:
h
It's in the image so users of the headers in the image will know where
to go find the .c file. Users might be able to figure out how to use
the API without having to hunt down the documentation. But please
discuss with Phil.
I will also be updating the documentation via
https://bugs.openjdk.java
> On Oct 28, 2016, at 11:32 AM, Pete Brunet wrote:
>
> Hi Mandy, That simplifies things. The new patch is at:
> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.08/
Looks better.
I only notice now that the readme.html is in the include directory. That
should be in the documentation
Hi Mandy, That simplifies things. The new patch is at:
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.08/
Pete
On 10/27/16 6:51 PM, Mandy Chung wrote:
>> On Oct 27, 2016, at 4:31 PM, Pete Brunet wrote:
>>
>> I moved the source to
>> src/jdk.accessibility/windows/native/bridge/src
> “sr
> On Oct 27, 2016, at 4:31 PM, Pete Brunet wrote:
>
> I moved the source to
> src/jdk.accessibility/windows/native/bridge/src
“src” subdirectory is redundant that should be dropped.
> and the includes to
> src/jdk.accessibility/windows/native/bridge/include
Please see the source layout defin
On 10/27/16 6:31 PM, Pete Brunet wrote:
> On 10/27/16 1:30 PM, Mandy Chung wrote:
>>> On Oct 27, 2016, at 10:44 AM, Phil Race wrote:
>>>
>>> No, we are definitely shipping those.
>>> Unless of course you think we should stop shipping JNI headers too …
>>>
>> No. I tried to understand what is ex
On 10/27/16 1:30 PM, Mandy Chung wrote:
>> On Oct 27, 2016, at 10:44 AM, Phil Race wrote:
>>
>> No, we are definitely shipping those.
>> Unless of course you think we should stop shipping JNI headers too …
>>
> No. I tried to understand what is external interface. I took it that these
> header
On 10/27/2016 11:52 AM, Pete Brunet wrote:
On 10/27/16 1:47 PM, Pete Brunet wrote:
On 10/27/16 1:34 PM, Phil Race wrote:
In which case be careful it is not built by the JDK build ..
Build team, Is there anything I need to handle here to make sure it isn't?
Actually, let me give it a try. I
On 10/27/16 1:47 PM, Pete Brunet wrote:
>
> On 10/27/16 1:34 PM, Phil Race wrote:
>> In which case be careful it is not built by the JDK build ..
> Build team, Is there anything I need to handle here to make sure it isn't?
Actually, let me give it a try. I should be able to resolve any
issues.
On 10/27/16 1:34 PM, Phil Race wrote:
> In which case be careful it is not built by the JDK build ..
Build team, Is there anything I need to handle here to make sure it isn't?
> unless that is actually required .. which I didn't think it was.
>
> -phil.
>
> On 10/27/2016 11:30 AM, Mandy Chung wro
On 10/27/16 1:34 PM, Phil Race wrote:
> In which case be careful it is not built by the JDK build ..
> unless that is actually required .. which I didn't think it was.
It isn't.
>
> -phil.
>
> On 10/27/2016 11:30 AM, Mandy Chung wrote:
>> Please move AccessBridgeCalls.c to
>> src/jdk.accessibili
In which case be careful it is not built by the JDK build ..
unless that is actually required .. which I didn't think it was.
-phil.
On 10/27/2016 11:30 AM, Mandy Chung wrote:
Please move AccessBridgeCalls.c to src/jdk.accessibility/windows/native/bridge
directory.
> On Oct 27, 2016, at 10:44 AM, Phil Race wrote:
>
> No, we are definitely shipping those.
> Unless of course you think we should stop shipping JNI headers too …
>
No. I tried to understand what is external interface. I took it that these
header files are external interfaces.
I reviewed:
No, we are definitely shipping those.
Unless of course you think we should stop shipping JNI headers too ...
-phil
On 10/27/2016 10:37 AM, Mandy Chung wrote:
Should they be kept just in the source and not to be included in the
image/include directory?
It’s not clear to me if anyone needs thes
Should they be kept just in the source and not to be included in the
image/include directory?
It’s not clear to me if anyone needs these header files from the JDK image as
AccessBridgeCalls.c is obtained from the source.
Mandy
> On Oct 27, 2016, at 6:48 AM, Pete Brunet wrote:
>
> The .h file
This all seems fine.
Do other accessbridge files still have the remnants of SCCS ? :-
That was purged from all the other JDK files when we moved to mercurial.
33 /*
34 * @(#)AccessBridgeCalls.c 1.25 05/08/22
35 */
If "yes", then I suggest to file a clean-up bug to clean up all of
Thanks for noticing that Phil. Updated at
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.05/
On 10/27/16 9:20 AM, Philip Race wrote:
> But it still needs to say "jdk9/jdk9" not jdk9/client or jdk9/dev.
>
> -phil.
>
> On 10/26/16, 9:27 PM, Anirvan Sarkar wrote:
>> Hi,
>>
>> If you replac
But it still needs to say "jdk9/jdk9" not jdk9/client or jdk9/dev.
-phil.
On 10/26/16, 9:27 PM, Anirvan Sarkar wrote:
Hi,
If you replace the hex number with 'tip' then it will always point to
the latest version.
Something like
http://hg.openjdk.java.net/jdk9/client/jdk/file/tip/src/jdk.acc
The .h files are unlicensed in the bundle/install so no need?
On 10/26/16 11:52 PM, Mandy Chung wrote:
> Should the same change be applied to the .h files as well?
>
> Mandy
>
>> On Oct 26, 2016, at 7:24 PM, Pete Brunet wrote:
>>
>> Please review the latest update at
>> http://cr.openjdk.java.net
Build change looks good.
/Erik
On 2016-10-27 04:24, Pete Brunet wrote:
Please review the latest update at
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/
The change is to AccessBridgeCalls.c. The license has been changed from
GPL2 to BSD. This is because the file was originally
Should the same change be applied to the .h files as well?
Mandy
> On Oct 26, 2016, at 7:24 PM, Pete Brunet wrote:
>
> Please review the latest update at
> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/
>
> The change is to AccessBridgeCalls.c. The license has been changed from
>
Thanks Anirvan. Appreciate you taking the time to participate in this
thread.
On 10/26/16 11:27 PM, Anirvan Sarkar wrote:
> Hi,
>
> If you replace the hex number with 'tip' then it will always point to
> the latest version.
>
> Something
> like
> http://hg.openjdk.java.net/jdk9/client/jdk/file/
Hi,
If you replace the hex number with 'tip' then it will always point to the
latest version.
Something like http://hg.openjdk.java.net/jdk9/client/jdk/file/tip/
src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c
Regards,
Anirvan Sarkar
On Thursday 27 October 2016, Pete Bru
I found a comment from Mandy in the bug. That hex number can be
replaced with "tip".
I uploaded http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.04/
Pete
On 10/26/16 11:05 PM, Pete Brunet wrote:
>
>
> On 10/26/16 10:44 PM, Philip Race wrote:
>> >
>> 15 > href="http://hg.openjd
On 10/26/16 10:44 PM, Philip Race wrote:
> >
> 15 href="http://hg.openjdk.java.net/jdk9/client/jdk/file/544828ab2a9b/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c";>
> That URL is definitely not authoritative.
>
> I think you need to give a pointer to somethin
>
15http://hg.openjdk.java.net/jdk9/client/jdk/file/544828ab2a9b/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c";>
That URL is definitely not authoritative.
I think you need to give a pointer to something more like
http://hg.openjdk.java.net/jdk9/jdk9/jdk/src/jdk.acces
Please review the latest update at
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/
The change is to AccessBridgeCalls.c. The license has been changed from
GPL2 to BSD. This is because the file was originally unlicensed prior
to being bundled into the JDK and the compiled .obj is link
The fix looks good to me.
Thanks,
Alexandr.
On 10/24/2016 1:18 PM, Erik Joelsson wrote:
The last change looks good and simple to me.
/Erik
On 2016-10-21 06:55, Pete Brunet wrote:
Please see the latest update
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/
The fix now is to sim
The last change looks good and simple to me.
/Erik
On 2016-10-21 06:55, Pete Brunet wrote:
Please see the latest update
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/
The fix now is to simply remove the copy of the AccessBridgeCalls.c file
into the JDK.
AccessBridgeCalls.c is th
Please see the latest update
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/
The fix now is to simply remove the copy of the AccessBridgeCalls.c file
into the JDK.
AccessBridgeCalls.c is the implementation of the documented Java Access
Bridge API and is a set of wrapper functions that
I've updated the webrev. Please see
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/
Rather than removing the files needed by Assistive Technology developers
we have to provide them in JDK. However since there is a .c file in the
group of files the files were moved from the include di
On 2016-10-14 17:51, Pete Brunet wrote:
Please review the following.
The .h files and .c file provided to allow Assistive Technology to
interface to the Java Access Bridge API are being removed from the built
JRE/JDK images. They are not used much and they can be obtained online
via the OpenJDK
It sounds like it would be easier to keep the files in the JDK then.
I'll wait for other comments before I redo the patch.
On 10/14/16 12:28 PM, Phil Race wrote:
> One big problem I see with this is that it means they will only be
> available under the GPL license
> as they will not be in an Orac
One big problem I see with this is that it means they will only be
available under the GPL license
as they will not be in an Oracle JDK which strips the GPL
So if you are going to do this then these files first need to be
dual-licensed
because otherwise people can't link their commercial produ
Please review the following.
The .h files and .c file provided to allow Assistive Technology to
interface to the Java Access Bridge API are being removed from the built
JRE/JDK images. They are not used much and they can be obtained online
via the OpenJDK web site. The pubs will be updated to m
44 matches
Mail list logo
