Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 7 down vote favorite
2

After reading this post about C#, it is very interesting to hear what you consider wrong with Java and what would you like to change? I bet on "call to super|this must be first statement in constructor".

share|improve this question
5  
Nothing; I use C#. – Job Aug 3 '11 at 18:31
1  
I'd get rid of the entire JCP, revert all language changes since 1.5, and lock the language (syntax, features). No more me2! releases which serve no other purpose than to stroke the vanity of some JCP member who wants to get his name on a JSR. – jwenting Aug 4 '11 at 9:00

closed as not constructive by Mark Trapp Aug 4 '11 at 19:24

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

10 Answers

up vote 7 down vote accepted

This has been discussed quite heavily in the blogsphere recently with the various Java 7/8 feature announcements and the the debate on backwards incompatible Java.

You should pick up Stephen Colebournes's talk at Devoxx (parleys.com)

For me?

  1. I wish Java had been modular from the start (coming in Java 8)
  2. I want to write less boiler plate exception handling (ARM - coming in Java 7)
  3. I want to write less boiler plate bean code (properties) (project Lombok)
  4. I wish they'd done Generics in full (too many corner cases that make your brain melt) - I changed my mind, see comment below
  5. Proper ISO std Date/Time handling (JSR-310 coming in Java 8, Joda time for now)
  6. Simpler concurrency (Fork/Join will help a little in Java 7)

Much of what I want is coming, it's good to see the JDK moving again.

share|improve this answer
1  
For #3 I recently moved ~50 event beans to use Project Lombok. Shaved off a few hundred lines a documentation hell. – TheLQ Nov 25 '10 at 16:51
2  
Good list but where is having functions as first-class objects? :( – NickC Nov 25 '10 at 17:23
2  
@Renesis - Its an opinion piece, I don't need functions as first class objects, for that I use Scala or Clojure :) – Martijn Verburg Nov 25 '10 at 17:31
I changed my mind about reified generics - it'll make language interop on the JVM very difficult, if not impossible – Martijn Verburg Aug 3 '11 at 18:24
+1 never seen lombok before, it seems great so far – NimChimpsky Aug 4 '11 at 14:04
up vote 5 down vote

I second every point of Martijn's answer (especially the full generics support), which leaves less for me:

  • Closures and methods as objects (use them and love them in Groovy and other languages, anonymous inner classes are no substitute)
  • Many of Groovy's convenience methods in JDK classes should be standard in Java too. E.g. I should be able to read or write a file directly (file.get/setText())
  • switch statements will soon support Strings, which is good, but I'd prefer real pattern matching as found in Groovy, Scala, Haskell and many other languages
  • Traits as in Scala (interfaces with actual methods)! You can get them via AspectJ, but I'd like them in plain Java. It's a clean way to implement Multiple Inheritance without running into the diamond problem.
share|improve this answer
1  
I don't like switch/case for strings, I don't know why... Maybe because it brings the tendency to write slow code... – duros Nov 25 '10 at 17:08
up vote 5 down vote

There are so many things fundamentally wrong with Java, and the language has moved so slowly, that I think it may be too late to fix. People who care have already moved to newer languages like Groovy, Clojure, and Scala. The most important thing to do now is to improve the JVM to support these languages as efficiently as possible.

Here's my list of fundamental Java deficiencies:

  • Primitive types. They never should have been in the language. The need to convert between arrays and lists is just silly.
  • Get/set methods. As soon as someone conceived of JavaBeans, properties should have been added to the language.
  • No meta-programming, and closed classes. Instead we have complex frameworks and millions of lines of XML configuration files.
  • No functional programming. With garbage collection already in place, why would anyone NOT support closures?
  • No support for automatic freeing of resources. Instead we have ugly and error-prone try-finally sequences. Fixed in C# ten years ago. Finally fixed in Java 7.
  • The reflection API.
  • No support for operator overloading, making it impossible to do mathematical programming in a reasonable way.
  • No list or map literals. The pain never ends.
  • Date and Calendar. Unix got this mostly right in 1970 with struct tm and time_t, and it's still wrong in Java in 2011. Every Java application ends up with a DateUtil class to do all the stuff that should be trivially easy but isn't.
  • JDBC. Unwieldy, and the date handling is completely wrong. The only thing that java.util.Date has in common with an ANSI-SQL DATE is the name.
  • Cloneable.
  • Checked exceptions. Maybe good in theory, but the average Java programmer seems to just add exception classes to the throws clause until it compiles.
  • Collections. Inconsistent, inconvenient, and incomplete. The C++ STL is older and better.
share|improve this answer
2  
Operator overloading is just a syntax shortcut for a function call. Its the easiest way to make a program unreadable. – James Anderson Aug 4 '11 at 9:32
The point of GC isn't to allow closures (it's to make memory management less buggy in general); it's just that without GC, closures are really painful. – Donal Fellows Aug 4 '11 at 9:43
@James: Operator overloading could be OK, but only if you could only overload in a mathematically-sensible way (e.g., by defining operations to allow a class to be a Field). The problem is, people don't do that in practice… – Donal Fellows Aug 4 '11 at 9:50
3  
@James: Do you think calculus is unreadable? We invented operators to make it easier to read mathematical formulas. I don't care if someone else uses operators in a strange way. That's their problem. I don't want to be stuck with w = x.plus(y.plus(z.times(a)).times(b)) instead of w = x + b * (y + a*z). – kevin cline Aug 4 '11 at 14:50
3  
"Operator overloading is just a syntax shortcut for a function call. Its the easiest way to make a program unreadable.". Sure. The easiest way to make a program unreadable is having methods that have absolutely nothing to do with what they actually do. Should we prevent the programmers from choosing method names, then? – devoured elysium Aug 4 '11 at 15:13
up vote 3 down vote

Embrace Lisp.

In the same way that Java contains a Javascript engine as part of the standard runtime, which is scriptable with JSR-233, it would be really nice to have a well-integrated Lisp engine in the JRE.

share|improve this answer
1  
Clojure is not an option? – duros Nov 25 '10 at 17:38
@duros, could be. I would like it to be embraced in the standard runtime. – user1249 Nov 25 '10 at 17:48
1  
@Thorbjoern the JRE is already large, there's no need to make it even bigger, specially that it's not absolutely necessary to do so. – Mahmoud Hossam Aug 3 '11 at 19:35
@Mahmoud, does the question mention any restrictions? – user1249 Aug 3 '11 at 20:07
1  
@Thorbjoern No, I'm just saying that I don't think that's a good idea, that's all. – Mahmoud Hossam Aug 3 '11 at 22:23
up vote 2 down vote

I would make Groovy as fast as Java. Groovy has implemented evrything I wanted I'm Java.

share|improve this answer
ivokedymanic is coming in JDK 7 - you'l get your boost then – Martijn Verburg Nov 25 '10 at 16:53
up vote 1 down vote

Java should really have Software Transactional Memory, because it greatly simplifies concurrency issues.

After that, it would be really nice to have functional lambdas.

share|improve this answer
up vote 1 down vote

Java over the years has become a monster of "features" added "because XXX" has it. Generics, built-in web servers, automatic type conversions, and now people want function pointers as well. It used to be a great platform to work on, but ever more it feels like I'm programming using some sort of Frankenstein monster JCRuby#++ rather than Java. Revert all that rubbish and return the language to what it was designed to be.

share|improve this answer
I wonder how can anyone be against the introduction of type generics in a language and automatic type conversion.. – devoured elysium Aug 4 '11 at 15:15
+1 for "JCRuby#++" – user24770 Aug 4 '11 at 15:18
@de: I'm not necessarilly opposed to such thing, but the reason they were introduced and the way (at least in part) they were implemented. E.g. automatic type conversion in Java can now lead to nasty runtime errors where prior you'd get a compiler error for the same code, that's a potential for bugs in a language designed to prevent such things. Generics are very nice, but at times "feel" unfinished, bolted on as an afterthought (which of course they are). I use them extensively, but do run into limitations at weird places where things just don't work as you'd expect them to because of that. – jwenting Aug 9 '11 at 5:37
up vote 0 down vote

For me, it is JVM speed. Now many here will come and say that "Java is slow" is a myth from the old days. Some may pull out benchmarks, that refute any claims about Java being slow.

As a developer I am also a user. The tools I use are running on the CLR, the JVM, the AVM2, the V8 or are natively compiled. Of all those tools the ones in Java are the ones that let me wait. The best example is, I have 2 compilers for the same platform, one of which is written in Java and will take longer for an incremental build, than the one written in OCaml will use for a complete build (and compiling here is just parsing, type checking and issuing some opcodes, which are really almost just a representation of the AST).

I have very few apps or tools that require much time to launch or tend to become unresponsive. Those that do, are written in Java. Possibly because the JVM spends so much time booting and JITing (?).

I think, this is really a pitty, because the JVM has quite a high market penetration and the Java ecosystem is immense, with a lot of tools and languages. But I really just use it, when I have no other choice, which is why I don't consider Java as a preferable platform until I eventually get the UX I want to give my users.

share|improve this answer
I think you'll find that the JVM is getting ton of performance work put into it for JDK7 and 8 with bits of JRockit merging into Hotspot amongst otehr imrpovements. JDK8 will modularise Java which means no more bloated bootstrapping – Martijn Verburg Nov 25 '10 at 16:55
@Martijn Verburg: I am happy to hear and very eager to actually experience it ;) – back2dos Nov 25 '10 at 17:20
JVM speed is fine, period. Never had a problem with it when running well written code, and you can get poorly performing code in any environment. – jwenting Aug 4 '11 at 9:01
@jwenting: I said for me it is too slow. Who are you to tell me it isn't? I'm happy for you, you never have problems with it. For me it is quite the opposite. I wish for it to become significantly faster. – back2dos Aug 4 '11 at 11:11
Tbh, my .net apps are reaaally slower than their java counterparts. Debugging is dead slow for .net code on my machine and is instant with Java. The same is true when running testing suites. – devoured elysium Aug 4 '11 at 15:17
show 4 more comments
up vote 0 down vote

In addition to what everyone has mentioned, can we have smaller function names?

for a simple output statement, its not fun to write system.out.println("Hello World")

Relatively the code needed for learning Java is much more then that needed for C (hello world, and even other academic programs are much smaller in C than Java)

share|improve this answer
Does import static not help? – Donal Fellows Aug 4 '11 at 10:03
having a verbose language makes code easier to read, thus easier to maintain... – jwenting Aug 9 '11 at 5:38
@jwenting: Say what? That's just ridiculous. Having an expressive language is what makes code easy to read. By your logic, a piece of code would be easier to read, if I prefixed every statement with yetAnotherPointlessKeyword. – back2dos Aug 9 '11 at 13:13
much easier to read "if x do y else do z" than it is to read "x->y!z" (just to invent a convoluted syntax). – jwenting Aug 10 '11 at 6:37
x->y!z seems like a nice short syntax.. – Akash Sep 6 '11 at 19:13
up vote -1 down vote

If I had a change, I want these 4 properties in JAVA

Value types

Partial classes

Operator overloading

Variable type inference

share|improve this answer
-1 and no comment? Someone having a bad day! – Soner Gönül Aug 4 '11 at 9:25
1  
Not that I'm the downvoter, but perhaps you could say why you want those things? – Donal Fellows Aug 4 '11 at 9:40
that's one reason. Another is that all those things are explicitly ruled out by the original language design, and quite deliberately so, a decision that's widely carried in the community. – jwenting Aug 9 '11 at 5:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.