> Then I wonder if we should consider the size of a function with
> assertions removed when making JIT inline decisions? Since
> at JIT time I presume whether assertions are turned on or off
> is known – or is it too inefficient to calculate this metric?
Hi Andrew,
This is also a good suggestion
> This makes me wonder if it is worth introducing a compiler flag
> that would omit assert statements from the compiled bytecode
> for this scenario.
Hi Andrew,
Maybe the first one of this FAQ could answer your question:
https://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html
Hi Pavel,
> There have been studies looking into correlation between assertion density
> and fault/defect density. Here's one such study: "Assessing the Relationship
> between Software Assertions and Code Quality: An Empirical Investigation".
Thanks and yes! And there are also some more recent st
Hi John,
> I believe this can be partially alleviated by extracting the asserts to a
> method (partially as the call also increases method size). The optimizer
> seems to be smart enough to not call the method if it does nothing
> (when ea is disabled).
Thanks a lot! Good to know that. I'm not su
Hi Alan,
> You will find places in the JDK code, esp. in performance critical code,
> where assertions are commented out. The reason is that asserts, even if
> disabled, increase the method size and can impact inlining by the
> compiler at run-time. So while useful when debugging some issue in suc
Regards,
Daohan
From: liangchenb...@gmail.com
Sent: Sunday, July 16, 2023 7:09
To: Daohan Qu
Cc: core-libs-dev@openjdk.org
Subject: Re: Questions about using `assert` in Java
Hi Daohan,
assert keyword is safely usable within production code. I don't think it
&type=code
[2] https://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html
Regards,
Daohan Qu
On Fri, 23 Jun 2023 07:44:31 GMT, Daohan Qu wrote:
> Similar to #11745 , this patch adds more information for
> `NoSuchFieldException` thrown by `getField()` or `getDeclaredField()` of
> `java.lang.Class`. The error message changes like the example below:
> 1. For `getField()`
>
On Fri, 23 Jun 2023 09:30:43 GMT, Chen Liang wrote:
> I think a message like 'Class.field' is better, more consistent with
> methodToString's behavior.
Hi, @liach, thanks for your suggestions, this `Class.field` format is indeed
more succinct. But I'm following this format (`NoSuchFieldError`
Similar to #11745 , this patch adds more information for `NoSuchFieldException`
thrown by `getField()` or `getDeclaredField()` of `java.lang.Class`. The error
message changes like the example below:
1. For `getField()`
Before this change:
Exception in thread "main" java.lang.NoSuchFieldExceptio
11 matches
Mail list logo