パスワードを忘れた? アカウント作成
349584 story

Java SE 7 リリース 71

ストーリー by headless
更新 部門より

あるAnonymous Coward 曰く、

Oracleは7月28日、Java Platform, Standard Edition 7(Java SE 7)の提供を開始した(プレスリリースダウンロードページ本家/.)。

Java SEのメジャーアップデートは5年ぶりであり、OracleによるSun Microsystems買収後では初めてとなる。主な変更点/新機能は、生産性向上のための言語仕様変更、動的/スクリプト言語サポートの改善、マルチコア対応API、非同期I/O API、Unicode 6.0サポートなど。

主要な統合開発環境では NetBeans 7.0IntelliJ IDEA 10.5 が対応済み。Eclipseは7月29日以降の最新ビルドで順次サポート機能が追加されているが、正式対応は9月リリースの3.7 SR1となる予定。 また、アプリケーションサーバーでは GlassFish 3.1.1 が対応版として公開されている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 今回のバージョンにはループ最適化に関する致命的なバグ [lucidimagination.com]があるそうです。

    (重要な用途には用いないこと || 関連する最適化オプションを無効にすること) && 今後のアップデートを速やかに導入することをお薦めします。

    • by Anonymous Coward on 2011年07月31日 20時04分 (#1995390)

      例えばVisual Studioがループ最適化に致命的なバグを持ったまま出荷されたらどうなるだろうか?
      間違いなく叩かれるだろう「こんなもん使い物になんねーよ」「金払ってんだからちゃんとしたもの売れ」そんな声が聞こえてくるようだ

      では無償版のVisual Studio Expressの方だったらどうか?
      やはり叩かれるだろう「無償版だからって手抜いてんじゃねーよ」「有償版を買えってことですね分かります」そんなところか

      ならばGPLなgccだったらどうだろう?
      それでもやはり叩かれるだろう「人柱さん何やってんの?」「良くもまあこんなんでstable宣言できたな?」「OSSの方が品質が高いとか思っている奴は情弱」ボロクソに言われるだろう

      それならどうしてJavaはこんな致命的なバグ持ちで出荷されても許されるのか?
      悲しいかな、これこそが日本人の中立であろうとした時の立ち位置だからだ

      世界で中立とか公平とかいう場合、どんなものも同じ価値となり、それがgccだろうと、JDKだろうと、同じように評価される
      しかしながら同じことを日本人にやらせると、どういうわけだか劣っている方を大目に、優っている方を減じて評価してしまう習性がある
      いわゆるケンカ両成敗という考えかたこそが、日本人の考える公平とか中立という立ち位置になる
      似ているようでいて全く違う考え方なのだが、大抵の日本人は悲しいかな違いが分からない
      なにしろ自分は中立な立場に立っていると勘違いしているので、違いもへったくれもないわけだ

      これだから日本人と議論するのは疲れるんだ
      物事を公平に見るということができず、常にどちらか側につくことで両者の優位性を打ち消すことを、公平に見るということだと誤解しているので話にならない
      どうしてダメなものはダメと言えないのか?

      親コメント
    • by Anonymous Coward
      でもそのバグにあたらないコーティングをするならGoodです!
      • Miyakawaさんの張ったリンク先には

        > Don’t use Java 7 for anything (unless maybe you know you don’t have any loops in your java code)

        って書いてありますね。ループのないコードなら OK ってことです。

        Java 7 のループは if と goto で書きましょう。;-)

        親コメント
        • って書いてから「もしかして Java って goto なかったような?」と思ったら、ほんとにありませんね。使わないと気付かないもんだなぁ…

          どうやったら loop が書けるんだろう?

          親コメント
          • by firewheel (31280) on 2011年07月31日 13時09分 (#1995235)

            >「もしかして Java って goto なかったような?」と思ったら、ほんとにありませんね。使わないと気付かないもんだなぁ…

            懐かしのFAQだけど、バイトコードにはあるよ。
            http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.... [sun.com]

            つまりバイトコードのアセンブラで書けば良いんだね!
            #そっかー。このFAQが流行ったのって、もう10年以上前の話なんだ……
            #そら知らん人も多いわけだ。

            親コメント
            • by Anonymous Coward on 2011年07月31日 13時13分 (#1995237)

              バイトコードのレベルで無条件ジャンプ命令があるのは当たり前だと思うけど。
              構造化プログラミングってのは極論すればソースコード見る人間の都合にすぎないんだし。

              親コメント
          • by Anonymous Coward on 2011年07月31日 12時43分 (#1995226)

            末尾再帰で書きましょう。
            最適化でループで展開されるみたいなんで・・・あれ?

            親コメント
            • by Anonymous Coward

              Javaって末尾再帰をループに最適化してくれましたっけ?
              Scalaならしてくれるみたいですけど。

            • by Anonymous Coward

              ところで、何でいまだに人間様が末尾再帰で書いてやらなきゃならないんですかね。
              人間が通常の再帰を末尾再帰に書き換えることができるなら、どうして機械にはそれができないんでしょうか。
              末尾再帰に書き換え不可能な再帰があるのは知ってますけど、そんなのはエラーにしても十分実用的ではないですか。だって計算量が指数関数的どころの騒ぎではないのに、アッカーマン関数なんてベンチマーク等の目的以外で実用的なプログラムに使いますか?

              • by Anonymous Coward
                そういうセマンティクスの書き換えが言語仕様的にものすごく難しそうなC言語でさえgccはやってる [fc2.com]みたいなので、単なる手抜きではないですかね。
          • ループしない。全てを再帰コールで実装する(メモリ的にかなり無茶だ)

            --
            fjの教祖様
            親コメント
          • by Anonymous Coward
            java でのプログラミング経験なしで言うのもなんですが、
            再帰呼び出しとか
            極短周期のタイマイベントとか
          • by Anonymous Coward
            ラベル付きcontinueってあったよな
          • by Anonymous Coward

            ループ回数分だけコピー&ペーストする

        • by Anonymous Coward
          もしかしなくても今回のリリースはゴミ(黒歴史)ですかね?
    • by Anonymous Coward

      > 関連する最適化オプションを無効にする
      具体的にはどういう起動オプションを指定したらいいんですかね。リンク先はただ「使うな」だけで回避策は書かれていないみたいですし。

  • by Anonymous Coward on 2011年07月31日 16時07分 (#1995293)

    ところで、Javaの優位性って何でしょう?
    どんなに工夫しても所詮はインタプリタだから遅いし、
    どこでも動く的な話は夢であることははっきりしてきたし、、、
    WEBシステムで表示はIEへ、DBはOracleへ丸投げとか、Android上ではそれなりかもしれないが、それなら他の言語に比べて良いこと無いし。

    特に実務で使う場合はコーディングルールとかの蓄積が無いからむちゃくちゃになるし、訳の判らない争いごとが多いし。
    #それに比べればCOBOLって最高だよね。仕事で使うなら。

    • by Anonymous Coward on 2011年07月31日 16時21分 (#1995303)
      こ、こんなエサにつられないんだからねっ!!
      親コメント
      • 笑ってしまいましたw

        それはさておき。
        C++をやっていたので、Javaが覚えやすかった。
        ポインターみたいな事もやってくれるし、
        メモリー管理をしてくれているだけで精神的に楽。
        WindowsとLinuxで動けばそれ以外はどうでも良いかな。

        COBOLはオフコン環境で使うと出来ない事の理解をお客から得やすいのが良かった。
        文章を書いている感覚で、クラスなんて無くても十分読みやすいコードだった。
        印刷した時に段下げの美しさを自画自賛したりしてw
        PC環境ではどうなんでしょうね?

        親コメント
        • by Anonymous Coward

          #釣りと思われれしまったか、まあ、COBOLって最高とか書いたからしかたないか。

          PC環境でも普通にCOBOL使っていますよ。理由は「十分読みやすい」ですね、やっぱり。
          Javaも正しくクラスを作っていけばそれなりに良いのだけど、統制を取るのに苦労する。
          分業すると作業者の癖が出てシステムが腐るし、優秀なアーキテクチャに任せれば
          しっかりしたシステムが出来るが、それでは分業のときのような生産性や人員計画立
          てられないし。

          あと、Javaにはちょっとくらい環境による違いがあってもとりあえずコンパイラーと
          VMがあるとうれしいよね。(計画段階で調査するとJavaが無い環境が結構あってね。

          • by Anonymous Coward
            釣り針デカすぎですぜ、老害さん
    • ところで、Javaの優位性って何でしょう?

      古典的すぎるネタですが。

      「インタープリター言語」を利用する最大の理由は「速度よりも言語的柔軟性」を優先したい場合です。なので、「遅い」事が問題になるような場合には使わない。

      「どこでも動く」が嘘であっても、「WindowsでもLinuxでもMacでもそれなりに動いて欲しい」とか「HP/UXとLinuxとSolarisとAIXでそこそこ動いて欲しい」とかいうニーズに対してなら、シングルバイナリ配布で済む分、Native Binary出力よりも優位。

      特に実務で使う場合はコーディングルールとかの蓄積が無いからむちゃくちゃになるし、訳の判らない争いごとが多いし。

      それは Java の問題ではなく、プログラマーとしてのあなたの実力が不足しすぎていて、他者を圧倒していないから起こること。
      「私が黒と言ったら、白熊は黒いっ!!」
      と言えるだけの実力をつけましょう。

      #それに比べればCOBOLって最高だよね。仕事で使うなら。

      おいおい、モノを知らないにもほどがあるってもんだぜ。
      「ADD A TO B GIVING C.」って書くべき所を「COMPUTE C = A + B」って書く奴らが増えちまって、COBOLの世界も大混乱よ。

      --
      fjの教祖様
      親コメント
      • by Anonymous Coward on 2011年07月31日 19時28分 (#1995382)

        > おいおい、モノを知らないにもほどがあるってもんだぜ。
        > 「ADD A TO B GIVING C.」って書くべき所を「COMPUTE C = A + B」って書く奴らが増えちまって、COBOLの世界も大混乱よ。

        そうそう。
        この間の奴なんか、中堅者自称してるくせに「GO TO」で書かずに「PERFORM」でループ書きやがる。

        親コメント
      • >他者を圧倒していないから起こること。
        >「私が黒と言ったら、白熊は黒いっ!!」
        >と言えるだけの実力をつけましょう。

        つまり、JAVAを使うには、言語仕様とは関係なく、
        無理を言って押し通す技術が必要ということですね。

        >「ADD A TO B GIVING C.」って書くべき所を「COMPUTE C = A + B」って書く奴らが増えちまって、COBOLの世界も大混乱よ。

        つまり、「COMPUTE C = A + Bと書け!」と言って押し通せる必要があるのではないですか?

      • by Anonymous Coward

        > 「速度よりも言語的柔軟性」を優先したい場合です。

        javaにそれが当てはまりますか? 例えばC++と比べてどこがインタープリタとして優れいているの?

        > 「どこでも動く」が嘘であっても

        ここは同意ね。

        > 「WindowsでもLinuxでもMacでもそれなりに動いて欲しい」とか「HP/UXとLinuxとSolarisとAIXでそこそこ動いて欲しい」とかいうニーズに対してなら、シングルバイナリ配布で済む分、Native Binary出力よりも優位。

        その意見はある程度同意します。それなりやそこそこで動く分には。
        実際、単体試験は各作業員のWindowsPCで実行はUNIXサーバーという形式は良くやる。

        • でもそこまで、Win-mac-unix でそのままのバイナリがそこそこ動くのはね。
          ちゃんとを目指したり、WEBサーバー以外のアプリケーション開発するならシングルバイナリ配布では対応できない。

          どうやらここから突っ込む必要がありそうですね。

          よく考えてください。C言語ができてもうすぐ30年です。
          未だに「CUIとGUI、X11用とWindows用とMac用のコードが単一コードから生成できるライブラリセット」はできていません。C言語はもともと Human Interface については何の仮定も置いていないプログラミング言語なのに、ですよ?と言うことは、そもそも「UIを書く」ための「単一インターフェース(言語であれ、ライブラリであれ)」はまだないってことです。

          当然、存在しない概念を実装した処理系は存在しえません。

          だから、シングルバイナリ配布で可能なのは「マシン・マシン・インターフェース」が決まっている(あるいは、unixのようにヒューマンインターフェース側が限りなくマシン・インターフェースに等しく、かつ テキストのような汎用化された通信ベースに基づいている)場合に限定されるわけです。

          なので、シングルバイナリ配布の恩恵を受けられるのはHuman Interfaceを大量に必要とする「対人間用」コードではなく、その一歩手前まで…つまりサーバー側からスタートして、クライアントにおけるバックグラウンド処理まで…に限られます。最後のUIの部分は、絶対個々のOSごとに native でつくるしかないんです。

          これはどのような言語であっても共通して言えること。C for JVM があっても何も変わりません。

          基盤の大転換なんかめったにやらないし、それを始めたらJavaが特に有利ということは無い。
          基盤間移植が始まったら結局は修正とリコンパイルするからJavaの優位性も消える。

          うん。それはつまり「ソースコードがある」「ソースコードがきちんとしている」って言うことだよね。

          たとえば「所定の時間待つ」ために for文+nop で構成されたりしていないってわけだ。
          また、「ソースコードが無くなっていない」ってわけだ。

          実際には、基盤間移植の本当に大変な部分は、ソースは残っていないし、中身は腐っているんだよ

          つまり、ソースコードはなく、アセンブラで追い回したら for 文みたいな構文の中に nop が入ってる…なんてのがゴロゴロしているコードこそが曲者。なにしろ、エミュレーターや仮想マシンをもってしても、「マシン語1命令単位」での実行時間をオリジナルとぴったり合わせることはできない。CPUが早すぎたり、逆にエミュレーターが遅すぎたりする。

          しかし、最適化が中途半端にかかっているものだから、デコンパイルが効かない。まさに問題のポイントの周辺が解析不能に陥る。「意味論的に理解できるパターン」が書かれているからこそ、デコンパイラーのデザイナーがパターンを登録できるのであって。「意味不明なコード」をコンパイルしてできた結果は、デコンパイルできない。

          捨てて作りなおそうにも何やってんだかよく分からなさすぎる上に、コストだけは大量にかかった、スケジュールのスリップしまくったプログラムなので、まだ元が取れてない。だから捨てられない(と泣きついてくることが多い)。

           
          しかし Java は違う。Javac は最適化をほとんどかけないので、デコンパイルし易い。JVM上で動くので最初から 「for文+nopでタイミング調整」なんてできない。

          つまり「Javaで書いておくと基盤間移植しやすい」のだ。

          「速度よりも言語的柔軟性」を優先したい場合です。

          javaにそれが当てはまりますか? 例えばC++と比べてどこがインタープリタとして優れいているの?

          当てはまります。が、多分それは想像している答と違うでしょう。

          まず、Javaはコンパイラ言語です。C++やPascalとかと同じです。なので、C++に比べてJavaが「言語的に」何か優れている、と言うことはありません。いや、オブジェクト指向言語としてよりシンプルである、とかそういうのはあるでしょうが、「インタープリターであるための言語柔軟性」…例えば eval が実行できるとか…は Java そのものにはありません。

          なので、「インタープリターとしての柔軟性」は全て JVM 用バイトコード処理系側に存在します。別の言い方をすれば、「JVMがCorei7に比べて何が優れているのか」という比較になります。で、すぐ判るでしょうが、この比較であれば「JVMは物理プラットフォームに対する縛りが緩い」事と「Garbage Collector を持っている」の2点が柔軟性としてあげられます。物理CPUに対する縛りを緩める、というのは「インタープリターとしてのJava」の特徴の一つですから、当然勘定してあげなくちゃ不公平、というものです。

          GCはサーバー用/デーモン系プログラムにおける福音です。少なくともこれが福音になるような人たちですら、基本的に停止させないプログラムを書いて、メモリリークの心配をしなくて良い、という段階で福音です(JVM自身のバグのせいで酷いメモリリークを起こすことがあるのは、脇に置いておくとして)。

          Javaは「馬鹿でも安全にコードが書ける」プラットフォームとして、C++に比べて言語的柔軟性が優れているのです。
          # ポインタ操作の山をかいくぐって「完璧なGC」を行うのは難しい。
          # だから、C++用にはBoehm GCのような保守的GCしか実装できない。と言うことは、
          # メモリリークを起こすし、無限に動き続ける daemon を書く上で、C++では十分な保護は
          # 受けられないわけだ。

          プログラマーとしてのあなたの実力が不足しすぎていて、

          マネージャじゃなくて?

          他者を圧倒していないから起こること。

          私の配下では統制しているよ。

          うむ、影響範囲が狭すぎる。

          考えてみて欲しい。Cの場合「歴史があるので書き方がより定まっている」というのは「私の配下では統制できている」程度の人しかいなかったなら、おかしいと思わないか?

          もし、非常に狭い部隊内部だけの統制が取れればいいのであれば、マネージャーで十分だ。別に強圧的な方法なんぞ使わなくてもよい。しかし、それでは世間の常識になんかならない

          「書き方が定まっている」のは歴史があるからじゃない。組織外部に向かってでも、「こういう場合はこう言うふうに書くものであるっ!!」と宣言し、押し付けた人がいたからこそ書き方が定まっているのだ。プログラマーとしての実力が不足しすぎていて、他者を圧倒できていないとはそういうことだよ。

          小さな自分の配下ごときで「できている」なんぞとは言わない。
          自分の部署と取引がある部隊が同じルールに従うのでは、世界が狭すぎる。

          もっともっと、でかい世界を「平伏できていない」のならば 実力不足 か、影響が十分世間に回っていないか…どちらかだ。そして「マネージャじゃなくて?」と聞いたということは、これは実力不足の方であると確定した、と言うことだ。
          # 「それ、俺の仕事と違う」と宣言したに等しいからね。

          --
          fjの教祖様
          親コメント
        • まあ、わざわざ人間が書く必要もないような退屈な処理専用のCOBOLと、言語としてのエレガントさを捨てて、
          カオスな現実に擦り寄ったツギハギなJavaの論争は適当にやってくれればよいですが、

          設計者のことを指すなら「アーキテクチャ」じゃなくて、「アーキテクト」ですね。
          「優秀なアーキテクチャ」とか一瞬意味がわからなくて戸惑うので、今後は修正を望みます。

          親コメント
    • by Anonymous Coward on 2011年07月31日 22時21分 (#1995437)
      以前、本気でこういうことを言う上司の下にいたので笑えない…
      親コメント
    • by Anonymous Coward on 2011年08月01日 11時14分 (#1995631)
      javaの遅さってインタプリタだからなんでしょうかね。

      個人的には起動時のクラス読み込みなんかが終わると問題ないスピードで動いてると思います。

      親コメント
    • by Anonymous Coward

      >どんなに工夫しても所詮はインタプリタだから遅いし、
      ネタにしてもコレは古すぎるぞ。
      JITコンパイラもないって、どこの環境の話だ。
      #ケータイ上?でもケータイでCOBOLは動かないと思う。

      >どこでも動く的な話は夢であることははっきりしてきたし、、、
      夢じゃなくOSのバージョンが変わっても同じアプリが動いてるのは、
      さすがJavaってとこなんだけど。

      今ままでだと、XPとVistaで同じアプリが動きますなんて夢物語だったもんね。
      SolarisとLinuxでも厳しいと思う。

      >コーディングルールとかの蓄積が無いからむちゃくちゃになるし
      http://www.amazon.com/dp/0521777682/ [amazon.com]

      まあでもCOBOLerがする反論って、今でもこのレベルなのは事実なんでしょう。

      • > 夢じゃなくOSのバージョンが変わっても同じアプリが動いてるのは、
        > さすがJavaってとこなんだけど。

        うーん、そうですか?
        私のところでは、OS変わっても同じJavaアプリが動いていたのに、バージョンが変わったら突然、印刷が文字化けするようになりました。(自分が書いたプログラムではなかったので、何が問題なのかとうとう分からなかった・・・。)
        そのアプリを使うために、古いバージョンを入れなおして、バージョン指定して起動するように設定を弄る必要がありました。

        なので互換性に関しては、Java開発陣営もWindowsの事は言えないなぁ。と思いましたよ。
        (多分、Java開発陣営は現時点に至るまで互換性を維持できているなどと、今もって驕ったりはしないと思います。むしろ、互換を信じているのはアプリ開発者の方で・・・)

        正確に互換性を堅持する、というのはどこの世界でも高い難易度を持つ開発だと思います。
        拡張に想定外はつきものですから。
        バグ修正で互換性を損なう事もありますから。
        仕様が変更されれば互換性も捨てられますし。

        まあ、一介のアプリ開発者が互換性の問題に気づくかどうかというと、それには相応の経験とか情報収集とかが必要なのでしょうけど。
        私もOSや言語の互換性に関する文書は可能な限り読んでますが、それでも問題に直面するまで気付かないことも多々ありです。

        よって、「○○は互換性の問題がない」みたいな話は、常に猜疑心に満たされます。

        親コメント
      • by Anonymous Coward
        >今ままでだと、XPとVistaで同じアプリが動きますなんて夢物語だったもんね。

        こういうこと書くから、java使いって、こんな認識なのか、と思われちゃうんですよ。
        javaがインタプリタってのといいとこ勝負。
      • by Anonymous Coward

        > JITコンパイラも

        それを指して(#1995293 [srad.jp])で「工夫」と言っています。
        コンパイルなんかビルド時にやれば十分。
        本当にVMの用意だけでそのまま動くならJITコンパイラもいいけど、環境変えたらどうせ修正+リコンパイルなのだから。

        > #ケータイ上?でもケータイでCOBOLは動かないと思う。

        例外や、下を見たらきりが無くて。
        Javaもまともに動く環境はあまり無いし、せいぜいUI担当程度しかできなくて、Flashに完敗しいているし。
        本体となる部分の処理やサーバー側のサービスはJava以外でやっているしね。

        > 夢じゃなくOSのバージョンが変わっても同じアプリが動いてるのは、
        > さすがJavaってとこ

      • by Anonymous Coward
        こっちの釣針もでかいな
  • --
    誤記 FireFox
    巫女 Firefox [mozdev.org]
  • by Anonymous Coward on 2011年07月31日 20時22分 (#1995395)

    が、今後のJavaの方向性を示していて、何気に重要な気がします。
    Java以外の言語のための機能を追加するということは、Javaが単なる言語からプラットフォームへと変質してきているということなのでしょう。
    ひょっとしたら十年後ぐらいには、Javaという言語自体は廃れてしまっていて、JVMは全く別の言語のためのプラットフォームという扱いになっているかもしれませんね。
    (そういう意味で、上のほうでJavaだけ見てコーディングが大変だの言っているのは、あまりに古臭い考えかと。そもそも別に大変だと思ったことはないが・・・。)

    と言いつつ、個人的にはProject Coin [hatena.ne.jp]の微妙な構文改良の方が嬉しかったり。
    うん、大変だと思ったことは無いが、面倒くさい構文は多々あるんだよな。
    Stringのswitchだのマルチキャッチだのリソース付きトライだの型推論だの、ほんとなんで今まで対応されてなかったのか(嘆

typodupeerror

アレゲは一日にしてならず -- アレゲ見習い

読み込み中...