Thank you,
Adam
> On 28 Feb 2020, at 12:57, Lance Andersen wrote:
>
> I think this looks OK. I did a search and did not find any usages so I
> suspect this should be safe to do.
>
> Best
> Lancee
>
>> On Feb 28, 2020, at 5:28 AM, Adam Sotona > <m
Hi,
I would like to ask for review of the attached patch removing dead code from
jar tool
Class files sun.tools.jar.Manifest and sun.tools.jar.SignatureFile appear to be
dead code and should be removed.
Build with the patch passes all Tier1, Tier2 and Tier3 tests.
Thank you,
Adam
-8230117.patch>
>>
>>> On Feb 28, 2020, at 12:00 PM, Lance Andersen
>> wrote:
>>>
>>> Here it is again
>>>
>>>> On Feb 28, 2020, at 11:07 AM, Sean Mullan
>> wrote:
>>>>
>>>> I think you forgot
On Mon, 17 May 2021 13:11:56 GMT, Adam Sotona wrote:
> Actual javap implementation reacts on corrupted TABLESWITCH or LOOKUPSWITCH
> bytecode instructions resulting to negative array allocation with
> NegativeArraySizeException, which is reported to user with stack trace and as
Actual javap implementation reacts on corrupted TABLESWITCH or LOOKUPSWITCH
bytecode instructions resulting to negative array allocation with
NegativeArraySizeException, which is reported to user with stack trace and as
serious internal error.
The fix in c.s.t.classfile.Instruction is checking
On Thu, 25 Feb 2021 13:01:30 GMT, Adam Sotona wrote:
> Please review javap fix to handle java.lang.IllegalStateException for classes
> with invalid Signature attribute.
> New test (T8260403) parsing class with invalid Signature attribute (as
> described in the bug) is included.
Hi Vicente,
thanks for the review.
May I ask you also to /sponsor this PR?
Thanks again,
Adam
On 25/02/2021, 16:39, "core-libs-dev on behalf of Vicente Romero"
wrote:
On Thu, 25 Feb 2021 13:01:30 GMT, Adam Sotona wrote:
> Please review javap
Please review javap fix to handle java.lang.IllegalStateException for classes
with invalid Signature attribute.
New test (T8260403) parsing class with invalid Signature attribute (as
described in the bug) is included.
Fix wraps java.lang.IllegalStateException, reports "Error: Invalid value for
On Mon, 14 Feb 2022 22:47:53 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>>
On Mon, 14 Feb 2022 22:47:53 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>>
On Wed, 23 Feb 2022 02:13:21 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>>
On Fri, 11 Feb 2022 18:31:57 GMT, Joe Darcy wrote:
> This is an early review of changes to better model JVM access flags, that is
> "modifiers" like public, protected, etc. but explicitly at a VM level.
>
> Language level modifiers and JVM level access flags are closely related, but
>
ic test case.
>
> Please review the patch or raise objections against declaration of
> jdk.compiler dependent on jdk.zipfs.
>
> Thanks,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
fix of LimitedImage te
### Problem description
Minimal jdk image created by jlink with the only jdk.compiler module and its
dependencies
fails to run java source launcher correctly (for example when --source N is
specified).
Failing source launcher is the only one expression of internal jdk.compiler
malfunction,
On Tue, 8 Jun 2021 16:53:38 GMT, Henry Jen wrote:
>> …d on macOS
>>
>> This patch simply round up the specified stack size to multiple of the
>> system page size.
>>
>> Test is trivial, simply run java with -Xss option against following code. On
>> MacOS, before the fix, running with
This is continuation of PR #4256
The patch simply rounds up the specified stack size to multiple of the system
page size, on systems where necessary.
The patch is based on the original PR/branch, with reflected remaining
recommendations.
Please review.
Thank you,
Adam
-
Commit
.
>
> Thank you,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
Updated Java mannpage
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8953/files
- new: https://git.openjdk.java.net/jdk/p
On Tue, 31 May 2022 13:28:30 GMT, David Holmes wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updated Java mannpage
>
> src/java.base/share/classes/sun/launcher/resources/launcher.pro
On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona wrote:
>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its
>> dependencies
>> fails to run java source launcher correctly (for example when --source N is
>>
in 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
On Tue, 31 May 2022 08:37:19 GMT, Adam Sotona wrote:
> This is continuation of PR #4256
>
> The patch simply rounds up the specified stack size to multiple of the system
> page size, on systems where necessary.
> The patch is based on the original PR/branch, with refl
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
in 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
in 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:master'
On Sun, 22 May 2022 17:04:30 GMT, Peter Levart wrote:
> > My humble opinion: if java.compiler needs jdk.zipfs for full
> > functionality
>
> Sorry, I wrongly assumed it was `java.compiler` (the library module), but
> this is about `jdk.compiler` (the tool)... Nevertheless, the same
On Wed, 18 May 2022 02:50:49 GMT, Jaikiran Pai wrote:
> Hello Adam, I don't have necessary knowledge of this area, so I don't know
> what approach would be preferred.
>
> But a couple of questions:
>
> * If we do decide to add the `jdk.zipfs` dependency to `jdk.compiler` module,
> do you
ion of jdk.compiler
> dependency on jdk.zipfs.
> Plus added specific test case.
>
> Please review the patch or raise objections against declaration of
> jdk.compiler dependent on jdk.zipfs.
>
> Thanks,
> Adam
Adam Sotona has updated the pull request increm
in 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 convers
in 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 'openjdk
On Wed, 25 May 2022 00:35:24 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>>
On Tue, 17 May 2022 12:47:25 GMT, Adam Sotona wrote:
> ### Problem description
> Minimal jdk image created by jlink with the only jdk.compiler module and its
> dependencies
> fails to run java source launcher correctly (for example when --source N is
> specified).
> Faili
in 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
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
in 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
On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs wrote:
>> PR#8599 8244681: proposes to add compiler warnings for possible lossy
>> conversions
>> From the CSR:
>>
>> "If the type of the right-hand operand of a compound assignment is not
>> assignment compatible with the type of the variable, a
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
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
in 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
in 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
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
40 matches
Mail list logo
