Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

Erik, I need your +1 again because the make files have changed since you last looked. I'll also be running JPRT before I push. Pete > > -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,

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

gt;> > This works for me. Updated: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.09/ > > Mandy > >> -phil. >> >> On 10/28/16, 12:42 PM, Mandy Chung wrote: >>>> On Oct 28, 2016, at 11:32 AM, Pete Brunet<peter.bru...@oracle.com>

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

://bugs.openjdk.java.net/browse/JDK-8168018 Pete On 10/28/16 2:42 PM, Mandy Chung wrote: >> On Oct 28, 2016, at 11:32 AM, Pete Brunet <peter.bru...@oracle.com> wrote: >> >> Hi Mandy, That simplifies things. The new patch is at: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webr

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

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 <peter.bru...@oracle.com> wrote: >> >> I moved the source to

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

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 <philip.r...@oracle.com> wrote: >>> >>> No, we are definitely shipping those. >>> Unless of course you think we should stop s

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

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

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

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 res

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

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

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

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

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

BridgeCalls.c >> <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 Brunet <peter.bru...@oracle.com >&g

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

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 <peter.bru...@oracle.com> wrote: >> >

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

net/jdk9/client/jdk/file/tip/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c > <http://hg.openjdk.java.net/jdk9/client/jdk/file/tip/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c> > > Regards, > Anirvan Sarkar > > On

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

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

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

ot;latest" link. Maybe some other reader will know. > > But I am not sure about that either .. it may need to be split between the > main URL and the location in the repo. > > -phil > > > On 10/26/16, 7:24 PM, Pete Brunet wrote: >> Please review the latest up

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

/25/16 6:48 AM, Alexandr Scherbatiy wrote: > > 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, Pet

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

with the current API and related calls into WindowsAccessBridge*.dll. Pete On 10/18/16 12:28 PM, Pete Brunet wrote: > 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 develope

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

directory to a new javaaccessbridge directory. On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote: > 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

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

icense > 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 products with these. > > -phil. > > On 10/14/2016 08:51 AM, Pete Brunet wrote: >> Please r

RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

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

Re: build failing on Mac

run "sudo xcode-select -switch > /path/to/Xcode.app"? > > -DrD- > >> On Jun 22, 2016, at 10:09 PM, Pete Brunet <peter.bru...@oracle.com> wrote: >> >> Installed 6.3.2. Refreshed source. Ran configure. make clean. make >> images. Build faile

Re: build failing on Mac

, Daniel Fuchs wrote: > Hi Pete, > > I had the same problem recently - and solved it by installing > Xcode 6.3 - which I was told is the officially supported version. > > best regards, > > -- daniel > > On 18/06/16 01:20, Pete Brunet wrote: >> I haven't done a fu

Re: build failing on Mac

Thanks Daniel! Bookmarked. On 6/20/16 8:18 AM, Daniel Fuchs wrote: > Hi Pete, > > On 20/06/16 13:24, Pete Brunet wrote: >> Thanks Daniel, I will give it a try. I've not been having luck recently >> finding old versions of xcode. Any thoughts on the best place to >&

Re: build failing on Mac

.3 - which I was told is the officially supported version. > > best regards, > > -- daniel > > On 18/06/16 01:20, Pete Brunet wrote: >> I haven't done a full build in around a month, but just pulled (tpull >> -u) / cleaned / reconfigured and got this on my Mac: >>

Re: build failing on Mac

On 6/19/16 10:52 PM, David Holmes wrote: > On 18/06/2016 10:20 AM, Pete Brunet wrote: >> I haven't done a full build in around a month, but just pulled (tpull >> -u) / cleaned / reconfigured and got this on my Mac: > > Did you update Xcode in that month? Hi David, II

Re: build failing on Mac

An using configure switch --disable-warnings-as-errors for now. On 6/17/16 7:20 PM, Pete Brunet wrote: > I haven't done a full build in around a month, but just pulled (tpull > -u) / cleaned / reconfigured and got this on my Mac: > > ... > Creating gtestLauncher from 1 file(s) &

Re: Mac build failing

Installing the xcode command line tools resolved that issue. xcode-select --install On 5/9/16 5:26 PM, Pete Brunet wrote: > Back on 6.2 but now getting > > Creating jjs from 1 file(s) > strip: error: unable to find utility "strip", not a developer tool or in > PATH

Re: Mac build failing

5/9/16 4:03 PM, Pete Brunet wrote: > Going back to 6.2. Hopefully 7.3.1 won't force install itself this time. > > On 5/9/16 3:30 PM, Pete Brunet wrote: >> Further along I got this (after using --disable-warnings-as-errors): >> >> ... >> Compiling 15 files for

Re: Mac build failing

Going back to 6.2. Hopefully 7.3.1 won't force install itself this time. On 5/9/16 3:30 PM, Pete Brunet wrote: > Further along I got this (after using --disable-warnings-as-errors): > > ... > Compiling 15 files for jdk.naming.dns > ld: warning: object file > (/Users/petebrune

Re: Mac build failing

with exit code 1 (use -v to see invocation) make[3]: *** [/Users/petebrunet/JDK9/JDK-8145207/client/build/macosx-x86_64-normal-server-release/support/modules_libs/java.base/libosxsecurity.dylib] Error 1 Pete On 5/9/16 3:17 PM, Pete Brunet wrote: > Thanks. That worked. > > On 5/9/16

Re: Mac build failing

Thanks. That worked. On 5/9/16 3:07 PM, Phil Race wrote: > The usual one --disable-warnings-as-errors when running configure. > > -phil. > > On 05/09/2016 01:11 PM, Pete Brunet wrote: >> Thanks Phil, I asked in the bug but will ask here too - is there a >> workaround

Re: Mac build failing

Thanks Phil, I asked in the bug but will ask here too - is there a workaround until the issue is resolved? In my case I have 6.2 and 7.3.1. Pete On 5/9/16 2:29 PM, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8152856 > > -phil. > > On 05/09/2016 12:20 PM, Pete Brun

Mac build failing

Am running into a build problem on Mac. Creating libjvm.dylib from 771 file(s) In file included from /Users/petebrunet/JDK9/JDK-8145207/client/hotspot/src/share/vm/precompiled/precompiled.hpp:30: In file included from

Re: small changes, long build time

What is exploded vs not exploded? On 5/3/16 4:55 AM, Erik Joelsson wrote: > > > On 2016-05-03 07:46, Alan Bateman wrote: >> >> >> On 03/05/2016 02:48, David Holmes wrote: >>> >>> So what build target will ensure the exploded image is created and >>> up to date? >> `make` without any target, that

Re: small changes, long build time

On 4/30/16 2:32 AM, David Holmes wrote: > On 30/04/2016 4:18 PM, Alan Bateman wrote: >> On 30/04/2016 00:46, Pete Brunet wrote: >>> Even small edits to code in the jdk source tree result in very long >>> time >>> build times now that jigsaw is mer

small changes, long build time

Even small edits to code in the jdk source tree result in very long time build times now that jigsaw is merged in. Is anyone working on trying to improve that? Is there a workaround? Thanks, Pete

Re: 32 bit build failed

Hi Erik, The boot jdk was 64 bit 8u60 b25. I'll send you a log shortly. -Pete On 4/26/16 4:29 AM, Erik Joelsson wrote: > What do you use as boot jdk? I would recommend using a 64bit JDK 8. > Could you rerun with LOG=debug and send me the build.log? > > /Erik > > On 2016-04-26

Re: Mac build failing: error: sending 'id' to parameter of incompatible type 'id'

-phil. > > On 04/01/2016 02:16 PM, Pete Brunet wrote: >> My Mac build is failing today. Maybe something changed with respect to >> the required SDK? >> >> I refreshed my source and rebuilt and this is the output. >> >> Building target 'images' in co

32 bit build failed

I did a 64 bit build OK but my 32 bit build is failing: Building configuration 'windows-x86-normal-server-release' (matching CONF=windows-x86-normal-server-release) Building target 'images' in configuration 'windows-x86-normal-server-release' Building JVM variant 'server' with features 'all-gcs

Mac build failing: error: sending 'id' to parameter of incompatible type 'id'

My Mac build is failing today. Maybe something changed with respect to the required SDK? I refreshed my source and rebuilt and this is the output. Building target 'images' in configuration 'macosx-x86_64-normal-server-release' Compiling 776 files for jdk.xml.bind Compiling 1227 files for

latest version of XCode?

What is the latest version of XCode we can use to build? I need to reinstall and am currently at 6.2.

Re: RFR: JDK-8143895: Fix LDFLAGS issues after JDK-8056925

Looks good Erik. On 11/24/15 7:00 AM, Erik Joelsson wrote: > Please review this minor build fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143895 > Patch: > diff -r 314ce60cae98 make/launcher/Launcher-jdk.accessibility.gmk > --- a/make/launcher/Launcher-jdk.accessibility.gmk Mon Nov

RfR JDK-8056925 Add jaccessinspector and jaccesswalker to the bin directory

Please review http://javaweb.us.oracle.com/~pbrunet/JDK-8056925/webrev.05/

Re: RfR JDK-8056925 Add jaccessinspector and jaccesswalker to the bin directory

I need to move that to a website that all will have access too. Will be back with that soon. On 11/20/15 10:07 AM, Pete Brunet wrote: > Please review http://javaweb.us.oracle.com/~pbrunet/JDK-8056925/webrev.05/

Re: RfR JDK-8056925 Add jaccessinspector and jaccesswalker to the bin directory

http://cr.openjdk.java.net/~ptbrunet/JDK-8056925/webrev.00/ On 11/20/15 10:09 AM, Pete Brunet wrote: > I need to move that to a website that all will have access too. Will be > back with that soon. > > On 11/20/15 10:07 AM, Pete Brunet wrote: >> Please review http://jav

unknown source

What do I need to do so the dumps know where the source is? -Pete Exception in thread "Thread-2" java.lang.RuntimeException: java.lang.NullPointer Exception at com.sun.java.accessibility.AccessBridge$InvocationUtils.invokeAndWait(AccessBridge.java:7202) at

RfR JDK-8134453,JAWS crashes in WindowsAccessBridge.DLL on 32 bit 8u60 running on 32 bit Win 7

Hi I need two reviewers for http://cr.openjdk.java.net/~ptbrunet/JDK-8134453/webrev.00/ This problem started in 8u60 b20 and is due to JDK-8078649 which is a backport of JDK-8043160. In this fix the text "LEGACY" in file jdk/make/lib/PlatformLibraries.gmk was changed to "legacy". The lower case

Re: AWT Dev RfR JDK-8055160

Thanks Mandy, The new patch is at http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.04 On 6/10/15 6:29 PM, Mandy Chung wrote: On Jun 10, 2015, at 3:33 PM, Pete Brunet peter.bru...@oracle.com wrote: Due to some other priorities it's been over 2 months since the last webrev. An update

Re: AWT Dev RfR JDK-8055160

Thanks Mandy. I need one more review from the awt-dev team. Pete On 6/10/15 6:29 PM, Mandy Chung wrote: On Jun 10, 2015, at 3:33 PM, Pete Brunet peter.bru...@oracle.com wrote: Due to some other priorities it's been over 2 months since the last webrev. An update is here: http

Re: AWT Dev RfR JDK-8055160

Note that I need to remove the import of java.io.PrintWriter in java.awt.Toolkit.java On 6/10/15 5:33 PM, Pete Brunet wrote: Due to some other priorities it's been over 2 months since the last webrev. An update is here: http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.03 The changes

RfR JDK-8078335

Please review this simple patch which causes jdk.accessibility to be built for all platforms, not just for Windows. I tested it on Win and Mac. http://cr.openjdk.java.net/~ptbrunet/JDK-8078335/webrev.00/ Pete

Re: AWT Dev RfR JDK-8055160

. Instead a file is created when Toolkit.getDefaultToolkit activates providers and tested for existence when the test runs. 2) The copyright header in the new jdk.accessibility files were fixed. Pete On 4/3/15 3:59 PM, Pete Brunet wrote: Due to the recent push of JDK-8076182 (Open source Java Access

Re: AWT Dev RfR JDK-8055160

in windows image at the moment. It is a bug. Are you going to fix that in this changeset? I think you have to verify this change in windows as well as other platforms. Mandy On Jun 10, 2015, at 3:33 PM, Pete Brunet peter.bru...@oracle.com wrote: Due to some other priorities it's been over

Re: need to build a DLL for an openjdk test

On 6/3/15 8:43 PM, Pete Brunet wrote: Cross posting to build-dev for possible insight regarding Jon's last paragraph below. On 6/3/15 8:13 PM, Jonathan Gibbons wrote: On 06/03/2015 04:27 PM, Pete Brunet wrote: Hi, As part of my test I need to build a simple DLL and then load it from my

need to build a DLL for an openjdk test

Cross posting to build-dev for possible insight regarding Jon's last paragraph below. On 6/3/15 8:13 PM, Jonathan Gibbons wrote: On 06/03/2015 04:27 PM, Pete Brunet wrote: Hi, As part of my test I need to build a simple DLL and then load it from my test class. Can jtreg build the DLL

RfR JDK-8077296 RE build fails on non-Win builds when attempting to build Win only javadoc

Please review the following change for 8u: http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/ Background: - As part of the open sourcing of the JAB and Java Accessibility Utilities (JAU) the JAU Javadoc was setup to be added to the build. - Due to a 8u build issue (it uses source

Re: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5

On 06.05.2015 15:39, Pete Brunet wrote: Hi Vadim, I had to defer from this for a while but am back at it. Apparently --with-xcode-path isn't currently a valid option. Pete On 4/7/15 10:22 AM, Vadim Pakhnushev wrote: Pete, have you tried sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3

Re: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5

doesn't pick the correct path from the xcode-select. Although I successfully built jdk8u on 10.10 with both xcode-select and --with-xcode-path BTW, the correct path for xcode-select would be /Applications/Xcode\ 4.6.3.app/Contents/Developer I guess. Thanks, Vadim On 07.04.2015 15:56, Pete

Re: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5

After installing XQuartz, thanks to the text at Problem #1 at http://mail.openjdk.java.net/pipermail/build-dev/2014-October.txt using these options worked --with-freetype-include=/usr/X11/include/freetype2 --with-freetype-lib=/usr/X11/lib Pete On 5/6/15 2:49 PM, Pete Brunet wrote: Thanks David

Re: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5

p.s. make images ran with no problems. On 5/6/15 3:09 PM, Pete Brunet wrote: After installing XQuartz, thanks to the text at Problem #1 at http://mail.openjdk.java.net/pipermail/build-dev/2014-October.txt using these options worked --with-freetype-include=/usr/X11/include/freetype2

Re: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5

--with-xcode-path explicit path to Xcode 4 (generally for building on 10.9 and later) Thanks, Vadim On 06.05.2015 15:39, Pete Brunet wrote: Hi Vadim, I had to defer from this for a while but am back at it. Apparently --with-xcode-path isn't currently

Re: build failure after switching to vs2013

, but since the removal of that code hasn't happened yet, I think we should propose your patch as a fix for that bug. /Erik On 2015-04-22 18:00, David Holmes wrote: On 23/04/2015 10:57 AM, Pete Brunet wrote: On 4/22/15 6:48 PM, David Holmes wrote: Peter, See https://bugs.openjdk.java.net

Re: 9 b58 fails on Win 8 when screen reader running

Hi Erik, It's https://bugs.openjdk.java.net/browse/INTJDK-7615864. On 4/22/15 8:20 PM, Erik Joelsson wrote: That's an interesting find. I suppose we need to add that linker flag then. Do you have a bug opened for this issue? /Erik On 2015-04-22 17:56, Pete Brunet wrote: The problem

Re: 9 b58 fails on Win 8 when screen reader running

this flag is set. Pete On 4/21/15 3:19 PM, Pete Brunet wrote: Hi Phil, On 4/21/15 2:42 PM, Phil Race wrote: Perhaps JAWS is not well behaved w.r.t multiple DLL versions ? Tell me more. Does it happen only on win 8 ? If you boot the same system into win 8 or win 8.1 is it OK ? Win 7

Re: build failure after switching to vs2013

On 4/22/15 6:48 PM, David Holmes wrote: Peter, See https://bugs.openjdk.java.net/browse/JDK-8077422 update 4 is not supported yet. Hi David, Do I need to uninstall Update 4 and install Update 3? -Pete David On 23/04/2015 8:02 AM, Pete Brunet wrote: This hack to jdk/make/lib/Lib

build failure after switching to vs2013

I was able to build 9 OK then I switched from VS2010 to VS2013 and now get the following. I tried hg tpull -u but that didn't help. Is there something I need to do besides installing VS Pro 2013 with Update 4? $ make images 21 | tee make-64.log Building target 'images' in configuration

Re: build failure after switching to vs2013

p.s. I also had done a make reconfigure and make clean. I'll try make clean and reconfigure from bash. On 4/22/15 4:06 PM, Pete Brunet wrote: I was able to build 9 OK then I switched from VS2010 to VS2013 and now get the following. I tried hg tpull -u but that didn't help

Re: build failure after switching to vs2013

:= -DHPROF_LOGGING, \ MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \ Pete On 4/22/15 4:12 PM, Pete Brunet wrote: p.s. I also had done a make reconfigure and make clean. I'll try make clean and reconfigure from bash. On 4/22/15 4:06 PM, Pete Brunet wrote: I was able

Re: build failure after switching to vs2013

On 4/22/15 4:52 PM, David Holmes wrote: On 23/04/2015 7:06 AM, Pete Brunet wrote: I was able to build 9 OK then I switched from VS2010 to VS2013 and now get the following. I tried hg tpull -u but that didn't help. Is there something I need to do besides installing VS Pro 2013 with Update

9 b58 fails on Win 8 when screen reader running

Starting with b58 with JAWS (screen reader) running on Win 8, when starting SwingSet2 the splash screen appears but the application doesn't start. There are no messages in the console. I see b58 only had one fix: 8076531 infrastructure Switch default compiler on Windows to VS2013 What might be

Re: 9 b58 fails on Win 8 when screen reader running

use javaw instead of java ? Same behavior: splash screen, then back to the prompt. -phil. On 04/21/2015 11:53 AM, Pete Brunet wrote: Starting with b58 with JAWS (screen reader) running on Win 8, when starting SwingSet2 the splash screen appears but the application doesn't start

Re: RfR JDK-8076552 nightly build break fix

approval. I have started a local Win build and will start JPRT builds on Linux, Windows, Solaris, and Mac shortly. Thanks, Pete On 4/8/15 12:51 AM, Pete Brunet wrote: Please review/approve the following patch. http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/ The recent push for JDK

Re: RfR JDK-8076552 nightly build break fix

the patch. Let me know. -phil. On 04/08/2015 10:25 AM, Pete Brunet wrote: Here is an updated patch. http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/ It simply removes the com.sun.java.accessibility.util part of the javadoc generation. How to better deal with the javadoc generation

Re: RfR JDK-8076552 nightly build break fix

/2015 10:51 PM, Pete Brunet wrote: Please review/approve the following patch. http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/ The recent push for JDK-8076182 caused a build break, i.e. a problem for the creation of the Javadoc in the environment used by the nightly build

Re: RfR JDK-8076552 nightly build break fix

that the source should be in jdk/src/share/classes does that change things? -Pete David On 8/04/2015 3:51 PM, Pete Brunet wrote: Please review/approve the following patch. http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/ The recent push for JDK-8076182 caused a build break, i.e. a problem

Re: RfR JDK-8076552 nightly build break fix

? (from where I can pull/clone your fixes)? - Lana On 04/08/2015 11:08 AM, Pete Brunet wrote: I confirmed the javadoc is gone, and make docs did not fail. I have yet to submit the JPRT job. Sean/Winston do you want to wait for the 7 JPRT jobs to finish before you approve the push? Phil

Re: RfR JDK-8076552 nightly build break fix

requests should be carried out on jdk8u-dev mailing list. I did the RfA on jdk8u-dev (but am pending the start/run/success of the 7 JPRT builds). regards, Sean. On 08/04/2015 19:14, Pete Brunet wrote: resending - too many on To:/Cc: On 4/8/15 1:08 PM, Pete Brunet wrote: I confirmed

Re: RfR JDK-8076552 nightly build break fix

on windows build. Mandy On 4/8/2015 10:29 AM, Phil Race wrote: Isn't it sufficient to comment out this one line ? 1215 ALL_OTHER_TARGETS += jaccessdocs .. and add a comment as to why ? -phil. On 04/08/2015 10:25 AM, Pete Brunet wrote: Here is an updated patch. http://cr.openjdk.java.net

MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks 10.9.5

Hi, I need some help so I can build on MacOSX to fix a build break. First since I had Xcode 6.1.1 and configure complained that I didn't have v4 I installed v4.6.3. After installing 4.6.3 and doing sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/ I got past that. Then for some reason my

RfR JDK-8076552 nightly build break fix

Please review/approve the following patch. http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/ The recent push for JDK-8076182 caused a build break, i.e. a problem for the creation of the Javadoc in the environment used by the nightly build. This was because a newly opened package

Re: AWT Dev RfR JDK-8055831 Open Source Java Access Bridge

On 3/24/15 3:23 PM, Pete Brunet wrote: Hi Sergey, That's pretty much the case. I just went through the code and found these differences: - merged in JDK-8055173 (merge jawt.dll into javaaccessbridge.dll) which was recently pushed. That should have been jawtaccessbridge.dll (not jawt.dll

Re: AWT Dev RfR JDK-8055831 Open Source Java Access Bridge

Hi Sergey, Which methods are you referring to? -Pete On 3/25/15 10:16 AM, Sergey Bylokhov wrote: The fix looks fine. But it is interesting, do we have an option to remove all deprecated methods during this opening? or can we do it later? or we cannot? 25.03.15 17:44, Pete Brunet wrote

Re: AWT Dev RfR JDK-8055831 Open Source Java Access Bridge

. Thanks Erik, My build and tests ran OK so apparently they are no longer needed. To all: My hope is to push this patch into 9 tomorrow (Thursday) so please let me know if there are any additional issues as soon as you can. Pete /Erik On 2015-03-24 22:36, Pete Brunet wrote: Here's the latest

Re: AWT Dev RfR JDK-8055831 Open Source Java Access Bridge

think the safe thing to do is undo that change in Copy-java.gmk and leave the closed file in place and discuss off-line with the security team why the files differ .. I'll start a discussion on this. -phil. On 3/25/2015 8:55 AM, Pete Brunet wrote: Hi Sergey, Which methods are you referring

Re: AWT Dev RfR JDK-8055831 Open Source Java Access Bridge

and Monkey test tools which will be the subject of a later patch - removed the DEF files; although they were used in the build, there are no build or runtime problems after their removal On 3/24/15 8:08 AM, Magnus Ihse Bursie wrote: On 2015-03-23 18:31, Pete Brunet wrote: Hi Erik, I tried

Re: AWT Dev RfR JDK-8055831 Open Source Java Access Bridge

correctly that the code itself were not changed except files location? 21.03.15 7:33, Pete Brunet wrote: Please review the following patch which will add the code of the Java Access Bridge (JAB) and related Java Accessibility Utilities to OpenJDK. This code is used by Assistive Technology

Re: RfR JDK-8055831 Open Source Java Access Bridge

-21 05:33, Pete Brunet wrote: Please review the following patch which will add the code of the Java Access Bridge (JAB) and related Java Accessibility Utilities to OpenJDK. This code is used by Assistive Technology such as screen readers and screen magnifiers used by those who are blind or have

RfR JDK-8055831 Open Source Java Access Bridge

Please review the following patch which will add the code of the Java Access Bridge (JAB) and related Java Accessibility Utilities to OpenJDK. This code is used by Assistive Technology such as screen readers and screen magnifiers used by those who are blind or have low vision. AT use the JAB

Re: [8u40]: RFR 8059136: Reverse removal of applet demos

Hi Daniil, I reviewed the two webrevs original change: http://cr.openjdk.java.net/~dtitov/8015376/webrev.00 backout: http://cr.openjdk.java.net/~dtitov/8059136/webrev.00/ and saw no problems with the backout of the original change. Pete On 9/26/14, 3:48 PM, Daniil Titov wrote: Hi, Please

Request for review of make changes for JDK-8041507, Java Access Bridge version strings need to be fixed

Please review the open part of the change for this fix: JDK-8041507 Java Access Bridge version strings need to be fixed https://bugs.openjdk.java.net/browse/JDK-8041507 Change: Some variables needed to be set for use by the RC phase of the build of jabswitch.exe. The closed part of the fix is a

Re: jdk7u full build fails on Win - unable to load zip.dll

-clone/jdk7' make: *** [build_product_image] Error 2 I noticed my 4G was maxed out so I rebooted and that issues was resolved. BTW, I prefer a local build because I have a bunch of them to do and I need to test all of them locally. Pete /Erik On 2014-04-18 23:56, Pete Brunet wrote: p.s

Re: building 7u on macosx

On 4/21/14 9:30 PM, David Holmes wrote: On 19/04/2014 5:25 AM, Pete Brunet wrote: Success. I found this post from Arun Gupta: https://blogs.oracle.com/arungupta/entry/build_open_jdk_7_on which specifies this make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true

building 7u on macosx

Hi, It's been a long time since I built 7 on macosx. Refering to https://wiki.openjdk.java.net/display/MacOSXPort/Main I see these instructions CPATH=/usr/X11/include LANG=C make ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` but that

Re: building 7u on macosx

Maybe 7 is not supported? The reason I am trying to build it is to back port two bugs from 9, but maybe that's not needed. On 4/18/14 11:39 AM, Pete Brunet wrote: Hi, It's been a long time since I built 7 on macosx. Refering to https://wiki.openjdk.java.net/display/MacOSXPort/Main I see

Re: building 7u on macosx

x. Pete On 4/18/14 11:59 AM, Pete Brunet wrote: Maybe 7 is not supported? The reason I am trying to build it is to back port two bugs from 9, but maybe that's not needed. On 4/18/14 11:39 AM, Pete Brunet wrote: Hi, It's been a long time since I built 7 on macosx. Refering to https

Re: building 7u on macosx

this: SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true I didn't yet investigate if there is a subset of the changes that would be successful. Pete On 4/18/14 1:43 PM, Pete Brunet wrote: I see Mac downloads for 7u55 so I should be able to build 7u. But the instructions at https

jdk7u full build fails on Win - unable to load zip.dll

A full 7u build currently fails like this: make[6]: Entering directory `/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7/jdk/make/com/sun/jmx' /usr/bin/mkdir -p C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes/javax/management/remote/rmi rm -f

Re: jdk7u full build fails on Win - unable to load zip.dll

p.s. The ALT_BOOTDIR specifies 6u45. On 4/18/14 4:53 PM, Pete Brunet wrote: A full 7u build currently fails like this: make[6]: Entering directory `/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7/jdk/make/com/sun/jmx' /usr/bin/mkdir -p C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586

Re: copy folders instead of sequential hg clones

reviews, I go to one of shared server, clone fresh workspace, apply patch form webrev to it and submit a commit job. Thanks for that. -Dmitry On 2014-04-12 05:12, Pete Brunet wrote: Hi Jon, I am on VPN from Austin. It has always taken forever. And downloading programs from the internet when

copy folders instead of sequential hg clones

Since it takes forever to clone on my Win machine, in the case where I want to work on several bugs, is it OK to instead clone the first directory and then cp -ar that to n additional directories? -Pete

Re: copy folders instead of sequential hg clones

this long, something must be broken? -- Jon On 04/11/2014 04:26 PM, Pete Brunet wrote: Since it takes forever to clone on my Win machine, in the case where I want to work on several bugs, is it OK to instead clone the first directory and then cp -ar that to n additional directories? -Pete

  1   2   3   >