DEV Community: Liriel

Java 27: What Now? 7 Changes Every Developer Should Know

Liriel — Fri, 18 Sep 2026 17:07:50 +0000

Java 27 is here, but it is not the kind of release that asks you to relearn the language or rewrite your application. Most of its important changes happen behind the scenes: Java can use memory more efficiently, choose a different strategy for cleaning unused objects, protect network connections against future attacks, and produce safer diagnostic recordings.

If terms such as JVM, garbage collector, or JEP are unfamiliar, do not worry. We will translate each one into practical consequences.

Released on September 15, 2026, Java 27 contains nine JEPs. It is a non-LTS release; Java 25 remains the latest Long-Term Support release. In simple terms, Java 27 is a useful release to test and learn from, while companies that prioritize years of vendor support may prefer to remain on Java 25.

Here are the seven changes that deserve your attention.

First, what exactly was updated?

“Java” can refer to three related things:

The Java language is the syntax you write: classes, records, if, switch, and so on.
The JDK is the development kit containing the compiler, command-line tools, libraries, and the runtime.
The JVM is the virtual machine that executes compiled Java code and manages resources such as memory.

Java 27 changes all three, but its biggest improvements are in the JDK and JVM. A JEP, or JDK Enhancement Proposal, is the public design document for a significant JDK change.

Feature status is equally important:

Final means the feature is supported as a normal part of the platform.
Preview means developers can test the feature, but it may still change.
Incubator means an experimental API is available for feedback and is even less settled.

1. G1 is now the default GC in every environment

Java creates objects in memory while processing work. When they are no longer needed, a garbage collector (GC) finds their memory and makes it available again—automatic housekeeping for the application.

Java has several collectors because workloads have different priorities. Serial GC can suit very small applications. G1, short for Garbage-First, divides memory into regions and cleans promising regions first, balancing throughput with predictable pauses.

G1 was already the normal choice on server-class machines. Java 27 removes the remaining environment-dependent selection: if you do not explicitly choose a collector, HotSpot uses G1 everywhere, including small machines and containers where Serial GC could previously be selected.

For a beginner, the practical message is simple: your code will continue to work, but its performance profile may change. A service might use CPU differently, pause for different amounts of time, or keep a different amount of memory available.

Before upgrading, record the collector used by the current deployment and compare it with Java 27 under a representative load:

java -XX:+PrintCommandLineFlags -version

The safest approach is to compare Java 27 with your current JDK under realistic traffic rather than assuming that a newer default is automatically better for every workload.

2. Smaller object headers become the default

An object contains more than your declared fields. The JVM attaches a header with internal runtime information. Imagine a package: your data is the product, while the header is the shipping label.

Compact Object Headers move from an optional capability to the default HotSpot object layout. On 64-bit architectures, that label can shrink from 96 bits to 64 bits.

The saving on one object is tiny. Across millions, it can mean a smaller heap, better use of the CPU cache, and less memory for the GC to scan. Applications creating many small objects benefit most.

Your source code does not need to change. Still, agents, profilers, JNI code, or libraries that assume an object layout should be tested with the Java 27 build you plan to deploy.

3. TLS 1.3 gets hybrid post-quantum key exchange

TLS is the security protocol behind HTTPS. A client and server first perform a handshake to agree on encryption keys. Today's techniques are safe against current computers, but future quantum computers could threaten some of them.

Java 27 adds hybrid TLS 1.3 groups that combine conventional elliptic-curve cryptography with the post-quantum ML-KEM algorithm.

The traditional algorithm protects traffic today; ML-KEM adds protection against future quantum attacks. This counters harvest now, decrypt later: recording encrypted traffic now to attack it years later.

Applications using Java's standard javax.net.ssl APIs can benefit automatically when the other side also supports the new negotiation. Most developers do not need to call a new method. Platform teams should still test load balancers, proxies, external security providers, and any tool that inspects TLS handshakes.

Java 27 also enables TLS 1.3 certificate compression with zlib by default, reducing the size of certificate chains exchanged during a handshake.

4. JFR redacts sensitive data before it leaves the process

Java Flight Recorder (JFR) is a flight recorder for a Java application. It collects low-overhead information about CPU, memory, threads, and garbage collection to explain slow or unstable behavior.

The problem is that diagnostic data can accidentally contain secrets. Java 27 addresses this by redacting sensitive command-line arguments, environment-variable values, and system-property values inside the running process, before the recording is written or streamed.

That is a meaningful improvement for commands such as:

java -Ddb.password=secret -Dapi.key=token -jar app.jar

Redaction is enabled by default and can be extended with application-specific filters. This reduces the chance that a password or API key ends up in a recording shared with another team. It is still better not to pass secrets on the command line at all. JFR redaction is a safety net, not a replacement for a secret manager.

5. The most exciting APIs are still not final

Java 27 continues several long-running experiments. Here is what they mean without the jargon:

Structured Concurrency groups related tasks. If loading a profile and recent orders in parallel fails, the group can cancel and report them as one operation instead of leaving work behind.
Primitive types in patterns makes values such as int, long, and double work more naturally with pattern matching and switch. The long-term goal is fewer awkward differences between primitive values and objects.
Lazy Constants delay expensive initialization until a value is actually requested. A large lookup table, for example, does not need to slow application startup if no request ever uses it.
PEM encodings give Java a standard way to read and write the familiar -----BEGIN CERTIFICATE----- format used for cryptographic keys and certificates.
The Vector API describes one operation over several numbers at once. The JIT can translate it into CPU instructions useful for images, scientific computing, and machine learning.

These features are worth exploring, but their status matters. Preview code requires explicit flags:

javac --enable-preview --release 27 Main.java
java --enable-preview Main

The flags prevent accidental dependence on unfinished features. Preview and incubating APIs can change or disappear, so use them in controlled projects unless your maintenance policy accepts that cost.

6. Production diagnostics get more useful

Production debugging requires inspecting the JVM that is actually running, not merely the expected configuration.

jcmd gains a command that prints the active security properties of a running JVM:

jcmd <pid> VM.security_properties

Here, <pid> is the operating-system process ID of the Java application. VM.info and fatal-error logs also report the number of open file descriptors. A file descriptor represents an open file, socket, or similar resource; leaking too many can cause the dreaded Too many open files failure.

One compatibility detail can break monitoring pipelines: numeric fields in JSON thread dumps, including thread IDs and the PID, are now JSON numbers rather than strings. The output declares "formatVersion": 2. If you parse these dumps, test the parser before rollout.

7. Migration includes removals and behavior changes

Every platform eventually removes obsolete behavior. Beginners can treat this section as a checklist for build and platform teams; most ordinary application code will not use these features directly.

Java 27 removes several pieces of accumulated legacy:

The experimental JVMCI and bundled Graal JIT are gone. This does not mean the wider GraalVM project has disappeared.
Several obsolete JVM verification and class-GC flags are removed.
Linux's VFORK process-launch mechanism is removed.
ThreadPoolExecutor.finalize() is removed.
HttpServer changes from string-prefix matching to path-prefix matching. A context at /foo matches /foo/bar, but no longer /foobar.
ServiceLoader now consistently wraps linkage failures in ServiceConfigurationError.

Build plugins, agents, platforms, and older libraries are more likely to depend on these details. Successful compilation alone does not prove an upgrade is safe.

A practical upgrade checklist

Confirm your support policy. Java 27 is not LTS; decide whether you are evaluating, experimenting, or deploying.
Inventory JVM flags. Search container images, deployment manifests, CI jobs, and startup scripts for removed or obsolete options.
Benchmark with production-like traffic. Pay special attention to the G1 switch, heap behavior, startup, tail latency, and memory.
Test infrastructure boundaries. Exercise TLS proxies, custom providers, monitoring agents, native integrations, and thread-dump parsers.
Separate final features from previews. Do not accidentally make --enable-preview a hidden production dependency.
Run compatibility tools and the full test suite. Unit tests alone rarely expose runtime, packaging, and observability issues.
Keep a rollback path. Record the JDK build, flags, images, and baseline metrics used by the previous deployment.

So, should you upgrade?

For most teams, Java 27 is best viewed as an evaluation release with unusually practical runtime improvements. G1 everywhere and Compact Object Headers can improve deployment behavior without source changes. Post-quantum TLS and JFR redaction make safe behavior the default. The preview APIs show where Java is heading, but they are not yet stable contracts.

If you are on Java 25 LTS, there is no need to move simply because 27 exists. Install it in CI, run your services under realistic load, and use what you learn to prepare for the next releases. If you already track every six-month release, Java 27 is a compelling upgrade—provided you test the defaults you did not explicitly choose.

The real story of Java 27 is not flashy syntax. It is a JVM that uses memory more efficiently, exposes safer diagnostics, and prepares network security for a very different future.

Building GitHub Companion taught me a few things about Android architecture...

Liriel — Thu, 02 Jul 2026 17:04:51 +0000

One of the biggest challenges when learning Android development is moving beyond isolated code examples and building an application that resembles a production environment. Once an application starts interacting with external APIs, local databases, background synchronization, and asynchronous operations, concepts such as MVVM, repositories, dependency injection, and state management become essential rather than optional.

To explore these concepts in practice, I built GitHub Companion, a native Android application that consumes the GitHub REST API while combining modern Kotlin components with Java interoperability commonly found in real-world Android projects.

1. Why Java Still Matters in Android Development

Kotlin is currently the preferred language for Android, but Java remains a foundational pillar of the ecosystem:

Coexistence and Legacy Codebases: A vast number of production Android applications contain legacy systems written entirely in Java. Engineering teams rely on developers who can seamlessly navigate, refactor, and extend Java modules alongside newer Kotlin additions.
Interoperability: Kotlin and Java compile to the same JVM bytecode and are 100% interoperable. In modern projects, it is common to write UI layers in Kotlin (e.g., Jetpack Compose) while maintaining stable backend interfaces, models, and network libraries in Java.
Solid OOP Foundations: Understanding Java's strict object-oriented design, garbage collection, and class hierarchies makes it significantly easier to grasp advanced Android frameworks and design patterns.

2. Architecture: Demystifying MVVM and Coroutines

The application is built on the Model-View-ViewModel (MVVM) pattern, which enforces a strict separation of concerns:

Model: Encapsulates the domain logic, database entities, and API clients.
View: Handles user interaction and rendering (in our case, declarative Jetpack Compose).
ViewModel: Holds UI state and coordinates data operations. It communicates with the domain repositories and exposes states (Loading, Success, Error) to the View.

To handle asynchronous networking without blocking the UI thread, we utilize Kotlin Coroutines. Coroutines provide a non-blocking execution model. By launching network requests in a Coroutine scope, we suspend task execution while waiting for the network, and resume automatically when the data arrives, keeping the main thread free to draw the UI.

3. Under the Hood: Deep Technical Insights

To build reliable applications, we must understand how our frameworks operate underneath the abstraction layers. Here is how our app functions "under the hood."

A. Why Room Exists If SQLite Already Exists

SQLite is the engine under Android's local database, but using raw SQLite requires significant boilerplate. Developers must manually write SQL queries as strings, translate Cursor objects into Java/Kotlin objects, and handle database updates.

Room is an abstraction layer over SQLite that solves these issues:

Compile-Time Verification: Room parses and validates your SQL queries during compilation. If you mistype a table name in a @Query annotation, the build fails immediately. With raw SQLite, this syntax error would only crash your app at runtime on the user's device.
No Boilerplate Mapping: Room maps database rows directly to Java/Kotlin Data Objects (Entities) using annotation processors, eliminating cursor traversal loops.
Reactive Streams: Room seamlessly integrates with Flow and LiveData. When a row in your SQLite table changes, Room automatically publishes the updated query results to any active subscribers, keeping the UI in sync.

B. What Actually Happens When Retrofit Executes a Request

When you define a networking interface in Retrofit, it is just an interface with annotations—there is no implementation class. How does it execute?

Dynamic Proxy: When you initialize Retrofit and call retrofit.create(GitHubApiService.class), Java's reflection mechanism uses Proxy.newProxyInstance() to construct a dynamic proxy class at runtime.
Annotation Processing: When a method (like getRepository()) is called, Retrofit intercepts the call, parses the annotations (such as @GET and @Path) using reflection, and builds an HTTP request configuration.
OkHttp Core: Retrofit passes this request configuration to OkHttp, which manages the low-level connection pool, headers, and HTTP interceptors.
Serialization: Once the raw bytes return from the server, Retrofit uses GsonConverterFactory to deserialize the JSON stream into a Kotlin/Java DTO (Data Transfer Object).
Thread Switching: If using Java Call.enqueue(), Retrofit schedules the HTTP work on a background executor pool and posts the result back to the Android Main Thread. If using Kotlin suspend, it suspends the Coroutine and resumes on the dispatcher scope.

C. Coroutines Are Not Threads

A common misconception is that a Coroutine is simply a thread wrapper. It is not.

Threads are managed by the Operating System. Context switching between threads is expensive because the OS must save registers and CPU states, costing memory and time. You cannot run millions of threads concurrently.
Coroutines are managed by the runtime environment and are cooperative. They use suspension points where they yield the underlying thread to other coroutines without blocking it.
Lightweight: A coroutine is just a small object allocated on the heap. You can launch 100,000 coroutines on a single thread without memory pressure.
Dispatchers: Coroutines execute on dispatchers (like Dispatchers.IO for network/disk operations or Dispatchers.Main for UI changes). The dispatcher acts as a scheduler, mapping coroutine tasks to a thread pool underneath.

D. Understanding Dependency Injection Through Hilt

Without Dependency Injection (DI), classes instantiate their own dependencies. For example, a MainActivity would instantiate a Repository, which instantiates a RoomDatabase and a Retrofit client. This creates tight coupling, makes testing impossible, and violates the Single Responsibility Principle.

Hilt (built on Dagger) is a compile-time DI library:

Service Decoupling: Instead of writing new GitHubRepositoryImpl(...), we annotate the class constructor with @Inject and Hilt automatically provides the dependency.
Codegen Graph: During compilation, Hilt parses our annotations and generates the dependency graph. It validates that every class has access to the instances it needs. If a dependency is missing, the app fails to compile.
Scope Management: Hilt couples dependencies to Android lifecycles (e.g., @Singleton lives for the app's duration, while @ActivityScoped exists only as long as the Activity).

E. Why Repository Exists

The Repository pattern serves a vital architectural purpose: it isolates the domain layer from data origin details.
Without a Repository, the ViewModel would need to coordinate Room database transactions and Retrofit network calls directly. If we decided to migrate our caching engine from Room to Realm, we would have to rewrite the ViewModel.

The Repository provides a Single Source of Truth (SSOT). The ViewModel simply requests a repository record, and the Repository decides whether to fetch it from SQLite or trigger a web request. During tests, we mock the Repository interface using mock libraries (like Mockito) to return local test data, verifying our UI states without hitting real APIs.

F. The WorkManager + Hilt Crash That Took Hours to Debug

When setting up background syncing, we encountered a runtime crash: NoSuchMethodException: SyncFavoritesWorker.<init>.

The Cause: By default, Android's androidx.startup library automatically initializes WorkManager. During startup, WorkManager uses reflection to look for a default two-argument constructor (Context, WorkerParameters). Because our worker uses @HiltWorker to inject dependencies, it lacks this constructor, causing reflection to fail.
The Resolution: We had to disable the automatic WorkManager initializer in the AndroidManifest.xml via:
```
<meta-data
    android:name="androidx.work.WorkManagerInitializer"
    android:value="androidx.startup"
    tools:node="remove" />
```
Then, we implemented Configuration.Provider in our Application class, manually injecting the custom HiltWorkerFactory to handle the instantiation.

G. Cache Invalidation Is Harder Than It Looks

Offline synchronization sounds simple: save data locally and show it. But what happens if the data on the server changes?
If the app never checks for updates, the user sees stale information forever. If the app updates too often, it defeats the purpose of caching and drains the battery.

To solve this, we implemented a Time-Based Invalidation Policy:

Every database record includes a lastSync timestamp.
When a user searches for a repository, the repository queries Room and checks if System.currentTimeMillis() - lastSync < 30 minutes.
If valid, it returns the cached data. If expired, it attempts a network fetch. If the network call fails (e.g., no internet), it falls back gracefully to the expired cache.

H. Why GitHub API Rate Limits Matter

The GitHub REST API enforces a strict rate limit of 60 requests per hour for unauthenticated requests.

If our app did not cache data locally, every tab switch (Commits -> Branches -> Issues) or list reload would count against the user's rate limit. The user would quickly receive a 403 Forbidden error. By caching details in Room for 30 minutes and grouping repository data, we minimize API calls, saving our network budget.

I. Why ANRs Happen

An Application Not Responding (ANR) dialog is shown when the Main Thread (UI Thread) is blocked.
In Android, the Main Thread has a message loop managed by a Looper. It processes layout draws, touch events, and system notifications. If any event takes longer than 5 seconds to execute, the OS assumes the app is frozen and shows the ANR dialog.

Running a database query or an API request synchronously blocks the Thread until the socket completes or disk I/O completes. In our application, we prevent this by executing database queries asynchronously using Room's Flow bindings and performing Retrofit calls inside Kotlin Coroutines or Java's background executor thread pools.

4. Java-Kotlin Interoperability: The Date Formatter

To show how Java classes integrate with Kotlin, we implemented DateFormatterUtil.java in Java to parse ISO-8601 strings into user-friendly relative dates (e.g., "3 minutes ago").

In our Kotlin presentation layer, we consume this Java helper directly:

val relativeDate = DateFormatterUtil.formatGithubDate(commit.date)

5. Architectural Code Walkthrough

Below are the streamlined core components of the application. The full, concrete implementations can be viewed directly in the project repository.

A. Consuming REST APIs (Retrofit Interface)

Retrofit abstracts network endpoints. In a mixed codebase, we can define our endpoints in Java using Call<T> or in Kotlin using suspend functions:

Kotlin (using Coroutines):

interface GitHubApiService {
    @GET("repos/{owner}/{repo}")
    suspend fun getRepository(
        @Path("owner") owner: String,
        @Path("repo") repo: String
    ): RepositoryDto
}

Java Equivalent (using Call<T>):

public interface GitHubApiService {
    @GET("repos/{owner}/{repo}")
    Call<RepositoryDto> getRepository(
        @Path("owner") String owner,
        @Path("repo") String repo
    );
}

B. The Repository Pattern (Cache Management)

The Repository acts as a mediator between data sources, providing a single source of truth.

Kotlin Implementation:

`  class GitHubRepositoryImpl(
    private val apiService: GitHubApiService,
    private val repositoryDao: RepositoryDao
) : GitHubReposit[](url)ory {
    override suspend fun getRepository(owner: String, name: String, forceRefresh: Boolean): Repository {
        val localRepo = repositoryDao.getFavoriteById("$owner/$name")
        val isCacheValid = localRepo != null && (System.currentTimeMillis() - localRepo.lastSync < 30 * 60 * 1000)

        if (isCacheValid && !forceRefresh) return localRepo!!.toDomain()

        return try {
            val dto = apiService.getRepository(owner, name)
            dto.toDomain().also { repositoryDao.insertFavorite(RepositoryEntity.fromDomain(it)) }
        } catch (e: Exception) {
            localRepo?.toDomain() ?: throw e
        }
    }
}

C. State Management (ViewModel)

The ViewModel hosts the application state, pushing states lifecycle-safely to the View.

Java LiveData ViewModel:
`java
public class RepositorySearchViewModel extends ViewModel {
private final GitHubRepositoryImpl repository;
private final MutableLiveData> searchResult = new MutableLiveData<>();

public LiveData<Resource<Repository>> getSearchResult() { return searchResult; }

public void searchRepository(String owner, String repo) {
    searchResult.setValue(Resource.loading());
    new Thread(() -> {
        try {
            Repository result = repository.getRepository(owner, repo, true);
            searchResult.postValue(Resource.success(result));
        } catch (Exception e) {
            searchResult.postValue(Resource.error(e.getMessage()));
        }
    }).start();
}

}
`

6. Key Concepts Comparison: Kotlin vs. Java

Developers working in mixed codebases must understand the structural equivalents across both languages:

Concept	Kotlin Pattern	Java Equivalent
Async Operations	Coroutines (`suspend`)	Executors, `Thread`, or Retrofit `Call.enqueue()`
State Observation	`StateFlow` or `SharedFlow`	`LiveData` or RxJava `Observable`
Data Binding	Jetpack Compose State	`LiveData.observe()` or View Binding
Data Classes	`data class Repository(...)`	Standard Java Class with private fields, getters, and constructor

7. Application Branding & Interface Preview

To give the application a premium identity, we designed a custom logo combining a robotic companion concept with the GitHub symbol:

Below is a preview of the search and detailed views of the app:

8. Clean Code & Mobile Best Practices

DRY (Don't Repeat Yourself): Network responses (DTOs) are mapped to domain models in a centralized mapping layer, ensuring parsing logic is never repeated.
SOLID Principles: We respect the Single Responsibility Principle. For example, database DAOs are solely responsible for SQL queries, while the Repository handles cache management logic.
Version Control (Git): Adopted a feature-branch workflow (e.g., feature/retrofit-api) to keep the main development branch clean, employing semantic commit logs.

9. Conclusion & Learnings

Building GitHub Companion highlighted the value of structured architecture. By leveraging the Repository Pattern and MVVM, writing clean, encapsulated Java models, and integrating Kotlin Coroutines and Retrofit REST APIs, we built a codebase that is highly testable, scalable, and easy to maintain in a mixed-language development environment.

Working directly on these layers shows that mobile development is more than just writing UI; it requires understanding JVM thread synchronization, memory architectures, caching thresholds, and how frameworks integrate.

Video

10. References & Further Reading

To learn more about Android architectures, JVM interoperability, and best practices, check out these official developer resources:

You can explore the full implementation code of this project in my GitHub Repository:

GitHub Companion Repository

Java Garbage Collector: Why Creating Objects Is Cheaper Than You Think

Liriel — Sun, 28 Jun 2026 17:26:32 +0000

When many developers first hear about Java's Garbage Collector, they often associate it with one thing:

"Automatic memory management comes at the cost of performance."

This perception made sense twenty years ago.

Today, however, some of the largest systems in the world run on the JVM, handling millions of requests per second with strict latency requirements.

Companies like Netflix, Uber, LinkedIn, and many banks rely heavily on Java in production environments where performance is not optional.

So what changed?

The answer lies in understanding how the Java Garbage Collector actually works.

The Memory Problem Every Language Must Solve

Imagine the following code:

User user = new User();

The application allocates memory for the User object.

Eventually, that object is no longer needed.

The question is simple:

Who is responsible for freeing that memory?

In languages such as C, the developer is responsible:

User* user = malloc(sizeof(User));

free(user);

Forgetting to free memory causes leaks.

Freeing memory too early can lead to crashes and undefined behavior.

Java chose a different approach:

The JVM itself determines when an object is no longer reachable and automatically reclaims its memory.

This process is known as Garbage Collection.

How Does Java Know an Object Is Dead?

Java does not determine whether an object is alive based on variables or scope.

Instead, it uses a concept called reachability.

Consider:

User user = new User();

The variable user references the object.

As long as that reference exists, the object is considered alive.

Now:

user = null;

If no other references point to that object, it becomes unreachable.

Unreachable objects become candidates for garbage collection.

This approach is significantly safer than manual memory management because the JVM avoids both accidental deallocation and most memory corruption issues.

The Observation That Changed Everything

The JVM is built around an observation known as the Generational Hypothesis:

Most objects die young.

Surprisingly, this is true for the majority of modern applications.

Examples include:

HTTP request objects
DTOs
JSON parsing structures
Temporary strings
Stream operations
Intermediate collections

These objects often live for only a few milliseconds.

Meanwhile, objects that survive for longer periods tend to remain alive for a very long time:

Caches
Singleton services
Application configurations
Database connection pools

This observation fundamentally shaped the design of Java's Garbage Collectors.

The Heap Is Divided Into Generations

Instead of treating all objects equally, Java separates memory into generations.

Heap
│
├── Young Generation
│   ├── Eden
│   ├── Survivor 0
│   └── Survivor 1
│
└── Old Generation

Eden: Where Objects Are Born

Almost every object starts its life in Eden Space.

new User();
new Order();
new Product();

All of them are allocated inside Eden.

When Eden becomes full, the JVM triggers a Minor GC.

Minor GC

During a Minor GC, the JVM identifies which objects in Eden are still alive.

Dead objects are discarded immediately.

Live objects are copied to one of the Survivor spaces.

Eden → Survivor

This process is extremely efficient because most objects are already dead.

Remember the Generational Hypothesis:

Most objects die young.

As a result, the JVM often removes the vast majority of objects during every Minor GC cycle.

Survivor Spaces

The JVM alternates between two survivor areas:

Survivor 0
Survivor 1

Objects bounce between these spaces while they survive multiple garbage collection cycles.

Each time an object survives, its age increases.

Age 1
Age 2
Age 3
...

Eventually, the JVM decides that the object is probably long-lived.

At this point, it gets promoted.

Promotion to Old Generation

Objects that survive enough collection cycles are moved to the Old Generation.

Young Generation
        ↓
Old Generation

Typical examples include:

Spring Beans
Caches
Singleton instances
Application configuration objects

These objects are expected to remain alive for much longer periods.

Major GC and Full GC

Cleaning the Old Generation is considerably more expensive.

This process is often called a Major GC.

In some situations, the JVM may need to collect the entire heap:

Young Generation
Old Generation
Metaspace

This is known as a Full GC.

Historically, Full GCs were among the most feared events in Java applications because they frequently paused the application for long periods.

Modern collectors significantly reduced this problem.

The Stop-The-World Moment

During certain phases of garbage collection, the JVM pauses all application threads.

This event is called:

Stop-The-World (STW)

While the JVM performs critical operations, application threads remain suspended.

The goal of modern collectors is not to eliminate these pauses entirely, but rather to make them extremely short and predictable.

Enter G1GC

Since Java 9, the default collector is Garbage First (G1).

Instead of dividing memory into large contiguous spaces, G1 divides the heap into many small regions.

+----+----+----+----+
| R1 | R2 | R3 | R4 |
+----+----+----+----+
| R5 | R6 | R7 | R8 |
+----+----+----+----+

Some regions contain young objects.

Others contain old objects.

This design allows G1 to focus on collecting the regions that provide the highest memory recovery with the smallest pause times.

Hence the name:

Garbage First.

The Secret Behind Fast Object Allocation

One of the biggest misconceptions in Java is:

Creating objects is expensive.

In reality, object allocation in Java is often incredibly cheap.

Most allocations happen using a technique called Bump Pointer Allocation.

| Object A | Object B | Free Space |
                       ^
                    Pointer

Creating a new object frequently means little more than:

pointer += object_size

No complex memory search.

No traversal.

No expensive allocation algorithms.

Just moving a pointer forward.

Thread Local Allocation Buffers (TLAB)

The JVM goes even further.

Each thread often receives its own allocation area called a Thread Local Allocation Buffer (TLAB).

Instead of multiple threads competing for access to the heap, they allocate objects inside their own local buffers.

This dramatically reduces contention and synchronization overhead.

For most applications, object allocation becomes almost lock-free.

Sometimes the Object Never Exists

Modern JVMs perform sophisticated optimizations.

One of the most impressive is Escape Analysis.

public int sum() {
    Point point = new Point(10, 20);

    return point.x + point.y;
}

If the JVM determines that point never escapes the method, it may avoid allocating the object entirely.

In some cases:

The object is never created.

Is Garbage Collection Free?

No.

Garbage Collection introduces overhead.

The JVM spends CPU cycles:

Identifying live objects
Moving objects
Compacting memory
Updating references

However, the trade-off has proven extremely successful.

Developers gain:

Memory safety
Higher productivity
Fewer crashes caused by invalid pointers
Simpler application code

Final Thoughts

The Garbage Collector is often described as a convenience feature.

In reality, it is much more than that.

The JVM combines decades of research in:

Allocation algorithms
Concurrent programming
Memory compaction
Cache locality
Latency reduction

Modern Java applications are not fast despite the Garbage Collector.

In many cases, they are fast precisely because of the engineering behind it.

The next time you write:

new User();

remember that behind this single line, the JVM is leveraging decades of computer science research to make that operation as efficient as possible.

References

Oracle Java HotSpot Garbage Collection Tuning Guide
Oracle G1 Garbage Collector Documentation
Aleksey Shipilev — JVM Anatomy Quarks
Scott Oaks — Java Performance: The Definitive Guide
Plumbr Garbage Collection Handbook
OpenJDK Documentation
GCeasy JVM Performance Articles

What Are Classes, Objects, and Methods in Java? (Explained Simply)

Liriel — Fri, 26 Jun 2026 00:54:29 +0000

Classes, Objects, and Methods in Java

When you start learning Java — or any object-oriented language — three concepts will show up everywhere: classes, objects, and methods. Before you can write meaningful code, you need to understand what each of these is, why it exists, and how they relate to each other.

This article breaks all three down in a practical, straightforward way, using a real-world example you would actually find in a backend application.

What is a Class?

A class is a blueprint. It is a definition, a template that describes what a certain type of thing looks like and what it can do — but it is not the thing itself.

Think of it like an architectural floor plan. The plan tells you how many rooms a house has, where the doors are, and how the kitchen is laid out. But the plan is not a house you can live in. You use the plan to build a house.

In the same way, a class tells Java what attributes (data) and behaviors (methods) a certain type of object will have. No memory is allocated for real data yet — the class is just the definition.

A class defines two things:

Attributes — the data that each object of this type will hold
Methods — the actions that each object of this type can perform

Example: the `User` class

In a web application, users are everywhere. Let's model one as a class:

public class User {
    private Long id;
    private String name;
    private String email;
    private boolean active;

    public User(Long id, String name, String email) {
        this.id = id;
        this.name = name;
        this.email = email;
        this.active = true;
    }

    public void deactivate() {
        this.active = false;
    }

    public void changeEmail(String newEmail) {
        this.email = newEmail;
    }

    public String getUserInfo() {
        return name + " (" + email + ") - Active: " + active;
    }
}

This class describes what every user in our system has and can do:

Attributes: id, name, email, and active — these are the pieces of data each user carries
Methods: deactivate(), changeEmail(), and getUserInfo() — these are the actions a user can perform

Notice that the class alone does nothing. It just declares the structure. To actually work with a user, you need to create an object from it.

What is an Object?

An object is a concrete instance of a class. While the class is the blueprint, the object is the actual thing built from it — with its own real data stored in memory.

Every time you write new User(...), Java uses the User class to create a brand new object. That object gets its own copy of id, name, email, and active. Multiple objects can exist from the same class at the same time, and each one holds its own independent data.

Example: creating and using objects

public class Main {
    public static void main(String[] args) {
        User user1 = new User(1L, "Ana Silva", "ana@email.com");
        User user2 = new User(2L, "Carlos Souza", "carlos@email.com");

        user1.deactivate();
        user2.changeEmail("carlos.souza@newmail.com");

        System.out.println(user1.getUserInfo());
        System.out.println(user2.getUserInfo());
    }
}

Here, user1 and user2 are two separate objects, both created from the same User class. Even though they share the same structure, they are completely independent. Deactivating user1 has no effect on user2. Changing the email of user2 does not touch user1.

This is one of the most important things to internalize: the class defines the shape, but each object has its own state.

What is a Method?

A method defines what an object can do. It is a block of code attached to a class that describes a specific behavior or action.

In real backend systems, methods tend to represent either business logic or data access. They are not just utility functions — they express what a concept means in your domain.

Let's look at the methods from our User class more carefully:

public void deactivate() {
    this.active = false;
}

public void changeEmail(String newEmail) {
    this.email = newEmail;
}

public String getUserInfo() {
    return name + " (" + email + ") - Active: " + active;
}

Each method has a clear responsibility:

deactivate() encapsulates the business rule that deactivating a user means setting their active flag to false. Instead of writing user.active = false scattered throughout your code, you put that logic in one place and call it by a meaningful name.
changeEmail() provides a controlled way to update the user's email. You could add validation inside it later without changing anything else in your codebase.
getUserInfo() formats user data into a readable string, separating that concern from whoever is displaying it.

This is the essence of why methods exist: they keep logic organized, named, and reusable.

How the Three Concepts Work Together

These three concepts are not independent — they depend on each other to make object-oriented programming work.

Concept	Role	In our example
Class	Defines the structure and behavior	The `User` blueprint with its fields and methods
Object	A real instance with actual data	`user1` (Ana) and `user2` (Carlos) in memory
Method	An action the object can perform	`deactivate()`, `changeEmail()`, `getUserInfo()`

The relationship is straightforward: you write a class once, create as many objects from it as you need, and interact with those objects by calling methods on them.

Why This Matters in Real Java Development

This is not abstract theory you'll leave behind once you get to "the real stuff". This is exactly the foundation that real backend applications are built on.

When you work with Spring Boot, for instance, your classes become the backbone of the entire application. The User class from this article is one annotation away from being a database entity:

@Entity
public class User {
    // same fields and methods
}

From there, it flows through your entire layered architecture:

Controllers receive HTTP requests and work with User objects
Services contain business logic that operates on User objects
Repositories persist and retrieve User objects from the database

Every layer of a Spring Boot API is built on classes. Every piece of data passing through your system is an object. Every interaction with that data goes through methods. Understanding this clearly makes every other concept in Java easier to grasp.

Final Thoughts

Once you have a solid grip on these three ideas, a lot of what can seem confusing about Java starts to make sense:

Classes give your code structure
Objects are the live, running instances of that structure
Methods define how those instances behave and interact

Everything else in Java — inheritance, interfaces, annotations, frameworks — builds on top of this foundation. Get comfortable with it, and the rest of the language becomes much more approachable.

Where to Go Next

If you feel confident with classes, objects, and methods, the natural next steps are:

Encapsulation and Access Modifiers — understanding why fields are private and what that protects
Inheritance — how one class can extend another to reuse and specialize behavior
Spring Boot REST APIs — applying these concepts in a real web application context

DEV Community: Liriel

Java 27: What Now? 7 Changes Every Developer Should Know

First, what exactly was updated?

1. G1 is now the default GC in every environment

2. Smaller object headers become the default

3. TLS 1.3 gets hybrid post-quantum key exchange

4. JFR redacts sensitive data before it leaves the process

5. The most exciting APIs are still not final

6. Production diagnostics get more useful

7. Migration includes removals and behavior changes

A practical upgrade checklist

So, should you upgrade?

Further reading

Building GitHub Companion taught me a few things about Android architecture...

1. Why Java Still Matters in Android Development

2. Architecture: Demystifying MVVM and Coroutines

3. Under the Hood: Deep Technical Insights

A. Why Room Exists If SQLite Already Exists

B. What Actually Happens When Retrofit Executes a Request

C. Coroutines Are Not Threads

D. Understanding Dependency Injection Through Hilt

E. Why Repository Exists

F. The WorkManager + Hilt Crash That Took Hours to Debug

G. Cache Invalidation Is Harder Than It Looks

H. Why GitHub API Rate Limits Matter

I. Why ANRs Happen

4. Java-Kotlin Interoperability: The Date Formatter

5. Architectural Code Walkthrough

A. Consuming REST APIs (Retrofit Interface)

B. The Repository Pattern (Cache Management)

C. State Management (ViewModel)

6. Key Concepts Comparison: Kotlin vs. Java

7. Application Branding & Interface Preview

8. Clean Code & Mobile Best Practices

9. Conclusion & Learnings

10. References & Further Reading

Java Garbage Collector: Why Creating Objects Is Cheaper Than You Think

The Memory Problem Every Language Must Solve

How Does Java Know an Object Is Dead?

The Observation That Changed Everything

The Heap Is Divided Into Generations

Eden: Where Objects Are Born

Minor GC

Survivor Spaces

Promotion to Old Generation

Major GC and Full GC

The Stop-The-World Moment

Enter G1GC

The Secret Behind Fast Object Allocation

Thread Local Allocation Buffers (TLAB)

Sometimes the Object Never Exists

Is Garbage Collection Free?

Final Thoughts

References

What Are Classes, Objects, and Methods in Java? (Explained Simply)

Classes, Objects, and Methods in Java

What is a Class?

Example: the User class

What is an Object?

Example: creating and using objects

What is a Method?

How the Three Concepts Work Together

Why This Matters in Real Java Development

Final Thoughts

Where to Go Next

Example: the `User` class