TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why There Is Interface Pollution in Java 8

76 点作者 Jarlakxen超过 10 年前

5 条评论

steve_barham超过 10 年前
Regarding the &#x27;checked exception issue&#x27;; an alternative technique to the method-wrapping-lambda is to use a default interface method to implement the non-exceptional interface, which delegates to the possibly-exceptional method. It&#x27;s a bit fussy, but it&#x27;s a nice technique to know:<p><pre><code> interface IOConsumer&lt;T&gt; extends Consumer&lt;T&gt; { @Override default void accept(T t) { try { maybeAccept(t); } catch (IOException ie) { throw new RuntimeException(ie); } } void maybeAccept(T t) throws IOException; } </code></pre> As IOConsumer&lt;T&gt; is also a Consumer&lt;T&gt;, if you can assign the lambda to an IOConsumer&lt;T&gt; it will get this wrapping behaviour automatically. So your code might look something like:<p><pre><code> try (Writer writer = new StringWriter()) { final IOConsumer&lt;String&gt; ioPrinter = writer::write; &#x2F;&#x2F; hand ioPrinter off to something that expects a Consumer&lt;String&gt; } </code></pre> This is by no means beautiful; for &#x27;writer::write&#x27; to be treated as an IOConsumer&lt;T&gt; requires that the target type be IOConsumer&lt;T&gt;, so typically would require an interim assignment. It does allow us to simplify the &#x27;wrapping&#x27; method, though, so that lambdas can again be used as one-liners:<p><pre><code> static &lt;T&gt; Consumer&lt;T&gt; maybe(IOConsumer&lt;T&gt; consumer) { return consumer; } try (Writer writer = new StringWriter()) { final Consumer&lt;String&gt; printer = maybe(writer::write); } </code></pre> It would be nice not to have these wrinkles, but I think Java 8 has done a fairly decent job of preserving backwards compatibility while introducing language features and APIs which feel like a vast improvement. I&#x27;d love to see reified generics in the future, particularly if the type parameter can be extended to support primitives.
评论 #8380785 未加载
lmm超过 10 年前
All this makes me very happy I nowadays work almost exclusively in Scala. No language is perfect, but Scala supports all the things Java 8 does (a few things are experimental until the next release), has straightforward FunctionN interfaces (as the article mentions) in addition to SAM synthesis (I mean, why not just do both?), and while a recent emphasis on compatibility means it&#x27;s starting to accumulate its own cruft, it at least drops the first ~10 years of Java&#x27;s backwards-compatibility awkwardness.
评论 #8381006 未加载
评论 #8381044 未加载
评论 #8380993 未加载
评论 #8381734 未加载
AndrewDucker超过 10 年前
I&#x27;m glad that, whether by better design, or lucky happenstance, C# managed to avoid bumping into these issues.<p>(It still has the problems, of course, that WinForms was written back in 2002 and doesn&#x27;t even use Generics, which would make the API a lot cleaner.)
评论 #8381093 未加载
EdwardDiego超过 10 年前
Can someone please define for me what exactly &#x27;interface pollution&#x27; is and why it&#x27;s so bad?<p>Because I read this article, and the article from the Jooq blog he references, and I can&#x27;t see anything beyond one guy&#x27;s preference for one thing, and Java 8 does it the other way.
评论 #8382060 未加载
lnanek2超过 10 年前
C# got rid of type erasure and is better for it. Java really needs to bite the bullet and do the same. It is just a compatibility hack anyway.
评论 #8382032 未加载
评论 #8382194 未加载