Tag Archives: java

A Java primer for Oracle v Google

Oracle was the opening keynote for Linuxcon this year, where they talked about how much they did for Linux and open source.  The moment everyone had checked out of their hotel in Boston, they filed a massive patent suit against Google’s open source java like implementation in Android.  Oracle, you can suck it.

This has led to a lot of virtual ink in the blogosphere on the subject, and you can see that for the most part, we all sit inside our tech valleys, unable to see the wider world over the hills.  This is especially true for folks that have worked in the same kind of tech for a long time.  Charles Nutter provides a really good background on what the Java space looks like, and gives his own thoughts on the matter.  Much like Linux, Java is really just about everywhere, some times in surprising places.

The Java platform is big. Really big. You just won’t believe how vastly hugely mindbogglingly big it is. And by big, I mean it’s everywhere.

There are three mainstream JVMs people know about: JRockit (WebLogic’s first and then Oracle’s after it acquired them), Hotspot (Which came to Sun through an acquisition and eventually became OpenJDK), and J9 (IBM’s own JVM, fully-licensed and with all its shots). Upon those three JVMs lives a gigantic world. If you want the details, there’s numerous studies and reports about the use of Java in all manner of business, from the hippest new startups (Twitter recently switched much of their stack to the JVM) to the oldest of the old financial concerns. It’s the favored choice for government server applications, the strongest not-quite-completely-Free managed runtime for open-source libraries and applications, and now with Android it’s rapidly becoming one of the strongest (if not the strongest) mobile OS platform (even though Android isn’t *really* Java, as I’ll get into later). You may love or hate Java, but I guarantee it’s part of your life in some way or another.

It’s a long read, but well worth your time.  The why people hate Java section is particularly useful for people that hate Java.  It may or may not change your mind, but it will at least give you a broader view.

Isn’t this what we were afraid Microsoft would do?

There is one main reason people in the open source community get so violent over Mono (the open source .NET implementation): the fear that Microsoft could shut everything.  There is long standing fear that MS has patents on core parts of the system.  People were afraid their investments in software written on top of it would be at risk.  Java was always held up as the much safer choice, with a longer legacy, being more open source friendly, with a company behind it that everyone trusted.  Of course, companies change hands some times….

Oracle sues Google for patent, copyright infringement

Oracle filed a complaint in federal court in California, alleging the infringement of seven patents and copyrights by Google’s Android mobile operating system software.

I was once told that Sun actually made money off Java, and one of the big sources of revenue was the J2ME market, which is what all those dumb little snake games are written in.  Google has undercut that by making a really popular cell phone platform with a version of Java they wrote themselves.

It’s still not a good world to be in, where innovation comes with a 10% patent tax.

Why Mixins matter

The Ruby language has this great feature called Mixins.  It lets you add methods to existing classes. Take this example from Ruby on Rails (which uses mixins heavily):

time = 2.days.ago

Yes, that’s valid code and does what you think. The result is a DateTime object. It was accomplished by adding methods the Numeric and to DateTime. If you come from a strongly locked down language background, this sort of thing horrifies you. If you don’t, you think it’s awesome. Remember, this isn’t inheritance, it’s actually changing the fundamental classes.  This makes it much easier to retrofit on existing code. The python folks call it Monkey Patching, which makes it sounds kind of dirty. I like Mixins better.

While Ruby has been my language of choice for personal time hacking, I’m doing a lot of Java recently due to working on Android things. This past weekend I remembered one of the things I dislike about strongly typed languages: type gymnastics.

If you’ve got a time as milliseconds in Java and you want it in a string you’ve got to first convert it to a Calendar, then to a Date, then give that Date to a DateFormat. You’d think that Calendar.toString() might actually give you something useful, but it doesn’t. Oh, and also realize that every one of these objects has it’s own internal notion of TimeZone, quietly gotten from the system, so if you are trying to do something in UTC, you have to manually force that on them all. This is the crux of type gymnatics, long changes of type conversion operations because to get from A to B (in my case A:long, B:string) you’ve got to go through C, D, and E in the right order. These conversions are error prone, and clumsy, and largely produce some part of your namespace called “util” that is largely static methods to convert between one thing and another.

This is because the authors of A never thought you’d have to get to B. What’s so interesting about B? C is really nice this time of year, wouldn’t you just like to stay there instead?

The real problem is that original authors of software rarely really understand what their software will be used for, and the more immutable languages don’t let you fix things after the fact. In Java this means that any project ends up with a “utils” package which is used to do conversions between types that can’t natively be converted. All that code is just boring boiler plate, which is where you are most often going to make a hard to find mistake. Nothing generates errors like boredom.

Where is Io – v1.3

Where is Io 1.3 has been released, and is available for free on the Android Market.  Most of this release was behind the scenes refactoring, as I tried to get this into a shape where I could do useful animations.  Being a good little agile minion I made sure there were some user visible enhancements for the release.  There are only 2, but they should be useful:

  • Time hash marks so you get a good idea of how far in the future I’m displaying
  • The main screen will actually update over time (before it was just drawn on start or rotate)

I learned a heck of a lot about the Android state model; threading in Android; when certain threads like to stop and start relative to the state model; how much the Java thread signaling model leaves to be desired; the fact that google knows that, and created this really nice Handler infrastructure to do async message passing; and that it’s really important to have good utility functions when you are converting between 3 different time schemes.

I also broke down and learned how to use the Eclipse debugger on Android applications, as one of my bugs was just not finding its way to the surface (the afore mentioned time conversions).  Holy crap.  I am seriously impressed with how good and intuitive the integrated debugger is when it comes to Android apps.  Nicely done folks.

The project has gotten me to appreciate Java again.  Java was never my favorite environment, but with the support in eclipse, Google’s quite tight API set for Android, and emacs keybinding support, I’m now about 1/2 as productive in Java as I am in Ruby.  That’s saying something, as previously that number would have been 10% or less.

Now that I’ve got the basic threading and signaling going in this application, I’m going to see about some animation on startup.  Maybe I’ll even get that done in time for Frank’s Android talk on Wednesday.

Rambling thoughts on C# on Linux

Livnat Peer just posted an interesting look at converting a large source base from C# to Java.  This was done because when Red Hat aquired the company that wrote KVM, they also got a huge .NET management application that they wanted to run on Linux.  It’s a pretty interesting look at the various approaches you could take, and how they were eventually successful.

C# on Linux is an interesting beast.  I like C# better syntactically than Java.  Properties are just too damn useful.  Having to have lots of getFoo(), setFoo() in Java when we’ve got this perfectly good key on our keyboard ‘=’ that everyone has known about since they were 7 bugs me architecturally.  It is a short coming that Java will probably never get past.

Mono, the open source C# runtime, was the only open source Just In Time Compiler (JIT) you could get your hands on a few years ago.  That made it a huge boon to language implementers, and was the defacto runtime that people would play with and hack on to build scripting engines inside over other applications.  It’s the reason you’ll see Mono specifically show up all over the place in the gaming industry.  Since that time Java went open source, under GPL, and LLVM, which is under a very permissive license, really grew up.  This gave developers interested in language design some options for VMs they could run on top of.

But, there is always another hand.  Microsoft casts a long shadow over C# on Linux.  The Mono project remains many years behind Microsoft on features, and many more years behind that on stability and performance.  While I was working on OpenSim, I was continuously frustrated by how much worse the environment performed on Linux than on Windows.  Any project that is written in C# will be relatively poor performing on Linux.  The word relative is in reference to the same code on Microsoft .NET, it’s still 20 times faster than if it was in Python.  Microsoft’s sword rattling over Linux infringing their IP ensured that the Mono community remained somewhat small and close nit, with no large organizations investing in it other than Novell.

Mono makes for some decent desktop Applications.  I use three of them on a regular basis: F-Spot, Tomboy, and Do.  I can’t function on a computer without Do any more.  But I still have a personal grudge with Mono over a simple fact: I can’t watch Netflix Instant on Linux.  There was this theory that because of the way the media framework worked that it was going to work “real soon”.  That was 3 years ago… and I’m still waiting.

C# has the basic issue that Java had for a long time, it’s a vendor language.  And that’s just a tough thing to really believe in, unless you have a sufficient reality distortion field.  Java has finally transcended that.  It took building a community process for future features and open sourcing the JVM.  Google’s entirely parallel Java implementation for Android was additional proof that it’s no longer in the hands of a single vendor.  And while Java remains far from perfect, if you are on Linux, and want performance, it’s a pretty decent approach.

What’s with all this Java complaining about AppEngine

I’ve seen all manner of people in the twitter verse complaining that Google’s AppEngine Java support is a subset of Java, and how that “breaks a decade of compatibility”.


I mean, really, seriously?!?

I’ve got to have 3 JVMs installed on my system to use ~ 5 java applications in total.  So I’m not buying the compatibility complaint, as “best practice” in the java world is to ship your own copy of the vm. 

And I definitely sympathize with the Google folks that really don’t want to be running millions of idle 2 GB memory footprint VMs.  It is basically free after all, so what’s up with all the complaining.  And, honestly, if it gets Java folks rethinking if they really need 5000 classes floating around at all times, I think that’s doing the world a favor. 🙂