- PR -

JDK7の情報交換

投稿者投稿内容
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 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のアップデート
等です。

機能についての議論があっても面白いなと思います。
よろしくお願いします。
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2006-12-17 22:33
気の早い話だとは思いますが。

・新しい構文によるgetter/setterアクセスとproperty構文

というのは琴線に触れるものがありますね。
Eclipseが自動でsetter, getterを作ってくれるようにはなりましたが
いかんせん、冗長なというか、いちいち記述するのが面倒と言うか
リフレクションでアクセスする場合に大変というか、
言語的にうまくまとまっていないな、というのが気になっていたので。

やや関連した話題として、DIを使ってるとsetter, getterをDIのコンテナのために
publicにせざるを得ないという難点がありますね。アレどうにかならないのかなと。
O/Rマッピングの際にも同様の問題がありますが、
要するにPOJOに値をマッピングする機能というものを使うには
フィールドに対してsetter, getterでpublicにアクセスさせないといけない。
だけども、他のプログラムからは隠蔽したい、ということが多々あるのです。

public になっているということは、本来みえなくてもいいはずのものが
見えてしまうということですから、開発の際の混乱の元になることがあります。
これらコンテナを使った開発をしていると、アクセスレベルが混乱するのですよね。
mio
ぬし
会議室デビュー日: 2005/08/25
投稿数: 734
お住まい・勤務地: 神奈川県
投稿日時: 2006-12-17 23:07
・クロージャ
前にも書いたんですが、どうもこれは、違うような気がしてます。

・switch文にStringが使用可能
(クロージャと合わせて)JavaがJavaScriptになっていく…。
たしかに、使えればきれいに書ける箇所はあるんだけど…。

・新しい構文によるgetter/setterアクセスとproperty構文
C#と同様に…でしょうかね。
実際こっちのほうがいいなとは思ってるんですが。

・new構文の省略形(型推論?)
これもC#でやっていたような…(最初のC#しか使ってないので記憶)。
Gio
ぬし
会議室デビュー日: 2003/11/28
投稿数: 350
お住まい・勤務地: 都内から横浜の間に少量発生中
投稿日時: 2006-12-18 00:04
引用:

nagiseさんの書き込み (2006-12-17 22:33) より:

O/Rマッピングの際にも同様の問題がありますが、



Hibernate では private な setter/getter が使えるので不必要に広い可視性は避けられます。
でも、これも privileged で処理していると考えるとスマートとは言えません。
(そこまで気をもむ必要もないかもしれませんが)

すぐに思いつく案としては、@ORM とか @POJO とかのクラスアノテーションを導入して、コンパイラや IDE では O/R マッピングというロールを持たないクラスから参照した時はコンパイルエラーや補完候補から除外するというものがあります。
クラスのロールがマーカインタフェースとどう違うのかは考えていません。

いっそのこと一緒にしてしまって、@ORM(gio.foo.ORMapper) で gio.foo.ORMapper インタフェースを implement したクラスの参照だけを認めるというのもアリかも(???)

最初「C++ の friend の復活か?」と考えましたが、これは公開する相手をクラス名で指定しないといけないので DI や O/R マッピングに使うには柔軟性に欠けますね。
Gio
ぬし
会議室デビュー日: 2003/11/28
投稿数: 350
お住まい・勤務地: 都内から横浜の間に少量発生中
投稿日時: 2006-12-18 00:50
引用:

すぐに思いつく案としては、@ORM とか @POJO とかのクラスアノテーションを導入して、



クラスではなくてメソッドアノテーションです。

けれどもこれも違和感があって、private だけれども gio.foo.ORMapper 実装クラスには参照を許すという意味で
コード:

@ORM(gio.foo.ORMapper)
private Foo getFoo() {...}


と書くと、可視性をアノテーションと private の二つで表すことになります。

一つにすると、可視性の指定に restricted()(仮称)を追加して
コード:

restricted(gio.foo.ORMapper) Foo getFoo() {...}


という考えもありますが、自分で書いたくせにこれもしっくり来ません。

すべての setter/getter メソッドにこう書くのも鬱陶しいので、参照を許すマーカインタフェースはクラスアノテーションにして
コード:

@ORM(gio.foo.ORMapper)
public class Bar {
restricted Foo getFoo() {...}
...
}


だとちょっとはマシでしょうか。

[ メッセージ編集済み 編集者: Gio 編集日時 2006-12-18 00:52 ]
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2006-12-18 01:17
>nagiseさん
確かに早いかもしれませんね・・・リリース時期は2008年くらいかな。
一応JDK6も正式バージョンが出たので、やっと次期バージョンと呼べるようにはなりましたね。

プロパティ構文については、
コード:
public class Hoge{
    public property String foo;
}


と定義して、
コード:
//従来
hoge1.setFoo(hoge2.getFoo());
//プロパティ構文
hoge1->Foo = hoge2->Foo;


となるみたいです。

リフレクションでgetter/setterの存在チェックする必要がなくなるのはいいかもしれません。


>mioさん
型推論はスコープが狭くてもいいのであれば便利ってレベルでしょうね。
C#とJavaで相互にいい部分はサポートして欲しいところです。


ComegaライクにSQLリテラルとか・・・も欲しいと思ったりするのですが、
そこまではいらないので、せめてヒアドキュメントかマルチライン文字列を
もうそろそろサポートして欲しいところです。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2006-12-19 23:28
property構文ってオーバーライドできるんでしょうか。

コード:
public property String hoge;


と定義して、
コード:
public String getHoge(){
    return this.toUpperCase();
}


みたいに、一般的な方法でオーバーライドするのか、
コード:
public property String hoge{
    public String get(){
        return hoge.toUpperCase();
    }
    
    public void set(String hoge){
        this.hoge = hoge;
    }
}


のようになるのか・・・

なにか情報ありましたらよろしくお願いします。
guccii
会議室デビュー日: 2007/01/04
投稿数: 7
投稿日時: 2007-01-04 05:29
まだJDK7のことは何も...
でもここで書かれている機能リストでの中では、私的には、「メソッド参照」が気になりました。

ちなみに皆さんは、(状態遷移表などの)関数表を利用する設計をJavaで実装する場合にはどうしてますか?
私は、関数一つ一つを単一のメソッドをもつセルクラスし、基底セルクラスから継承するように実装してます。「メソッド参照」があれば、こんなめんどくさいラッピングをする必要がなくなるのでは?と思って期待しちゃいます。

あとは、リアルタイム仕様とパラレルVM対応はどうなってるのかなぁ。

さらにいうと、SWTなんかもうどうでもいいから、WPFやFlashに対抗できるものをjava標準で用意しないのかなぁ。そしたらそしたらぜーんぶjavaで開発するのになぁ。

すいまっせん。欲張りで。

スキルアップ/キャリアアップ(JOB@IT)