問題タブ [java-8]

jdk8 を使用して Java プログラムをコンパイルし、最新の機能を使用しました。

JRE 8 は最終リリース前に出荷できますか? JRE 8 はスタンドアロンで利用できないようです。そのため、最終リリースになる前に JDK8 を出荷できますか?

Java 8 では、メソッドを Lambda 式として作成し、参照によって渡すことができます (内部で少し作業が必要です)。ラムダが作成され、メソッドで使用されるオンラインの例はたくさんありますが、ラムダをパラメーターとして取るメソッドを作成する方法の例はありません。その構文は何ですか？

当初、 Project Coinはコレクションのサポートを強化していました。たとえば、list[3]代わりにlist.get(3)、map["hello"] = 27代わりにコレクションをサポートしていましたが、jdk7にはありませんでしmap.put("hello", 27)た。それらはjdk8に含まれる予定ですか？はいまたはいいえの決定的な答えを見つけることができませんでした。

私は将来のJava8リリース（別名JDK 1.8）で遊んでいます。

そして、私はあなたが簡単にできることを知りました

のように使用します

これは単に3を出力します。

また、より一般的な方法でこれを行うjava.util.function.Functionインターフェイスがあることもわかりました。ただし、このコードはコンパイルされません

そして、私は最初に次のようなことをしなければならないようです

では、IntIntFunctionステップを回避する別の方法があるかどうか疑問に思っていますか？

私の知る限り、Java 7にMethodHandleが導入されたことで、コンパイラーによって生成されたメソッドのオーバーロードが導入されました。

MethodHandleのjavadocには、次のように記載されています（例をトリミングしました）。

使用例を次に示します。

上記の各呼び出しは、invokeという名前とコメントに示されているタイプ記述子を持つ単一のinvokevirtual命令を生成します。引数の型は実際の引数から直接取得されますが、戻り型は呼び出しにすぐに適用されたキャストから取得されます。このキャストはプリミティブへのキャストである可能性があります。欠落している場合、戻り値を使用するコンテキストで呼び出しが発生すると、タイプはデフォルトでObjectになります。呼び出しがステートメントとして発生する場合、キャストは不可能であり、リターンタイプはありません。呼び出しは無効です。

事実上、invokeExactとその仲間は、パラメーターとリターンタイプの可能なすべての組み合わせに対してオーバーロードがあるかのように動作します。

MethodHandlesがラムダのようなJava8の機能を準備していると聞きました。（私はそれらがすでにスクリプト言語に役立つことを知っています。）

[/前書き]

では、これらのコンパイラーによって生成されたオーバーロードがJavaに隠れているのでしょうか？将来（たとえば、拡張メソッドを使用して）さらに多くのヒントがありますか？そもそもなぜそれが必要なのですか？ただのスピード？ラムダをどのように助けますか（ラムダは匿名の内部クラスにコンパイルされると思いました）？

要するに、理論的根拠は何ですか。なぜそれら（生成されたオーバーロード）が現在および将来的に役立つのですか？

更新：ここでコンパイラが生成するオーバーロードと呼んでいるのは、オラクルの連中が署名ポリモフィックと呼んでいることです。

私は Java 8 の新しいラムダ機能をいじっていて、Java 8 が提供するプラクティスが本当に役立つことを発見しました。ただし、次のシナリオを回避する良い方法があるのではないかと考えています。たとえば、オブジェクト プールを埋めるためにある種のファクトリを必要とするオブジェクト プール ラッパーがあるとします ( を使用java.lang.functions.Factory):

関数型インターフェースをラムダ式に変換すると、上記のコードは次のようになります。

確かにそれほど悪くはありませんが、チェックされた例外にはラムダ内に/ブロックjava.sql.SQLExceptionが必要です。私の会社では、長い間 2 つのインターフェイスを使用しています。trycatch

• IOut<T>java.lang.functions.Factoryこれは;と同等です。
• 通常はチェック例外の伝播が必要な場合のための特別なインターフェース: interface IUnsafeOut<T, E extends Throwable> { T out() throws E; }.

IOut<T>Java 8 への移行中にとの両方IUnsafeOut<T>が削除されるはずですが、 と完全に一致するものはありませんIUnsafeOut<T, E>。ラムダ式がチェックされた例外をチェックされていないかのように処理できる場合、上記のコンストラクターで次のように単純に使用できる可能性があります。

それはずっときれいに見えます。ObjectPoolスーパークラスを書き直してIUnsafeOut<T>私たちの

• に似たものを実装しIUnsafeOut<T, E>ますか？（正直なところ、私はそれを汚いと考えています-サブジェクトは何を受け入れるかを選択する必要があります：どちらか、Factoryまたは互換性のあるメソッドシグネチャを持つことができない「安全でないファクトリ」）
• ラムダでチェック例外を無視するだけなので、IUnsafeOut<T, E>サロゲートは必要ありませんか? （なぜですか？たとえば、別の重要な変更：私が使用しているOpenJDKは、匿名クラス[関数インターフェイス]またはラムダ式でキャプチャされるjavacように変数とパラメーターを宣言する必要がなくなりました）final

したがって、問題は一般的に次のとおりです。ラムダでチェック済み例外をバイパスする方法はありますか、またはJava 8が最終的にリリースされるまで、将来的に計画されていますか?

更新 1

うーん、私たちが現在持っているものを理解している限り、参照されている記事は 2010 年のものですが、現時点では方法がないようです: Brian Goetz は Java で例外の透過性を説明しています。Java 8 で何も変わっていない場合、これは答えと見なすことができます。また、Brian は、interface ExceptionalCallable<V, E extends Exception>(私が言及しIUnsafeOut<T, E extends Throwable>たコードの遺産から外れたもの) はほとんど役に立たないと言い、私も彼に同意します。

私はまだ何か他のものを見逃していますか？

Windows 7 に Java 8 EA をインストールしましたが、私の環境にも環境に%JAVA_HOME%もありません%PATH%。ただし、 をクリックして IntelliJ IDEA v12 を起動すると、とidea64.exeにある Java SDK 1.6.0_32 の代わりに Java 8 EA が選択されました。%JAVA_HOME%%PATH%

IDEA がいつ開始されたか、どの Java バージョンを実行するかをどのように決定したかを知っている人はいますか?

Java 8 以降、JDBC-ODBC ブリッジは JDK に含まれなくなりました。

JDBC-ODBC Bridge を接続する他のソリューションはありますか?

Java 8 と、インターフェイスに実装を追加する可能性 (Scala の特性に少し似ています) を使用すると、Scala でできるようにケーキパターンを実装することが可能になりますか?

もしそうなら、誰かがコードスニペットを提供できますか?

私はJava 8をいじって、ファーストクラスの市民としてどのように機能するかを調べています。次のスニペットがあります。

私がやろうとしているのは、メソッド参照を使用してdisplayIntメソッドをメソッドに渡すことです。myForEachコンパイラに次のエラーが生成されます。

コンパイラはそれを不平を言いvoid cannot be converted to Voidます。myForEachコードがコンパイルされるような署名で関数インターフェイスの型を指定する方法がわかりません。displayInt戻り値の型をto に変更してからVoidreturnに変更できることはわかっていnullます。ただし、別の場所に渡したいメソッドを変更できない場合があります。そのまま再利用する簡単な方法displayIntはありますか？