サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
www.javainthebox.com
このエントリーは Java Advent Calendar の9日目のエントリーです。 qiita.com Virtual ThraedはJava 19でPreview (JEP 425)、Java 20でSecond Preview (JEP 436)となり、うまくいけば次のLTSであるJava 21で導入予定です。 パフォーマンスを考える時に、一般的にはスループットと応答性の2つがあります。スループットは単位時間あたりにどのくらいリクエストをさばけるか、応答性は処理のリクエストから結果が帰るまでの時間です。Virtual Threadのこの2者のうち、スループットを向上させるために導入されます。 では、なぜ今になってVirtual Threadが導入されるのかということを、歴史を振り返りながら考えてみるのがこのエントリーです。 いにしえの時代 - Java 1.0からJ2SE 1.4
半年ぶりの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
今日のあさイチのセッションはチュートリアルだと思っていたらハンズオンだったので、自主休講。ちゃんと朝起きたのに... JavaFX のハンズオンだったのですが、コントロールを自作しようというハンズオン。昨日のセッションの内容ともかなりかぶっていたのでした (はじめに CSS で見栄えを変えて、次にスキンを入れ替えてというようなぐあい)。 かといって、代わりに聴講したいセッションもなかった >< ということで、今日、聴講したセッションです Modules and Services [CON2949] Connecting Oceans with Project Panama: A Journey into Native [CON1471] Project Jigsaw: Under The Hood [CON2963] Thinking in Parallel [CON5051] これ以外に
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 年ぶりに東京で開催される JavaOne です。もちろん、フル参戦です。 寺田さんが早く来てくれと blog や Twitter で呼びかけていたせいか、みなさん来るのが早い。8 時にはすでにエレベータ前に行列ができてました。もちろん、私も 8 時に来ましたけど。 9 時のキーノートまでの間、会場をうろうろ。やっぱり狭いのはしかたないのかなぁ。 今回は森タワー 49F のアカデミーヒルズ 49 が会場。でも、40F のアカデミーヒルズ 40 だとばっかり思っていました。2005 年に行われた Java Computing 2005 Spring が開催された場所です。 ところが、今は 40F はイベントの会場として貸し出してないみたいですね。残念。40F の方が全然広いんだけどなぁ.... アカデミーヒルズ 49 はライブラリーに使われているところと、アカデミーヒルズのセミナ
このエントリは Java Advent Calendar 2011 の一環で、第 1 日目のエントリーです。 やっぱり、櫻庭といえば Java SE の新しいところでしょう (これ去年も書いたなぁ ^ ^;;)。ということで、Java SE 8 の目玉機能となっている Project Lambda を取りあげます。 結果的に超長文になってしまいましたww 厳密にいえば、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のアップデートです。 Java 22は、LTSであるJava 21の次のバージョンですが、意外と新機能盛りだくさんです。 Java 22のJEPは以下の12。しかも、スタンダードJEPが4もあります。 423: Region Pinning for G1 447: Statements before super(...) (Preview) 454: Foreign Function & Memory API 456: Unnamed Variables & Patterns 457: Class-File API (Preview) 458: Launch Multi-File Source-Code Programs 459: String Templates (Second Preview) 460: Vector API (Seventh Incuba
今日は 2 日目ですが、日曜日にもイベントがあったので 3 日目のような気がしてなりません。 上の写真は OOW/JavaOne のためにペプシなどを搬入しているところなのですが、量が半端じゃないです。写真には写ってませんけど、このとなりにペプシが山になってます。 参加者が多いのはこういうところでも分かりますね。 そういえば、昨日朝ごはんがあることを知ったので、見にいってみました。 去年はパックに入ったドーナツ 2 個だったのが、食べ放題になったのはいいですね。でも、もっと早い時間からにしてくれないと、使えない!! さて、今日、聞いたセッションは以下の通り。 Technical Session S314629 HTML5 and Java: Opening the Door to New Possibilities S314557 The Modular Java Platform and
今日から JavaOne 本番です。 今日は 8 時から OpenWorld の Keynote があるのですが、それはパス。なので、セッション会誌の 10 時までゆっくりできます。 まずは朝ごはんを食べに行かないと。ということで 7:30 ぐらいに Hilton にいってみたのですが... どこにも朝ごはんがない!!! だいたいパンフレットにも朝ごはんの場所も書いてない。まさか、ほんとに朝ごはん抜きなの!! 去年の JavaOne と比べてもしかたないのですが、毎年 7 時から朝ごはんが提供されていたのに比べると、今年はどうなっているのだろう? Twitter にも朝ごはんがないというツィートが。その中で、@masafumi_ohta さんが、Press/Blogger だったらプレスルームでごはんを食べられるよと教えていただきました。 しかたないので、Moscone までテクテク歩いて
<その 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 に投げているだけなの
このページを最初にブックマークしてみませんか?
『Java in the Box Annex』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く