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
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
> 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
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:
> 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
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
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
> 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
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
>>
> 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
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
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
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
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
>>
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
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
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
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
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
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
>>
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
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
>
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
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 >
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
>
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
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
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
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
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
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
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
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
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
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
41 matches
Mail list logo