Diary

Introduction

Google Chrome has an experimental Vertical Tabs feature that displays tabs in a left sidebar instead of the top bar. Microsoft Edge has offered this as a standard feature for some time, and Chrome now allows you to enable it via chrome://flags.

For anyone who keeps many tabs open or uses a widescreen monitor, vertical tabs can significantly improve productivity. This article explains how to enable and use them.

What Are Vertical Tabs?

In standard Chrome, tabs are arranged horizontally at the top of the window. As you open more tabs, each one gets narrower and the title becomes unreadable. With 20 or more tabs open, you can barely see anything beyond the favicon.

Enabling vertical tabs solves this problem:

• Tabs are arranged vertically in a left sidebar, so titles remain visible even with many tabs open
• Tab titles are always displayed as text, making it easy to find the tab you need
• The top tab bar is removed, increasing vertical screen space for content
• The sidebar can be collapsed and expanded as needed

Requirements

• Supported OS: Mac, Windows, Linux, ChromeOS
• Chrome version: Latest version recommended (as an experimental flag, it may not exist in some versions)

Setup Steps

Step 1: Open the Flags Page

Type the following in Chrome’s address bar and press Enter:

chrome://flags/#vertical-tabs

The “Vertical Tabs” entry will appear highlighted in yellow.

As shown in the screenshot above, “Vertical Tabs” is highlighted and you can change the setting from the dropdown on the right.

Step 2: Change to “Enabled”

Click the dropdown next to “Vertical Tabs” and select “Enabled” (the default is “Default”).

The flag description reads:

Enables an option for showing tabs to the side. – Mac, Windows, Linux, ChromeOS

Step 3: Restart Chrome

After the change, a blue “Relaunch” button appears at the bottom of the page. Click it to restart Chrome and activate vertical tabs.

Using Vertical Tabs

After restarting, tabs will appear vertically in the left sidebar.

Toggling the Sidebar

• Click the sidebar toggle icon at the top-left of the window to show or hide the sidebar
• Alternatively, right-click on the tab bar and select “Show tabs in side panel”

Collapsing the Sidebar

When the sidebar is in the way, click the arrow button on the left edge to collapse it (icon-only view). Click again to expand.

Reverting to Normal Tabs

To disable vertical tabs, open chrome://flags/#vertical-tabs again, set the dropdown back to “Default”, and restart Chrome. This restores the standard horizontal tab bar.

Differences from Edge’s Vertical Tabs

Microsoft Edge’s vertical tabs are a polished standard feature with tab group nesting and auto-collapse support. Chrome’s vertical tabs are experimental, so there are some differences:

That said, Chrome’s vertical tabs are perfectly usable for daily browsing.

Summary

Chrome’s vertical tabs can be enabled in under a minute via chrome://flags/#vertical-tabs. For anyone who keeps many tabs open or wants the same experience as Edge’s vertical tabs in Chrome, it is a feature worth trying.

Since it is an experimental flag, it may be disabled by a Chrome update. If that happens, simply follow the same steps to re-enable it.

Introduction

In 2026, OpenAI released GPT-5.5, the successor to GPT-5.4. This article examines GPT-5.5’s features, how it compares to competing models, API migration considerations, and its implications for enterprise systems — particularly in Japan.

Positioning of GPT-5.5

GPT-5.5 is the latest evolution of OpenAI’s flagship model, building on GPT-5.4. It remains a general-purpose foundation model for language understanding and generation, covering text generation, summarization, translation, and code assistance.

Key improvements over GPT-5.4 include:

• Enhanced reasoning accuracy
• Stronger multimodal support (image and audio input integration)
• Advanced agent capabilities (external tool invocation)
• Expanded token limits

AI Usage Rates Across Major Countries

The adoption of AI models including GPT-5.5 varies significantly by country.

While India and China show high usage rates, Japan remains at 32% — one of the lowest among major economies. There is still significant room for Japanese enterprises to integrate AI into their operations.

Comparison with Competing Models

GPT-5.5’s main competitors are Anthropic’s Claude series and Google DeepMind’s Gemini series.

Anthropic positions Claude as “The AI for Problem Solvers,” focusing on problem-solving capabilities. Google DeepMind’s Gemini follows the concept of “Learn, build, and plan anything,” balancing general-purpose use with specialized domains (Veo for video generation, Imagen for image generation, AlphaFold for life sciences).

Functional differentiation is narrowing. Selection criteria are shifting toward system compatibility, vendor lock-in tolerance, and alignment with internal security policies. The key question is not which model to choose, but how to fit it to your specific requirements.

API Migration Considerations

When migrating from GPT-5.4 or earlier to GPT-5.5, verify the following:

1. Model name change: Update the model parameter to gpt-5.5
2. Response format: New metadata fields may have been added
3. Token limits: Maximum input/output token counts may have changed
4. Deprecated parameters: Check for removed parameters

Migration checklist:

• Verify existing prompts
• Review error handling
• Recheck rate limit settings
• Recalculate cost estimates

Impact on Japanese Enterprise Systems

Integration with Forms and Workflows

Processing tied to Japan-specific business practices — such as invoice cut-off dates, approval circulation flows, and year-end tax adjustment documents — depends heavily on Japanese language precision in prompt design. With GPT-5.5’s improved Japanese capabilities, the effort spent manually correcting particles and phrasing may be reduced.

Azure OpenAI Availability Timing

For organizations that cannot send data outside Japan, such as financial and medical institutions, Azure OpenAI Service is the primary option. New model availability on Azure typically lags several weeks to months behind the OpenAI platform. Production deployment schedules should be planned only after confirming Azure availability dates.

Operational Considerations

Model version upgrades can subtly change output behavior. Japanese enterprise systems often implicitly expect identical outputs for identical inputs. Recommended countermeasures:

• Automate regression testing
• Periodically review output samples manually
• Pin model versions for critical operations

Future Outlook

GPT-5.5’s release has further intensified competition in the LLM market. Google DeepMind is expanding the Gemini family with specialized models like Veo (video generation) and Lyria (music generation), and OpenAI is pursuing similar specialization.

In Japan, expansion of Azure OpenAI domestic regions, Japanese-specific fine-tuning options, and integration support services from domestic system integrators are expected to advance.

Summary

GPT-5.5 is a solid evolution from GPT-5.4, maintaining OpenAI’s flagship position in an increasingly competitive LLM market. When considering adoption, Japanese enterprises should make comprehensive evaluations that go beyond simple performance comparisons to include system integration feasibility, Azure OpenAI availability timing, and operational readiness.

Uploading to App Store Connect will require builds with Xcode 26 and the iOS 26 SDK starting April 28, 2026. iOS 26 was released in September 2025 — a major update including the Liquid Glass design and Foundation Models framework announced at WWDC25. iOS 27 will be announced at WWDC26 (June 8–12, 2026) and is expected to ship in September 2026. This article lays out the migration order with both versions in mind.

App Store SDK Requirement Schedule

Every year, Apple raises the minimum SDK version required for submissions to App Store Connect.

Source: <https://developer.apple.com/news/upcoming-requirements/>

If you don’t build with the iOS 26 SDK, you won’t be able to upload app updates to App Store Connect. This isn’t about new features — it’s a mandatory requirement to continue delivering updates to existing users.

iOS 26 Migration Priority Order

Get Your Tooling in Order First

Whether you’re working on iOS 26 compliance or early iOS 27 validation, the first blockers are usually build tooling issues rather than OS APIs. Lock down the tooling first.

The most common issue when migrating to Swift 6 mode is concurrency errors around CoreData. Accessing NSManagedObject outside @MainActor now triggers warnings, so the fix is to wrap operations inside context.perform blocks.

actor DataProcessor {
    func process(context: NSManagedObjectContext) async {
        await context.perform {
            // CoreData operations go inside context.perform
        }
    }
}

Behavior Changes in iOS 26 That Are Easy to Trip Over

TLS Minimum Version Change

For apps linked against the iOS 26 SDK, the minimum TLS version for URLSession and Network framework has been raised from 1.0 to 1.2.

If internal systems or external APIs still use legacy TLS settings, apps built with the iOS 26 SDK won’t be able to communicate with them.

// Example allowing legacy TLS (not recommended — temporary workaround only)
let config = URLSessionConfiguration.default
config.tlsMinimumSupportedProtocolVersion = .TLSv10 // triggers a warning
let session = URLSession(configuration: config)

The correct fix is to upgrade the server side to TLS 1.2 or higher. Make sure to check connections made through third-party SDKs as well.

Removal of UIScreen.mainScreen

UIScreen.mainScreen, which had been previously deprecated, has been promoted to deprecated in the iOS 26 SDK. For compatibility with multi-window and iPadOS scene support, screen size should now be obtained from UIWindowScene.

// Before (deprecated)
let screenWidth = UIScreen.main.bounds.width

// After (recommended)
if let scene = UIApplication.shared.connectedScenes
    .first(where: { $0.activationState == .foregroundActive }) as? UIWindowScene {
    let screenWidth = scene.screen.bounds.width
}

Push to Talk Entitlement Change

The com.apple.developer.pushkit.unrestricted-voip.ptt entitlement no longer works with the iOS 26 SDK. Migration to the Push to Talk framework (iOS 16+) is required.

CoreData iCloud Sync Key Removal

Keys like NSPersistentStoreUbiquitousContentNameKey, which were deprecated over 10 years ago for iCloud ubiquitous sync, now cause build errors with the iOS 26 SDK. Migration targets are NSPersistentCloudKitContainer (iOS 13+) or SwiftData (iOS 17+).

Adapting to Liquid Glass Design

Standard UIKit / SwiftUI components (navigation bars, tab bars, sheets, etc.) automatically adapt to the new design. For custom UI with manual drawing, it’s worth visually verifying on a real device how it interacts with background blur and glass effects.

Getting Ahead on iOS 27 (WWDC26: June 8–12, 2026)

WWDC26 runs June 8–12, 2026. As usual, the new OS will be announced on day one with Beta 1 released immediately. iOS 27 is expected to ship in September 2026.

Testing Priority for Simultaneous iOS 26 & 27 Support

Common Pitfalls for Japanese Business Apps

What to Check Before Upgrading

The fastest first step is to do a rough scan for deprecated APIs.

grep -R "UIScreen.mainb|unrestricted-voip.ptt|UbiquitousContentName|UbiquitousContentURL" ./

Running a similar check for TLS-related issues helps catch things you might miss.

grep -R "TLSv10|TLSv11|tlsMinimumSupported|kCFStreamSSLLevel" ./

Java 26 went GA on 2026/03/17.

There are a lot of preview features again, but there are some changes around HTTP/3, G1 GC, and virtual threads that could quietly make a real difference.

On the flip side, if your environment is still carrying legacy APIs or old JVM flags, there are clear spots where an upgrade could trip you up.

Especially coming from Java 8, the gap is large enough that it’s better to look at where you’ll get stuck before looking at what’s new in Java 26.

Overview Diagram

Java 8 in production
	|
	+-- Audit legacy APIs / libraries
	|      - javax.xml.bind
	|      - Thread.stop
	|      - sun.*
	|      - Old JVM flags
	|
	+-- Validate on an LTS first
	|      - Test on Java 17 or 21
	|
	+-- Then check Java 26 deltas
			 - HTTP/3
			 - G1 improvements
			 - Virtual thread changes
			 - Security default changes

What Looks Good

java.net.http.HttpClient now supports HTTP/3.

Being able to use HTTP/3 without major code changes on the app side is straightforwardly useful.

Beyond that, there are fairly solid performance improvements: reduced synchronization in G1 GC, better humongous object reclamation, and AOT Object Cache now supporting any GC.

Virtual threads have also been improved — they’re less likely to hold onto the carrier thread while waiting for class initialization, which should reduce weird blocking scenarios.

Some of the smaller but welcome additions:

• Process now implements AutoCloseable
• UUID.ofEpochMillis() was added, making UUIDv7-style handling easier
• ByteOrder is now an enum, making it easier to use in switch statements

For example, the HTTP Client lets you benefit with minimal code changes:

var client = HttpClient.newBuilder()
	.version(HttpClient.Version.HTTP_3)
	.build();

var request = HttpRequest.newBuilder()
	.uri(URI.create("https://example.com/api/status"))
	.GET()
	.build();

var response = client.send(request, HttpResponse.BodyHandlers.ofString());
System.out.println(response.statusCode());

And since Process now implements AutoCloseable, cleanup after running external commands is a bit cleaner:

try (var process = new ProcessBuilder("java", "-version").start()) {
	var exitCode = process.waitFor();
	System.out.println("exit=" + exitCode);
}

Things to Watch Out For

First, Thread.stop() has been removed.

If it’s still lingering in legacy maintenance code, it won’t even compile on JDK 26.

The Applet API has also been removed, so environments pulling from old documentation or samples need to watch out.

JVM flag cleanup has also progressed — flags like -Xmaxjitcodesize, MaxRAM, and AggressiveHeap that you’ve been using out of inertia may need to be revisited.

RMI over TLS now enforces endpoint identification by default, so environments with sloppy certificate SANs may hit connection failures.

HttpRequest.Builder.timeout() now covers the full response body reception, not just the initial connection. Depending on your existing timeout design, this could cause noticeable behavioral differences.

For environments that have been running on Java 8 for a long time, here’s what to be aware of before jumping straight to Java 26:

• Java 8 ran on the classpath model, but from Java 9 onward, module boundaries and internal API dependencies become visible
• Java EE / CORBA modules were removed in Java 11, so if javax.xml.bind is still in your codebase, you’ll need a separate fix
• Reflection and security defaults have become stricter — code that used to work silently may now warn or fail
• Old TLS settings, keystores, and RMI connections are prone to breaking right after an upgrade

For Japanese business systems, character encoding is also a quiet minefield.

Banking and core business systems in particular often still assume Shift_JIS-family encodings for back-office and host system integrations.

If you naively consolidate everything to “UTF-8 is the standard now,” you can end up with insidious bugs where the UI works fine but reports or external integrations produce garbled text.

In the Java 8 era, there was a lot of code that happened to work because the default charset on Windows was windows-31j.

But since JDK 18, the default charset is UTF-8, so patterns like new String(bytes) or FileReader that rely on the implicit charset will behave differently after migration.

In practice, you also shouldn’t treat Shift_JIS and windows-31j as interchangeable.

Both are available in Java’s charset list, but windows-31j / MS932 includes Windows-specific extensions, so there can be mismatches with circled numbers, platform-dependent characters, and IBM/NEC extensions.

For banking file transfers and host connections, it’s safer to confirm upfront whether the other party expects “Shift_JIS but actually CP932,” “strictly within the Shift_JIS range,” or “IBM host code pages included.”

If you’re looking at Japanese language issues specifically, these should be part of your pre-migration checklist:

• Is the charset explicitly specified in byte array conversions?
• Are you conflating Shift_JIS and windows-31j?
• Have you verified round-trip correctness for circled numbers, wave dash, fullwidth tilde, platform-dependent characters, and gaiji?
• For report CSVs, fixed-length files, and host transmission: are you mixing up character-based and byte-based lengths?
• Can you detect unmappable characters instead of silently replacing them?

So if you’re coming from Java 8, rather than going straight to 26 in production, it’s more realistic to first get your build and tests passing on LTS 17 or 21, strip out the old dependencies there, and then evaluate Java 26.

Java 26 itself is interesting, but absorbing the delta from Java 8 is where most of the real work lies in practice.

What to Check Before Upgrading

The fastest first step is to do a rough scan for deprecated APIs and flags.

grep -R "Thread\.stop\|Xmaxjitcodesize\|AggressiveHeap\|MaxRAM" ./

If you want to catch Java 8–era dependencies as well, run this too:

grep -R "javax\.xml\.bind\|javax\.activation\|CORBA\|sun\." ./

To do a rough scan for charset assumptions, this helps catch things you might miss:

grep -R "Shift_JIS\|MS932\|windows-31j\|Cp943\|Cp930\|EBCDIC\|file.encoding" ./

On the Java side, it’s safer to explicitly specify charsets and detect unmappable characters rather than relying on the default charset:

var charset = Charset.forName("windows-31j");
var encoder = charset.newEncoder()
	.onMalformedInput(CodingErrorAction.REPORT)
	.onUnmappableCharacter(CodingErrorAction.REPORT);

var bytes = encoder.encode(CharBuffer.wrap("顧客コード①"));
System.out.println(bytes.remaining());

Here’s a rough comparison:

• Java 26 from Java 8’s perspective: Large gap — this is a migration project
• Java 26 from Java 17’s perspective: Mainly evaluating new features and checking default value changes
• Java 26 from Java 21’s perspective: Migration cost is relatively light

In more practical terms:

For Java 8 projects, before getting excited about Java 26’s new features, the real topic is usually figuring out how to peel off Java 8–era technical debt.

Conversely, if you’re already on Java 17 or 21, Java 26 isn’t a “full migration” — it’s more about evaluating how to incorporate performance improvements and default value changes.

Here are some things worth verifying in CI for peace of mind:

• HttpClient timeout and header behavior
• RMI / TLS communication involving certificate validation
• Runtime creation with jlink
• XML Signature and legacy keystore dependencies
• Round-trip tests for Shift_JIS / windows-31j / host integration files

Preview / incubator features are interesting, but they’re probably better viewed as evaluation targets rather than production-ready at this point.

Summary

Java 26 is less of a single blockbuster and more of a stack of solid improvements across performance, standard APIs, and operationally safer defaults.

For typical business systems, HTTP/3, GC, and virtual thread improvements are positive moves forward.

On the other hand, the more legacy code and legacy runtime flags your environment carries, the more important it is to audit first and upgrade second.

For Japanese environments, character encoding in particular shouldn’t be put off.

In shops where Shift_JIS-family encodings or host system integrations are still in play, fixing default charset dependencies and Japanese round-trip issues takes priority over evaluating Java 26’s new features.

Especially coming from Java 8, doing an intermediate cleanup on LTS 17 or 21 first and then going after Java 26’s benefits is the more sensible path.