Common Misconceptions About Java
Java is the most widely used language in the world ([citation needed]), and everyone has an opinion about it. Due to it being mainstream, it is usually mocked, and sometimes rightly so, but sometimes the criticism just doesn’t touch reality. I’ll try to explain my favorite 5 misconceptions about Java. Java is slow – that might have been true for Java 1.0, and initially may sounds logical, since java is not compiled to binary, but to bytecode, which is in turn interpreted. However, modern versions of the JVM are very, very optimized (JVM optimizations is a topic worth not just an article, but a whole book) and this is no longer remotely true. As noted here, Java is even on-par with C++ in some cases. And it is certainly not a good idea to make a joke about Java being slow if you are a Ruby or PHP developer. Java is too verbose – here we need to split the language from the SDK and from other libraries. There is some verbosity in the JDK (e.g. java.io), which is: 1. easily overcome with de-facto standard libraries like guava 2. a good thing As for language verbosity, the only reasonable point were anonymous classes. Which are no longer an issue in Java 8 with the the functional additions. Getters and setters, Foo foo = new Foo() instead of using val – that is (possibly) boilerplate, but it’s not verbose – it doesn’t add conceptual weight to the code. It doesn’t take more time to write, read or understand. Other libraries – it is indeed pretty scary to see a class like AbstractCommonAsyncFacadeFactoryManagerImpl. But that has nothing to do with Java. It can be argued that sometimes these long names make sense, it can also be argued that they are as complex because the underlying abstraction is unnecessarily complicated, but either way, it is a design decision taken per-library, and nothing that the language or the SDK impose per-se. It is common to see overengineered stuff, but Java in no way pushes you in that direction – stuff can be done in a simple way with any language. You can certainly have AbstractCommonAsyncFacadeFactoryManagerImpl in Ruby, just there wasn’t a stupid architect that thought it’s a good idea and who uses Ruby. If “big, serious, heavy” companies were using Ruby, I bet we’d see the same. Enterprise Java frameworks are bloatware – that was certainly true back in 2002 when EJB 2 was in use (or “has been”, I’m too young to remember). And there are still some overengineered and bloated application servers that you don’t really need. The fact that people are using them is their own problem. You can have a perfectly nice, readable, easy to configure and deploy web application with a framework like Spring, Guice or even CDI; with a web framework like Spring-MVC, Play, Wicket, and even the latest JSF. Or even without any framework, if you feel like you don’t want to reuse the evolved-through-real-world-use frameworks. You can have an application using a message queue, a NoSQL and a SQL database, Amazon S3 file storage, and whatnot, without any accidental complexity. It’s true that people still like to overeingineer stuff, and add a couple of layers where they are not needed, but the fact that frameworks give you this ability doesn’t mean they make you do it. For example, here’s an application that crawls government documents, indexes them, and provides a UI for searching and subscribing. Sounds sort-of simple, and it is. It is written in Scala (in a very java way), but uses only java frameworks – spring, spring-mvc, lucene, jackson, guava. I guess you can start maintaining pretty fast, because it is straightforward. You can’t prototype quickly with Java – this is sort-of related to the previous point – it is assumed that working with Java is slow, and that’s why if you are a startup, or a weekend/hackathon project, you should use Ruby (with Rails), Python, Node JS or anything else that allows you to quickly prototype, to save & refresh, to painlessly iterate. Well, that is simply not true, and I don’t know even where it comes from. Maybe from the fact that big companies with heavy processes use Java, and so making a java app is taking more time. And Save-and-Refresh might look daunting to a beginner, but anyone who has programmed in Java (for the web) for a while, has to know a way to automate that (otherwise he’s a n00b, right?). I’ve summarized the possible approaches, and all of them are mostly OK. Another example here (which may be used as an example for the above point as well) – I made did this project for verifying secure password storage of websites within a weekend + 1 day to fix stuff in the evening. Including the security research. Spring-MVC, JSP templates, MongoDB. Again – quick and easy. You can do nothing in Java without an IDE – of course you can – you can use notepad++, vim, emacs. You will just lack refactoring, compile-on-save, call hierarchies. It would be just like programming in PHP or Python or javascript. The IDE vs Editor debate is a long one, but you can use Java without an IDE. It just doesn’t make sense to do so, because you get so much more from the IDE than from a text editor + command line tools. You may argue that I’m able to write nice and simple java applications quickly because I have a lot of experience, I know precisely which tools to use (and which not) and that I’m of some rare breed of developers with common sense. And while I’ll be flattered by that, I am no different than the good Ruby developer or the Python guru you may be. It’s just that java is too widespread to have only good developers and tools. if so many people were using other language, then probably the same amount of crappy code would’ve been generated. (And PHP is already way ahead even with less usage). I’m the last person not to laugh on jokes about Java, and it certainly isn’t the silver bullet language, but I’d be happier if people had less misconceptions either because of anecdotal evidence, or due to previous bad experience a-la “I hate Java since my previous company where the project was very bloated”. Not only because I don’t like people being biased, but because you may start your next project with a language that will not work, just because you’ve heard “Java is bad”.
April 4, 2014
·
20,838 Views
·
1 Like
Comments
Jan 20, 2019 · James Sugrue
It was a long time ago and I've lost all code except the one in the blogpost..
Jun 10, 2018 · Duncan Brown
If you want to be precise, yes. And it's not so applicable to the scenario of constantly coming and going servers. But that's not the general usecase out there
Jan 02, 2018 · Jordan Baker
The Regulation has a specific clause that says "if the data is required by regulation, it should be stored". So other regulations override the principles in this one.
As for fraud - you can still keep audit logs, especially of sensitive actions (like trying credit card numbers), and besides, you don't have to immediately "forget' the user. You can take the request and manually forget them within a few days, after making sure no fraudulent behaviour was attempted.
Nov 15, 2017 · Michael_Gates
Eclipse is not without issues, of course, and I also like IDEA's extras.
Nov 15, 2017 · Michael_Gates
which one I didn't know how to use? The call hierarchy critique was not about me not liking it, but an observation of IDEA users. I use it heavily (and find it lacking when trying to find a default constructor call hierarchy).
The rest are not features (I know about proejcts vs modules - but modules imply logocal coupling and that's not applicable in many cases)
Apr 30, 2015 · James Sugrue
Good question, but I don't know. Check the management API, though - maybe it spits some relevant information and you can consume it with a RestTemplate or any rest client in Java
Apr 18, 2015 · Allen Coin
Sure, I know what NIO is designed to solve. The NIO connector is a specific usage of NIO (which has a lot more general application).
I'm not sure the TCP specifics matter here - the point is that NIO multiplexes between requests, and writing the responses.
How would you write a real-world, but not too complicated scenario to test?
Apr 18, 2015 · Allen Coin
Sure, I know what NIO is designed to solve. The NIO connector is a specific usage of NIO (which has a lot more general application).
I'm not sure the TCP specifics matter here - the point is that NIO multiplexes between requests, and writing the responses.
How would you write a real-world, but not too complicated scenario to test?
Apr 18, 2015 · Allen Coin
Sure, I know what NIO is designed to solve. The NIO connector is a specific usage of NIO (which has a lot more general application).
I'm not sure the TCP specifics matter here - the point is that NIO multiplexes between requests, and writing the responses.
How would you write a real-world, but not too complicated scenario to test?
Apr 18, 2015 · Allen Coin
How would five consecutive file reads differ from a single one?
Apr 18, 2015 · Allen Coin
How would five consecutive file reads differ from a single one?
Jan 30, 2015 · James Sugrue
So, you have a class FooProvider and you see an exception thrown there. You go to the class, go to the method, and have no clue what the class is about. The code in the method itself is obvious, the name of the method and that of the class are obvious, yet it's entirely unclear how that fits into the bigger picture and why it's needed.
I think having comments and documentation on public methods is an agreed best-practice. Maybe my assumption about that is wrong, though.
Jan 26, 2015 · James Sugrue
I disagree. The code can be good and readable, but it needs context. The comments provide the context.
Apr 03, 2014 · James Sugrue
Yeah. Unfortunately I'm not a full-time android developer, so I won't be able to fix all the painpoints of the Camera API, but I'm open to suggestions.
Feb 26, 2014 · James Sugrue
Also possible. But URL validation may be moved to the RestClient class, rather than expecting a valid url as input. Both are viable.
Feb 24, 2014 · James Sugrue
Good point. It adds a little bit of complexity to the API, but is worth considering.
Aug 09, 2013 · James Sugrue
.......
Aug 09, 2013 · James Sugrue
Good point - the only drawback of the native solution is that the resources stay in the jars, which means you can't change them in development mode, and save-and-refresh won't work.
Aug 09, 2013 · James Sugrue
Good point - the only drawback of the native solution is that the resources stay in the jars, which means you can't change them in development mode, and save-and-refresh won't work.
May 23, 2013 · Skills Matter Marketing
Automatic reloading of jsps is a standard JavaEE servlet container option, there is no issue with that.
May 23, 2013 · Skills Matter Marketing
Automatic reloading of jsps is a standard JavaEE servlet container option, there is no issue with that.
May 23, 2013 · Skills Matter Marketing
Automatic reloading of jsps is a standard JavaEE servlet container option, there is no issue with that.
May 23, 2013 · Skills Matter Marketing
Automatic reloading of jsps is a standard JavaEE servlet container option, there is no issue with that.
May 23, 2013 · Skills Matter Marketing
Automatic reloading of jsps is a standard JavaEE servlet container option, there is no issue with that.
May 23, 2013 · James Sugrue
Automatic reloading of jsps is a standard JavaEE servlet container option, there is no issue with that.
May 23, 2013 · James Sugrue
Automatic reloading of jsps is a standard JavaEE servlet container option, there is no issue with that.
May 23, 2013 · James Sugrue
Automatic reloading of jsps is a standard JavaEE servlet container option, there is no issue with that.
May 23, 2013 · James Sugrue
Automatic reloading of jsps is a standard JavaEE servlet container option, there is no issue with that.
May 23, 2013 · James Sugrue
Automatic reloading of jsps is a standard JavaEE servlet container option, there is no issue with that.
Nov 05, 2012 · Bozhidar Bozhanov
Sep 10, 2012 · Allen Coin
Dec 09, 2011 · James Sugrue
Dec 09, 2011 · James Sugrue
Dec 09, 2011 · James Sugrue
Oct 28, 2011 · Mr B Loid
Oct 28, 2011 · James Sugrue
Oct 25, 2011 · Bozhidar Bozhanov
Oct 25, 2011 · Bozhidar Bozhanov
Oct 25, 2011 · Bozhidar Bozhanov
Oct 13, 2011 · Bozhidar Bozhanov
Oct 12, 2011 · Andries Inzé
Oct 12, 2011 · Siva Prasad Reddy Katamreddy
Sep 28, 2011 · Shamanth Murthy
Sep 27, 2011 · Shamanth Murthy
Sep 26, 2011 · Shamanth Murthy
Sep 26, 2011 · mitchp
Sep 15, 2011 · James Sugrue
Sep 07, 2011 · Mr B Loid
They use dynamic proxies, which is still an OOP approach, although, for concrete classes, there's no good support in the language and its libraries. Btw, in normal (eager) scenarios JPA implementations don't need to make proxies.
I called it "black magic", because the dependency appears to come from nowhere. With JPA proxies you get that from the entitymanager, so even though it may look strange, it is obvious where it comes from. With aspectj you have "new Foo()", and suddenly your instances has all sorts of things happening to it - contrary to what you'd expect from a normal object.
I agree that aspectj is not a bad thing, but note also my point that it is only supported by spring. I was suggesting something more standard.
Sep 07, 2011 · Mr B Loid
They use dynamic proxies, which is still an OOP approach, although, for concrete classes, there's no good support in the language and its libraries. Btw, in normal (eager) scenarios JPA implementations don't need to make proxies.
I called it "black magic", because the dependency appears to come from nowhere. With JPA proxies you get that from the entitymanager, so even though it may look strange, it is obvious where it comes from. With aspectj you have "new Foo()", and suddenly your instances has all sorts of things happening to it - contrary to what you'd expect from a normal object.
I agree that aspectj is not a bad thing, but note also my point that it is only supported by spring. I was suggesting something more standard.
Sep 07, 2011 · Mr B Loid
They use dynamic proxies, which is still an OOP approach, although, for concrete classes, there's no good support in the language and its libraries. Btw, in normal (eager) scenarios JPA implementations don't need to make proxies.
I called it "black magic", because the dependency appears to come from nowhere. With JPA proxies you get that from the entitymanager, so even though it may look strange, it is obvious where it comes from. With aspectj you have "new Foo()", and suddenly your instances has all sorts of things happening to it - contrary to what you'd expect from a normal object.
I agree that aspectj is not a bad thing, but note also my point that it is only supported by spring. I was suggesting something more standard.
Sep 07, 2011 · James Sugrue
They use dynamic proxies, which is still an OOP approach, although, for concrete classes, there's no good support in the language and its libraries. Btw, in normal (eager) scenarios JPA implementations don't need to make proxies.
I called it "black magic", because the dependency appears to come from nowhere. With JPA proxies you get that from the entitymanager, so even though it may look strange, it is obvious where it comes from. With aspectj you have "new Foo()", and suddenly your instances has all sorts of things happening to it - contrary to what you'd expect from a normal object.
I agree that aspectj is not a bad thing, but note also my point that it is only supported by spring. I was suggesting something more standard.
Sep 07, 2011 · James Sugrue
They use dynamic proxies, which is still an OOP approach, although, for concrete classes, there's no good support in the language and its libraries. Btw, in normal (eager) scenarios JPA implementations don't need to make proxies.
I called it "black magic", because the dependency appears to come from nowhere. With JPA proxies you get that from the entitymanager, so even though it may look strange, it is obvious where it comes from. With aspectj you have "new Foo()", and suddenly your instances has all sorts of things happening to it - contrary to what you'd expect from a normal object.
I agree that aspectj is not a bad thing, but note also my point that it is only supported by spring. I was suggesting something more standard.
Sep 07, 2011 · James Sugrue
They use dynamic proxies, which is still an OOP approach, although, for concrete classes, there's no good support in the language and its libraries. Btw, in normal (eager) scenarios JPA implementations don't need to make proxies.
I called it "black magic", because the dependency appears to come from nowhere. With JPA proxies you get that from the entitymanager, so even though it may look strange, it is obvious where it comes from. With aspectj you have "new Foo()", and suddenly your instances has all sorts of things happening to it - contrary to what you'd expect from a normal object.
I agree that aspectj is not a bad thing, but note also my point that it is only supported by spring. I was suggesting something more standard.
Sep 07, 2011 · Mr B Loid
Sep 07, 2011 · Mr B Loid
Sep 07, 2011 · Mr B Loid
Sep 07, 2011 · James Sugrue
Sep 07, 2011 · James Sugrue
Sep 07, 2011 · James Sugrue
Aug 31, 2011 · Byron Kiourtzoglou
Aug 31, 2011 · Tony Thomas
Aug 31, 2011 · Tony Thomas
Aug 31, 2011 · Tony Thomas
Aug 31, 2011 · Tony Thomas
Aug 31, 2011 · Tony Thomas
Aug 31, 2011 · Tony Thomas
Aug 31, 2011 · Tony Thomas
Aug 31, 2011 · Tony Thomas
Aug 31, 2011 · James Sugrue
Aug 31, 2011 · James Sugrue
Aug 31, 2011 · James Sugrue
Aug 31, 2011 · James Sugrue
Aug 31, 2011 · James Sugrue
Aug 31, 2011 · James Sugrue
Aug 31, 2011 · James Sugrue
Aug 31, 2011 · James Sugrue
Aug 31, 2011 · Tony Thomas
web.xml is part of the build, so I don't think it's nice to put the path there.
I don't like the database option, because it is much easier for Ops to deploy, redeploy and reconfigure text files than a database. It's simpler for development as well.
Aug 31, 2011 · Tony Thomas
web.xml is part of the build, so I don't think it's nice to put the path there.
I don't like the database option, because it is much easier for Ops to deploy, redeploy and reconfigure text files than a database. It's simpler for development as well.
Aug 31, 2011 · Tony Thomas
web.xml is part of the build, so I don't think it's nice to put the path there.
I don't like the database option, because it is much easier for Ops to deploy, redeploy and reconfigure text files than a database. It's simpler for development as well.
Aug 31, 2011 · James Sugrue
web.xml is part of the build, so I don't think it's nice to put the path there.
I don't like the database option, because it is much easier for Ops to deploy, redeploy and reconfigure text files than a database. It's simpler for development as well.
Aug 31, 2011 · James Sugrue
web.xml is part of the build, so I don't think it's nice to put the path there.
I don't like the database option, because it is much easier for Ops to deploy, redeploy and reconfigure text files than a database. It's simpler for development as well.
Aug 31, 2011 · James Sugrue
web.xml is part of the build, so I don't think it's nice to put the path there.
I don't like the database option, because it is much easier for Ops to deploy, redeploy and reconfigure text files than a database. It's simpler for development as well.
Aug 31, 2011 · Tony Thomas
Aug 31, 2011 · Tony Thomas
Aug 31, 2011 · James Sugrue
Aug 31, 2011 · James Sugrue
Aug 30, 2011 · Tony Thomas
Aug 30, 2011 · James Sugrue
Aug 25, 2011 · James Sugrue
Aug 25, 2011 · James Sugrue
Aug 25, 2011 · James Sugrue
Aug 20, 2011 · Bozhidar Bozhanov
Aug 20, 2011 · Bozhidar Bozhanov
Jul 01, 2011 · Alex Hortopan
May 09, 2011 · Bozhidar Bozhanov
May 02, 2011 · Bozhidar Bozhanov
May 01, 2011 · Bozhidar Bozhanov
May 01, 2011 · Bozhidar Bozhanov
Apr 30, 2011 · Bozhidar Bozhanov
Apr 30, 2011 · Bozhidar Bozhanov
Apr 30, 2011 · Bozhidar Bozhanov
Apr 30, 2011 · Bozhidar Bozhanov
Apr 30, 2011 · Bozhidar Bozhanov
Apr 30, 2011 · Bozhidar Bozhanov
Apr 30, 2011 · Bozhidar Bozhanov
Apr 30, 2011 · Bozhidar Bozhanov
Feb 28, 2011 · Gerd Storm
This is not deep copying. Both clone() and BeanUtils.cloneBean() make shallow copies. Deep copying means that the whole data hierarchy is replaced. With the above approaches if you call foo.getBar().setBaz(..), the change will be reflected in both the clone and the original object.
There are two ways to to deep cloining in Java - one is reflection and the other is serialization. commons-lang have SerializationUtils.clone(..). And for reflection there's java-deep-cloning-library.
See this stackoverflow answer.
Feb 28, 2011 · James Sugrue
This is not deep copying. Both clone() and BeanUtils.cloneBean() make shallow copies. Deep copying means that the whole data hierarchy is replaced. With the above approaches if you call foo.getBar().setBaz(..), the change will be reflected in both the clone and the original object.
There are two ways to to deep cloining in Java - one is reflection and the other is serialization. commons-lang have SerializationUtils.clone(..). And for reflection there's java-deep-cloning-library.
See this stackoverflow answer.
Feb 22, 2011 · Bozhidar Bozhanov
Dec 30, 2010 · Bozhidar Bozhanov
Dec 28, 2010 · Tony Thomas
Dec 28, 2010 · James Sugrue
Oct 18, 2010 · Peter Thomas
Sep 17, 2010 · Yuri Filimonov
And what is the problem of
throw new RuntimeException(originalException);
Sep 17, 2010 · Luigi Viggiano
And what is the problem of
throw new RuntimeException(originalException);
Sep 05, 2010 · Sharath A.V
Reread this post and ask yourself whether it's not just a rant without any sign of concreteness.
In this thread I've made some (I hope) less biased points about CDI
Btw, Spring commercial? VMWare is, but not the sprign framework.
CDI is based on Seam, Guice and Spring. (less on spring, alas). And it looks good when you get into depth - it is a mature DI framework. Whether it's better than spring or guice - time will tell.
Sep 05, 2010 · James Sugrue
Reread this post and ask yourself whether it's not just a rant without any sign of concreteness.
In this thread I've made some (I hope) less biased points about CDI
Btw, Spring commercial? VMWare is, but not the sprign framework.
CDI is based on Seam, Guice and Spring. (less on spring, alas). And it looks good when you get into depth - it is a mature DI framework. Whether it's better than spring or guice - time will tell.
May 25, 2010 · Nicolas Fränkel
May 23, 2010 · erik ooostent
Can you create a generic repository (DAO) with this scenario? "createBean" is type-unsafe, because you are passing the bean name and return an Object. If we extend this approach to JPA, we'll have to consider caches, entity manager lifecycle combined with a prototype lifecycle, etc.
My view on DDD with spring is a bit different - you shouldn't use spring to manage your domain objects (if using JPA at least)
May 23, 2010 · Erdinç Kocaman
Can you create a generic repository (DAO) with this scenario? "createBean" is type-unsafe, because you are passing the bean name and return an Object. If we extend this approach to JPA, we'll have to consider caches, entity manager lifecycle combined with a prototype lifecycle, etc.
My view on DDD with spring is a bit different - you shouldn't use spring to manage your domain objects (if using JPA at least)
Aug 20, 2009 · Denis Gobo
Well, your statement is wrong from the very beginning. It is not hard to google 'JSF ajax' (or something of the sort), and stumble upon wonderful frameworks like RichFaces or PrimeFaces. There are ajaxified and ajaxifying jsf components. Then all of your arguments go nowhere. I've worked with RichFaces for sometime, and it is really state of the art. You use ajax with writing no javascript whatsoever. Validators can use your model objects directly (with Hibernate-validation), so - automatic ajax validation. And so on, and so forth.
So better go check those frameworks ;)
Aug 20, 2009 · James Sugrue
Well, your statement is wrong from the very beginning. It is not hard to google 'JSF ajax' (or something of the sort), and stumble upon wonderful frameworks like RichFaces or PrimeFaces. There are ajaxified and ajaxifying jsf components. Then all of your arguments go nowhere. I've worked with RichFaces for sometime, and it is really state of the art. You use ajax with writing no javascript whatsoever. Validators can use your model objects directly (with Hibernate-validation), so - automatic ajax validation. And so on, and so forth.
So better go check those frameworks ;)
Aug 16, 2009 · Lebon Bon Lebon
Actually, JSF is not that much 'ivory towery'. I'm using JSF 1.2 now + RichFaces, and I must say, this is pretty much sufficient. It offers almost all the abstractions that can possibly be needed (and even such that would not be needed). Yes, it has drawbacks, which are being addressed in JSF 2.0.
Aug 16, 2009 · James Sugrue
Actually, JSF is not that much 'ivory towery'. I'm using JSF 1.2 now + RichFaces, and I must say, this is pretty much sufficient. It offers almost all the abstractions that can possibly be needed (and even such that would not be needed). Yes, it has drawbacks, which are being addressed in JSF 2.0.
Jul 09, 2008 · Bozhidar Bozhanov