Cleanup non-Java libraries

[shathor]

Mainly removed non-Java libraries (or just with trivial, bad or non-idomatic Java-clients) but also dead links:

• Apache Mesos: C++
• jasync-sql: Kotlin
• Orbit: Kotlin
• OkHttp: Kotlin (rewrite from Java, see: Upgrade OkHttp 3 to Kotlin and call it OkHttp 4 square/okhttp#4723)
• Play WS: Scala
• Apache Spark: Scala (has a Java client, but is really bad)
• Deepdive: Shell, Scala, no Java
• H2O: C++, Scala, no Java, commercial only free trial
• Synapses: Scala
• Lagom: Scala
• LeakCanary: Kotlin
• Kamon: Scala
• Datadog: Go, commercial only free trial
• Prometheus: Go, changed link to Java Client project
• Sematext: commercial only free trial
• Beagle: Clojure
• Lingua: Kotlin
• AkkaGRPC: Scala
• Finagle: Scala
• Javalin: Kotlin, just some Java interfaces
• Vault: Go, no Java
• Grails: Groovy, no Java
• Seata: non-secure link, changed link to github
• Geotoolkit.org: link contains next to no information, changed link to github
• Koloboke: dead link, changed link to github
• Jtwig: link only says that it's not maintained, changed link to github

Not removed, but could be discussed (or marked):

• jlink.online: Go, but is a tool anyway
• Apache Thrift: C++ with Java client
• Protobuf: C++ with Java client
• Wire: Kotlin with Java API
• Akka: Scala with Java client
• Play: Scala with Java client
• flatbuffers: C++ with Java client
• Cloudsmith: seems to be only free trial not free tier
• Jtwig: Says it's not maintained anymore: http://www.jtwig.org/

[jasonab]

I can't speak to the rest, but OkHttp is an excellent HTTP client in Java, regardless of the fact that it's written in Kotlin.

[shathor]

With respect to OkHttp my opinion is very different. It's harder to properly debug in Java, documentation is not Java centric, API is not respecting Java devs needs, has dependencies on other Kotlin stuff like the standard library and there are loads of good Java alternatives around. It's simply not a Java library anymore. You should be able to find it in awesome-kotlin or awesome-jvm but not awesome-java.

[jasonab]

What Java alternatives do you like? That's one thing I wish this repo had, was rankings or recommendations of some sort. I know these libraries are all "awesome" but it would be nice to pick out one or two in each list as "excellent."

[shathor]

Java 11's HttpClient is nice (add Methanol if you need it) and also the Apache HttpComponents (not on the list so far).
If I'm developing in Spring I use its RestTemplate.

[lskillen]

@shathor @akullpp @cloudsmith-io has a free tier; the pricing page just doesn't make that obvious (but the FAQ below does mention it). The team is working out the best way to display it. Basically if you don't pay, and that's fine, you default to free. Plus open-source is always free. :)

[shathor]

@lskillen Nice. I wasn't sure so I just left it as is.

[heldev]

I would vote to keep this list user-centric (what benefits developers who do Java) instead of switching to a portfolio mode (these things were made with Java)

Examples:
Spark - written in Scala and Java is not a 1st-class citizen there, but if you need to work with it from Java it gives you this option, so it's unique and useful

Apache Thrift - I think it's a tool so implementation details aren't important to me as a Java developer

Finagle - "provides both Scala and Java idiomatic APIs", but the real question I would ask is "How useful it is to a Java developer as a final product or as a basis for another Java project"

[shathor]

@heldev then this list might aswell be merged with awesome-jvm. Heck, you could even throw in some JavaScript frontend framework and C++ code that you access through GraalVM or JNI for performance reason (e.g. PDFium). "Useful for Java developers" as a criteria is just too subjective and vague.

Apache Spark is a good example of this. It's Java API is so bad from a Java developer point of view if you asked me. It's unnatural and cumbersome. So frustrating to work with that I was about to shake my monitor yelling what they were thinking.
The other argument is that there is always friction when integrating a library or framework written in another language. Be it documentation, debugging, build, non-idiomatic second rate API, updating etc.

Also most of the things I removed have a perfectly fine alternative in Java (Lagom, Grails, OkHttp, Javalin,...), it's added value is questionable or it's very niche.

[heldev]

Also most of the things I removed have a perfectly fine alternative in Java

I do agree that you have valid concerns and some things are good candidates for removal, I mostly wanted to point out that would be great to focus on pragmatism instead of formalities. I think if it was possible to remove subjectivity this list would be replaced with a simple query (e.g. where language = 'Java' and stars ...)

[pablogrisafi1975]

With respect to OkHttp my opinion is very different. It's harder to properly debug in Java, documentation is not Java centric, API is not respecting Java devs needs, has dependencies on other Kotlin stuff like the standard library and there are loads of good Java alternatives around. It's simply not a Java library anymore. You should be able to find it in awesome-kotlin or awesome-jvm but not awesome-java.

Totally agree should be removed. It was an awesome library and it is probably still awesome to use if you are using Kotlin, but using it form Java has becoming annoying since the Kotlin rewrite.

[tr7zw]

I'll join the others in saying this is a "list of awesome Java frameworks, libraries and software". Projects that can be added via Maven repo and then used in Java as a framework/library fit this list. It doesn't matter in what language the project is written or rather it uses JNI. Especially projects like OKHttp that are clearly Java libraries should stay on this list. Also it shouldn't matter how "Java centric" the documentation/API is, since this is a list of options, not a list of "This is the best Json parser, this is the best HTTP client etc".

[akullpp]

I agree with most of the changes, there are other awesome lists for JVM languages that are better suited for these kind of frameworks. Thanks for your work!

[jodastephen]

I came back to the awesome list today and was stunned to find OkHttp not on the list, which led me here. I have to say that removing it was a mistake. I agree that the language a library is written in should be a factor in consideration, but it is far from the most significant one. In addition, Scala and Clojure libraries are likely to be very different from Java ones because of the nature of those languages - Kotlin is much closer to Java in feel, which results in libraries that tend to be less problematic to use from Java. However, none of the other items removed jump out as being as important to keep as OkHttp. As a reminder, here are the 4 official criteria:

(a) widely recommended, regardless of personal opinion
(b) highly discussed in the community due to its innovative nature
(c) absolutely unique in its approach and function
(d) a niche product that fills a gap

I think OkHttp meets those criteria - it has 38,000 stars on GitHub!. It is still the HTTP library I would recommend to Java devs - Java 11 client is low level, and in my opinion the API of OkHttp is better designed and more modern than that of Apache HTTP components. Significantly, I also have faith in the OkHttp team's ability and maintenance, which is very important for an HTTP library.

If there is discomfort about the Kotlin aspect, that should be addressed using brackets, like the license comments "(LGPL-3.0-only)", in this case perhaps "(built using Kotlin)". To summarize, I wish OkHttp was still written in Java, but I still believe it is the most awesome HTTP library widely used by Java devs, and as such should be on the list.

[pablogrisafi1975]

Unrelated to the issue, @akullpp , your list has become significant enough to deserve Colebourne's criticism. What else do yo want? A pony?

I still think OkHttp should remain deleted, however. Include a Kotlin library in a java project and suddenly you have the full Kotlin library poping up everty time you hit ctrl-space, and every problem @shathor has explained