Operators are the verbs of the language: what turns inert data into calculations. You have already used + and - intuitively, but Java has a broad catalogue and several traps that catch everyone at least once: integer division discarding the decimals, the difference between i++ and ++i, string comparison with == that sometimes works and sometimes does not, and the treacherous precision of double when money is involved. This lesson goes through them all calmly, always on the same BiblioTech case: calculating the late fine for a loan from the Nexus Software library.

1. Arithmetic operators and the integer-division trap
2. The modulo operator
3. Compound assignment operators
4. Increment and decrement: pre and post
5. Relational operators
6. Logical operators and short-circuit evaluation
7. The ternary operator
8. Bitwise and shift operators
9. The instanceof operator
10. Precedence and associativity
11. Comparing strings: == versus equals
12. The precision of double and why BigDecimal exists
13. Common Mistakes and Tips
14. Exercises

The five basic arithmetic operators:

It is the number one mistake of anyone starting out in Java:

The rule is this: if both operands are integers, the division is an integer division and the result is truncated towards zero, discarding the decimals. Java does not round, it cuts.

And this is not fixed by storing the result in a double:

Why? Because the operation total / parts is evaluated first, between integers, giving 2; only afterwards is that 2 converted to a double. The conversion arrives too late.

The three correct solutions:

Watch the order in the cast: (double)(total / parts) does not work. The parentheses make the integer division happen first and the conversion afterwards: it gives 2.0. The cast has to be applied to one of the operands.

It depends on the type, and the difference matters:

Integer division by zero throws a runtime error. Decimal division produces special values (Infinity, NaN) that propagate silently through every later calculation, which can be worse: you end up printing NaN EUR on a receipt without ever having seen an error.

Here daysLate is an int and DAILY_RATE is a double: Java promotes the integer to a decimal before multiplying and the result is correct. Automatic promotion saves us; division is the only one to watch out for.

% returns the remainder of an integer division. It is far more useful than it looks at first sight.

Common uses:

Applied to BiblioTech, to express the delay in weeks and leftover days:

Notice how / and % work as a pair: one gives the quotient, the other what is left over. It is a pattern that will come back many times.

They are shortcuts for operating on a variable and storing the result back in it:

There is a little-known detail: compound assignment includes an implicit cast. This compiles:

whereas the equivalent "long" form does not compile:

It is an asymmetry in the language that can hide precision loss with no warning at all. It is worth knowing about.

++ adds 1 and -- subtracts 1. What is interesting is that they can be written before or after the variable, and that changes the value of the expression:

• Post-increment x++: uses the current value, and then increments.
• Pre-increment ++x: increments first, and then uses the new value.

The table sums up the difference, always starting from x = 5:

When it really matters: if the ++ is alone on its own line (counter++;), pre and post are identical and it makes no difference which you use. The difference only shows up when the value of the expression is used for something, such as an assignment, an index or an argument.

Practical advice: do not write expressions that depend on that subtlety. Code like int x = i++ + ++i; is a riddle, not a program. When it matters, split it into two clear lines.

They compare two values and always produce a boolean:

It repeats the idea from the previous lesson: a comparison is an expression that is worth true or false on its own. You do not need an if to obtain it; the if (module 2) is for deciding what to do with it.

Two warnings:

• == compares values for primitives, but references for objects. That is the topic of section 11.
• The most expensive typo in programming is writing = (assignment) where you meant == (comparison). In Java, fortunately, if (x = 5) does not compile unless x is a boolean, because an int assignment does not produce a boolean. The compiler protects you.

They combine boolean values:

Truth tables:

Applied to BiblioTech:

This is the important part. && and || are lazy: they stop evaluating as soon as the result is already decided.

• In a && b, if a is false, the result is false whatever happens with b. b is not evaluated.
• In a || b, if a is true, the result is true whatever happens with b. b is not evaluated.

Why does it matter? Because it lets you protect dangerous operations by putting the safety check first:

The order of the conditions is not cosmetic: it is functional. Remember it, because it is a pattern you will use constantly from module 6 onwards.

There are & and | applied to booleans, which always evaluate both sides:

In practice && and || are used almost always. Remember that & and | also have a completely different meaning on numbers, which is the next section.

It is Java's only operator with three operands. Its form is:

It reads: "if the condition is true, the result is the first thing; otherwise, the second".

This line does something very valuable for us: it stops the delay from being negative. If the book is returned after 10 days, 10 - 15 would give -5, and a negative fine would be absurd (the library paying the employee!). The ternary lets us fix it without using if, which we have not seen yet.

The most common use is adapting a piece of text:

They can be nested, but readability degrades very quickly:

Practical rule: the ternary is excellent for choosing a value; as soon as you want to run several different actions, you need an if, which arrives in lesson 02-01.

These operators work on the binary representation of integers. At first they look esoteric, but they show up in permissions, flags, cryptography, image processing and network protocols, and in technical interviews.

A reminder: an int is 32 bits. The number 12 is 00000000 00000000 00000000 00001100, and 10 is ...00001010.

The result ~12 = -13 is surprising. The reason is that Java represents negative integers in two's complement, where ~x is always equivalent to -x - 1.

The relationship with arithmetic is direct and very easy to remember:

• x << n is equivalent to multiplying by 2ⁿ
• x >> n is equivalent to dividing by 2ⁿ (integer division)

Where these operators really shine is packing several boolean options into a single integer. In BiblioTech we could encode an employee's permissions over the catalog:

Four booleans in a single int, with instant checks. It is the mechanism behind Unix file permissions and a great many APIs.

instanceof checks whether an object is of a given type and returns a boolean:

It is mentioned here only to complete the catalogue of operators. Its real usefulness appears when there are type hierarchies and polymorphism, that is, from module 3 onwards. Since Java 16 it also supports pattern matching (if (obj instanceof String s)), which is studied in module 10.

When an expression combines several operators, Java applies a fixed order. From highest to lowest priority:

Associativity decides what happens when there are operators of the same level: 10 - 4 - 3 groups as (10 - 4) - 3 = 3, not as 10 - (4 - 3) = 9.

Examples where precedence changes the result:

And a real BiblioTech case where parentheses are missing:

The definitive advice: do not memorise the table. Use parentheses. Nobody has ever failed a code review for adding extra parentheses, and plenty of people have lost hours trusting precedence. Parentheses document your intent.

It is the classic Java mistake par excellence, and the worst part is that sometimes it works, which delays the diagnosis for weeks.

Remember from the previous lesson that a String variable does not contain the text, but a reference to an object on the heap. And == on references compares whether they point to the same object, not whether the content is equal.

The JVM maintains a string pool: a special area where it keeps literals. When it compiles String a = "Effective Java"; and then String b = "Effective Java";, it sees that the literal is identical and makes both variables point to the same object in the pool. That is why a == b gives true. It is a memory optimisation, not a promise of the language.

But new String("Effective Java") forces the creation of a new object, outside the pool. Now there are two objects with the same text at different addresses, and == gives false.

a == b compares #p1 == #p1 → true. a == c compares #p1 == #h9 → false. In both cases the text is the same.

To compare the content of two Strings, always use equals(). Never ==.

Why the danger is real: strings arriving from a Scanner, from a file or from the network are not in the pool. So your == comparison will work perfectly in tests with literals and fail with real data.

A common defensive technique is putting the literal on the left, because a literal is never null:

Summary table:

One last warning, particularly relevant because BiblioTech handles money:

This is not a Java bug: it happens in Python, JavaScript, C and practically every language. The cause is that float and double follow the IEEE 754 standard, which represents numbers in binary. Just as in decimal you cannot write 1/3 exactly (0.3333…), in binary you cannot write 0.1 exactly. The stored value is an excellent approximation, but an approximation.

Practical consequences:

• Never compare two doubles with ==. Compare whether their difference is smaller than a tolerance: Math.abs(a - b) < 0.0001.
• Never use double for money in a real system. The errors accumulate over thousands of operations and end up throwing the accounts off.

Java's solution is the BigDecimal class, which represents decimals with exact precision and lets you control rounding:

It has a cost: it is more verbose (you cannot use +, you have to call add()) and slower. It is studied in module 10; in this course we will keep using double for BiblioTech fines because the focus is on learning the language, but you have been warned: in a real billing system, BigDecimal.

• 5 / 2 gives 2. Integer division. Apply a cast to one of the operands: (double) 5 / 2.
• (double)(5 / 2) still gives 2.0. The cast arrives after the division. It must be applied to an operand, not to the result.
• Comparing Strings with ==. It works with literals and fails with input data. Always use equals().
• Comparing doubles with ==. Use a tolerance.
• Forgetting the parentheses in (a - b) * c. Multiplication has higher priority than subtraction.
• Confusing & with &&. On booleans, && avoids evaluating the second operand; & does not. On integers, & is a completely different bitwise operation.
• Getting the order of guarded conditions wrong. x != null && x.length() > 0, never the other way round.
• Writing acrobatic expressions with ++. If you have to stop and think, refactor it into two lines.
• Tip: use parentheses whenever an expression has more than two operators. There is no performance penalty and the gain in clarity is enormous.
• Tip: Integer.toBinaryString(n) is the best tool for understanding the bitwise operators. Try it in JShell.
• Tip: the ternary is perfect for clamping values to zero (x > 0 ? x : 0), a pattern you will use a lot in BiblioTech so that the days late are never negative.

Without running the code, write the output of each line and justify why.

Write the class FineCalculator that, from the following constants and data, calculates and displays the settlement of a loan:

• Constants: LOAN_DAYS = 15, DAILY_RATE = 0.25, MAX_FINE = 20.0, SEVERE_SURCHARGE = 1.5 (a multiplier applied if the delay exceeds 30 days).
• Loan data: employee "Diego Alonso", book "Refactoring", elapsedDays = 52.

It must calculate and display:

1. The days late, which can never be negative (use the ternary operator).
2. The delay expressed in whole weeks and leftover days (use / and %).
3. The base fine (daysLate * DAILY_RATE).
4. The fine with the surcharge if the delay exceeds 30 days (use the ternary).
5. The final fine, never exceeding MAX_FINE (use the ternary).
6. A severity label: "ON TIME", "MINOR" (1-7 days) or "SEVERE" (more than 7), with nested ternaries.

All of it without using if.

Using the bitwise operators, write the class BiblioTechPermissions that:

1. Defines four permission constants with values 1, 2, 4 and 8: view, lend, reserve and administer.
2. Composes the permissions of three Nexus Software employees: Marta Ruiz (view + lend), Diego Alonso (view + lend + reserve) and Nuria Vidal (all four).
3. Shows for each one the integer value of their permissions, its binary representation and whether they can administer.
4. Adds the reserve permission to Marta Ruiz using |= and shows the result.

Solution 1

Justifications:

• 7 / 2 → 3. Both operands are int: truncated integer division.
• 7 % 2 → 1. The remainder of dividing 7 by 2.
• 7.0 / 2 → 3.5. Since 7.0 is a double, the 2 is promoted and the division is a decimal one.
• (double)(7 / 2) → 3.0. The parentheses force the integer division first (3) and the cast arrives afterwards.
• x++ → 5, and immediately after x is 6. Post-increment returns the previous value.
• x → 6. Confirms the earlier increment.
• ++x → 7. Pre-increment increments first (7) and returns the new value.
• 2 + 3 * 4 → 14. * has higher precedence than +: 3*4=12 is computed and then 2+12.
• 10 - 4 - 3 → 3. Left associativity: (10-4)-3.
• a == b → true. Both are identical literals, so the JVM shares them in the string pool and the two references point to the same object.
• a == c → false. new String(...) creates a different object outside the pool; the references differ even though the text is the same.
• a.equals(c) → true. equals compares the content, which is indeed identical.
• 0.1 + 0.2 == 0.3 → false. The IEEE 754 representation of 0.1 and 0.2 is approximate; the sum gives 0.30000000000000004.
• 12 & 10 → 8. In binary, 1100 & 1010 = 1000, which is 8.
• 12 << 2 → 48. Shifting 2 bits to the left is equivalent to multiplying by 2² = 4.

Solution 2

Output:

Look at the 13.875: three decimals for an amount in euros. It is exactly the kind of result that in a real system would demand BigDecimal or, at the very least, formatting to two decimals. We will solve that last part in the next lesson with printf.

Solution 3

Output:

Two details worth attention:

• The parentheses in (martaPermissions & ADMINISTER) != 0 are mandatory, not optional. & has lower precedence than !=, so without them Java would try to evaluate martaPermissions & (ADMINISTER != 0), which does not even compile because it mixes int and boolean.
• Integer.toBinaryString does not show leading zeros: 3 appears as 11, not as 0011. That is normal; it represents the same value.

You now have a grip on Java's full operator catalogue: arithmetic with its integer-division trap, the modulo and its natural pairing with /, compound assignment with its hidden implicit cast, pre- and post-increment and when the difference matters, comparisons that produce booleans, the logical operators with the short-circuit evaluation that lets you guard dangerous expressions, the ternary for choosing values without if, bitwise operations applied to permission flags, precedence and the advice to use parentheses, the critical difference between == and equals explained by the string pool, and the precision limits of double that will one day lead you to BigDecimal. With all of that, BiblioTech can already calculate a complete fine: days late clamped to zero, a severity surcharge and a maximum cap.

In the next lesson, Console Input and Output, we will fix what has been left ugly in these examples: we will stop printing amounts like 13.875 and learn to format output with printf (%.2f, widths, alignment), and above all we will stop having the data hard-coded so we can ask the user for it with Scanner. It is the last ingredient before building the first complete version of BiblioTechApp.