Re: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security

Hi Erik, I spent the last week getting familiar with the new build environment, but then got pulled of into something else. I'm glad I got pulled off, it looks like you were quietly working on many of the same issues I was. I would hate to have duplicated that work. Anyway, I'm close to be

Re: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security

Currently, the only way to get a valid build is to do an images build. Having to do a full image build adds too much time to the think/edit/compile/run environment. The default target build: % make381 will not create a valid JCE environment. The proper JCE signed files and policy files

Re: RFR: JDK-8023075: JDK-5049299 has broken old make in jdk8

Thanks, David. Pushed. You should be able to build the JCE jar files. Brad P.S. Yes, Alan, I am making progress on the JCE build issue. ;) On 8/14/2013 7:11 PM, David Katleman wrote: On 8/14/2013 7:07 PM, Brad Wetmore wrote: Rob, I'm not sure what happened, but I'm gue

RFR: JDK-8023075: JDK-5049299 has broken old make in jdk8

Rob, I'm not sure what happened, but I'm guessing your editor made a couple of glaring mistakes. 1. in the clean clobber target command section instead of 2. No newline at end of file In: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4b0be7341ef % hg diff . diff --git a/make/ja

Re: old build - has a date been set for its removal?

For the JCE builds, I'm hoping to have a look at this soon along with some other back-burnered tasks. Unfortunately, some unexpected family matters cut into my availability the last three weeks. Brad On 6/4/2013 6:22 AM, Erik Joelsson wrote: On 2013-06-04 14:13, Alan Bateman wrote: On 04

Re: RFR: JDK-8011812: JDK-8011278 breaks the old build

Three of your builds (macos_x64/windows_i586/windows_x64) failed (1 failed in install:unix-wrappers and 2 due to missing docs because of c:/ resolution), but there were no problems with building the JDK. Since this is the old build, I think we're ok to putback. Your change looks good to me, I

Re: Allow using a system-installed giflib

On 4/11/2013 3:45 AM, Alan Bateman wrote: Personally I think it would be good to agree and set a date, after which there is no requirement to keep the old build "working". At the moment it is a tax on all changes that involve change changes. I'm not even sure that the old build generates good

Re: RFR: JDK-8011812: JDK-8011278 breaks the old build

$(JVMLIB) $(OBJDIR)/../../jpeg/$(OBJDIRNAME)/jpeg$(SUFFIX).lib endif # PLATFORM On 4/10/2013 11:37 AM, Brad Wetmore wrote: Looks good to me. Can you, or I, push this to TL? We need this for a putback I'm planning in the next day or two. Brad On 4/10/2013 3:07 AM, Erik Joelsson

Re: RFR: JDK-8011812: JDK-8011278 breaks the old build

x and changed to the SHARED_SRC variable used in the old build. /Erik On 2013-04-10 00:01, Brad Wetmore wrote: Mike/Omair/Eric, This putback has likely broken the old JDK build (i.e. in jdk/make) JDK-8011812: JDK-8011278 breaks the old build At least deploy and JCE are still stuck on the old

Re: Allow using a system-installed giflib

On 4/10/2013 1:19 AM, Alan Bateman wrote: On 09/04/2013 23:11, Omair Majid wrote: : I would like to avoid this in the future; any tips on how to run the old build? I couldn't get it to work last I tried (the error messages were redirecting me to the new build). I see Brad's reply but I think

Re: Allow using a system-installed giflib

ime. HTH, Brad On 4/9/2013 3:11 PM, Omair Majid wrote: On 04/09/2013 06:01 PM, Brad Wetmore wrote: Mike/Omair/Eric, This putback has likely broken the old JDK build (i.e. in jdk/make) JDK-8011812: JDK-8011278 breaks the old build Sorry for this. At least deploy and JCE are still st

Re: Allow using a system-installed giflib

Mike/Omair/Eric, This putback has likely broken the old JDK build (i.e. in jdk/make) JDK-8011812: JDK-8011278 breaks the old build At least deploy and JCE are still stuck on the old build. One workaround that is said to work: diff --git a/make/sun/splashscreen/Makefile b/make/sun/splashs

Re: RFR : 80111342 : hgforest.sh : 'python --version' not supported on older python

Approved, thanks Mike! Brad On 4/2/2013 3:00 PM, Mike Duigou wrote: Hello all; Brad Wetmore noticed that yesterday's fix for 8011178 did not work on older versions of python which lack support for the --version long option. Enclosed is a patch which uses the more widely supported -V o

Re: RFR 8009517: Disable fatal compiler warning in the old build

On 3/22/2013 1:34 AM, Alan Bateman wrote: On 21/03/2013 22:12, Brad Wetmore wrote: : The codereview is here: http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/ I plan to push through the deploy gate, as they have an integration next week. Thomas Ng will do the push for us. Any

Re: RFR 8009517: Disable fatal compiler warning in the old build

h through the deploy gate, as they have an integration next week. Thomas Ng will do the push for us. Any objections, please speak now. Brad On 3/18/2013 6:29 PM, Brad Wetmore wrote: Sorry for the delay in response, I've been pulled in yet another direction, and this has come back up in

Re: Does README-builds.html need to mention Nashorn?

I noticed the same and filed JDK-8010258 yesterday. Tim Bell thinks it's probably just an oversight. Brad On 3/19/2013 8:57 AM, David Chase wrote: I was just browsing through, to be sure I was going to set the knobs right for some performance testing, and noticed no mention of the reposito

Re: RFR 8009517: Disable fatal compiler warning in the old build

Sorry for the delay in response, I've been pulled in yet another direction, and this has come back up in priority. On 3/9/2013 12:11 AM, Chris Hegarty wrote: I agree about warning creeping problems. This is a temporary solution, we should soon be fixing the underlying hashcode/equals problems.

Re: Allow configure to detect if EC implementation is present

CC'ing security-dev. Vinnie, As owner of ECC, you should probably look at this. Brad On 3/13/2013 7:02 PM, David Holmes wrote: On 14/03/2013 6:09 AM, Omair Majid wrote: Hi, jdk/makefiles/CompileNativeLibraries.gmk has a little note: TODO Set DISABLE_INTREE_EC in configure if src/share/nat

Re: RFR 8009517: Disable fatal compiler warning in the old build

I responded in another thread (wasn't aware of this one, sorry), there is an alternate to completely disabling -Werror. On 3/8/2013 7:58 AM, Chris Hegarty wrote: On 08/03/2013 15:49, Mike Duigou wrote: Looks fine to me. Thanks Mike. > Do we have an issue open for restoring warnings to th

Re: code review request: 8009604, old make images failed: JarBASE64Encoder class not found

Looks good. brad On 3/6/2013 6:33 PM, Weijun Wang wrote: Please review the fix at http://cr.openjdk.java.net/~weijun/8009604/webrev.00/ The class was defined in jarsigner/Main.java and was removed in JDK-8006182, but it's still mentioned in jdk/make/common/Releases.gmk. Noreg-build. Tha

Recent Minor Change to Makefiles.

I just made a minor change to the JCE makefiles. I forgot to have it reviewed by you, sorry! Fortunately the changes are very minor. http://hg.openjdk.java.net/jdk8/tl/jdk/rev/940c8cc5a5c4 1. I'm adding the missing Manifest file to several of the JCE jar files. 2. Changing the string sto

Re: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy

It's now marked as resolved. Thanks, Brad On 9/27/2012 9:58 AM, Andrew Hughes wrote: - Original Message - - Original Message - Will you be putting this back yourself? If so let me know when you go in, and I can update the bug once you're in. I will, though I'll need

Re: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy

On 9/27/2012 9:50 AM, Andrew Hughes wrote: - Original Message - Will you be putting this back yourself? If so let me know when you go in, and I can update the bug once you're in. I will, though I'll need a bug ID for it. I presume tl is ok as the forest to use? This going into

Re: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy

Will you be putting this back yourself? If so let me know when you go in, and I can update the bug once you're in. I will, though I'll need a bug ID for it. I presume tl is ok as the forest to use? This going into 8? Then yes. 7201205: Add Makefile configuration option to build with unl

Re: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy

On 9/18/2012 7:39 AM, Andrew Hughes wrote: The following simple webrev will achieve what I think is needed: http://cr.openjdk.java.net/~andrew/100062/webrev.01/ allowing OpenJDK to be built with the unlimited rather than limited crypto policy in place. I got a chance to talk to Valerie, and

Re: [PATCH FOR REVIEW] Allow OpenJDK to be built with the unlimited crypto policy

> But I think someone from the security team should chime in on this. I plan to look closer at this. On the surface, it looks acceptable to me, but I've been heads down in the SNI code: likely for one more day. Wanted to also run this by one of my other colleagues. One thought: I'm wonderin

Re: Commit responsibilities and Lines of Defense

Definitely. Making OpenJDK bug DB IDs usable in changesets would be a good start (probably involves jcheck...) I'll have to punt on that, someone else is working on it, but the intent is to have a completely open bug tracking system that also allows us link it with the internal Oracle bug tra

Re: Need reviewer: Add vsvars.sh script to jdk7 repo

10 10:33 PM, Kelly O'Hair wrote: On Dec 29, 2010, at 8:44 PM, Brad Wetmore wrote: Regarding the script you added to the repository: What expectations does this script have in terms of the environment already being setup? For example, can I just install VS2010/cygwin, then run this scrip

Re: Need reviewer: Add vsvars.sh script to jdk7 repo

Regarding the script you added to the repository: What expectations does this script have in terms of the environment already being setup? For example, can I just install VS2010/cygwin, then run this script, or do I need to set my path to something before I run this? Here's what I hoped I'd

Re: Need reviewer: GNU make 3.81

Looks ok to me. Brad On 12/18/2010 11:59 AM, Kelly O'Hair wrote: Need reviewer. This just causes a sanity warning message at build time when anything older than GNU make 3.81 is used. We have run into multiple issues where the use of the older GNU make versions have caused problems and there

Re: Preliminary work on jdk build time improvements

This is a great optimization. A couple comments. Platform.gmk: Haven't quite figured out why if MAKELEVEL=0 you export $1:=$2, but only export $1 if MAKELEVEL != 0. Sure there's a good reason why, doc'ing it would be appreciated. 48/49: (if $(strip $1)... according to the gnumake docs:

Re: Should GNU make 3.81 be required?

I only mentioned the sum because the one Kelly was suggesting was probably the same one I got from cmake. I wasn't suggesting that you should be testing for that particular version. I would hope you can just create a simple check to see if the drive letter logic is on, possibly using cygpath.

Re: Should GNU make 3.81 be required?

Tim wrote: > Excellent! We may be in better shape than I thought, unless there > are other make.exe downloads that report 3.81 yet are broken for > our purposes - that would be confusing. A quick reminder, the gnumake 3.81 as part of a normal cygwin install does *NOT* support the drive letter

Re: Should GNU make 3.81 be required?

So do I continue on, and assume a new requirement to upgrade to GNU make 3.81 because of these changes (on all platforms), or do I go back to the drawing board and try and make the changes work with 3.80, or even 3.78.1 ??? If we can find a Windows/Cygwin GNU make v3.81 or better that works, I

Re: package org.omg.CORBA_2_3.portable does not exist

Just as an update for the OpenJDK alias. Since this caused us to miss Friday's TL/JSN/langtools integration, we've been discussing this amongst the gatekeepers and javac teams in order to assess the cause/impact. We now have a pretty good guess what's going on. In b31, we fixed: 6725036: jav

Re: package org.omg.CORBA_2_3.portable does not exist

nRolledbackException.class < org/omg/DynamicAny/DynValueBox.class < org/omg/DynamicAny/DynValueBoxOperations.class < org/omg/SendingContext/ < org/omg/SendingContext/RunTime.class < org/omg/SendingContext/RunTimeOperations.class Max (Weijun) Wang wrote: I pull from JSN (not JSN gate

Re: package org.omg.CORBA_2_3.portable does not exist

Max, are you pulling from the current JSN gate or something else? I had no problems with last night's nightlies. If you're pulling from the master, I expect Tim will integrate tonight and sync TL with the latest MASTER. I'll pull them down into JSN at midnight and should have results the nex

Re: Can somebody sanity-check me here?

I didn't notice the appropriate developer's guide section mentioned in the followups. http://openjdk.java.net/guide/repositories.html#term Brad Kelly O'Hair wrote: For your build changes work, the forest clone of interest is hg fclone http://hg.openjdk.java.net/jdk7/build which will

Re: Building on ubuntu 8.04

I think you've got a problem still with your sh setup, or possibly something else. IIRC, the ?replType? variables is supposed to be replaced with various values depending on whether you have an encoder or decoder. (sed/awk preprocessing = a Javaman's #ifdef equivalent) It's done a similar wa

Re: JDK libraries build question: propagating a new make variable/value

Many of the common variables used throughout JDK are defined in the common and shared Makefiles, and then included in the various leaf and middle makefiles. I'd start by looking at those first. Another tip, many of the common Makefiles include other common Makefiles, so if one you need isn'

Re: What am I doing wrong here?

> But Brad's comment seemed to imply that everything that wasn't a > "developer" workspace was in jdk7, and I was trying to confirm that > this wasn't the case. Ted, I'm sorry my posting wasn't as helpful as I hoped. David wrote: > Or maybe that the listing on http://hg.openjdk.java.net/ doesn'

Re: What am I doing wrong here?

Ted, Since you're talking about the build workspaces, this may not be immediately obvious, but the MASTER workspaces: http://hg.openjdk.java.net/jdk7/jdk7 will generally be more stable than the individual project repositories (build/TL/JSN/etc.) Developers put back directly into the pro

Re: New question: new build?

It depends on who you ask (and when). Folks like myself are focused primarily on JDK7, folks like Joe Darcy are mainly on JDK6, and folks like Kelly are a mix. Brad Ted Neward wrote: This isn't a criticism aimed at you, Kelly, but that last statement sounds pretty ominous--is there any forw

Re: undefined reference error during the build of openjdk

Feng Xian wrote: I downloaded from http://download.java.net/jdk7/ On 1/29/08, *Kelly O'Hair* <[EMAIL PROTECTED] > wrote: This looks like JRL sources not "open source" files. Where did you get these source files from? As Kelly surmised, what you have is not

Re: JDK 7 build 24 is available at the openjdk.java.net website

Climbing back up on the dead horse: (that is: I am now back from vacation) >> The key is in getting the Mercurial with the forest extension >> installed--I >> had 0.9.5, which didn't, and I couldn't figure out where to get it or >> how to >> install it; I simply got the 0.9.4 version from:

Re: kdiff3 arguments order

Yuri Nesterenko wrote: Colleagues, moderately useful dry-run finding: using kdiff3 as a merge tool for mercurial, you better wrap it in the script like this ("merge = ~/bin/kdiff3.sh" in my .hgrc): #!/bin/bash /opt/kde3/bin/kdiff3 -o $1 $2 $1 $3 I like kdiff3 too, but doesn't work under de

Re: OpenJDK Mercurial Transition Update 7

Ted, All the changes you've been seeing are us Sun employees trying out the new mercurial environment on temporary, throw-away repositories, but these gates are pretty much what will go live very soon now. Everything we've been changing will be trashed at the end of this test period, and the

Sparse repositories and fclone/fpull

One of the Mercurial assumptions a few of us (Tim/Kelly/I) have been working under is that we can use "partial trees" for our builds/tests. For example, for my gatekeeping, I want to build most things, but not hotspot and some of the closed repositories (install). So I fclone'd openjdk, then d

webrevs of forests with arbitrary "parents"

Hi Jessie, It's possible this has been rehashed before, I've read so much email over the last week...My brain is full, can I go home now? In my role as gatekeeper, I create build/test/integration dirs using the following layout: jsn tl \/ \ / \/