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

Add support for Java 8 modifier changes #244

Merged
merged 1 commit into from
Mar 17, 2015

Conversation

octylFractal
Copy link
Contributor

Adds support for most Java 8 modifier changes.

@octylFractal octylFractal mentioned this pull request Mar 7, 2015
@@ -82,4 +84,13 @@ public static String join(String separator, List<String> parts) {
result.addAll(b);
return result;
}

public static boolean hasDefaultModifier(Collection<Modifier> modifiers) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should not be public

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I guess doesn't matter, this class isn't public

@swankjesse
Copy link
Member

For tests, copy a method from TypeSpecTest and modify it until it does what you need! We want to accept default on interface methods, but not elsewhere.

@octylFractal
Copy link
Contributor Author

Looks like I wrote the wrong checkState, I'll add tests and attempt to fix that.

@octylFractal
Copy link
Contributor Author

@swankjesse Is there any preferred order for test methods, or can I insert anywhere? Also, this can't be tested without Java 8. Is there a specific way of doing that?

@swankjesse
Copy link
Member

@kenzierocks related tests are usually together, but the order isn't too important. Probably best to put these with the other tests that check for modifiers.

@octylFractal
Copy link
Contributor Author

And for the Java 8 compile restriction?

@swankjesse
Copy link
Member

One interesting/bad consequence of the DEFAULT constant is that testing this will cause our tests to require Java 8. @cgruber is this a problem?

@JakeWharton
Copy link
Member

Hmm... what about doing an assumeTrue(isJava8()); and then Modifer.valueOf("DEFAULT")?

@octylFractal
Copy link
Contributor Author

Can do.

@octylFractal
Copy link
Contributor Author

Alright, that should be it.

@octylFractal octylFractal force-pushed the feature/defaults branch 2 times, most recently from 14b085d to 83dbfc5 Compare March 7, 2015 19:38
@octylFractal
Copy link
Contributor Author

Okay, found a new problem. default methods aren't abstract, so that's no longer implicit in interfaces because it would cause a checkArgument to fail. However, when there's no default, abstract is implicit, but there's no clear way to indicate this. Is there a preferred way that this should be handled?

@swankjesse
Copy link
Member

@kenzierocks I think you should require either default or abstract, but not both.

@octylFractal
Copy link
Contributor Author

Yes, but then it emits an abstract modifier in cases where it's implicit. I could change that checkArgument I linked above.

@JakeWharton
Copy link
Member

Don't forget static. Also, while we're in here, we should support private methods on interfaces as well (Java 9).

@octylFractal
Copy link
Contributor Author

Oh, that sounds cool. I think I'll rework the implicit structure a bit to ease this in the future in case even more implicitness is added/removed.

@octylFractal octylFractal force-pushed the feature/defaults branch 3 times, most recently from 0a89400 to 9c463b5 Compare March 8, 2015 20:10
@octylFractal
Copy link
Contributor Author

I changed it so that implicit modifiers are not required, which is the most minimalist change I can think of that won't break compatibility but will allow this new rule. A side effect of this is allowing the above changes to also work. I just need to add a test that checks for static on interfaces working, and also double check that private works.

@swankjesse
Copy link
Member

@kenzierocks I'd like to continue requiring implicit modifiers. When Java 9 comes and interface methods can be public or private, I want the public to be in the callsite so we don't have to guess!

@octylFractal
Copy link
Contributor Author

Then I'll need to think of some way to allow the implicit modifiers through, or scrap the whole system and just always print modifiers explicitly.

@octylFractal
Copy link
Contributor Author

Updated the hasDefaultModifier method to cache the value of DEFAULT.

@octylFractal
Copy link
Contributor Author

I'm not finding the specification for private on interface methods, would you mind showing me?

Modifier def = null;
try {
def = Modifier.valueOf("DEFAULT");
} catch (IllegalArgumentException expected) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: expected –> ignored

(expected: this should happen 100% of the time. ignored: I don't care if this happens)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right.

@swankjesse
Copy link
Member

I love how this is coming together. Thanks for your patience on my strict and pedantic reviews. I think it's worth it.

@octylFractal
Copy link
Contributor Author

Oh, I don't mind. The only pain I have is my formatter is off by a little bit so I'm trying not to hit format.

@octylFractal octylFractal force-pushed the feature/defaults branch 2 times, most recently from 5d3f7fe to f6ff4ab Compare March 16, 2015 14:20
@octylFractal octylFractal changed the title Add support for default methods on interfaces Add support for Java 8 modifier changes Mar 16, 2015
@octylFractal octylFractal force-pushed the feature/defaults branch 7 times, most recently from 53b24c7 to 894391a Compare March 16, 2015 14:59
@octylFractal
Copy link
Contributor Author

Okay, this should be good.

if (kind == Kind.INTERFACE) {
requireExactlyOneOf(EnumSet.of(Modifier.PUBLIC, Modifier.PRIVATE),
fieldSpec.modifiers);
if (kind == Kind.INTERFACE) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This if can be removed. You already have it above.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was leftover from when the above if had || kind == Kind.ANNOTATION. Fixing.

@octylFractal
Copy link
Contributor Author

Fixed problem, let me know if there's anything else I need to modify.

checkArgument(fieldSpec.modifiers.containsAll(kind.implicitFieldModifiers),
"%s %s.%s requires modifiers %s", kind, name, fieldSpec.name,
kind.implicitFieldModifiers);
checkState(kind != Kind.ANNOTATION, "%s %s cannot have fields", kind, name);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love this

@swankjesse
Copy link
Member

This works! I'm going to merge it as-is and send my own follow-up to you where I think we can slightly shrink the code required. (Fun java tricks!)

swankjesse added a commit that referenced this pull request Mar 17, 2015
Add support for Java 8 modifier changes
@swankjesse swankjesse merged commit 14216e0 into square:master Mar 17, 2015
@swankjesse
Copy link
Member

Thanks for the fix, and for your patience!

@swankjesse
Copy link
Member

#251

@octylFractal octylFractal deleted the feature/defaults branch March 18, 2015 15:27
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.

None yet

3 participants