Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove Guava from missinglink-core #61

Merged
merged 4 commits into from
Oct 21, 2019
Merged

remove Guava from missinglink-core #61

merged 4 commits into from
Oct 21, 2019

Conversation

mattnworb
Copy link
Member

In the interest of having as few dependencies as possible in the core
module, this commit removes Guava from it.

Guava was only really used in three ways in the core module:

  1. Immutable collection types 2. Preconditions checks 3. Joiner for
    concatenating strings

I replaced 1 with a mix of Collection.singleton(), singletonList()
etc., along with vanilla ArrayList / HashMap usage. The classes generated
by AutoMatter for POJOs will make copies of any collections passed in, so I
skipped a lot of the usage of Guava's Immutable types for making copies of
collections before passing them into the generated POJOs.

Use of the Preconditions static methods to throw NullPointerExceptions or
IllegalArgumentExceptions I replaced with
java.util.Objects.checkNotNull() or vanilla if-else checks.

The plugin module still uses Guava; removing it from that module was out of
scope for this change (anyone using Missinglink in other build tools will
just depend on the core module).

Closes #60.

as this class depends on Guava's Joiner class and a future commit will
remove Guava from the missinglink-core module altogether
In the interest of having as few dependencies as possible in the core
module, this commit removes Guava from it.

Guava was only really used in three ways in the core module:

1. Immutable collection types
2. Preconditions checks
3. Joiner for concatenating strings

I replaced 1 with a mix of `Collection.singleton()`, `singletonList()`
etc., along with vanilla ArrayList / HashMap usage. The classes
generated by AutoMatter for POJOs will make copies of any collections
passed in, so I skipped a lot of the usage of Guava's Immutable types
for making copies of collections before passing them into the generated
POJOs.

Use of the Preconditions static methods to throw NullPointerExceptions
or IllegalArgumentExceptions I replaced with
`java.util.Objects.checkNotNull()` or vanilla if-else checks.

The plugin module still uses Guava; removing it from that module was out
of scope for this change (anyone using Missinglink in other build tools
will just depend on the core module).

Closes #60.
@mattnworb mattnworb requested a review from spkrka October 21, 2019 15:45
@coveralls
Copy link

coveralls commented Oct 21, 2019

Coverage Status

Coverage decreased (-0.3%) to 78.664% when pulling dbdf55b on remove-guava into 6fc7ac7 on master.

since we have changed the dependencies, and return types of some public
methods
@mattnworb mattnworb merged commit 52344db into master Oct 21, 2019
@mattnworb mattnworb deleted the remove-guava branch October 21, 2019 18:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

idea: remove guava dependency from core
3 participants