Why do some people hate Java? Why do some people hate Java?
quora.com
quora.com
It is assumed that this helps with the learning curve, take for example the old VB, very simple, easy to learn but lacks any form of power to do much past what is in the box.
Java took a road somewhere in the middle, not absolute power but not VB. Some people gripe about the choices they made because they are used to features of a more powerful language or features that are simpler in languages that don't religiously adhere to a functional/procedural/object oriented paradigm.
I do a bit of Java work, and as long as you stick to the constructs and patters it is not all that bad, but you do see the idiosyncrasy with the strict adherence to OO.
For example when I write an app in JavaScript I generally have my UI widgets which are OO, then I have procedural code that does the workflows and then I have functional code that provides reusable utility to the workflow. To emulate this in Java I have to create classes that represent the workflow, there are whole frameworks dedicated to doing this, such as Struts and it tends to take on a life of it's own, where my JavaScript work flow is just a JS file. In Java I have struts config, routing, classes that need to be inherited. It actually becomes very complex to undo the OO so I can use procedural code, that best fits work flow. Now that is just the workflow, to create utility functions I have to declare everything static and ensure that everything is self encapsulated for thread safety. Having to use OO to provide functional routines means double checking all the OO baggage to make sure I have not messed up scope and killed my thread safety. The alternative is to use OO for workflow and utility functions in which case the result is a mess of spaghetti code. Because OO does not lend itself to large multistage workflow. As well creating objects for utility functions is a lot of overhead.
Another example would be delegates, callbacks, anonymous functions, function pointers as they are called in other languages, their real name is Lambda Forms. Take for example in Lisp or JavaScript, I can take a reference to a function and pass it as an argument to another function. This provides all kinds of flexibility that allows for code reuse. For example say I have a routine that is exactly the same except for a small portion of code, with a Lambda Form type language I can create customized functions and pass them into the generic routine which then calls that custom logic. As well I can use it to give a routine access to limited scope outside of itself. It's actually really powerful and can eliminate a lot of code. In strict strong typed OO without access to pointers though it is a convoluted process to accomplish this simple language construct. You have to use an interface that defines a function signature and then you have to inline declare a class that implements that interface, from there you can give it scope to the encapsulating class. Again, the dogmatic adherence to Java's language structure and rules creates something that is far more complex that simple Lambda Forms.
Multiple inheritance is a big issue for many, a very powerful feature was thrown out due to the fact that in a few fringe cases you run into conflicts, when a simple chain of command would have sufficed. A lot of OO's promise went out the window when multiple inheritance was killed in Java. For example say I have an object and I want it to serialize to a file with MI, I could inherited a parent object and a file serialize and with little code, create such an object. With single inheritance I am left with stripped down interfaces that I have to go and write the code for, they do nothing but guarantee a contract. This is great for a bunch of custom classes that need to be treated generically, but for cases where I want to take two novel classes and create a class as a product of them, it fails. Ruby and some of the JavaScript toolkits like Dojo did a really good job of addressing the issues of multiple inheritance via mixins. They addressed the issues without throwing it out and are the better for it.
Finally, I really would like to see a languages that uses the idea Microsoft used in C# with the unsafe flag, but a little different, instead of having to declare something unsafe in code, have a layered approach to the language for example first layer is dynamic with no type safety, maybe not even OO at that layer, kind of like basic or JavaScript. Just a simple language that can be picked up by complete novices. Then you can choose to implement addition layers like type safety, OO. Then at another level you can chose to layer on Lambda's pointers, multiple inheritance. etc. The really nice part about this would be that you could turn off layers when they are getting in the way of doing something simple, like say needed to drop out of the OO box for a simple routine.
As a note: I do a lot of Java development and have worked with most of the major languages, as a language I don't find Java all that bad, and I find the wealth of libraries available generally far outweighs any idiosyncrasy the language brings as baggage with it.
One of my biggest gripes is server manufacturers wrapping the remote console functionality in a LOM in some stupid Java app. Why not just allow raw VNC or RDP connectivity? There's a 50% chance that any given server I try to manage will fail on my primary browser (Firefox and Chrome on FreeBSD), and I'll most likely need to fire off IE in a Windows VM just to do my damned job.
Plus, the size of the run-time environment itself is shocking. Sure, I have 8GB of memory in my workstation, but why use a few hundred of it when a binary client would consume just a couple? A perfect example of this is the units converter "frink" (by Alan Eliasen), distributed as a jar file. I just fired it up, and it consumes 55MB of resident memory and a total virtual memory size of 343MB. This program is mostly a fancier version of the unix "units" command. (I don't wish to disrespect the author here -- I find frink insanely useful -- but 25-to-50 times the memory footprint of the likely equivalent C program hits an aesthetic nerve with me.)
There are quite a few slick products I simply don't use because I find the requirement for Java distasteful. Limewire is a good example. Whenever I'm exploring my FreeBSD ports collection for something I need (or just looking for cool stuff), I tend to skip the ones where Java is a dependency.
The other day I was reading triangle mesh data into Processing and the data seemed to have an error somewhere. Part of finding it was checking for duplicate edges. So I wanted a Set of tuples of reals. Hilarity ensued. That Java didn't have tuples was a minor annoyance. The amount of boilerplate needed to make what was basically a struct of two floats Set'able was ridiculous. I suspect Java is not as terrible for big projects.
As a hobbyist programmer, my advice is that you should not limit yourself to one language. If you are a Java guy, you can still learn a very different language like Python, Lisp, or CoffeeScript. I believe that once you feel competent with a few different languages, you will begin to see through the language war BS and understand the roles of Java in the world.