Gary Gregory
Gary Gregory
I'll try to take a look this week...
Not sure about the impact here of changing the behavior... needs a bit more study...
Not a fan unless `testIsParsable` is updated to actually prove that something is parsable or not; for example, update: ``` assertTrue( NumberUtils.isParsable("64") ); ``` to ``` assertTrue( NumberUtils.isParsable("64") ); Integer.parseInt("64");...
> > @garydgregory Some of your comments related to code format could be resolved by defining IDE specific code formatter. WDYT. > > What @melloware suggested is much more appealing...
I am glad that you have some flexibility here and for the civil discourse as well :-) My main concern is for compatibility so throwing an exception in the place...
I think we should pass on these types of changes. It makes debugging and maintenance harder IMO. The tests are harder to comprehend. -1 from me.
The current style we use is to have one method fail fast, if the original author of that test wanted to have one potential failure for different parts of that...
A parameterized test seems like the way to go here instead of anything "parallel" which if truly parallel is very bad as it lacks determinism. We want reproducible builds.
I do not understand what this PR is about and you'd be correct in assuming that I did not parse out the new code in my head or run it...
This will break binary compatibility and I don't see releasing out of 1.x anyway as we are resource-constrained and want to get 2.0 out. A general comment: This PR adds...