Integrated: 8233269: Improve handling of JAVA_ARGS

2022-06-01 Thread Adam Sotona
On Wed, 1 Jun 2022 13:52:46 GMT, Adam Sotona wrote: > LauncherCommon.gmk is unfortunately defining JAVA_ARGS with `-J-ms8m` option > for all JDK launchers, including java launcher. > JAVA_ARGS should not be defined for java launcher (in contrast to the other > JDK launchers), and

RFR: 8233269: Improve handling of JAVA_ARGS

2022-06-01 Thread Adam Sotona
LauncherCommon.gmk is unfortunately defining JAVA_ARGS with `-J-ms8m` option for all JDK launchers, including java launcher. JAVA_ARGS should not be defined for java launcher (in contrast to the other JDK launchers), and the command line option `-J-ms8m` is obsolete for java launcher. Proposed

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v10]

2022-05-23 Thread Adam Sotona
JDK are already addressed in a separate > umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with two additional commits since the last revision: - re-enabled lossy-conversion javac warnings in JDK Build Too

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v9]

2022-05-23 Thread Adam Sotona
JDK are already addressed in a separate > umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'openjdk:maste

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v8]

2022-05-16 Thread Adam Sotona
JDK are already addressed in a separate > umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: 8244681: Add a warning for possibly lossy conversion

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v7]

2022-05-16 Thread Adam Sotona
JDK are already addressed in a separate > umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'op

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v6]

2022-05-13 Thread Adam Sotona
JDK are already addressed in a separate > umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - lossy conversions addressed in jav

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v5]

2022-05-11 Thread Adam Sotona
JDK are already addressed in a separate > umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: enabled lossy-conversions warnings for jdk.jfr and jdk.manageme

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3]

2022-05-11 Thread Adam Sotona
On Wed, 11 May 2022 13:31:16 GMT, Roger Riggs wrote: >> Thanks for quick reaction. >> I'll keep my eyes on this race of patches and update this pull request >> accordingly or create a new PR. > > I put out a PR for java.base, but thought I'd wait until the javac fixe were > pushed before integr

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v4]

2022-05-11 Thread Adam Sotona
JDK are already addressed in a separate > umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3]

2022-05-11 Thread Adam Sotona
On Wed, 11 May 2022 13:10:10 GMT, Magnus Ihse Bursie wrote: >> I agree, but if it doesn't happen, I can follow up with a separate PR where >> I remove the disablement. > > That's good to know. I think the tricky part is mostly about keeping track of > all these disabled warnings, so they are no

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3]

2022-05-11 Thread Adam Sotona
JDK are already addressed in a separate > umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: 8244681: Add a warning for possibly lossy conversion in

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v2]

2022-05-10 Thread Adam Sotona
JDK are already addressed in a separate > umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: 8244681: Add a warning for possibly lossy conversion in compound

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments

2022-05-10 Thread Adam Sotona
On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to > javac to warn about type casts in compound assignments with possible lossy > conversions. > > The new lint warning is shown if the type of the rig

RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments

2022-05-09 Thread Adam Sotona
Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the t

RFR: 8264485: build.tools.depend.Depend.toString(byte[]) creates malformed hex strings

2021-11-30 Thread Adam Sotona
make/jdk/src/classes/build/tools/depend/Depend.java method toString(byte[]) constructs hex string out of the given byte array. Actual implementation is using custom conversion code, which does not pad byte values <16 with leading zero. Resulting hex string is invalid and for example sequence of b