The plugin uses deprecated guava methods

[afdia]

The plugin uses the method Objects.toStringHelper which will be removed in June 2016 according to the Guava JavaDoc

It should probably be replaced with MoreObjects.toStringHelper

[danielwegener]

Hi @afdia!
Replacing Objects with MoreObjects would cause a broken build for everyone with guava < 18.0 (see https://github.com/google/guava/blob/master/guava/src/com/google/common/base/MoreObjects.java). I'd suggest we add a legacy option that leaves the behaviour as it is now and change the default behaviour to:

• building equals using java.util.Objects.deepEquals(...)
• building hashCode using java.util.Objects.hash(...)
• building toString using com.google.common.base.MoreObjects(...)

What do you think?

[afdia]

Sounds good to me. I guess you are talking about adding an alternative trigger such as:

-Xguava uses these 3 methods in the new version
-Xguava-legacy or -Xguava-jdk6 uses the old methods
right?

[afdia]

After thinking again about the issue, you have already mentioned that there are methods in Java for equals and hashCode.
What do you think about using StringJoiner instead of MoreObjects (see http://stackoverflow.com/a/32691545) to generate the toString() method? Especially the static String.join() method looks very concise (see http://www.mscharhag.com/java/java-8-string-join)
This would remove the Guava runtime dependency completely, right?

By the way, do you plan to release a new version to make the fix for #5 available? Then I would be able to switch back to this plugin instead of using jaxb2-basics ;)

[danielwegener]

Hi @afdia!
Sounds reasonable - well the title xjc-guava-plugin would be a bit misleading then :)

[danielwegener]

Released xjc-guava-plugin 0.3.2

[afdia]

Hi
Thanks for the release!

The name wouldn't really fit anymore, but it's good that the Java API finally offers these methods to make Guava obsolete, at least for this specific use case :)

Perhaps the name could be changed to xjc-hashequalstring-plugin, or something like that which reflects what it generates.
If forking and/or renaming is too cumbersome, it could keep the plugin name (also for backwards compatibility as you suggested before) and simply use a different trigger such as -Xjava8 or -Xjdk8 (which reflects the change that it uses the Java8 API instead of guava).

[maurizio-lattuada]

Hi @danielwegener ,
do you plan any release to fix this issue?
I'm using this plugin with cxf-codegen-plugin (generate classes from a WSDL) and is the only one not generating duplicated equals and toString :)

BTW, the proposal of @afdia sounds honestly good also to me.

Thanks for this wonderful plugin!

[danielwegener]

Hey guys. Unfortunately I currently do not have the capacity to continue on this. To be honest, If we plan to drop guava anyway, I'd just fork this repo, refactor it to plain Java8 and release it as its own plugin and leave this one as it is (same or more permissive license would be nice though).

I also do currently have no real project use for this plugin so someone with a actual need would be a better driver. I'd be happy to help out with reviews or questions but I do not feel very optimistic about having the time to actively push this further.