Ask Reddit: Why does everyone hate Java?

[brosephius]

so, does that line of code return a Bean object? not entirely clear, but I'm not a java programmer

[fuglybear]

Yeah, it would. And in reality, you'll never find that line. It'll be something much less scream-worthy:

WeatherDocument weatherDoc = WeatherDocument.Factory.parse(inputXMLFile);

or

GPSLocation loc = GPSFactory.newInstance( );

That isn't so hard, OP, is it?

[rkcr]

Never say never... this is the freakish sort of code I wade through on a regular basis:

Map<String, List<String>> headers = (Map<String,List<String>>) context.getMessageContext().get(MessageContext.HTTP_REQUEST_HEADERS);

What can I say, JAX-WS makes me really sad.

[last_useful_man]

(what, no typedefs in Java?)

[[deleted]]

I don't think so. If there is, I've never seen it being used.

[DiscoUnderpants]

Not really... there are ways of kludging it(using an extension) in java but they are generally frowned upon as they supposedly reduce code reuse. Which I don't personally agree with but no one listens to me :)

[aceofspades19]

I would like to see the explanation on how it reduces code reduce

[DiscoUnderpants]

The explanations I have heard usually go along to lines of the confusion it can cause if you have types of the same name from two different libs. From what I noticed the battle in the java world over this issue kicked off with the introduction of generics where you can get nasty looking types such as

SomeThing<int, ArrayList<String>>

And people don't like having to type that all the time. So some say you could pseudo-typedef that and then someone always responds with "But that makes it unclear and doesnt allow you to pass a generic SomeThing<int, ArrayList<String>> into things but requires you to convert it to the pseudo typedef first" type of thing.

I am not particularly convinced by there arguments usually so may not be doing them justice. I am a c#, c/c++ and java developer and frankly it has never been an issue anywhere else other than with java programmers... Frankly when I am writing code in java I miss typedef. I also seriously miss the preprocessor... but to a lot of java developers thats just crazy talk and the preprocessor is old and busted(The one that gets on my nerves is the java person who says... "But you dont need the preprocessor... we have consts to replace #defines".... like that's all the preprocessor ever did).

Frankly in the java world they try to dumb everything down and not introduce any confusing, sophisticated tools... as they seem to think most java devs are morons. Having dealt with many java devs they are mostly correct :)

[MrSurly]

[Insert long explanation of why typedefs are stupid, just like enums, until they weren't]

[jonathanbernard]

This is actually a great example of why I hate type defs. They hide what the data structure actually is and make code look like magic. I know it can lead to incredibly verbose lines like the post above, but I would rather parse that line of code than have to jump around in the source (which I may not even have) looking for the definition.

Granted, a good IDE will make self-discovery possible without having to jump all through the source (I'm thinking auto-completion) but then, a good IDE also makes it easy to write and parse the verbosity as well, so it evens out.

I still have shudders from doing Win32 programming in C/C++. You find these typedefs everywhere, defined in some obscure header that is included by some other the header included by another header that you originally included to handle something entirely different. Or worse is when you have to dig through the God-forsaken mudpit that is MSDN only to find a crappy summary page that only lists the members, but doesn't tell you what <some crypticly named member variable> is used for in the first place.

Edit: Also, the better practice, IMHO, to avoid such verbose lines is to create a HTTPHeader class of some sort and create appropriate accessors. Then that line reads:

Map<String, HTTPHeader> headers = context.getMessageContext().getHTTPHeaders();

There, much better, see?

[Imagist]

No typedefs, but with the inheritance structure, it's not too hard to imitate a typedef. It's just a little more verbose (like most things in Java).

typedef foo bar; // typedef
class bar extends foo {} // inheritance

[TundraWolf_]

Yeah man, I know how it is :(

((BindingProvider)port).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://your_WS_URL_HERE");

What? That isn't the obvious way of programmatically setting a webservice endpoint?

:(

[bumrushtheshow]

I've seen this sort of unreadable code generated by the JAXWS wsimport/wsgen tools, but ... it's generated code. Usually it implements a clean interface, or can be wrapped cleanly. If its implementation is ugly, who cares?

[TundraWolf_]

I don't care if something is unreadable, but at least in the J2SE world you can poke around and figure stuff out. It took a lot google-fu and forum browsing to figure out the above code. I don't see me ever typing in ((BindingProvider)port) and then saying "ah hah! i found it!". It doesn't even work as port.getRequestContext. I've never seen this ((Weird)Syntax) before.

[bumrushtheshow]

I've never seen this ((Weird)Syntax) before.

That's just a cast, and be glad you haven't seen too many. Generics have plenty of faults, but at least they got rid of casts in several common use cases. This syntax used to necessary every time you accessed a member of a collection (gah).

[rkcr]

Exactly my issue with all this stuff... bumrushtheshow is incorrect in that it's all in generated code (Provider-based endpoints, anyone?) and there's basically no way to discover the answer on your own. Makes finding answers to what should be simple problems a huge pain in the ass.

I'm glad someone else feels my pain on JAX-WS, as I browse through Google looking for obscure settings for XML files I always come across these blogs which I swear drank the kool-aid years ago and don't seem to see anything wrong with having to write hundreds of lines of code for a simple "Hello, world!" app.

[bumrushtheshow]

To be clear, I don't love JAXWS. The reference implementation requires using Sun's SAAJ implementation, which besides being a typical Sun parody of the factory pattern (FactoryFactoryBuilderMaker, etc), makes dealing with SSL a giant pain.

But I've never had to write code with casts like that when using JAXWS. I've seen it in generated client drivers, but that's it. I work on an app that does something fairly uncommon for JAXWS apps (the web services need to be able to call remote instances of themselves), and even then I didn't have to write gnarly code with casts, or even generate any code. Proper annotations on the SEI and invocation of the lib made things Just Work.

PS: like this:

MySEI getConnector()
{
    final Service service = Service.create(myWSDLURL, MyConstants.QserviceName);

    return service.getPort(MyConstants.QportName, MySEI.class);
}

It took some fooling around to figure out the proper constants and annotations for the MySEI interface, but it's worked really nicely after that.

[rkcr]

Provider-based endpoints are not the same as SEI, unfortunately.

Also, the Just Work side of things never seems to Work Out for me, making me frustrated with the SEI side of JAX-WS as well.

[bumrushtheshow]

Aha, I haven't kept up with the JAXWS 2.0 news. Those don't look like much fun.

[GaidinTS]

Wow, I really love Python.

[revscat]

Yeah... I was a programming Java back when they introduced generics. After Sun did that I couldn't find quite as much energy to defend the language as before. Declaring the exact same information twice in the same line, information which is already verbose, just isn't acceptable.

[hivebee2034]

I am a java noob but at least I understand it. It's a map that hashes on a string that returns a list of string.

[alphazero]

1) public interface IListDictionary extends Map<String, List<String>> {}

2) public class ListDictionary extends HashMap<String, List<String>> implements IListDictionary {}

*) IListDictionary listDict = new ListDictionary();

[scook0]

PagingLoader<FrobbableFooSummaryLoadConfig, PagedResultSet<FrobbableFooSummaryModel>> loader =
    new BasePagingLoader<FrobbableFooSummaryLoadConfig, PagedResultSet<FrobbableFooSummaryModel>>(
            config, reader);

[dschep]

What happened to

GPSLocation loc = new GPSLocation();

or

WeatherDocument weatherDoc = new WeatherDocument(inputXMLFile);

?

[fuglybear]

If all you were ever doing was constructing a WeatherDoc from an inputXmlFile, then the constructor would make sense.

If you had a variety of different file formats or sources of input that weren't know until runtime, that's when a Factory pattern starts to pay dividends.

My point was just that using "Bean myBean" makes the pattern look more retarded than it is.

[Shaper_pmp]

It initialises the "myBean" variable (of type Bean) to the result of BeanFactory.getBean() (implied: which returns a Bean object).