23

I've seen objects created in Java code without storing a reference to the object. For example, in an eclipse plugin I've seen a SWT Shell created like so:

new Shell();

This new Shell object is not stored in a variable, but will remain referenced until the window is disposed which [I believe?] happens by default when the window is closed.

Is it bad practice to create objects like this without storing a reference to them? Or was the library poorly designed? What if I don't have need of a reference, but only want the "side effects" of the object? Should I store a reference anyways?

UPDATE:

Admitedly, my above example is poor. While I have seen UI elements created like this, creating a SWT Shell like this would probably be pointless because you need to call the open method on the Shell instance. There are better examples provided by aix such as the following from the Java concurrency tutorial:

(new HelloThread()).start();

This practice is seen in many contexts, so the questions remains. Is it good practice?

Community
  • 1
Buttons840
  • 1,866
  • 3
    What would be the point of storing the reference? – Daniel R Hicks Jan 12 '12 at 20:22
  • (It probably would be better, from a conceptual point of view, to have a static method such as Shell.createTopLevelShell() or whatever, vs using a constructor in this case. But functionally there's little difference.) – Daniel R Hicks Jan 12 '12 at 20:25
  • Is this question about the practice of creating objects without referring to them, creating classes that require this practice, or is it specifically about the way SWT uses this sort of pattern? – StriplingWarrior Jan 12 '12 at 20:34
  • @StriplingWarrior Is this bad practice on the part of the library designer or library user. I'm not asking about SWT specifically. – Buttons840 Jan 12 '12 at 20:36
  • 1
    SWT objects must be dispose()d: Rule 1: If you created it, you dispose it. http://www.eclipse.org/articles/swt-design-2/swt-design-2.html – jbindel Jan 12 '12 at 20:40
  • I never intended for this to be about SWT specifically. – Buttons840 Jan 12 '12 at 21:04
  • @Buttons840: I'm removing the SWT tag to remove any further confusion that this is about SWT in particular. – Edward Thomson Jan 12 '12 at 21:25
  • 2
    I would use a variable to hold a reference for debugging purposes. If you have a break point in this method then you can get the debugger to query the object via the local variable. Without the reference I am sure it is possible but probably a lot harder. – Martin York Jan 12 '12 at 22:35

6 Answers6

14

There's an element of personal preference to this, but I think that not storing the reference is not necessarily a bad practice.

Consider the following hypothetical example:

new SingleFileProcessor().process(file);

If a new processor object needs to be created for every file, and is not needed after the process() call, there's no point in storing a reference to it.

Here is another example, taken from the Java concurrency tutorial:

(new HelloThread()).start();

I've seen lots of other examples when the reference is not stored, and that read perfectly fine to my eye, such as:

String str = new StringBuilder().append(x).append(y).append(z).toString();

(The StringBuilder object is not kept.)

There are similar patterns involving common.lang's HashCodeBuilder et al.

NPE
  • 292
  • It's up to the factory whether to use a singleton or not. Caller of the factory shouldn't think about it too much. – Donal Fellows Jan 12 '12 at 20:33
  • In your example the FileProcessor instance is (presumably) not needed once the statement is complete, whereas in the OP's example the Shell instance is (under the covers) referenced by another object, and that reference (and therefore the Shell object) persists beyond the duration of the statement. – Daniel R Hicks Jan 12 '12 at 20:33
9

If you don't need a reference to the created object, then don't hold onto the reference. It's as simple as that.

Mike Baranczak
  • 2,614
  • 16
  • 16
5

In general, it's good practice to release references as quickly as they can reasonably be released. I see no difference between:

HelloThread thread = new HelloThread();
thread.start();
// where thread is never used for the rest of the method

and

(new HelloThread()).start();

As far as the code is concerned, you're just avoiding the use of a variable name, which could be a positive thing. The JIT compiler is generally smart enough to recognize it can garbage collect the thread after its last use, so there's probably no difference from a performance standpoint.

The only real issue to avoid is the Code in the Constructor Anti-Pattern, but it doesn't sound like that's what you're asking about.

snipsnipsnip
  • 105
StriplingWarrior
  • 2,407
  • 1
  • 16
  • 21
3

This could be bad if you're using SWT, because there you have to clean up after yourself (calling the dispose() method). But for other classes (non SWT) it's ok.

Here's an article about Managing Operating System Resources

Alex
  • 31
  • 3
  • Circular references do not prevent objects from being garbage collected in Java. Any modern Java VM determines whether objects are GCable based on whether they are reachable, and does not use reference counting. – jbindel Jan 12 '12 at 20:26
  • 2
    Indeed it doesn't use reference counting. But SWT is a special case where we do need to call dispose(), though there is no need to call any retain() first. – Alex Jan 12 '12 at 20:30
  • I meant to refer only to the non-SWT case. – jbindel Jan 12 '12 at 20:33
  • Here's an article about Managing Operating System Resources http://www.eclipse.org/articles/swt-design-2/swt-design-2.html – Alex Jan 12 '12 at 20:34
  • 2
    In that case edit your answer to remove the statement about “impossible to GC” as it is misleading. – Donal Fellows Jan 12 '12 at 20:34
  • Your point about not being able to call dispose() is actually very important. – jbindel Jan 12 '12 at 20:38
  • @Fly and Alexandra N - My own experience suggests that at least Shells do not need to be explicitly closed. I have asked for more details in another question: http://stackoverflow.com/q/8842479/565879 – Buttons840 Jan 12 '12 at 21:26
  • Can't you call dispose () from inside the object? I can do it with Swing. – user unknown Jan 13 '12 at 08:51
  • No, you can't call dispose() from inside the object on the object itself. – Alex Jan 13 '12 at 09:46
0

First of all, you're going to annoy people who learned C or C++ before Java. I'll leave that as an exercise for the reader to decide if that's a pro or a con.

While there are certainly situations in which objects are designed to be very short-lived, most of the time if something is complex enough to create an object for, it's complex enough to have good reasons to keep a reference, so not keeping it should at the very least be a warning to double check if you have missed something.

For example, in a tutorial no one cares about keeping a thread reference, but in real life, if something takes long enough that you want to spawn a thread, it usually takes long enough that you want to be able to cancel the thread. Or if shorter-lived, you usually are spawning a bunch of threads you will want to join before continuing. Or you want to make sure your thread creation actually succeeded. Or you want to make sure the thread finishes cleanly before exiting. You get the picture.

Karl Bielefeldt
  • 147,435
  • 2
    Is worrying about annoying programers from other languages really the first concern? – Buttons840 Jan 13 '12 at 16:40
  • It makes it a readability/familiarity/style issue depending on the composition of your team, because it's a style a lot of people carry over. Even people who have never programmed in C++ often adopt styles from their mentors who did. – Karl Bielefeldt Jan 13 '12 at 17:26
0

One good reason to create a reference is so you can give it a good, useful name to aid in documentation, especially of the class name is poor or overly general. e.g. (somewhat contrived)

HelloThread helloBasedUponPrivilige = new HelloThread(userLoginInfo);
helloBasedUponPrivilige.start();
user949300
  • 8,823