Replace guava with native java 8 usage

[hazendaz]

Upon going to java 8 as minimum required java version in waffle 2.0.0, look at replacing guava with native usage of java 8 where possible, if not everywhere.

[bmaehr]

There are two things in this request:

• Remove guava: IMHO it is a NO-GO to use such a lib like guava in a lib like waffle just for some syntactic sugar. We have a web application with spring, hibernate, jsf, web services and some document generation and it has about 100 MB of libs just because many libs add not really need dependencies. I had a quick look at waffle-jna and I think it would be easy to remove all guava dependencies because they are not really needed. And then a 2.5 MB lib is not needed anymore.
• Require java8: Is there really a good reason why to request a java version higher than 1.5? Waffle is used in enterprise applications and such applications should live for more than 10 years. Especially older application servers doesn't support java8 and in an enterprise application the application server defines the java version, not a helper lib like waffle. A good reason for requesting a higher java version IMHO would be support for the upcoming java jigsaw, but this is not included into java 8. But syntactic sugar like lambda expressions are IMHO no reason for for requiring such a high java version.

[dblock]

I have introduced guava into Waffle around 1.4, in 2011, curious to hear what a replacement for a fast cache-like dictionary would be other than rolling out your own?

[bmaehr]

I stumbled about this thread because I tried to eliminate guava from my web application. I don't know how long it have been there.
I have been looking at the imports of the source-files of waffle-jna and didn't see an any kind of cache.
But even if some kind of cache is needed and guava offeres an already implemented solution IMHO everything that can be implemented with one or two classes on the own should be done in favoure of adding a dependency.

[hazendaz]

Guava is used all over enterprise apps and even in EE solutions (jersey). Its definately needed and not as syntactic sugar. Its also in top 100 dependencies used. In fact its #3. Im just guessing but i bet your stack has a lot of apache commons libraries. And that is the alternative. We could be using cache on our own, reinvent commons collections and commons codec to name a few. Not quite sure on the benefit it would otherwise provide to do so. Guava is for all practical matters slowly over time being incorporated directly into java with roughly 50% in java 8.

That leads to my original java 8 as appropiate time to remove guava if we find no more need for it.

As for java version, its shocking if any enterprise is still using java 5. At that level security is basically ignored. And after all waffle is a security solution. Most enterprises are actually at java 6 if not 7 at this point. Various usage stats are around suggesting this. Our jump to java 7 did result in a significant drop in older java 6 usage of waffle. We do still have a java 6 branch but its been a year now since the jump.

Ill take a quick look again at our current guava usage. If there is built in support in java 7 i will switch it. If that still leaves us with a need ill let that be known. However i think that will just leave us in the same position at this time.

[dblock]

Guava is used here first. We need a thread-safe store with expiration (a timeout after which items expire).

[bmaehr]

Ok, I understand your opinion about guava. It seams to be more used than I expected. I have never used it and never needed it and was shocked about it's size.

Just to make clear: I don't think that it is good to use Java 1.5 nowadays and I'm also using Java 1.7, but I see no new features in 1.7 to break compatibly to 1.5. And just because it is a security lib, it important to keep it up to date even it is not possible to update the java version.

[hazendaz]

We are using a lot of java 7 which does break backwards compatabiity (diamond operator, try with resources, new classes). I just raised PR #362 which is using even more including bits of java 8 for the tomcat 9 module. And then there are the libraries we support like tomcat 8+ which only work on java 7+. The few pieces remaining outside of core waffle-jna we support are on deprecation road (spring 3, tomcat 6, tomcat 7 (will be soon enough!)) so java 6 support isn't necessary anymore. As always, one can run older versions which are all available in maven central with ease. There is a 1.7.x branch here that is java 6 if needed.

Guava is big (2.2mb) as it replaces the bulk of apache commons with more fluent and modern api. Google provides guava and uses it through their internal projects. Everything in guava is or has been migrating into the core java code for some time. I think other pieces have migrated elsewhere depending on the use-case.

It's definitely worth taking a look at guava here

To show the significance of guava a report out of github showing top 100 libraries was produced which you can read about here

OK - so now after PR #362, what is left with guava in waffle.

• One use of Files class (we can write code for this although it will be a lot more than a one liner!)
• Many uses of joiner class (this is part of jdk8 and we could easily write a method now for it)
• Caching - one possibility is to use 'cache2k'. I've got it stubbed out. It brings in two libraries on it's own (api and core) for a total of 303k size. It's beta though and unstable but much faster than a lot of others. I'm currently stuck trying to figure out the caching size as their seemingly only method at the moment is marked as broken.

If we can resolve those, we can drop guava.

[hazendaz]

One additional thing I should point out. With guava usage only, we had a stable consistent use of Base64 class which ultimately is part of jdk8 and not some back seat class hidden in restricted areas of oracle's jdk. With PR #362, the solution is highly inconsistent. For pieces where I have no option, I'm picking up jaxb code which shipped with java 6. Spring's wasn't very pretty after I initially put that in so dropped that to jaxb as well as that was cleaner. Tomcat was 50/50. Encode is ok, decode wasn't very good in tomcat 6. Tomcat 7 plus was much better and closer to what ultimately is in jdk 8. And hence this is why guava was useful. However, I can live with the variations. It's still better than the original code of us doing the exact same thing :)

[dblock]

My 0.02c is that we should leave guava alone until moving to Java 8.

[hazendaz]

I'll shelve the PR for the time being.

[ben-manes]

fyi, Caffeine is a Java 8 rewrite of Guava's cache. A migration is usually a few import changes, a different builder name (to avoid confusion), and a few simplifications to be lambda friendly.

[hazendaz]

@ben-manes If you have some time and can get the caching working, please feel free to raise a pull request replacing guava usage of cache in waffle along with raising to java 8. While I'll probably let that sit for a bit against master and might need a rebase later on, I plan to be bringing waffle to java 8 over next few months so definitely would be great to deal with that whenever ;)

[ben-manes]

The PR does not remove Guava or convert the code's style throughout (e.g. lambdas, streams). Using Guava in JDK8 is fine and idioms are too stylistic to broadly change.

The usages of Guava are: BaseEncoding (=> Base64), Joiner (~ stream, but ugly), Files (=> rewrite to NIO's Path). All are pretty small so doable, but perhaps a limited benefit.

[hazendaz]

@ben-manes I fully agree removing guava overall might be of limited value. This was more exploritory by request for lack of understanding how much guava is everywhere. That said, I'll change only the clear cut clean items to change and if guava remains so be it. These days I don't think I have any project that is completely free of guava so I'm not bothered by it and in fact like it. What Java camp did with Joiner disturbs me a bit. It was so much cleaner with guava. Same goes with what was done with joda-time team. I forget at the moment our full extent of usage but for now will just start dropping all deprecated items (tomcat 6 / spring 3) and go from there. I'll fix travis build in a few and I got you added to change log as well. Again thanks for being so quick!

[ben-manes]

Actually I think I got it mixed up, the Joiner alternative is fine looking but Splitter alternative is much worse. I do find java.time more confusing than joda. It's all much better than the logger debacle so I think they did a good job.

[hazendaz]

Reopening as this only closed out issue with caching. Will keep open until we can access final guava removal if possible.

[hazendaz]

We only have remaining to rewrite one File.write over to jdk8 then guava can be removed.

[ben-manes]

You can use nio.Files#write(path, str, charset) which is jdk7.

[hazendaz]

Thanks. I had looked at that but was getting very late. I wasn't sure how to test or convert. Got it squared away now. Guava is now no longer part of waffle.

Closed via #491