What would you do?

[James Yong]

Hi,

Let say I have a method in a helper class that is used throughout my java
project. This method changes a string value to empty if it has a null value.

public final String emptyStringIfNull(String a)
{
return a==null?"":a;
}

Would it be better to make this mathod to be static and synchronized?
On one hand, I am worry about the trade off in the slowdown caused by
synchronization..
On the other, I find it a sore to always to instantiate the helper class.

What are your views on it?

Regards,
James Yong

 

[Lars]

Would it be better to make this mathod to be static and synchronized?

There is no point at all in making this method synchronized, as it does
not access any shared object. I would make it static, not synchronized.

Lars

 

[Roedy Green]

public final String emptyStringIfNull(String a)
{
return a==null?"":a;
}

Would it be better to make this mathod to be static and synchronized?

You should make it static, but I don't see any need for it to be
synchronised. It uses only a local variable. Every thread has its own
copy of that local variable if it running your method.

 

[Gijs]

For this particular example, you could also just use the String.valueOf()
method.

- Gijs

 

[Thomas Hawtin]

public final String emptyStringIfNull(String a)
{
return a==null?"":a;
}

For this particular example, you could also just use the
String.valueOf() method.

You would get a different result. String.valueOf((String)null) returns
"null". (Languages lawyers will tell you that String.valueOf(null) will
select the most specific overload, which is String.valueOf(char[]) which
will NPE.)

Tom Hawtin

 

[Bryce]

Hi,

Let say I have a method in a helper class that is used throughout my java
project. This method changes a string value to empty if it has a null value.

public final String emptyStringIfNull(String a)
{
return a==null?"":a;
}

Would it be better to make this mathod to be static and synchronized?
On one hand, I am worry about the trade off in the slowdown caused by
synchronization..

Static is ok, but why Synchronized? There's no global data in there...

 

[James Yong]

There is no point at all in making this method synchronized, as it does
not access any shared object. I would make it static, not synchronized.

Lars

Actually I thought that when the method is static, there could be a
possibility of two threads in the same method. I seems to have forgotten all
about shared and local variable.

Thanks all for the reply. Cheers.

 

[Roedy Green]

Actually I thought that when the method is static, there could be a
possibility of two threads in the same method. I seems to have forgotten all
about shared and local variable.

Yes, there is the possibility of two threads in both static and
instance methods. However, unless there ARE multiple threads, you
don' t usually bother making methods thread safe, unless they are for
general consumption. The speed penalty for thread-safeness has been
considerably lowered fortunately as the JIT improves.

However, a method that uses nothing but local variables is thread-safe
automatically, and nothing further special need be done.

 

[Roedy Green]

Actually I thought that when the method is static, there could be a
possibility of two threads in the same method. I seems to have forgotten all
about shared and local variable.

A method that does nothing but examine or modify local variables or
primitive parameters is automatically thread safe.

As soon as it goes modifying fields in objects it did not create,
there is potential for trouble.

 

[Oliver Wong]

A method that does nothing but examine or modify local variables or
primitive parameters is automatically thread safe.
Agreed.

As soon as it goes modifying fields in objects it did not create,
there is potential for trouble.

If it modifies "other" objects via their public interface, I don't think
this would add any new thread-unsafeness unless there were already some. The
problem arises when it decides to modify fields outside of their public
interfaces (e.g. its own private fields).

- Oliver

 

[Roedy Green]

If it modifies "other" objects via their public interface, I don't think
this would add any new thread-unsafeness unless there were already some. The
problem arises when it decides to modify fields outside of their public
interfaces (e.g. its own private fields).

Where you go in via a public method won't protect you unless that
method is declared thread safe. For example, you can't do that with
swing methods. So the point is SOMEBODY has to think about thread
safety the minute you have multiple threads and a method starts
messing with the fields in objects it did not create, either directly
or via methods. And in that I include instance fields.

 

[John C. Bollinger]

Let say I have a method in a helper class that is used throughout my java
project. This method changes a string value to empty if it has a null value.

public final String emptyStringIfNull(String a)
{
return a==null?"":a;
}

Would it be better to make this mathod to be static and synchronized?
On one hand, I am worry about the trade off in the slowdown caused by
synchronization..
On the other, I find it a sore to always to instantiate the helper class.

What are your views on it?

Others have covered the synchronization angle quite well. Most have
been satisfied with making the method static, and some have even
encouraged it. In truth, the method in question has so specific an
apparent contract that making it static probably bears almost no risk.
NEVERTHELESS, in my newfound campaign against wanton use of static class
members, I'll point out that there is at least a minor cost to making
the method static: static methods are not polymorphic. If you make the
method static then you give up the possibility of overriding it on some
subclass of your utility class to do something such as count the number
of times it is invoked, log its activity, or some such.

Are you likely to want to do such things? Probably not, in this
particular case. All the same, it should not be taken for granted that
any method that *could* be made static necessarily *should* be made
static. If you have already implemented the method as an instance
method, then I'd leave it that way. Why fix it if it isn't broken? If
you decide to make it static anyway then be sure to change all
invocations to use the static invocation syntax (ClassName.foo());
invoking a static method via a reference-type expression is evil.

 

[Oliver Wong]

If you decide to make it static anyway then be sure to change all
invocations to use the static invocation syntax (ClassName.foo());
invoking a static method via a reference-type expression is evil.

Can you explain why? Eclipse gives me a warning when I do this, so to
satiate it, I use static invocation syntax, but I never understood why it
would be a problem.

- Oliver

 

[John C. Bollinger]

Can you explain why? Eclipse gives me a warning when I do this, so to
satiate it, I use static invocation syntax, but I never understood why it
would be a problem.

Mostly because it is confusing to programmers. Consider:

class Foo {
public static void doSomethingStatic() {
}
}

class FooSub extends Foo {
public static void doSomethingStatic() {
}
}

class Bar {

public Foo getFooOrNull() {
// ...
}

public void myMethod() {
Foo myFoo = null;

myFoo.doSomethingStatic(); // works fine

try {
getFooOrNull().doSomethingStatic();
} catch (NullPointerException npe) {
// Never exercised
}

myFoo = new FooSub();
myFoo.doSomethingStatic(); // invokes Foo.doSomethingStatic()
}

}

====

The meanings of such expressions are well-defined by Java, but they are
not necessarily what a programmer would expect, especially if they are
not knowledgeable about class Foo.