Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal > - Revise "value-

RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal

Integration of JEP 390, addressing the following issues: 8252180: [JEP 390] Deprecate wrapper class constructors for removal 8254047: [JEP 390] Revise "value-based class" & apply to wrappers 8252181: [JEP 390] Define & apply annotation jdk.internal.ValueBased 8252183: [JEP 390] Add 'lint' warning

Re: RFR: 8234835 Use UTF-8 charset in make support Java code

> On Dec 3, 2019, at 5:24 PM, Jonathan Gibbons > wrote: > > Hi Dan, > > I think it's a combination of oral tradition and long-standing precedent. > > Earlier this year, I raised this general issue, partly because of > inconsistent use of -encoding in the build system. The response was that

Re: RFR: 8234835 Use UTF-8 charset in make support Java code

> For the other files, it seems strange to force the use of a charset > which is different from the charset of record for all our source files > (i.e. US-ASCII). Can you clarify where this "charset of record" rule comes from? Is this written down somewhere, or more of an oral tradition? The

RFR: 8234835 Use UTF-8 charset in make support Java code

Please review this patch to make explicit use of the UTF-8 charset in build tools' IO code. JDK-8065704 changed the platform default to US-ASCII, so the intended effect of this change is to address a regression and restore the typical earlier behavior. My particular interest is in fixuppandoc,

Re: RFR: 8226325: Support building of filtered spec bundles

stand out more. See > make/common/Utils.gmk for examples. > > 691-693: Please indent properly (4 spaces). > > Nice that you found a way to get rid of the SPECS_BOTTOM_FILE_$n files, those > were an annoying construct. Looks good except for the style nits! > > /Eri

RFR: 8226325: Support building of filtered spec bundles

See this webrev for some enhancements to the documentation-building capabilities of the build system. http://cr.openjdk.java.net/~dlsmith/jdk/8226325/webrev.00

Re: Reducing dependencies for docs

> On Dec 12, 2018, at 6:39 AM, Magnus Ihse Bursie > wrote: > > Yes, the requirement for docs-jdk-index is indeed incorrect. Probably some > remnant from when I splitted up the single monolitical "docs" target, that > depended on exploded-image. > > Dan, please try if this patch helps you: >

Re: Reducing dependencies for docs

> On Dec 11, 2018, at 5:28 PM, Erik Joelsson wrote: > >> - Can we similarly eliminate dependencies from 'make docs'? Right now, the >> javadoc invocation requires compiled classes to be available, but I don't >> know if that's necessary. Maybe it will work just as well if it only has >>

Reducing dependencies for docs

Would it be possible to adjust the build system's handling of docs so that it is not necessary to do a complete compilation before the docs can be generated? I'm working with specs, and the following command does mostly what I want: make jdk.jdi-gensrc hotspot-gensrc && make docs-jdk-specs-only

-Wexpansion-to-defined warnings

I'm suddenly getting hundreds of these warnings when I build in macOS: /Users/dan/Dev/jdk/jdk/src/hotspot/share/gc/g1/heapRegionSet.hpp:126:5: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined] #if HEAP_REGION_SET_FORCE_VERIFY ^

Re: Module warnings for jdk.rmic

> On Mar 9, 2017, at 3:48 PM, Mandy Chung wrote: > > Are you using JDK 9 as the boot JDK or doing bootcycle build? I think the former, since I don't know what a bootcycle build is? Steps to reproduce: $ -> cd ~/Dev/jdk/jdk10 $ -> sh configure

Module warnings for jdk.rmic

During a build, many of these warnings get spit out: WARNING: Unknown module: jdk.rmic specified in --patch-module I've been assuming someone would clean this up eventually, but it's been there for months. Don't see a JBS bug. Is this on someone's radar? Or maybe this is somehow a weird quirk

RFR: JDK-8159186: jdk/test/Makefile: allow users to set verbosity

I'd like to make a simple tweak to jdk/test/Makefile in order to support control over the "-v" verbosity option sent to jtreg. 'langtools/test/Makefile' has supported a similar "JTREG_VERBOSE" variable for awhile now. (Would it be nice to align the test-running infrastructure for langtools

Stray output from 'tar' during configure

On OS X 10.11.5, most recent updates installed: Configure dumps this error message to stderr: tar: Must specify one of -c, -r, -t, -u, -x It appears innocent, but adds some noise to the output. —Dan

Re: OS X El Capitan & freetype

d that this 10.11 feature also partially breaks > the > Xserver since files that it needs to place in /System/Fonts are no longer > allowed. > I think a lot of people are going to find they need to disable this feature. > > -phil. > > On 10/1/15, 2:20 PM, Dan Smith w

dist-clean won't delete log files

My understanding is that given a properly configured 'dist-clean' will behave as noted: rm -r build sh configure make dist-clean find build -mindepth 1 # no output However, instead I get 3 files: build/macosx-x86_64-normal-server-release build/macosx-x86_64-normal-server-release/build.log

Re: Status of ccache

On May 25, 2015, at 2:38 AM, Erik Joelsson erik.joels...@oracle.com wrote: On 2015-05-22 17:47, Dan Smith wrote: JDK-8027584 disabled ccache by default, I gather because it doesn't work in Cygwin, and secondarily because of vague general problems with it. The documentation (README

Status of ccache

JDK-8027584 disabled ccache by default, I gather because it doesn't work in Cygwin, and secondarily because of vague general problems with it. The documentation (README-builds.html) still unambiguously endorses it, although doesn't say anything about how to turn it on (configure with

Re: RFR: JDK-8062449 Update langtools/test/Makefile to use JCK 9

While I'm at it, here are some trivial cleanups: - Silence echoing of the error-handling commands (command still runs, but make doesn't print it out) - Allow the 'JCK_VERBOSE' variable to request -v (JCK doesn't support this with an alias like -v:summary) Jon, if you still approve, I'll push

RFR: JDK-8062449 Update langtools/test/Makefile to use JCK 9

Looking for a review of the following small patch to langtools/test/Makefile. The script is hard-coded to use JCK 8 when running JCK tests, causing 19 failures; it should be using JCK 9. I assume there aren't any important processes that depend on this target (e.g., SQE automated runs) or

Re: Yosemite problems with FreeType

solution was to use XQuartz 2.7.5 (instead of 2.7.7), maybe it's worth a try. -Bernhard On Wed, Oct 22, 2014 at 12:46 AM, Dan Smith daniel.sm...@oracle.com mailto:daniel.sm...@oracle.com wrote: Looks like I'm a little bit too close to the bleeding edge, but I wonder if anyone's looking

Yosemite problems with FreeType

Looks like I'm a little bit too close to the bleeding edge, but I wonder if anyone's looking into cleaning up building on OS X Yosemite (10.10). Building jdk9 mostly works fine, but I've had issues with FreeType. Problem #1: make dist-clean sh configure --with-boot-jdk=$JAVA8_HOME ...

Can't build hotspot with Xcode 4

Starting today, if I configure with Xcode 4 on OS X 10.9, I can no longer build jdk9/dev/hotspot (changeset b329ff11a78c). make dist-clean sh configure --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin --with-toolchain-type=gcc --with-boot-jdk=$JAVA8_HOME make images ...

Langtools test makefile enhancement

Hi, I just created an Enhancement, JDK-8042882, requesting some extra control over verbosity in langtools/test/Makefile. I've got a patch that does this that I've been using locally for awhile now. Can I claim the issue and post my patch for review to this list, or is there a different

Re: OS X configure ignores --with-tools-dir

, 2014, at 1:43 PM, Henry Jen henry@oracle.com wrote: For JDK9, try to specify toolchain using --with-toolchain-type=gcc Cheers, Henry On 04/25/2014 10:41 AM, Dan Smith wrote: I'm using --with-tools-dir on OS X Mavericks to point to an old copy of Xcode 4. I configure jdk9 as follows

OS X configure ignores --with-tools-dir

I'm using --with-tools-dir on OS X Mavericks to point to an old copy of Xcode 4. I configure jdk9 as follows: make dist-clean hg update -d 2014-03-17 sh configure --with-boot-jdk=$JAVA8_HOME --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin Running generated-configure.sh

Unexpected Mac X11 dependency

I'm trying to do a vanilla build on Mac OS X Mavericks. (Using an old copy of Xcode 4.) Configure succeeds as follows, while acknowledging that X11 is not found: sh configure --with-boot-jdk=$JAVA7_HOME --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin ... checking what is

README-builds.html feedback

I'm building for the first time under the new infrastructure (late to the party, I know). I appreciate the comprehensive readme page. Here's a list of minor points of feedback: The set of repositories and what they contain: need to add nashorn warn — Default and very quiet: I presume this is

Re: JDK build on Mountain Lion

Thanks. This was useful. Similar experience for me, except 'make sanity' failed immediately because of the X11 freetype dependency. Following these hints, I was able to successfully build jdk8/jdk8 on a fresh Mountain Lion install by doing the following: - Get the Xcode application from the

Re: Improving source drops documentation

'do not edit these files unless you have approved' and hope that people obey that rule. I just haven't had the cycles to deal with this of late. This is a sore point in building that we really need to fix. -kto On Oct 11, 2011, at 2:14 AM, Dan Smith wrote: I build infrequently

Improving source drops documentation

I build infrequently, but when I do, I often get errors due to out-of-date jaxp and jax-ws source bundles. My typical process is something like this: 1) Start to build 2) Observe a failure complaining about an improper $ALT_DROPS_DIR 3) Track down my note where I wrote down the URL where I can