Frank Carver's musings about software and life
It’s a long-running argument. Are modern, dynamic, languages such as Ruby and Python really much more concise than more mainstream languages such as Java? What constitutes “big” in each case? Stephan tries to flush out some hard facts, and gets a lot of comments.
I started the day cursing the stupid jar format, but ended the day smiling. I needed to build a stand-alone executable jar which accessed a MySQL database but kept getting all sorts of build-time and run-time errors.
Normally to make an executable jar I use the excellent pack ant task which build a minimal jar file by trawling all the class dependencies in yout code and including just the required classes from the classpath. For example:
<target name="jar"> <taskdef name="pack" classname="org.sadun.util.ant.Pack" classpath="lib/pack.jar" /> <pack classes = "${root.classes}" targetJar = "dist/${project.name}.jar" manifestMainClass = "${main.class}" excludePkg = "java,sun" includePkg = "com,org,javax" > <classpath refid="classpath"/> </pack> </target>
Just set up the main.class property to the main class of the application, and set the root.classes property to a class which refers to everything you need (in many cases this will be the same main class) and you get a lovely small executable jar.
However, trying this approach with MySQL cause a bunch of problems. First I needed to add a load of (apparently dynamically loaded) MySQL class names such as com.mysql.jdbc.Driver.
I thought I was doing well when I had resolved that issue, but then I hit an even harder problem:
java.lang.RuntimeException: Can't load resource bundle due to underlying exception
java.util.MissingResourceException: Can't find bundle for base name com.mysql.jdbc.LocalizedErrorMessages, locale en_GB
Despite spending an hour or so searching and trying, I could not convince pack to find it. So I had to look elsewhere.
The solution I eventually chose was “one-jar” – a trick which subverts the normal jar execution process and creates a custom classloader to resolve jars within a jar. I still use pack to minimise the amount of other classes included in my project, but explicitly include the whole MySQL driver jar.
My ant target now looks like:
<target name="jar"> <taskdef name="pack" classname="org.sadun.util.ant.Pack" classpath="lib/pack.jar" /> <pack classes = "${root.classes}" targetJar = "tmp/main.jar" manifestMainClass = "${main.class}" excludePkg = "java,sun" includePkg = "com,org,javax" > <classpath refid="classpath"/> </pack> <taskdef name="one-jar" classname="com.simontuffs.onejar.ant.OneJarTask" classpath="lib/one-jar-ant-task-0.96.jar" onerror="report"/> <one-jar destfile="dist/${project.name}.jar" manifest="src/main/files/${project.name}.mf"> <main jar="tmp/main.jar"/> <lib> <fileset file="lib/mysql-connector-java-5.0.4-bin.jar"/> </lib> </one-jar> </target>
This builds all of my application except the MySQL bits using pack into a temporary “main.jar”, then uses one-jar to build another jar which refers to both main.jar and the MySQL driver jar.
I did need to create an explicit manifest file this way (usually, pack is smart enough to make it for me)
Main-Class: com.simontuffs.onejar.Boot One-Jar-Main-Class: org.example.project.Main
I now have a working stand-alone executable jar which can access a MySQL database. Cool.
Read more at Deliver Your Java Application in One-JAR™ ! and Java: Using ONE-JAR
Scott Selikoff recently posted that we should “never return null arrays”. I’m not sure I entirely agree. Both the tone of the article and the comments so far seem to be in agreement, but I am still not so sure.
I’ll skip the terminology issue for the moment, just note that an array in Java is different, in syntax, interface and implementation, from a Collection. Scott’s article seems to discuss Collections rather than arrays.
As far as I am concerned, there is a qualitative distinction between a Collection which exists, but is empty, and a collection which simply does not exist (i.e is null). I’ll grant that in many situations they should result in the same action or output; but not always.
Imagine parsing XML documents. Consider the following three cases:
<result> </result>
<result> <stuff/> </result>
<result> <stuff> <item id="1"/> <item id="2"/> </stuff> </result>
I suggest that first and second cases are different. It’s relatively easy to imagine that some software should behave differently in the case where the “stuff” block is not present at all, and in the case where it is present, but empty. A simplistic example might be that in the second and third cases a “Stuff” heading is rendered on a web page, but not in the first one.
If that abstract example is not enough to convince, consider the more practical example of an “all you can eat” buffet restaurant (pause for a Homer Simpson “mmm … buffet“). The way many of these places work is that when you arrive you pay a flat fee and receive an empty plate. You may then take that plate to the food and fill it with whatever you like. If you do not have a plate, you have not paid, and so can neither physically nor contractually fill it with food.
In this example the plate represents the collection. The state of having no (null) plate is very different from having an (empty) plate. The restaurant staff would be wise to know the difference.
Just for fun, here’s some java to illustrate:
public class Diner { private Wallet wallet; private Collection plate; public Diner() { wallet = new Wallet(); } public void pay(Cashier cashier) { Money fee = wallet.extract(cashier.getFee()); this.plate = cashier.payForPlate(fee); } public void selectFoodItem(Buffet buffet, Object item) { if (buffet.contains(item)) { buffet.grab(item, plate); } } }
public class Buffet { public boolean contains(Object item) { return true; // the ultimate buffet :) } public void grab(Object item, Collection plate) { if (null == plate) throw new RestaurantException("This is not a soup kitchen! Pay first or hit the road"); if (plate.size() > 10) System.out.println("I see you brought your big plate, Alan"); plate.add(item); } }
The bottom line is that while the Null Object pattern is a very useful pattern, it should not be used indiscriminately. Just like any pattern, really.
Never return Null Arrays! | Down Home Country Coding With Scott Selikoff and Friends
I look forward to more thought-provoking posts from Scott and Jeanne!
So the question is: are dynamic-typed languages (ruby, python, smalltalk, etc.) easier or harder to maintain than static-typed languages (Java, C#, etc.)? It seems there are arguments both ways.
On the one hand, dynamic languages tend to be a bit more concise, and reducing code size is a great way to simplify maintenance. On the other hand static languages typically support better and more intelligent tooling, which is also a great way to simplify maintenance.
Ola Bini has some thoughts, but has so far been unable to come up with any hard data one way or another. is there any?
The Maintenance myth | Ola Bini: Programming Language Synchronicity
This looks very interesting, even though I have a few questions to answer when I evaluate it properly.
@me&java » Building scalable server in 20 lines
I’m particularly interested how MINA stacks up against Grizzly, as they both seem to be addressing the same problem – a high-performance Java server using newer IO facilities.
Currently my Mojasef framework works in three ways: a server-less version for unit testing, a simple stand-alone server for embedded use and integration testing, and as a servlet inside a servlet container. A flavour which works closely with one of these high-performance servers might be a good addition.
Ted Leung reports on the broad spread of interesting languages available on the JVM these days. Several that I had not heard of, too.
The First Annual JVM Language Summit at Ted Leung on the Air
We use ant, a lot, but I’m getting progressively fed up with it so I’m looking for alternatives.
Ant has several well-known problems, including:
I have recently investigated three alternatives:
gant, gradle and pjmake. Gant and gradle both aim to replace ant with a build system scripted in interpreted Groovy. Pjmake aims to replace ant with a build system scripted in compiled java.
Ever wanted to make a “screencast” (a recording of some on-screen activity, with or without a commentary, typically used for software tutorials)?
I have done a few, but found choosing and configuring screen-recording software to be trickier than it should be. If you also find it a bit cumbersome, then this might be of use – an on-line screencaster which both records and plays using Java.
I’m cross. Very cross. Cross with Sun for releasing a new version of Java which shatters both backward- and forward- compatibility. Cross enough that I cannot see any sensible way of moving my software to Java 6 in the near future.
It all started with an innocuous question in a comment on my Punchbarrel blog. I had posted asking for opinions on a move to Java 5, potentially abandoning Java 1.4, for the core Stringtree codebase. The question in the comment was about skipping Java 5 and moving directly to Java 6. This would normally be too big a leap, but I replied that I would endeavour to continue my policy of ensuring my code works with as wide a range of Java versions as possible.
Then I actually tried to do it, and that’s what made me cross. The more I attempted to produce code which would compile and run on Java 1.4, Java 5 and Java 6, the more impossible it began to seem.
I was already aware of the first hurdle. Sun have added new methods to a lot of key JDBC interfaces by tagging them with the new javax.sql.Wrapper interface. This is actually relatively easy to fix in a compatible way. Just add two new methods to each class which implements one of the affected JDBC interfaces:
public boolean isWrapperFor(Class clz) { return false; } public Object unwrap(Class clz) throws SQLException { throw new SQLException("Not a Wrapper for " + clz); }
The actual method signatures in the Java 6 Wrapper interface are phrased in terms of Generics, but the above stripped version compiles fine using Java 1.4, Java 5 and Java 6 compiler and libraries.
However, even after adding these arguably pointless methods to all my concrete implementations of affected JDBC interfaces, I still had a bunch of compilation errors when using Java 6 libraries. And this is where Sun have really screwed up.
Several other key JDBC interfaces have also been extended. But this time it has not been done by anything as simple as tagging with a new interface. These interfaces have all gained extra method themselves. This should not be a deal-breaker. It should be feasible to just add implementations of these methods to the existing Java 1.4-compatible code. After all, any class is free to define any methods it likes, not just those from an interface.
Nope.
It is simply impossible to add these new methods to a class and have that class still compile in a Java 1.4 or Java 5 environment.
The reason is that these methods are themselves defined in terms of classes and interfaces which do not exist in earlier Java versions. For example, the java.sql.Connection interface gains methods referring to new interfaces NClob and SQLXML
There is no answer to this. Sun have broken backward and forward compatibility of JDBC in Java 6. It is no longer possible to write an implementation of several key JDBC interfaces in a way which compiles under all the most popular Java versions.
Once again, Sun completely misunderstands the real world. Not everyone is free to upgrade every deployment to the very latest Java version immediately it is released. Even within those who do manage to update all their machines in one go, not everyone can immediately drop real work to spend time messing with old code which should still work to bring it into line with a new fashion.
As I wrote at the start of this rant. I’m cross.
Grrr.
A major goal of the Stringtree software project has always been to be as compatible as possible with all the software people are using for their Java development. Naturally that also includes whatever Java version is being used.
For a long time I interpreted this goal as implying that all Stringtree code should run on all Java versions from Java 1.2 onwards. Java 1.4, however, introduced some compelling new features including built-in regular-expression handling. For a few years I still tried to ensure that most code was still 1.2-compatible (for example by using Ant to swap in a third-party regular-expression library while building a jar file), while also providing a Java 1.4 version. Eventually, use of Java versions prior to 1.4 declined enough that I felt comfortable removing the complicated pre-1.4 version.
For the last few years I have been very careful to keep all my Stringtree code compatible with all versions of Java from 1.4 upwards. Now, however, the pressure is building again to move over to Java 5. In my day-to-day coding I develop with Java 5 and make increasing use of Java 5 features such as the enhanced for loop, the Iterable interface, enums, generics, autoboxing, varargs and so on. It would be very nice to be able to update the Stringtree codebase to use these features too.
Occasionally a Java 5-specific detail has crept in to a Stringtree library, and I have soon received comments or emails pointing this out. I haven’t noticed this for a while, which might indicate either that I have been especially careful, or that I there are no longer any/many people developing with Stringtree code who are still limited to Java 1.4.
If you are reading this and you still require Java 1.4 support, please let me know. Likewise, if you have thrown off the shackles of 1.4 within the last year or so or are desperately hoping for a Java 5 Stringtree that would be good to know too.
Is it time for Java 5 yet?
A few years go I wrote a series of articles for The Java Ranch Journal entitled “Small and Simple Web Applications – the Friki Way”. The series showed an example of developing a very simple wiki (collaborative editable web site) in Java using Test-Driven Development (TDD) and a form of agile project management.
From time to time I refer someone to these articles but it has been tedious to find and gather all the individual article links. This post contains those links, so I can just give out a single URL in future.
Unfortunately I never got around to continuing the series beyond that point. Maybe one day I should …
Mockito is a Java Mock objects framework which seems more usable than either of the main contenders (JMock and EasyMock). The project has just released a new version which now allows the attachment of a mock “overlay” to an existing object.
This has been on my “evaluate” stack for months, but (as Harry Pynn pointed out when he “vouched for” me) I tend to be more comfortable with “classic” TDD and don’t usually find much use for Mock Objects.
I have had a quick play with the examples of use on the Mockito site with mixed success. many obvious cases work well, but there are also some gaps in the way it works. For example, consider this small example test:
import static org.mockito.Mockito.spy; public class PlaypenTest extends TestCase { public void testMockito() { List real = new ArrayList(); real.add("first"); real.add("second"); List ml = spy(real); stub(ml.get(0)).toReturn("huh"); assertEquals("huh", ml.get(0)); assertEquals("second", ml.get(1)); } }
It works correctly. However, the following idiomatic and functionally similar simplification throws a complicated internal exception in the “spy” method.
import static org.mockito.Mockito.spy; public class PlaypenTest extends TestCase { public void testMockito() { List real = Arrays.asList(new String[] {"first", "second"}); List ml = spy(real); stub(ml.get(0)).toReturn("huh"); assertEquals("huh", ml.get(0)); assertEquals("second", ml.get(1)); } }
Maybe I’ll get around to using it for something. I’m still not sure.
A report of a presentation at a user group about Java Enterprise Edition (JEE) version 6, written in slightly unusual language – I can’t quite imagine that the main reason to try Spring is “to get high”.
I tend to agree with the author that a JEE “profile” with servlets, messaging (JMS) and transaction management would be a very useful idea, though. Despite the improvements and the hype I still have not found a compelling use for EJB other than a brief flirtation with message-driven beans
Steve Freeman recently wrote about some of the perils of passing around a “context” object, from which different parts of the code may extract the collaborators they need to do their job. This approach is one form of “dependency injection”, a technique which decouples code from specific implementations of its collaborating classes and allows any compliant implementation (such as a “stub” or “mock” for testing, an updated version, or simply a version which works differently) to be used instead.
Steve describes an example of using such a context object, then points out some possible problems, then offers some refactoring options to remove the need for the context object in such cases. Within the parameters set by Steve’s post, his solution has merit, but I really don’t feel that the “straw man” problem he raises is representative of all uses of this technique.
The form of context object chosen for Steve’s example might be referred to as a “strongly typed” context. In such usage each object available from the context has its own unique accessor. Addition of a new object to the context requires a change to the context itself. This approach is common when the use of the context object is a direct replacement either for some other form of dependency injection or for a hard-coded object creation in the utilising class.
However, there is another form of context obect, one which might be referred to as a “weakly typed” context. In such usage the context provides general-purpose accessors and the client code is responsible for ensuring (using a cast, introspection, or some other technique) that the retrieved collaborator provides the required facilities. Addition of a new object to the context requires no change to the context itself – typically the object is placed in the context with a name, and a general purpose accessor allows retrieval of any object by name.
In my experience, this form of context is more common in software built using a “core and plugin” architecture. In such an architecture, the “core” is generic, providing features to control or support unknown code in the plugins. This is a powerful and flexible architecture, but if implemented naively can result in the core needing to be changed for every change to, or addition of, a plugin. A more robust approach is to ensure that the core is general enough to work with whatever is needed by all the plugins, even those implemented after the core was written. In order to achieve this, the core must usually have some way of passing information from plugin configurations to plugin invocation, and potentially from one plugin to another. If this is to work for unknown objects, it cannot be expected that every possible configuration value will have its own context accessor.
It is my opinion that in in cases such as this, a weakly-typed context object is still the best choice. Even though any particular client code may use hardly anything from the context, the fact that the context is there, and contains everything required, enables valuable code to continue to be written and used long after the context class was created.
For Steve’s original article, see: Unpack the bag | Steve Freeman
A discussion of the benefits and disadvantages of single vs multiple returns from a method cropped up today. Unfortunately we became distracted before getting to the meat of the opinions. To help stir up that discussion again, here’s a link to an article (and follow-up comments) from Mark Levison’s blog.
Notes from a Tool User: Multiple Returns from a Single Method
It should come as no surprise that you need to keep your wits about you when you write software. But the wise programmer should also be wary of blithely adopting any kind of “best practice” without considering the implications. Here’s a cautionary tale about a case where doing things as it appeared they “should” be done resulted in a performance problem.
This looks interesting, but I have not had the time to look at it yet.
Despite several brushes with it over the years, I have never really worked with Lisp enough to “get it”. It’s certainly interesting that this language from the relative dawn of software is still around and still compelling enough to prompt new implementations and new support tools. Maybe I should try again and take another look.
This looks like an interesting dynamic class-loading solution, potentially in the same sort of space as Impala, which I have mentioned here before.
I can’t really think of a use for this rightnow, but it looks useful all the same, so I am filing it here in the hope that it will be easier to find if/when I do need it.
In one place both capturing from the screen in Java, and generating a flash animation from the resulting data. Neat.
wuetender-junger-mann.de » Blog Archive » A Screen Camera in Java