Java 6: finally able to access interface MAC address!
Better Late Than Never
I recently learnt about one neat addition to Java6 (thanks Taras!): java.net.NetworkInterface class now has method getHardwareAddress() (see Java6 Javadocs), which returns MAC address of Ethernet interfaces. It seems that this addition was made with little fanfare, so I wasn't even aware of it. However, it addresses a long-standing small but significant issue: previously accessing this information has required use of native code via JNI, or executing platform-dependant scripts (like Unix ifconfig)
So what? What is the low-level hardware address for my Ethernet card useful for? There are at least two important use cases (web server implementors probably have others, as well as people writing tools for dealing with network interfaces and so on):
- To be able to generate time/location based UUIDs one needs MAC address (see Java Uuid Generator project for more information). Jug pacakge actually has small native C-libraries (compiled on multiple platforms) to support this generation method. Other UUID generation packages (like JDK's castrated java.util.UUID) either only produce other kinds of UUIDs (JDK), or require calling application to figure address out.
- For per-instance/host software licenses, some sort of permanent (but not necessarily public) identity is very useful.
Although the first case is the one I personally care for most, it turns out there are probably many more developers that care about second use case. This based on feedback I have received regarding Jug: it seems there are actually more users who only use the native code for accessing Mac address than there are users who actually generate UUIDs (or is it that they just have more problems? I know I get more emails from them, at any rate). So for software packages that can count on only running on Java6 JVMs, problems is now more easily solved.
But this is also good news for UUID use case too, since now the whole UUID generation can be done using just Java: Jug, for example, has JNI accessible libraries only for couple most popular platforms. I should probably spend some time to write new version of Jug that can take advantage of Java 6, if running on it (and downgrade gracefully to JNI if not).
Finally, it is interesting to note that for some reason java.net.UUID has not been upgraded to take care of this new functionality. It is a shame, since it would be very little work to implement missing generation functionality. But for Jug I guess it's good news, given that JDK UUID varant will remain sub-optimal given it can only generate random number based UUIDs (which theoretically speaking are just fine, but which most developers are sceptical of). So it will still remain relevant even for users that do run on Java6.
