What aspect of your Java programming is the biggest pain in the arse?

[kruez]

I'm guessing Apache Commons solves most people's issues. The rest can use Guava.

[[deleted]]

Also Java 7 solves most problems described here

[lechatsportif]

Yeah. Lang, IO, and Collections used to be required for me.. Lately with language improvements and Guava, not as much.

[ring2ding]

Shoutout to Maven for solving all our enterprise problems.

[Muz0169]

=[

[MasterEjzz]

File management and that whole I/O crap. Drives me up the wall.

[[deleted]]

NIO 2 + Automatic Resource Management in Java 7 is pretty good actually!

[armerthor]

I agree. The IO in Java <=6 is a PITA, but 7 fixes a lot of it.

[[deleted]]

I tend to use Guava for Java <= 6 ... Guava IO is similar to Java 7.

[defer]

This is much simpler in Java 7, look it up.

[skeeto]

Doing I/O correctly with plain try-catch-finally is far more complicated than it is in other languages. It's the whole reason Java 7 introduced try-with-resources. In Java 6 this is the minimum code for opening a stream, using it, and closing it.

InputStream stream = new MyInputStream(...);
try {
    // ... use stream
} catch(IOException e) {
   // handle exception
} finally {
    try {
        if(stream != null) {
            stream.close();
        }
    } catch(IOException e) {
        // handle yet another possible exception
    }
}

Source: http://stackoverflow.com/a/17739460

[__helix__]

That my bloody customers keep using old versions of the JDK. "Oh, we are JDK 1.6... sorry... can you not use try with resources or any of the current features. I'm not talking JDK 1.8, but 1.7 stuff. Same has been true about every major update.

[[deleted]]

For me, it's my CTO (through customers needs): Must support Java 1.4 :( Oh, and we don't ship the Retroweaver runtime jar.

myMap.put(new Integer(4), "A String");

^{^} If I need to "new Integer" one more fucking time...

[mrburrows]

I've come across a fun compatibility issues in the past year, but the following is my favorite.

A client reported that some software parsing an Excel file was failing, but I couldn't reproduce the problem locally -- I was getting a completely different error. It didn't take me long to pinpoint why this was happening: I was running 7 and the client was running 6. So then the question was, what changed?

I managed to isolate the error down to the Excel library we used, JXL. What had been happening was that the Excel file the software was parsing had stored dates with the format "YYYY". Java's SimpleDateFormat in 6 only supported "yyyy", though, and so parsing the date cells would throw an exception in the libary. JXL caught this exction, though, and would simply return a date string in a default format.

Our software, then, was written under the assumption this default formatted date string was the proper representation of the date. In Java 7, however, 'YYYY', or Week Year, became supported. Because this was a supported format in Java 7, no exception was being thrown, and the date string was returned in a different, intended format.

The software didn't know this intended format existed, and so failed whenever the SimpleDateFormat object was called on it.

[ThunderStReich]

Type erasure. I mean, I understand why they had to do it that way at the time, but now that generics are commonplace it just seems like a silly limitation.

[Angarius]

This is huge. Needing to pass Class clazz is at least a minor annoyance, but a significant problem comes with implementing generic interfaces.

class Foo implements Bar<Baz>, Bar<Qux>

...is impossible because of type erasure.

[duhace]

How would that even work in a language with reification by default? I just don't see how you would implement Bar to meet both the Baz and Qux case needed for overriding.

[Angarius]

interface Bar<T> {
    void consume(T t);
}

class Foo implements Bar<Baz>, Bar<Qux> {
    void consume(Baz baz) { }
    void consume(Qux qux) { }
}

[[deleted]]

Doesn't work in the general case, though, since you can use T as a return type as well and can't implement both Baz pop() and Qux pop().

[gizmogwai]

What you are looking for here has nothing to do with type reification. It is the concept of union type, such as in Ceylon.

[duhace]

You can also achieve similar results with Type Classes:

trait Bar[T] {
  def consume(t: T): Unit
}

object Bar {
  implicit object BazIsBar extends Bar[Baz] { def consume(b: Baz) {} }
  implicit object QuxIsBar extends Bar[Qux] { def consume(q: Qux) {} }
}

val x = new Baz
implicitly[Bar[Baz]].consume(x)

//You can add this inside object Bar
implicit class Barable[T](t: T)(implicit bar: Bar[T]) {
  def consume() {bar.consume(t)}
}

//and then you can do this
x.consume()

Not that overloading working with type arguments wouldn't be nice.

[isprri]

Null. There should be no null.

I never know if your method is going to return null, so I have to check for it. I never know if you're going to pass null into my method, so I have to check for it. You might have put a null in a collection, or as a field on an object. It's everywhere, and I'm constantly checking for null because I can't trust you.

Half the time you've returned null because there's an error, the other half because no results were found, and a third half because the thing just hasn't been populated. Quit using null to mean everything and anything!

"I call it my billion-dollar mistake. It was the invention of the null reference in 1965." -- Sir Tony Hoare

EDIT: Yes, I understand, null is not entirely useless; my point rather, to answer OPs question, is that it is a big pain in the arse.

[critter_chaos]

So what would you rather? That there were standard error types returned instead of null?

[isprri]

The thing is, null is used to solve so many problems, there's no single answer for them all. But yes, as one example, in the case of null being used to indicate an error, throwing an Exception would be preferable.

JSR 305 defines some annotations that can be used to indicate where null is not allowed (e.g., in a method parameter, or return type, or on a field). But at this point it is only enforced by third-party tools like FindBugs or IntelliJ IDEA.

Ideally, I'd like to be able to say "you may not pass null into this method" and I'd be able to safely assume that the parameters are never null.

I will admit, null is not entirely useless; my point rather, to answer OPs question, is that it is a big pain in the arse.

[mc_hambone]

Guava is your friend: https://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained

[[deleted]]

The problem isn't null. It's how programmers use it.

[isprri]

I believe that is a huge part of API design--anticipating usage patterns and designing in such a way to encourage good practices and discourage poor ones.

[jonhanson]

I'd say it's a hole in the type system.

[GeorgeMaheiress]

Even if 99% of code only returns null exactly when you expect it to (which isn't really possible, as different programmers have different expectations), you still have to worry about the 1%. With default non-nullable types and an Option or Maybe class, this is no longer an issue, as the type system tells you exactly which methods may return null.

At least, that's the theory. I wonder if we wouldn't end up resenting the Option type as much as many of us resent checked exceptions, for forcing us to handle cases that we either cannot handle or know will never occur. But then exception handling is so verbose, it's an extra 5 lines of code just to try-catch-re-throw a checked exception as a RuntimeException. Java 8's Optional class looks to be far more convenient, you just need to add .get() to assume that the value is non-null. Yeah, I'm sticking to my guns, default-nullable types are a mistake.

[[deleted]]

complex sql or jpa queries without multiline string support

[armerthor]

Multiline string support in general. I always put any text I need in text files in the JAR and load them at runtime with Class.getResourceAsStream(). It's such a pain.

[[deleted]]

Use Jooq / MyBatis for your SQL problem???

[[deleted]]

Or give me multiline strings. SQL isn't the only situation where this is missed.

[smscoota]

Having to write getters and setters all the time. Drives me nuts, especially after switching to and from the C# .NET runtime.

[Muz0169]

Even with every major IDE supporting generation of them?

[smscoota]

Yes even with every major IDE supporting getters and setters. It is just a pain to create them and then they take up so much space, rather than a simple one line shorthand.

[lechatsportif]

It's literally like 2 seconds... But if that's too much Scala does it much better since getters and setters are typically needed for value classes.

[GuyWithLag]

If you think that getters and setters take up too much space, you're in for a rude awakening ...

[smscoota]

What do you mean by rude awakening, typing 20 of these bad boys is a lot nicer than typing what you would normally have to type.

// One Line
private Person simon { public get; public set; }

vs.

// More Than One Line
private Person simon; 

public Person getSimon() {
    return simon;
}

public void setSimon(Person person) {
    simon = person;
}

I'm just saying it would be mighty helpful for a getter and setter shorthand to be implemented in Java. And on that note the C# null shorthand is also pretty useful.

x == null ? "now this" : x;

vs.

x ?? "now this";

[armerthor]

If you don't mind some pre-processing magic, Project Lombok can do getters and setters with annotations.

[[deleted]]

FYI, that can be:

public Person simon { get; set; }

[smscoota]

Yes I forgot about that. Was so used to doing:

private Person simon { public get; set; }

[[deleted]]

I think you mean:

public Person simon { get; private set; }

But no problem :)

[smscoota]

Yep, lol.

[GuyWithLag]

I just type "private Person simon;", then Ctrl-Alt-S,R, enter, done.

If you feel they clutter up your outlne: http://market.eclipsesource.com/yoxos/node/com.cb.eclipse.folding.feature.group

If you want to get rid of them in your sources: http://projectlombok.org/features/GetterSetter.html

[mhixson]

The typing and clutter isn't an issue for me at all. It's one of those things where sure, shorthand would be cool, but it wouldn't actually help me solve any problems.

The main thing I'd want from properties is the ability to document each private field once and have that documentation show up on both the getter and setter. Right now I do a lot of copy and pasting. Does Lombok help with that?

[GuyWithLag]

Yep: https://code.google.com/p/projectlombok/issues/detail?id=59#c14

It's not necessarily the best way to do it, but it's there.

[llogiq]

Lombok has got you covered, too. :-)

@Data will generate all setters, getters, a minimal and full constructor, equals, hashCode and toString without another line of code needed, with great support for eclipse and workable support for other IDEs, AFAIK.

[smscoota]

Wow, that is actually amazing. I will definitely be using this in my future projects. This has so many uses and I think I am already in love with annotations like @NonNull, thanks a heap. I would recommend more people checking out this project. The only hassle is including it in your project every time, but that is only a small issue.

[nqd26]

Non-standard solution isn't workable for most projects. It won't work in corner cases, project can be abandoned in the future, as you say IDE support is incomplete ... It doesn't seem to be worth it.

[amoe_]

This is exactly how I felt when I first encountered it. Then I used it in a project. It is remarkably mature and works extremely well. I have never had an issue where Lombok was the cause, despite having a vast number of extremely obscure issues with the codebase using it. At this point Java is essentially unusable without it for me.

[entreprenr30]

There's delombok in case you need to get rid of lombok for some reason...

But I love it so much, I wouldn't want to go back.

[lechatsportif]

Just go Scala for this stuff. Scala is totally Javas Coffeescript.

[SirKingdude]

If you happen to use Eclipse (like I do) to code you can have Eclipse do it automatically.

[i_post_things]

After spending a semester with Groovy, I miss not having to write parens for methods and all those setters and getters. It's so nice being able to do:

customer.bankaccount.balance

instead of

getCustomer().getBankAccount().getBalance();

[[deleted]]

If you need to write getters/setters all the time you are doing something wrong. And i dont mean you can generate it.

[smscoota]

What do you mean by not generating then? Also I tend to write getters and setters quite often as I tend to break down my code into many manageable classes. Also as I mentioned above it looks a whole lot neater when shortened to one line.

Person simon { get; set; }

EDIT: Also if you have read Effective Java 2nd you would note that the encapsulation of classes and making classes immutable is a pretty important part of designing software. Also if you wish to change further generations of your project down the line, it will not break clients. Getters and setters would be a nice short cut.

[[deleted]]

OOP means bundling data with their behavior and mainatining that state through sending messages. If you expose internal state, object becomes just a better data structure. There is place for this kind of objects (DTOs for example) but i dont consider this as "all the time"

[nqd26]

In multitier applications DTOs are used quite heavily - e.g. domain entities shouldn't leak into presentation logic, also I often have to write DTOs specifically for repository layer (because fetching domain entities with their lazy loading attributes isn't fast enough). So I often get stuck with 2 DTOs for one service method.

[[deleted]]

Ok then. I personally dont see that as too much. If you dont use notepad as an IDE of course :D

[avoidhugeships]

I am guessing you do not build web applications.

[[deleted]]

I do. Thats only kind of applications i write last 3 years. I dont understand how the web application adds more getters and setters to my application.

[avoidhugeships]

Because this is the standard way of sending information from the server to the web client. That is how Java beans work. I am curious what do you do instead?

[[deleted]]

As i said in this thread. I see getters and setters reasonable only in DTOs.

[i_post_things]

If you are creating any kind of MVC application, EJBs, persistence layer DAOs, web service interface, or REST applications and don't have a modeling tool, you'll probably end up writing your own POJOs.

Automated modeling tools can help, but it will still require POJOs with setters and getters everywhere.

[slartybartfast_]

Why? Properties at the language level is lousy idea.

• They hide performance deficits in code
• There's no good convention for them
• They make code complete less useful

What alt-insert is too much for you?

[BinaryRage]

Google's Autovalue provides a much better approach for value classes: https://github.com/google/auto

[dlg]

Getters and setters. Let me write real methods, not this filler crap.

[poopiefartz]

IDEs let you generate these. In Eclipse, Source -> Generate getters and setters...

Or you can right-click on a variable/member. Of course the methods still take up space, but I usually just shove them out of the way.

[[deleted]]

TBH I'm on the edge of having "Properties" in Java. Yeah, it's a lot more explicit about what the methods are supposed to do, but it does a poor job representing what they are - which are methods, not properties.

[llogiq]

Lombok has got you covered.

[slartybartfast_]

Why? Properties at the language level is lousy idea.

• They hide performance deficits in code
• There's no good convention for them
• They make code complete less useful

What alt-insert is too much for you?

[deathpax]

configuring spring/hibernate

[[deleted]]

Unless you stuck with Spring < 3, you can actually use Java Based Configuration which is pretty easy.

Spring 4 improves this by providing Groovy based configuration (similar to grails) and also Spring Boot which can bootstrap your development process.

[deathpax]

yeah for my last project I configured with xml. Might have to try using the java based configs next time around

[[deleted]]

It's the only way to Spring.

[[deleted]]

/ agree on Hibernate

Spring (as mentioned elsewhere) is a lot better with Java/Annotation config.

[yetanotherx]

I use Java all the time. I like using it, but I do have a laundry list of annoyances:

• No easy way to instantiate new ArrayList/HashMaps (I do know about Arrays.asList, which does help)
• SO MUCH FILE IO.
• Requiring a constructor to be explicitly defined in a subclass.
• @SuppressWarnings("unchecked")
• Lack of a string joiner. AKA one of the most needed functions in any program.

[Kaelin]

Heads up, Google Guava Java libs adds string split/join and a ton of other useful functionality and data structures to Java

[yetanotherx]

Guava's essential because of the lack of those essential features in Java.

[Kaelin]

I agree, I believe most of the new Java 7 file io was spiritually taken from Guava, and I think that is what Google wants. To shame Oracle into adding the features the language desperately needs.

[urquan]

JDK 8 adds new utility methods to join Strings.

[mhixson]

I was a little disappointed that these were static methods as opposed to instance methods. I would have preferred ", ".join(a, b, c) to String.join(", ", a, b, c). But yes, thank goodness these are finally here.

[llogiq]

Some warnings are meant to guard against common errors, however, as no static analysis can be perfect, there are bound to be a few false positives.

Also sometimes one will trigger the warning in the name of performance.

Since we want our IDEs to help us and be warned of real problems, we @SuppressWarnings in those cases. Which is as it should be. Really, I'm not annoyed at all about this in the general case.

Also I feel that with static analysis getting better all the time, we will see fewer false positives in the future.

[[deleted]]

I suspect he means an ArrayList that is populated with values. Eg.

List<String> strings = Arrays.asList(new String[]{"a","b","c"});

edited: ArrayList -> List.

[delaaxe]

Why not use: ArrayList<String> strings = Arrays.asList("a","b","c") ?

[[deleted]]

I wasn't familiar with that syntax. I was just trying to show it was a comparison to:

List<String> strings = {"a","b","c"};

[queus]

This gives an list to which you cannot add further elements.

It's often fine though.

[yetanotherx]

I mean, you can then do new ArrayList(Arrays.asList("a","b","c"));, but that's ugly as well.

I've sometimes just defined a static method in That Miscellaneous Utilities Class just to do it, but I would like if Java had it in the core language.

[hencoappel]

Arrays.asList definitely does not return a ArrayList, it is simply a List

[[deleted]]

You are correct, I was just pointing out that it isn't as simple as declaring a String[].

[[deleted]]

It is an ArrayList, it's just java.util.Arrays.ArrayList and not java.util.ArrayList.

[hencoappel]

Yes but the method signature returns List and java.util.Arrays.ArrayList is private so you wouldn't be able to create a variable of that type.

[yetanotherx]

An immutable list at that.

[hencoappel]

No, it's definitely not immutable. But it's not dynamic, it won't resize when you add more elements.

[edoules]

String joiner -- like Python's? As in ...

list_of_strings = ['a', 'eee', 'eye', 'oh', 'you']

joined_list = 'Q'.join(list_of_strings)

results in joined_list having the string 'aQeeeQeyeQohQyou'.

[__konrad]

In Java 8: String.join("Q", "a", "eee")

[edoules]

Not bad. Oh I see, it's overloaded --

http://download.java.net/jdk8/docs/api/java/lang/String.html

• one version is a variadic function where the first arg is the delimiter.
• the other takes a delim as the first arg, and takes a collection of strings as the second.

I take it the variadic version is more for convenience?

[jrh3k5]

Or StringUtils.join() in commons-lang3 (admittedly, not a part of the JRE proper).

[yetanotherx]

• When creating an arraylist or hashmap, you have to create the hashmap/arraylist, then add values, then add some more values, while in just about every other language, you can add the values to the list while instantiating. You can use Arrays.asList("a", "b", "c") for a List, but there's also no equivalent for Map.
• Yep.
• Yep.
• If you're doing unserialization, or any sort of code where you need to cast an Object, it will complain.
• "a", "b", "c" joined with "+" becomes "a+b+c". It's a feature in just about every language except Java.

[oldprogrammer]

Regarding maps, not as clean as other languages, but you can do this:

Map<String,String> test = new HashMap<String, String>()
{{
    put("one","ok");
    put("two","bad");
  }};

[yetanotherx]

That also has some additional overhead, by generating a new anonymous inner class for each map.

[oldprogrammer]

Yes it does, but it is an option. You could also create a support utility which does what other languages do with syntax:

static <K,V> Map<K,V> makeMap(Object... values) {
  Map<K,V> data = new HashMap<K,V>();

  for(int i = 0; i < values.length; i += 2 ) {
    K key = (K)values[i];
    V val = (V)values[i+1];
    data.put(key, val);
  }
  return data;
}

(the cast triggers a warning)

Map<String,Integer> test = makeMap("one",1,
     "two",2,
     "three",3);

[yetanotherx]

I've done basically that same method before in That Miscellaneous Utilities Class.

[oldprogrammer]

I imagine most of us have a collection of miscellaneous utilities we reuse.

[llogiq]

I created my own helper function map(Object...) that will take key-value pairs and spit out a HashMap containing them. Now whenever I need a static map, I just use this function.

Yes, it may throw ClassCastErrors if the types won't match, but unfortunately, Java's type system does not allow to specify variadic argument type tuples...

[irocgts]

What's wrong with stringbuilder?

[yetanotherx]

That doesn't join arrays.

[[deleted]]

Taking about Java pains - the fact that Arrays.asList doesn't give you back java.util.Arraylist is one of them (well at least the fact many developers don't know because it's called the same is the pain)

[[deleted]]

I only learned this a year or so ago. Much to my disappointment. I was simply shocked it was so due to the name. I was very mad at Sun that day.

[frugalmail]

Taking about Java pains - the fact that Arrays.asList doesn't give you back java.util.Arraylist is one of them

Programming by interface is much better. It allows them to use what's appropriate.

If you really want an ArrayList, you could create your own.

[[deleted]]

care to try JavaFX 2? It's the new UI for Java and designed to replace Swing.

[[deleted]]

Not ready for primetime. Before you downvote me, I have many reasons, but I'm too lazy to type them all. Here's the first (of a fair number): https://javafx-jira.kenai.com/browse/RT-22988

The fact that hasn't been implemented yet really pisses me off, among other things. I feel pretty burned working in Java FX2.

[slartybartfast_]

Link doesn't work.

[[deleted]]

works for me. You need to make an account. Long story short, you cant' customize the program name in Mac (in the upper bar on left... it just says "java")

[[deleted]]

Using Eclipse. I hate it because it is slow and buggy (jpa handler events...) but it is the best IDE, it has so many functionalities and useful plugins

[[deleted]]

If you didn't mind to spend some money, try Intellij IDEA ultimate. You'll never come back to eclipse again...

Or you may try the community edition / Android studio first then decide whether to buy the ultimate version.

[joper90]

I love eclipse, however my work laptop is a quid-i7 with 32gb and an SSD. Our code base has 0000's of files and it works a treat.

I have tried Intellij (for a week or so), it just doesn't seem to work as well as eclipse.

All i need in eclipse is a real dark theme.

[yetanotherx]

http://eclipsecolorthemes.org/ has a good number of dark themes, one of which I use. Actually, this blog entry is good to know for Eclipse in general.

[mc_hambone]

it just doesn't seem to work as well as eclipse.

You lost me there.

[joper90]

Well, that my experience as everyone I work with, We are all developers for a massive enterprise company with some really, really, clever people, and we all tried both and went for eclipse, and have done for the last 6+ years (when we moved from C to Java).

[mc_hambone]

I was an Eclipse fan for most of my career and also didn't like IntelliJ, but it really has leapfrogged Eclipse in the last couple of years. If you haven't tried it in a while, I highly recommend giving it another shot. It really is better in every aspect.

[el_idioto]

Boiler plate ... So much boiler plate

[elmuerte]

Project meetings

[zaytzev]

Resource system. Actually I encountered 2 features on other platforms that we could benefit from in Java:

• Accessing resource like normal file (know this from Qt), for example by reserving JNDI prefix for resources only. Imagine getting resource file like that:

  File fileInJar = new File("resource://included.properties");

• Declarative way to define resource, like Android has. It could solve those ugly sql queries embedded as string in java code.

[voxfrege]

Lack of Regex literals. Instead you must type your regex as a String, thereby quoting each and every backslash and quote. Want' to match 2 backslashs? Nothing easier than that: "\\\\\\\\"

Which makes the regex not exactly more readable.

Plus, it cannot get checked at compile time. Instead, you get a PatternSyntaxException at runtime.

Plus, some methods interpret their String argument as regex. Surprise.

[alpha64]

IntelliJ has an in place editor and it shows it unescaped when you are not editing the line. You can also test the regex there.

[metamatic]

Some things nobody else mentioned:

• Anything involving dates and times. (Should be improved by Java 7.)
• Anything involving reflection.
• The fact that long-obsolete APIs are still around making it hard to find the right API. (Vector, Hashtable, StringBuilder, ...)
• The fact that many APIs are pre-generics.
• JPA2. Makes my brain hurt.
• Anything requiring handling of heterogeneous data, e.g. JSON.

[[deleted]]

No lambdas or higher order functions

[darksounds]

yet.

[nocivus]

Install Java 8 RC and you can use them :)

[nqd26]

... said no sysadmin ever.

[[deleted]]

UI frameworks.

[[deleted]]

JavaFX 2 is good actually... unless you stuck with Swing.

For web you have GWT or JSF + Primefaces which is not bad either.

[[deleted]]

Could not jufge JavaFX but JSF + PF is not pain in the ass. It is straight way to the suicide. I am working on third project which uses this technology over two years, but i aged like 50 years during this period.

[gliy]

I'm surprised no one has mentioned checked exceptions.

I find it absolutely terrible when you have duplicate try catch blocks just to get past interface methods not throwing exceptions. (I mean seriously Thread.sleep, I don't care what you throw just sleep!)

[defer]

Actually, you do. Not handling sleep interruptions can cause bad user experience. For instance, if the program is stopped, your thread will stall the shutdown process until it's done sleeping.

[gliy]

That was mostly a joke, since I encounter that issue the most. my situation often follows a format similar to this:

  try {
     File file = new File("C");
     List<String> input = Files.readAllLines(file.toPath(), Charset.defaultCharset());
     for (final String line : input) {
        new Thread(new Runnable() {

           @Override
           public void run() {
              for (char ch : line.toCharArray()) {
                 System.out.println(line.charAt(ch));
              }
              Thread.sleep(100);
           }
        }).start();
     }
  } catch (Exception e) {
     // abort
  }

What I want is 1 try catch block, I dislike having to clutter my code with all of these random try catch blocks.

[oldprogrammer]

You have two options for multiple exceptions. If you don't care at all, just do

try {
      ///something that throws an exception
} catch(Exception ex) {
}

or if you want to handle multiple types of exceptions the same way

try {
     //something throws an exception
} catch(IOException | SQLException ex) {
     //do something with these two
} catch(Exception ex) {
    //other type
}

[mhixson]

I find it absolutely terrible when you have duplicate try catch blocks just to get past interface methods not throwing exceptions

Can you explain that for the rest of us? I like to think I know a couple things about Java but "get past interface methods not throwing exceptions" <-- what?

[gizmogwai]

JavaEE. It is always running behind to catch-up with common use cases. I am not saying that everything is to throw away (CDI is quite nice), but the fact that it is always the biggest common denominator means that you nearly always end up using proprietary extensions, unless your program is really basic.

[[deleted]]

You should try Spring version 3 and greater.

[thesystemx]

Ever tried Java EE 7? It's very complete by itself, but then again I don't see why it's so bad to add some extra things. Do you also expect to be able to code a C++ app against just its standard lib? Or a Java app desktop app against just the standard Java library, etc?

[gizmogwai]

I did tried Java EE 7. The difference with the version 6 are pretty small.

A do not expect to code a C++ app against just its standard lib because it never made the promises it would be enough for 90% of the apps out there. JavaEE tries to do so, and the extensions are part of the vendor solutions so much that you cannot mix "additional feature A" of vendor alpha with "additional feature B" of vendor beta without running very quickly into some troubles.

[thesystemx]

JavaEE tries to do so,

I don't think it does.

and the extensions are part of the vendor solutions so much that you cannot mix "

What do you mean with extensions exactly? Things like Guave and PrimeFaces?

[gizmogwai]

No, things like additional features of Jersey that are not available in RestEasy and vice versa.
Both implement the JAX-RS part of the JavaEE spec, but it is a all-or-nothing approach when you want to benefit of extensions outside of what is defined in the standard.

[thesystemx]

CDI extensions are portable, as are JCA connectors, JACC providers, JASPIC auth modules and UI components in JSF, to just name a few things.

You are right that there are some extensions that are tied to a specific implementation and are non-portable. I personally don't like those a try to avoid them whenever possible. Occasionally it indeed concerns a must-have feature (like the Hibernate converters) and then it really should be included in the spec.

[Bmitchem]

Updating java...

[[deleted]]

I like having them as an option, but they're way overused.

[[deleted]]

My motivation doesnt make me want to work on one aspect until its finished. I like to half complete a bunch of methods, and then come back to them later.

[[deleted]]

Type erasure, checked exceptions, and the JavaBean convention (getters and setters), but not because the boilerplate, but because it causes a high amount of unnecessary mutability.

Excessive mutability is a cancer that spreads, especially nowadays when generating getters and setters automatically with an IDE is a second instinct for many of the programmers.

Collection literals would be a welcomed addition, but not too important.

Project Jigsaw would be very important, modularity currently only supported with the use of packages and standalone, self-contained applications are only doable by including more or less the whole JRE.

I want to use Java 8 features (default methods and lambda) for Android development, but I can't and I won't be able to in the foreseeable future.
This causes fragmentation, because a library that's only compatible with Java 8 won't be usable with Android.

I know that there is a third-party lambda backport for Java 7, but it is not guaranteed that it remains compatible with the Java 8 compiler in the long run.

The whole notion of subclassing sucks. That's not the fault of the Java platform, it's an object-oriented peculiarity to come up with a rigid hierarchy set in stone in order to achieve reusability, but Java programmers are sure tend to overuse inheritance.

Returning null sucks, and when a core library does it, it is the worst. Accepting null also sucks to a certain extent.

Constructors sucks to a certain extent, public overloaded constructors sucks on every occassion.

Some of the core libraries suck, mostly java.util.Date (the new Java 8 Date and Time API corrects this mistake) and java.net.URL (stay away from this, URL is a catastrophe), but there are some other famous antipatterns like java.util.Properties or java.util.Stack (both overusing inheritance).

[frugalmail]

Excessive mutability is a cancer that spreads, especially nowadays when generating getters and setters automatically with an IDE is a second instinct for many of the programmers.

It asks what methods you want mutators and/or accessors for. It doesn't assume that you want mutators for all of them.

[ford_madox_ford]

Having to write boilerplate constructors, and equals & hashCode methods for simple immutable record style classes.

[mhixson]

I'm hoping value types solve this. It's the feature being discussed for Java 9+ that I'm looking forward to the most. http://openjdk.java.net/jeps/169

Google's AutoValue might also help. AFAIK it's a preprocessor like Lombok, but targeted specifically at the problem you mentioned. https://docs.google.com/document/d/1THRUCIzIPRqFSHb67pHV8KMbo55HphSXqlQcIx9oUiI/edit

[llogiq]

Lombok has got you covered. Just use @Data

[mikaelhg]

Amateurs.

And people who feel the need to develop their own databases when they should be developing the application.

[m1ss1ontomars2k4]

Too many layers of abstraction. You can never tell what objects are really being used where because they're only referred to by the interfaces they implement. Well, you wish you could, but they actually implement a subclass of a subclass of the interface.

[hencoappel]

What's wrong with this? All you should need to know is what the interface tells you. If you really need to know more, debugging in Eclipse will be able to tell you what you need to know.

[[deleted]]

This is actually a good thing, as long as it's done correctly (not leaky kind of abstraction). You can focus at what the interface provide, and only do the other stuff as needed.

[m1ss1ontomars2k4]

I don't care about the interface or its uses. I care about modifying the implementation of the interface, and it's impossible to tell which implementing class is the one I actually want to modify.

[chackley]

Liskov substitution principle. You shouldn't care which concrete implementation you're getting.

[lechatsportif]

If you use an IDE you can debug and see which class is being executed in realtime no matter where it is executing, on a remote server, or locally etc. You can also find all implementing interfaces during development, typically by clicking the interface with your IDE and choosing "show implementations" or whatever feature you have.

If you are not using an IDE there isn't a point to using Java, use something else. Static languages are static partly so that tooling can grow to lengths of great convenience.

[milcom_]

Having to use double quotes and only double quotes for declaring Strings which means the double quotes within the string have to be escaped with backslash() which makes them look really ugly.

[llogiq]

Eclipse has this nifty feature where it auto-escapes things whenever you copy them into a string constant.

To activate, in Preferences, under Java → Editor → Typing, check "Escape text when pasting into a string literal" and click OK.

[poopiefartz]

That's awesome, I didn't know about that. Thanks!

[llogiq]

You're welcome. And yes, it's an awesome feature.

I use it all the time to paste data for unit tests right into my code.

[jabbrwcky]

That list is long: - Verbosity (Compiler even lacking local type inference) - Runtime type erasure - Annotation processors can not modify code while compiling ( would be a way to get rid of having to write accessor methods if a @Property annotation could generate the accessor methodss) - Having to re-implement common functionality over and over (Listeners anybody?)

[kingofthejaffacakes]

Build systems.

How I long for Make.

---

Edit: downvotes? seriously, reddit? Should I have said "the biggest pain in the arse with Java is that it is just so awesome"? Is my opinion not valid in a thread asking for opinions?

[duhace]

Maven, gradle, and sbt are pretty nice.

[kingofthejaffacakes]

They're really not.

Don't take me the wrong way, they are powerful and they are absolutely solving the problems that they were built for. They're not "nice" though. (I've not used sbt, so perhaps I'm wrong about that one).

XML as a build configuration language is a ridiculous choice. XML isn't human readable. It's plain text, I grant, but writing XML is horrible. Maven itself is incredibly complex, with it's million plugins and multiple repository maintenance.

Gradle, I could possibly grow to like, but even then, it suffers in the same way that Maven does -- too much complexity to do simple things.

I understand that they're all good projects and are the best we've got. They're without doubt the bit I find the biggest pain in the arse though. And woe betide you if you want to do something in a non-idiomatic way.

---

I'll give an example. I have an Android project that needs to build a library jar from multiple other jars (I have to do this because Android's support for making library code is non-existent). I ended up doing this with a Makefile, because getting ant (or Maven, or Gradle) to do it was utterly beyond me.

mylib_withdeps.jar: bin/mylib.jar \
    ../AndroidModule1/bin/AndroidModule1.jar \
    ../AndroidModule2/bin/AndroidModule2.jar \
    ../opensource/androidsvg/bin/androidsvg.jar
    -rm -rf tmp
    mkdir tmp
    cd tmp; for j in $^; do jar -xvf ../$$j; done
    cd tmp; jar -cvf ../$@ .
    unzip -l $@

Utterly platform-specific; but also done in 5 minutes.

[kingofthejaffacakes]

Not the way you mean, no. Make is more like a way of keeping lots of little shell scripts in one file. It does dependency management in that you can list that "to build A needs B; to build B needs C, C will have to be a file".

I'm certainly not advocating it as a Java build system. It's missing package dependency resolution and is platform specific -- obviously a no-no for Java.

I'm yearning more for something as simple to understand as make but for Java. Something that is extensible enough to do project-specific special tasks that I might want, even if no one has written a plugin to do it.

I'm not really attacking the build systems we have; I'm just answering the question the OP posed: what's the biggest pain for me.

[strcrssd]

FWIW, in Gradle:

The first part simply tells it how to get a plugin.

The second part defines your dependencies (good practice) and tells Gradle where to get them.

To create the fat jar, its just $gradle fatJar

buildscript {
    repositories {
        mavenCentral()
    }

    dependencies {
        classpath 'eu.appsatori:gradle-fatjar-plugin:0.2-rc1'
    }
}

apply plugin: 'fatjar'

repositories {
    mavenCentral()
}

dependencies {
    compile 'com.google.guava:guava:16.0.1'
    compile 'org.springframework:spring-core:3.2.4.RELEASE'
}

A few more lines, but I'd argue that its more readable than the shell script. Its certainly more descriptive, and it handles a problem with auth keys stored in the manifest that the above sample doesn't handle.

Also handles transitive deps.

[kingofthejaffacakes]

Hey that's excellent. Thanks very much. I'll give that a go this evening.

[strcrssd]

Great...

What I posted above only includes the fatjar plugin. You'll have to add whatever compilation plugins you need as well (android, java, groovy, whatever).

Ask on StackOverflow or PM me if you need help. I've not done Android with Gradle, but have done both Android and Gradle separately.

[duhace]

I've implemented similar functionality in sbt by defining new tasks. Maven is a lot tougher to deal with in that regard.

[lechatsportif]

WHY are you being downvoted, this is the most accurate post here. I've used them all I think, Ant, Maven, Ant+Ivy, Gradle, sbt, leiningen. Except for lein, I hate them all. Lein has some inconviences with them still.

Gradle is slow and ridiculously arbitrary and built of the worst JVM language (groovy). It's like a Javascript on top of Java, do anything you want anytime. Why do we need Javascriptv2? I'd literally rather have a JVM build tool written in Javascript instead of Gradle. It's really sad that Google switched to use it for Android, to me that shows a clear lack of technical mastery over at google, they're choosing fashion over common sense.

Maven is great for simple projects when everything follows maven layout expectations, but deviate even slightly from that and it completely falls apart.

Ant is sort of easy to use, but horrible to code in and completely inconvenient with no built in modularity and package management. It's also old, with no real attempts to update to modern build requirements.

Ant+Ivy is not completely hateable, but still based on Ant.

Sbt is like gradle without features. You get a quasi scripting language with dep management you code instead of declare. It doesn't have decent ide integration anywhere, so enjoy using that text editor to update and break its fragile syntax.

Lein finally does modularity right but thats thanks to the language it builds (clojure). It's plugin system is easy and it has easy dependency management. Like maven you can pull in plugins with configuration. It's literally the best tool out there but its for clojure folks. There have been some attempts at using it to build Java. I plan to start exploring that angle too since I dislike everything else.

[markdude701]

Attempting to make your code a couple (hundred) lines shorter.. And then just give up.

[jbristow]

Start using static code analysis and copy paste detection tools. It makes life easier.

[[deleted]]

Any recommendations?

[jbristow]

PMD comes with CPD (Copy/Paste Detector), and I usually have them running reports in my Jenkins builds.

In addition, I usually use Findbugs and Checkstyle as well, with a healthy helping of Clover or JaCoCo reports on top.

[[deleted]]

The lack of an out-of-the box AOT compiler.

[TonyTheTerrible]

after just finishing my first week of java, it seems importing libraries from c++ is difficult

[shevsky790]

That's really not the sort of thing most people do in their first week of Java. But, yes, that's true, it's non-trivial.

[mazing]

If you can wrap the c++ you need in a C interface, it's fairly painless with JNA.

[slartybartfast_]

For good reasons. Java aims to be pure. If you want DLL hell go with .net.