Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed support for keys that look like numbers longer than an int. #568

Merged
merged 1 commit into from
Jan 9, 2019

Conversation

michalmela
Copy link
Contributor

Previously such config keys would still be parsed with
Integer#parseInt, resulting in a NumberFormatException.
Now the number-like keys are parsed to a Long (no measures made but
performance expected hit expected to be negligible) if their numbers of
digits is shorter than the number of digits in Long.MAX_VALUE.

One could have also tried to parse numbers exactly up to Long.MAX_VALUE,
but added usability doesn't seem to match the required complexity - in
fact, one could also argue that the current loop-based checking if a key
looks like a number is a bit of an overkill, but I didn't want to dig into
the original reason for why a regexp was not used, instead focusing on
fixing an apparent bug in the most straightforward way.

@michalmela
Copy link
Contributor Author

It was only after I made the pull request that I realized there is already an issue and a pull request open with regard to the issue I tried to solve here ( #557 ).

While I greatly appreciate the effort put in the other pull request (as it definitely develops the library's extensibility in the right way), I wonder if my fix couldn't be used for a bugfix release? As I believe the NumberFormatException thrown on long number keys is definitely a bug, I tried to fix the bug with the minimal amount of changes in the behavior of the key parser/ordering.

Therefore, I believe my fix is rather straightforward and could be merged for a bugfix release much sooner, with little need for further discussion. The final solution, as developed in the other pull request/issue, would in time replace my fix, while not leaving a glaring bug in the library in the meantime.

What do you think?

@havocp
Copy link
Collaborator

havocp commented Dec 6, 2018

Sorry for the slow reply; I agree with separating out just the bugfix, but maybe using BigInteger is a nicer solution than checking the number of digits (so that we still sort things as numbers even when large)?

@michalmela
Copy link
Contributor Author

Done. Now the pull request contains basically the same thing as in @mmolimar 's #557 minus the comparator being configurable (which I guess is why that pull request is still being discussed) plus a tiny improvement to the unit tests. Hopefully we can get a bugfix release soon then :)

@michalmela
Copy link
Contributor Author

I am not sure why did the Travis CI build fail, the only error message I see is "We couldn't find the repository lightbend/config" but I don't know if it's me not having some permissions to see the build or is it an actual configuration problem?

@havocp
Copy link
Collaborator

havocp commented Jan 4, 2019

Maybe a transient travis bug?

Anyway the error is

info] Set current project to config-root (in build file:/home/travis/build/lightbend/config/)
[error] java.lang.RuntimeException: Switch failed: no subprojects list "2.12.8" (or compatible version) in crossScalaVersions setting.
[error] If you want to force it regardless, call ++ 2.12.8!

@michalmela
Copy link
Contributor Author

OK, now I see the Travis logs as well! But it's the same error as in #602 – an unrelated issue with the Scala version used by Travis CI (2.12.8, as seen in the error message) vs the one defined in SBT for the project and (I guess) the recent release of Scala 2.12.8.

I guess it should be an easy fix by either specifying the Scala version to use in the .travis.yml or bumping the project Scala version to 2.12.8. I don't know, however, if it should be done within this pull request (will certainly look counter-intuitive to anyone analyzing the git history in the future) and also which of these paths would you rather see through?

@havocp
Copy link
Collaborator

havocp commented Jan 4, 2019

I'm not sure of the right fix but agree it should be in its own PR. Bumping the project version of scala seems like it would keep the build faster (not need to download another one), but it could have some unforeseen complexity to it, I don't know.

if (Character.isDigit(c))
continue;
else
if (!Character.isDigit(c))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

heh, good cleanup

michalmela pushed a commit to michalmela/config that referenced this pull request Jan 5, 2019
…ngs fixed

As discussed in lightbend#568 .

`lift-json` was also bumped as there was no longer any suitable version for Scala 2.12.x.

Also fixed compiler warnings (e.g. _eta expansion of parameterless methods is deprecated_) as well as some rarther non-controversial IDE warnings (e.g. redundant semicolons and such).
michalmela pushed a commit to michalmela/config that referenced this pull request Jan 7, 2019
…ngs fixed

As discussed in lightbend#568 .

`lift-json` was also bumped as there was no longer any suitable version for Scala 2.12.x.

Also fixed compiler warnings (e.g. _eta expansion of parameterless methods is deprecated_) as well as some rarther non-controversial IDE warnings (e.g. redundant semicolons and such).
Previously such config keys would still be parsed with
`Integer#parseInt` for the sake of sorting, resulting in a `NumberFormatException`.
Now the keys consisting of digits only are parsed to a `BigInteger` and
compared as such.

This addresses the following issues:
lightbend#604
lightbend#541
@michalmela
Copy link
Contributor Author

Travis is finally at peace :)

@havocp havocp merged commit aa0c42b into lightbend:master Jan 9, 2019
@havocp
Copy link
Collaborator

havocp commented Jan 9, 2019

🎉 thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants