Why & How I Write Java

A few weeks ago I posted a software developer’s reading list. An important criterion for this list was technology independence because most software development skills transcend whatever tools we are currently using. That being said, our choice of tools is quite important. This article explains why I currently build software using Java (and its platform). I also describe how I write Java: techniques, conventions, and practices.

I’m no Java evangelist. I am frustrated by the gap between established languages and what I believe our profession is capable of designing. (One cause is the momentum of standards which makes them expensive to replace.) For me the goal of software development is to evolve valuable software with a team. I think Java, with its platform & ecosystem, is currently the best tool to support this multi-faceted goal. (This applies to general application programming, not to programming requiring the ability to explicitly manage memory.)

I recognize that using Java isn’t an interesting or exhilarating choice. I am going to be posting some open-source Java code, and I think it is useful and perhaps helpful to present the rationale for why I choose to use Java professionally. Also my perspective is informed and biased by my background, which is 7+ years of delivering web applications and services, starting with Python + JavaScript and then shifting towards Java. The right decision for my needs may not be the right one for yours.

Related Article: Teach yourself programming in 10 years

Why I Write Java

I use Java for general application programming. I recommend Python or Ruby for learning programming. I don’t know what to use for programming requiring the ability to explicitly manage memory (i.e. C, C++, D, Rust).

Benefits of Java

  • Platform Maturity: Java is stable and it’s about as fast as you’re going to get with garbage collection. It is depended on by huge companies. I want to spend time evolving valuable software, not fighting with semi-mature tools. (Examples of being forced to switch back to Java include Twitter and Yammer. Notice the dates on these, because issues do get ironed out.)
  • Statically Typed: I’ve used Python professionally for 7+ years. It is a wonderful language that has taught me a lot. However I am convinced that static typing is a profoundly valuable tool for software development. Reasons include:
    1. Contextual Documentation: With static typing I always know the types for inputs and outputs. I know exactly what I have to provide as input, and I know the attributes available on the output. This makes it a little easier to work with code I remember, considerably easier to work with code I can’t remember, and a ton easier to work with code I’ve never seen before (i.e. learning the AWS SDK for the first time).
    2. Explicit Interfaces: Object-Oriented Component Design is about managing interfaces. With explicit interfaces I can more easily focus on interface design without worrying about the implementation details (classes). When I do get to implementing a class, I can declare what interfaces it is supposed to implement, as well as the interfaces of the dependencies. These declarations are great documentation and are used by tool support to help me.
    3. Tool Support in an IDE: Tool support makes programming easier so I can focus more on higher level issues. Examples of how it helps include:
      • When an interface changes, the out-of-sync clients and implementations go red.
      • I have confidence that the automated rename refactoring works. If it doesn’t work, I expect something to go red.
      • If I want to implement an interface, I can auto generate a class with all the stub methods. Then I can write fields on the class and auto generate a matching constructor. (This last part sounds possible with dynamic typing + conventions.)
      • I can call a non-existing method on an object and the call goes red. Then I auto generate a corresponding method on that object’s interface. Then that object’s class goes red because it doesn’t implement that method yet. Then I auto generate a corresponding method stub on the class.
    4. Prevent Type Errors: With static typing I discover type errors instantly instead of finding them when running tests, or even later if I don’t have perfect test coverage. I find rapid prototyping to be a easier when I have static types to lean on. When I was switching from Python to Java, I found I could throw together working code faster with Java, despite Java’s annoying verbosity and despite knowing Python much better.
  • Write Once, Run Most Places: With Java I have one language that can target servers, Android, and browsers via Google Web Toolkit (GWT). Commenters have suggested that J2ObjC and RoboVM can help reach iOS. If you need explicit memory management, then you’ll unfortunately need a different language. I believe that fragmenting a team’s codebase into multiple languages introduces a tremendous amount of accidental complexity and redundancy. I think the non-linear costs significantly outweigh the relative advantages of various languages. Complexity is the enemy, and unnecessary variation is a significant cause of complexity. (For an alternative perspective, look into polyglot programming: a website, a thesis.)
  • Libraries: Java has libraries for what you need, and those libraries are often pretty good. In my experience I have found Java libraries to be more solid on average than in Python or JavaScript. Often Java will have reference/official clients for stuff like AWSAMQP, Thrift, etc.
  • Dependency Packaging: I really like being able to package all the dependencies into a JAR or WAR file for deployment. Other languages obviously have solutions to this, but I’ve found Java’s solutions to be at least easier than Python’s virtualenv.

For an alternate perspective, Michael O. Church wrote a nice 2010 essay about the benefits of static typing. In 2013 he wrote an article about why he has softened his static typing stance and has found Clojure to be great.

Problems with Java

The cons are mostly language design issues:

  • Insufficient Type Inference: This is inane. Java 7’s diamond operator helps some, and Guava Collections Utilities provided some of its benefits for Java 6 (using existing inference for generic methods). There are other problems with the type system, most notable being the inclusion of null (Guava’s Optional helps with this).
  • Only One Superclass/Mixin/Trait: Implementation inheritance causes problems. Multiple implementation inheritance causes even more. I prefer to instead use composition when possible. However without syntactic support to delegate to nested objects, you do want multiple mixins sometimes.
  • Verbose Lambda Syntax: Java 8’s lambda should fix this.
  • No Get/Set Properties: I want to be able to use “x.y” and “z = x.y” while preserving uniform access. This is available in at least C#, Python, and Ruby.
  • XML Configuration: I prefer to use code files for configuration. If it must be a separate language, then YAML would be better. Of course XML isn’t inherently part of Java, but it is used by the community in practice. (For example, I have to wrestle with Maven XML files.) (These comments say the community is trending towards less XML: comment 1, comment 2, comment 3.)
  • C Style Syntax: I prefer significant whitespace, like Python. This is just a personal preference.
  • CamelCase: I prefer snake_case, because _ reads more like a space, which is how we usually separate words. This is just a personal preference. (I think the best choice would be to do auto conversion between snake case and camel case based upon the programmer’s preferences and needs. It could then be an IDE setting for how to render the code. You’d have to force CamelCase and snake_case to be mutually exclusive, so this is probably only possible for a new language.)
  • … I’m sure this list could be arbitrarily long, but you get the idea …

For more discussion about pros and cons, here are a couple articles/discussions about Why Java Is Great and Why Java Sucks. Also it’s often wise to listen to an oldneckbeard.

Why I Don’t Use <other language>

Here are a few reasons why I currently choose Java over other languages, in addition to the fact that many of them can’t target browsers. (I include these notes in order to explain my thought process, as I would to a friend. Please don’t beat me up over it. Describing a language in a sentence or two is absurdly inadequate. I’m just trying to convey a brief sense of my current general conclusions, in case it is helpful. I could, and maybe should write a post about what excites me about many of these languages.)

  • C#: I don’t use C# because I’m not interested in Microsoft’s ecosystem. But if you are, C# seems like a good alternative to Java. C# was originally Microsoft’s answer to Java. In some areas it has more gained more advanced features (comparison of features). I particularly like LINQ. I think it’s cool that they hired Haskell folks like Eric Meijer and SPJ.
  • Scala: Scala is probably the language with the closest design to what I’d want. Building on the JVM puts it on the “fast” track to maturity, but I don’t feel like it is there yet. Here is a dialogue about issues that might arise in practice. (Comments about Scala’s current maturity: slidescomment 1, comment 2, at Netflix, at Coursera.)
  • Clojure: Clojure is innovative, but it is dynamically typed. I don’t know about the maturity of the platform, ecosystem, and libraries, but here is are some comments: comment 1, comment 2. Clojure’s explanation of state and mutation is great. The language seems particularly innovative in the area of modeling shared memory. Rich Hickey has given some great presentations. ClojureScript is of course interesting to me. In my heart I feel that Lisp syntax hinders readability and macros are too fancy, but having read amazing Lisp books, I wonder if I’m a bit ignorant to believe that.
  • Python: Dynamically typed. Platform and libraries are less mature than Java.
  • Ruby: Dynamically typed. Platform and libraries are less mature than Java.
  • Perl: Dynamically typed and worse design than Python and Ruby. (Of course worse than the best does not mean bad. Like many people, Perl was my first scripting language, and it really opened my eyes. I would be worse at writing Java if I hadn’t experienced Perl and Python.)
  • PHP: Dynamically typed and worse design than Python and Ruby. (I think software is valuable if it is used, and by this metric PHP has been very valuable. It isn’t the best for my needs though.)
  • JavaScript: Dynamically typed and worse design than Python and Ruby. (Brendan Eich’s interview in Coders at Work provides great context. Given the constraints, I am thankful that he did such a good job.) Regardless, it runs in the browser. If I had to write JavaScript instead of compiling to it, I would consider using a pre-processor like CoffeeScript. There is a certain logic to attempting server side JavaScript, but this makes me sad.
  • Dart: Not mature enough. Like TypeScript its goals and corporate backing make it interesting to watch.
  • TypeScript: Not mature enough. Like Dart its goals and corporate backing make it interesting to watch.
  • Go: I’ve only looked at the docs. The ecosystem maturity is my primary concern, but like Dart and TypeScript, it is interesting to watch.
  • Haskell: Insufficient adoption and difficult to work with. Real World Haskell is worth reading, but I don’t find Haskell code particularly readable. Haskell does not appeal to me as a software developer who loathes “tricky” code. (These are just my impressions, don’t take my word for it.) That being said, Haskell is motivated by numerous unassailable insights and benefits. Languages should make immutable the default and should strongly encourage (but not require) writing wide swaths of referentially transparent pure code. You can and should blend FP with your OO design
  • F#: Other than the idea (FP on .NET), I don’t know much about it in practice. Here is someone’s comment.
  • Groovy: Other than the idea (scripting on JVM), I don’t know much about it in practice.
  • Objective-C: Haven’t looked into it much, but I will when I write software for iOS.
  • Other Languages: There are many languages with communities that are too small for me to be comfortable using them on professional projects: OCaml, ML, Common Lisp, Scheme, Smalltalk, etc. Obviously not everyone shares this opinion. Also, how will a community get bigger unless someone is willing to be the tip of the spear?
  • Programming with explicit memory management: This bucket includes C, C++, Rust, D, etc. I haven’t needed to explicitly manage memory, so I haven’t used these professionally. (Other than C, C++ and assembly as a student and a teaching assistant.)

How I Write Java

One of the concepts on my software developer’s reading list is Code Design: Writing intention revealing code. My starting point for how to write clean Java is two excellent books: Clean Code and Effective Java (2nd edition).

In addition to the material in these books, here are other practices I follow when writing Java…

Dependency Inversion & Type Naming Conventions

Dependency Inversion means having your dependencies provided to you, rather than statically importing them or building them yourself. This increases modularity and is important for testing. Ideally you statically import (depend on) interfaces, not classes or singletons. I think this is why the first suggestion in Effective Java is to use static factory methods. Here is an example of the organization and naming I use to follow this advice:

  • Employee (public interface): The employee interface. I prefer this over the IEmployee convention.
  • EmployeeClass (package visibility class): The employee class. (The implementation.) I prefer this over the EmployeeImpl convention.
  • EmployeeLib (public abstract class): The library for creating instances of Employee. I prefer this over the plural Employees convention, but not by much. This library contains the static factory methods, as well as other related miscellaneous functionality. If there are multiple factory methods, only one uses “new”, and the others delegate to it. I prefer having a separate file for the EmployeeClass rather than nesting it inside the EmployeeLib.
  • PersonMixin (public abstract class): A shared superclass. Even though I prefer composition over inheritance, implementation inheritance is useful for quick behavior reuse or implementing the Template Method Pattern.

If you strictly follow these conventions you will never have the words “public class” in your codebase (be pragmatic though). Notice that if a CompanyClass statically imports EmployeeLib to create an Employee instance, then that isn’t quite dependency inverted yet. This instance isn’t provided, it is retrieved. However it would be easy to invert this dependency by instead passing an Employee instance or Employee factory into the CompanyClass constructor (or using some other form of Dependency Injection).

Here’s a related Google Presentation: Don’t Look for Things.

Other Practices I Follow When Writing Java

Following a company or team standard is actually more important than what exact standards you choose to follow. Without shared standards you introduce unnecessary variation (complexity) into the codebase. Here are some of my current practices:

  • Use Google Guava as a Java extension (user guidephilosophy, compared to Apache commons).
  • Use jUnit for unit tests, using annotations and using the assertThat() syntax with Hamcrest matchersTestNG seems to be a popular alternative to jUnit (list of frameworks).
  • Use Mockito for mocking (but I prefer to use fakes when possible).
  • Use Maven for building. I find it difficult to use at times but it is the standard. I put a lot of links into my pom.xml files because because I find POM to be a collection of magical incantations (here’s an example) .
  • I use Eclipse as an IDE, but I don’t know enough about the alternatives to make a recommendation. I use Google’s Eclipse plugin for GWT. IntelliJ IDEA appears to be a well liked alternative to Eclipse. (I’ve definitely noticed an enthusiasm gap between Eclipse and IntelliJ in favor of IntelliJ. I haven’t tried it yet though.)
  • Use Google’s Eclipse Java Formatter to follow Google’s Style Guide. (discussion)
  • Have the IDE require @Override annotations.
  • Use Guava’s Optional to avoid using null (Sir Tony Hoare’s billion dollar mistake).
  • Make objects immutable by default. Guava’s immutable collections help. If an immutable object hashes based on state instead of memory address, then it is called a value object. Among other benefits, immutable objects remove an entire category of bugs and complexity.
  • I wish “final” was the default so you’d have to mark variables as “mutable”. But should we use final for all immutable variables? (Which is most of them for me.) This is a decision of communication and enforcement vs. cluttering the code. For class fields, I think using final is definitely worth it because any method on the class could potentially mutate a field. For method inputs and local variables, I don’t think writing final is necessary. Writing final for these local variables doesn’t seem to be a favorable tradeoff because my methods tend to be short.
  • Try to write referentially transparent functions. These functions don’t have side effects and their output is simply a function of input, not when the function was called. In functional languages like Haskell this kind of pure code is the default. In Java it is not the default, but it should be our default in practice. Among other benefits, referentially transparent code removes an entire category of bugs and complexity.
  • Prefer composition over implementation inheritance. I think this is a general consensus.
  • Keep things small: methods, classes, and directories.
  • Keep the numerous component design principles in mind.
  • Try to apply modifiers in this order: public protected private abstract static final strictfp (discussion 1discussion 2)
  • Never have public instance fields (always use getters/setters).
  • Use java.util.Objects.requireNonNull to defensively receive input. Guava has other preconditions.
  • Use Guava’s toStringHelper for implementing toString() and java.util.Object.hash() for implementing hashCode()
  • Avoid accidental ordering by preferring Set and Map over List. This removes a class of ordering/duplication bugs. There is a (small?) performance tradeoff, but most code isn’t in a bottleneck. (Here’s a discussion about this.)
  • Pragmatically adapt to context instead of dogmatically adhering to context-free rules such as these.
About these ads

63 thoughts on “Why & How I Write Java

    1. Steve Wedig Post author

      Sort of. I’d prefer to focus my creativity on building awesome products and services rather than struggling to get semi-mature tools to work.

      Reply
      1. Craig van Nieuwkerk

        This is actually a good answer. I am a .NET C# developer myself but what I love is building products. The actual code behind it is interesting and fun to do, but it’s all about the product. Would I rather have a user say I made a fantastic product or another developer say I wrote a fantastic bit of code? Definitely the user compliment, whereas I suspect many developers are the opposite.

        Reply
      2. Mite Mitreski (@mitemitreski)

        Great post Steve, I was planning to write one like this for a long time. I agree with you on most of the topics.
        I do like to play around with various languages/tools/frameworks for smaller project but reality is that I do prefer Java for most of the stuff for the same reasons you have listed.

        Reply
      3. Steve

        You might want to say the products and services … for now. The 3 main areas available for product services in Java right now primarily include Android (Mobile), Amazon (Cloud), Web, and the area that Java is the strongest at for the time being Enterprise (I’m throwing a lot in this bucket because it is what they are first and foremost). But remember that Android is having fragmentation issues and trying to solve them moving forward for being able to move to later versions of Java (while C# has presence on iOS, Android, and not mentioning Windows because it’s a on the bad bad MS ecosystem), Amazon is a great platform but with people trying to come up with solutions to the C10K problem as in this solution (http://raygun.io/blog/2014/02/why-the-raygun-api-now-runs-on-node-js/) and Java is still 80% reliant on Tomcat as it’s main container. Which then brings me to enterprise… most java developers I find using tools from 10 years to solve problems when new technologies, while not currently mature, are gaining ground on the problems that have been created because. I think the boring comment is a little misplaced but I do think saying getting into Java now is like saying getting into COBOL 10 years ago. Saying you’re getting more into the JVM is like getting into Linux 10 years ago.

        Reply
        1. Edmond

          I am afraid you are conflating hype for progress. Yes there are a ton of new stuff coming out constantly but it would be a mistake to conclude that this means a proven platform such as Java is somehow being left behind.

          I have sampled a number of the hot-babes (RoR, Django..etc) of recent years in the realm of web development and they always leave me scratching my head because I see nothing inherently interesting about their technology and often a lot to be concerned about.

          The JVM is now being recognized as the sensible middle-ware over which to build newer technology, this can be seen from the current trend of porting a number of languages to the JVM (JS, Ruby, Clojure, Python…etc).

          Granted the competition from the newer platforms is good for the Java ecosystem, it forces innovation and pressures the Java platform to address legitimate shortcomings. But it would be a mistake for the Java platform to be reactive to fad based platforms.

          Whenever I am confronted by JVM detractors my usual response regarding the merit of the JVM is this: there is a reason there’s jvm on the server, desktop, on your phone, on the rovers on mars and god knows on how many mission critical systems.

          And no it isn’t because of clever marketing, which is another common and silly response from JVM detractors.

          The JVM is an impressive engineering effort and the eco-system spawned by it is currently unrivaled.

          Reply
    2. Justin N.

      Putting aside the sadly immature, uninformed response to a wonderfully written piece about Java, Steve is considerably practical. Personally I have fought with many dynamic compiled and dynamic interpreted languages and I usually end up hating them because I’d rather know as I’m coding that it will work as I expect and not get bombarded with typo issues, missing reference issues, etc. Simply, a statically-typed language supports rigor and in the mature world of programming, this is essential.

      It’s sad to see that teenagers and early-20-somethings aren’t taught better in schools to provide insight and critical thought to these kinds of programming issues instead of glossing over the article and accusing the author as “boring” as if somehow that’s a bad thing when dealing with enterprise-level, multi-tiered, highly available/reliable systems.

      Reply
  1. Rudolf Olah

    Reblogged this on NeverFriday and commented:
    Interesting read, somehow I can’t handle too much Java, I always get tripped up by the primitiveness of it (even when using an IDE like Intellij IDEA which I own a license for). Copying JAR files around or making sure that the XML config files are written correctly is something I can’t wrap my head around. Java itself is okay, the stuff around getting an app or servlet to run isn’t fun to deal with. I find Python + pip + virtualenv, Ruby and its gems and NodeJS with NPM to be a breeze (as a counter-example).

    Reply
    1. Steve Wedig Post author

      Thank for the reblog and the feedback Rudolf. There are a lot of frustrating parts of Java. XML configuration is one we definitely agree on. I’ve found JARs to be easier for deployment than Python virtualenv’s.

      Reply
  2. Java person

    > Instead of .getX() and .setX(x), I just write .x() and .x(x).

    This is the most surprising thing here. How does every piece of code on the planet that expects JavaBean standards deal with not using this convention?

    Reply
    1. Steve Wedig Post author

      That is a good point. I have run into this problem when it is a convention, for example with StringTemplate. However I really find the verbosity of get and set prefixes to hinder readability. I’ll just take this one off the list because it may be bad advice in practice.

      Reply
  3. Mike Hernandez

    What are your thoughts on java programming certification? I tend to think that programming certs are of little value when compared to real world experience but I’m curious as to your stance, specifically regarding Java.

    Reply
    1. Steve Wedig Post author

      I’m not qualified to say, since I haven’t had any experience with them. I imagine I would be more interested in what someone has actually built, but I really don’t know.

      Reply
    2. Hannah

      I think you should get one if you don’t have a lot of experience or if you have some free time. A 7-year experienced person might not be able to score more than 80% in those tests in the 1st try.

      Reply
  4. aQu

    Very interesting read. I’m sure we could go hours debating about some of the points in the article, but i believe you were very objective in most of the points. So I’m particularly interested in picking your brain on your work environment. You specified some good practices specifically for Java, but I’m wondering if you use tools for proprietary issue tracker , continuous integration, continuous code quality management, and any special, and if you use any particular protocol for software versioning and revision control.

    Also, how much have you been affected (and your co-workers) about the particular change on naming conventions.

    Reply
  5. niktheheratik

    I dislike Java as it seems to me to have the worst of both worlds: you have to wait on the compiler to see your results and yet you aren’t talking directly to the system so you only have the APIs available that are available through the Virtual Machine. Though Dalvik is probably a notable exception to this rule.

    Granted, my most recent experience with it is at least a decade old, but the verbose naming conventions and JSP really turned me off of the language. Objective C is definitely worth trying, though it has its own naming convention quirks, and I’ve enjoyed picking up Python this last year after a brief experience in a University course. It makes it much easier to write clean code than PHP though less useful for cases where you just need to write a script to chomp through some data. Not that I’ve had to do that so much lately.

    Reply
  6. Steve Perkins (@stevedperkins)

    > “Despite believing everything should be immutable by default, I don’t use ‘final’
    > everywhere. I think it clutters the code.”

    Wat?

    > “I wish ‘final’ was the default so you’d have to mark variables as ‘mutable’.”

    In other words, it’s such a great practice that you believe it should be the default. (I agree) But it’s one extra keyword, so you don’t use it. (Wat?)

    Reply
    1. Steve Wedig Post author

      Thanks for the feedback. One extra keyword for most variables in a codebase feels like a lot of clutter to me. Especially when I’m used to Python!

      Based on your feedback and someone’s comment on Reddit, I’ve updated my thinking, which I include here:
      I wish “final” was the default so you’d have to mark variables as “mutable”. Should we use final for all immutable variables? (Which is most of them for me.) This is a decision of communication and enforcement vs. cluttering the code. For class fields, I think using final is clear win, because any method on the class could potentially mutate them. For method inputs and local variables, I am unsure. Since my methods tend to be short, this may not present a favorable tradeoff.

      Reply
      1. Steve Perkins (@stevedperkins)

        Scala approaches this by using the “val” keyword to declare a new variable as immutable, and the “var” keyword to declare a new variable as mutable. Use of “val” is strongly encouraged, unless you have a specific reason to use “var” instead.

        After exploring Scala for awhile, I started understanding what a good practice immutability is in general. I shifted over to using “final” whenever possible in my Java code as well. Immutability reduces a lot of risk when you write multi-threaded code, and it makes a functional style of programming much tighter as well. Neither Java nor Python are known for heavy use of a functional style, but this will certainly change (for better or for worse) when Java 8 comes out!

        Anyhoo, I didn’t mean to be rude. But Java is definitely a much more “verbose” language than Phython, Ruby, etc… and as you get deeper into it, you just have to make peace with that. Having worked with Java as my primary language for about 15 years, it feels natural to me… so I tend to guffaw at lot of complaints from other communities (e.g. “You have to end statements with a semicolon? Oh, the horror!”). :)

        Reply
        1. Steve Wedig Post author

          It sounds like we’re on the same page. One of my next posts is actually going to be about immutable value objects. Thanks again for making me rethink my practice for “final”. I changed a small project to use final for all the class fields, and it is definitely more readable when you can easily see which fields are mutable, if any.

          Reply
  7. Matt

    Someone said that writing this post made you boring. I don’t disagree, I’d even say you are boring and lazy.
    Not lazy in the sense you don’t like to work, I’d say lazy in the sense you don’t want to go out of what you’re used to. This is a natural human process to stay where we are kind of comfortable. That’s why it takes an unusual amount of effort to really shift your focus on something new. And shifting your focus on at least one completely different language than Java would make you look at life differently.
    You are missing out man.

    Reply
    1. Steve Wedig Post author

      I am actually more comfortable with Python than Java.

      I appreciate your feedback, but I don’t think it applies to me. An earlier revision of this post included my background, because I am both informed and biased by on it. I figured people weren’t interested, so I took it out. The basic gist was that I’ve primarily used Python, JavaScript and Java professionally. I’ve built small apps with C#, PHP and Perl. In undergrad I learned C, C++, and assembly. In grad school I was a teaching assistant for C++, assembly, Lisp for AI, and SQL for DB. As an aspiring programming language designer I’ve read books on Ruby, Haskell, Erlang, Clojure, Scala, Common Lisp, Scheme and Smalltalk.

      Reply
      1. matthieus

        You see me corrected and surprised. I felt your dismissal of other languages and environments was a bit light. I also have a background in Java and recognised a point of view that I once had.
        I don’t have your impressive background though, so I will apologise.

        Reply
        1. Steve Wedig Post author

          No worries. We all have a necessarily myopic viewpoint until trying a variety of other languages. I think it is helpful to point this out, which I why I try to link to Peter Norvig’s article as much as possible:
          http://norvig.com/21-days.html

          I also agree that describing a language with one sentence is terribly lacking in detail. I’ll make a note of this.

          Reply
    2. Hannah

      He’s not “lazy” Matt. He already shifted from Python to Java. Give him some time and he’ll shift from Java to something else :)

      Reply
    1. Steve Wedig Post author

      I’ve definitely noticed an enthusiasm gap between Eclipse and Intellij in favor of Intellij. I haven’t been able to try Intellij yet though.

      Reply
  8. Yulian Kuncheff (@Daegalus)

    Great post. While I agree with most of what you said, I am more into learning all the new stuff and keeping up with it (you seem to also since you make a pretty informed opinion.) Though I have mostly switched to Scala, there are a few pain points, primarily with SBT, that is easily fixed by using Maven or Gradle instead. I am also a huge proponent of Dart.

    Like you said, I feel Scala is the closest to what I want. and with ScalaJS. I feel like I can accomplish a lot with it. I just wish the java ecosystem felt more lightweight. But thats probably a personal opinion.

    Reply
    1. Steve Wedig Post author

      Thanks Yulian. Between ScalaJS, Clojurescript, Dart, and Typescript, I can’t imagine I’ll be writing Java 5 years from now. The sooner they reach “maturity” the better for all of us! I wish I could be more confident being an early adopter in a professional context.

      Reply
  9. Jared

    Correction: D is GC’d and Rust has “optional” GC. Sure, they still have true pointers, but don’t require explicit memory management.

    Reply
    1. Steve Wedig Post author

      Thanks for pointing this out. My phrasing was ambiguous. What I meant was “projects requiring the ability to manage memory”, not that memory management is required by D. I’ve improved the phrasing.

      Reply
    1. Steve Wedig Post author

      I don’t know. I stopped using web frameworks after we evolved away from Django. I know the Play framework is along the same lines as Rails and Django for Java. I was using Struts for a Java webapp in 2002, but I would be amazed if that is still popular.

      If you are ok with separate tools, Java certainly has mature ORM’s, templating engines, and web containers. There are advantages to decoupling much of your code from any particular framework. I link to a Bob Martin presentation and provide a few notes here:
      http://stevewedig.com/2014/02/03/software-developers-reading-list/#domain-design

      Reply
  10. Tirthal

    Interesting read, but different programming languages bring different strengths. Both Oracle (formerly Sun) and Microsoft has officially started to support widely used languages (such as JavaScript, Ruby, Groovy, Python, F#, Scala and more) on their runtimes. With respect to Java platform – Java 6 added specification for supporting multiple scripting languages in JSR 223. JSR 292 in JDK 7 is focused to enable developers of compilers for dynamically typed languages to generate bytecode that runs extremely fast in the JVM. Also from JBoss community, TorqueBox project is a new kind of Ruby application platform that supports popular technologies such as Ruby on Rails and Sinatra, while extending the footprint of Ruby applications to include built-in support for services such as messaging, scheduling, caching, and daemons.

    I would say – it has been became common to consider polyglot programming in enterprise application. A business perspective of polyglot programming is covered at depth by Hans-Christian Fjeldberg here – http://daim.idi.ntnu.no/masteroppgave?id=4167

    Within same project architecture, as per polyglot programming pyramid defined by Bini O (http://ola-bini.blogspot.in/2008/06/fractal-programming.html), it is recommended to choose one of statically typed language (i.e. Java or Scala) in stable layer. However Dynamic and Domain layers can consist of one or more languages in respective layer. Examples of suitable languages for dynamic layer are Groovy, Jython, Clojure, Javascript, Ruby, etc. Examples of DSLs are Apache Camel DSL, Drools, Web templating (Velocity, Freemarker…), etc.

    Reply
    1. Steve Wedig Post author

      Thanks for reminding me to mention Polyglot programming. I had meant to but forgot. I will put one of your links into the article.

      I think increasing the number of languages in a company codebase creates a great deal of accidental complexity and redundancy. I think these non-linear costs significantly outweigh the relative advantages of various languages. Complexity is the enemy, and unnecessary variation is a significant cause of complexity.

      Reply
      1. Craig

        Ahh, a huge XML file, filled to the brim with boilerplate and redundant syntactic noise. This is a Java project alright.

        Reply
  11. Craig

    “Java is stable”

    …which is a shame, because it’s also very deeply flawed. UTF-16 in 2014? That’s not even laughable — it’s cryable.

    Reply
    1. Steve Wedig Post author

      Thanks for the pointer. I’ll take a look and watch the language. The home page says it just released the first production-ready version.

      Reply
      1. Luke

        Yes, it’s 1.0. I’ve been playing with it back when it was beta and they’re improving it steadily. There’s an Eclipse IDE, it has first class/higher order functions, and some killer features like union and intersection types, as well as a first class module system baked into the language. Also, it has much better reified generics with better semantics for covariance/contravariance and declaration site variance, as well as a type safe metamodel/reflection.

        Reply
      2. Luke

        BTW, your comment about wishing that final was the default is true in Ceylon. If you want your variable to be final, you don’t add a keyword or annotation. If you want your variable to be non-final, you must use the variable annotation. There’s no use of val/var in this case.

        Reply
  12. Download titanfall

    Nice post. I used to be checking continuously this blog and I am impressed!
    Very helpful information specially the last phase :) I deal with such info a lot.
    I used to be seeking this particular info for a long time.
    Thanks and good luck.

    Reply
  13. Edward Waudby

    Very interesting and informative view. I probably agree with about 95% of your observations and of the remaining 5%, frankly I’m pretty schizophrenic about anyway (such as getter and setter methods rather than naked public properties and I can be a bit naughty when cutting and pasting camel case code into snake case)

    The bottom line for me though is that the language, whichever one it is, is good for the job at hand in terms of the commercial, logistical, functional and non-functional requirements. That includes maintenance, training, testing, fault determination and all those other goodies that seem to be increasingly lumped in with the language these days.

    A hammer, by any other name would whack in nails as sweet[sic].

    Reply
  14. Eric Henderson

    I thought I would mention that http://www.rubymotion.com/ is a much better way of writing iOS (and native Mac) apps. It lets you use Ruby instead of Objective-C. I’ve worked in both Objective-C and RubyMotion, and I find RubyMotion to be a lot easier to work with. There are also plenty of gems to make things even easier, and it still has access to all of the stuff you have in Objective-C.

    Reply
    1. Steve Wedig Post author

      Thanks Eric. After writing this article, I’ve been happy to learn of the progress being made in reaching iOS from other languages. It’s nice to learn that Ruby is working in this direction as well as Java.

      Reply
  15. Andrei Rinea

    Excellent analysis. I deeply recommend IntelliJ IDEA after trying Eclipse and Netbeans. Coming from Visual Studio (C# on .NET) where I am a heavy user of ReSharper (another product of JetBrains just like IntelliJ IDEA) might bias me a little but, again, give it a try. ALT-ENTER is the “fix almost-anything” key combo.

    Reply
  16. Eleftheria Kiourtzoglou

    Hello Mr Wedig,

    Nice blog! Is there an email address I can contact you in private?

    Thanks,

    Eleftheria Kiourtzoglou

    Head of Editorial Team @ Java Code Geeks

    email: eleftheria[dot]kiourtzoglou[at]javacodegeeks[dot]com

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s