Java Implementation

[ianturton]

This contains a java implementation of the OLC - it is based heavily on the Javascript implementation and passes all the tests in the csv files provided there.

Just run mvn install to test and release.

I've signed the CLA.

[drinckes]

Hi Ian - there was another Java implementation pull request that has been merged in. Could you see if there's any merging that makes sense?

[mprins]

Ian's pom file would definitely be nice to have/keep

[ianturton]

I'm not sure I like the fact the all the methods return an Object that I have to call .getCode() on - seems redundant to me.
I don't like the CodeArea constructor (x,y,w,h) rather than (x1,y1,x2,y2) as it isn't intuitive or geographically sound.
Finally I saw the comment about rounding error from using doubles but I haven't seen any evidence for this so it's possible the overhead of using BigDecimals is unnecessary.

Functionally the two versions are compatible - so I could move the existing code around to make it work in Maven and probably keep my test class which uses the csv files rather than hard coding the test values.

[drinckes]

Now I've had a chance to look more closely, there are quite a lot of things I like about yours. The pom file will be useful because I want to set up build integration with travis-ci.org, so any pull request or push will trigger the tests. I also like your structure more (objects with static methods operating on them, rather than one big object).
I would ask that you use the existing test data files (in /test_data) if possible so tests can be added in one place if necessary.
But I'm ok if you do a fairly aggressive merge :-)

[drinckes]

I'll have some more comments tomorrow.

[jirisemecky]

Hi Ian,

I like the maven integration. To add some background - for the implementation, I used a different approach than you did - I wasn't looking at the JavaScript version and only followed the textual spec. I think this "double implementation" is good for catching possible bugs and not copying them over. I was actually able to catch inconsistencies between the test data and the spec.

I agree with your concern about the the intuitiveness of arguments of the CodeArea. These are just internal fields and "user" of the class doesn't see them and alway access them through the getters. But we can definitely change them to be the rectangle sides.

I like your idea of making the encode() methods return String directly in case this is what you want. Now they are there only to stick to the spec and just call the constructor.
However, I think the encapsulation in the OpenLocationCode is an advantage. If you only have Strings, you can never trust it and you always have to do the validity checks (which is an expensive operation). In my implementation the OpenLocationCode is actually just a glorified String, but guaranties to be a valid code, so you are sure all the operations pass on it.

Be careful about the statements about doubles, I run into this bug (the evidence) during implementation therefor I went for the BigDecimal. Floating points in java are tricky in this extend and they might not always add up correctly and in this case it matters if it's on the border of an rectangle. You can sometimes "hide" the problems on by shuffling the operant order but it is a time bomb. Your usage of the TOLERANCE constant suggest that you're just hiding the double problems. OLC doesn't limit the precision per spec, so this will hit you on some level.

For the tests, I also use the CSVs but I didn't want to copy/paste them for maintenance reasons, so I just refer to the files in test_data directory. Optimally, all the implementations should refer to the same golden test set.

[drinckes]

My preference would be for Ian's version (sorry Jiri) due to it more closely matching the JS implementation. Jiri did mention a good point to me about the CodeArea object, that it is four arbitrary values and doesn't necessarily match an OLC box, but since the JS has the same issue I'm ok to live with it, and consider that issue as part of a new API at some later date.

Ian, could you please update when you're good to go (use the test_data directory files, remove the existing Java classes, use BigDecimal)?

[drinckes]

Actually - Jiri and Ian - can you collaborate on this? I'm coming around to a more OO view of implementations, where the class initialiser can be called with the arguments of encode, decode, and recover_nearest so those methods don't actually need to be exposed.

Maybe work on a fork and then send it back as a pull request when you agree?

[drinckes]

I'm going to close this request since the existing Java implementation works and nobody's responded on this for months.