{"id":154,"date":"2019-07-20T12:32:58","date_gmt":"2019-07-20T12:32:58","guid":{"rendered":"http:\/\/bcisnotes.com\/secondsemester\/?p=154"},"modified":"2020-01-10T14:29:46","modified_gmt":"2020-01-10T08:44:46","slug":"common-misconceptions-of-java","status":"publish","type":"post","link":"https:\/\/bcisnotes.com\/secondsemester\/object-oriented-programming\/common-misconceptions-of-java\/","title":{"rendered":"Common Misconceptions of Java || Introduction to java || Bcis Notes"},"content":{"rendered":"

Common Misconceptions of Java:-<\/h2>\n

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\u2019t touch reality. I\u2019ll try to explain my favourite 5 misconceptions about Java.<\/p>\n

Java is slow \u2013<\/strong><\/p>\n

That might have been true for Java 1.0, and initially may sound 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.<\/p>\n

Java is too verbose \u2013<\/strong><\/p>\n

Here we need to split the language from the SDK and from other libraries.<\/p>\n

There is some verbosity in the JDK (e.g. java.io), which is:<\/p>\n

    \n
  1. easily overcome with de-facto standard libraries like guava<\/li>\n
  2. a good thing<\/li>\n<\/ol>\n

    As for language verbosity, the only reasonable point was anonymous classes. Which are no longer an issue in Java 8 with the functional addition? Getters and setters, Foofoo = new Foo() instead of using value \u2013 that is (possibly) boilerplate, but it\u2019s not verbose \u2013 it doesn\u2019t add conceptual weight to the code. It doesn\u2019t take more time to write, read or understand.<\/p>\n

     <\/p>\n

    Other libraries \u2013<\/strong><\/p>\n

    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 was taken per-library and nothing that the language or the SDK impose perse. It is common to see over-engineered stuff, but Java in no way pushes you in that direction \u2013 stuff can be done in a simple way with any language. You can certainly have AbstractCommonAsyncFacadeFactoryManagerImpl in Ruby, just there wasn\u2019t a stupid architect that thought it\u2019s a good idea and who uses Ruby. If \u201cbig, serious, heavy\u201d companies were using Ruby, I bet we\u2019d see the same.<\/p>\n

     <\/p>\n

    You can do nothing in Java without an IDE \u2013<\/strong><\/p>\n

    Of course, you can \u2013 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\u2019t make sense to do so, because you get so much more from the IDE than from a text editor + command-line tools.<\/p>\n

    You may also like the history of java,<\/a> the features of java.<\/a><\/p>\n

    <\/div>