Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Java Programming IT

The Reason For Java's Staying Power: It's Easy To Read 414

jfruh writes: Java made its public debut twenty years ago today, and despite a sometimes bumpy history that features its parent company being absorbed by Oracle, it's still widely used. Mark Reinhold, chief architect for the Oracle's Java platform group, offers one explanation for its continuing popularity: it's easy for humans to understand it at a glance. "It is pretty easy to read Java code and figure out what it means. There aren't a lot of obscure gotchas in the language ... Most of the cost of maintaining any body of code over time is in maintenance, not in initial creation."
This discussion has been archived. No new comments can be posted.

The Reason For Java's Staying Power: It's Easy To Read

Comments Filter:
  • by Anonymous Coward on Thursday May 21, 2015 @07:21AM (#49742655)

    Solving problems can be done quite quickly with Java as a lot of the frameworks/tooling for solving common problems have already been built. Including:

    - Distributed Configuration
    - MapReduce
    - Spark
    - Large portion of the NS math libraries have been ported (think of all the Fortran libraries)
    - Networking
    - Embedded devices
    - First-class support for many app hosts
    - Concurrency libraries (including standard)
    - World-class web application serving (Jersey, DropWizard, etc.)

    These are things that are proven and enterprise ready with large communities supporting them.

    • by Anonymous Brave Guy ( 457657 ) on Thursday May 21, 2015 @09:18AM (#49743315)

      I'd agree with the ecosystem being a huge factor in Java's success.

      More than that, it is a relatively closed ecosystem. Tools like JNI are available, but in practice few projects seem to use them. Mostly, either you're working in JVM world or you're working somewhere else. That's a lot of momentum to overcome for any long-standing project or development team to move to another language, tool chain, standard library, and so on.

      I also think the summary's claim that Java is easy for humans to understand at a glance because of its simplicity is a mischaracterisation. Java is a relatively verbose, inexpressive language, so actually it can take quite a long time to figure out how any given piece of code works. What Java does offer is that an average developer can reliably figure out how any given piece of code works, even if it takes a while. For long-running, large-scale projects that is a valuable attribute for a programming language.

      • by jeremyp ( 130771 ) on Thursday May 21, 2015 @11:11AM (#49744269) Homepage Journal

        Actually, it's easy to read because it is verbose and inexpressive as you put it. Generally speaking, the more information you pack into a sequence of characters, the harder it is to understand. There are also relatively few syntactic constructions to get your head around and tokens are not usually overloaded with different meanings. It doesn't take long to learn the whole language, which means that even a newbie has a good chance of reading a piece of code without coming across something they haven't seen before.

        • There's a sweet spot for conciseness versus verbosity. If something gets overly concise, then what you say is true. However, there's a such thing as too verbose as well, where it's so indirect that it becomes difficult to read.

          Not to mention, Java has a lot of things that are absent from other languages due to being relatively pointless or having better alternatives like public vs private things. On top of that, the fact that Java best practices dictate using getters and setters whenever possible mean lot
  • by Anonymous Coward on Thursday May 21, 2015 @07:22AM (#49742661)

    I am tired of hearing languages are "easy to read". If a piece of code is well written and identifiers are well named anyone who is accustomed to the syntax or syntax that is SIMILAR will be able to read it. The point is that C style syntax have been what the majority of programmers have been used to so it has become a staple. However, if it was down to pure logic and an understanding of the English language Ada, Pascal, and (Visual) Basic would be the most readable.. and who here thinks that -- we've all been brainwashed by CS101.

    • by glennrrr ( 592457 ) on Thursday May 21, 2015 @07:27AM (#49742685)
      Maybe it's improved with the new versions of C++, but I coded in C++ for many years before transitioning to iOS development, and I never wrote my own templated classes, mainly because I would never be able to understand what any kind of semi-complicated template would do. So, I just used STL and Boost, and only with the templates I was comfortable with.
      • Re: (Score:3, Insightful)

        by Anonymous Coward

        The syntax isn't what makes C++ templates hard. They're hard because they're templates.

        However, they're powerful because of it. There's no "generics meta programming" because generics don't offer any sort of comparable power. That said, the reason template meta programming is so useful is because C++ lacks reflection.

    • by jfdavis668 ( 1414919 ) on Thursday May 21, 2015 @07:32AM (#49742709)
      His point is that it doesn't contain strange syntax that isn't easy to follow at first glance. One of the original purposes of Java was to eliminate the complexity of C++ has from its C legacy. When you use a command in Java, it does what its supposed to do. They are not using it as some obscure purpose to take advantage of some quirk in the hardware. Java did this by defining its own hardware of sorts, the JVM. It moves the complexity of the actual system to a group of programmers who specialize in that arena, the JVM developers. It's not that all Java is readable, we maintain one system we inherited that was developed by a poorly trained group of developers. The names of classes provide no help in understanding the code. One of the main classes is "M". They also put things together in classes that have nothing to do with each other. We are re-developing that system from scratch to fix it. Even with this, there are no commands in the system that we don't understand when we read them.
      • Java doesn't have obscure syntax - part of that is the language itself, part of that is the fact that it explicitly doesn't support operator overloading and that prevents people from making incomprehensible DSLs ( Scala's SBT, anyone? )

        On the other hand, in terms of "readable" I still think calling Java readable assumes a familiarity with C style syntax. I think if you took someone that never read or wrote code before and showed them 100 line, idiomatic programs in Java, Javascript, Python, Ruby, PHP, Perl, Lisp, Haskell, C, Fortran, COBOL, Basic, and a few other languages that Java would not top the list for readability. My guess is that the winners would be Basic, COBOL, and Python.

        One of the biggest reasons C++ became popular was that it was a relatively small step away, in terms of syntax, from C. I really think Java became popular mostly because the syntax is a small step away from C++.
        • by fulldecent ( 598482 ) on Thursday May 21, 2015 @09:25AM (#49743389) Homepage

          Yes, and if you gave someone who never read or wrote code before and gave them a printed sheet of Perl... they might wonder if the sheet is upright or upside down.

        • by AuMatar ( 183847 )

          Don't worry- Java people are learning how to make up for that by creating whole incomprehensible sublanguages based on annotation processing that make C macros look good.

        • part of that is the fact that it explicitly doesn't support operator overloading

          I would argue that this creates as many problems as it solves. E.g. when working with BigInteger or BigDecimal, a.multiply(b) is less readable than a*b.

    • by jareth-0205 ( 525594 ) on Thursday May 21, 2015 @07:37AM (#49742735) Homepage

      I am tired of hearing languages are "easy to read". If a piece of code is well written and identifiers are well named anyone who is accustomed to the syntax or syntax that is SIMILAR will be able to read it. The point is that C style syntax have been what the majority of programmers have been used to so it has become a staple. However, if it was down to pure logic and an understanding of the English language Ada, Pascal, and (Visual) Basic would be the most readable.. and who here thinks that -- we've all been brainwashed by CS101.

      Clearly a language can be easy or hard to read - Or do you think well-written Brainfuck is easy to read? Since programs are written by actual flawed humans who make stupid mistakes or have weird style preferences sometimes, it's generally a good idea to have a language syntax that doesn't let them shoot themselves in the foot.

      • by Giant Electronic Bra ( 1229876 ) on Thursday May 21, 2015 @08:54AM (#49743141)

        Right, but I would argue it extends far past easy to read. Java is easy to grasp. It is very clear which method will be invoked when you make a method call. It is very clear what the lifecycle of a memory allocation is and there's no question about who is responsible for managing that chunk of memory, etc. Its just VASTLY easy to code in Java. Now, the development tools/environment may not be as simple as scripting languages, which tends to push untrained 'do-it-yourselfers' into things like PHP where they can see some results on day one, but for the organization which has real business needs and develops code to meet them, Java is an excellent choice because in all respects its clear what things do and how they work. I can look at virtually any piece of decently-written Java code and understand it. At the very least I won't find out that it does something totally different than it appears, which is COMMON in C++.

    • python white space (Score:4, Interesting)

      by goombah99 ( 560566 ) on Thursday May 21, 2015 @09:07AM (#49743219)

      Like most people I thought pythons enforced white space and avoidance of braces and elimination of semicolons was constricting. Then I realized how easy it was to read other people programs. Python used to be even simpler to read when it only provided one idioms for one job (avoiding a dozen way to do the same thing resulting in dialects). Now it's adding new idioms and genres so it's a little more opaque. But it's still easier to read than any language with comparable expressiveness. (Lua is refreshing for similar reasons).

      • Re: (Score:3, Interesting)

        by iwbcman ( 603788 )
        Pythons inane whitespace conventions make it impossible to simply copy and paste python code. Now for a seasoned python programmer this is a nobrainer, but for beginners, people trying to learn python it is critical. I grew up reading computing magazines and typing in code reprinted in the magazines, later I would copy and paste code bits from webpages/blogs etc. in various languages to try to learn how they work. Yet with python this simply does not work until you have already mastered it's conventions, on
    • by Megol ( 3135005 )

      Are you joking? Ada is easy to understand because it was designed to be. It is verbose and partially redundant by design as that is known to 1) increase understanding of programs 2) decreases some types of common errors.
      Pascal wasn't really designed for ease of use (even though it is), one big problem is the use of semicolon as a separator: it isn't always obvious where they should go and misplaced semicolons can generate errors.

    • by Capt.Albatross ( 1301561 ) on Thursday May 21, 2015 @09:45AM (#49743603)

      If a piece of code is well written...

      This is not an article about what is possible, it is about what actually happens. I have seen incredible abuses of operator overloading, for example. I have also seen some highly confused Java, but its pedestrian syntax seems to make it a little harder to write cryptic bad code in.

    • by LWATCDR ( 28044 ) on Thursday May 21, 2015 @10:17AM (#49743855) Homepage Journal

      I disagree that it is because java is easy to read. Java is easy to write. A good programer can write an app in Java and have it work really well. A bad programer can write an app in java it will work.
      With C++ a good programer can write an app and it will work but you really have to watch for a lot of gotchas. A bad programer can not write a program that works in C++ because it will leak memory, stomp on memory, and have issues with pointers.
      Java is better at stopping the little brain farts from blowing up in your face.
      C++ is a lot more fun to write in IMHO.

  • by Jonathan Mann ( 3481921 ) on Thursday May 21, 2015 @07:23AM (#49742665)
    Not as easy to read as Python though
    • Re: (Score:2, Informative)

      Not as easy to read as Python though

      Properly, consistently indented Java is. It's just that python has to be correctly indented to work, which is great, BTW!

    • by gatkinso ( 15975 ) on Thursday May 21, 2015 @07:38AM (#49742743)

      Two words: tabs, spaces.

    • BTW, in case you haven't noticed, Python syntax is similar to Fortran syntax which is among the oldest, if not the oldest programming language still alive.
      • Re: (Score:3, Interesting)

        by TeknoHog ( 164938 )

        BTW, in case you haven't noticed, Python syntax is similar to Fortran syntax which is among the oldest, if not the oldest programming language still alive.

        This. I think Fortran (and now Julia) strikes the best balance [], because it doesn't have the tab/space issue that may produce problems, especially when sharing code. Like Python, it lacks the ugly {} ; punctuations, but it needs something to denote the end of a block, so it uses the English word "end" to keep things simple and clean.

    • by engun ( 1234934 ) on Thursday May 21, 2015 @07:44AM (#49742783)
      Exactly. Having used Java in an enterprise setting for many years, and having had the good fortune to move to Python, I couldn't be happier. I realised how much more verbose Java was than its Python equivalent. Even if you overlook that - there's an inherent structural complexity that Java engenders to its code - one only need look at the Python equivalent to see why. For example, take a look at a basic Hadoop WordCount example here: [] Now compare a rough Python equivalent here: []

      It's not just stuff like the lack of lambdas (it looks like Java 8 has fixed this), or the static typing that contributes to this complexity. I suspect that the culture that has sprung up around Java favours over-architecting and over-engineering, which is exacerbated by its statically typed nature. The Java language itself is simple enough.

      In contrast, there is a cult of simplicity around Python, and the language itself has a high-level of expressivity, allowing for a clearer exposition of one's intent - instead of burying it in layer upon layer of abstraction built to please the language and its type system. C# is a language that fares much better than Java in this regard - it's a lot cleaner. For starters - no type erasure!
    • Except when you are trying to debug code where the indents are mixed with Spaces and Tabs.

      • Re: (Score:3, Insightful)

        I've been programming in Python professionally for something close to a decade now, and in all that time the number of tab/space bugs I've seen in production is: 0.

        Get a good edit -- any good editor -- and worry about problems that actually matter. This one was solved in about 1927.

    • by Marginal Coward ( 3557951 ) on Thursday May 21, 2015 @08:51AM (#49743117)

      I agree: that seems to be the thing that Python does better than any other language, IMO. That also points out a fallacy of the premise in TFS: it doesn't really make sense to attribute the success or failure of a given language to any single factor. Instead, programmers evaluate each on a combination of factors, and each has strengths and weaknesses compared to others. Therefore, each language fits into different areas, and a language thrives and prospers according to how many such areas there are and how important those areas become.

      IIRC, the original strength of Java was supposed to be "write once, run anywhere." I think it was the first language to feature that as the primary selling point, though others have followed. It's surprising that its primary initial selling point would now be eclipsed (tee-hee) by supposedly being "easy to read" - especially since that could be said about several other languages, depending on one's personal preferences in that regard.

  • by Anonymous Coward on Thursday May 21, 2015 @07:23AM (#49742667)

    And that's a good thing.

    • by DickBreath ( 207180 ) on Thursday May 21, 2015 @07:49AM (#49742811) Homepage
      final T up = (T) throwable;
      throw up;
      • If your going to put in that hack, you might as well just include lombok into your annotation processing and just put @SneakyThrows everywhere. If only Java had gone with real generics like c#, we wouldn't have had all these erasure hacks.
      • throw up;

        That one never gets old. My favorite is:

        public void loveYou(long time);

        You can add an extra pun by adding a comment // this function takes a long time.

        • For C users:

          #define while if // makes code faster
          #define struct union // makes data use less memory
    • by asylumx ( 881307 )
      Yes -- You have to be clever about being clever.
    • It is, just as long what you are doing is similar to what everyone else is doing. Sometimes, you may need to break the mold. But that is actually very rare. And you need decades of experience to really know when you really should break the mold.

    • by firewrought ( 36952 ) on Thursday May 21, 2015 @09:45AM (#49743601)

      It's difficult to be "clever" in Java

      To the contrary, Java's lack of expressiveness resulted in people writing tons of external XML files, code generators, DI frameworks, and build tools to glue the whole mess together. Instead of small, judicious bits of cleverness in the main language/runtime, it's been pushed to very clever tools on the periphery that come with relatively large learning curves. That's not really a win from the readability standpoint.

    • It is not difficult to be "clever" at all. Look at various "bean" frameworks. Use their object marshaling features. Throw in some of their aspect-oriented programming features.

      Now you usually have a bloated, incomprehensible mess. Sure you can easily read any couple of lines of code in isolation. But the system as a whole is a huge pile of gratuitous redundant layers of abstraction and confusing action-at-a-distance creepiness.

  • by antiperimetaparalogo ( 4091871 ) on Thursday May 21, 2015 @07:26AM (#49742677)
    Yes, while verbose, i find Java easy to read - and i think its verbosity helps in this (after a while you know what/how to read Java code, and your reading becomes "smooth").
  • by Craig Cruden ( 3592465 ) on Thursday May 21, 2015 @07:27AM (#49742683)
    The popularity of Java is not because of it's "easy to read" nature, but because it is fairly forgiving for programmers that don't really know what they are really doing.

    I programmed in Java for 15+ years and it is not the best language now (more of a legacy language) that tends to get riddled with boilerplate code which requires code generation and produces an outcome that is not as clear and concise as it could be.

    It is however a forgiving language where if you don't understand memory management -- it is not a big problem. For example I remember a system written by programmers in another language that was riddled with memory leaks because of cylindrical references. The code was literally translated into java and all the problems disappeared. The programmers on that project just figured that the language that they programmed in was the problem -- but in reality java saved them from their inability to understand the basics of what they were doing.
    • Re: (Score:3, Funny)

      by Anonymous Coward
      You made me google "cylindrical reference".
    • by invid ( 163714 ) on Thursday May 21, 2015 @07:42AM (#49742771)
      A problem with Java and C# is that it is possible to create memory leaks in those languages, but since people rely so much on garbage collection they don't think about it and get bit in the ass. Event handlers shared across processes are particularly dangerous.
      • You have just described why java has been such a pain in my neck. Otherwise nice looking software that functions until the memory leaks cause it to crash.

        As for c# events, delegates, and event handlers in the msdn documentation is a mess it's not surprising it's a issue. I've read a few of the tutorial and I'm not sure the people writing them even understand what they are doing.

      • Yeah, but they are a class of leaks which are generally not that hard to sort out. Now, I've seen a few ugly leaks in my time that had no really obvious source, but even then it was very easy to determine WHAT was leaking and HOW, even if the exact explanation of WHY was rather obtuse. Your average programmer can understand most of the common cases though, like "gosh I created a static list of unbounded size and put 9 billion object references in it, that won't work!"

    • Hard for me to agree that a language is forgiving when it avoids syntax pitfalls other languages might contain. Forgiving implies it let's things go. In this case, Java by its design and nature, helps avoid problems you would otherwise need to deal with when using another language.
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Hmmm. I enjoy driving my modern car because it has an fuel injection and an engine management CPU. I guess I'm just not a real "driver" because I drive such a forgiving car. If I really knew what I was doing, I would drive a car more like a Ford Model A with a crank start, manual choke, and manual spark advance on the steering column.

      Machines (I'm including computers in this category) that provide useful abstractions that relieve the machine's users from having to be concerned with details of the machine

  • Stability (Score:5, Insightful)

    by Anonymous Coward on Thursday May 21, 2015 @07:29AM (#49742691)

    A huge standard library that has been stable for 20 years (backward compatible as much as humanly possible) has a lot to do with it as well.

    In other languages, I feel like I have to re-learn basic elements every decade to "how it's done now"...

    • Re:Stability (Score:5, Interesting)

      by DickBreath ( 207180 ) on Thursday May 21, 2015 @08:10AM (#49742823) Homepage
      Not only do you have to re-learn basic elements every decade, you might have to rewrite very old code to work on current systems.

      The people who make these incompatible changes vastly underestimate the cost of such incompatibilities.

      The sheer amount of working Java code is not only why the language will stay around for a long time, but economically represents a very large amount of wealth.
    • by drerwk ( 695572 )

      A huge standard library that has been stable for 20 years (backward compatible as much as humanly possible) has a lot to do with it as well.

      In other languages, I feel like I have to re-learn basic elements every decade to "how it's done now"...

      No kidding - especially the socket libraries that let me write network code in the later 90s that would work on Sun, Mac, Windows, and Linux. Getting cross platform network code to work in C at that time was quite painful. And I don't recall any C++ libraries that I found pleasant to use before boost, and now Qt. And even now, while I consider boost essential, it's really only pleasant in the same way as no longer having to get your braces tightened qualifies as pleasant.

  • Verbosity is easy? (Score:4, Insightful)

    by DJ Rubbie ( 621940 ) on Thursday May 21, 2015 @07:30AM (#49742699) Homepage Journal

    Really? Having a pile of needless verbosity makes it more difficult to read in the long run simply because one needs to figure out what exactly is being done even for the most trivial client application. To do even just simple fetch of some resource over HTTP requires rather laborious conversion routine from a stream to a string type before most common JSON libraries would be able to use it. In any more modern language it can simply be used right away rather than having to figure out which JSON libraries to use or why toString() doesn't seem to work on InputStream [] (I mean intuitively shouldn't toString() on a stream get back a string?).

    Granted the Apache commons can make this a bit easier, I find it extremely annoying to have to cast things into the right object type just to access some simple JSON object, instead of just doing something like result['collections']['links'][0] which is much easier to understand. Dumbing things down does not necessary make better programmers.

    • by Anonymous Coward on Thursday May 21, 2015 @07:47AM (#49742801)

      Your mindset is exactly what causes problems with other languages. What you expect isn't readability but a higher power density. If you push this too far, you get too much implicit functionality, and that makes code difficult to read, because you can no longer understand what's going on if you're not familiar with all the idioms.

      There are fundamental differences between a stream and a string (hence the existence of separate classes), so something has to give if you want to use a stream where a string is expected. If you make this implicit, then someone who doesn't know the semantics first has to realize that there is something implicit going on, and probably look up what it is, while in Java the conversion is explicit. Java isn't "surprising".

      • Well, this implicit functionality is rather useful, that is why you see libraries like Apache IOUtils (like IOUtils.reafLine()) that bring some of that magic back. But the fact that you can go to the lower level is a good thing, I just wish the Java designers had these kind of utilities backed into the core of the language.

      • Re: (Score:3, Interesting)

        by bwwatr ( 3520289 )
        I agree with this guy. Java forces you to acknowledge and address subtle differences between different types of objects. Yes, sometimes code is overly verbose, but overly compact code that does a lot of "magic" for you, is far worse. I unfortunately work in PHP a lot, and you can pretty much treat any value as any type and usually get away with it, until you suddenly don't. Strong typing and an IDE that whacks you with a stick every time you forget it, is far preferable, even if your code is a few lines
      • by quietwalker ( 969769 ) <> on Thursday May 21, 2015 @09:52AM (#49743657)


        The whole "convention over configuration" theme is maddening, because if you don't know the conventions - or haven't figured out the new conventions that a particular project uses to drive execution and data flow, you're going to be lost. What is gained in brevity is added cost on the maintenance side. I once spent 2 days helping someone troubleshoot a currency formatting issue on a RoR app; someone had created a mixin to extend a base string class method, in a file describing a service. Fixing the code took all of 5 minutes, but finding it took forever.

        With Java, it's worse now than it used to be. A decade ago, your major threat to readability was someone with pattern prejudice; those who ended up encapsulating everything in a factory-factory to factory to interface to abstract to etc, etc, etc, making every data object change require changes to 5-10 files just to surface the changes to the end methods using it, just for the sake of doing it.

        Today you've got stuff like Spring. Ever try to do a manual, non-runtime code analysis of a project of decent size that heavily uses Spring, even where it's not necessary (like interfaces that will only ever have a single implementation)? Or worse, have you guys seen the OSGi development model? Let me put it this way; imagine using the original J2EE bean model, with home and remote interfaces and all that, only we've decided to use CORBA as our architectural focus. So every method can be a dependency-injected service-provided module, ready for you to call the service factory and grab an instance of the feature you want, which incidentally makes static analysis of code by humans more or less impossible.

        Yes, I understand the concepts for these features, and OSGi actually has some neat capabilities (that we've had since the mid 90's via similarly laborious mechanisms like CORBA or more often, DCOM), but they do detract heavily from both the readability and maintainability of the code. If a new developer can't determine the execution or data flow for a given scenario in a few minutes, it's going to be onerous for them to maintain the system. That pain for the benefit of what we all know is the patent myth of polymorphism; that every project is going to have a need for unplanned sibling code modules in the future - it doesn't seem like a good trade off to me.

        I've started to really appreciate code that I can use tools - often just the 'find in files' feature of an IDE - to trace through execution and data flow. It's becoming less and less common, and sourcing and correcting bugs is taking up more and more of my time because of that rarity. I sometimes look back on 'tricky' C code that uses/abuses pointer arithmetic and requires complex memory management, and I feel wistful for when it was that simple, that you could know what the code was actually doing. .. aww crud. I'm like a few years away from complaining about those darn kids on my lawn, aren't I?

    • by Pastis ( 145655 )

      > I mean intuitively shouldn't toString() on a stream get back a string?

      Yes it should return a String (enforced by polymorphism) but not the String you imply.

      From the API []

      Returns a string representation of the object. In general, the toString method returns a string that "textually represents" this object. The result should be a concise but informative representation that is easy for a person to read.

      So your String should be a description of the InputStream, not its contents.

      For example: "InputStream for URL: []" or whatever satisfies the co

    • Why would you expect toString() to work on a InputStream?

      There is no general safe way to create a String from an InputStream, because mapping from a byte stream(Which is what a InputStream is) to a string is not 1:1.

      That is: The same string can be encoded as different bytes, depending on the encoding such as UTF-8, UTF-16 iso-8859-1).

      The funny thing is that Sun did not think about this when they first created Java, so there are a bunch of deprecated methods which create strings from bytes, trying to guess t

    • Re: (Score:3, Informative)

      by a_claudiu ( 814111 )

      A Stream is not a String. A Stream is a pipe which can serve you bytes as soon as some of them available.
      If the InputStream.toString() will give you the full content of the stream you will have some very nasty errors. Eg. A beginner wants to read a file using a stream and is doing a toString() suddenly all the file will be loaded into memory into a big String eating all the memory. Another beginner listens to a tcp port using a stream does a toString() and suddenly the thread hangs until the client closes

  • by Anonymous Coward

    Java's readability is part of its staying power, which is part of the reason that Java is able to overcome its severe age and lack of features. As a software developer, I spend 90% of my time reading other peoples' code and 10% of the time writing my own. I also need to read code that I read over 6 months go, which I largely won't remember writing.

    This is a major part of the reason why languages such as Scala haven't taken off. Scala, Perl, and other similar languages are largely "write-only" in my opin

    • by DickBreath ( 207180 ) on Thursday May 21, 2015 @08:30AM (#49742953) Homepage
      Readability goes along with 'toolability'. The fact that tools can 'understand' Java code and therefore can correctly make so many kinds of automated changes to the source code is a major sign of readability. If it is not possible to make tools that can do precise and sophisticated manipulations of the source code, then chances are that humans cannot understand it easily.

      As an example of what I mean by 'toolable'. When I rename a variable in Java, every instance of that variable throughout the entire project are changed. This is not a dumb 'search and replace'. It is a precise change made by tools that use most of the Java compiler front end in order to make these changes. Similarly if I rename a method, the change is precisely made throughout the source code. It doesn't matter if there is a variable, or a class or even another method elsewhere with the same name, there can be no possible confusion. Just as the compiler has no confusion about what identifier 'foo' in some line of code refers to, the renaming and refactoring processes are equally precise. That is what is meant by toolable.
  • Just like IE 6 it is so engrained into our business processes that it won't ever leave. At least here in the office which greatly angers web developers greatly, but operations doesn't care.

    Java is around for no technical reasons. It is here because it is already here. Why change for the sake of change and .NET wasn't worth the effort in 2005 as IIS was a steamy piece of poo back then. So now no one wants to take the risk and $$$$ for something that already works. Yes we stayed on XP too until 2014 but my em

  • by gatkinso ( 15975 ) on Thursday May 21, 2015 @07:37AM (#49742731)

    That's what I thought.

    It was purely serendipity, and now the install base is so large you can;t get rid of it.

    • by Greyfox ( 87712 )
      Well if there's one thing programmers hate more than unreadable code, it's typing shit, and COBOL was an awful lot of typing shit. And for some reason, even though the individual lines were easy enough to read, something about the language made it very difficult to follow overall. Since the language was so overly verbose, functions usually ended up being pretty long, and it was very easy to get lost in them, in any COBOL code I was exposed to anyway. I'm sure there was probably some clean, well written COBO
    • Serendipity could also mean that it was in the right place, at the right time, and that is why the base of code written in Java become so huge. It solved a problem. And did so better than other solutions at the time. And arguably, still does.

      Other solutions may look sexy. And for smaller projects, they probably are.

      But long term maintainability is important. Does your project still need to work in ten years? Twenty?

      Having a compiler is also probably a major factor to Java success. If I make
      • by gatkinso ( 15975 )

        the occurrence and development of events by chance in a happy or beneficial way.

    • COBOL was relatively readable when it was invented, compared to the other languages of the time. The purpose was to be so readable that even managers could understand it

      Well written COBOL is understandable. The biggest complaint is that it's overly verbose (other problems like "no re-entrant functions" aren't problems anymore). In many ways Java seems like a modern version of COBOL.
  • I could sure do without the { }.

    • Would you rather have begin/nigeb or something dumb like that?

      • What exactly makes curly brackets inherently not dumb? They are non-indicative and typing them on many keyboard layouts that are not en-US is quite uncomfortable.

  • Easy to read? (Score:3, Informative)

    by AchilleTalon ( 540925 ) on Thursday May 21, 2015 @07:47AM (#49742797) Homepage
    Almost all programming languages are easy to read. This is not the reason of Java's success at all. A complicate algorithm in first place will not make a program easy to read whatever the language you pick to program it. If you find Java easy to read, it is only because you cope with trivial algorithms.
  • You must be joking (Score:3, Insightful)

    by joseph90 ( 193138 ) on Thursday May 21, 2015 @08:20AM (#49742873) Homepage

    I am sorry but can I just say:

      BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(;
      input = bufferedReader.readLine();
      number = Integer.parseInt(input);

    In Pascal (1960's) you could just do something like:
    integer number;

    See if the compiler knows number is an integer do I really have to tell it to create a stream and parse it as an int? seriously?
    Java is an abomination.

    • by Anonymous Coward on Thursday May 21, 2015 @08:46AM (#49743067)

      I think you prove the author's point. Where the fuck is your pascal snippet reading from? How does it abstract bytes to characters? Why is there only an input with no output? Is `read` taking an integer and doing something with it? How is data getting out? In the java snippet, everything is laid out. You're reading from standard in. You're line buffering (with default encoding, but that's fine when reading from STDIN and not a file. Usually). You're reading exactly 1 line, then parsing that line for an int value. It's extremely explicit what's going on and has no magic. The whole passing in an outvalue thing that C and Pascal do is an AWFUL KLUDGE OF A DESIGN. It makes code harder to read and harder to understand.

    • int number = Integer.parseInt(;

  • by Anonymous Coward

    Libraries tools and 3rd party support in the form of books, articles developer know how, WORA, etc. It's very very fast no matter what people around in the 90s may still think, it has an unbelievable number of extremely high quality, battle proven open source libraries for highly specialized and useful functions and of course the tools supporting it like IDEs are out this world good. So I can do anything I want, I can run in most anywhere, I have vast libraries at my disposal and best in class documentatio

  • Most of the cost of maintaining any body of code over time is in maintenance ...

  • "the cost of maintaining any body of code over time is in maintenance"

    No, really? The cost of maintaining is in maintenance? Well, now that's some earth shattering surprise.

    Anyway, the intention was probably to say that maintaining is more costly than creating. However, since it says "any body of code" I'll just call it the deepest bullcrap. I've seen and heard lots of people talking out of their behinds over the years dismissing the effort going into creating some really nice algorithms and realizing t
    • No, really? The cost of maintaining is in maintenance? Well, now that's some earth shattering surprise.

      I thought the same thing when I first read that, but then again we're talking about an architect for the language that brought us "Foo foo = new Foo();" so a bit of redundancy is to be expected ;)

  • Yes, Java is pretty easy to read. It contains all the standard control structures, and not a lot more. Aside from inheritance (which, by now, pretty much all developers understand), there isn't a lot of hidden functionality: See the code, understand what it does.

    This is one reason that I object to the introduction of Lambda's in Java 8. Lambdas belong in functional languages, where they make sense in the context of the language. Java is not functional, so lambdas break the paradigm. Moreover, they are unfamiliar to most developers, and they are cryptic in a way that hides functionality.

  • Dumb Slashdotters (Score:4, Insightful)

    by bigsexyjoe ( 581721 ) on Thursday May 21, 2015 @09:38AM (#49743501)

    This is an article about why Java has decent staying power, not about why it is the perfect language, nor most readable language possible. The article does not say people will be using Java in 1,0000 years. But Java became popular and continues to have strong staying power for an old language. There are reasons for that, even if it isn't your cup of tea.

  • by theendlessnow ( 516149 ) * on Thursday May 21, 2015 @09:45AM (#49743593)
    What makes "Java" or anything object oriented difficult to read is that objects tend to produce more spaghetti code and have a ton of easily overlooked side effects. Debugging can be a nightmare. I see more "pitch till you win" code maintainers.... so much so, that some consider it normal to just keep trying stuff until it "works". I'm not saying you can't create "good" object oriented code.... I just haven't seen any yet.
  • by ThePhilips ( 752041 ) on Thursday May 21, 2015 @09:53AM (#49743671) Homepage Journal

    It is pretty easy to read Java code and figure out what it means.

    Many who deal with the "enterprise" software would simply laugh at the statement.

    But hey, the same argument was often made about the BASIC. And I always said that Java and BASIC users are very similar.

  • by msobkow ( 48369 ) on Thursday May 21, 2015 @10:17AM (#49743843) Homepage Journal

    What amuses me is that many people rave on about how great C# is, while denouncing Java. Yet other than a few minor syntax tweaks (like the way you write getters/setters and the "?" indicator for nullable attributes), they are virtually identical right down to the API.

    They're both very easy to read and code with, and if you know the packages/libraries of one you'll find the equivalent in the other in short order, with very, very few differences in the details of the APIs.

    Yet C# is "great" and Java "sucks".

    Go figure.

  • by NynexNinja ( 379583 ) on Thursday May 21, 2015 @11:15AM (#49744293)
    I guess we're not talking about working with Java Struts. When you do, turn on mysql logging, and then tail -f mysqld.log, you'll see garbage like this: select column_623 from table_943 where column_142='xxx'; ---- is that readable to you? Is that supposed to improve readability by abstracting so far away from the database that no one can understand what is going. I basically have to grep for values inserted or updated or selected from tables in order to figure out what table stuff is being written to. It's not ugly, its an abomination. Who ever thought up the idea doesnt know what they are doing. Easy to read..... YEAH RIGHT -- its a joke. It takes 5 times longer to reverse engineer this spaghetti mess than any other languages. Straight Java code is easy to read, if you don't intrude abstraction layers on top of the language, like Struts.

Going the speed of light is bad for your age.