Thought I'd share something I discovered about Json comparison. This simple line also works:

  return jsonObject1.toMap().equals(jsonObject2.equals);

because JsonObject uses HashMap internally which supports equals(). The downside is it would be slower because toMap() creates a copy.

Btw, downloaded java-commons as Maven dependency from JitPack: https://jitpack.io/#blobcity/java-commons

Yes this also works. We were using this for a while until we landed up with very large JSON's. .toMap() is very expensive and takes significantly longer to execute on large JSON's.

./gradlew dependencies will not tell you which versions play nice together.

Concrete example:

I dealt with a dependency conflict between two different packages that wanted different versions of Apache Commons. Both of them only claimed that they wanted "greater than or equal to X version." This wasn't actually true, though, because Apache Commons had removed some features and added some features, so the real requirements were

  Package A wants Commons >= X and < Y
  Package B Commons >= Z

where Z > Y.

Sorting that out meant manually doing exactly what this Depends package does - poking around with different versions and using the missing method exceptions and some other research to figure out the exact nature of the conflict, so that I could pin their versions and set up appropriate package relocation rules.

This tool would not just do that faster, but also more reliably - by doing it manually, I was only able to verify that I had resolved any issues with the code I actually exercised. A gap in test coverage would leave me exposed to run-time errors in production.

If you don't need full SQL then you can use embedded key-value stores: - RocksDB - MapDB

Have you considered adding Stack Exchange or Quora integration and then using reputation from those sources? Might help in avoiding bots/trolls

I don't think they offer an API for reputation exporting, do they?

Also, our reputation system, the thanks count, is based more around HOW you interact with others, so if you are polite, open to have your claim changed, etc. It's a general measure of how nice it is to work with you and how good your contributions are.

Contrary to SO and Q, we are not a place where you, solipsistically add an atomic answer, but because you are working with others in a collaborative reasoning system, will have to edit your claims, comment on others etc.

The article says it is a 2 year old startup but its more like 3-4. Incorporated in Sep 2014

I believe "reproducible build" is a more appropriate term.

Unfortunately its quite difficult to get a fully reproducible build with Maven as the post points out. Even if you manage to replicate the build environment and settings, Maven produced binaries will be slightly different on each run. File timestamps are saved in jar files so they change on every build.

It recommends using the Maven wrapper to fix Maven's version.

Presumably Kafka Streams KTables

I've found that Project Lombok solves this problem for me. Simply add a @Data or @Value annotation and it will generate getters/setters/hashCode/toString etc. https://projectlombok.org/features/Value.html

I started with Lombok but found that you're effectivly writing a different language from Java anyway - all your tools (IDEs, code coverage, binary compatibility checking, build infrastructure... ) need to support it. So it's just as much effort as Scala, and gives you a lot less in return.

From Oracle Security Alert for CVE-2016-0636

  This vulnerability applies to Java deployments, typically in clients running 
  sandboxed Java Web Start applications or sandboxed Java 
  applets, that load and run untrusted code (e.g., code that 
  comes from the internet) and rely on the Java sandbox for 
  security. 

  This vulnerability does not apply to Java deployments, 
  typically in servers, that load and run only trusted code 
  (e.g., code installed by an administrator).

[1] http://www.oracle.com/technetwork/topics/security/alert-cve-...