Stack OverflowWhat is the most dangerous feature in Java?
[+7] [21] Mnementh
[2009-07-29 10:51:44]
[ java polls language-features ]

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.

(14) Reduced life expectancy of keyboards due to the verbose class and method names. - Quentin
@David: I lolled. You should have put it as an answer: Since this is a community wiki, you'll take no rep losses from downvotes (or gains from upvotes). - Powerlord
[+32] [2009-07-29 10:55:50] cletus

Threading and concurrency, hands down.

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

(1) Can't upvote enough. - Imagist
(4) 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
[+20] [2009-07-29 10:55:03] Chii

Classloading, while powerful, causes pain all the time.

[+18] [2009-07-29 12:06:40] mkoeller

The assumption: Garbage collection = No memory leaks

(2) 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 ;-). - Oliver Weiler
[+13] [2009-07-29 11:37:17] Andreas_D

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

(6) 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
(2) 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
[+12] [2009-07-29 10:56:08] Gordon Carpenter-Thompson

Java Native Interface


why? i think its better that you can also do somethings faster in c++. - IAdapter
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
[+8] [2009-07-31 18:30:03] instcode

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) {

    abstract protected void initModel(int id);

class AdvancedModel extends BasicModel {
    private int id = 0;

    public AdvancedModel(int id) {

    protected void initModel(int 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!!

That's really a big problem. Should be forbidden, you're right. - Mnementh
[+7] [2009-07-29 10:54:10] shoosh

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

(7) Unless you have a SecurityManager. - Joachim Sauer
[+4] [2009-07-29 11:39:52] Daniel C. Sobral

The idea that has pervaded Enterprise that anyone can code.

That's not really a Java feature, is it? - Joachim Sauer
I don't think that Dr "Bones" McCoy can code ... :-) - Stephen C
(2) Java has helped to bring this mindset to managers. - Mnementh
(2) @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
[+3] [2009-07-29 11:15:31] pjp

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

(3) 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. - Oliver Weiler
[+3] [2009-07-29 11:29:29] Larry Watanabe

RMI (Remote Method Invocation)

naa, maybe "Most useless feature of Java" - shoosh
why? its easy to hack? o_O - IAdapter
[+3] [2009-08-17 06:25:14] Shimi Bandiel

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;

You are so right! Java was way better without them... - Massimiliano Fliri
[+2] [2009-07-29 14:43:53] Vijay Mathew

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


Inner classes (or non-static member classes) maybe not very concise but why are they dangerous? - Oliver Weiler
[+2] [2009-07-30 23:17:03] Matt Beldyk

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

(1) The absence of real destructors and the finalizers that easy to confuse with destructors bring a complex class of problems. - Mnementh
[+1] [2009-07-29 11:22:32] Jeroen van Bergen

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.

[+1] [2009-07-29 12:13:12] Bastien Léonard

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

public static void test(Integer 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.

(2) 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. - IAdapter
[+1] [2009-07-29 14:40:05] lmsasu

Sending parameters only by values.

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. - topchef
Passing parameters only by reference would be far more dangerous, IMO - finalman
[+1] [2009-07-30 23:40:47] JustJeff

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

[0] [2009-07-29 11:59:28] Crystal

Reflection or Serialization.

[0] [2009-07-29 14:24:47] Uri

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.

[0] [2009-08-17 03:22:55] topchef

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.

[0] [2009-09-15 13:30:39] Larry Watanabe

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