Java does not
let you declare them in the type signature... Java
requires you to declare them in the type signature. That means, the interface must precede the implementation, temporally, as in, it must exist first. In purely local development, you may do the implementation before the implementation, but until you at least have them together, the compiler won't let you claim you've implemented that interface.
That means you can't just take an image class from some JPEG library and declare an interface around its already-existing methods. That means the JPEG library has to know all the interfaces that may be useful, and declare them all first. If some of those interfaces are from other libraries, it must depend on those libraries to do it. This pressures image libraries to get together and have to declare "image processing" frameworks, which creates pressures to create all-singing, all-dancing image frameworks because these new interfaces being declared have to work for everything up front. If you get the interfaces wrong, the end-user of these libraries can't just fix them up on the fly. The framework then is pressured to undergo significant churn as it keys in on the correct all-singing, all-dancing set of interfaces to provide, either breaking backwards compatibility or having to drag along every bad decision it made for extended periods of time.
Granted, if a set of libraries does successfully run this gauntlet, the end result can be quite impressive, but it's a hell of a gauntlet to run!
This is also why it's at least a modestly acceptable Java practice to pre-emptively declare an interface for anything you think you might need an interface for later, because if you don't do it now, you'll have a harder time coming back and doing it later. I have a Java code base where darned near every class is basically duplicated, as both an interface and an implementation. I understand not everyone thinks this is good practice, but the language still pushes you in that direction even so. In Go, it simply neither good practice, nor something the language pushes you towards.
In Go, if I need to parse PNGs, I get a PNG parsing library. It just parses PNGs. The author of the library can make the best PNG library they care to, and the author of the library has no obligations to pre-declare any interfaces. If someone wants to weave this into a metalibrary, they can, and they don't have to fork the PNG library to do it, they can easily declare interfaces as they like, wrap things if they like, whatever. It's all more flexible. You're less likely to end up with that best-of-breed, all-singing, all-dancing awesome framework that is integrated and does everything in the end... but in the meantime you also get to use all the code that would have failed to finish the Java gauntlet.
In Java, because interface declarations must temporally precede all implementations, there's this huge pressure constantly pulling things into huge, all-encompassing frameworks, because all requirements are constantly being pushed up into the interfaces... the same interfaces that also have to exist first, before they can use them.
On paper, this is such a small little difference. It even sounds good... "why, of course we should have to declare conformance to interfaces? What if we accidentally implemented an interface and all hell broke loose? [1]" In reality... it's been a huge mistake.
[1]: My answer to that, BTW: http://www.jerf.org/iri/post/2954