How Is Java Programming Different from Regular Programming?

# A typical "regular" script (Python)
def greet(name):
    return "Hello, " + name

print(greet("Uncodemy"))

// The same idea in Java
public class Greeter {
    public static String greet(String name) {
        return "Hello, " + name;
    }

    public static void main(String[] args) {
        System.out.println(greet("Uncodemy"));
    }
}

Java compilation pipeline:
1. Write source code       → Greeter.java
2. Compile with javac      → Greeter.class (bytecode)
3. Run with java           → JVM loads and executes bytecode

The bytecode is not tied to Windows, macOS, or Linux.
The JVM translates it for the underlying operating system.

What the JVM handles for you:
□ Class loading
□ Bytecode verification
□ Memory allocation
□ Garbage collection
□ Just-in-time compilation
□ Platform-specific system calls

This is why Java programs can move between environments
without rewriting the core application logic.

public class Student {
    private String name;
    private int score;

    public Student(String name, int score) {
        this.name = name;
        this.score = score;
    }

    public boolean hasPassed() {
        return score >= 40;
    }

    public String getName() {
        return name;
    }
}

class Student:
    def __init__(self, name, score):
        self.name = name
        self.score = score

    def has_passed(self):
        return self.score >= 40

# No type declarations required.
# Errors like passing a string score may appear at runtime.

Java memory model basics:
- Objects live on the heap.
- References live on the stack or inside other objects.
- The garbage collector finds objects with no reachable references.
- Developers do not call free() or delete.

Benefit:
Less manual memory management, fewer crashes caused by
dangling pointers.

Trade-off:
GC pauses and heap tuning can matter in very large systems.

How JIT helps:
1. The JVM starts by interpreting bytecode.
2. It watches which methods run often.
3. Hot methods are compiled to native machine code.
4. The program gets faster over time.

This is different from a purely interpreted script,
where the same work may be repeated without this
kind of adaptive optimization.

Typical Java build workflow:
1. Declare dependencies in pom.xml (Maven) or build.gradle (Gradle)
2. Compile source files
3. Run tests with JUnit
4. Package into a JAR or WAR
5. Deploy to a server or container

This standardized workflow is one reason Java is common
in large organizations with many teams.

Common enterprise Java stack:
- Spring Boot for REST APIs and services
- Spring Data for database access
- Spring Security for authentication and authorization
- JUnit and Mockito for testing
- Docker and Kubernetes for deployment
- Prometheus and Grafana for monitoring

This ecosystem is broader than what most "regular"
scripting languages provide out of the box.