Why Don't People Use Java Generics

My company tends to be behind in technology.  Java 5 was released in 2004, but my company didn't start using it until 2008.  That means we have been using Java 5 for six years now.  You would think the developers would be using generics.  You would be surprised.

I feel like some developers don't want to learn new technology.  They learn one thing and they want to stick with it.  That is the only reason why after six years, people are still writing Java code without using generics.  It is either that or they LOVE casting.  We don't disable Java warnings, so Eclipse will tell them right away that they are doing something wrong.  We use various static code analysis tools that give them reports about problems.  You can lead a developer to water, but you can't make them use Java generics.

I find this frustrating because I hated Java prior to Java 5.  I couldn't stand the endless casting that needed to happen.  Code that is written like that feels dirty.  I feel like you need to constantly handle ClassCastExceptions.  The weird thing is I feel like Java code with generics is faster to write.  This is a scenario where spending a little time learning how to become a better developer is a good return on investment.

Rant About Online Forums: Help, Don't Criticize

Online forums are very helpful.  They can also be very frustrating.  Technology is filled with people that have strong opinions about technology and enjoy trolling.  I find it frustrating when I look for help on a topic, but all I get is "my way is better, so I'm not going to help you."

I recently wrote about problems with ZFS when upgrading Ubuntu to 14.04.  Technically, the problem was around the 3.12 kernel upgrade.  When searching for answers, I came across lots of people that were anti-ZFS.  If someone is anti-ZFS, then why would they answer a ZFS related question?  Because they are trolls.

The most frequent answer I saw to this question was usually something about how you shouldn't use ZFS.  They would start a discussion about the cons of ZFS.  These types of answers don't help.  They don't provide anything constructive.  They just frustrate.  If I need help with a technology, I need people who are familiar with that technology.  I don't need to justify WHY I used a technology before I get that help.

A similar thing happened when I was researching DTLS.  DTLS is an encryption standard for UDP packets.  If you need to send data to someone over UDP, then DTLS is the way that you would encrypt it....in theory.  The problem is DTLS isn't very well supported.  I wanted to write an Android app that uses DTLS, but the OpenSSL version that comes with Android doesn't have DTLS enabled.  Some people were helpful and pointed out that I could compile OpenSSL myself.  I was trying to avoid that, but at least they were trying to be helpful.

Others were not so helpful.  They would argue that DTLS is useless because UDP is useless.  They argued that I should just use TCP.  They argue that there is no reason to use UDP, even though they know nothing about what I am trying to do.  Once again, you end up having to defend rather than getting help.  In this particular case, I was trying to avoid the TCP over TCP meltdown problem.

I remember running into this many times in the past.  Something that people need to keep in mind is that the harder the problem, the more help someone is going to need.  You shouldn't claim to be the expert then argue about the why.

Another hard disk dead

It's that time of year again.  The seasons are changing.  I have to mow my lawn again.  The temperature is getting warmer.  Hard disks are dying!  I had expected that moving my server into my basement would reduce the deaths of the hard disks.  This death might be a little unique, though.  The hard disk is brand new.  I bought it 3 months ago.  It is a Hitachi 4TB hard disk.  I never had a Hitachi before, but it was 4TB and it was on sale for the same price as Seagate and Western Digital 3TB disks.  I decided to take a chance.  At 3 months, I consider this hard disk a dud.

My server has 7 hard disks attached to it, although one of them is an SSD (the operating system).  Five are inside of the case while 2 are in an external eSATA enclosure.  The Hitachi is in the external enclosure.  I know the enclosure is fine, since there is another hard disk in it that is working fine.  This hard disk was my first chance to really expand my capacity.  Most of my hard disks are between 1.5TB and 3TB.  I previously combined two 1.5TB drives into a single 3TB device and two 2TB into a 4TB device in my RAIDZ.  The 4TB drive replaced the two 1.5TB drives, matching the capacity of the two 2TB drives.  With the 4TB dead, I'm running in DEGRADED state until a replacement can get shipped to me.  I don't need the capacity yet.  Right now, the biggest thing driving my data growth is doing backups of my Windows PC, but I barely use it anymore, so I was able to reduce the backup frequency.

iPhone 5 and Galaxy S5 - There is something about 5

I have seen lots of reports about the design chief for the Galaxy S5 stepping down.  He isn't stepping down because the S5 was a bad phone.  He is stepping down because the S5 was only an incremental upgrade over the S4.  The S5 had some great upgrades, but none were earth-shattering.  My buddy upgraded from an S4 to the S5, mostly because of the fingerprint scanner.  He was greatly disappointed, though.  From the outside, they are so similar he accidentally brought his S4 home from work, thinking it was his S5.  My wife is going to upgrade from an S2 to the S5.  She considered the S4 which would have been free, but we decided that the IP67 rating of the S5 and the Qi charging (semi-false advertising, but that is a rant for another day) was worth paying a little bit for the S5.

This whole situation reminded me of the iPhone 5 rollout last year.  The S5 is an incremental upgrade similar to how the iPhone 5 was an incremental upgrade.  I wrote about the iPhone 5 upgrade last year.  I will dive deeper into the S5 next time, but for now, I want to compare the "upgrades".

Charging

The iPhone 5 released a new charging connector that was not compatible with older iPhones.  While this new connector was better, it also meant you had to buy all new connectors.  All the old wires were now useless.

The S5 continues to use the standard Micro-USB.  All your old cables still work.  There is talk about the S5 supporting Qi wireless charging (another standard), but it turns out you have to buy an after-market replacement cover from Samsung.  Unofficial qi receivers are available, but they remove the IP67 water resistance.  If you buy the cover (which we are going to do) then you have a more convenient way to charge your phone that supports a standard.

64bit (iPhone 5S)

The iPhone 5S is 64bit.  The S5 is still 32bit.  Right now it isn't that important, but it will become a big deal in the future.  We don't know when in the future it will become important.  While 64bit does increase your performance, so does doubling your cores (S5 has 4 cores).

Size

The iPhone 5 was about 20% lighter and thinner.  That is nice.  It isn't what most people want, though.  Many people like having the bigger screens.  Rumor has it Apple has finally got the memo and the iPhone 6 might have a larger screen.  The S5 on the other hand....didn't change.  It looks identical to the S4.  At least the iPhone 5 changed something.  My buddy wouldn't have made the same mistake with an iPhone 5.

Post-Launch Marketing

As a general rule of thumb, ignore all pre-launch marketing.  That is why we are jumping right to post-launch.  After the iPhone 5 launched, Apple continued to market it as if it was a huge improvement over the iPhone 4S.  They wouldn't acknowledge that it was an incremental upgrade.  Apple portrayed the iPhone 5 as the next big thing (hehe).  Samsung on the other hand realized that the S5 was an incremental upgrade after launch.  That is why the person in charge stepped down.

This is where I think both companies got it wrong.  There shouldn't be anything wrong with an incremental upgrade.  You shouldn't market it as something great, or fire someone for mediocrity.  Most people get upgrades every two years.  They tend to skip a model.  When asking people why they were upgrading to the iPhone 5, the most common response I got was it was time to upgrade...since they were on either the iPhone 3 or the iPhone4.  Apple does have a lot of fan boys that will pay for the yearly upgrade, however.  Samsung has to compete with Apple, so it sticks with the yearly rollout as well.  These companies should acknowledge this. Besides, what else can you really put into the phones?  Apple has some catching up to do (screen size, wireless charging, IP67), but not by much.

The next big thing should come out next year.

Make a Backup Before Upgrading Ubuntu

I am a little obsessive about backing up my data.  I use ZFS with RAID-Z to prevent data loss due to silent data corruption.  Since ZFS can be problematic due to its licensing, I also have a USB hard disk that contains a copy of all my data.  In the event that my house gets destroyed, all my data is backed up to an EC2 micro instance.  My EC2 instance runs Owncloud with the data stored on a ZFS volume.  Since the EC2 instance is outside of my home, I try to keep it up to date.  During the last update, serious problems occurred.

After upgrading my EC2 instance to Ubuntu 14.04, my ZFS volume disappeared.  Since there was a kernel upgrade, I assumed the zfs module just needed to be recompiled.  Finding the instructions on how to do this was pretty painful, but that is a rant for another day.  The recompile of the zfs module failed, however.  The zfs module won't compile against the 3.12 version of the Linux kernel.  I would have to patch my kernel to get it to work.  I decided to try and roll back the kernel, but that just made things worse.

This is where I wished I took a backup.  Not a backup of my data.  A backup of the Ubuntu OS.  Now that 14.04 is out, I am having a hard time finding Ubuntu AMIs for older versions that work.  I fired up another EC2 instance using Gentoo.  Gentoo is the distro I use at home, and I know ZFS works well with it.  I used this instance to import the ZFS pool and copy the data to an ext4 volume.  I will create a new Ubuntu 14.04 instance that will use the ext4 volume for Owncloud.

This experience has showed that I did a few things right.  First, my data was on a different EBS volume.  I did backup the Mysql database, but not with enough frequency.  The software I installed was pretty minimal and minimally customized.  This makes it a lot easier to create a new instance and get running.

I definitely have a few things that I know I need to do in the future.  First, I need to take snapshots of the OS.  Second, I need to keep the configuration backed up as well.  That way, if I need to create a new instance, I can more easily recover.  Finally, I should back up the Mysql data to the data volume.

Static methods for all....and (another) reason to not use them

When I switched to my current team, I was surprised to find an endless supply of static methods and variables.  It seemed like the team really liked them.  I can understand why.  Most of the team were younger and weren't really used to design patterns and object orientation.  For them, the only reason to extend and object is to make it convenient to call common methods.  Being new to the team, I didn't try to force a paradigm shift.  I brought it up a handful of times, but everyone seemed to like their static methods.

Recently, however, I was tasked to fixing a recurring issue.  Inside of our Android app, some of our static variables were being reset to null.  It seemed like it happened when the app crashed, so we put in code to reinitialize the static variables in the Activity that gets called when the app crashes.  We were still getting sporadic null values.

Then a major problem occurred.  We started using a 3rd party Android library that was returning null values.  I disassembled the code and the developer had used static variables to store some values.  Sound familiar?  At first it happened when the app crashed, but then we noticed it happening when we ran out of memory.  The screenshot library has a memory leak....ugh!  We plugged the memory leak and the nulls in the 3rd party library went away.  The incident got me thinking.

I started doing some research on the topic.  I found lots of places talking about Android memory management.  There seemed to be a debate of where to put long-lived objects.  Some (including Google) recommended using a static variable to create a singleton.  Others suggested keeping a reference to it from the Application class.  I then found more details on what we think is going on.

First, a few things that you might not realize.  Java classes are loaded into memory.  If nobody is using a Java class, then that class can be unloaded from memory.  If someone decides to use that class again, then the class can be reloaded into memory.  This type of thing might happen if you run out of memory.

Apparently, one of the differences between a JVM and Dalvik is the definition of a "class being used", or when is it OK to unload a class.  It looks like the JVM looks for references to the class while Dalvik looks for references to an instance of the class.  It turns out that it is a very important distinction.  In the above examples, the entire class was static.  All the methods and variables were static.  There was no instance of the class.  There wasn't a need for one since everything was static.  This works in the JVM world, but it doesn't work in Dalvik.  When you are low on heap space, Dalvik will unload the static class, since by it's definition, nobody is using the class.  Then, someone calls a static method which reloads the class, reinitializing the static variables, usually to null.

I made the decision that we shouldn't use completely static classes any more.  While it is generally bad practice to use static only classes, I had a concrete technical reason to stop using them.  I rewrote the code to use instances of the classes that are referenced from the Application class.  Anyone that wants to call them needs a Context.  Luckily almost all of our code already had a reference to a Context.  We haven't had an issue since I did the refactoring.