Tsurugi Advent Calendar 2024の15日目です。
Iceaxeは、JavaでTsurugiにアクセスするプログラマー向けライブラリーです。
今年は以下のような変更がありました。
Iceaxeの変更はだいたいTsubakuroの変更に伴うものですが、こうして見返してみると、そうでないものもちょくちょくありますね。
Tsurugi Advent Calendar 2024の14日目です。
2024/12/12に、スーパーフォーミュラでTsurugiを使ったニュースが出ていました。
このニュースのTsurugiに関する部分は、5ミリ秒間隔でスーパーフォーミュラカーの車載データをUDPで受信してTsurugiに入れ、同時に5～20ミリ秒間隔でAIの推論処理を行った（Tsurugiからデータを取得した）、というところでしょうか。
Tsurugiはwrite heavyな用途に向いていると言われていて、スループット重視なRDBMSです。逆に言うと、レイテンシー（低遅延）が要求される使い方は得意ではないということだと思います。
また、TsurugiはインメモリーDBなのでメモリー上で全てを処理しますが、ローカルディスクへのトランザクションデータの保存（永続化）も行います。
それでも今回のような時間間隔で処理できたということですね。
それと一貫性に関して、Tsurugiのトランザクション分離レベルはシリアライザブルですが、それでも読み書きが同時に処理できたということになります。
（他のRDBMSでシリアライザブルにして同じことを実行したら、アボートしまくりのような気がします＾＾；）
Tsurugi Advent Calendar 2024の10日目です。
Tsubakuroは、JavaでTsurugiにアクセスする基本となるライブラリーです。
今年は以下のような変更がありました。
Tsubakuro内部の作りについては他にも変更がありますが、プログラマーから使えるAPIに関する変更はこんなところですかね。
Tsurugi Advent Calendar 2024の8日目です。
Tsurugi SQLコンソール（tgsql）は、TsurugiでSQLを実行するCLIツール（REPL）です。
今年は以下のような修正が入りました。
使い勝手に関するところはあまり変わってませんね＾＾；
使用できるSQLの構文が増えても、それはtgsqlの変更ではないですからねぇ…。
Tsurugi Advent Calendar 2024の7日目です。
昨日（2024/12/6）のPostgreSQL Conference Japan 2024で、Tsurugiに関する講演があったようですね。
自分は参加していないのですが、ブログを書いている方がいらっしゃいます。
Tsurugiに関してどんな話があったのか知りませんが、何かすごかったらしい(笑)
ここで、なぜPostgreSQLのカンファレンスでTsurugiの講演があるのか説明しておきましょう。
Tsurugiの開発当初は、PostgreSQLをフロントエンドにして、バックエンドとしてTsurugiを使うという構想がありました。
ユーザーからはPostgreSQLを触っているように見えるので、PostgreSQLカンファレンスでTsurugiの講演がされていたのです。「TsurugiはPostgreSQLの皮を被ったRDBMS」のような言われ方をしていましたね。
フロントエンドをPostgreSQLに任せると、ユーザー認証（パスワードの管理）やテーブルのメタデータの管理（create文やalster文）にはPostgreSQLの仕組みが使えるので、Tsurugiでは実装しなくて済むということになります。
しかし開発中に方針が変わり、Tsurugiは単独で（フロントエンドが無くても）動作するようになりました。
そんなわけで、ユーザー認証やalter文は後回しになっているわけです…。（さすがにcreate tableが無いと何も出来ないので作られたようですが＾＾；）
ただ、JDBCに関しては、PostgreSQLのJDBCを使用するという方針から変わっていません。
TsurugiにJavaでアクセスするライブラリーであるIceaxeはJDBCではないので（Tsurugiの機能をフルに使えるようにするというのがIceaxeの方針なので、JDBCの形になっていない）、既存のJavaアプリケーションからIceaxeを使ってTsurugiに乗り換えるのはなかなか難しいでしょう。
PostgreSQLのJDBCを使うためには、PostgreSQL FDWの機能を使ってTsurugiにアクセスできるようにする必要があります。Tsurugiの書籍の第7章で紹介されている機能ですが、もっと便利に使えるように改修中らしいので、期待しています！
Tsurugi Advent Calendar 2024の3日目です。
Tsurugiにアクセスするクライアントツールやライブラリーを簡単に紹介します。
Tsurugi Advent Calendar 2024の2日目です。
Tsurugi本体のバージョンは、初公開されたものがTsurugi 1.0.0-BETA1で、その後BETA2, BETA3…とバージョンアップしてきました。
今年の9月にBETAが取れてTsurugi 1.0.0となり、現在のバージョンは0.1上がってTsurugi 1.1.0、次のバージョンは1.2.0になる見込みです。
一方、TsurugiにJavaでアクセスする為の通信ライブラリーであるTsubakuroのバージョンは、初公開時が1.0.1で（1.0.0はリリースミスがあったため、すぐに1.0.1が出ました＾＾；）、その後Tsurugi本体がバージョンアップするのに合わせて1.1.0, 1.2.0…と0.1ずつ上がってきました。
そして、Tsubakuroを使用しているJavaライブラリー（高レベルAPIであるIceaxe）やJavaアプリケーション（Tsurugi SQLコンソール（tgsql）や原価計算ベンチマーク・請求処理ベンチマーク等）のバージョンはTsubakuroのバージョンと一致しており、Tsubakuroのバージョンアップに合わせてバージョンが上がっています。
そういうわけで、Tsurugi 1.1.0に対応するJavaライブラリーやJavaアプリケーションのバージョンは1.7.0です。
バージョンの値がずれていて分かりにくいですが＾＾；、そもそも、Tsurugi本体のバージョンアップとクライアントライブラリーのバージョンアップは同時に行われるとは限らないものです。今後、開発が安定してくれば、Tsurugi本体のバージョンが上がってもクライアントライブラリーのバージョンは上がらないことが有り得えると思います。
ちなみに、Tsurugi公式ではなく自分が個人的に作っているTsurugiのEmbulkプラグイン（embulk-input-tsurugidb・embulk-output-tsurugidb）もTsubakuroを使っていますが、初公開が0.1.0で、その後は0.0.1ずつバージョンアップしてきました。
Tsubakuroのバージョンアップだけでなくプラグイン本体の修正でもバージョンアップしてきたので、対応するTsurugiのバージョンとは、さらに不一致でした＾＾；
なので、Tsurugiが1.0.0になるのに合わせてプラグインも1.0.0にしました。これなら分かりやすいと思います！
…しかしこれを書いていて思ったんですが、今後、Tsubakuroのバージョンが上がらなくなったらプラグインのバージョンも上がらなくなるので、そうしたらTsurugi本体のバージョンとは乖離してしまいますねorz
Tsurugi Advent Calendar 2024の1日目です。
『Tsurugi』は、メニーコア・大容量メモリーをターゲットとしたOSSのRDBMS（インメモリーDB）です。
Tsurugiは数十コア～100コア超でスケールすることを目指しています。（10コア以下ではPostgreSQLの方が性能が良いらしいです）
昨年10月に初公開となるTsurugi 1.0.0-BETA1がリリースされ、その後BETA2, BETA3…とバージョンアップしてゆき、今年の9月にTsurugi 1.0.0（BETAが取れたGA版）となりました。
1.0.0になってもSQLの機能的にはまだ足りない部分もあるのですが＾＾；、1.0.0（GA版）がリリースされたことにより、商用サポートも始まりました。
現時点の最新バージョンは1.1.0であり、今後もまだまだバージョンアップしていくと思われます。
最近Rustを勉強していたので（といってもj4rsを使ってJavaを呼び出して遊んでいたので、Javaから離れていたわけではないぞ(爆)）、Java23が出たのに調査がちょっと遅れてしまった＾＾；
しかし、さくらばさんが『JEPでは語れないJava 23』で今回はそれほど変化は無いと書いている通り、APIの変更という意味では確かに目ぼしいものは無かった…。（だから今回きしださんはブログを書いてないのだろうか＾＾；）
でもそんな中で青天の霹靂だったのが、マークダウン形式Javadoc！
プレビューも無かったし、そんなものが導入されるとは全く思ってなかった＾＾；
（ちなみにマークダウン形式Javadocは「/**～*/」ではなく「///」を使う。ちょうどRustを勉強していたので「Rustと同じじゃん！」と思ったけど、勉強してなかったら「なんだそりゃ」と思ったことだろう…）
最新版のEclipse（Java23プラグイン導入済み）だと「///」の行でEnterを押したら次の行も「///」を入れてくれるし、ポップアップでちゃんとJavadocとして表示してくれるので、十分便利だ。（まだ多少バグがあるようだけど、すぐに修正されていくだろう）
最近は（GitHubのissueとかで）けっこうMarkdownで文章を書いているので、マークダウン形式Javadocもちょっと書いてみたけど、ほとんど違和感ないですね。素晴らしい。
あと、今回新しくプレビュー版機能に追加されたプリミティブ型のパターンマッチ。
他の言語だと普通に出来ていることがJavaでも出来るようになる感じだけど、旧バージョンとの互換性を崩さずswitchとかinstanceofに徐々に機能を追加していって、ようやくJavaでも出来るようになった、というのがいかにもJavaっぽい(笑)
その他のプレビュー版機能はほとんど繰り越しのようだけど、コンストラクターでsuper()呼び出しの前に文を入れられるという機能にちょっと変化があった。
親インスタンスの初期化前に自クラスのフィールドを初期化できるようにするというもので、「マジか？！」って思ったんだけど、さくらばさんはニーズはほとんど無いだろうって書いてましたね(汗)
自分は、親コンストラクターから子クラスでオーバーライドされたメソッドを呼んだけどフィールドが未初期化でnullのままなので「うぅ…」ってなった経験があるので、ニーズが無いことはないと思います、はい＾＾；（あまりやるべきじゃないんでしょうけどね、ええ、分かっておりますともorz）
2024/3/19にJava22が出たので、例によって調査。
今回の目玉は無名変数。
tryで「_」が使えるようになったのは嬉しい。
それと、複数ファイルソースコードの実行。
単一のソースファイルをjavaコマンドで直接実行することは以前から出来ていたけど、今回、複数のソースファイルを参照してくれるようになった。
（ちなみに単一のソースファイルから直接実行って、Java11からだったんだなぁ。もっと最近かと思ってた＾＾；）
それと、一部の人にとって待望のForeign Function & Memory APIがついに正式版になったようだ。
自分個人としては使う機会があるかどうか分からないけど＾＾；
Java22ではプレビュー版の機能がかなり多い。
しかも、今回新しく追加になったプレビュー版機能もなかなか期待大。
（翌日追記）
Class-File API使ってみた。なかなか楽しいｗ
