Further fixes for https://github.com/google/guice/issues/904 -- java8 generates
default methods for subclasses when they override generic methods with the more
specific type.

We use a two-tiered approach to fixing: (1) try to use MethodHandles + unreflectSpecial, which lets us call default method implementations directly, and if that doesn't work then (2) try to map default methods to compatible method signatures that could be the overrides of the method.  (1) may not always work because we're using a private API [new Lookup(clazz, int)], but we need to do that in order to non-public classes.  (2) may not always work because it's possible to have more than one compatible method signature.

In the unlikely case that both (1) & (2) fail, we give an error message.
Also: we must validate the default method's return type for visibility vs the factory type's visibility too.

This ends up with two possible differences caused by java8:
a) If the Lookup cxtor can't be used (different JDK, version skew, etc..) and there's more than one compatible method signature: we fail.
b) If the default method's return type isn't public but the factory is public: we fail.

For reference, javac8 generates a default method in the following scenario:
interface Parent<I extends CharSequence, O extends Number> {
O create(I input);
interface Child<String, Integer> {
Integer create(String input);

Child has a generated default method of:
Number create(CharSequence input);

... so, for example, failure could be newly triggered if 'Number' was package-private but Child was public, or if the reflection APIs didn't work and Child also had a 'Integer create(StringBuilder input);' method.
Created by MOE: http://code.google.com/p/moe-java
2 files changed
tree: eb87961ff032167d5997c055e797e83e217136b8
  1. .gitattributes
  2. .gitignore
  3. .travis.yml
  6. README.md
  7. bom/
  8. build.properties
  9. build.xml
  10. common.xml
  11. core/
  12. examples/
  13. extensions/
  14. jdk8-tests/
  15. latest-api-diffs/
  16. lib/
  17. pom.xml
  18. util/


Now, out in 4.0 Beta5!

Documentation: User Guide, 3.0 javadocs, Latest javadocs
Continuous Integration: Build Status
Mailing Lists: User Mailing List, Developer Mailing List
License: Apache 2.0

Put simply, Guice alleviates the need for factories and the use of new in your Java code. Think of Guice's @Inject as the new new. You will still need to write factories in some cases, but your code will not depend directly on them. Your code will be easier to change, unit test and reuse in other contexts.

Guice embraces Java's type safe nature, especially when it comes to features introduced in Java 5 such as generics and annotations. You might think of Guice as filling in missing features for core Java. Ideally, the language itself would provide most of the same features, but until such a language comes along, we have Guice.

Guice helps you design better APIs, and the Guice API itself sets a good example. Guice is not a kitchen sink. We justify each feature with at least three use cases. When in doubt, we leave it out. We build general functionality which enables you to extend Guice rather than adding every feature to the core framework.

Guice aims to make development and debugging easier and faster, not harder and slower. In that vein, Guice steers clear of surprises and magic. You should be able to understand code with or without tools, though tools can make things even easier. When errors do occur, Guice goes the extra mile to generate helpful messages.

For an introduction to Guice and a comparison to new and the factory pattern, see Bob Lee's video presentation. After that, check out our user's guide.

We've been running Guice in mission critical applications since 2006, and now you can, too. We hope you enjoy it as much as we do.

jolt award