Re: strange build error

environment is clean, e.g. that there are no classes belonging to a previous build? Maurizio Maurizio Cimadamore wrote: Hi Roman, just to ask, if you go in the langtools repository and type hg tip what's the output? Just to make sure that you have the latest langtools available Maurizio Roman

Re: JDK8 Preliminary Repository Layout

On 10/03/11 09:49, Johan Walles wrote: The problem for many developers with the all-in-one repository solution is the time it takes to clone everything (5-6 minutes). I think another problem with the all-in-one repository solution is that it increases chances for conflicting changes (i.e. when

Re: Build succeeds even if JDK source file fails to compile

On 16-Dec-11 11:25 PM, Chris Hegarty wrote: On 16 Dec 2011, at 20:56, Kelly O'Hairkelly.oh...@oracle.com wrote: Change looks good. +1 Thumbs up! Maurizio -Chris -kto On Dec 16, 2011, at 11:58 AM, Stuart Marks wrote: Here's a fix I'm working on. I'm still doing test builds but I

Re: Need help in building openjdk in ubuntu 11.10

Attached is the script I use to build JDK on Ubuntu 11.10 (x64). Works for me. You will have to update the paths to the JDK accordingly. Maurizio On 22/12/11 02:35, Charles Lee wrote: On 12/22/2011 10:11 AM, m silverstri wrote: I did. $ echo $ALT_BOOTDIR /home/michael/Programs/jdk1.6.0_30

Re: What is the xawt sizer wrapper, really?

On 14/06/12 13:14, David Holmes wrote: On 14/06/2012 10:10 PM, Magnus Ihse Bursie wrote: On 2012-06-14 13:52, David Holmes wrote: As I understand this, sizers is to X11 Java code what the UnixConstants program is to the filesystem code. It has to determine various sizes of native data

build failure in nashorn with sjavac enabled

Hi, I was doing experiments with the recently added sjavac flag to enable smart recompilation of JDK classes. I got a failure in Nashorn (I'm building on linux x64, Ubuntu 11.10): ## Starting nashorn Compiling BUILD_NASHORN Compiling 106 files in 7 packages (jdk.internal.dynalink to

Re: make clean images fails on windows 8

On 09/05/13 19:15, Boaz Nahum wrote: e:\dev\jdkbuild\ll5\hotspot\src\share\vm\classfile\defaultmethods.cpp(1082) : error C4716: 'ShadowChecker::path_has_shadow' : must return a value Compiling... verificationType.cpp verifier.cpp Known issue or I'm doing wrong ? Thanks Boaz Yep we know about

Re: Disable overrides during jdk build

I think it makes sense, esp. if the messages appear to be redundant. The compiler logic is very strict and there are cases where it comes down to guessing user intent and compilers are notoriously bad at doing that. In the long term, I'd like to see @SuppressWarnings(overrides) applied in

new build system configure step - a small suggestion

Hi, as I recently went through the process of reinstalling my OS, I had to get the JDK build up and running again (with Ubuntu). As expected, configure kept failing because of missing libraries; I counted 4 failures: *) build-essential missing (gcc, etc.) *) X headers missing *) cups headers

Re: new build system configure step - a small suggestion

to track the suggestion. /Erik On 2013-05-28 13:36, Maurizio Cimadamore wrote: Hi, as I recently went through the process of reinstalling my OS, I had to get the JDK build up and running again (with Ubuntu). As expected, configure kept failing because of missing libraries; I counted 4 failures

hg: jdk8/build/langtools: 8013638: Few policy tests are failing in Lambda nightly

Changeset: 6d85acab769e Author:mcimadamore Date: 2013-07-17 19:28 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/6d85acab769e 8013638: Few policy tests are failing in Lambda nightly Summary: BridgeHarness test is leaving files open Reviewed-by: ksrini !

running compiler JCK tests from toplevel makefile

Hi, I've spent some time investigating why jck compiler tests could not be launched from toplevel make - i.e. using make test TEST=langtools_jck-compiler Turns out that langtools makefile expects certain variables, while the build provide others, and those are not correctly wired up. On top

Re: running compiler JCK tests from toplevel makefile

to suggestions here - actually it's a pretty good idea. Ok - I will file an issue to keep track of this one and submit a review later on. Thanks for the comments Maurizio Mike On Jun 5 2014, at 10:37 , Maurizio Cimadamore maurizio.cimadam...@oracle.com wrote: Hi, I've spent some time

Re: RFR [9] Modular Source Code

I'm looking at the langtools-related changes in build.xml; I what is the degree of support available in the build.xml ant file for the Jigsaw world? It seems to me that not all the target would function and it also seems that some of the properties previously encoded in a side property file

Re: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version

Lahoda wrote: Ah, yes, I did not realize that. Thanks, will fix. Thanks, Jan On 27.5.2015 11:59, Maurizio Cimadamore wrote: Looks great. The only nitpick is that the comments in CreateSymbols don't mention the fact that a side effect of the sym.txt generation is the platform-description-file

Re: question on checking dependencies across modules

On 10/06/15 16:30, Erik Joelsson wrote: On 2015-06-10 15:25, Maurizio Cimadamore wrote: Hi, In the context of the IntelliJ project support for JDK, I have a question on the very last step of 'make images' : ## Starting verify-modules Checking dependencies across JDK modules Access

Re: question on checking dependencies across modules

On 10/06/15 17:27, Mandy Chung wrote: On Jun 10, 2015, at 6:25 AM, Maurizio Cimadamore maurizio.cimadam...@oracle.com wrote: Hi, In the context of the IntelliJ project support for JDK, I have a question on the very last step of 'make images' : ## Starting verify-modules Checking

Re: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version

: On 22.5.2015 14:52, Maurizio Cimadamore wrote: Excellent work. I think the comment in CreateSymbols could be made clearer w.r.t. Probe - i.e. that Probe should be ran on top of the JDK N - i.e. JDK-8/bin/java Probe -- classes-8 JDK-7/bin/java Probe -- classes-7 JDK-6/bin/java Probe -- classes-7 etc. Sure

Re: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version

On 21/05/15 12:48, Jan Lahoda wrote: As an example, consider we would be currently storing data for 6, 7 and 8. We could have full 8 APIs stored, and then 8-7 diff and 7-6 diff. So the baseline for 7 would be 8 and the baseline for 6 would be 7. When the data for 9 would be added(*), we

Re: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version

Hi Jan, great work - couple of comments below: * it seems like some of the routines in Arguments can be simplified using lambdas - especially lookupPlatformProvider and checkOptionAllowed * Why JDKPlatformProvider is not called JDKPlatformProvider*Factory* ? *

Re: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version

comment -other cleanup in langtools per Maurizio's comments. Thanks, Jan On 21.5.2015 12:31, Maurizio Cimadamore wrote: Hi Jan, great work - couple of comments below: * it seems like some of the routines in Arguments can be simplified using lambdas - especially lookupPlatformProvider

Re: Fwd: cygwin too old ?

now. Maurizio On 14/08/15 13:27, Boaz Nahum wrote: YES !!! On Fri, Aug 14, 2015 at 3:08 PM Maurizio Cimadamore maurizio.cimadam...@oracle.com mailto:maurizio.cimadam...@oracle.com wrote: Is this only an error with Windows build? Maurizio On 14/08/15 12:43, Boaz Nahum wrote

Re: Fwd: cygwin too old ?

, str_to_find)) != NULL; It was fixed on jdk9dev Can I asked for this sync too ? Boaz On Fri, Aug 14, 2015 at 1:53 PM Boaz Nahum boazna...@gmail.com wrote: Yes, it works. Thx Boaz On Fri, Aug 14, 2015 at 1:19 PM Maurizio Cimadamore maurizio.cimadam...@oracle.com wrote: I've pushed a temp

Re: Fwd: cygwin too old ?

I've pushed a temp workaround for this; let me know if it works for you. Maurizio On 14/08/15 11:07, Boaz Nahum wrote: Many thanks Whom should I asked to do this sync? Boaz On Fri, Aug 14, 2015 at 12:12 PM Ingemar Åberg ingemar.ab...@oracle.com wrote: Hi Boaz, Your problem looks like

Re: RFR(XS): 8141416: "expr: syntax error" due to gcc -dumpversion excluding micro

On 09/11/15 13:54, Maurizio Cimadamore wrote: Hi, I still see this on my Ubuntu 14.04 (x64) on a fresh jdk 9 repo. Was the fix pushed? Nvm - it has been pushed to the hs-comp repo - it will take few days to get to jdk9/dev (which is what I'm using). Thanks Maurizio Thanks Maurizio On 06

Re: RFR(XS): 8141416: "expr: syntax error" due to gcc -dumpversion excluding micro

Hi, I still see this on my Ubuntu 14.04 (x64) on a fresh jdk 9 repo. Was the fix pushed? Thanks Maurizio On 06/11/15 06:27, Christian Thalinger wrote: On Nov 4, 2015, at 8:21 AM, Volker Simonis wrote: Hi, can somebody please review and sponsor the following tiny

jdk.scripting.nashorn

Hi, in the context of the IntelliJ project I am mantaining, do you know why jdk.scripting.nashorn doesn't seem to be listed in the make variable $(ALL_JAVA_MODULES) ? A small grep is giving me this: make/CompileJavaModules.gmk:ALL_JAVA_MODULES := $(filter-out jdk.scripting.nashorn, $(call

CCACHE build error

Hi, I'm getting a build failure containing the following error (there are more - but all similar to this): /w/lt/9/dev/common/bin/logger.sh: line 44: CCACHE_COMPRESS=1: command not found I have --enable-ccache in my configure - if I disable it, everything is fine; started to happen very

Re: CCACHE build error

-8135014 and will post a fix shortly. /Magnus /Erik On 2015-09-03 12:20, Maurizio Cimadamore wrote: Hi, I'm getting a build failure containing the following error (there are more - but all similar to this): /w/lt/9/dev/common/bin/logger.sh: line 44: CCACHE_COMPRESS=1: command not found

Re: build concurrency

As I said, building/compiling is not the issue - but when running CPU intensive tests you are bound to see spurious failures (I see at least 2 regular ones in langtools tests). Maurizio On 14/09/15 12:06, Andrew Haley wrote: On 09/14/2015 12:03 PM, Maurizio Cimadamore wrote: why the default

build concurrency

Hi, I realized that the concurrency factor inferred by the JDK build might be too high; on a 16 core machine, concurrency is set to 14 - which then leads to absurd load averages (50-ish) when building/running tests. High load when building is not a big issue, but when running test this almost

Re: build concurrency

The information I posted was slightly incorrect, sorry - my machine has 8 cores (and 16 virtual processors) - so you see why choosing concurrency factor of 14 is particularly bad in this setup. Maurizio On 14/09/15 12:03, Maurizio Cimadamore wrote: Hi, I realized that the concurrency factor

Re: build concurrency

. The current implemenation uses 100% of number of virtual cpus when 1 to 4 of them, then 90% at 5 to 16. After that it caps out at 16. (I might remember some detail wrong here) /Erik On 2015-09-14 04:10, Maurizio Cimadamore wrote: The information I posted was slightly incorrect, sorry - my machine has

Re: Building Valhalla

I believe this has been caused by the latest push... try doing: make jimages afaik that should not run the last verification step ;-) Maurizio On 02/10/15 20:59, Mani Sarkar wrote: Hi guys, I get the below build error half way through build the valhalla build of OpenJDK: *ERROR:

Re: Fail to build on windows 'g1ParScanThreadState.cpp'

Hi Boaz, this: http://mail.openjdk.java.net/pipermail/build-dev/2015-April/014773.html and this: http://mail.openjdk.java.net/pipermail/build-dev/2015-August/015418.html Seem related - you might find some solutions there to either workaround the issue, or to disable warnings as errors for

Re: Build failure on windows 'freetypeScaler.c'

Fix pushed Maurizio On 18/12/15 13:16, Boaz Nahum wrote: Hi Lately, I have this error: f:/Dev/JDKBuild/valhalla/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(106) : error C2220: warning treated as error - no 'object' file generated

Re: Fail to build on windows 'g1ParScanThreadState.cpp'

On 30/11/15 07:59, Volker Simonis wrote: If it's not there, you should just sync valhalla with the latest jdk9 or use VS2013 or newer. Valhalla has been synced last week to jdk9 b93, so it should be fairly recent. But it seems like this particular fix is very recent and hasn't made it to

Re: Fail to build on windows 'g1ParScanThreadState.cpp'

I've pushed the fix indicated by Volker (thanks!). Let me know if you see some improvements. Maurizio On 30/11/15 10:43, Maurizio Cimadamore wrote: On 30/11/15 07:59, Volker Simonis wrote: If it's not there, you should just sync valhalla with the latest jdk9 or use VS2013 or newer

Re: RFR (L) JEP 280: Indify String Concatenation (integration)

Langtools changes look fine to me (as discussed on previous review thread). Thanks! Maurizio On 27/01/16 13:55, Aleksey Shipilev wrote: Hi again, This is a formal pre-integration review thread for JEP 280 ("Indify String Concatenation") integration: http://openjdk.java.net/jeps/280 The

question on jigsaw build

Hi, the current build system in JDK 9 has a way to recover all the source dirs for a given module, by doing something like this: $(call ALL_SRC_DIRS,$(mod)) That is, the build system exports a function that can be passed a module name and will return all the source roots for the module with

Re: RFR: JDK-8152666: The new Hotspot Build System

On 06/04/16 10:14, Erik Joelsson wrote: Hello, I assume the mx projects are for Java code or do they also generate projects for native? The new top level target is only meant to replace the old Visual Studio project generator, at least for now. +1 for having the build system a more central

build and ccache

Hi, I seem to be running into ccache issues very frequently lately; basically, every time I do a reconfigure (because the build tells me to do so after a repo refresh), I'm typically not able to build after make clean make images The build will typically fail somewhere when linking the VM -

Re: build and ccache

heh - in my case disabling ccache means jumping from building JDK in 2:30 minutes to building it in 6 mins, so it is noticeable :-) Maurizio On 19/04/16 11:42, Mario Torre wrote: 2016-04-18 19:10 GMT+02:00 Maurizio Cimadamore <maurizio.cimadam...@oracle.com>: Hi, I seem to be r

Re: build and ccache

gcc 4.9.2 /Erik On 2016-04-18 19:10, Maurizio Cimadamore wrote: Hi, I seem to be running into ccache issues very frequently lately; basically, every time I do a reconfigure (because the build tells me to do so after a repo refresh), I'm typically not able to build after make clean make images

strange error when running jtreg tests

Hi, I've encountered this error when running jtreg tests from make using the following command line make test JT_HOME= TEST=jdk_util * For target support_test_hotspot_jtreg_native_support_exeinvoke_BUILD_TEST_invoke_link:

Re: strange error when running jtreg tests

On 12/08/16 14:12, David Holmes wrote: On 12/08/2016 11:06 PM, Maurizio Cimadamore wrote: Hi, I've encountered this error when running jtreg tests from make using the following command line make test JT_HOME= TEST=jdk_util * For target

Re: strange error when running jtreg tests

Yes - other colleagues seeing this too Maurizio On 13/08/16 00:56, David Holmes wrote: Did you do a clean first? I've not seen nor heard of this before.

Re: strange error when running jtreg tests

Using Ubuntu 14.04 on x64. Maurizio On 15/08/16 23:41, Gustavo Romero wrote: Hi, I observed the same issue on Ubuntu 16.04 but not on RHEL 7.2. RHEL 7.2: https://paste.fedoraproject.org/409005/raw/ Ubuntu 16.04: https://paste.fedoraproject.org/409004/raw/ I checked on PPC64 LE arch

Re: strange error when running jtreg tests

ts affiliates. All rights reserved. Use is subject to license terms. JCov 2.0-b18 beta TestNG: version 6.9.5 Maurizio On 16/08/16 11:39, Maurizio Cimadamore wrote: Using Ubuntu 14.04 on x64. Maurizio On 15/08/16 23:41, Gustavo Romero wrote: Hi, I observed the same issue on

Re: strange error when running jtreg tests

running jtreg manually (which is what I'm doing). But the question is: is this a bug? Maurizio On 16/08/16 11:39, Maurizio Cimadamore wrote: Using Ubuntu 14.04 on x64. Maurizio On 15/08/16 23:41, Gustavo Romero wrote: Hi, I observed the same issue on Ubuntu 16.04 but not

Re: Query on developing OpenJDK with IntelliJ

I confirm that the use case you bring up is addressed with the available IntelliJ project configuration. I've tried creating a project for the modules java.base and jdk.jshell, and then opened the class jdk.jshell.TaskFactory, which mention the Version class, which is new in JDK 9. No red

Re: error when running jtreg tests

ed build-test-failure-handler and build-test-lib. Not sure. No luck - that fails with this: Error: Cannot find observer class: jdk.test.failurehandler.jtreg.GatherDiagnosticInfoObserver Maurizio /Erik On 2016-12-13 15:43, Maurizio Cimadamore wrote: Hi, i'm trying to run tests as follow

error when running jtreg tests

Hi, i'm trying to run tests as follows: make tests TEST=jdk_util And I get this: Building target 'test' in configuration 'linux-x86_64-normal-server-release' Building JVM variant 'server' with features 'all-gcs cds compiler1 compiler2 fprof jni-check jvmci jvmti management nmt services

Re: error when running jtreg tests

tend to sneak in. /Erik On 2016-12-13 16:56, Maurizio Cimadamore wrote: I think the problem is caused by a quirk in my gcc - if I compile something with gcc -ldl foo.cpp it fails with messages similar to the one I mentioned. To make it work I have to do: gcc foo.cpp -ldl On the other hand

hotspot atom editor integration

Hi, over the last few days I've been looking at integrating hotspot with the Atom editor [1]. I managed to do it successfully and I can now debug hotspot from Atom and even enable code completion (requires clang plugin [2]). Regarding code completion, to make it work, you have to come up with

Re: Maximum number of warnings allowed?

Hi David, -Xmaxwarns controls how many warnings can be emitted - the default is 100, which means after 100 warnings the warning output will be omitted. There are similar options to limit errors and notes. That said, changing these limits does not affect the 'treat the warning as errors'

Re: running tests from make causes spurious repo changes

On 25/09/17 20:58, Alan Bateman wrote: On 25/09/2017 20:11, Jonathan Gibbons wrote: Erik, It could be a feature of the build (i.e. test makefiles) to verify that no source-controlled files were modified in the course of a test run. Something fishy in this thread as these tests have

Re: permission issues when running make

Thanks Magnus, your explanation makes sense - in the past such issues would have been caught by the spec.gmk check; that explains why I've been able to fix the issue by re-running configure. Maurizio On 02/10/17 14:45, Magnus Ihse Bursie wrote: On 2017-09-27 12:45, Maurizio Cimadamore

Re: RFR: JDK-8188090 Running tests from make causes spurious mercurial changes

this when not needed. Isn't that too fragile? What if I'm running jdk tests but my repo is nested inside some other repo? Maurizio /Erik On 2017-09-28 10:49, Maurizio Cimadamore wrote: Hi, this fixes the problem of the build changing permissions on some library files when executing t

Re: RFR: JDK-8188090 Running tests from make causes spurious mercurial changes

ROOT So, it seems like we should cover all cases with the test above (albeit still a bit uncomfortable with the idea that this patch would potentially peek outside the repo). Maurizio On 28/09/17 10:27, Maurizio Cimadamore wrote: On 28/09/17 10:25, Erik Joelsson wrote: I think you need to al

Re: RFR: JDK-8188090 Running tests from make causes spurious mercurial changes

tests so I'm fine with this being a bit crude. /Erik On 2017-09-28 11:49, Maurizio Cimadamore wrote: This is a modified patch that takes into account hotspot tests: diff -r 355349babaf4 test/TestCommon.gmk --- a/test/TestCommon.gmk    Wed Sep 27 16:47:07 2017 -0700 +++ b/test/TestCommon.gmk

Re: running tests from make causes spurious repo changes

On 26/09/17 07:13, Alan Bateman wrote: On 25/09/2017 21:35, Maurizio Cimadamore wrote: On 25/09/17 20:58, Alan Bateman wrote: On 25/09/2017 20:11, Jonathan Gibbons wrote: Erik, It could be a feature of the build (i.e. test makefiles) to verify that no source-controlled files were

running tests from make causes spurious repo changes

Hi, if I try to run tests from make, after the test run an 'hg status' reveal the following 'changes': M test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/linux-i586/libLauncher.so M

Re: running tests from make causes spurious repo changes

On 25/09/17 12:53, Erik Joelsson wrote: I couldn't agree with you more, but AFAIK, this behavior is in the tests themselves and not something the build is doing. I see - for the records, I got this when running the test group jdk_lang Maurizio /Erik On 2017-09-25 13:33, Maurizio

RFR: JDK-8188090 Running tests from make causes spurious mercurial changes

Hi, this fixes the problem of the build changing permissions on some library files when executing tests [1, 2]. The issue is that a relative path in TestCommon is bogus - jdk tests are now executed in the folder test/jdk, so there's no longer hg repo under ../ Patch inline below: diff -r

Re: hotspot atom editor integration

to remove references to 'atom' in the targets and script - but I think something like this could be very useful for integration of hotspot with IDE (I think Netbeans and Eclipse CDT need something very similar to get started). Maurizio /Erik On 2017-08-11 15:37, Maurizio Cimadamore wrote

Re: running tests from make causes spurious repo changes

is up. More specifically, this test: if [ ! -d $(TEST_ROOT)/../.hg ] ; then   \ was probably failing before, causing the permission changing branch not to be taken? Maurizio On 26/09/17 12:10, Maurizio Cimadamore wrote: On 26/09/17 07:13, Alan Bateman wrote

permission issues when running make

Hi, I sometimes encounter this (consolidated repo only): $ make /usr/bin/tee: /bin/mkdir: /build.logcannot create directory ‘/make-support’: Permission denied: Permission denied /usr/bin/tee: /build.log: Permission denied Building target 'default (exploded-image)' in configuration

Re: permission issues when running make

On 27/09/17 10:51, David Holmes wrote: On 27/09/2017 7:46 PM, Maurizio Cimadamore wrote: Hi, I sometimes encounter this (consolidated repo only): $ make /usr/bin/tee: /bin/mkdir: /build.logcannot create directory ‘/make-support’: Permission denied: Permission denied /usr/bin/tee

Re: permission issues when running make

-support Seems like BUILD_OUTPUT was renamed into OUTPUTDIR ? Still, not 100% what's up. Maurizio On 27/09/17 11:24, David Holmes wrote: On 27/09/2017 8:19 PM, Maurizio Cimadamore wrote: On 27/09/17 10:51, David Holmes wrote: On 27/09/2017 7:46 PM, Maurizio Cimadamore wrote: Hi, I sometimes

Re: on jdk.internal.vm.ci

by a call to FindModuleSrcDirs, (e.g. MODULE_SRC_DIRS is not set correctly for these) and I think they should. Maurizio On 27/11/17 19:14, Maurizio Cimadamore wrote: Hi, the IntelliJ support for JDK relies on make to give the set of source roots used for any given modules. I have noticed

on jdk.internal.vm.ci

Hi, the IntelliJ support for JDK relies on make to give the set of source roots used for any given modules. I have noticed that the set of source roots associated with 'jdk.internal.vm.ci' is incorrect, as it points to src/jdk.internal.vm.ci/share/classes while in reality it should point to

Re: on jdk.internal.vm.ci

Done https://bugs.openjdk.java.net/browse/JDK-8192158 Cheers Maurizio On 28/11/17 17:30, Erik Joelsson wrote: These modules are certainly an annoyance in the build. Please file a bug with this concern. /Erik On 2017-11-28 03:16, Maurizio Cimadamore wrote: Some more specifics

Re: RFR: 8201274: Launch Single-File Source-Code Programs

Thumbs up - thanks for taking the comments into account. Great job! Maurizio On 04/05/18 22:59, Jonathan Gibbons wrote: Here's an update to the previously proposed patch for JEP 330: Launch Single-File Source-Code Programs. It includes all review feedback so far. The changes are mostly

Re: RFR 8209064: Make intellij support more robust after changes for 2018.2

On 23/08/18 14:21, Maurizio Cimadamore wrote: On 21/08/18 10:31, Magnus Ihse Bursie wrote: Hi Maurizio! Even if this only incidentally relates to the build, please always include build-dev when making changes in the "make" directory. I will - thanks As far as I can understand, yo

Re: RFR 8209064: Make intellij support more robust after changes for 2018.2

correct - the script is not meant to be modified; customized properties are injected by the runtime environment - such properties are defined in the ant.xml file and that is indeed a template file (so it can be customized). Thanks Maurizio /Magnus On 2018-08-07 13:21, Maurizio Cimadamore wro

RFR 8210226: Add support for multiple project folders to idea.sh

Hi, this patch adds proper support for -o option to the idea.sh script, which allows to place the .idea folder under any given output folder (not necessarily the JDK root). To be able to do this, I had to revampo the logic for template substitution in idea.sh, as it was growing too brittle.

Re: RFR 8210226: Add support for multiple project folders to idea.sh

! Maurizio On 30/08/18 16:12, Maurizio Cimadamore wrote: Hi, this patch adds proper support for -o option to the idea.sh script, which allows to place the .idea folder under any given output folder (not necessarily the JDK root). To be able to do this, I had to revampo the logic

Re: RFR 8210318: idea.sh script doesn't work on Mac

Ah - thanks for the tip, I'll give that a try Maurizio On 04/09/18 18:50, Erik Joelsson wrote: Hello, $TARGET was just pseudo code. In your case it's $1.tmp. /Erik On 2018-09-04 10:34, Maurizio Cimadamore wrote: Hi Erik, would $TARGET be set by make? Maurizio On 04/09/18 16:55, Erik

Re: RFR 8210318: idea.sh script doesn't work on Mac

, Maurizio Cimadamore wrote: Hi Erik, would $TARGET be set by make? Maurizio On 04/09/18 16:55, Erik Joelsson wrote: Hello, When choosing a temp file in the build, we avoid using /tmp whenever possible. A common pattern is instead to write to $TARGET.tmp and then mv that to $TARGET. Though unlikely

generated sources and make

Hi, I was playing with the script for IntelliJ project generation, and I noted that make does not report generated source roots (e.g. those under support/gensrc) _unless_ such folders exist in the file system. This is a bit of a let down - normally one would create the IJ project on an empty

Re: generated sources and make

of gensrc is pretty cheap to build. /Erik On 2018-07-09 04:18, Maurizio Cimadamore wrote: Hi, I was playing with the script for IntelliJ project generation, and I noted that make does not report generated source roots (e.g. those under support/gensrc) _unless_ such folders exist in the file

Re: RFR: 8201274: Launch Single-File Source-Code Programs

Looks great - some initial comments (I can't really comment on the launcher changes): * This logic is efficient: int magic = (in.read() << 8) + in.read(); boolean shebang = magic == (('#' << 8) + '!'); but convoluted to read; perhaps could be improved slightly by making '#' << 8) + '!' a

Re: RFR: 8201274: Launch Single-File Source-Code Programs

, Maurizio Cimadamore wrote: Looks great - some initial comments (I can't really comment on the launcher changes): * This logic is efficient: int magic = (in.read() << 8) + in.read(); boolean shebang = magic == (('#' << 8) + '!'); but convoluted to read; perhaps could be impro

is ccache working effectively?

Hi, I've observed that the time spent in C/CPP compilation during a JDK build seems to have crept higher lately. By monitoring processes during the build I found an awful lot of c++ compilations taking place, which was surprising since I'm setup to use ccache. So I decided to run some more

Re: is ccache working effectively?

On 08/11/2018 20:31, Erik Joelsson wrote: I think we need more details here to figure it out, but it doesn't surprise me that hotspot is the part that's failing. Building hotspot is way more complex than the rest. Digging more into the command lines of the various HS files, they include

Re: is ccache working effectively?

can try --disable-precompiled-headers and see if that helps. We have had special considerations for combining these features in the past, but it's certainly a source of trouble for ccache. /Erik On 2018-11-08 16:20, Maurizio Cimadamore wrote: On 08/11/2018 20:31, Erik Joelsson wrote: I think

RFR 8210318: idea.sh script doesn't work on Mac

Hi, following the latest updates to the idea.sh script, Mac users reported issues - mostly having to do with usage of 'sed' - more specifically: * sed -i option is not portable - it has different formats in Mac vs. Linux. This patch does without -i, by moving the replaced file onto a

Re: Help with JDK-8211057

Hi Magnus, it's true that CompileProperties relies on Properties, which rely on Hashtable (not HashMap) which is likely NOT to have predictable iteration order (although I haven't been able to make it spit things in different orders on my Linux box). That said, it seems like the code keeps

Re: RFR: JDK-8210962 Deprecate jdk-variant

I have been bitten by this change - not something too difficult to handle, but I think it can be confusing - e.g. if you run 'make reconfigure' the old config name will be preserved, but if you run 'sh configure' from scratch you will have two configuration sitting beside each other and any

X11 build error

Hi, we recently refreshed the Panama repo and I'm getting a weird build error: === Output from failing command(s) repeated here === * For target support_native_java.desktop_libawt_xawt_awt_GraphicsEnv.o: /w/lt/panama/dev/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:37:10:

Re: X11 build error

Seems like a duplicate of this? https://bugs.openjdk.java.net/browse/JDK-8213944 Maurizio On 21/11/2018 12:15, Maurizio Cimadamore wrote: Hi, we recently refreshed the Panama repo and I'm getting a weird build error: === Output from failing command(s) repeated here === * For target

Re: is ccache working effectively?

On 20/11/2018 11:49, Magnus Ihse Bursie wrote: On 2018-11-09 11:09, Maurizio Cimadamore wrote: That does the trick, thanks. If ccache and PCH is so bad in combination, maybe we should not allow it? Like turning off PCH by default of --enacle-ccache is given? Or at least *warn

strange reconfigure issue

Hi, after Panama merged with upstream yesterday, many developers reported an issue with make reconfigure which fails with this message: configure: Current directory is configure: Since this is not the source root, configure will output the configuration here configure: (as opposed to

Re: RFR: JDK-8235483: Warnings printed during the build

Sounds sensible! Thanks Maurizio On 06/12/2019 15:40, Jan Lahoda wrote: Hi, During build, several warnings are printed: --- Compiling 68 files for COMPILE_CREATE_SYMBOLS

Re: JDK 14 RFR of JDK-8224630: ElementScannerN, N > 9 should scan type parameters

Looks good - I agree we should proactively update this on every release. Maurizio On 05/12/2019 03:29, Joe Darcy wrote: Hello, First on the build front, the -source/-target used in the bootstrap build of langtools was stuck at 9; in the change I'm proposing to update it to 13, the minimum

Re: RFR: JDK-8226585: Improve javac messages for using a preview API

Looks good - but I suggest garbage collecting the isEssentialAPI() from the @PreviewFeature annotation, as the new behavior effectively removes any distinctions between the two (unless I miss something). Maurizio On 16/10/2019 13:50, Jan Lahoda wrote: Hi, An updated patch is here:

Re: RFR: JDK-8226585: Improve javac messages for using a preview API

: 18. října 2019 14:05:45 SELČ, Maurizio Cimadamore napsal: Looks good - but I suggest garbage collecting the isEssentialAPI() from the @PreviewFeature annotation, as the new behavior effectively removes any distinctions between the two (unless I miss something). I am afraid there is still

Re: RFR: JDK-8226585: Improve javac messages for using a preview API

The javac changes looks good. I guess I would have preferred to move the check for preview from Check to Preview, and also create a tighter integration between PreviewFeature.Feature and javac's Feature enum, so that we could generate tight error messages, but I guess we can also do that as a

Re: Builds fail due to use of preview features & removed arguments

On 20/12/2019 00:22, Ty Young wrote: On 12/19/19 6:12 PM, Maurizio Cimadamore wrote: On 20/12/2019 00:02, Ty Young wrote: On 12/19/19 5:44 PM, Maurizio Cimadamore wrote: On 19/12/2019 23:30, David Holmes wrote: I think this is more an issue for the language and compiler folk

  1   2   3   4   >