• Unable to access the selected application.
• Exception in AppMerge flows’ progression

Baffled, I almost gave up – the errors mean nothing.

Thankfully trial and error (and plenty of web searching) I have discovered that the errors are caused by invalid deployment descriptors or invalid WAR/EARs (an empty WAR or EAR will cause these errors immediately). So don’t fret, it’s not the end of the world!

First check your web.xml, application.xml and then ensure the contents of the WAR/EAR are as expected – APP-INF, META-INF only for the latter!

Hope that helps someone, it annoyed me for a while!

I therefore decided to implement an Ant Task for parsing TODOs in source code. You can read more about it over on the Google Code project. Please feel free to review code, suggest features or try it out and report a bug.

Happy new year to all; many happy returns.

See you in 2010!

Note, $SKY_SONGS_DIR should be changed to your installation directory. If you used wine to install Sky Songs, have a look under /home/YOURUSERNAME/.wine/drive_c/windows/profiles/YOURUSERNAME/Local Settings/Application Data/Sky  Songs/.

Sky Songs works by giving you “SKS” files that describe to its client (“Sky Songs MP3 Downloader“) what and how to download; i.e. your songs. Once you’ve downloaded one (say Renegades.sks; the “Renegades” album by Rage Against the Machine), just execute the skysongs script as follows:
alex@prometheus:~/Music$ skysongs Renegades.sks

Thankfully the Sky Songs download client is written in Java so it’s not only cross-platform but its structure is obvious.

Please note that these instructions are absolutely not intended for circumventing Sky’s download procedure, nor are they to be used to break the Terms of Service you’re most likely bound to by law. This information is purely for educational purposes and to assist those who are new to Linux get to grips with their everyday software in a new environment.

This time round I’ve been learning Common LISP and now Scala. Being a Java programmer professionally it makes sense to try the latter. I love the idea of it being its own language – for scripting as well as fully-fledged development – that can run inside the JVM (or if you’re evil, the .NET CLR).

First impressions are that it’s exciting to learn. I love its simplicity, and its productivity. One thing I do hate: the syntax of array indexes. I can’t for the life of me think why it’s a good idea. I like the [] syntax because it makes it explicit as to what you’re working with. Doing array(1) looks like a method call, not great. Sure I’ll find out soon enough as to why it’s done that way.

I wrote the following today whilst waiting for my Grilled Mackerel to finish soaking :)

#!/bin/sh
exec scala $0 $@
!#
args.foreach(arg => for (c <- arg) println(c))

Would set the logging level to DEBUG for all registered loggers in classes net.beplacid. Similarly:

log4j.logger.net.beplacid=FATAL

Would disable all but FATAL logging calls.

Hope that helps someone, I couldn’t find an ‘easy fix’ page when searching…

Background

Before I start, I want to explain my programming background with Java and other languages, so this post isn’t regarded as Just Another Flame ™.

I am a Sun Certified Java Programmer, and have been contracting for 3 years here in the UK. I have worked for two large companies (no names) that have given me excellent experience with the Java programming language and its use in the Enterprise tier. As well as Java, I have been required to develop in SQL (both Oracle and MySQL, as well as MS-SQL), Perl (CGI and scripting), BaSH and the usual web design/development languages HTML, Javascript and CSS. I have recently taken to learning Python, the high-level dynamic object oriented programming language, and doing so has prompted me to post this article.

Common Misconceptions

A lot of the Java doubters out there tend to blow the same trumpet; sing the same tune; fuel the same fire – that is, they all say ‘Java sux!!11′. The problem with this, is that Java is all of three things: a programming language, compiler, and virtual machine/interpreter. This means that those blabbering on about how ‘Java sux’ don’t direct their comments at what particular part they dislike; that is whether they hate the language itself, the compiler or the interpretor. Not only is this an inaccurate flame, but it’s usually bellowed by those who have very little to no experience with the programming language or its uses. At best, they’ve tried to run a Java program and due to their own lack of understanding or misconfiguration, it hasn’t worked. However, some people who flame it do know the language and its software components and therefore have an educated opinion. I prefer, and indeed regard myself as, the latter.

One of the other wondrous clauses that Java-haters tout, is that it is slow. Well, they’re mostly right. Again there’s more to it than just speed. The first releases of Java were very slow. Fact. However, the latest releases (Java 5 & 6) have added language features that speed up the run-time execution of Java code – namely parameterisation of types, auto boxing/unboxing of primitives to objects – by forcing compile-time checks as opposed to run-time checks of types (the old object cast when adding/retrieving to/from collections is now unnecessary). Whilst these features do speed things up, Java is still relatively slow.

Now, on to the flame…errr, constructive criticism.

Java’s too Strict

Java has prided itself on two things – strict object orientated design (OO) and ‘Write Once, Run Anywhere’ multi-platform availability – and has been both accepted and rejected on the merits/pitfalls of these features. I don’t actually see anything wrong with OO design. In fact, it’s my preferred software development approach. The issue with Java’s strict OO design, is that it’s very difficult to program otherwise. You’re forced to stick to OO practices whether you’re writing a quick hack, or a fully-fledged framework, and this forces its usefulness to be restricted. This isn’t the case with Python. It’s so dynamic and productive to write, that it can be used to write a quick backup script or large back-end services.

Java is also a strict-typed language. This means that at instantiation, objects are given a type (or ‘class’) and the compiler enforces this. If an object needs to change type, it must do so through the ‘Polymorphism’ object oriented design approach. This is enforced by Java at runtime. It’s another extension of Java not allowing you to make the decision over what software design approach you’re going to take – procedural or object oriented – so you’re stuck from day one. Languages like Python and Ruby are not strict-type. This means the programmer has more flexibility (but has the overhead of ensuring specific types at runtime, and checking thus) over how specific aspects of a program treat information.

Java’s too ‘wordy’ – a.k.a Verbose Syntax

The nature of OO design means that more code is written to define objects and their relative connections. Java does this well, with a nice object hierarchy, but it’s a victim of its own design and conventions – accessors/mutators (‘getters’ and ‘setters’) mainly – whereas in languages such as python, the convention isn’t to use this approach, but to expose an object’s properties either by direct dot notation, or to define it as a dict. You can still do this in Java, but obj['val'] is much easier to write than ‘obj.getValue()’. You might see this as a moot point, something that’s purely implementation specific, but in reality anyone that knows how to write Java, will stick to the strict convention that objects should hide their underlying implementation. This is definitely a good approach to software design, but in practice it becomes too much of a burden on a programmer to write and use such design aspects. Not to mention it doesn’t bode well with the 80 character per line rule…

Another example of Java’s ‘wordy’ syntax is the Collections API. Once touted as its glorious achievement, the Java Collections API was an outstanding set of objects aimed at providing objects – an extension to the typical array – that provide easy, OO and fast access to a collection of objects. With the emergence of other languages however, the Java Collections API has become rather stagnant due to the language’s lack of dynamic syntax. Below are two examples, one of defining and iterating over a list in Java 1.5 and the other iterating over a list in Python 2.5:


List<String> list = new List<String>();// define a List that contains only String objects
list.add("Herro");
list.add("Moo");
list.addAll(myOtherList);
for (String str : list)
System.out.printf("Item: %s\n",str);


And the exact same operations in Python 2.5:


list = ['herro','moo']
list.extend(my_other_list)
for item in list:
print "Item: %s\n" % item


4 lines of code, or 6? Stretch that out over a large application (what application these days wouldn’t use lists or maps?), you can see that code written in Java would become quite large, purely because of the language’s syntax. Programmers like to program, they don’t like having to write more than they need to. Python allows you do write exactly what’s needed, and without having to write 100 words to do so.

‘Write once, debug anywhere’

The ability to run an application on any operating system without the need to recompile is a nice idea. Java’s main selling point is that it has this ability. Initially this was a useful and much desired feature of the language because not only did it work, but it was at an age where the Web was booming (pre-2000) and new technologies were on the uptake. Nowadays, the platform is the Web. This means you don’t necessarily need inter-platform abilities from a language and compiler/interpreter. You just need a working web browser, and an internet connection. Indeed, with the rapid adoption of AJAX (Asynchronous Javascript and XML), web sites are now replacing the desktop application. Software As A Service (SAAS) is now the forefront of software development and business aims, and the need for desktop applications becomes ever smaller as more and more websites offer an abundance of features from the web browser – just checkout GMail, EyeOS or Google Maps – and you’ll experience feature rich applications, all in the comfort of your web browser.

What’s next?

Undoubtedly Java will remain a large part of the industry for the next few years. Sun are a large and powerful company, and are good at keeping things alive. Not only that, but they’ve recently released Java under the GPL , so it’ll be around for a while yet. Some might say that this was part of a clever marketing campaign to get people back in to using Java. Either way, I can really only see its demise as more dynamic, open source, reliable technologies take the driving seat.

Java still has a large place in the enterprise market. According to this site, it’s the number one language (in terms of job opportunities, third-party vendors and courses); but as with all statistics, i’d take that with a pinch of salt.

Summary

I’m not a Java-hater. It’s paid my bills for the past few years, so I owe it some credit. Due to my recent adventures with Python though, I immediately saw the flaws in Java. Python makes things quick to write. It’s powerful, ever maturing and more to the point – it’s open source. I think Java will stick around for the foreseeable future, but its original merits are no longer going to keep it alive…