Syntax & Basic Constructs

Java has three: single-line starting with //, multi-line wrapped in /* ... /, and Javadoc written as /* ... */ which is a documentation comment the javadoc tool reads. All of them are ignored by the compiler.

Rules are what the compiler enforces; conventions are agreed style. By convention: classes use UpperCamelCase, variables and methods use lowerCamelCase, constants use UPPER_SNAKE_CASE, and packages are all lowercase. Breaking a convention still compiles, but it's bad style.

A Java identifier can contain letters, digits, the dollar sign ($), and the underscore (_). It can start with a letter, $, or _, but it cannot start with a digit.

Keywords are words Java reserves for its own grammar (like class, if, return, int). The compiler treats them specially, so you can't use them to name your own variables, methods, or classes.

An expression produces a value (like 2 + 3 or x). A statement performs an action and is a complete instruction the program runs (like x = 5; or an if). Expressions compute things; statements do things.

The semicolon ends a statement, like a period ends a sentence. Each instruction - a variable declaration, an assignment, a method call, return - finishes with a ';'. Blocks wrapped in { } and class/method headers do not take one.

Mostly no. Java ignores spaces, tabs, and blank lines between tokens, so you can add them freely for readability. But you need at least one space to separate words like 'int x', and whitespace inside text in quotes is kept exactly.

No. Unlike fields, a local variable in an inner block cannot reuse the name of a local variable from an enclosing block — the compiler reports an error. The inner block can still see the outer variable, but it cannot redeclare it.

Words like String, System, main, args, and length are NOT keywords — they're class names, method names, or fields from the libraries. Keywords are the fixed grammar words like class, public, and void. You could even reuse the library names as your own (though it's a bad idea).

Besides ordinary blocks, a class can have a bare { } block (instance initializer) that runs when an object is created, and a static { } block that runs once when the class is loaded. Variables you declare inside these blocks are local to the block, but they can read and set the class's fields.

A block comment ends at the very first / the compiler sees. So if you put one / */ inside another, the inner */ closes the whole thing, and the leftover text after it becomes real code that usually fails to compile.

Comment to explain WHY, not WHAT. If a comment just restates the code, rename things or extract a method instead. Use Javadoc for public APIs. Comments that explain confusing code often mean the code should be made clearer.

Yes. Java allows Unicode letters in identifiers, so you can use characters from other languages, like accented letters or non-Latin scripts. A 'letter' is not limited to A–Z; many Unicode letter characters and currency symbols are allowed too.

goto and const are reserved words in Java but they have no use — you cannot write working code with them. Java reserved them so they can't be variable names and to leave the door open and give clearer errors.

An expression statement is an expression followed by a semicolon, like x = 5; or list.add(y);. Java only allows expressions that have a useful side effect (assignment, ++/--, method call, new). A bare value like a + b; is rejected because computing and discarding it is pointless.

The compiler ignores formatting, but people don't. Consistent indentation and spacing make code easy to read, review, and change. Teams use auto-formatters so everyone's code looks the same and diffs only show real changes.

You need whitespace when two pieces of code would otherwise stick together into one word, like 'int x' (without the space it becomes the single name 'intx'). The compiler reads the longest possible word at a time, so it can't split joined words by itself.

Local variables get no default value, so Java forces you to assign one before you read it. The compiler checks this per path through the code. Where you declare a variable (which block) and which branches assign it decide whether every path has given it a value.

A variable declared inside the loop body is fresh on every iteration; one declared outside is shared across all iterations. This matters for lambdas, which can only capture variables that are effectively final — a fresh per-iteration variable can be captured, a shared mutating one cannot.

Inside a string the characters are just data, not source syntax. The lexer knows it is reading a string, so it does not treat // or /* as comment starters. So System.out.println("http://x") prints the whole URL.

A lone underscore (_) used to be a legal name, but modern Java reserved it. You can no longer use just _ as a variable name; it now marks an unnamed (ignored) variable instead.

Contextual keywords (like var, yield, record, sealed) only act as keywords in certain places. Everywhere else they're ordinary names, so old code that used them as variable names still compiles.

A switch statement performs branching but produces no value. A switch expression (Java 14+) evaluates to a value you can assign or return, using arrow labels (case A -> ...) or yield. So the same keyword can be either a statement (does an action) or an expression (produces a value).

Technically they are reserved literals, not keywords — true/false are boolean literals and null is the null literal. But like keywords, you cannot use them as names.

The empty statement is just a single semicolon (;) that does nothing. It is legal anywhere a statement is allowed. It causes bugs when a stray semicolon ends a loop or if early, e.g. while (cond); accidentally makes an empty loop body.

Java separates how code looks from what it means: braces define blocks and semicolons end statements, so spacing is free. This makes parsing simple and unambiguous. Python instead uses indentation for structure, and JavaScript guesses missing semicolons - each choice trades off layout flexibility against safety and simplicity.

In an expression-oriented language almost everything produces a value (even if/blocks). Java is mostly statement-oriented: control flow like if/for produces no value, and you sequence actions explicitly. Statement-orientation is simpler and explicit; expression-orientation reduces boilerplate and mutable variables.