Re: Inconsistent revision control

2023-06-26 Thread Alan Snyder
Thanks for the information. That indeed was the problem. Carbon Copy Cloner 
squirrels some files away to allow undo, a feature that I don’t usually pay 
attention to. Removing the extra CCC directory did the trick.

  Alan





> On Jun 26, 2023, at 6:24 PM, Sriram Narayanan  wrote:
> 
> 
> 
> On Tue, 27 Jun 2023 at 8:34 AM, Alan Snyder  > wrote:
>> Can we start over?
>> 
>> I am trying to do a JDK build using make.
>> 
>> It reports an error like this: Inconsistent revision control: 17-24-55/ is 
>> missing .git directory
>> 
>> at which point the build is aborted.
>> 
>> I’d like to know what this message means, so that I can fix the problem or 
>> avoid it in the future.
>> 
>> What is 17-24-55?
> 
> 
> It is a directory. Please check which files are within. Try removing it ( 
> move it outside the entire source tree) and stay the build.
> 
> 
>> 
>> 
>> If there is a missing .git directory, where would it be?
>> 
>> The top level .git directory is present.
>> 
>> If I do “git status” it tells me things that I expect, listing untracked 
>> files and changes not staged for commit.
>> 
>> It does not complain about the repo being broken in any way.
>> 



Re: Inconsistent revision control

2023-06-26 Thread Sriram Narayanan
On Tue, 27 Jun 2023 at 8:34 AM, Alan Snyder  wrote:

> Can we start over?
>
> I am trying to do a JDK build using make.
>
> It reports an error like this: Inconsistent revision control: 17-24-55/ is
> missing .git directory
>
> at which point the build is aborted.
>
> I’d like to know what this message means, so that I can fix the problem or
> avoid it in the future.
>
> What is 17-24-55?



It is a directory. Please check which files are within. Try removing it (
move it outside the entire source tree) and stay the build.



>
> If there is a missing .git directory, where would it be?
>
> The top level .git directory is present.
>
> If I do “git status” it tells me things that I expect, listing untracked
> files and changes not staged for commit.
>
> It does not complain about the repo being broken in any way.
>
>


Re: Inconsistent revision control

2023-06-26 Thread Joseph D. Darcy

Thread archived at

https://mail.openjdk.org/pipermail/build-dev/2023-June/039957.html

-Joe

On 6/26/2023 6:03 PM, Alan Snyder wrote:

I’m deducing the existence of a message from Erik that I did not receive.
Perhaps someone can repost it?



Re: Inconsistent revision control

2023-06-26 Thread Alan Snyder
Can we start over?

I am trying to do a JDK build using make.

It reports an error like this: Inconsistent revision control: 17-24-55/ is 
missing .git directory

at which point the build is aborted.

I’d like to know what this message means, so that I can fix the problem or 
avoid it in the future.

What is 17-24-55?

If there is a missing .git directory, where would it be?

The top level .git directory is present.

If I do “git status” it tells me things that I expect, listing untracked files 
and changes not staged for commit.

It does not complain about the repo being broken in any way.



Re: RFR: JDK-8308398 Move SunEC crypto provider into java.base [v2]

2023-06-26 Thread Anthony Scarpino
> Hi,
> 
> I need a code review for moving the contents of the jdk.crypto.ec module into 
> java.base.  This moves the SunEC JCE Provider (Elliptic Curve) into 
> java.base.  EC has always been separate from the base module/pkg because of 
> its dependence on a native library.  That library was removed in JDK 16.  An 
> empty jdk.crypto.ec module will remain for compatibility, but marked as 
> deprecated with the intent to be removed in a future release.
> 
> There should be no compatibility risk for application using EC through JCE. 
> There are no public API changes to EC, XEC, and EdDSA classes .  Applications 
> that unwisely accessing internal EC classes will need to use the java.base 
> module.
> 
> Thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional 
commit since the last revision:

  update for review:  changed test, removed commented out code in module, fixed 
switch statement, added --limit-modules

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/14457/files
  - new: https://git.openjdk.org/jdk/pull/14457/files/85870520..32b4cee1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14457&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14457&range=00-01

  Stats: 34 lines in 5 files changed: 13 ins; 3 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/14457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14457/head:pull/14457

PR: https://git.openjdk.org/jdk/pull/14457


Re: Inconsistent revision control

2023-06-26 Thread Joseph D. Darcy
And anyone is free to use the standard set of tools, which is know to 
work and used daily by dozens to hundreds of developers.


-Joe

On 6/26/2023 3:24 PM, David Holmes wrote:

On 27/06/2023 8:04 am, Alan Snyder wrote:

An incremental clone is a sync, like an incremental backup.

Erik responded to a different question. I’ve gotten no closer to 
figuring out this problem.


Erik responded to exactly your question.


Feel free to be helpful, if you can.

I don’t think it is helpful to nitpick my words.


When your words do not make it clear what exactly it is you are 
reporting then they need to be clarified. "clone" is a git operation 
not a build one.


David




On Jun 26, 2023, at 2:46 PM, David Holmes  
wrote:


On 27/06/2023 7:40 am, Alan Snyder wrote:

No, I meant incremental clone.


What is an incremental clone?

After updating the directory, I tried to do an incremental build 
and got the strange message.


So you did mean "incremental build".

After that, I tried doing a full build, reconfiguring, etc., but 
nothing helped.
Now that you know that a build tool is involved, can you help me 
figure out what the problem is?


I think Erik already addressed that.

David


On Jun 26, 2023, at 2:32 PM, David Holmes 
 wrote:


On 26/06/2023 10:55 pm, Alan Snyder wrote:
It would be very unlikely for CCC to fail to correctly clone the 
directory.
It would be helpful to know what the build tool is complaining 
about with that message.


Wasn't apparent any build tool was involved. You stated:

After an incremental clone of the directory tree, I get 
mysterious messages like this:


I presume you actually meant "incremental build".

David

On Jun 25, 2023, at 10:04 PM, David Holmes 
 wrote:


On 24/06/2023 12:28 pm, Alan Snyder wrote:
I have been trying to use Carbon Copy Cloner to make a copy of 
an active jdk repo on another macOS machine for the purpose of 
running tests.

The initial clone is fine.
After an incremental clone of the directory tree, I get 
mysterious messages like this:

Inconsistent revision control: 17-24-55/ is missing .git directory
What is this about?
Is there an easy way to fix this problem?


This isn't really a build issue. I can only suggest that you 
check that the copy you made actually copied across all hidden 
directories, e.g. .git, as well.


Cheers,
David









Re: Inconsistent revision control

2023-06-26 Thread David Holmes

On 27/06/2023 8:04 am, Alan Snyder wrote:

An incremental clone is a sync, like an incremental backup.

Erik responded to a different question. I’ve gotten no closer to figuring out 
this problem.


Erik responded to exactly your question.


Feel free to be helpful, if you can.

I don’t think it is helpful to nitpick my words.


When your words do not make it clear what exactly it is you are 
reporting then they need to be clarified. "clone" is a git operation not 
a build one.


David





On Jun 26, 2023, at 2:46 PM, David Holmes  wrote:

On 27/06/2023 7:40 am, Alan Snyder wrote:

No, I meant incremental clone.


What is an incremental clone?


After updating the directory, I tried to do an incremental build and got the 
strange message.


So you did mean "incremental build".


After that, I tried doing a full build, reconfiguring, etc., but nothing helped.
Now that you know that a build tool is involved, can you help me figure out 
what the problem is?


I think Erik already addressed that.

David



On Jun 26, 2023, at 2:32 PM, David Holmes  wrote:

On 26/06/2023 10:55 pm, Alan Snyder wrote:

It would be very unlikely for CCC to fail to correctly clone the directory.
It would be helpful to know what the build tool is complaining about with that 
message.


Wasn't apparent any build tool was involved. You stated:


After an incremental clone of the directory tree, I get mysterious messages 
like this:


I presume you actually meant "incremental build".

David


On Jun 25, 2023, at 10:04 PM, David Holmes  wrote:

On 24/06/2023 12:28 pm, Alan Snyder wrote:

I have been trying to use Carbon Copy Cloner to make a copy of an active jdk 
repo on another macOS machine for the purpose of running tests.
The initial clone is fine.
After an incremental clone of the directory tree, I get mysterious messages 
like this:
Inconsistent revision control: 17-24-55/ is missing .git directory
What is this about?
Is there an easy way to fix this problem?


This isn't really a build issue. I can only suggest that you check that the 
copy you made actually copied across all hidden directories, e.g. .git, as well.

Cheers,
David









Re: Inconsistent revision control

2023-06-26 Thread Alan Snyder
An incremental clone is a sync, like an incremental backup.

Erik responded to a different question. I’ve gotten no closer to figuring out 
this problem.

Feel free to be helpful, if you can.

I don’t think it is helpful to nitpick my words.



> On Jun 26, 2023, at 2:46 PM, David Holmes  wrote:
> 
> On 27/06/2023 7:40 am, Alan Snyder wrote:
>> No, I meant incremental clone.
> 
> What is an incremental clone?
> 
>> After updating the directory, I tried to do an incremental build and got the 
>> strange message.
> 
> So you did mean "incremental build".
> 
>> After that, I tried doing a full build, reconfiguring, etc., but nothing 
>> helped.
>> Now that you know that a build tool is involved, can you help me figure out 
>> what the problem is?
> 
> I think Erik already addressed that.
> 
> David
> 
> 
>>> On Jun 26, 2023, at 2:32 PM, David Holmes  wrote:
>>> 
>>> On 26/06/2023 10:55 pm, Alan Snyder wrote:
 It would be very unlikely for CCC to fail to correctly clone the directory.
 It would be helpful to know what the build tool is complaining about with 
 that message.
>>> 
>>> Wasn't apparent any build tool was involved. You stated:
>>> 
 After an incremental clone of the directory tree, I get mysterious 
 messages like this:
>>> 
>>> I presume you actually meant "incremental build".
>>> 
>>> David
>>> 
> On Jun 25, 2023, at 10:04 PM, David Holmes  
> wrote:
> 
> On 24/06/2023 12:28 pm, Alan Snyder wrote:
>> I have been trying to use Carbon Copy Cloner to make a copy of an active 
>> jdk repo on another macOS machine for the purpose of running tests.
>> The initial clone is fine.
>> After an incremental clone of the directory tree, I get mysterious 
>> messages like this:
>> Inconsistent revision control: 17-24-55/ is missing .git directory
>> What is this about?
>> Is there an easy way to fix this problem?
> 
> This isn't really a build issue. I can only suggest that you check that 
> the copy you made actually copied across all hidden directories, e.g. 
> .git, as well.
> 
> Cheers,
> David
> 
>>> 
> 



Re: Inconsistent revision control

2023-06-26 Thread David Holmes

On 27/06/2023 7:40 am, Alan Snyder wrote:

No, I meant incremental clone.


What is an incremental clone?


After updating the directory, I tried to do an incremental build and got the 
strange message.


So you did mean "incremental build".


After that, I tried doing a full build, reconfiguring, etc., but nothing helped.

Now that you know that a build tool is involved, can you help me figure out 
what the problem is?


I think Erik already addressed that.

David



On Jun 26, 2023, at 2:32 PM, David Holmes  wrote:

On 26/06/2023 10:55 pm, Alan Snyder wrote:

It would be very unlikely for CCC to fail to correctly clone the directory.
It would be helpful to know what the build tool is complaining about with that 
message.


Wasn't apparent any build tool was involved. You stated:


After an incremental clone of the directory tree, I get mysterious messages 
like this:


I presume you actually meant "incremental build".

David


On Jun 25, 2023, at 10:04 PM, David Holmes  wrote:

On 24/06/2023 12:28 pm, Alan Snyder wrote:

I have been trying to use Carbon Copy Cloner to make a copy of an active jdk 
repo on another macOS machine for the purpose of running tests.
The initial clone is fine.
After an incremental clone of the directory tree, I get mysterious messages 
like this:
Inconsistent revision control: 17-24-55/ is missing .git directory
What is this about?
Is there an easy way to fix this problem?


This isn't really a build issue. I can only suggest that you check that the 
copy you made actually copied across all hidden directories, e.g. .git, as well.

Cheers,
David







Re: Inconsistent revision control

2023-06-26 Thread Alan Snyder
No, I meant incremental clone.

After updating the directory, I tried to do an incremental build and got the 
strange message.

After that, I tried doing a full build, reconfiguring, etc., but nothing helped.

Now that you know that a build tool is involved, can you help me figure out 
what the problem is?



> On Jun 26, 2023, at 2:32 PM, David Holmes  wrote:
> 
> On 26/06/2023 10:55 pm, Alan Snyder wrote:
>> It would be very unlikely for CCC to fail to correctly clone the directory.
>> It would be helpful to know what the build tool is complaining about with 
>> that message.
> 
> Wasn't apparent any build tool was involved. You stated:
> 
> > After an incremental clone of the directory tree, I get mysterious messages 
> > like this:
> 
> I presume you actually meant "incremental build".
> 
> David
> 
>>> On Jun 25, 2023, at 10:04 PM, David Holmes  wrote:
>>> 
>>> On 24/06/2023 12:28 pm, Alan Snyder wrote:
 I have been trying to use Carbon Copy Cloner to make a copy of an active 
 jdk repo on another macOS machine for the purpose of running tests.
 The initial clone is fine.
 After an incremental clone of the directory tree, I get mysterious 
 messages like this:
 Inconsistent revision control: 17-24-55/ is missing .git directory
 What is this about?
 Is there an easy way to fix this problem?
>>> 
>>> This isn't really a build issue. I can only suggest that you check that the 
>>> copy you made actually copied across all hidden directories, e.g. .git, as 
>>> well.
>>> 
>>> Cheers,
>>> David
>>> 
> 



Re: Inconsistent revision control

2023-06-26 Thread David Holmes

On 26/06/2023 10:55 pm, Alan Snyder wrote:

It would be very unlikely for CCC to fail to correctly clone the directory.

It would be helpful to know what the build tool is complaining about with that 
message.


Wasn't apparent any build tool was involved. You stated:

> After an incremental clone of the directory tree, I get mysterious 
messages like this:


I presume you actually meant "incremental build".

David


On Jun 25, 2023, at 10:04 PM, David Holmes  wrote:

On 24/06/2023 12:28 pm, Alan Snyder wrote:

I have been trying to use Carbon Copy Cloner to make a copy of an active jdk 
repo on another macOS machine for the purpose of running tests.
The initial clone is fine.
After an incremental clone of the directory tree, I get mysterious messages 
like this:
Inconsistent revision control: 17-24-55/ is missing .git directory
What is this about?
Is there an easy way to fix this problem?


This isn't really a build issue. I can only suggest that you check that the 
copy you made actually copied across all hidden directories, e.g. .git, as well.

Cheers,
David





Re: RFR: 8310890: Normalize identifier names

2023-06-26 Thread Pavel Rappo
On Mon, 26 Jun 2023 18:44:42 GMT, Pavel Rappo  wrote:

>> make/data/charsetmapping/charsets line 149:
>> 
>>> 147: package sun.nio.cs
>>> 148: typesbcs
>>> 149: histname ISO8859_2
>> 
>> Should this column be re-aligned with the longer name?
>
> I thought about it before publishing the PR. I decided not to re-align 
> anything because (i) the change would be bigger and (ii) the fact that there 
> was already a property that is similarly misaligned; search for:
> 
> internal true

If you are concerned with functionality rather than looks, then I can tell you 
this:

1. The build succeeds and tier1 tests pass.
2. The code that parses that file expect one or more whitespace characters as a 
separator:

String[] tokens = line.split("\\s+");

-

PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242629052


Re: RFR: 8310890: Normalize identifier names

2023-06-26 Thread Pavel Rappo
On Mon, 26 Jun 2023 18:31:06 GMT, Jens Lidestrom  wrote:

>> Please review this cleanup PR to normalize names of identifiers which are 
>> Java variables/fields or tokens in text files. Those names either contain a 
>> pronoun that is very rarely used in code, or seem like they contain such a 
>> pronoun, which, in fact, they don't. Either way, the goal is to improve 
>> readability and clarity.
>> 
>> Also, this PR fixes a few related typos.
>
> make/data/charsetmapping/charsets line 149:
> 
>> 147: package sun.nio.cs
>> 148: typesbcs
>> 149: histname ISO8859_2
> 
> Should this column be re-aligned with the longer name?

I thought about it before publishing the PR. I decided not to re-align anything 
because (i) the change would be bigger and (ii) the fact that there was already 
a property that is similarly misaligned; search for:

internal true

-

PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242617579


Re: RFR: 8310890: Normalize identifier names

2023-06-26 Thread Pavel Rappo
On Mon, 26 Jun 2023 18:21:07 GMT, Roger Riggs  wrote:

>> Please review this cleanup PR to normalize names of identifiers which are 
>> Java variables/fields or tokens in text files. Those names either contain a 
>> pronoun that is very rarely used in code, or seem like they contain such a 
>> pronoun, which, in fact, they don't. Either way, the goal is to improve 
>> readability and clarity.
>> 
>> Also, this PR fixes a few related typos.
>
> src/java.base/share/classes/java/util/EnumMap.java line 690:
> 
>> 688: Object otherValue = em.vals[i];
>> 689: if (otherValue != ourValue &&
>> 690: (otherValue == null || !otherValue.equals(ourValue)))
> 
> Is this the same as java.util.Objects:  
>   `!Objects.equals(vals[i], em.vals[i]);`

You are right: we can fold this if-else construct into that utility method. 
That said, it in *this* PR, I'd prefer not to.

The reason is that I've been preparing a much bigger PR that uses 
Objects.equals as well as other utility methods and modern language features to 
improve some equals, hashCode, and compareTo implementations across java.base. 
I'm planning to publish that PR soon. In fact, this change to Java variable 
names was cherry-picked from that bigger PR, to separate trivial renames from 
code changes.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242608041


Re: RFR: 8310890: Normalize identifier names

2023-06-26 Thread Jens Lidestrom
On Mon, 26 Jun 2023 14:07:03 GMT, Pavel Rappo  wrote:

> Please review this cleanup PR to normalize names of identifiers which are 
> Java variables/fields or tokens in text files. Those names either contain a 
> pronoun that is very rarely used in code, or seem like they contain such a 
> pronoun, which, in fact, they don't. Either way, the goal is to improve 
> readability and clarity.
> 
> Also, this PR fixes a few related typos.

make/data/charsetmapping/charsets line 149:

> 147: package sun.nio.cs
> 148: typesbcs
> 149: histname ISO8859_2

Should this column be re-aligned with the longer name?

-

PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242595069


Re: RFR: 8310890: Normalize identifier names

2023-06-26 Thread Roger Riggs
On Mon, 26 Jun 2023 14:07:03 GMT, Pavel Rappo  wrote:

> Please review this cleanup PR to normalize names of identifiers which are 
> Java variables/fields or tokens in text files. Those names either contain a 
> pronoun that is very rarely used in code, or seem like they contain such a 
> pronoun, which, in fact, they don't. Either way, the goal is to improve 
> readability and clarity.
> 
> Also, this PR fixes a few related typos.

Looks good, with or without the suggestion.

src/java.base/share/classes/java/util/EnumMap.java line 690:

> 688: Object otherValue = em.vals[i];
> 689: if (otherValue != ourValue &&
> 690: (otherValue == null || !otherValue.equals(ourValue)))

Is this the same as java.util.Objects:  
  `!Objects.equals(vals[i], em.vals[i]);`

-

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14653#pullrequestreview-1499137712
PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242585695


Re: RFR: 8310890: Normalize identifier names

2023-06-26 Thread Naoto Sato
On Mon, 26 Jun 2023 14:07:03 GMT, Pavel Rappo  wrote:

> Please review this cleanup PR to normalize names of identifiers which are 
> Java variables/fields or tokens in text files. Those names either contain a 
> pronoun that is very rarely used in code, or seem like they contain such a 
> pronoun, which, in fact, they don't. Either way, the goal is to improve 
> readability and clarity.
> 
> Also, this PR fixes a few related typos.

Looks fine to me

-

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14653#pullrequestreview-1499124651


RFR: 8310890: Normalize identifier names

2023-06-26 Thread Pavel Rappo
Please review this cleanup PR to normalize names of identifiers which are Java 
variables/fields or tokens in text files. Those names either contain a pronoun 
that is very rarely used in code, or seem like they contain such a pronoun, 
which, in fact, they don't. Either way, the goal is to improve readability and 
clarity.

Also, this PR fixes a few related typos.

-

Commit messages:
 - Improve further
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14653/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14653&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310890
  Stats: 184 lines in 10 files changed: 0 ins; 0 del; 184 mod
  Patch: https://git.openjdk.org/jdk/pull/14653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14653/head:pull/14653

PR: https://git.openjdk.org/jdk/pull/14653


Re: Inconsistent revision control

2023-06-26 Thread erik . joelsson
The makefile is trying to locate your local repositories and record the 
state of the workspace. It will only do so if it finds what looks like 
.git repositories and a git executable to run. If not, it will just skip 
this. You aren't giving us much to work on here, but the error message 
looks to originate from this line:


"$(error Inconsistent revision control: $(repo) is missing $(SCM_DIR) 
directory))"


This implies that the string "17-24-55" is a directory name that the 
makefile thinks is a repository. If you could locate this directory in 
your workspace, it might shed some light on what's actually happening.


The algorithm for finding repositories is basically this (but using the 
make $(wildcard) function instead of ls):


$ ls .git */.git */*/.git */*/*/.git */*/*/*/.git

This means that there must be a file named ".git" in your "17-24-55" 
workspace, or possibly up to 4 directories down.


I'm not familiar with Carbon Copy Cloner, and I'm not sure why you would 
use such a tool. Git is a pretty good tool for moving source code 
around. Adding another layer of copying on top seems to me like it could 
easily cause trouble.


/Erik

On 6/26/23 16:12, Alan Snyder wrote:

That much is obvious :-)

As the script appears to run git status, I am going to take a guess that it is 
complaining because I have modified or untracked files in the repo.
Can someone confirm that?

On the other hand, I don’t see why modified or untracked files should prevent 
building during development.

The actual message makes no sense to me.  What is “17-24-55”?

I was not able to find any files named “.src-rev”.





On Jun 26, 2023, at 6:08 AM, Pavel Rappo  wrote:

It appears that the error is coming from make/SourceRevision.gmk


On 26 Jun 2023, at 13:55, Alan Snyder  wrote:

It would be very unlikely for CCC to fail to correctly clone the directory.

It would be helpful to know what the build tool is complaining about with that 
message.


On Jun 25, 2023, at 10:04 PM, David Holmes  wrote:

On 24/06/2023 12:28 pm, Alan Snyder wrote:

I have been trying to use Carbon Copy Cloner to make a copy of an active jdk 
repo on another macOS machine for the purpose of running tests.
The initial clone is fine.
After an incremental clone of the directory tree, I get mysterious messages 
like this:
Inconsistent revision control: 17-24-55/ is missing .git directory
What is this about?
Is there an easy way to fix this problem?

This isn't really a build issue. I can only suggest that you check that the 
copy you made actually copied across all hidden directories, e.g. .git, as well.

Cheers,
David



Re: Inconsistent revision control

2023-06-26 Thread Alan Snyder
That much is obvious :-)

As the script appears to run git status, I am going to take a guess that it is 
complaining because I have modified or untracked files in the repo.
Can someone confirm that?

On the other hand, I don’t see why modified or untracked files should prevent 
building during development.

The actual message makes no sense to me.  What is “17-24-55”?

I was not able to find any files named “.src-rev”.




> On Jun 26, 2023, at 6:08 AM, Pavel Rappo  wrote:
> 
> It appears that the error is coming from make/SourceRevision.gmk
> 
>> On 26 Jun 2023, at 13:55, Alan Snyder  wrote:
>> 
>> It would be very unlikely for CCC to fail to correctly clone the directory.
>> 
>> It would be helpful to know what the build tool is complaining about with 
>> that message.
>> 
>>> On Jun 25, 2023, at 10:04 PM, David Holmes  wrote:
>>> 
>>> On 24/06/2023 12:28 pm, Alan Snyder wrote:
 I have been trying to use Carbon Copy Cloner to make a copy of an active 
 jdk repo on another macOS machine for the purpose of running tests.
 The initial clone is fine.
 After an incremental clone of the directory tree, I get mysterious 
 messages like this:
 Inconsistent revision control: 17-24-55/ is missing .git directory
 What is this about?
 Is there an easy way to fix this problem?
>>> 
>>> This isn't really a build issue. I can only suggest that you check that the 
>>> copy you made actually copied across all hidden directories, e.g. .git, as 
>>> well.
>>> 
>>> Cheers,
>>> David
>>> 
>> 
> 



Re: RFR: 8310728: Enable Zc:inline flag in Visual Studio build

2023-06-26 Thread Erik Joelsson
On Mon, 26 Jun 2023 12:36:38 GMT, Daniel Jeliński  wrote:

> Enabling `Zc:inline` flag improves C++11 standard compliance, reduces the 
> size of obj files produced by the build by 200+MB, and might also improve 
> build speed.
> 
> 2 files failed to compile with the flag added; see JBS for details if you're 
> interested. This PR fixes the compilation issues.
> 
> Tier1-4 builds and Tier1-2 tests passed.

Looks good to me.

-

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14651#pullrequestreview-1498487839


Re: Inconsistent revision control

2023-06-26 Thread Pavel Rappo
It appears that the error is coming from make/SourceRevision.gmk

> On 26 Jun 2023, at 13:55, Alan Snyder  wrote:
> 
> It would be very unlikely for CCC to fail to correctly clone the directory.
> 
> It would be helpful to know what the build tool is complaining about with 
> that message.
> 
>> On Jun 25, 2023, at 10:04 PM, David Holmes  wrote:
>> 
>> On 24/06/2023 12:28 pm, Alan Snyder wrote:
>>> I have been trying to use Carbon Copy Cloner to make a copy of an active 
>>> jdk repo on another macOS machine for the purpose of running tests.
>>> The initial clone is fine.
>>> After an incremental clone of the directory tree, I get mysterious messages 
>>> like this:
>>> Inconsistent revision control: 17-24-55/ is missing .git directory
>>> What is this about?
>>> Is there an easy way to fix this problem?
>> 
>> This isn't really a build issue. I can only suggest that you check that the 
>> copy you made actually copied across all hidden directories, e.g. .git, as 
>> well.
>> 
>> Cheers,
>> David
>> 
> 



Re: Inconsistent revision control

2023-06-26 Thread Alan Snyder
It would be very unlikely for CCC to fail to correctly clone the directory.

It would be helpful to know what the build tool is complaining about with that 
message.

> On Jun 25, 2023, at 10:04 PM, David Holmes  wrote:
> 
> On 24/06/2023 12:28 pm, Alan Snyder wrote:
>> I have been trying to use Carbon Copy Cloner to make a copy of an active jdk 
>> repo on another macOS machine for the purpose of running tests.
>> The initial clone is fine.
>> After an incremental clone of the directory tree, I get mysterious messages 
>> like this:
>> Inconsistent revision control: 17-24-55/ is missing .git directory
>> What is this about?
>> Is there an easy way to fix this problem?
> 
> This isn't really a build issue. I can only suggest that you check that the 
> copy you made actually copied across all hidden directories, e.g. .git, as 
> well.
> 
> Cheers,
> David
> 



RFR: 8310728: Enable Zc:inline flag in Visual Studio build

2023-06-26 Thread Daniel Jeliński
Enabling `Zc:inline` flag improves C++11 standard compliance, reduces the size 
of obj files produced by the build by 200+MB, and might also improve build 
speed.

2 files failed to compile with the flag added; see JBS for details if you're 
interested. This PR fixes the compilation issues.

Tier1-4 builds and Tier1-2 tests passed.

-

Commit messages:
 - Build with Zc:inline

Changes: https://git.openjdk.org/jdk/pull/14651/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14651&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310728
  Stats: 5 lines in 3 files changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14651/head:pull/14651

PR: https://git.openjdk.org/jdk/pull/14651


Re: RFR: 8298047: Remove all non-significant trailing whitespace from properties files [v2]

2023-06-26 Thread Erik Joelsson
On Sat, 24 Jun 2023 06:47:48 GMT, Vladimir Sitnikov  
wrote:

> I've posted the suggetion to add .editorconfig on ide-support-dev, however, 
> the list does not seem to be active: 
> https://mail.openjdk.org/pipermail/ide-support-dev/2023-June/000281.html

I think that sounds like a reasonable idea. I'm not following that mailing 
list. I think you can just post a PR with your suggested contents and target 
build-dev (through the `build` label). I'm not familiar with this kind of file, 
so an explanation of which IDEs support it would be good to include.

-

PR Comment: https://git.openjdk.org/jdk/pull/11491#issuecomment-1607073914


Re: xattr: Permission denied: build/macosx-aarch64-server-release/jdk/conf/management/jmxremote.password.template

2023-06-26 Thread Vitaly Provodin
Erik,

thanks a lot!

Terminal did not have the Developer Tools permission - adding it resolves this 
issue.

Vitaly

> On 26. Jun 2023, at 16:20, erik.joels...@oracle.com wrote:
> 
> Hello Vitaly,
> This could be a permissions problem with the terminal application you are 
> using. This seems like a common issue if you use something other than the 
> default Terminal application. If so you need to give that application 
> permissions to run "developer tools". It could also be some anti-virus, if 
> you have that installed, that is flagging the file and preventing you from 
> accessing it.
> /Erik
> On 6/23/23 12:54, Vitaly Provodin wrote:
>> Hi all 
>> After migrating to a new macbook I become getting the following error
>> 
>> + make images CONF=macosx-aarch64-server-release
>> Using exact match for CONF=macosx-aarch64-server-release (other matches are 
>> possible)
>> Building target 'images' in configuration 'macosx-aarch64-server-release'
>> Compiling up to 1 files for BUILD_TOOLS_HOTSPOT
>> Compiling up to 8 files for BUILD_TOOLS_LANGTOOLS
>> xattr: [Errno 13] Permission denied: 
>> ‘~/workspace/openjdk/build/macosx-aarch64-server-release/jdk/conf/management/jmxremote.password.template'
>> make[3]: *** 
>> [~/workspace/openjdk/build/macosx-aarch64-server-release/jdk/conf/management/jmxremote.password.template]
>>  Error 1
>> make[3]: *** Deleting file 
>> `~/workspace/openjdk/build/macosx-aarch64-server-release/jdk/conf/management/jmxremote.password.template'
>> make[2]: *** [jdk.management.agent-copy] Error 2
>> make[2]: *** Waiting for unfinished jobs
>> 
>> ERROR: Build failed for target 'images' in configuration 
>> 'macosx-aarch64-server-release' (exit code 2) 
>> 
>> as far as I understand this file is being generated during make images - not 
>> clear why it was not generated in my case… On old macbook it works well.
>> I checked permissions for all dirs. I also launched make on a new clone - 
>> with no success…
>> 
>> configure works well. macOS 13.4.1, Xcode 14.3.1
>> Has anybody faced this issue? How it may be resolved?
>> 
>> Thanks in advance for any ideas
>> Vitaly



Re: path arguments to make

2023-06-26 Thread erik . joelsson
The problem lists are expected to be either relative to the test root 
(test/jdk in this case) or an absolute path. The command using them 
happens to be launched with CWD in the make dir, so you were able to 
resolve a file relative to that dir. That isn't intentional.


/Erik

On 6/24/23 04:31, Alan Snyder wrote:

This command worked:

make exploded-test TEST=jdk_awt 
JTREG="EXTRA_PROBLEM_LISTS=../exclude.txt;OPTIONS=-l”


but it was a surprise that I needed the .. because the path was 
evaluated relative to the make subdirectory.


Is this fixable?


Re: xattr: Permission denied: build/macosx-aarch64-server-release/jdk/conf/management/jmxremote.password.template

2023-06-26 Thread erik . joelsson

Hello Vitaly,

This could be a permissions problem with the terminal application you 
are using. This seems like a common issue if you use something other 
than the default Terminal application. If so you need to give that 
application permissions to run "developer tools". It could also be some 
anti-virus, if you have that installed, that is flagging the file and 
preventing you from accessing it.


/Erik

On 6/23/23 12:54, Vitaly Provodin wrote:

Hi all

After migrating to a new macbook I become getting the following error

+ make images CONF=macosx-aarch64-server-release

Using exact match for CONF=macosx-aarch64-server-release (other 
matches are possible)


Building target 'images' in configuration 'macosx-aarch64-server-release'

Compiling up to 1 files for BUILD_TOOLS_HOTSPOT

Compiling up to 8 files for BUILD_TOOLS_LANGTOOLS

xattr: [Errno 13] Permission denied: 
‘~/workspace/openjdk/build/macosx-aarch64-server-release/jdk/conf/management/jmxremote.password.template'


make[3]: *** 
[~/workspace/openjdk/build/macosx-aarch64-server-release/jdk/conf/management/jmxremote.password.template] 
Error 1


make[3]: *** Deleting file 
`~/workspace/openjdk/build/macosx-aarch64-server-release/jdk/conf/management/jmxremote.password.template'


make[2]: *** [jdk.management.agent-copy] Error 2

make[2]: *** Waiting for unfinished jobs


ERROR: Build failed for target 'images' in configuration 
'macosx-aarch64-server-release' (exit code 2)



as far as I understand this file is being generated during make 
images - not clear why it was not generated in my case… On old macbook 
it works well.
I checked permissions for all dirs. I also launched make on a new 
clone - with no success…


configure works well. macOS 13.4.1, Xcode 14.3.1
Has anybody faced this issue? How it may be resolved?

Thanks in advance for any ideas
Vitaly

Re: RFR: 8294982: Implementation of Classfile API [v58]

2023-06-26 Thread Adam Sotona
On Fri, 23 Jun 2023 09:05:21 GMT, Andrey Turbanov  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   removed obsolete javadoc from implementation classes
>
> src/java.base/share/classes/jdk/internal/classfile/instruction/ConstantInstruction.java
>  line 139:
> 
>> 137: Util.checkKind(op, Opcode.Kind.CONSTANT);
>> 138: if (op != Opcode.BIPUSH && op != Opcode.SIPUSH)
>> 139: throw new IllegalArgumentException(String.format("Wrong 
>> opcode specified; found %s, expected BIPUSH or SIPUSH", op, op.kind()));
> 
> IDEA shows warning here.
> Too many arguments for format string (found: 2, expected: 1)
> 
> Seems op.kind() parameter is unused in the format string.
> 
> And the same issue in 
> `jdk.internal.classfile.instruction.ConstantInstruction#ofLoad`

I'll fix it, thank you.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/10982#discussion_r1241816908