views:

1021

answers:

21

Which feature of the Java-language is the source of the most misunderstandings and bugs in your experience? The scope of this question is about the language, not the class-library.

+5  A: 

Reflection?
Allows you to do pretty much anything and break all rules.

shoosh
Unless you have a SecurityManager.
Joachim Sauer
+19  A: 

Classloading, while powerful, causes pain all the time.

Chii
+30  A: 

Threading and concurrency, hands down.

This isn't just Java-specific though. Multithreading is by nature difficult.

cletus
Can't upvote enough.
Imagist
also worth noting that as of Java5, java.util.concurrent offers MANY advanced primitives to help make threads/concurrency both easier and safer to use.
basszero
+12  A: 

Java Native Interface

shudder

Gordon Carpenter-Thompson
why? i think its better that you can also do somethings faster in c++.
01
yes, it's great for that but it's also dangerous as YOU are responsible for managing the memory. A company I worked out exposed their complicated C library using JNI and just fresh out of university I was given the responsibility to make it work. Object A kept pointers to Object B and C and D (and vice-versa) and each was stupidly exposed as a separate java object. Object A was occasionally cleaned up by the garbage collector and objects B, C and D were left around with an invalid dangling pointer. User accessed object B... BOOOM! :-D
Gordon Carpenter-Thompson
now add threads and signals into JNI and you're REALLY screwed
basszero
+3  A: 

The switch statement and lazy people who forget breaks...

pjp
I just don't use switch statements
Tim Büthe
I don't blame you: `if-else` is *so* much more readable
oxbow_lakes
In C# they removed the fall through behaviour... In Java I like to comment where I want to fall through.
pjp
The dangerous thing is that one would think that the normal behaviour would be to NOT fall through.
Helper Method
+1  A: 

As a source of bugs: concurrency. Since 1.5 life for the programmer is a lot easier thanks to java.util.concurrent though.

For misunderstanding: writing a good hashCode() method, serialization and class versions.

Jeroen van Bergen
+2  A: 

RMI (Remote Method Invocation)

Larry Watanabe
naa, maybe "Most useless feature of Java"
shoosh
why? its easy to hack? o_O
01
+11  A: 

Misunderstandings and source for bugs? Here:

((aString == anotherString) && (aString.equals(anotherString)) 
                              // can be true or false - you never know

and another classic one:

aString.equals("I love NPE"); // **Boom** if aString == null
Andreas_D
I like to swap the stings like this: "I love NPE".equals(aString); or use commons lang ObjectUtils.equals(aString, "I love NPE"); for that
Tim Büthe
Sure, that's how it has to be done - but I'm surprised how many programmers don't know it or forget about it :-))
Andreas_D
this should be the #1 answer, so frustrating when switching from C# to Java
Allen
I've never heard of such an approach. I learned something new today!
Dopyiii
+4  A: 

The idea that has pervaded Enterprise that anyone can code.

Daniel
That's not really a Java feature, is it?
Joachim Sauer
I don't think that Dr "Bones" McCoy can code ... :-)
Stephen C
Java has helped to bring this mindset to managers.
Mnementh
@Stephen C, no. He can't. He's a doctor, not a software engineer.
Thomas Owens
Hang on a minute. I'm a doctor AND a software engineer. :-)
Stephen C
A: 

Reflection or Serialization.

+17  A: 

The assumption: Garbage collection = No memory leaks

mkoeller
Reading this as I try to find a memory leak in my own code :(
RHSeeger
But it does prevent memory leaks! All that data that filled up your computer's RAM and swap partition is, technically, still accessible... ;)
Jeremy Friesner
@Jeremy Technically yes, but practically, maybe not ;-).
Helper Method
+1  A: 

The fact that Integer, Boolean and so on are immutable. With Autoboxing it can get especially weird:

public static void test(Integer i)
{
    ++i;
}

This method actually does nothing, except creating a new Integer and assigning it to i. It doesn't modify the object pointed to by i.

Bastien Léonard
In which widly used language do you see mutable basic types ?
e-satis
@e-satis: C and C++, for example. But I'm not saying it's a bad thing. In Java it's particularly misleading though, because most of the time we use `int` instead of `Integer`. (There isn't this problem in Python, for example). And autoboxing makes `Integer` look like `int`, which is even more confusing IMO.
Bastien Léonard
i could also do i=null in that method, i dont see any problem here. I could write code that wont compile too.
01
A: 

The take-first-found approach to class search is also risky. It's not frequently a problem, but when it is, it's a bi*tch to debug.

I'm talking about how classes are searched in the specified classpath; too easy to end up with conflicting versions when using different libraries that are out of synch and include (and export) too many common classes.

Uri
+1  A: 

Sending parameters only by values.

lmsasu
Why is that dangerous?
Michael Myers
Mainly because beginner programmers are not fully conscious about this. It is rather a missunderstanding of the intimate mechanisms, rather of the language.
lmsasu
I personally would think it's more dangerous, if parameters are passed by variable. Methods would have side-effects. Very confusing.
Mnementh
It's dangerous because it's not obvious and often forgotten.
grigory
Passing parameters only by reference would be far more dangerous, IMO
finalman
+2  A: 

The implementation of inner classes seems to be a good candidate. This article has a detailed discussion.

Vijay Mathew
Inner classes (or non-static member classes) maybe not very concise but why are they dangerous?
Helper Method
+2  A: 

The belief that finalize() will be executed in a timely manner is a great way to run out of resources other than just memory.

Matt Beldyk
The absence of real destructors and the finalizers that easy to confuse with destructors bring a complex class of problems.
Mnementh
+1  A: 

Synchronization. Too often 'synchronized' is stuck on a method in an attempt to make a critical section.

JustJeff
+7  A: 

Allow for invoking non-final methods in constructor is a big pitfall!

I wrote a similar code 4 years ago:

abstract class BasicModel {
    public BasicModel(int id) {
        initModel(id);
    }

    abstract protected void initModel(int id);
}

class AdvancedModel extends BasicModel {
    private int id = 0;

    public AdvancedModel(int id) {
        super(id);
    }

    protected void initModel(int id) {
        this.id = id;
    }

    public int getId() {
        return id;
    }

    public static void main(String[] args) {
        AdvancedModel model = new AdvancedModel(10);
        System.out.println("id = " + model.getId());
    }
}

Gotcha, it printed "id = 0" to the standard output!!

instcode
That's really a big problem. Should be forbidden, you're right.
Mnementh
A: 

The fact that object variables are actually object references (and only references) is so fundamental and pervasive in Java that it should be at the top of this list.

The corollary: since everything in Java is passed by value objects are never passed at all. This fact alone makes Java very dangerous when forgotten.

grigory
+3  A: 

Autoboxing and Unboxing.
Makes for the following code to be legal (resulting in poor performance):

Long result = 0L;
for(Integer i = 0; i < 100000; i++)
{
  result = i * i + result /2;
}
Shimi Bandiel
You are so right! Java was way better without them...
Massimiliano Fliri
A: 

JRE - if Java were never run, it wouldn't be dangerous.

Larry Watanabe