This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Hint for transformation to BigDecimal constants like BigDecimal.ZERO/BigDecimal.ONE/BigDecimal.TEN | ||
---|---|---|---|
Product: | java | Reporter: | markiewb |
Component: | Hints | Assignee: | Svata Dedic <sdedic> |
Status: | NEW --- | ||
Severity: | normal | ||
Priority: | P3 | ||
Version: | 7.4 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: |
Proposed patch incl. tests for java.hints
Patch v2 Updated patch |
Description
markiewb
2013-09-22 15:07:02 UTC
FYI: Fixed in 1.1.0 of the additional hints plugin https://github.com/markiewb/nb-additional-hints/issues/11 great ! Shouldn't the enhancement closed as resolved/fixed ? (In reply to Svata Dedic from comment #2) > great ! Shouldn't the enhancement closed as resolved/fixed ? @Svata: You may close it as wontfix (because this feature is already available as plugin) OR I could provide a patch so that the hint can get into the official NB sources What do you like? If you're willing to provide a patch, I'll be pleased to integrate it to 8.0 Created attachment 142697 [details] Proposed patch incl. tests for java.hints (In reply to Svata Dedic from comment #4) > If you're willing to provide a patch, I'll be pleased to integrate it to 8.0 Hi Svata, here's the patch. Please review. If you like to include some more hints from https://github.com/markiewb/nb-additional-hints please tell me. You even can contribute some experimental hints to the plugin itself. Best regards, Benno Ah thanks; a couple of ideas: * combine all BigDecimal constant hints into one. Reason: I can't think of a case I would like 0 to be replaced and not 10 (or any other JDK-defined constants) * the hint should check for Source >= 5, BigDec constants are @since 1.5 * ctors with BigInteger.ZERO|ONE|TEN could be also covered; not sure about the ctor with scale ... possibly for scale == 0 ? * the variants of 0s 1s etc except the most basic form could be replaced by $v, where ArithmeticUtilities evaluate $v expression to constant. Created attachment 142749 [details] Patch v2 (In reply to Svata Dedic from comment #6) > Ah thanks; a couple of ideas: > > * combine all BigDecimal constant hints into one. Reason: I can't think of a > case I would like 0 to be replaced and not 10 (or any other JDK-defined > constants) > > * the hint should check for Source >= 5, BigDec constants are @since 1.5 > > * the variants of 0s 1s etc except the most basic form could be replaced by > $v, where ArithmeticUtilities evaluate $v expression to constant. Fixed. Please review the new patch. > * ctors with BigInteger.ZERO|ONE|TEN could be also covered; not sure about > the ctor with scale ... possibly for scale == 0 ? Mmh. I do not know how to integrate this in the same hint. Suggestions? Or worth a new RFE? Created attachment 142802 [details]
Updated patch
Sorry, the changes to the original patch (after going through some rounds of optimization) were quite big. Here's what I think works better:
* String goes through constant evaluation (without resolving field refs, as it may decouple the BigDec value from the original constant)
* Strings are converted to their value to avoid .00
* pritimives are converted to double, it's faster than going through BigDecimal and .compareTo, since we have constants for integer values only
* ctors that use BigInteger constants with 0 scale are converted to BigDecimal constants. I didn't mess with combination like BigInteger 10 + scale 1 (= 1.0 = BigDecimal.ONE), sorry :)
[I've noticed an unrelated issue in ArithmeticUtilities, so only values that resolve constants are cached]
(In reply to Svata Dedic from comment #8) > Created attachment 142802 [details] > Updated patch > > Sorry, the changes to the original patch (after going through some rounds of > optimization) were quite big. Here's what I think works better: > > * String goes through constant evaluation (without resolving field refs, as > it may decouple the BigDec value from the original constant) > * Strings are converted to their value to avoid .00 > * pritimives are converted to double, it's faster than going through > BigDecimal and .compareTo, since we have constants for integer values only > * ctors that use BigInteger constants with 0 scale are converted to > BigDecimal constants. I didn't mess with combination like BigInteger 10 + > scale 1 (= 1.0 = BigDecimal.ONE), sorry :) > > [I've noticed an unrelated issue in ArithmeticUtilities, so only values that > resolve constants are cached] Oh. You covered some more cases I wasn't aware of. Nice. |