Java – rc3.org

Tag: Java (page 1 of 2)

Lambdas arrive in Java

Turns out Java is not just going to sit there and let Scala eat its lunch. Java 8 will have lambdas:

Before lambdas, developers often used a poor “beef to bun ratio” to express ideas, often with inner classes.

The argument for the Java ecosystem

October 18, 2013 / Rafe / 0 Comments

There’s a lot to hate about Cade Metz’s article on server-side Java from last month’s Wired magazine. For one thing, Java has been more successful on the server than on the client for at least 15 years. The fact that you can use it to build large-scale Web applications is not news, nor is the fact that the JVM is a great host for languages other than Java.

That said, the tradeoffs that go into choosing a software development platform are interesting. The Wired article is mostly concerned with scaling at levels that are unrealistic for nearly anyone to plan for. And indeed, platform is only a small part of the scaling discussion. I’m sure that most of the software written for Healthcare.gov was written in Java, and it didn’t solve any of the problems that are endemic to that sort of project (about which more some other time).

In the early stages, any Web company should focus almost solely on developer productivity. The hard part is building software people want to use, and iterating rapidly on your ideas. (I think everybody already knows this.) You’ll probably have rewritten everything by the time you even start to approach scaling issues of the kind face by companies like Pinterest or Twitter, to say nothing of the really big companies like Facebook and Google. Just choose whatever helps you build software as efficiently as possible.

If it were up to me, though, I’d build software using a JVM-based language, for reasons that the Wired article doesn’t really get into. The fact that Java and the JVM are heavily used at big companies like Google and a lot of others that are significantly more boring means that the platform will continue to grow and evolve. In that sense, it’s an incredibly safe choice.

Java also has an incredibly robust open source ecosystem, and mature libraries for almost everything. Non-Java languages that run on the JVM can make use of these libraries as well. One of the first things Java developers notice when they move to non-Java platforms is that the key libraries that you take for granted in the Java ecosystem tend to be immature or completely missing.

Another key advantage is that the world of Big Data is built to a huge degree on Java. Hadoop is written in Java, as are most Hadoop jobs. Storm, Hadoop’s realtime processing cousin, is also written in Java. One key advantage here is that if you’re already writing your software in Java or some other JVM-based language, you can transfer those skills to start writing Hadoop jobs. More importantly, you can share library code between your standard software and your Big Data jobs. This can be a huge advantage. Again, in the early stages of a company, your “Big Data” can easily be processed using R or Python and you won’t need Hadoop at all, but it’s likely you will eventually.

Finally, all businesses eventually have to integrate with “enterprise” software to some degree. Maybe you’re experimenting with the Community Edition of Vertica for data warehousing, or your HR department has purchased some special software for managing benefits. The bottom line here is that every enterprise software package integrates Java (and Microsoft) first. In many cases, those are the only options for integration. If you’re not on one of those platforms, you’re stuck with awful options like the Unix ODBC implementations. This isn’t reason enough to choose Java on its own, but it’s something you get for free.

Every company of significant size is eventually going to find its way to supporting some JVM-based software. Maybe they’re running Hadoop, or they use Solr for search, or Cassandra as a data store. Why resist?

There are a lot of other advantages to choosing the JVM. There are lots of developers out there who know Java. The Java development tools are very mature. Write once/run anywhere was always overstated, but it’s still very easy to write your code on OS X or Windows, and then deploy and run it on Unix servers without any tweaks or even making a new build. Because Java is so heavily used by big companies, and API stability over time is valued, so you don’t often have to do much work to upgrade to newer versions of the JVM when they arrive. Indeed, I’ve worked on projects where my development JVM was different from the production JVM and never ran into problems.

There are great arguments to be made for all of the other popular platforms. I’ve built software using PHP, Ruby on Rails, Python and Django, and plenty of other languages and libraries, and they all have real strengths. However, I think that the advantages of betting on the JVM outweigh the alternatives in most cases.

The leap second bug

July 2, 2012 / Rafe / 0 Comments

Nelson Minar has a nice, short writeup of the Linux kernel bug that caused servers to spin out of control yesterday. Most initial write-ups blamed Java, but that was incorrect. Interestingly, Java not only accounts for leap seconds, but also mentions them prominently in the documentation for the java.util.Date class:

Although the Date class is intended to reflect coordinated universal time (UTC), it may not do so exactly, depending on the host environment of the Java Virtual Machine. Nearly all modern operating systems assume that 1 day = 24 × 60 × 60 = 86400 seconds in all cases. In UTC, however, about once every year or two there is an extra second, called a “leap second.” The leap second is always added as the last second of the day, and always on December 31 or June 30. For example, the last minute of the year 1995 was 61 seconds long, thanks to an added leap second. Most computer clocks are not accurate enough to be able to reflect the leap-second distinction.

As Nelson notes, time is complicated. Further evidence of this fact is provided in Noah Sussman’s post Falsehoods programmers believe about time and his followup.

Java 7 looks kind of awesome

September 6, 2011 / Rafe / 1 Comment

Sure, you may know me as a very amateur political commentator or guy who builds Web stuff, but I spend most of my day writing Java code. My first impression of Java 7 was that it is a disaster due to some compiler bugs that result in unstable code. While it’s certainly prudent to wait for Oracle to work out those bugs, I am actually pretty excited about the language features in new version. One of the biggest complaints about Java is all of the extra typing you have to do compared to scripting languages like Ruby and Python, so it’s always good to see things get a little simpler. The new features certainly won’t convince anyone who isn’t already a Java developer to switch to it, but they will make life a little easier for those of us who use Java already.

Why people are returning to Java

July 7, 2011 / Rafe / 7 Comments

I am a huge fan of Ruby on Rails, but I was not terribly surprised to read that as Twitter’s code base has grown, they’ve found it more amenable to move to JVM-based languages for reasons having mostly to do with encapsulation. InfoQ interviews Twitter engineer Evan Weaver about how the company’s stack is evolving as they get bigger.

On one hand, they’re moving more services to the JVM for performance reasons. When they extract components from their main code base to optimize them, they generally migrate them to the JVM:

The primary driver is honestly encapsulation, so we can iterate faster as a company. Having a single, monolithic application codebase is not amenable to quick movement on a per-team basis. So when we decide to encapsulate something, then because of our performance concerns, its better to rewrite it in the JVM for most systems, than to write a new Ruby system.

They’re also finding the rigidity of the JVM useful for productivity reasons:

And the other half is that, as search has moved into a Service Oriented Architecture and exposes various APIs, static typing becomes a big convenience in enforcing coherency across all the systems. You can guarantee that your dataflow is more or less going to work, and focus on the functional aspects.

Those are the kinds of reasons why I could not imagine rewriting the main application I work on as a Ruby on Rails application. I’m surprised he doesn’t also mention the maturity and power of the tools on the Java side. Text editors like TextMate and Vim are great, but when it comes to navigating through a large, complex code base, you cannot beat the state of the art Java IDEs like Eclipse and IDEA.

Update: Edd Dumbill lists seven reasons you should use Java again.

Java coding style, accessor methods, and IDEs

February 1, 2011 / Rafe / 3 Comments

Last week I was asked to answer a question about our code base and wound up with the wrong answer for what I think are interesting reasons. Thus, a few thoughts on the power of IDEs, the importance of coding standards, and a problem with the way Java handles accessor methods.

The application I work on queries an external datasource and then does stuff with the incoming data to provide a variety of results. I often get questions about how, exactly, we’re using that external data to make decisions. The incoming data is copied into Java classes which are persisted in the database using Hibernate.

My usual approach to answering these types of questions is to open Eclipse, find the appropriate accessor method for the value in question, and then use the fantastic “Find References” function to locate all the places in our code where we use that value. (It’s Command-Shift-G on your keyboard if you’re a Mac user.) If someone asked where a certain value originates, I start by pulling up all of the references to to the setter method. If someone asks how the value is being used, I find all of the references to the getter. Sometimes the sleuthing involves navigating through the code by finding a method that calls an accessor, then finding all the places that method is called, and so on.

For all of the hassle associated with building Java applications, the power of Java IDEs almost makes it worth it. I find it easy to be productive using TextMate to work on Ruby on Rails applications, but I always miss features like “Find References” and “Open Declaration” that are found in Eclipse. Eclipse, IntelliJ IDEA, and other Java IDEs build a semantic model of Java code that makes it very easy to manage your code that aren’t available when using other languages and editors. Any developer who’s avoided a bug because their IDE told them a local variable is never referenced anywhere knows exactly what I’m talking about.

Anyway, I had trouble figuring out how our code worked because I was investigating a feature written by another developer. The get method in question didn’t have any usages in our code base, and I assumed that while the value was being stored in the database, it was not incorporated into our business logic. I was asked to look again, and deeper inspection revealed that the member variable associated with the accessor I was searching for was accessed directly in other methods in its class.

When people talk about coding standards, this sort of thing is a bigger deal than bracket placement or tab size. My habit is to always use accessor methods if they’re available, whereas this other developer’s habit was to use the instance variables within the class. It’s probably better to do it one way or the other, or at least to have a clear understanding of why you might use one or the other in a given situation. The fact that we didn’t cost us a little wasted time, and could have been worse had I not reinvestigated and made sure that things were working as expected and not the way I thought they were.

This also underscores a drawback of the way Java handles accessor methods. Because accessors are regular methods, there are no easy ways to pull up all of the references to a particular variable that includes both references to the instance variable and to the accessors. It seems like Ruby accessors would lend themselves better to a more consistent approach. I’d also be curious to know whether the accessor implementation in C# leads to better tools.

Building distributable Web applications

January 28, 2011 / Rafe / 4 Comments

My current project involves building a commercial Java Web application. For years I’ve built Web applications (using Java and a number of other platforms) to deploy on our own servers. Building something that’s suitable for distribution is a horse of a different color. I thought I’d write up my experiences for other people who are taking on similar tasks.

Distribution format – Usually Java applications are distributed as WAR or EAR files, but many people also package their Java Web applications with a servlet container to run them to make things easier.
Open source licenses – My application uses a number of open source libraries, and I had to go through and make sure that all of the libraries were distributable without much fuss.
Configuration – What’s the best way to set up database connections and other configuration parameters?
Deployment platform – In theory, Java Web applications should work with any servlet container, but the devil is always in the details. Many Java applications seem to be distributed with a servlet container as well. What’s the best approach?

Look for separate posts dealing with each of those issues.

I’m sure other considerations will arise as well, but those are the first few that have cropped up as I’ve started working on this.

Embarking on this process makes it clear why PHP has become the dominant platform for writing distributable Web applications. Regardless of its strengths and weaknesses as a development platform, its deployment story is hard to beat.

There are no real questions when it comes to distribution format. You archive the files and put them up for download. The end user downloads the archive, expands it, and puts the files in the directory where they want the application to appear.

As far as licenses go, many PHP applications have no external dependencies. PHP provides all of the functionality you need for most applications, and PHP developers have never really taken to using libraries to make things easier. Java developers tend to use tons of third party libraries, and Ruby on Rails applications often depend on dozens of Gems. PHP developers use what’s available as part of PHP and that’s it. PEAR is out there, but it isn’t terribly popular. I assume that’s because so many PHP applications are deployed on shared hosting. It’s just not worth the risk to bring in dependencies if you don’t have to.

Configuring a PHP application usually involves editing one heavily commented PHP file. Most people consider that to be inelegant, but it’s hard to argue with the simplicity.

PHP is ubiquitous, so there’s not much to worry about in terms of deployment. You just need Apache with PHP support.

When you look at those factors as compared to Java or Ruby, it’s easy to see why PHP maintains its massive popularity over other development platforms, and why we see explosive growth among applications built using PHP, like Drupal, WordPress, and MediaWiki. For all its drawbacks, PHP has evolved in a world where simple deployment and configuration are both hugely important, and that has given PHP some powerful advantages that other platforms aren’t even trying to compete with.

Apple open sources their Java implementation

November 12, 2010 / Rafe / 0 Comments

First Apple deprecated their Java implementation. Now they’ve released it as open source:

Oracle and Apple today announced the OpenJDK project for Mac OS X. Apple will contribute most of the key components, tools and technology required for a Java SE 7 implementation on Mac OS X, including a 32-bit and 64-bit HotSpot-based Java virtual machine, class libraries, a networking stack and the foundation for a new graphical client. OpenJDK will make Apple’s Java technology available to open source developers so they can access and contribute to the effort.

The question that remains for me is whether Apple will continue to contribute code to OpenJDK. (Hopefully they will.)

This, combined with the fact that Apple is no longer going to ship Flash on OS X, seems to signal that Apple isn’t interested in being responsible for shipping updates for other people’s runtimes any more. You can certainly run Java or Flash on your Mac if you like, but the vendor is responsible for making sure that your runtime is patched and secure.

Only Java developers use Java desktop applications

October 25, 2010 / Rafe / 4 Comments

Chris Adamson talks about the strange fact that the number one use of Java desktop applications is to run tools used to create Java server applications:

We know the big use for AWT and Swing, and it’s a terrible irony: measured by app launches or time spent in an app, the top AWT/Swing apps are surely NetBeans and IntelliJ, IDEs used for creating… other Java applications! The same can be said of the SWT toolkit, which powers the Eclipse IDE and not much else. This is what makes this white elephant so difficult to dispose of: all the value of modern-day Java is writing for the server, but nearly all the Java developers are using the desktop stuff to do so, making them the target market (and really the only market) for Desktop Java. If there were other viable Java applications on the desktop, used by everyday end-users, Apple couldn’t afford to risk going without Java. There aren’t, and it can.

This is sort of a weird result of how Java evolved. The original idea behind Java is that it would be a replacement for platform-native GUI toolkits, but of course that didn’t work out particularly well. However, it did make it easy for Java developers to write their tools in Java, and those tools wound up being write once, run anywhere.

That, in turn, contributed to the resurgence of the Mac. If you were a Java developer who used Eclipse, it was very very easy to move from Windows to the Mac. When it became obvious that using the Unix-based OS X was a better deal for Java developers than using Windows, you could just get a Mac, download Eclipse or whatever Java IDE you enjoy, check out your source, and get started.

Adamson’s prediction is that you soon won’t be able to run your favorite Java IDE on a Mac, but I don’t think he’s correct. At least I hope not. The strong negative reaction we’re seeing from the Java community is, for the most part, an expression of this worry. They don’t want to have to choose between their favorite tools and their favorite operating system, especially when they don’t have to right now.

The future of Java on the Mac platform

October 22, 2010 / Rafe / 14 Comments

Yesterday, I talked about what we might be able to infer from Apple’s decision to deprecate Java and prohibit Java applications from the Mac App Store in terms of the future of the Mac as an open platform. Today, I want to round up some links about the future of the Mac as a Java development platform and as a platform for developers.

Nobody is exactly sure what to make of the deprecation of Apple’s port of the Java Development Kit for the Mac, but a lot of people are rather stressed about it, as you can see from several threads at Hacker News. I am a Java developer and I do all of my work on a Mac. Losing the ability to continue to work in this manner would be a hit to my productivity.

First, Apple announced that the version of the JDK that they maintain is deprecated. A Java developer who is a Mac user emailed Steve Jobs what Apple’s future plans are for Java on OS X. Jobs responded that Oracle maintains the Java released for other platforms, that Apple’s Java release is always behind the latest Oracle (formerly Sun) release, and that keeping Java up to date for OS X is their job. Java creator James Gosling takes issue with Jobs on a number of points, noting that many companies do maintain Java for their platforms, and that Apple in the past chose to maintain the port for a variety of reasons. Former Sun open source evangelist Simon Phipps explains why it would be difficult for Oracle to take over maintenance of the OS X JDK.

Matt Drance says this is the end of Java as a development platform for Macs. The one community that really cares about this is Java developers who use Macs. Here’s his prognosis:

A lot of Java professionals use Macs for development, even if they deploy somewhere else. What will they do? If they’re using Eclipse, I think they’ll be OK. It shouldn’t take long to shim SWT on top of an OpenJDK port, and IBM has shown a lot of initiative over the years. Other “pure Java” IDEs, like JetBrains’ (superior, in my opinion) IDEA, depend on a working AWT, and therefore have some more thinking to do.

And finally, Tim Bray, on Twitter:

Unclench, everyone. There are millions of Java devs, all their tools are in Java, they like Macs, one way or another it’ll be there.

I don’t know what the future of Java on the Mac is, but I think it’s foolish for Apple to turn its back on hosting development environments that they don’t fully control. One of the factors that brought Apple back into relevance as a computer maker was the fact that Apple provided a friendly version of Unix that Web developers could use to get their work done. A few years ago switching from Windows to Mac became a no brainer if you were developing apps that would eventually be deployed on Unix servers. That led to a lot of Macs being sold, not only to those developers but also to the people those developers influence.

Furthermore, I believe that the presence of Macs on the desks of millions of software developers who were doing Java work, or PHP work, or Ruby on Rails work contributed in a big way to the growth of iPhone development. There are huge advantages associated with being the platform of choice for developers. Apple should be very careful before it fritters away those advantages.

rc3.org

Strong opinions, weakly held