Today, I decided to flush out and clean up my A* implementation in Clojure. I cleaned up the namespaces, removed some cruft, got the Java integration working (which required by-passing RT.loadResourceScript() since it seems to be broken), and moving my graph structure definition out of code and into a separate XML file (which is read and parsed directly in Clojure).

I’m still not sold on functional programming, these minor changes took me more hours than I care to admit and gave me a crazy headache, but that could just be because I’m unfamiliar with the language.

I also uploaded the code to GitHub, because I figured where’s the fun in learning a new algorithm in a new language without tossing in the risk of losing all your code to an silly mistake with an unfamiliar version control system?

Luckily no data was lost, and if you have any interest in Clojure, Clojure-Java integration, or A-Star search, check it out here:

http://github.com/jbcpollak/AStar-Clojure

My next steps are going to be more rigorous unit testing and perhaps some benchmarking. I’d like to see how this implementation does against a large graph.

I wanted to refresh my knowledge of functional programming, A-Star search, and I figured learning Clojure at the same time couldn’t hurt. I figured I’d do all three at once, and throw in a health dose of Maven and Java at the same time.

This project was intended to:

1. Refresh myself on how to do functional programming
2. Refresh my knowledge of A* search
3. Help me learn Clojure
4. Demonstrate Java interoperating with Clojure
5. Demonstrate Maven as a viable build system for Clojure

Once downloaded, unzip the zip file and open a terminal.

You now have three options:

Review the Source Code

The meat of the code is all in Clojure, here:

src/main/resources/com/example/clap/astar.clj

There is a bit of boot-strap Java code in the following file, but I can’t say its all that interesting:

src/main/java/com/example/clap/App.java

Running from Source

If you are on a Mac, or you already have Maven and Java installed, just run the following:

cd astar && mvn test

Maven will download all the needed packages and then compiled and execute the demo.

Running from Binary

If you are on Linux, or have cygwin installed on Windows, you can run the following:

cd astar/bin/ && ./run-astar

At work, we need to start using JOGL as a dependency of our project, which we build with Maven. JOGL, the Java OpenGL interface, uses platform specific binaries, which introduces some complexity to the build process.

After a brief websearch, I found the appropriately titled using-jogl-as-dependency-in-maven, unfortunately, it appears to be a private blog, so I can’t see if the information is useful or not.

I did find on mvnbrowser.com that jogl-1.1.1-rc6 (as of this writing) is on the dev.java.net Maven2 repository, but I couldn’t find a usage guide.

Oh well, I’ll keep looking. For now its not a hugely pressing issue, so the one developer who is using has just hacked his Eclipse setup.

A few days ago I posted an article about my wrapper API which unifies the mDNSResponder and JmDNS packages behind a single interface, but I neglected to provide usage examples or a usage guide. I’ll try and correct that now.

In addition to unifying multiple mDNS implementations under a single API, I think my API reduces the amount of work needed by the developer for registering and listening for services to a minimum.

Building the code
First off, all you should need to compile and run my package is Maven. Once you have Maven installed, cd into the jmdns directory, and run:

mvn test

This will compile JmDNS, my add-on API, and run a few unit tests. The API in question is tested by org.jmdns.api.DiscoveryFactoryTest. I would expect the JmDNS portion of the test testJmDNS() to pass under almost any circumstance, but the testmDNSResponder() will only pass if you are running on Linux and have mDNSResponder (or possibly the avahi compatibility layer) installed successfully.

Example usage – Initialization

Before registering or listening for services, you need to initialize the discovery subsystem:

DiscoveryFactory.initRegistry( DiscoveryFactory.DISCOVERY_REGISTRY_DEFAULT);

The above will use the default mDNS implementation (JmDNS). Alternatively you can use the following to use JmDNS explicitly:

DiscoveryFactory.initRegistry( DiscoveryFactory.DISCOVERY_REGISTRY_JMDNS);

Or mDNSResponder instead:

DiscoveryFactory.initRegistry( DiscoveryFactory.DISCOVERY_REGISTRY_MDNSRESPONDER);

Consider this an initialization a singleton, you should do this once and only once per JVM instance.

Example usage – Registering a Service

Assuming the system is initialized, the following code will register a service:

HashMap<string,> props = new HashMap<string,>(); props.put("type", "website");</string,></string,>

IDiscoveryRegistry registry = DiscoveryFactory.getRegistry();

IServiceInfo myService = registry.registerService("_http._tcp", "mySite", null, 80, props);

Note the ‘null’ in the registerService() call is to use the default domain (.local). You can pass a domain name here to register in another domain.

To unregister your service, just do:

registry.unregisterService(myService);

Example usage – Listening for a Service

Create a listener:

BaseDiscoveryListener listener = new BaseDiscoveryListener("_http._tcp", "website", null);

Wait 15 seconds for a service:

listener.waitForFirstService(15000);

Get the first service found:

IServiceInfo service = listener.getFirstService();

Print out some information on the service:

System.out.println("service name: " + service.getName() + " at " + service.getHostAddress() + ", port: " + service.getPort());

My company has given me permission to release a Java Zeroconf API. The advantage of this API is that it allows the application to select which implementing library to use at runtime, and eases developer work implementing mDNS / DNS-SD. I also think my API is easier to understand than the raw interfaces of the underlying implementations.

Currently there are two implementing backends, one for JmDNS and one for Apple’s mDNSResponder. I would really like to see one written for Avahi, but I probably won’t get to it myself.

The API is in the org.jmdns.api package, which both implementations are in the org.jmdns.impl package. A unit test is also included which demonstrates usage and verifies operation.

I’ve implemented this version within the JmDNS source tree, but ideally the API, JmDNS and mDNSResponder portions of the code would be broken out to be separately distributed, with the JmDNS and mDNSResponder portions functioning as plugins implementing the API.

I’ve only tested this against mDNSResponder 107.5. I’m not sure if Apple’s dnssd.jar is compatible with newer mDNSResponder versions or not.

You can download the full implementation here: jmdns-kiva-1.1.3.tar.bz2

I hope the JmDNS project will pick this effort up and incorporate this into the official release!

I came across this post and this Maven plugin today. Call me cynical, but I was shocked when it worked out of the box, building our application as a Mac friendly .app which can be run with a double click.

To test it out, all I did was change into our application’s trunk directory and ran:

mvn package osxappbundle:bundle -DmainClass=com.mypkg.MyMain

And it worked!

So I extended integrated it into our pom.xml with the following. Now whenever our app is packaged on a Mac, in addition to the other artifacts, an .app, .dmg, and .zip of the My App tool will be created.

<profiles>
   ....
        <profile>
            <id>package-osx-bundle</id>
            <activation>
                <os>
                    <family>mac</family>
                </os>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>osxappbundle-maven-plugin</artifactId>
                        <configuration>
                            <mainClass>com.mypkg.MyMain</mainClass>
                            <bundleName>My App</bundleName>
                            <jvmVersion>1.5+</jvmVersion>
                        </configuration>
                        <executions>
                            <execution>
                                <phase>package</phase>
                                <!-- append to the packaging phase. -->
                                <goals>
                                    <goal>bundle</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>