はてなブックマーク

半年ぶりのJavaのアップデートで、Java 19がリリースされます。 Java 19はJava 18よりJEPは少なく、しかもPreviewやIncubatorでないJEPはJEP 422のLinux/RISC-V Portしかありません。こんなアップデートは初めてかも。 405: Record Patterns (Preview) 422: Linux/RISC-V Port 424: Foreign Function & Memory API (Preview) 425: Virtual Threads (Preview) 426: Vector API (Fouth Incubator) 427: Pattern Matchning for switch (Third Preview) 428: Structured Concurrency (Incubator) JEP 424の

恒例の半年ぶりのblog更新です。 アメリカ西海岸時間の9月14日にJava SE 17がリリースされました。今回のJava 17は多くのディストリビュータがLTSにするバージョンなので、注目度も高いのではないでしょうか。 まぁ、常に新しいバージョンに移行している身にとってみては、LTSはあんまり関係ないんですけどねw また、Oracle JDKが無償で使えるとか、LTSが2年周期になるとかいろいろ話題はあるようですが、ここでは触れないでおきます。 Java 17では17のJEPが導入されました。その中でPreviewがProject Amberによるパターンマッチング、IncubatorがProject Panama関連の2つがあります。 文法ではSealed ClassがPreviewが外されて、正式に導入されました。その他に注目すべきJEPとしてはMacのM1チップ用の移植があります

Javaのアップデートでしか更新しないようになってしまいましたが、半年ぶりのblog更新ですw ということで、アメリカ西海岸時間の3月17日にJava SE 14がリリースされます。 今回もJEPに含まれていないAPIの変更をメインにJava 14についてまとめていきます。 とはいうものの、Java 14は16もJEPがあります。特にProject Amberがらみの文法変更や、ZGCがWindowsとOS Xに対応したことなどが注目されてますね。 そして、久しぶりにIncubator ModuleがJEPで提案されました!! Project Panamaで策定されているForeign Funtion Interfaceに関連するモジュールで、ヒープではないメモリへのアクセスを行うためのAPIです。 JEPに関する変更はまた別の機会に書くとして、本エントリーはJEP以外のAPIの変更につい

アメリカ西海岸時間の9月17日にJava SE 13がリリースされました。 ちょうどサンフランシスコではOracle Code Oneが開催されていて、櫻庭も参加しています。OC1に参加しているのでなかなか書く時間がとれないのですが、恒例となっているのでJEPで提案されている以外のJava SEの変更をまとめておきます。 Java SE 13も変更はかなり少ないです。提案されたJEPは5個。ライブラリに関するJEPはなく、言語使用に関するJEPが2つです。 1つがswitchが文から式になるということ(JEP 354)。Java SE 12でもPreview機能で入っていましたが、再検討されて新たにPreview機能として入っています。値を返す時のyieldが一番の違いです。 もう1つが、テキストブロック(JEP 355) こちらはJava SE 12で入らなかったJEP 326 Raw

アメリカ西海岸時間の3月19日にJava SE 12がリリースされます。 恒例となっているJEPで提案されている以外のJava SEの変更をまとめておきましょう。 全般的にいえるのが、Java SE 12の変更がかなり小規模だということ。言語仕様的にはswitchが文から式になったことが大きいですが、APIの変更はほんとにちょっとしかありません。 今回もABC順にならんでいます。同じように、セキュリティ系のAPIはちゃんと理解していないので、省略してます。 廃止になったAPI Java SE 12では5つのメソッドが廃止になっています。 いずれも、Java SE 10で@DeprecatedのforRemovalがtrueになったメソッドです。つまり、forRemovalがtrueになってから1年で廃止ということです。 java.io.FileInputStream.finalize()

今日の早朝、Java SE 11がリリースされました。 Java SEの機能はJEPでまとめられていますが、JEPに入っていないこまごまとした変更もいろいろ入ってます。ということで、Java SE 10に引き続き、Java SE 11についてもまとめてみます。 量が多いので、今回はjava.baseモジュールだけです。他のモジュールも引き続きまとめるつもりです。 基本的にはABC順にならんでいます。重要度順にしようかと思ったのですが、量が量なので... また、セキュリティ系のAPIはちゃんと理解していないので、省略してます。 廃止になったAPI Javaは互換性を重視する言語ですが、Java 9から使われなくなった機能はほんとに削除対象になっています。 Java SE 11でも多くのAPIが廃止になっています。 Java 11で一番大きな非互換性となるのが、Java EE関連のモジュールの

前回の続き。 もし、どうしてもモジュールアプリケーションにしたいという場合を考えてみます。 普通のアプリケーションであれば、そんなに急いでモジュール化する必要は私はないと思っています。ただし、ライブラリを開発している場合は、なるべく早くモジュールに対応してほしいです。 前回のサンプルはライブラリではないのですが、モジュール化する場合もあるでしょうし、とりあえずやってみましょう。 前回のサンプルはJersey + Grizzly の単純なアプリケーションでした。 このサンプルは 2 つのクラスから構成されています。リソースを表すMyResouceクラスと、アプリケーションの起動クラスとなるMainクラスです。いずれもcom.exampleパッケージにあります。 MyResourceクラスはこちら。 package com.example; import javax.ws.rs.GET; im

Java SE 11のリリースまで3か月を切りました。みなさん、移行の準備は進んでいますでしょうか。 Java SE 11は、新しいリリースモデルになってはじめてのLTSになるバージョンです。なので、Java 9や10はすっ飛ばして、Java 11に移行することを考えている方も多いと思います。 しかし、Java 11への移行はいろいろ大変です。 今回は簡単なサンプルをベースにJava 11への移行を考えてみます。 Jersey + Grizzly Jerseyは、JAX-RSのRIです。ということは、私よりもこれ読んでいる人の方が絶対に詳しいはずw そのJerseyのUser GuideのGetting Startedに書いてあるサンプルを題材にしてみましょう。 このサンプルはMavenで勝手に作ってくれます。以下はGetting Startedからの引用です。 mvn archetype

今日リリースされる Java SE 10 の注目機能といえば var の導入ですね。 var の導入などの機能は、OpenJDK の JEP (JDK Enhancement Proposals) で管理されています。たとえば、var の導入は JEP 286 です。 Java SE 10 では 12 の JEP が機能として導入されます。 ところが、JEP になっていない変更といのが、けっこうあるのです。そこで、このエントリーでは、JEP になっていない機能をまとめてみました。 JEP になっていないぐらいなので、かなり細かいです。 廃止になった API Java SE 9 で、@Deprecated アノテーションに forRemoval が追加されました。この値が true なものは、ほんとに削除されることになっています。 Java SE 10 では Java SE 9 で forR

JavaOne は iOS と Andoroid 向けの公式アプリがあるのですが、私の iPhone ではまったく動いてくれません ＞＜ 動いていても、Web から登録したセッション情報を同期できないなど、できが悪すぎ。 よっぽど、Gluon が JavaFX で作ったアプリの方がサクサク動いてます。セッションの登録情報を表示できれば、Oracle のアプリは使わないんだけどなぁ。 というわけで、今日聴講したセッションです。 Adventures with Extreme Types in a Purely Functional Language [TUT1288] JDK 9 Language, Tooling, and Library Features [CON2497] JavaFX: New and Noteworthy [CON2483] A Survey of Memory F

この記事は、Java Advent Calendar 2015 の 13 日目の記事です。 昨日は @cero_t さんのStream APIをつくろう でした。明日は opengl_8080 さんです。 JavaOne にいってから、Project Jigsaw で遊ぶことが多くなりました。で、モジュールを作った後の話を紹介します。ちょうど、JavaFX in the Box の方の このエントリー の後の話題のようなものです。 このエントリーでは JavaFX のサンプルのモジュールの依存性を調べたのですが、せっかく依存性を調べたのですから、モジュールを作ってみましょう。 サンプルはこれです。 package fxdemo; import javafx.application.Application; import javafx.scene.Scene; import javafx.s

このエントリは Java Advent Calendar 2013 の第 9 日目です。 昨日は、@nabedge さんの Mixer2のSpringMVC連携機能がver 1.2.17でさらに進化！ 明日は Satoyuki Tsukano さんです。 去年も一昨年も Project Lambda について書いてきました。一昨年は Project Lambda の基本的なところ (まだこの頃は Stream がありませんでした)、去年は Stream の遅延処理についてです。 今年はこの Advent Calendar でも Project Lambda や Stream を扱っている人がいるぐらい、興味を持っている人が増えてきたと思います。 普通の Stream の使い方とかは、当たり前なので、ちょっと違う視点から書いてみようと思います (普通の Stream の使い方は ITpro

このエントリは Java Advent Calendar 2012 の第 1 日目です。 去年の Java Advent Calendar も第 1 日目を書いて、しかも Project Lambda についてでした。 今年も Project Lambda について書くわけですが、去年とはちょっと観点を変えようと思います。 今年の JavaOne で Java SE の一番のトピックといえば、やっぱり Project Lambda だったと思います。実際、Keynote でも Brian Goetz が登壇して Lambda の説明をしていますし、セッションも Lambda だけで 5 つもあったほどです。 実際に Brian Goetz の Lambda のセッションに出て思ったのは、Lambda の言語仕様はほぼ固まったということです。そして、開発の中心は Lambda の実装方法や、

7/7 に東京、7/9 に札幌で Java SE 7 ラウンチイベントに登壇しました。 東京と札幌では基本的に同じ資料を使ってプレゼンをしました。JavaFX 2.0 は先月行った JavaFX 勉強会の修正版です。 で、思ったのはやはりプレゼンというのはストーリーが重要だということ。 Fork/Join Framework は全体を通して分かりやすいストーリーがあるので、自分でも話しやすいですし、聞いていただいている方たちにも分かりやすいだろうなと思います。 しかし、NIO2 は全体を通すストーリーを作れませんでした。前半はそれなりにちゃんと作り込んだんですが、後半がダメ。機能の羅列になってしまいました。 機能を羅列するにしても、それはそれなりのやり方があるはずです。機能を示すことは各論になりがち。でも、その機能が全体の中でどのような位置づけにあるかということを示せれば、より理解度が深ま

このエントリは Java Advent Calendar -ja 2010 の一環です。 さて、何を書こうかいろいろ悩んでいたのですが、やっぱり櫻庭といえば Java SE の新しめのところというイメージがあると思うので、新しいところを取りあげようと思います。 で、取りあげるのが Project Coin です。 Project Coin は Java 言語仕様の小さな変更を行なうためのプロジェクトです。昔の言い方であれば Ease of Development に相当して、もっと簡単に書けるようにすることが目的です。 この Project Coin は来年リリース予定の Java SE 7 で導入されます。ところが、Project Coin のほとんど機能はすでに OpenJDK に実装済みです。 ということで、すでに使える Project Coin を使ってみてみましょう。ここでは J

本エントリーはJava Advent Calendarの最終日です。昨日はzoosm3さんのDBFlute Examples有志募集中でした。 今年もJava Advent Calendarが無事完了してなによりですね。 さて、今日、紹介するのはJava 24で正式に導入されるStream Gathererです。JEPはこちら。 JEP 485: Stream Gatherers Stream APIはJava 8で導入されて、はや10年。もうStream APIなしにJavaのプログラムを書けといわれても、ムリとしかいえないぐらいですね。少なくともさくらばはそうなのですが、みなさんはどうでしょう。 とはいうものの、Stream APIが万能というわけではありません。文句をつけたくなるところも多々あります。本題とは違いますが、例外が扱いにくいのはほんとどうにかしてほしい... 中間操作の制

<その 1> <その 2> Java でサムネイルを作る方法についての最終回です。 前回、単純にバイキュービックなどの補間法でイメージを縮小しても、クオリティが低いということを書きました。 ところで、下のイメージを見比べてみてください。 右のイメージに比べ、あきらかに左の方がジャギが少ないと思いませんか。 この 2 つのイメージは両方ともバイリニアで縮小しています。違いは縮小率。 左が 50%、右が 48% です。 50% の場合、縮小した時に対応するピクセルは単純に求めることができます。4 ピクセルを 1 ピクセルにすればいいだけですから。 このため、品質が高いまま縮小が可能になるのです。これは最近傍だとだめなのですが、バイキュービックでも大丈夫です。ただ、パフォーマンス的にはバイリニアの方が速いので。 さて、ここで、発想を変えてみます。 つまり、縮小を 1 回で済ませなくてもいいのでは

<その 1> 前回はイメージを扱うクラスと、イメージのロード方法について書きました。 今回は BufferedImage クラスのデータ形式について書こうと思ったのですが... 検証用のサンプルで確かめていたら、J2SE 1.5 と Java SE 6 では実行結果が違うのです。グラフィックアクセラレータの使い方がかなり変わってきているようです。J2SE 1.5 まではアクセラレートされなかったものも、Java SE 6 ではアクセラレートされるようになっています。 このように、Java のバージョンによって処理アルゴリズムが更新され、過去のイディオムが使えないということもあります。古いバージョンで言われてきたことが、最新のバージョンでは違うということが多々あるので、そこらへんはご注意ください。 で、今回はイメージの縮小について。 イメージを縮小するには、複数の手法があります。g を Gr

Java でイメージ処理、特にサムネイルを作成する需要があるらしいのです。で、書き始めてみたのですが、結構分量になりそう。で、何回かに分けて書くことにします。 ぶっちゃけ結論だけ書いてもいいんですけど、それだと応用がきかないので基本的なところから。 Java のイメージ Java でイメージを扱うにはいくつかの方法があります。 java.awt.Image クラス java.awt.VolatileImage クラス java.image.BufferedImage クラス Imageクラスは Java でのイメージ処理の基本となるクラスです。ところが、このクラスのインスタンスは OS のイメージ処理に依存しています。 Windows であれば Windows のイメージ、Linux であれば Linux のイメージになるわけです。 もともと AWT は、処理を OS に投げているだけなの