How to create a variable that can be set only once but isn't final in Java

Let me suggest you a little bit more elegant decision. First variant (without throwing an exception):

public class Example {

    private Long id;

    // Constructors and other variables and methods deleted for clarity

    public long getId() {
        return id;
    }

    public void setId(long id) {
        this.id = this.id == null ? id : this.id;
    }

}

Second variant (with throwing an exception):

     public void setId(long id)  {
         this.id = this.id == null ? id : throw_();
     }

     public int throw_() {
         throw new RuntimeException("id is already set");
     }

The "set only once" requirement feels a bit arbitrary. I'm fairly certain what you're looking for is a class that transitions permanently from uninitialized to initialized state. After all, it may be convenient to set an object's id more than once (via code reuse or whatever), as long as the id is not allowed to change after the object is "built".

One fairly reasonable pattern is to keep track of this "built" state in a separate field:

public final class Example {

    private long id;
    private boolean isBuilt;

    public long getId() {
        return id;
    }

    public void setId(long id) {
        if (isBuilt) throw new IllegalArgumentException("already built");
        this.id = id;
    }

    public void build() {
        isBuilt = true;
    }
}

Usage:

Example e = new Example();

// do lots of stuff

e.setId(12345L);
e.build();

// at this point, e is immutable

With this pattern, you construct the object, set its values (as many times as is convenient), and then call build() to "immutify" it.

There are several advantages to this pattern over your initial approach:

1. There are no magic values used to represent uninitialized fields. For example, 0 is just as valid an id as any other long value.
2. Setters have a consistent behavior. Before build() is called, they work. After build() is called, they throw, regardless of what values you pass. (Note the use of unchecked exceptions for convenience).
3. The class is marked final, otherwise a developer could extend your class and override the setters.

But this approach has a fairly big drawback: developers using this class can't know, at compile time, if a particular object has been initialized or not. Sure, you could add an isBuilt() method so developers can check, at runtime, if the object is initialized, but it would be so much more convenient to know this information at compile time. For that, you could use the builder pattern:

public final class Example {

    private final long id;

    public Example(long id) {
        this.id = id;
    }

    public long getId() {
        return id;
    }

    public static class Builder {

        private long id;

        public long getId() {
            return id;
        }

        public void setId(long id) {
            this.id = id;
        }

        public Example build() {
            return new Example(id);
        }
    }
}

Usage:

Example.Builder builder = new Example.Builder();
builder.setId(12345L);
Example e = builder.build();

This is much better for several reasons:

1. We're using final fields, so both the compiler and developers know these values cannot be changed.
2. The distinction between initialized and uninitialized forms of the object is described via Java's type system. There is simply no setter to call on the object once it has been built.
3. Instances of the built class are guaranteed thread safe.

Yes, it's a bit more complicated to maintain, but IMHO the benefits outweigh the cost.

Google's Guava library (which I recommend very highly) comes with a class that solves this problem very well: SettableFuture. This provides the set-once semantics that you ask about, but also a lot more:

1. The ability to communicate an exception instead (the setException method);
2. The ability to cancel the event explicitly;
3. The ability to register listeners that will be notified when the value is set, an exception is notified or the future is canceled (the ListenableFuture interface).
4. The Future family of types in general used for synchronization between threads in multithreaded programs, so SettableFuture plays very nicely with these.

Java 8 also has its own version of this: CompletableFuture.