dow.ngra.de

I run Debian Unstable as my main desktop system. I shoot myself in the foot couple of times a year with the upgrades but I like using the bleeding edge of development.

Today after my “regular” upgrade I noticed that one of the ANT tasks did not perform as I would have expected.

/home/toomasr/workspace/project/build.xml:459: The following error occurred while executing this line:
/home/toomasr/workspace/project/changelogic-build.xml:72: Please check the correctness of the root url property. The server returned HTTP response code 300 or above for the URL http://172.17.57.242/lib/changelogic-build.xml

A quick ant -debug did not help me much.

/home/toomasr/workspace/project/build.xml:459: The following error occurred while executing this line:
/home/toomasr/workspace/project/changelogic-build.xml:72: Please check the correctness of the root url property. The server returned HTTP response code 300 or above for the URL http://172.17.57.242/lib/changelogic-build.xml                                                                                                                                       
        at org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:508)                                                                                   
        at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:369)                                                                                                                  
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)                                                                                                     
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)                                                                                                              
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)                                                                                            
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                    
        at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                         
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)                                                                                              
        at org.apache.tools.ant.Task.perform(Task.java:348)                                                                                                                         
        at org.apache.tools.ant.Target.execute(Target.java:357)                                                                                                                     
        at org.apache.tools.ant.Target.performTasks(Target.java:385)                                                                                                                
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
        at org.apache.tools.ant.Main.runBuild(Main.java:758)
        at org.apache.tools.ant.Main.startAnt(Main.java:217)
        at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
        at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
Caused by: /home/toomasr/workspace/project/changelogic-build.xml:72: Please check the correctness of the root url property. The server returned HTTP response code 300 or above for the URL http://172.17.57.242/lib/changelogic-build.xml
        at org.apache.tools.ant.taskdefs.Exit.execute(Exit.java:142)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:357)
        at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:142)
        at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:93)
        at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:367)
        ... 17 more
--- Nested Exception ---
/home/toomasr/workspace/project/changelogic-build.xml:72: Please check the correctness of the root url property. The server returned HTTP response code 300 or above for the URL http://172.17.57.242/lib/changelogic-build.xml
        at org.apache.tools.ant.taskdefs.Exit.execute(Exit.java:142)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:357)
        at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:142)
        at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:93)
        at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:367)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:357)
        at org.apache.tools.ant.Target.performTasks(Target.java:385)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
        at org.apache.tools.ant.Main.runBuild(Main.java:758)
        at org.apache.tools.ant.Main.startAnt(Main.java:217)
        at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
        at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
 
Total time: 3 seconds

The access log on the server did not show anything for the request. Browsing to the url with FireFox worked just fine. Where to even start debugging this? The simple env did not show any proxies configured either. Quite lost.

At last I decided to trace the problem with strace. strace -f ant my_target > result 2>&1 produced 35 892 lines of output. Searching for the ip showed me the message

35596 [pid 13544] connect(46, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::ffff:172.17.57.242", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 ENETUNR      EACH (Network is unreachable)

Weehah, I’m getting somewhere! Googling a bit showed me multiple solutions. Either a system wide sysctl -w net.ipv6.bindv6only=0 or just -Djava.net.preferIPv4Stack=true will do the trick. I hope this helps somebody.

Today’s software is so much about integration. You can have a cool Java utility but if you don’t have an Eclipse plugin for that, a large % of Eclipse users won’t adopt (IDEA & NetBeans users require plugins just as much). In the consumer market the same goes for browser extensions and iPhone apps that support the main service with better accessibility.

There are different ways for integration. Usually it is done via an API. The host platform offers some hooks into the system and you can use them to add some custom functionality on top of the host (or maybe just integrate your own product with the host). The result of this in the IDE world is a plugin. JRebel (the product our team is spending the most development time on) has plugins for application servers, frameworks and even IDEs.

If you’re in luck you can achieve everything with the API, if not you need other tricks. If the API does not offer certain public methods or access to some internal fields you can go in with reflection and still use them (of course there are no guarantees if the internals stay the same on version changes).

One step further to the darkside is binary patching. By binary patching I mean adding/changing/removing methods/fields/classes in runtime. This is the approach that we had to take when writing the JRebel NetBeans plugin.

On NetBeans startup we lookup a debugger class and on success try to patch it. In 2009 and using the JVM (not native apps) it is quite an easy task, at least for the most part. No assembler involved (of course you could be using a bytecode generation library), no need to do jumps to correct offsets or even read assembler (or bytecode).

In our case we use the Javassist library. It is a matter of inserting Java code embedded into a String to methods looked up via reflection. For example the following code adds some new code into the beginning of a method.

ctc.getDeclaredMethod("setRequests").insertAfter(
  "org.netbeans.api.debugger.jpda.LineBreakpoint _breakpoint = getBreakpoint();" +
  "java.lang.String _className = _breakpoint.getPreferredClassName();" +
  "if (_className == null) {" +
  "  _className = reader.findCachedClassName(_breakpoint);" +
  "  if (_className == null) {" +
  "    _className = org.netbeans.modules.debugger.jpda.EditorContextBridge.getContext().getClassName (" +
  "      _breakpoint.getURL ()," +
  "      lineNumber);" +
  "    if (_className != null && _className.length() > 0) {" +
  "      reader.storeCachedClassName(_breakpoint, _className);" +
  "    }" +
  "  }" +
  "}"

For the complete source code of the patch see the src folder of the nb-plugin.

In conclusion, the best way to integrate with any system is via the API it provides. If it does not cut it then look into reflection and start using internals. You will lose on maintainability of course. Still not happy? Look into binary patching and have your fingers crossed whenever the target platform releases a new version.

Editor: We have a guest appearance from a CDO of a Fortune 500 company (actually not Fortune 500, but yes, a development manager for 200 devs). The twist? He has a compiler installed and apparently an editor too.

The other day I was playing around with a tool for memory analysis and wrote a small snippet using which I would be able to test the new tool. Quickly (Editor: yeah right quickly) created the following and executed it:

[code language='java']
import java.util.*;
class Leak {
static List list = new ArrayList();
public static void main(String[] args) {
for (int i = 0; i >= 0 ;) {
list.add(i++);
}
System.out.println("I will either reach here or die trying (with OOM)");
}
}
[/code]

And what do you think I was displayed by my command prompt (editor: CDOs don't have a command prompt):

Option A:
[code language='java']Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2760)
at java.util.Arrays.copyOf(Arrays.java:2734)
at java.util.ArrayList.ensureCapacity(ArrayList.java:167)
at java.util.ArrayList.add(ArrayList.java:351)
at Leak.main(Leak.java:6)
[/code]
Option B:

Well, as I found out, it doesn’t print out anything. As this is now two years from my last real Java development experience (got demoted to C-level), I went to my hardcore Java hackers. For 10 minutes we all stood with bedazzled faces, before it struck – the memory will be allocated in a way that there is no room for new OutOfMemoryError() to be created.

If you execute the above with 64MB heapsize (which is the default heapsize):

But if you increase (well actually modify) the heap size a bit:

Moral of the story? I definitely would not want to be fixing a production system dying like this (Editor: lucky you, you don't have to) – most likely I would be mad way before I could have grasped anything about the reasons …

Remember that post about Typesafe DSLs that had a part one and no follow up? Well, meanwhile Juhan Aasaru and yours truly were joined by Michael Hunger of jexp.de and JEQUEL and together we have created the Squill project that came right out of the ideas in the paper we wrote with Rein Raudjärv. The announcement follows, enjoy!

It is with great pleasure that we announce the first release of Squill. Download it now or check out the quickstart guide, the step-by-step tutorial and the Devoxx presentation.

Squill is a slick internal DSL for writing SQL queries in pure Java. It uses the database metadata and generics to catch as many errors as possible during compilation and is almost completely typesafe.

At the same time it is designed to allow everything SQL allows you to do, exactly the way SQL is meant to do it. This means that you’re encouraged to select only the data you need and no hidden queries are generated for you, leaving you in full control of the query performance. Squill supports database-specific extensions, allowing you to both use advanced features and fully tweak your queries.

Squill also has special support for CRUD operations and table relations, adding some sugar over vanilla SQL. A typical Squill query looks like this:

Squill is a very young project and you can follow (and help) its development by joining the user or developer mailing lists.

For many years I was convinced that Maven was a plot to bring the community of Java developers to the point of extinction. It is very slow in development, overengineered and imposes a set of standards where a 20 line build script would suffice.

On the other hand I was always envious of the way Maven manages dependences and downloading 20 megs of dependencies every time I do a fresh checkout was a bit of a embarrassment. Well, last week it all changed.

What happened is that Kristian Rosenvold contributed a JavaRebel plugin. Him being a fan of Maven and me being a fan of JavaRebel we wanted to find some way to set up a Maven repo for various JavaRebel projects that wouldn’t expose me to the things I consider unholy. Lo and behold, the Maven guys have figured out our pains and provided the nifty library called the Maven Ant tasks.

Now this maybe ancient news to the Maven community, but being a hardcore Ant hacker I have always thought that Ivy is the best and latest in the Maven-Ant integration game. Ivy does the job, but it is a pain to configure and even after three years still very buggy. The Maven Ant tasks can use the standard Maven pom.xml files if you like them, or to configure everything in Ant if you don’t.

The basic gist is that you put the following three lines in your build script:

This gives you a path dependency.classpath that includes all your dependencies and that you can refer as pathref or classpathRef. It is also possible to get a fileset of dependencies as well as individual dependencies using properties of the form ${groupId:artifactId:type}.

With the dependencies in such a form it’s trivial to use them even in existing build scripts. You just replace your current paths and sets with the Maven ones an voila — you get a hackable Ant script with all the pleasure of Maven and without any of the pains.