OracleがJava 7 と Java 8のJSRを発表Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
IBMがOpenJDKの開発をオラクルと共同で進めると発表
IBM Press room - 2010-10-11 Oracle and IBM Collaborate to Accelerate Java Innovation Through OpenJDK - United States OpenJDKはサン・マイクロシステムズが中心となって開発してきたもので、同社がオラクルに買収された後はオラクルがそれを引き継いでいました。 IBMはそれとは別に、The Apache FoundationによるオープンソースなJava実装であるApache Harmonyに肩入れをしてきました。 しかし今回の発表で、両社は協力してOpenJDKの開発に注力することが明記されています。 Oracle and IBM will support the recently announced OpenJDK development roadmap, which ac
Javaのラムダ式導入に関する最新提案の雑なまとめ - 矢野勉のはてな日記
java7月頭に，Brian GoetzがJavaにおけるラムダ式導入に関する最新提案のドラフトを出しました。State of the Lambda 私はこの提案書と，提案書を元にした英語記事を読んだだけですが，Twitterで話していると，23日くらいにこの提案を元にしたソースがJavaのソースリポジトリにコミットされたらしい。ただし，中ではまだ議論続発してるらしい。ちなみに英語記事はラムダについての連続記事の4回目で，5回目ではWicketでラムダ式を使うとどうなるか，という考察が載っています。提案書のラムダ式とWicketの非整合部分についての考察で，Wicket好きの人は読んでみてもいいと思う。あと，空コンストラクタがないクラスについて提案書は明確なところ書いてないよね，みたいな指摘も。せっかくなんで，最新提案におけるラムダ式実装をまとめておきます。いままでのあらすじ最新提案書では
OutOfMemoryErrorが発生したときにきちんとJavaプロセスを殺す - nekop's blog
OutOfMemoryErrorが発生してもスレッドを異空間に葬るだけでJava VMはそのまま動き続ける場合があるけど、当然ながら状態に一貫性のない状態で動いている可能性があるわけで基本的にはとっとと死んで欲しいわけである。一般的に言うところの「不定」状態。OOMEはErrorであってふつうの例外ではなく、致命的なJava VMエラーを示すものである。OOME発生後にプロセス再起動しないでそのままどうこうしようというのは絶対に避けた方が良い。 例えばJDBCのコネクションオープンしてDBからデータを読み込んでるときにOOMEが起きた場合、JDBCコネクションは大抵オープンしっぱなしで回収はされなかったりする。OOMEではfinallyブロックが呼ばれる保証はない。JDBCコネクションリークくらいならまだ良い方だが、これは全てに当てはまる。A-B-Cといったセットになっている処理は例外など
クロージャ、Java 7には間に合わない可能性 | エンタープライズ | マイコミジャーナル
Java Programming Language 紆余曲折の末、2009年の末には次期JavaメジャーリリースであるJava 7にクロージャの機能が取り込まれる線が固いものになった。クロージャは開発者からときに熱狂的に支持される。さらに今回のケースでは高性能並列処理を簡単に記述するためにクロージャが有効であることから、関連するプロジェクトと加味してもJava 7での導入は固い線だとみられていた。 しかしOracleによるSun Microsystemsの買収後、事はどうも違う方向に進み出した可能性がある。David Flanagan氏がClosures in Java 7: Not Likely - davidflanagan.comにおいてそうした状況を簡潔に伝えている。JDK7の機能フィックスが6月の3週に控えているものの、クロージャ関連のプロジェクトのアクティビティが低下しており、
Windowsユーザの広範囲に影響、Java脆弱性 | エンタープライズ | マイコミジャーナル
Netcraft - Internet Research, Anti-Phishing and PCI Security Services NetcraftがJava Web Startにある脆弱性によってきわめて多くのWindowsユーザが危険にさらされる可能性があると警告している。これはjavawsコマンドを経由してJava仮想マシンに任意のオプションを渡すことができるというもので、この脆弱性を利用されると悪意あるJarファイルを対象のPCで実行される可能性があると説明されている。 説明によれば、この脆弱性の影響を受けるのはWindows向けに提供されているJava SE 6 Update 10以降のすべてのバージョン。この脆弱性を利用するコードはすでに広く公開されているため、次の回避策のうちどちらかを実施することが好ましいとされている。 脆弱性の回避方法 IEユーザはCAFEEFAC
2007-07-29
JavaScriptで使えるDIコンテナはないかなとGoogleで10分だけ探したけど見つからなかったので、作ることにしました!(予定) 何に使うの? MVCでUIを作ると、各レイヤー間の依存関係が何気に複雑になりがちです。 要素のイベントハンドラとコントローラの関連付けとか(View-Controllerの関連付け) モデルの変更を捕捉してUIを更新とか(View-Modelの関連付け) このあたりを一手にやってくれるコンテナがあったら、使えるかなと思うわけです。 コンセプト 超軽量。 計画 基本線、Guice風で。 型がないので、名前ベースでバインディング。 プロパティインジェクションのみサポート。 コンストラクタインジェクションはできなくはないけどあまり使い道なさそう。 メソッドインジェクションは・・・。getXX,setXXとかいちいち書かないよね? AOPも使えるようにする。 ア
Javaオブジェクトクラスメモ(Hishidama's Java Object Memo)
equalsメソッド オブジェクトが値として等しいかどうかを判断する。 （細かい条件はJavadoc参照。けど要するに等しければtrueを返せばいいのだ(爆)） →==演算子との違い （ただし、オーバーライドされていないデフォルトの状態では、実装は「this==otherObject」なので、==演算子と等しい。[2010-01-25]） equals()をオーバーライドして独自の比較を行うようにした場合は、hashCode()も相応の値を返すように実装しなければならない（らしい。ハッシュ値を使わないなら不要な気がしないでもないが）。 hashCodeメソッド ハッシュコード値を返す。 当メソッドは、 ハッシュテーブル（Hashtable）やハッシュマップ（HashMap）で使用される目的で存在しているらしい。 だからハッシュ系のクラスを使わないのであれば、hashCode()を実装する必
OutOfMemoryError発生！ その解決への近道とは
これらの情報を基に、OutOfMemoryErrorの障害発生原因を探ることとなる。 障害調査～メモリ領域を切り分ける～ まずは、GCログやOutOfMemoryErrorのエラー情報から、「Javaのどのヒープ領域（Javaヒープ、Permanentヒープ、Cヒープ）でOutOfMemoryErrorになっているか」「どれだけのメモリを確保しようとして失敗したか」を確認する。 前回記事で、OutOfMemoryのエラー情報からどの領域でメモリ不足が発生しているかを見分けるポイントについては紹介した。例えば、以下のような場合には（*1）からJavaヒープでメモリが不足していることが分かる。 java.lang.OutOfMemoryError: Java heap space <=======【*1】 at java.nio.CharBuffer.wrap(CharBuffer.java:
Java 7はいらない | taro-nishinoの日記 | スラド
Stephen Colebourne氏が"No more Java 7"を書いて、議論を呼んだことはJava関係者なら記憶に新しいことでしょう。日本でもマイコミジャーナルが"Java 7はいらない?"の題名で、それを取上げたのはいいのですが、Colebourne氏の言いたいことを十分に反映しているとは言い難く、あまつさえ、この記事の執筆者は英語を誤読していると思われる箇所があります（後で、具体的な一例を取上げます）。しかし、日本では殆どの人がこの記事を鵜呑み（殆どの人が氏のブログを読んでいないと思います。）にして、Colebourne氏の心の叫びを「OSS教信者の迷言」とか言って一笑に付した人が多く見受けられました（一流家気取りの何と多いこと）。私は早くから気付いていたのですが、Colebourne氏のブログを誰かが訳せば或る程度は理解されるだろうから、Java信者でもない（どころか、嫌い
Java SE 7は高速化する、Oracle JRockit技術マージ | エンタープライズ | マイコミジャーナル
Java Programming Language OracleはSun Microsystemsの買収によってJavaポートフォリオを手にいれた。これまでJavaが今後どうなるか不透明だったが、Oracle + Sun: Java Strategyにおいて計画が発表された。基本的にSunが計画していた案を踏襲しつつ、いくつかの変更を加えたものになっている。計画の概要は次のとおり。 Java開発を継続 Java SE 7は2010年のリリースを計画 Java SE 7のHotspot技術にJRockit技術をマージ Java SE 7の開発はモジュール化、動的言語対応、ハイパフォーマンス化の目標を踏襲 Java SEとJava MEの統合 JavaFX開発を継続 JCP (Java Community Process)を継続 GlassfishはJava EE参照実装として継続 Glass
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ibmURL(変更不可)
James Gosling氏、Oracleを退職
Javaに未修正の脆弱性、Webページを閲覧するだけで攻撃を受けるおそれ