DEV Community: Liriel

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

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