<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Java on Dan Goldin</title><link>/tags/java/</link><description>Recent content in Java on Dan Goldin</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 10 Mar 2015 00:00:00 +0000</lastBuildDate><atom:link href="/tags/java/index.xml" rel="self" type="application/rss+xml"/><item><title>Strongly typed, static language tools</title><link>/2015/03/10/strongly-typed-static-language-tools/</link><pubDate>Tue, 10 Mar 2015 00:00:00 +0000</pubDate><guid>/2015/03/10/strongly-typed-static-language-tools/</guid><description>&lt;p>Good tools are essential for developer productivity. Imagine how tough it would be to write code in an editor that didn’t have any of the features we use on a daily basis - syntax highlighting, smart spacing, shortcut keys, auto completion, etc. It takes time to get used to all the tools available but once we’re familiar with them we’re orders of magnitude more productive.&lt;/p>
&lt;p>For the past year my primary language has been Java although I’ve gotten to do a fair amount of JavaScript, Python, and PHP as well. As great as Sublime is, I’m much more productive in Eclipse. It has nothing to do with the editor and everything to do with the language. Eclipse is able to provide a lot more functionality due to Java’s static, strongly type nature. Some examples are being able to quickly rename variables and methods, move packages, and quickly identify dumb mistakes in method signatures and typos. I suspect similar tools exist for weakly typed or dynamic languages but I can’t imagine them working as well as they do in Eclipse. Strongly typed and static languages are able to get rid of an entire class of errors that are common with scripting languages - typos, forgetting to add an argument to a method call, messing up a type - that the time saved typing gets replaced with the time spent debugging. For many tasks this tradeoff makes sense but larger projects that involve multiple developers and require higher performance would benefit from moving to a strongly typed, static language.&lt;/p></description></item><item><title>Getting the most out of log4j</title><link>/2015/02/28/getting-the-most-out-of-log4j/</link><pubDate>Sat, 28 Feb 2015 00:00:00 +0000</pubDate><guid>/2015/02/28/getting-the-most-out-of-log4j/</guid><description>&lt;p>Something that’s incredibly helpful when writing Java code is customizing &lt;a href="http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html" target="_blank">log4j&lt;/a>. There are a variety of configuration options and learning just a little bit about them can make you notably more productive. I’ve found two features that have sped up my development cycles.&lt;/p>
&lt;p>One was updating my PatternLayout to include the filename and line of each message. With Eclipse, this allows me to quickly jump to the relevant code block whenever anything looks odd rather than having to first open the file and then search for that particular message.&lt;/p></description></item></channel></rss>