Strong statement, but it's true. We've all come across different ways of managing configuration data. The Java Preferences API is one of those little things in the JDK that are often overlooked but are very useful. It handles a lot of the \"heavy lifting\" of managing external data and reduces your code's plumbing code.<\/p>\n\n
I've been actively developing Java since 2002 and I still ask \"Where do I put configuration data?\". Usually the answer is \"Wherever your users want it dummy!\". There are so many choices, though. Which one do you want?<\/p>\n\n
A plain old Java Properties<\/a> file has been my go-to choice for configuration for years (and it should be your's too). They're so easy to access and understand. But where do you put the file and how does your code read it? Do you put it on the classpath? Do you put it in an external directory? Do you change the code so that the application just \"knows\" where to look? Do you add support for fancy Url-style names for your file? <\/p>\n\n These questions create a point of frustration for a lot of developers and customers. It'd be better if Java at least gave us a default that could be built off of like they do for the JDK Logging configuration where a configuration file can be stored and then overridden with a system property.<\/p>\n\n Another question I've often asked is how often does a user actually change their configuration? My experience says the answer is very rarely, if ever. So while a configuration file is easily accessible and changable, that ease of access rendered moot if it's not going to be changed often (think YAGNI<\/a>).<\/p>\n\n Sometimes you think need a different format from Properties so you try something else like XML, JSON, YAML, or whatever else (like the God-awful HCL<\/a>). This is all well and good and there good \"reasons\" (rationalizations) for choosing a different file format. What you're doing though is adding to your user's cognitive load<\/a>. A special configuation file format doesn't add anything to your application whatsoever. And if your customer won't be changing their configuration much after it's working, what's the point (see above)?<\/p>\n\n But let's say that you have decided to use a different file format anyway. Now you need code to process it. You could write it. That'd be fine. Or would it? Code, debug, test, repeat till defects are gone. That's a waste of time that adds nothing to the functionality<\/strong> of your application.<\/p>\n\n Ok, you say, I'll follow Josh Bloch's advice in Effective Java and just use a stable library<\/a> that's widely used<\/a> because the bugs have been flushed out by everyone. Using a library is great advice<\/strong>. Except now you've added a dependency to your application. If you depenedency graph is already complex, this is going to make it worse. There are lots of libraries to choose from for parsing configuration. Oh, and don't forget to write your tests for your configuration. When it comes to configuration your user couldn't care less if the application doesn't work right.<\/p>\n\n Don't. Now you've added another integration point\/dependency to your application.<\/p>\n\n All of this tongue firmly planted in cheek discussion. Everyone has reasons for doing what they do. We all know that configuration should enhance your application or service, not be front and center. And there's an easy way to do that for Java-based applications. And that way is to use the Preferences API<\/a> that's already part of the JDK (and has been since version 1.4) which is a solution to these common problems.<\/p>\n\n Java Preferences are data that is stored in a platform-specific way and accessed in a platform-agnostic way that is used to store configurations that seldom change. Confused? Let's break it down.<\/p>\n\n Preference data is stored in a way that's best\/common for the platform the JVM is currently running on. For example, your JVM knows it's running on Windows so the concrete implementation of the PreferencesFactory<\/a> will use the Windows Registry<\/a> to store its data. Other platforms will use what's appropriate for them. This is all OK because the API in the JDK that's used to access the Preference data is the same no matter what platform you're on, and it let's Java make up its own mind release-to-release how best to store these data. The details have been (very appropriately) abstracted away from you to let you concentrate on reading\/writing the data you need to make your application work.<\/p>\n\n So now that you don't have to worry about accessing your platform's backing store, how do I change it? Well, since the data is stored in a way that is platform-specific this may mean you're not able to easily access it without operating system-specific tools. Most of the time that's fine, right? I mean, if you're constantly tweaking your application then that's one thing but if you just care about getting the thing set up and going without worrying about changing things run-to-run, then this is the best fit. For example, to read or change Preferences data in Windows, you'd likely use Regedit and navigate to the key that you wanted to change. Rather than doing that though, this API is easy enough to use and understand that you can write your own tools<\/a> to do the job for you<\/a> using the API and letting your JRE worry about the editing details.<\/p>\n\n The best part about using and editing Preferences in this way is that there is a standard format<\/a> for sharing Preferences data from platform-to-platform. This is totally editable outside the backing store and can be imported to another backing store with relative ease.<\/p>\n\n Preferences are trees. The tree has roots with many nodes. The roots are for scoping the child nodes (either to the current user<\/em> or the entire system<\/em>). The nodes are names under the root. Each node can have another node or a map as children. Finally, a map has child entries that are the key-value pairs of data.<\/p>\n\n The convention for nodes is to name them similar to unix-style paths, naming them with the fully-qualified class name (including the package). For example under the user<\/em> root, there may be a node named There are limitations to the components of Preferences. They're meant to work on multiple platforms and as such they have to match the lowest common denominator for those platforms. So there's a maximum length for the name of a node<\/a>, the name of a key<\/a> , and the length for a value<\/a> as a string.<\/p>\n\n When you compare reading and writing properties files to reading and writing Preferences, you notice that things you used to worry about just go away.<\/p>\n\n The steps you should follow to access a Preference are:<\/p>\n\n If the key-value pair isn't under the node, it will be created in the backing store. Similar to above, the steps you should follow to save a Preference are:<\/p>\n\n This part of the Preferences API represents a small leaky abstraction<\/a> to me. The methods used to save data start with the verb Preferences can be deleted, exported and imported. The export and import operations rely on the aforementioned file format linked in this post. You can check for children of nodes. You can check for values associated with a node. The API is fully capable of doing anything you can think of with a Preference.<\/p>\n\n The great part about the Prefrences API is that it's extensible. See the Preferences API<\/a>. This means that if your IT shop centralizes its settings by putting them in a database or LDAP (as I groused about previously), you can write your own PreferencesFactory<\/a> implementation that connnects to it and manages the read-write operations as well as the data structures. For nearly all purposes though, the default implementation is enough.<\/p>\n\n Fair question. There are the length limitations mentioned earlier. And that editing Preferences requires some tooling (either provided by your platform or yourself). <\/p>\n\n One of the biggest drawbacks is that the Preferences API doesn't scale up very well. You can only associate 1 name-value pair with each node (no Collections-based values are allowed). But depending on how you use them, this should never be a concern.<\/p>\n\n Knowing when to use them too is important. I use Preferences when:<\/p>\n\n Yes I do. See some of the utilities in my Dotfiles<\/a> repository. There you'll see the Preferences tools I wrote to support my applications. Also, see my project pike<\/a>. Preferences fit the way I develop some things. They aren't just for GUI applications. It's one of the little things the JDK has that does the job well.<\/p>\n\n","category":"java"},{"title":"Writing Java Command Line Tools is Cumbersome... Or is it???","pubDate":"Fri, 02 Mar 2018 03:06:01 +0000","link":"https:\/\/dev.to\/argherna\/writing-java-command-line-tools-is-cumbersome-or-is-it--p42","guid":"https:\/\/dev.to\/argherna\/writing-java-command-line-tools-is-cumbersome-or-is-it--p42","description":" The JDK comes with a lot of great command-line tools on its own that support development. But on every project I've ever done I find I need just a little more from a tool that I can't get from it which usually means I have to write my own. Every tool I write is for me and it's usually just enough to do the job.<\/p>\n\n I write a lot of command-line tools to do my extra work. Most Java developers I work with hate the idea of writing a command-line Java tool. They have to be compiled, then they have to be run. Using Maven<\/a> helps with the Previously, I mentioned that I'm a huge fan of Bash<\/a>. All you need is a single Java source file and you can write something useful very fast. Consider this source file: Running this in the shell is as easy as: What happened here? Why was that so easy?<\/p>\n\n The answer is in the comment at the top. Shell scripts often start with a shebang<\/a> interpreter directive. A Java source file with this comment at the top runs the commands in bash.<\/p>\n\n It's easy to see what's going on here:<\/p>\n\n The best part about writing tools this way is that you can make changes to the code and \"run\" it again without worrying if compilation needs to happen. If you have an error, the compiler will tell you where it is and it won't attempt to run your program.<\/p>\n\n Developing tools this efficiently means you should:<\/p>\n\n I've written some tools that have helped me out tremendously:<\/p>\n\n There are tons of things you can do quickly using just the JDK. It may not have all the batteries included<\/a> but it has all the kinds you could find without having to go to a specialty store.<\/p>\n\n I'd like to again acknowledge Jessie Wilson<\/a> whose gist for My examples are in my Dotfiles GitHub repository<\/a>. Look in the Scripts directory and you'll find my tools along with all the other things I use.<\/p>\n\n","category":["java","bash"]},{"title":"Bash Functions and Aliases for the Beginning Docker Developer","pubDate":"Mon, 13 Nov 2017 15:49:06 +0000","link":"https:\/\/dev.to\/argherna\/bash-functions-and-aliases-for-the-beginning-docker-developer-d4","guid":"https:\/\/dev.to\/argherna\/bash-functions-and-aliases-for-the-beginning-docker-developer-d4","description":" I run MacOS for work and Ubuntu for fun. Unix-y stuff has always appealed to me because of its composability and extensibility.<\/p>\n\n I use Bash. Always have. It has plenty of features and is extensible. I used Zsh for a while, but found my way back to Bash after a time because it was important to me for my shell to match the script language I use (and I didn't grok Zsh scripting).<\/p>\n\n Our team at work has recently started a process of migration to an off-premises vendor for hosting. Part of our deployment strategy involves deploying our services and applications to Docker which I've began learning mostly in anger<\/a>. There are new paradigms, commands, subcommands with switches and all kinds of extras that I've never had to think about before. And I've had to think about deployment and management of services more than ever before. DevOps has finally caught me.<\/p>\n\n In this post, I don't describe what Docker is, how to build an image, etc. This is strictly about setting up something useful for learning and running the basic and (for me) most ran Docker commands quickly and easily.<\/p>\n\n Developers have to know a lot about their tools. Sometimes we find ourselves running the same things over and over. Thankfully, modern shells have features that let us combine multiple commands into easy to remember mnemonics that are short and quick to type. Bash in particular has functions and aliases that can be defined in your profile to lighten the cognitive load of learning all these commands.<\/p>\n\n I've started gathering the Docker bits into something that's usable for me and I'm sharing them here with you. What follows is a collection of Bash functions and aliases that I've found useful (that is, when I read my I learned quickly that Functions and aliases in Bash are similar on the surface; you make a mnemonic for a long command. They are very different from each other though and it's important to understand why. See here<\/a> for a quick explanation of the difference between a Bash function and alias. If you've ever got a choice between defining an alias vs a function, the Bash manual says:<\/p>\n\n For almost every purpose, shell functions are preferred over aliases.<\/p>\n<\/blockquote>\n\n\n \n \n Other File Formats and Libraries\n<\/h3>\n\n
\n \n \n How About in a Database or LDAP?\n<\/h3>\n\n
\n \n \n Man, You're Kind of a Jerk!\n<\/h2>\n\n
\n \n \n So what are Java Preferences?\n<\/h2>\n\n
\n \n \n Are These Just Key-Value Pairs or What?\n<\/h2>\n\n
com\/github\/argherna\/LocalDirectoryServer<\/code> where each piece of the \"path name\" is a node under a node. At the lowest level node, there may be a map containing keys and values. The Preferences API lets you read them as Strings<\/a>, booleans<\/a>, integers<\/a>, byte arrays<\/a> and other data types, and it requires you to set a default value if the key-value pair isn't in the map (Preferences don't like null values).<\/p>\n\n\n \n \n Show Me an Example of this \"Platform-Agnostic\" API\n<\/h2>\n\n
\n \n \n Reading a Preference\n<\/h3>\n\n
\n
\n<\/p>\n\nPreferences<\/span> myConnectionPrefs<\/span> =<\/span> Preferences<\/span>.<\/span>userRoot<\/span>().<\/span>node<\/span>(<\/span>\"com\/github\/argherna\/MyApplication\/connections\"<\/span>);<\/span>\nString<\/span> url<\/span> =<\/span> myConnectionPrefs<\/span>.<\/span>get<\/span>(<\/span>\"url\"<\/span>,<\/span> \"http:\/\/example.com\"<\/span>);<\/span>\n\n\/\/ Now start doing stuff with the url.<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n\n \n \n Saving a Preference\n<\/h3>\n\n
\n
put<\/code> which is associated with the Map<\/a> interface. Perhaps that was intentional. If it were, I should be able to get the Map data structure under the node and operate directly on it, then set it back to the node and let the API persist the settings.
\n<\/p>\n\nString<\/span> newUrl<\/span> =<\/span> \"https:\/\/secure.example.com\/\"<\/span>;<\/span>\nPreferences<\/span> myConnectionPrefs<\/span> =<\/span> Preferences<\/span>.<\/span>userRoot<\/span>().<\/span>node<\/span>(<\/span>\"com\/github\/argherna\/MyApplication\/connections\"<\/span>);<\/span>\n\n\/\/ Save the newUrl.<\/span>\nmyConnectionPrefs<\/span>.<\/span>put<\/span>(<\/span>\"url\"<\/span>,<\/span> newUrl<\/span>);<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n\n \n \n Other Operations\n<\/h3>\n\n
\n \n \n What else can this do?\n<\/h2>\n\n
\n \n \n What are the Drawbacks?\n<\/h2>\n\n
\n
\n \n \n Do You Use these Yourself?\n<\/h2>\n\n
\n \n \n Simple Java Tools\n<\/h2>\n\n
exec:java<\/code> goal. Without Maven, you're writing long javac<\/code> commands to compile, then a long java<\/code> command to run it. But if you're careful and stick to what's in the JDK to write a small tool to get the job done, you can use a trick with the shell I saw a few years ago<\/a> to make writing Java a lot more like writing Python. <\/p>\n\n\n \n \n A Simple Bash\/Java Example\n<\/h2>\n\n
\n<\/p>\n\n\/*bin\/mkdir -p \/tmp\/.java\/classes 2> \/dev\/null\n\n# Compile the program.\n#\njavac -d \/tmp\/.java\/classes $0\n\n# Run the compiled program only if compilation succeeds.\n#\n[[ $? -eq 0 ]] && java -cp \/tmp\/.java\/classes $(basename ${0%.*}) \"$@\"\nexit\n*\/<\/span>\n\nclass<\/span> SimpleGreeting<\/span> {<\/span>\n public<\/span> static<\/span> void<\/span> main<\/span>(<\/span>String<\/span>...<\/span> args<\/span>)<\/span> {<\/span>\n System<\/span>.<\/span>out<\/span>.<\/span>println<\/span>(<\/span>\"Hello\"<\/span>);<\/span>\n }<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
\n<\/p>\n\n$ <\/span>bash SimpleGreeting.java\nHello\n$<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n\n \n \n Breaking down the Interpreter Directive\n<\/h2>\n\n
\n
\/tmp<\/code> redirecting output to \/dev\/null<\/code> if the directory is already there (we don't care about an error message).<\/li>\n.class<\/code> file in the target directory we just made.<\/li>\nclass<\/code> file from the directory it was just written to, stripping off the suffix of the source file. But only run it if it compiled.<\/li>\njava<\/code> run.<\/li>\n<\/ul>\n\n\n \n \n Tips\n<\/h2>\n\n
\n
bash SourceFile.java <args><\/code>.<\/li>\n\n \n \n Sample Tools\n<\/h2>\n\n
\n
\n \n \n Acknowledgement\n<\/h2>\n\n
Rip.java<\/code> (linked above) inspired this post. He's a smart dude who likes to get things done quickly (obviously).<\/p>\n\n\n \n \n Where I'm Coming From\n<\/h2>\n\n
\n \n \n Why do this?\n<\/h2>\n\n
.bash_history<\/code> and see the same command run more than 10 times) in working with Docker. <\/p>\n\n\n \n \n Above All Else, Be Aware of Inconsistency\n<\/h3>\n\n
docker<\/code> and docker-compose<\/code> are similar, but at the same time very different. They both share a number of subcommands with the same name. But be warned that the similarly named subcommands don't necessarily support the same options. The evolution of Docker has been exciting since it took the world by storm, but it's come at the cost of consistency in its commands.<\/p>\n\n\n \n \n Function vs Alias\n<\/h3>\n\n
\n