rc2の go tool fix help を眺めていて気づいたのですが、リリースノートに記載のない errorsastype も登録されています。API自体の提案は #51945、モダナイザーのIssueは #75692です。
before/after
funchandle(err error) { - var nf *NotFoundError - if errors.As(err, &nf) { + if nf, ok := errors.AsType[*NotFoundError](err); ok { fmt.Println("key:", nf.Key) } }
Go 1.26で追加されたジェネリクス版 errors.AsType[T] への書き換えです。errors.As は第2引数に「エラー型へのポインタ」以外を渡すと実行時パニックという罠があり、ジェネリクス版はこれをコンパイル時に排除できます。変数のスコープもif文に閉じて、1行減ります。
fix版waitgroup: wg.Add(1) / go func() / defer wg.Done() の3点セットを wg.Go()に畳むモダナイザー
同じ sync.WaitGroup 対象、同じ名前で、片方はバグ検知・片方はモダン化という別物が同居していました。go1.26.5で go tool vet help waitgroup と go tool fix help waitgroup を叩くと、実際に全く違う説明が返ってきて確かに紛らわしいです。早めに修正できて良かったと思います。
さいごに
Go 1.27の go fix アップデートを紹介しました。1.27でも安全な書き換えしか行ないポリシーで開発されているため、安心して使えそうです。素敵！
そして、この攻撃は後から対策できません。移行を終えた後でも、それ以前に流れたトラフィックは保存された側の手元に残っています。移行が早いほど、守れる通信が増えます。期限の目安として、NISTはドラフト段階のNIST IR 8547で、量子コンピュータで破れる公開鍵暗号を2035年より後は使用できないものとする方針を示しています。RSA-2048相当の強度のものは、2030年より後は非推奨です。
Go 1.27ではcrypto/x509とcrypto/tlsもML-DSAに対応しました。x509.CreateCertificateに*mldsa.PublicKeyと*mldsa.PrivateKeyをそのまま渡せます。あわせて、標準ライブラリのソースツリーにある自己署名証明書の生成ツールcrypto/tls/generate_cert.goに--mldsaフラグが追加されました。
証明書を作る
$ go1.27rc2 run $(go1.27rc2 env GOROOT)/src/crypto/tls/generate_cert.go --host=localhost --mldsa 2026/08/06 00:26:49 wrote cert.pem 2026/08/06 00:26:49 wrote key.pem
カプセル化が破れる。type S struct{ *u } の場合、外部パッケージには u をアロケートする手段がこれまでありませんでした。もし案1を採用すると、呼び出し元で lib.S{A: 1} と書いた瞬間にコンパイラが暗黙に u をアロケートするため、コンストラクタを通らない「中身入りの S」を外部から作れてしまいます。これを避けようとすると「公開・非公開で挙動を分ける」という例外規則が必要で…とややこしいことになります
type User struct { Name string *SystemColumns // ★ポインタ } _ = User{Name: "子どもにせっかく甚平を買ったけど着てくれないの悲しい", Version: 1} // ./main.go:10:25: invalid implicit pointer indirection to reach Version
funcmain() { a := uuid.MustParse("f81d4fae-7dec-11d0-a765-00a0c91e6bf6") b := uuid.MustParse("F81D4FAE7DEC11D0A76500A0C91E6BF6") fmt.Println("a == b:", a == b) fmt.Println("map key:", map[uuid.UUID]string{a: "hello"}[b])
$ go run ./cmp a == b: true map key: hello sorted: [00000000-0000-0000-0000-000000000000 f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ffffffff-ffff-ffff-ffff-ffffffffffff]
var back User _ = json.Unmarshal([]byte(`{"id":"{D556AC56-0E8D-4A30-B7B0-647FE7A22ABA}","name":"Bob"}`), &back) fmt.Printf("unmarshal: %v 一致=%v\n", back.ID, back.ID == u.ID) }
$ go run ./jsondemo marshal: {"id":"d556ac56-0e8d-4a30-b7b0-647fe7a22aba","name":"Bob"} unmarshal: d556ac56-0e8d-4a30-b7b0-647fe7a22aba 一致=true
funcBenchmarkNewV4(b *testing.B) { for b.Loop() { uuid.NewV4() } }
funcBenchmarkGoogleNewV4(b *testing.B) { for b.Loop() { guuid.New() } }
funcBenchmarkNewV4Parallel(b *testing.B) { b.RunParallel(func(pb *testing.PB) { var u uuid.UUID for pb.Next() { u = uuid.NewV4() } runtime.KeepAlive(u) }) }
funcBenchmarkNewV7(b *testing.B) { for b.Loop() { uuid.NewV7() } }
funcBenchmarkGoogleNewV7(b *testing.B) { for b.Loop() { guuid.NewV7() } }
funcBenchmarkNewV7Parallel(b *testing.B) { b.RunParallel(func(pb *testing.PB) { var u uuid.UUID for pb.Next() { u = uuid.NewV7() } runtime.KeepAlive(u) }) }
funcBenchmarkParse(b *testing.B) { for b.Loop() { uuid.Parse(s) } }
funcBenchmarkGoogleParse(b *testing.B) { for b.Loop() { guuid.Parse(s) } }
funcBenchmarkString(b *testing.B) { u := uuid.MustParse(s) for b.Loop() { _ = u.String() } }
funcBenchmarkGoogleString(b *testing.B) { u := guuid.MustParse(s) for b.Loop() { _ = u.String() } }
一方、Proposal #74609を経てGoへ取り込まれた機能では、自動回復を採用していません。Proposalでは、論文の実装からの主な変更として、リークしたgoroutineとそのスタックからのみ到達可能なリソースを強制回収しないこと、goroutineleakプロファイルの取得を契機に検出用GCサイクルをオンデマンドで実行することが明示されています。なお、Go 1.27リリースノートには「Special thanks to Vlad Saioc at Uber for contributing this work.」と、この機能に貢献したSaioc氏への謝辞が記されています。
total 3は検出されたリークgoroutineの合計です。行頭の3は同じスタックに集約されたgoroutine数、@以降は各スタックフレームのPC値（プログラムカウンタ）、#行が関数名とソース位置を示します。3つのgoroutineが同じ箇所（main.go:15の受信待ち）でリークしているとわかります。
1つ注意点があります。リリースノートには「Marshaling and unmarshaling behavior is preserved, but the exact text of error messages may differ.」とあり、挙動自体は互換が保たれますが、エラーメッセージの文言（err.Error()の文字列）は変わり得るとされています。err.Error() == "..."のような文字列完全一致でテストしているコードは、Go1.27で壊れる可能性があります。エラーは文字列ではなく errors.Is / errors.As で判定するのが、よいプラクティスです。
深堀り2：format タグが標準から外れた
Go1.25 / 1.26のexperimentalでは、フィールドのエンコード表現を構造体タグで指定する format オプションが使えました1。例えば time.Time は本来RFC 3339形式の文字列でエンコードされますが、format:RFC3339 と明示的に書くこともできましたし、Formatメソッドが解釈できる任意のレイアウト文字列（例: format:"2006-01-02"）を指定して表現を変えることもできました。
type Event struct { At time.Time `json:"at,format:RFC3339"`// "2026-07-30T00:00:00Z" のような表現 }
この format タグはGo1.27の標準APIからは外れます（#79071）。Go言語自体にtyped struct tagsを導入する提案（#74472）を見越し、パッケージ内に専用のDSLを持たせない方針への転換です。
// Go 1.26 以前は syntax error: method must have no type parameters func(s *Stack[T]) Map[U any](f func(T) U) *Stack[U] { ... } // ^^^^^^^ メソッド独自の型パラメータ U
また、ジェネリックメソッドはインターフェースのメソッドの実装としては扱われません。 例えば、以下の例では、 S が Map メソッドを持っていても、I を満たしません。
package main
type I interface { Map(f func(int)int) []int }
type S struct{} func(S) Map[U any](f func(int) U) []U { returnnil } // ジェネリックメソッドである S.Map は、I.Map の実装としては扱われない var _ I = S{}
funcmain() {}
コンパイルしようとすると、以下のエラーが出ます。
main.go:9:11: cannot use S{} (value of struct type S) as I value in variable declaration: S does not implement I (wrong typefor method Map) have Map[U any](func(int) U) []U want Map(func(int) int) []int
“This limitation prevents to define functional-like stream processing primitives … Allowing type parameters in methods would allow constructing DSLs that would greatly simplify some existing use cases.” — mariomac, #49085 本文
“What people do want is to have methods like Map/Filter/Reduce on iter.Seq[T], to allow chaining those calls and reading them left-to-right.” — Merovius, #77273 (comment) (2026-02-15)
package p2 // HasIdentity is an interface that matches any type with a // parameterized Identity method. type HasIdentity interface { Identity[T any](T) T }
The fact that I could only find four examples today in ten minutes of research is a double-edged sword. On one hand it’s proof that basically noone wants more than two sections. （10分の調査で4例しか見つからなかったという事実は諸刃の剣です。一方では、基本的に誰も2つ以上のセクションを望んでいない証拠と言えます。）
この点に対して、2026年6月末、rc1リリース直後のタイミングで cmd/go: mod tidy unconditionally joining all go.mod “require” sections in Go 1.27 loses intentional grouping #80210 が起票されました。報告者の arp242 さんは、// Things I maintain（自分がメンテしているもの）、// golang.org/x、// Google cloud and its large dependency tree のようにドメインごとにブロックを分けて運用しており、gotipでtidyしたらすべて失われた、という報告です。主張も明快です。
Personally I rarely care if something is a direct or indirect dependency – I care about who maintains it: our team, me, the Go team, or some random internet person. （個人的には直接依存か間接依存かはほとんど気にしていません。気にするのは誰がメンテナンスしているかです。自分たちのチームか、自分か、Goチームか、それともどこかのインターネットの誰かか。）
You’re right that we didn’t do the analysis for this. This is exactly the kind of feedback we’re looking for. （この件について分析を行わなかったというのはその通りです。これはまさに私たちが求めていた類のフィードバックです。）
その上で、コメントなしブロックの扱いについては明言しています。
We’re definitely going to keep the behavior of folding blocks that don’t have comments for Go 1.27. （コメントのないブロックを畳み込む挙動は、Go 1.27で確実に維持します。）
つまり争点は「コメント付きブロックを畳むか（rc2の挙動）、触らないか（1.26の挙動）」に絞られています。arp242 さんは「事故で増えたブロックにはほぼコメントが付いていないはずなので、コメント付きだけ除外すれば両取りできる（I think we can have our cake and eat it too here）」と主張し、逆に元Issue側の立場の thediveo さんは全部畳んで欲しい派で、必要なら -keep-separate フラグでも良いとコメントしています。オプションをつけないのがGoの良いところだと思っている派なので、どうにか上手くまとまることを祈りたい..。
Go 1.27にあげつつ、ブロックの分割を守る方法は私の理解では存在しません。正確に言うと先述の通り、#80210 の結果次第です。
Q. そもそも増殖の一因である go mod edit 側の仕様を直せば良いのでは？
go mod edit -require が最後のブロックに追記する挙動は、1.27rc2でも変わっていません。そもそも増殖は go mod edit だけでなく、手動編集やGitのコンフリクト解消の過程でも発生するため、go mod edit を直しても問題は完全には解消しません。また、 go mod tidy でフォーマットを行う方法は gofmt と似ているように思え、どのようなツールやコード生成が吐くコードが不揃いでも、フォーマッタを通せば単一の形式に収束するという構図はGoらしさを感じました。
間接依存の行は go mod tidy が機械的に出し入れするもので、人間がコメントを書き添える対象は基本的に自分の意思で追加した直接依存のはずだ、という想定が背景にあると読み取れます。実際 #80210 でも「ブロックにはコメントを付けておらず、個々のモジュール行にだけ付けている」「ブロックレベルのコメントは使ったことがない」という声が寄せられており、間接依存側にブロックコメントが書かれるケースは相当に稀のようです。とはいえ「間接側にコメントは無いだろう」という想定で一律に寄せてしまうのは、互換性に慎重なGoチームにしては珍しく強気な設計判断で、個人的には意外に感じています。
さいごに
Go 1.27の go mod tidy の require ブロック自動マージについて紹介しました。
]]>Go 1.27でgo mod tidyに追加されたrequireブロックの自動マージについて紹介します。Go 1.27リリース連載：インデックス+HTTP/3(定期観察)+SIMD(第2弾)https://future-architect.github.io/articles/20260728a/2026-07-27T15:00:00.000Z2026-07-27T15:00:00.000Z澁川喜規
The Go gopher was designed by Renee French.
Go 1.27もそろそろ近づいてきたようです。Future Tech Blog恒例のGoリリース連載です。
funcmain() { group, _ := q.FindByID(ctx, 1) if group == nil || group.R == nil { return } for _, user := range group.R.Users { if user.R == nil { continue } for _, todo := range user.R.Todos { // todo に関する処理 } } }
SeaORM から生成されるモデルでは、 group.R.Users のように group のフィールドに users が紐づいてくれません。 また、連鎖的な eager load も書けません。 group に紐づいた形で users も todos も持つためには、以下のように Option<(groups::Model, Vec<(users::Model, Vec<todos::Model>)>)> という長い型で持つ必要が出てきます。
Rust を書くと、「今この値は生きているのか」「この値は今誰が所有しているのか」「この値は不変にすべきか可変でよいか」といったことを嫌でも意識せざるを得ず、結果としてメモリの安全性を担保するためのマインドセットが醸成されるような感触を受けました。 Rust は確かに難しく、Rust 特有の概念 (所有権、ライフタイム、スマートポインタ など…) を理解する必要があります。ただ、この難しさの壁については、 AI に色々質問できるようになったことで、ある程度緩和されているな、と学習しながら感じていました。 Go で感じていた課題が Rust によって色々と解決されており、より堅牢性や速度が求められる場面では、 Rust を選択するのもありと感じました。
一方、大規模な Web アプリケーションに向いているのかは判断しきれませんでした。大規模になってくるとビルドが非常に遅い、みたいな話もあり、ローカルでのテストや CI の実行時間が長くなってしまうのは地味に懸念ポイントのひとつかな、とも思います。 このあたり知見がある方がもしいらっしゃいましたら、コメントなどで教えていただけると嬉しいです。
functionjsStringToJava(str) { if (!teavm) return0;
// TeaVMのヒープに文字列用領域を確保 let javaString = teavm.allocateString(str.length); if (javaString === 0) { return0; }
let dataArrayPtr = teavm.stringData(javaString); let dataAddress = teavm.objectArrayData(dataArrayPtr); let dataView = newUint16Array(teavm.memory.buffer, dataAddress, str.length);
// UTF-16配列として書き込み for (let i = 0; i < str.length; ++i) { dataView[i] = str.charCodeAt(i); }
return javaString; }
functionjavaStringToJs(javaString) { if (!teavm || javaString === 0) return"";
let dataArrayPtr = teavm.stringData(javaString); let length = teavm.arrayLength(dataArrayPtr); let dataAddress = teavm.objectArrayData(dataArrayPtr); let dataView = newUint16Array(teavm.memory.buffer, dataAddress, length);
let result = ""; for (let i = 0; i < length; ++i) { result += String.fromCharCode(dataView[i]); }
原文ではThe baseline runtime overhead of cgo calls has been reduced by ~30%.の一行のみがさらっと記載されているのみでしたが、コードの書き換えを一切必要とせずアップグレードするだけで30％のオーバーヘッドを削減でき、素晴らしいアップデートでした。
Green Tea got its name in 2024 when Austin worked out a prototype of an earlier version while cafe crawling in Japan and drinking LOTS of matcha! This prototype showed that the core idea of Green Tea was viable. And from there we were off to the races.
Green Tea GCは Go 1.25 で GOEXPERIMENT=greenteagc として実験的に導入され、Go 1.26 からはデフォルトで有効化されました。本記事では、この新しいGCの仕組みと、実際にどの程度の性能改善が得られるのかを解説します。
TL;DR
10〜40%のGCオーバーヘッド削減を実現
メモリアクセスの空間的局所性を大幅に改善
Intel/AMDの最新CPUではAVX-512によるベクトル加速も利用可能
Go 1.26からデフォルト有効（オプトアウト: GOEXPERIMENT=nogreenteagc）
Imagine the CPU driving down a road, where that road is your program. The CPU wants to ramp up to a high speed, and to do that it needs to be able to see far ahead of it, and the way needs to be clear. But the graph flood algorithm is like driving through city streets for the CPU. The CPU can’t see around corners and it can’t predict what’s going to happen next. To make progress, it constantly has to slow down to make turns, stop at traffic lights, and avoid pedestrians. It hardly matters how fast your engine is because you never get a chance to get going.
// 大量の小さなオブジェクトを生成しては破棄する（短寿命オブジェクトの掃き出し負荷テスト） funcmakeGarbage() { var head *SmallObject for i := 0; i < numObjects; i++ { // リンク構造を作ることでスキャナにポインタを追跡させる head = &SmallObject{next: head, val: [6]int64{int64(i)}} } _ = head // keep alive until here }
このコードのポイント：
64バイトの小オブジェクト: Green Teaの最適化対象となるサイズ
リンクリスト構造: ポインタ追跡を強制し、GCスキャナに負荷をかける
1000万個 × 100回: 大量のオブジェクト生成と破棄を繰り返す
計測結果
Go 1.25 と Go 1.26rc1 でそれぞれ5回ずつ実行し、平均を取りました。
$ for i in {1..5}; do go run gc_bench.go 2>&1 | grep "Total Duration"; done Total Duration: 42.809022396s Total Duration: 41.469512574s Total Duration: 40.128681706s Total Duration: 41.512944959s Total Duration: 40.281574518s $ for i in {1..5}; do go1.26rc1 run gc_bench.go 2>&1 | grep "Total Duration"; done Total Duration: 36.808893283s Total Duration: 35.833063737s Total Duration: 36.843265014s Total Duration: 37.50556513s Total Duration: 36.551616285s
]]>Green Tea GCの開発タイムライン（出典: Go公式ブログ）*Go 1.26 がリリースされ、ガベージコレクタ（GC）に大きな変更が加わりました。その名も Green Tea GC（緑茶GC）です。Go 1.26で go fix が面白くなったhttps://future-architect.github.io/articles/20260129a/2026-01-28T15:00:00.000Z2026-01-28T15:00:00.000Z真野隼記はじめに
TIG（Technology Innovation Group）の真野です。
Go 1.26ブログ連載 の3日目は、go fix コマンドのアップデートについて解説します。
go fix の出発点
リリース内容へ入る前に、go fix そのものについて解説します。
まず、Go 1.26で新しく go fix コマンドが追加されたわけではありません。コマンド自体は2011年4月15日に公開されたIntroducing Gofixというブログで紹介され、その翌月リリースのr57 で追加されました。つまり、誕生から15年近く経過する由緒ある（？）ツールとも言えます。
それにも関わらず、 go fix コマンドはあまり有名で無いと思います。なぜでしょうか。
まず、Go言語が1.0に到達したのは、2012年3月28日で、go fix コマンドが紹介されたのはその1年前です。現在と大きく異なり、正式版に向けて週次ベースでリリースしており、破壊的な仕様変更も行われていた時期です。その中には http や os といった利用頻度が高いパッケージのAPI変更も含まれるため、開発者としては追随が大変でした。
go fix の出自は、こうしたAPIの破壊的変更にともなる既存コードの書き換えすることです（Goチーム公式からバージョンアップに伴う移行ツールが提供されていたという訳で、ホスピタリティが凄さを感じます）。もちろん、バイナリを書き換えるわけではないので再ビルドが必要ですが、利用者視点では手間という面で、このツールがあるのと無いでは大きな差でしょう。Go開発チームとしても、 go fix という変換ツールがあるこそ、API変更のコストに囚われすぎずより良い言語にすることが集中できた（意訳）という訳で、当時はとても重要な位置づけでした。
バージョン1.0以降の go fix
一方で、Goはバージョンが1.0に到達してからは破壊的な変更が行われなくなりました。
これ自体は良いことですが、go fix の存在感は低下しました。今となっては不要では？みたいな声を聞いたこともあります。実際、1.0以降のリリースノートで go fix の更新は、context の書き換えくらいでした（他にも見落としていたらすいません）。
Go 1.8、Go 1.10
golang.org/x/net/context を context に書き換える機能が追加
これ以降は更新が無かったため、ほとんどの開発者の意識から外れていたのではないでしょうか。 go fmt や go vet は広く活用されていたのに、不憫な子。
Go 1.26での go fix
さて、Go 1.26です。
リリースノートやIssueであるcmd/go: fix: apply fixes from modernizers, inline, and other analyzers #71859 を読むと、以下の点が更新されました。
go fix の内部実装が golang.org/x/tools/go/analysis という、go vet や gopls が利用しているのと同じフレームワークを使うようになった。型情報や変数のスコープなどを理解して安全な書き換えが可能になるとのこと
golangci-lint run --fix などとすれば、Golangci-lintもコードの置換も行ってくれます。
リンター一覧で Autofix タグがついているものがその対象です。
モダン化はいくつか重複している機能もありそうですが、詳しく見ていません。おそらく、衝突するような機能はgolangci-lint 側で無効化/修正されると思いますので（根拠はなく予想です）、まずは go fix と golangci-lint run --fix の両方を実行してみて試すのが良いのではないかと思いました。
インライン化は該当の機能はないのでこちらについては go fix の利用が必須になるかと思いした。
さいごに
コードレビューなどでより新しい書き方をsuggestするというのは、あまり創造的では無いと思っていました。これが go fix でかなり省略されるということで、AIが古いコードを出してきても矯正できる点は良いと思います（go fix で直してまた古いコードに書き換えられたりはあるかもですが）。
各種プロファイルは go tool pprof コマンドで HTTP エンドポイント（/debug/pprof/${プロファイル名}）を指定することで確認できます。 たとえば heap プロファイルを確認するコマンドは次の通りです。
$ go tool pprof http://localhost:6060/debug/pprof/heap Fetching profile over HTTP from http://localhost:6060/debug/pprof/heap ... File: main Build ID: 0692a5c786cbac9e9d379f2de2112b6066d8673c Type: inuse_space Time: 2026-01-19 15:15:56 UTC Entering interactive mode (type "help" for commands, "o" for options)
The advantage of this approach over other goroutine leak detection techniques is that it can be leveraged, with a minimal performance cost, in regular Go systems, e.g., production services. It is also theoretically sound, i.e., there are no false positives. Its primary limitation is that its effectiveness is reduced the more heap resources are over-exposed in memory, i.e., pair-wise reachable.
なお、AVX512はそれほど大量のデータを処理する必要とするアプリケーションが一部に限られるせいか、10th/11th Gen Core CPUでは対応していましたが、その後のチップからは取り除かれてしまいました。それだけ半導体を使うのに使用されないのであればその分通常のコア数を増やそうという感じですね。Eコア・Pコアに分かれた時代からは使えなくなりました。あとはCPUだけが早くてもメモリ転送がボトルネックになりそうですしね。
以下のコードがテストです。データの読み込みは省略しています。SIMDの方は[8]int16などの固定長配列を前提としているので、[][8]int16という形で、ベクトルを計算単位でまとめた二重配列的な構造にしてから与えています。なお、テストデータはReal World HTTPの原稿で、「クッキーのセキュリティ」という検索用語をそれぞれベクトル化してあらかじめファイルにしてあり、それを利用しています。
// プリミティブな内積計算ロジック funcdotProductPrimitive(a, b []int16)int32 { var sum int32 = 0 for i := 0; i < len(a); i++ { sum += int32(a[i]) * int32(b[i]) } return sum }
// SIMDの内積計算ロジック funcdotProductSIMD(a, b [][8]int16)int32 { acc := archsimd.Int32x4{} for i := 0; i < len(a); i++ { vq := archsimd.LoadInt16x8(&a[i]) vt := archsimd.LoadInt16x8(&b[i]) dot := vq.DotProductPairs(vt) acc = acc.Add(dot) } return acc.GetElem(0) + acc.GetElem(1) + acc.GetElem(2) + acc.GetElem(3) }
// 2. float32 -> int8 量子化 floatVec := resp.Embeddings[0] int8Vec := make([]int8, len(floatVec)) for i, v := range floatVec { val := v * 127.0 if val > 127 { val = 127 } if val < -128 { val = -128 } int8Vec[i] = int8(val) }
当初は3章構成の2章だけで、「配列 vs 連結リスト / HashMap vs Tree」みたいな企画内容として話が来ました。しかし、企画を見たときに「今どき連結リストとかわざわざ作ったり、古典的なアルゴリズムとデータ構造の話ってどこまで役に立つんだろうか？」みたいな、自分で何か設計するときに企画でいただいたような内容ってあんまり考慮することはないかな、ということを思い、オタク特有の早口でチャットに以下のようなことを書きました（一部読みにくかったので原文ママではない）
]]>真野さん、松本さんと一緒にSoftware Designの特集記事に寄稿しました。当初は3章構成の2章だけで、「配列 vs 連結リスト / HashMap vs Tree」みたいな企画内容として話が来たのですが、企画を見たときに...なぜアーキチームは設計や実装のパターンを絞りたいか？ 背景にある思考と技術選定のジレンマhttps://future-architect.github.io/articles/20251107a/2025-11-06T15:00:00.000Z2025-11-06T15:00:00.000Z真野隼記
Primitive Types in Patterns, instanceof, and switch (Third Preview)
Preview & Incubating
Language
508
Vector API (Tenth Incubator)
Preview & Incubating
Libraries
509
JFR CPU-Time Profiling (Experimental)
Additions
HotSpot JVM
510
Key Derivation Function API
Additions
Libraries
511
Module Import Declarations
Additions
Language
512
Compact Source Files and Instance Main Methods
Additions
Language
513
Flexible Constructor Bodies
Additions
Language
514
Ahead-of-Time Command-Line Ergonomics
Additions
HotSpot JVM
515
Ahead-of-Time Method Profiling
Additions
HotSpot JVM
518
JFR Cooperative Sampling
Additions
HotSpot JVM
519
Compact Object Headers
Additions
HotSpot JVM
520
JFR Method Timing & Tracing
Additions
HotSpot JVM
521
Generational Shenandoah
Additions
HotSpot JVM
503: Remove the 32-bit x86 Port
JEP 449 (JDK 21) 辺りから 32-bit x86 サポートの廃止に向けた動きが進んできていました。 Linux 向けの 32-bit x86 関連ソースが残るのみとなっていましたが、32-bit x86 サポートのために発生していた足かせの排除やビルド・テストの簡素化のために JEP 503 にてソースが削除されました。
506: Scoped Values
JEP 429 (JDK 20) からプレビュー提供されていた Scoped Values が、プレビューを終えて正式リリースされました。本機能は主に ScopedValue クラスにより提供され、次のような場合に役立ちます。
// class 定義を省略できる // main メソッドの修飾子を省略できる // main メソッドの引数を省略できる voidmain() { // `java.lang` パッケージに新たに追加された IO クラスを使う IO.println("Hello, World!"); }
class 定義に囲まれていないフィールドやメソッドを含むソースを compact source file と呼び、それらのフィールドやメソッドをメンバーとする暗黙のクラスが定義されているように扱われます。暗黙に定義されるクラスは名前を持たないため、 new 演算子でインスタンス化することや static メソッドのメソッド参照はできません。しかし、後述の仕組みで作られるインスタンスを this で参照できます。
暗黙定義されるクラスは次の仕様になります。
無名パッケージに定義されたトップレベルの final クラス
Object クラスを継承し、インターフェース実装は無し
コンストラクタは引数無しのデフォルトコンストラクタのみ存在する
main メソッドは次の仕組みで選択されます。
クラスに直接定義または継承で String[] を引数とする main メソッドがあればそのメソッドを選択する。
