- - PR -
JDK7の情報交換
1|2|3
次のページへ»
投稿者 | 投稿内容 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-12-17 17:58
JDK7について色々情報を集めているのですが、何かご存知のことがあれば何でも書いてください。
JDK7のサイトは以下です。 https://jdk7.dev.java.net/ これも参考になります。 http://blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf 現段階で知っている、噂になっている情報としては、 ・クロージャ ・XMLリテラル ・ファイルシステムインターフェイス ・BigDecimalで直接演算子で計算が可能 ・switch文にStringが使用可能 ・新しい構文によるgetter/setterアクセスとproperty構文 ・カテゴリ分けが可能なJavadoc ・モジュール化 ・enumの大小比較 ・メソッド参照 ・new構文の省略形(型推論?) ・引数チェック用のアノテーション(@NotNullみたいなもの) ・スクリプト言語向けのVMの命令追加 ・その他もろもろのAPIのアップデート 等です。 機能についての議論があっても面白いなと思います。 よろしくお願いします。 | ||||||||||||||||
|
投稿日時: 2006-12-17 22:33
気の早い話だとは思いますが。
・新しい構文によるgetter/setterアクセスとproperty構文 というのは琴線に触れるものがありますね。 Eclipseが自動でsetter, getterを作ってくれるようにはなりましたが いかんせん、冗長なというか、いちいち記述するのが面倒と言うか リフレクションでアクセスする場合に大変というか、 言語的にうまくまとまっていないな、というのが気になっていたので。 やや関連した話題として、DIを使ってるとsetter, getterをDIのコンテナのために publicにせざるを得ないという難点がありますね。アレどうにかならないのかなと。 O/Rマッピングの際にも同様の問題がありますが、 要するにPOJOに値をマッピングする機能というものを使うには フィールドに対してsetter, getterでpublicにアクセスさせないといけない。 だけども、他のプログラムからは隠蔽したい、ということが多々あるのです。 public になっているということは、本来みえなくてもいいはずのものが 見えてしまうということですから、開発の際の混乱の元になることがあります。 これらコンテナを使った開発をしていると、アクセスレベルが混乱するのですよね。 | ||||||||||||||||
|
投稿日時: 2006-12-17 23:07
・クロージャ
前にも書いたんですが、どうもこれは、違うような気がしてます。 ・switch文にStringが使用可能 (クロージャと合わせて)JavaがJavaScriptになっていく…。 たしかに、使えればきれいに書ける箇所はあるんだけど…。 ・新しい構文によるgetter/setterアクセスとproperty構文 C#と同様に…でしょうかね。 実際こっちのほうがいいなとは思ってるんですが。 ・new構文の省略形(型推論?) これもC#でやっていたような…(最初のC#しか使ってないので記憶)。 | ||||||||||||||||
|
投稿日時: 2006-12-18 00:04
Hibernate では private な setter/getter が使えるので不必要に広い可視性は避けられます。 でも、これも privileged で処理していると考えるとスマートとは言えません。 (そこまで気をもむ必要もないかもしれませんが) すぐに思いつく案としては、@ORM とか @POJO とかのクラスアノテーションを導入して、コンパイラや IDE では O/R マッピングというロールを持たないクラスから参照した時はコンパイルエラーや補完候補から除外するというものがあります。 クラスのロールがマーカインタフェースとどう違うのかは考えていません。 いっそのこと一緒にしてしまって、@ORM(gio.foo.ORMapper) で gio.foo.ORMapper インタフェースを implement したクラスの参照だけを認めるというのもアリかも(???) 最初「C++ の friend の復活か?」と考えましたが、これは公開する相手をクラス名で指定しないといけないので DI や O/R マッピングに使うには柔軟性に欠けますね。 | ||||||||||||||||
|
投稿日時: 2006-12-18 00:50
クラスではなくてメソッドアノテーションです。 けれどもこれも違和感があって、private だけれども gio.foo.ORMapper 実装クラスには参照を許すという意味で
と書くと、可視性をアノテーションと private の二つで表すことになります。 一つにすると、可視性の指定に restricted()(仮称)を追加して
という考えもありますが、自分で書いたくせにこれもしっくり来ません。 すべての setter/getter メソッドにこう書くのも鬱陶しいので、参照を許すマーカインタフェースはクラスアノテーションにして
だとちょっとはマシでしょうか。 [ メッセージ編集済み 編集者: Gio 編集日時 2006-12-18 00:52 ] | ||||||||||||||||
|
投稿日時: 2006-12-18 01:17
>nagiseさん
確かに早いかもしれませんね・・・リリース時期は2008年くらいかな。 一応JDK6も正式バージョンが出たので、やっと次期バージョンと呼べるようにはなりましたね。 プロパティ構文については、
と定義して、
となるみたいです。 リフレクションでgetter/setterの存在チェックする必要がなくなるのはいいかもしれません。 >mioさん 型推論はスコープが狭くてもいいのであれば便利ってレベルでしょうね。 C#とJavaで相互にいい部分はサポートして欲しいところです。 ComegaライクにSQLリテラルとか・・・も欲しいと思ったりするのですが、 そこまではいらないので、せめてヒアドキュメントかマルチライン文字列を もうそろそろサポートして欲しいところです。 | ||||||||||||||||
|
投稿日時: 2006-12-19 23:28
property構文ってオーバーライドできるんでしょうか。
と定義して、
みたいに、一般的な方法でオーバーライドするのか、
のようになるのか・・・ なにか情報ありましたらよろしくお願いします。 | ||||||||||||||||
|
投稿日時: 2007-01-04 05:29
まだJDK7のことは何も...
でもここで書かれている機能リストでの中では、私的には、「メソッド参照」が気になりました。 ちなみに皆さんは、(状態遷移表などの)関数表を利用する設計をJavaで実装する場合にはどうしてますか? 私は、関数一つ一つを単一のメソッドをもつセルクラスし、基底セルクラスから継承するように実装してます。「メソッド参照」があれば、こんなめんどくさいラッピングをする必要がなくなるのでは?と思って期待しちゃいます。 あとは、リアルタイム仕様とパラレルVM対応はどうなってるのかなぁ。 さらにいうと、SWTなんかもうどうでもいいから、WPFやFlashに対抗できるものをjava標準で用意しないのかなぁ。そしたらそしたらぜーんぶjavaで開発するのになぁ。 すいまっせん。欲張りで。 |
1|2|3
次のページへ»