Skip navigation

In the last-completed Java.net poll, the Java/JVM developer community indicated that, despite rumors that "the desktop" is disappearing into "the cloud," when it comes to hammering out code they prefer to work using a desktop-based Integrated Development Environment (IDE), and hope that the mid-term future evolution of IDEs is desktop-centric. The desktop may be becoming more specialized, used primarily for certain types of tasks, but as Geertjan Wielenga (@geertjanw) has frequently argued (for example, here), some tasks are ill-suited for any other platform. The results of this poll suggest that, as of today, developers consider programming using IDEs to be in this category.

A total of 318 votes were cast in the poll, and two comments were posted. The exact question and results were:

How would you like to see IDEs evolve over the next 2 to 5 years?

  • 59% (188 votes) - Exactly as they are now, on the desktop, because IDEs are best suited for the desktop
  • 4% (12 votes) - Only web-based, because everything is moving to the web, so IDEs should too
  • 30% (96 votes) - Hybrid: for collaboration, I want to be on the web (like Google Docs); but otherwise on the desktop (like Office suites)
  • 5% (17 votes) - I will be programming on a mobile device within the next 5 years
  • 2% (5 votes) - Other

The first three options are about desktop-based and web-based IDEs. Combining these results, we see that 89% of developers want their IDE to run on the desktop in the coming years, while 34% would like at least the option of using their IDE on the web. I think this makes sense. When I'm working in my home office, I prefer to program using a powerful (though somewhat ancient) beast of a desktop computer, with a nice big monitor that lets me spread out the windows occupied by my IDE, the running application I'm working on, often a terminal window, often a web browser where I pull up documentation on classes, methods, error messages, etc... It's nice to have all that displayed on a big screen backed by a pretty hefty n-core processor and gobs of disk.

But, I do go on the road. My normal practice is to copy code onto my fairly hefty laptop, where I can still run my IDE, just with the annoyance of a much smaller screen. I use the laptop also for all requisite communications tools, such as my email client, etc.

While I myself don't particularly need an IDE that runs in the cloud, I can readily see the benefits of that, particularly in the case of "virtual" companies that have individual developers contributing to a code base from around the world; or, open source projects, which are almost always geographically spread. It makes sense for a global effort to utilize web-based tools so that the team can share advice about issues relating to the IDE itself. And it's easy to see how many consultants who develop software for various clients, and/or provide support for various technologies and tools for multiple business clients, would find a web-based IDE to provide convenience and enhance efficiency.

An interesting minority, 5%, said they will be programming on a mobile device within the next 5 years. Surely this is an area that will expand. Though, if it was me, I think I'd still rather write code for mobile devices on my big old desktop system, using a desktop IDE, and run a mobile emulator on the desktop, then do final testing on the actual mobile device itself. Doing actual programming on a mobile device, a tablet or phone? I guess if you grew up frenziedly texting to your friends, that might seem reasonable; but, as for me, being one who grew up originally programming in 80-character wide text-based terminals using editors like vi... I'll take that windowed IDE fanning across my giant screen on this big old monster of a desktop when I need to developany application, including one for mobile devices!

New poll: Continuous Integration Servers

Our current poll asks Which Continuous Integration (CI) server do you prefer?. Voting will be open until Friday, March 7.


Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the java.net blogs feed. To follow Java.net net on Twitter, follow @javanetbuzz.

-- Kevin Farnham (@kevin_farnham)

You may notice that our current Java.net poll and our last Java.net poll are both related to Java IDEs. The current poll ends this Friday, February 21, and I'd like the next several polls to remain on the topic of Java tools. So, here's your opportunity to help!

We've already covered IDEs, so now it's time to move into different categories of tools. For example, there could be a poll about unit testing frameworks. Or continuous integration platforms? Performance analysis tools? Bug-identification tools? Or -- what other categories of tool do you use in your development work?

If you'd like to suggest a poll, think of a good question about a category of tools, then think up your recommended response options. These polls should not be about a single tool, but rather about a category of tool. It would be interesting to find out how developers compare different tools within a single category -- that is, how they rate something about tools that compete with one another; or the poll could simply ask which tool/framework/platform, among the most widely-used packages in a category, developers use the most.

If you have a suggestion for a poll, you can either post it as a comment to this blog, or send it as an email message to editor __at__ java.net.


Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the java.net blogs feed. To follow Java.net net on Twitter, follow @javanetbuzz.

-- Kevin Farnham (@kevin_farnham)

For years there has been a recognized "Big 3" with respect to IDEs used by Java/JVM developers. Each IDE has added new features along the way, and many of the improvements are great. But, truth be told, once a developer has invested significant time working with a particular tool, their efficiency is (at least temporarily) compromised if they decide to switch to a different tool. Not only does this make it difficult for one tool to attract users away from another, but it also makes it very difficult for a new entrant to break in and gain traction. What's a poor developer supposed to do when facing critical software delivery deadlines: get the release out as quickly and reliably as possible, or take the time to learn how to be equally or more efficient using a different IDE?

The results of the last-completed Java.net poll suggest that we shouldn't expect a revolution in which IDEs Java/JVM developers use any time soon. The top 3, I expect, will retain their dominance for years to come. A total of 925 votes were cast in the poll. The exact poll prompt and results were:

I do most of my coding using:

  • 38% (348 votes) - Eclipse
  • 11% (106 votes) - IntelliJ IDEA
  • 44% (406 votes) - NetBeans
  • 1% (5 votes) - Another IDE
  • 2% (19 votes) - A text editor
  • 4% (33 votes) - It depends on what I'm working on
  • 1% (8 votes) - Other IDE

A full 93% of the voters use Eclipse, IntelliJ, or NetBeans! Furthermore, you'd guess that among the 4% who selected "It depends on what I'm working on," what they're chosing between is probably most often a Big 3 IDE. If you're a consultant, and you have one project where the in-house development team uses one IDE, and another project where the in-house team uses a different IDE, it's going to be more convenient to interact with those teams within the context of their own native IDE.

This is, of course, not a scientific poll. Hence, I wouldn't want to argue that more Java/JVM developers actually use NetBeans than Eclipse; and it also wouldn't surprise me if more than 11% of Java/JVM developers use IntelliJ IDEA.

New poll: how should IDEs evolve?

Our current poll asks How would you like to see IDEs evolve over the next 2 to 5 years?. Voting will be open until Friday, February 21.

Suggest a Java/JVM tools poll!

As you may have noticed, we're running series of polls related to Java/JVM development tools. We've barely scratched the surface, starting with IDEs. Is there a category of tools for which you'd like to know the Java/JVM developer community's opinion? If so, please suggest the question and response options in a comment below, or in an email message to editor--at--java.net.


Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the java.net blogs feed. To follow Java.net net on Twitter, follow @javanetbuzz.

-- Kevin Farnham (@kevin_farnham)

The January/February 2014 issue of Java Magazine came out recently. This issue focuses on Big Data, which for very good reasons is receiving lots of attention. Based on the several decades I've spent working on mathematical modeling software and scientific data analysis, I have absolutely no doubt that the combination of Big Data techniques on the one hand, and inexpensive sensors (think Internet of Things) on the other had, is going to fundamentally transform the world in terms of technology.

Here's Java Magazine Editor Caroline Kvitka's introduction to the January/February issue:

 

As Caroline notes, there's more in this issue than Big Data, but Big Data is the focus.

Going back to the Big Data and Internet of Things (IoT) connection -- if you're wondering what I mean by that, take a look at the article "Power to the People". This article shows how OPower is changing the future of energy, in particular from the energy consumption side. OPower monitors the energy consumption of close to 100 Million residents across the world, and provides them with reports that detail their energy consumption patterns, including data on how their own energy consumption compares with other households in the neighborhood.

The input data comes from power meters on individual homes. But this isn't just a monthly check of power usage. Rather, the actual time series of power usage is evaluated over the course of the month, then a report is generated and sent to the customer. The report facilitates money-saving alterations in energy use by individual households.

The back-end technology includes Hadoop, Hibernate, Spring, and MySQL. OPower is another example where, when they were just getting off the ground, they considered going with languages like Ruby and Python -- but the knowledge that, if they succeeded, they'd be facing immense data processing requirements, led them to go straight to Java from the start.

As Caroline says, other instructive Big Data articles in this issue include:

While the Big Data poll we ran last November wasn't entirely conclusive, I think it's pretty clear from history that 'Big Data' isn't going away. This is because Big Data is simply the latest way to utilize our ever-increasing computational power.

Now, it may not be true when it comes to baseball fields that "if you build it, they will come" (see "Field of Dreams"). But, tell me, have you yet seen in your lifetime an instance where increased hardware and processing capability didn't almost immediately elicit a stream of new applications that fully utilize it? Then beg for more???


Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the java.net blogs feed. To follow Java.net net on Twitter, follow @javanetbuzz.

-- Kevin Farnham (@kevin_farnham)

Filter Blog

By date: