Call by value and call by reference are also called pass by value and pass by reference. The call by ~ form dates back to the ALGOL 60 report published in 1960. Section 4.7.3 of the revised report of 1963 specifies how parameters are passed, with 4.7.3.1 titled "Value assignment (call by value)" and 4.7.3.2 titled "Name replacement (call by name)." The pass by ~ form is also widely used in practice and in textbooks. This article uses call by ~ throughout.

The argument-passing behavior of Java, JavaScript, and Python, which shares an object rather than the caller’s variable itself, is sometimes called call by sharing. The term comes from the design document of CLU, a language created in the mid-1970s by a team led by Barbara Liskov. The object-argument behavior of Java, Kotlin, JavaScript, and Python and the passing of class instances in C#, all covered later, fall into this category. The term "call by object reference" used in the Python tutorial means the same thing. The same structure appears when you pass a map or a pointer in Go, or a pointer in C.

"Call by value" can mislead people into thinking the whole object is copied, and "call by reference" can mislead them into thinking that reassignment is reflected in the caller’s variable. Call by sharing is a good term for avoiding both misconceptions. Some sources use it, such as the MDN JavaScript documentation quoted later, but it has not become a standard term in textbooks or language specifications. This article therefore continues with only the two categories of call by value and call by reference.

The output of the following code shows how Java passes arguments.

By the test defined above, Java behaves as call by value for both primitive types and objects.

Let’s look more closely at passing an object as a method parameter.

If you change the internal state of the object the parameter points to, instead of reassigning the parameter, the changed state is visible through the caller’s variable.

Because the changed state is visible through the caller’s variable, the claim that "objects are passed by call by reference" sounds plausible. As explained above, however, the practical test for the two mechanisms is whether a value assigned to the parameter is reflected in the caller’s variable. The changed state is visible through the caller’s variable only because both variables point to the same object, and what is passed is still a copy of the reference value. In other words, it is call by value.

Head First Java explains object references with the analogy of a TV remote control. Passing an object does not copy the TV (the object); it copies the remote control (the reference value) that operates the TV. If you change the channel with the copied remote (changing object state), the person holding the original remote sees the new channel too. If you pair the copied remote with a new TV (reassignment, targetTv = new Tv()), that remote can no longer operate the original TV, and the original remote is still paired with the original TV.

James Gosling, the creator of Java, addressed this misconception directly in The Java Programming Language, which he coauthored.

Dev.java, the current official Java learning site, says the same thing.

The Dragon Book quoted earlier also states in the same section that Java uses call by value exclusively. In the call-by-reference entry that follows, however, it writes that Java behaves as if it used call by reference for anything other than basic types.

"Behaves as if it used call-by-reference" refers to the effect: the object is not copied as a whole, and changes the called method makes to the object’s state are visible to the caller. The phrase assumes what the book stated earlier, that the actual mechanism is not call by reference.

The word "reference" itself seems to have fed the misconception that Java passes objects by call by reference. Java calls a value that points to an object a "reference," and that word overlaps with the "reference" in "call by reference." Put more precisely, Java passes the reference value that points to an object by call by value.

A Java reference is a value that identifies and gives access to an object. You can think of it as a pointer. The following Java object access

is similar to this C++ code that uses a pointer.

The Java variable myTv holds not the object itself but a value that points to the object. When you pass myTv as an argument to another method, this reference value is copied and passed. The C++ code above is an analogy for object access and pointer reassignment only; it does not mean that object lifetime management or the actual representation of references are the same.

Let’s look at the relevant wording in the JLS (Java Language Specification). The JLS also uses the word "pointer." Section 4.3.1. Objects defines reference values as pointers to objects.

This describes language-level semantics; it does not guarantee that a reference value has the same format as a raw memory address. JVMS (Java Virtual Machine Specification) 2.7 does not mandate any particular internal structure for objects, and notes that in some implementations a reference may point to a handle rather than to the object data. A handle here is a small intermediate structure between the reference and the object data. The reference points to the handle, and pointers inside the handle in turn point to the object data and the method table. In other words, a reference value may not be the memory address where the object resides.

This description of handles originally described "Sun’s current implementation" in the first edition of the JVMS (1997). The second edition changed the wording to "some of Sun’s implementations," and editions after the Oracle acquisition to "some of Oracle’s implementations," but the content stayed the same. At the time of the first edition, Sun’s JVM was the Classic VM of JDK 1.0 and 1.1, and the "Handleless Objects" section of The Java HotSpot Performance Engine Architecture explains that the Classic VM used indirect handles. According to the same section, HotSpot, which today’s Oracle JDK and OpenJDK share, does not use handles and implements object references as direct pointers to objects.

How arguments are passed in a method call is described in Section 8.4.1. Formal Parameters. It says only that the "values" of the argument expressions initialize newly created parameter variables. Nothing in it says that a parameter becomes an alias of the caller’s variable, as call by reference was defined above.

The JLS also describes, step by step, how a method invocation is executed. Section 15.12.4.5. Create Frame, Synchronize, Transfer Control says that once the method to invoke has been determined, a new activation frame is created and the argument values are placed in it. An activation frame is a region of memory that holds the execution state of a method call, such as its parameters, local variables, and return address, and that disappears when the call ends.

The argument "values" are assigned to parameter variables freshly created in the new frame, not to the caller’s variables. This reaches the same conclusion as Section 8.4.1. The reference to the object on which an instance method is invoked (the target reference) is placed in the new frame in the same way and becomes this.

The JVMS defines this frame at the virtual machine level. Section 2.6. Frames says that a new frame is created on the thread’s JVM stack every time a method is invoked, and that each frame has its own array of local variables.

Parameters are passed through this local variable array, as Section 2.6.1. Local Variables explains.

Let’s trace how the reference value of myTv in the earlier reassign example is copied into the parameter targetTv within this structure. Two concepts are needed first.

With these concepts, the call to reassign looks like the figure below. Because reassign is a static method, the parameter targetTv is local variable 0 of the reassign frame. The reference value held by myTv, which javac assigned to local variable 1 of the main frame, is copied into this slot. The JVMS dictates that parameters start at slot 0, but the compiler decides which slot each non-parameter local variable occupies. At the bytecode level, the aload_1 instruction pushes this reference value onto the operand stack of the main frame, and the invokestatic instruction pops it and stores it in local variable 0 of the new frame. The two slots are separate storage belonging to different frames, so assigning a new object to targetTv leaves myTv in the main frame pointing to the original object.

Keep in mind that the JVMS defines an abstract machine. It is a model that specifies the rules for how instructions behave, not the memory layout of a particular implementation. The introduction to Chapter 2 of the JVMS leaves the memory layout of run-time data areas to the implementor’s discretion. For example, machine code produced by a JIT compiler may keep parameters in CPU registers. Even so, the language semantics, in which the caller’s variable and the parameter are separate variables, do not change.

Some sources make it easy to mistake JavaScript function calls for call by reference if you read only part of them. JavaScript: The Definitive Guide, 4th edition, written by David Flanagan and long regarded as the standard JavaScript book, has a summary table in Section 11.2, "By Value Versus by Reference," stating that objects are copied, passed, and compared by reference. From that table alone, it looks as if you could describe JavaScript as call by reference.

Read the explanation of the behavior in the same section, however, and the book’s "by reference" turns out to mean something different from the call by reference defined at the beginning of this article. The book uses the phrase to mean that a reference to the object is passed instead of the whole object value being copied, and it also explains that reassigning the parameter is not reflected in the caller’s variable.

The example that follows this explanation is titled "References themselves are passed by value." The observed behavior the book describes is the same as in this article; only the name for what is passed differs.

C++ also has the pointer parameters (for example, int*) inherited from C, so the two need to be distinguished. Pointer parameters are call by value in C++ too. A function that takes pointers, such as void swap(int* x, int* y), receives copies of the pointer values in its parameters, exactly as in the C example. Assigning a different address to x inside the function is not reflected in the caller’s variable.

An int& reference parameter, on the other hand, has no syntax for reseating it at all. x = y; is not a statement that rebinds the reference to another variable; it assigns a value to the object the reference refers to. Applying the test from above to the two cases gives different results. Assigning to a pointer parameter (int*) leaves the caller’s variable unchanged, while assigning to a reference parameter (int&) changes it.

The C++ standard also describes a reference as an alias, not as a value that is passed. A note in [dcl.ref] says that a reference can be thought of as "a name of an object." Paragraph 4 of the same section explicitly leaves unspecified whether a reference requires storage.

Even though compilers usually implement references as addresses, the standard does not even specify whether a reference has storage.

If you judge by what is copied at the machine level, no language would have call by reference at all. The two terms distinguish the semantics a language defines, not the compiled result.

That said, the C++ standard does not call reference parameters call by reference. Searching the entire standard turns up no occurrence of "call by value," "call by reference," or "pass by value," and only four occurrences of "passed by reference," all in notes or library clauses rather than normative definitions. Instead of naming evaluation strategies, the standard specifies behavior. Paragraph 6 of [expr.call] says only that each parameter is initialized with its corresponding argument.

How a parameter of reference type is initialized is governed separately by the reference binding rules. Call by value and call by reference are not standard terms of any particular language; they are programming language theory terms for comparing argument-passing mechanisms across languages.

Many books and articles recommend making Value Objects completely immutable.

If a VO is immutable, no aliasing bug arises even when several objects share the same instance. An aliasing bug is the problem where changing a value on one side also changes the value on another side that references the same instance. Java’s java.util.Date and Calendar are objects with the nature of values, yet they were designed to be mutable and became a source of such bugs. For example, when two objects share a single Date instance holding a meeting’s start time, calling setTime() on one side changes the start time on the other side as well.

Declaring Meeting as a record is not enough on its own to prevent this problem. A record only prevents assigning a different instance to a field; the internal state of the Date that the field references can still be changed.

The fact that Java 8’s java.time package made all of its date and time classes, such as LocalDate and Instant, immutable also reflects this lesson. If the start time is represented as a LocalDateTime, a date and time without a time zone, plusHours() returns a new instance instead of modifying the existing one, so sharing the instance does not change the start time of the other meeting.

A close look at Fowler’s and Evans’s sentences, however, shows that immutability appears as a guideline, not as the definition of a VO. Fowler presents immutability as a rule for avoiding aliasing bugs, and Evans presents it as an imperative design guideline. The property Fowler presents as the definition of a Value Object is equality by value. The "value objects should be immutable" quoted above also appears, when you read the whole sentence, as a rule he follows in order to avoid aliasing bugs.

In the same article, he even mentions an alternative: aliasing bugs can also be avoided when the language copies the value on every assignment, as with structs in C#.

Evans wrote about immutability in imperative sentences. In the solution part of the DDD Reference quoted above, the criterion for classifying something as a value object is whether you care only about the attributes and logic of the model element. The "Treat the value object as immutable." that follows is an imperative sentence telling you to treat the objects so classified as immutable, and the sentence right after it is also an imperative, telling you to make all operations side-effect-free functions. I read these sentences not as classification criteria but as design guidance for handling the objects once they have been classified.

The comments Fowler left on the ValueObjectsShouldBeImmutable page of Ward Cunningham’s wiki show the distinction between definition and guideline even more clearly. He says not to give a newly designed object any methods that change its state.

And about Value Objects that have already been made mutable, he says the following.

The very premise "If you are using a ValueObject that is mutable" presupposes the existence of Value Objects that are not immutable. The page is also named ShouldBeImmutable, not MustBeImmutable. The Cambridge Dictionary gives the first meaning of should as follows.

The same dictionary explains must as used to show that it is necessary or very important that something happens. If must expresses a necessity that something has to be so, should expresses a recommendation that doing so is the right thing.

On the other hand, some sources do describe immutability as part of the definition.

I see immutability as a desirable design norm rather than a definitional requirement of a VO. On the c2 wiki, Fowler too wrote that newly designed objects should be made immutable. Since a new Value Object is designed to be immutable whichever view you follow, cases where the difference between should and must shows up in practice are not common. Still, the distinction is not meaningless. When you meet a value-like object that was built mutable, like java.util.Date, including immutability in the definition makes that object something other than a VO, while treating immutability as a guideline makes it a VO that fails to follow the immutability guideline. Fowler’s sentence on the c2 wiki is practical advice from the latter viewpoint. It means that if you have already run into a VO that fails the immutability guideline, you should at least treat it as if it were immutable instead of excluding it as not a VO.

It is similar to the difference between including 'not driving after drinking' in the definition of a driver and seeing it as a norm a driver must follow. Either way, the conclusion that you must not drive after drinking is the same, but if the norm is folded into the definition, there is no longer a name for the violations that exist in reality, which makes such cases hard to discuss.

When an instance method carries the synchronized keyword, the instance itself becomes the lock. Even if several threads call synchronized methods on the same instance at the same time, only one thread can enter. The others wait until the first thread leaves the method. A static synchronized method uses the Class object of its class as the lock. So synchronized is a clue to thread safety, and it would seem useful to show it in Javadoc. Javadoc, however, does not print the synchronized keyword in method declarations. Synchronization is considered an implementation detail, not a contract to expose in the API documentation. Item 82 of Effective Java, Third Edition, defends this policy on the same grounds.

synchronized on a method declaration is equivalent to wrapping the whole method body in a synchronized(this) block. That is, the following code

does the same thing as this code:

As the implementation improves, the synchronized region may shrink to part of the method, or a separate lock object may replace this. Such implementation details change more often than the external interface. It is also hard to show every lock-protected region in the method declaration. Some classes synchronize internally with java.util.concurrent.locks.Lock or CAS (Compare And Swap) operations. The presence or absence of the synchronized keyword therefore cannot be the only criterion for thread safety.

In a multithreaded environment, each method call may be safe on its own while a combination of calls is not. For example, a HashMap that is safely published after construction (for instance, through a final field or a volatile variable) and never modified afterward can be read with get() from several threads without problems. But if one thread changes its structure with put() while another calls get(), the result is not guaranteed. The same applies to Hashtable, whose public methods are all synchronized or delegate to synchronized methods and views, and to a Map wrapped with Collections.synchronizedMap(). When two calls are combined, such as checking with containsKey() and then calling put(), a race condition occurs unless the caller holds a lock externally.

What needs documenting, then, is not whether methods are synchronized but under what conditions the class is safe. Since Javadoc has no convention for this, developers have to write it in the class description themselves. The Effective Java classification in the next section provides the criteria.

Item 82 of Effective Java, Third Edition, "Document thread safety" (Item 70 in the Second Edition), recommends documenting thread safety in five levels.

Here are three examples of where and how the Java standard library and Spring Batch describe thread safety.

Apache HttpClient 5 defines a single annotation for thread safety, org.apache.hc.core5.annotation.Contract. Its threading attribute takes a value of the ThreadingBehavior enum.

In the HttpClient 5.5 source, the main classes are declared as follows.

SAFE_CONDITIONAL has a name similar to "conditionally thread-safe" in Effective Java, but it means something different. The Effective Java classification is about which sequences of method calls need external synchronization, while the HttpClient value is about whether the dependencies received through the constructor are thread-safe.

@Contract carries the @Documented meta-annotation, so it appears in the class declaration in Javadoc. Below is the Javadoc for BasicHttpClientConnectionManager.

Because it always appears in the same place, thread safety is visible at a glance. The class description also says "this class is fully thread-safe", but the annotation in the declaration catches the eye first.

HttpClient did not start with its own annotation. Up to HttpClient 4.5.2, HttpGet and the classes from the 5.5 example above were declared with @NotThreadSafe and @ThreadSafe, as shown below.

These annotations lived in the org.apache.http.annotation package, and their Javadoc said they originated in the book "Java Concurrency in Practice". Because of a licensing issue with the original JCIP library, discussed below, HttpCore 4.4.5 removed these four annotations, and HttpClient has used @Contract since 4.5.3.

Each project can define its own annotations, as HttpClient did. Using annotations from widely adopted open source, however, spares users from learning something new. SpotBugs and IntelliJ IDEA, covered later, include the JCIP package in their default lists of recognized annotations. The JCIP annotations that HttpClient 4.x borrowed are the starting point for such shared annotations.

The JCIP annotations are the thread safety annotations proposed in Appendix A of "Java Concurrency in Practice". There are four:

The first three annotations tell users about the class’s contract, and @GuardedBy tells maintainers of the class which lock to respect.

Effective Java, Second Edition (2008) came out after JCIP (2006) and explains its five levels by comparing them with the JCIP annotations. Lining up the two classifications, the four levels other than thread-hostile map onto the three class-level JCIP annotations. Unconditionally thread-safe and conditionally thread-safe are both covered by @ThreadSafe.

In short, Effective Java divides classes into five levels by how much external synchronization users need. JCIP uses a safe-or-not dichotomy with immutability added as a special case, and separates information for maintainers into @GuardedBy. Section 4.5 of JCIP, "Documenting synchronization policies", recommends documenting thread safety guarantees for users and synchronization policies for maintainers.

The original library distributed with the JCIP book is net.jcip:jcip-annotations:1.0 on Maven Central. Its license, however, is Creative Commons Attribution, a license that the Creative Commons foundation itself does not recommend for software. That led to com.github.stephenc.jcip:jcip-annotations:1.0-1, a reimplementation of the same API under the Apache License 2.0. The two libraries share the package name (net.jcip.annotations) and the annotation names.

The JCIP annotations have also been copied into several other projects. The following libraries use the same annotation names in different packages.

The original JCIP library is hard to recommend for new projects because of its license, and JSR-305 because its standardization was abandoned. Instead, considering the coverage of the static analysis tools in the next section, I recommend one of the following two libraries.

SpotBugs, the successor to FindBugs, has one bug pattern for the JCIP annotations, and it is for @Immutable. @GuardedBy and @ThreadSafe have no dedicated checks. Instead, a detector that looks for inconsistently synchronized fields reads them as input to its judgment. SpotBugs recognizes three packages:

The JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS bug pattern, which dates back to FindBugs 2.0, warns when a class annotated with @Immutable has a field that is not final. The SpotBugs 4.10.4 implementation, however, excludes transient and volatile fields from this check.

Create a class declared @Immutable that nevertheless has a setter,

configure the SpotBugs plugin in Gradle,

and run ./gradlew :spotbugs:spotbugsMain. The report contains this line:

The example sets ignoreFailures to true so that the report is printed in full even when there are warnings. To fail the build on violations in real CI, change this setting to false or omit it.

@GuardedBy is handled by the IS_FIELD_NOT_GUARDED bug pattern. This pattern, however, does not find violations by looking at the annotation. The IS2_INCONSISTENT_SYNC detector estimates missing synchronization from the proportion of field accesses made while holding a lock. When a field carries @GuardedBy("this"), the detector treats it differently in three ways:

The only value it recognizes is "this". The detector treats fields where less than half of the accesses hold the lock as likely false positives and lowers their priority.

That is why Counter in the same project is not reported with the default settings, even though it modifies a @GuardedBy("this") field without a lock. The read and write in increment() happen without a lock, and only the read in the synchronized method get() holds it. One of three accesses, or 33%, holds the lock. Only when you make the example report low-priority warnings too with ./gradlew :spotbugs:spotbugsMain -PreportLow does it appear.

The class below has the same violation plus two more synchronized methods, which brings the locked accesses to 60%.

This class is reported with high priority even with the default settings. The first letter of the output is the priority and the second is the category.

The same detector also reads @ThreadSafe and @NotThreadSafe. It excludes fields of @NotThreadSafe classes from the check and uses @ThreadSafe on a class as grounds for raising the warning priority of its fields. It does not verify that the contract declared by the annotation is kept. A class declared @ThreadSafe can hold a field of a @NotThreadSafe type without a warning.

In short, the only thing SpotBugs checks deterministically from annotations alone is the final rule for @Immutable classes. @GuardedBy violations are also reported as estimates based on the proportion of locked accesses; the annotation only changes the candidates and priority of that estimate.

Google’s Error Prone plugs into javac and checks rules that prevent errors at compile time.

IntelliJ IDEA 2026.2 has six inspections in the Concurrency annotation issues group. Five are for @GuardedBy and one is for @Immutable. No inspection verifies contracts declared with @ThreadSafe.

The Unguarded field access or method call inspection recognizes @GuardedBy from all of these packages:

SpotBugs also reads the original JCIP package, but it handles only @GuardedBy("this") and stops at warnings guessed from access proportions. IntelliJ, by comparison, directly checks the guard expressions of the original JCIP annotation.

The Non-final field in @Immutable class inspection warns when an @Immutable class has a field that is not final. It does not check whether field types are mutable, so its depth is closer to SpotBugs than to Error Prone. Unlike SpotBugs, though, it also warns about transient and volatile fields. The markers this inspection recognizes are:

@ThreadSafe is read only as a hint by the Access to static field locked on instance inspection in the "Threading issues" group. This inspection warns when code holding an instance lock accesses a non-constant static field. If the accessed field is final, it checks the annotations on the field’s declared type and skips the warning if a registered thread safety annotation is present. It therefore does not verify the contract of the annotated class itself. The default list contains these annotations:

Error Prone’s @ThreadSafe is not in the default list.

However, the inspection registrations in IntelliJ IDEA 2026.2 declare every inspection in the "Concurrency annotation issues" group with enabledByDefault="false" and level="WARNING". You have to turn them on yourself under Settings | Editor | Inspections | Java | Concurrency annotation issues. Even when enabled, they are editor warnings and cannot block javac compilation the way Error Prone does. Enforcing them in CI requires a separate runner such as Qodana. Qodana is a code quality platform from JetBrains that runs the same inspections as IntelliJ IDEA in CI, as a Docker image or a command-line tool. You enable the checks in a Qodana profile and set a failure condition.

Across the three tools, the range checked deterministically from annotations alone is narrow.

This is why I recommended either error_prone_annotations or jcip-annotations earlier. If you need checks that block compilation, use annotations that Error Prone recognizes. If you want to mark all four annotations and still get checks from your IDE and SpotBugs, use the net.jcip.annotations package (the Apache-licensed reimplementation).

The example has a class annotated with @NotThreadSafe and a controller that holds it as a field. The controller also has a SimpleDateFormat field. The full project is in examples/thread-safety-archunit.

The ArchUnit test consists of two rules.

The first rule fails if the type of any field in a class annotated with @RestController carries @NotThreadSafe, without separately analyzing external synchronization or bean scope. ArchUnit reads annotations from bytecode. It can therefore check annotations with RUNTIME retention, such as the original JCIP annotations, as well as those with CLASS retention, such as the JSR-305 annotations and HttpClient’s @Contract. The example rule looks only at net.jcip.annotations.NotThreadSafe, though, so checking annotations from other packages or the threading value of @Contract requires additional conditions. Library classes outside the analyzed packages are also read from the classpath under the default settings, so the same rule can check @NotThreadSafe that a library has applied.

The second rule is for JDK classes that carry no thread safety annotation, such as SimpleDateFormat. It lists Format, Calendar, and StringBuilder explicitly.

Running ./gradlew test with ArchUnit 1.5.0, Spring Web 7.0.9, JUnit 6.1.3, and JDK 25 fails both rules and reports which field broke each rule.

HealthController in the same project, which holds only Clock and DateTimeFormatter as fields, passed both rules.

ReportController, caught by the rules, can be fixed by holding the immutable DateTimeFormatter as a field instead of SimpleDateFormat, and by confining ReportFormatter to a local variable of the request-handling method.

After changing ReportController this way and running the test again, both rules pass. ReportFormatter is created anew on each call and is not shared with other request threads. Passing the rules, however, does not prove the thread safety of the whole controller. Other shared state and race conditions in sequences of method calls need separate review.

This approach also has limits.