I was on the verge of taking my work laptop in for a severe servicing with a cattleprod when I googled this bug and found my ire was poorly directed at my innocent Dell. Deleting all the install zip files I had downloaded from my Desktop found me back and running in reasonable time.
What a crazy bug! It is kind of incredible that it hasn’t been fixed yet.
I know this isn’t exactly breaking news but it is further evidence that Sun is aiming to turn the JVM in a language agnostic platform. It’s also good news for the Jython project which has suffered a long period of hibernation and which has fallen far behind CPython in terms of its compatibility.
I like Python as a language and its clarity is great for one time scripts (which never really are). I would really like it to be a full member of the JVM-compatibles.
Joshua Bloch of Effective Java and Collections fame has given a powerful and in many ways depressing talk. He has probably nailed the coffin shut on BGGA with this almost clinical dissection of the flaws of grafting Closures into Java. However he has also indicated how Java is effectively at the end of the line. Sun, for perfectly good reasons, wants to maintain backwards compatibility and not throw the kitchen sink into the language. The JCP does not have to stick with that approach but this talk does effectively say that there is a limit to what can be done while keeping the language recognisably Java.
The mention of Scala is significant because a lot of the things that people want in Java are available there and other features are in JRuby. Trying to create one language with universal appeal is going to be impossible. The reason I feel depressed about all of this is because I have working with Java for years now. I really had to fight to switch to 100% Java and now its time to move on again!
It would be easier to do that if there was something that was obviously better but currently all of the candidates for a potential successor have lacked that Eureka factor where you see something that is going to make programming easier and better and your working life a whole lot more fun. So far only Scala has really come close.
I have recently struggled to try and get a prototype web application done with Ruby on Rails. It has been a really great experience and like all such experiences consists of both good and bad moments. Things that are particularly striking coming from a Java Web environment:
It is also remarkable how quickly people revert to the level of thought, planning and execution that you might use for a shell script. Even I have found myself getting caught up in “playing” with the app interactively rather than being focussed on creating behaviour and functionality in a structured way.
Elaborating on these points; in Java web development the first issue is usually building up your component stack. Some people just choose Spring but those people are idjits! If you are working purely in a web tier without any need for any backend interaction then it is probably a good bet but generally you want to put some thought into how you are going to assemble your various stacks. You tend to have to choose your MVC web framework, your persistence framework and your service framework (if appropriate). You often have to give some thought to your caching and messaging frameworks if they are relevant.
With Rails you just use the appropriate Active Module or Rails built-in features. If there is something that is going to ease some pain for you then it is going be operating as a plugin. That’s it, no framework holy war. It also means that there are a lot of applications that are just not going to be suitable for a Rails application as all those Java components have various strengths for different environments. I certainly wouldn’t want to tackle a legacy database with ActiveRecord for example. Not that it couldn’t be done but I wouldn’t want to do it.
The zero-turnaround is impressive after the build-deploy-check cycle. It was a wow factor last year when I saw the Phobos framework being demonstrated by Sun and its not lost any of its shine. By separating its deployment environments so ruthlessly Rails is able to deliver a really positive developer experience.
The interactive console takes a bit of getting used to in terms of faking browser requests but once you get used to doing so it is another tool that you wonder how you’ve managed without for so long. It’s much more intuitive to use than setting up a remote Java debugging instance (although admittedly you do similar tasks in both). It allows you to scratch those itchy “why?” questions.
And finally that lack of programming skill? A bit controversial perhaps? Well I feel that in recent weeks what I have been learning is how to manipulate Rails. The fact that it is implemented on Ruby may allow a lot of features to be implemented in the way they that they are but you are very rarely called upon to show Ruby madskillz. Instead the majority of the time you are simply plugging little customisations into the Rails framework. It is called Rails for a reason after all, when you are on them you are amazingly productive but if you can’t package your problem into a Rails solution then you are out of luck, you’re going to have to develop your own solution and that is going to be hard work. I have been trying to develop my Ruby skills (that is a whole other story) but the truth is you can bang out something that is acceptable with very little Ruby knowledge. You can go a lot of the way purely by mastering Ruby’s hash syntax.
So have I been converted? Well for all its problems I do have a hankering to get back to my great big Java applications with their holy wars and heavyweight processing. After all being on the Rails is fine for getting things done quickly but it can feel claustrophobic. I am also really glad that after getting distracted by the whole JSF controversy the challenge Rails presents to the status quo of web development means that a lot of the Java frameworks are starting to respond to the real problems faced in web development and ensuring that the easy stuff should be easy.
I have used all manner of organisation tools but at the moment the one that is really working for me (and indeed which is telling me I need to write this post) is Thinking Rock. A Java application based on the NetBeans RCP that implements the GTD process.
The basic elements of the application are okay, focussing on quick capture of thoughts and providing enough tools to correctly categorise them. However it is in reviewing and working on your actions that the application really shines. A single screen allows you to review and organise both projects and tasks. The filters for managing tasks are excellent and really make it possible to work with hundreds of thoughts and ideas at the same time. Better yet as a Java Swing programme you get exactly the same functionality and features on OSX and Windows allowing me to use it on all the various computers I own or use at work. A fully-fledged version 2.0 is promised soon but the development version I have been using has been completely stable and fully featured for my use.
I thoroughly recommend it to anyone else with a cross-platform need.
I decided to give OpenJPA another go now it’s all incubated and promises that running agents are the way of the past. Before I can really try any of that though I have a huge problem with my persistence.xml file not being parsed. I had this problem last time I tried OpenJPA and it took me ages to solve then as well.
I ended up looking at my own blog for any clues as to how I fixed it; I was infinitely recursing up my own arse. Anyway to help improve my Googling for a solution in future… If you are using OpenJPA and you get the following error:
cvc-elt.1: Cannot find the declaration of element 'persistence'.
Then replace the first persistence tag in the following way:
Not <persistence> but
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
This simply defines what the Schema should be for the persistence unit. To understand why you’re doing this see this post. Note that the post is titled Dumb User Question but it’s really not, if you look at the example persistence file given in the documentation you would forgive anyone for making this mistake.
Before Christmas I decided to give the Groovy Swing Builder a go since I am in the market for a language that makes creating small utilities in Java easier. Groovy is now Groovy 1.5, fully aligned with the Java 1.5 release. The new release sees lots of improvements all over the place. The Groovy Console has had a substantial revision and is now a really good way of experimenting with more complicated scripts (previously I only really used it to run snippets of code). The text colouring and decoration really works and the previous problems with massive stack traces obscuring actual issues seem to have been fixed. Really there are just two things that are needed to make it perfect, the first is line numbers so you can relate error messages back to the script you are working on and auto-completion. I wouldn’t mind having tabbed editors in the console as well but I can live without it.
What hasn’t changed is that documentation is generally woeful and examples and tutorials are hard to find. Most of the Swing examples I could find really used small numbers of components and simple Layout Managers. I have tried to create a more complex example using Grid Bag and based around some existing Swing code I found.
It took me a lot longer than I thought it would to create this code. Part of this is just not knowing how to tackle things, Groovy allows you to set attributes within the constructor with the interesting syntax property: value. However it is hard to know when you should use this or when the interaction should occur within the braces. After getting a working example going there is only one major mystery to me here. If I do not put the table inside the scroll pane then I lose the header columns on the table in the second tab. I really cannot see why that should be and if anyone more versed in the language can help me I would be grateful.
Okay so I currently I am setting up a number of databases on my own V-Server and I thought it would be helpful to make a few notes about the current Java databases and how easy they are to run in Server mode. The two biggest databases are Derby and HSQLDB, this post is about Derby. Both databases are really geared towards the embedded space and generally focus their documentation and tasks around this. In their default setups they are both pretty insecure for running on a public network, neither for example defaults to using passwords to authenticate logins.
All the databases are getting setup in the same basic way. Each database is going to be run in the userspace of a dedicated UNIX user and that user is meant to be accessed via SSH and SSH Keys. All the datafiles will reside within the user’s space. I’m not going to go into that as it is fairly straightforward and is probably better covered by the various UNIX admin guides you can find around the internet.
So Derby first then, well I have played around with Derby before so I hoped this would be the easiest. One thing that you need to know about Derby is that its documentation is good but it is organised into several different documents… by a madman. There is no apparent logic, rhyme or reason to the way information is included in one document or another. When setting up the server I had to jump between the Developer’s Guide, the Tuning Guide, the Server Guide and more unusually the Tool Guide. If you have the same experience then don’t worry, you’re probably doing it right.
Having downloaded the Derby package unpack it to the root directory. I find it helps with upgrades to create a symbolic link ~/derby to the actual installation directory. You can also create a profile environment variable DERBY_HOME that points to $HOME/derby.
With that all setup you can simply run ~/derby/startNetworkServer and you should be in the basic network server business. This is where it gets a bit more complicated. Derby will look for its configuration in the directory where you start it not in DERBY_HOME. So you need to create a derby.properties file in $HOME to configure the behaviour of the server.
To require authorisation you need to properties created in the properties file. Remember that the format of this file is a standard Java properties file. The two properties are:
You should now restart the server. Now when you want to interact with the database you should need to provide a username and password. You have to check this though to make sure it works.
Run the ij tool from the command line: try to create a new database with something like the following
connect 'jdbc:derby:test;create=true';
You should get a message saying something like ‘Invalid authentication’. If the database is actually created then the database is probably not picking up your properties file, which in turn is likely to be an installation issue.
All being well we can now add a user to the properties file. User information is also a property so to make the file manageable you probably want to use comments to divide up the file into relevant sections and try and keep all the user setup in the same place. The format of the user entry is derby.user.USERNAME=PASSWORD. So for example
derby.user.test=changeme
Okay now restart the server and login via ij again. This time use a connection URL like the one below.
connect 'jdbc:derby:test;create=true;user=test;password=changeme';
This should now create a new database under HOME and give you access to it normally. Drop out of ij and confirm that the test directory has been created.
That is pretty much that now, from here on in you can connect to your server database instance as you would any other database server.
Written like this the setup must seem very basic and quick to perform, which is good. However when I was finding my way with it, it took over an hour and most of that time was taken up with looking for things in the documentation. Nothing is logically organised with Derby, for example the configuration properties are all described in the Tuning Guide. Except the network control properties which are described in the Admin’s Guide.
Unlike code DRY is not a good idea unless you are going to very rigorously modularise the documentation. Even then why not repeat something if it means that all the information relevant to task is one place?
Derby has a great feature list but I wonder how many users are ignorant of what it can do because of the poor documentation?
I recently set up JBoss 4.2 on a Staging environment. The Production environment uses JBoss 4.0.3 SP1 and there was a hanging question of whether the application could be transferred to the newer series or not. The obvious advantage of the migration would be to move EJB3.
Well it took a lot of work but I am happy to say that if you have a J2EE 1.4 application you can move it to JBoss 4.2 and EJB 2 and 3 deployments all live together happily in the container.
However there is an important bit of behaviour that has changed and that is that JBoss no longer binds to all adaptors automatically. Instead it binds to localhost by default (I think). My deployment machine was a virtual server with a NAT internal IP and an external IP linked to its DNS alias. Therefore I knew I had issues with binding as in addition to the different IPs I also do not actually have any physical network I’m binding too.
However despite noting the issue in the JBoss wiki documentation I then proceeded to fluff the configuration. Despite having the web containers up and running, along with the JMX Beans I could not get my web tier to talk to my service tier. Instead I was getting obscure messages like Object not in table or a connection timeout.
What I had failed to realise from the documentation is that specifying the --host parameter to the run.sh script is not like defining the system property jboss.bind.address. Superficially they may seem the same, indeed they are so similar that you can in fact stop and start JBoss quite happily using this parameter. However your RMI connector will have be been bound to something else and therefore all RMI calls from outside the server will get routed to /dev/null (geek joke; I have no idea what happens to them but judging from the error message the JNDI lookup fails to connect to any object in the pool capable of servicing the request, the handle lookup probably returns null).
Essentially on a non-production machine you always want to pass
--host=0.0.0.0
to the start script otherwise the services will bind to different addresses and you will have erratic behaviour where connecting to your host by it’s DNS name, the localhost alias and by 127.0.0.1 will all have different results (normally only one of them will actually have the service).
The only other issue is that the AS Log4J configuration has been renamed to jboss-log4j.xml. While this causes some short term pain it was only when I read the release note that I thought: “hey it is weird that we configure all our logging via the container’s configuration file”.
I downloaded XWiki and gave the standalone application a whirl. I’m in the market for a simple wiki, I have used JSP Wiki before and it is fine but it can be a pain to setup correctly and I would also need to figure out how to secure editing offline first (as this is meant to be a public-read, private-edit wiki). My first impression is simply one of sluggish performance. It has a lot of nice features and it does arrive locked down but viewing and editing the pages is very lethargic and the Ajax is painfully slow. This could be the server but other servers are proving snappier.
Interestingly it seems to create a database in memory and import/export the data to file on startup/shutdown. I’m not sure what the advantage of that is, it seems counter-intuitive. Looking at options for a standalone database I am unsurprised to find a not saying that Hibernate does not play well with Derby. The lack of support between products built for either Derby and HSQLDB is annoying and seems unnecessary. However from past experience I know not to try and swim against the tide on this. If the developer worked exclusively on one or the other than chances are it is going to work better with the intended platform.
I also spotted a release note about a bug that requires Tomcat Security to be switched off. That doesn’t seem to be something you want to ship with. It’s not exactly the way you play with others.
Echo One 