Guus was kind enough to make a maven project for the Generic Tree. He also fixed an error in my equals method for the GenericTreeNode (I intended to do Object.equals(Object obj) but was doing GenericTreeNode.equals(GenericTreeNode obj). Since it’s a maven project, you can easily create a jar out of it and add it as a dependency to your project. You can download the project here. Thanks Guus!
Last week I was solving a problem at work that required the use of a Generic (n-ary) Tree. An n-ary tree is a tree where node can have between 0 and n children. There is a special case of n-ary trees where each node can have at most n nodes (k-ary tree). This implementation focuses on the most general case, where any node can have between 0 and n children. Java doesn’t have a Tree or Tree Node data structure. I couldn’t find any third-party implementations either (like in commons-lang). So I decided to write my own.
Read more…
I’ve added another project to the projects page. It’s called bAdkOde, an interpreter for an esoteric language that I designed. The very first incarnation of bAdkOde was written in Java and I actually posted it (or made a blog entry about it) over 8 years ago. For some reason I took it down. Probably because I stopped working on it. Anyway, I redesigned the language and wrote an interpreter for it in Perl about 4 or 5 years ago. I finally got around to posting it. Check out the project page for more details. Let me know what you think.
Mukesh alerted me to a problem with the Perl conversion script (that converts the XML produced by the Grinder recorder into a Jython file). It wasn’t parsing all the parameters in a GET request properly. I’ve fixed the bug and uploaded a new version of the script. You can download it here.
I’ve been doing a little bit of JSTL over the past week, especially custom tags. I’ve written custom tags in Grails before, and there you use actual Groovy code. I guess this was how custom tags used to be written (in Java), but now you can can build your own custom tags using the standard tag library. The standard tag library is still pretty useful when it comes to building custom tags. Since it’s not straight Java, it forces you think really hard about your logic. You don’t want to put any business or application logic in your tag, and you want to restrict everything to view or presentation logic. A side effect of it not being Java is that if you want to do anything extremely complicated, you’re probably better off writing the tag in Java (making sure that you don’t let any business logic creep in).
While writing my own custom tag, I noticed that although instanceof is a reserved word in the JSTL EL (expression language), it is not supported as an operator. The reason I wanted to use the instanceof operator is that I have an attribute that could either be a List or a Map and depending on the type, I wanted to do different things.
Another thing I was trying to do, was to inspect the incoming object to see if it had a certain property (reflection). JSTL uses reflection so that you can access the properties of an object via dot notation, if they follow the JavaBean naming-convention. However, there was no way for me to see if an object had a certain property. To solve both these problems, I wrote my own JSTL functions.
Read more…
Before reading this tutorial (if you haven’t already), please took at look at my last two tutorials (Performance Testing using The Grinder and Anatomy of a Grinder test-script). In this tutorial I’ll talk about easily writing Grinder test-scripts using a framework I designed. As a disclaimer, I’d like to point out that I’m not a Python programmer and therefore certain things may not be very python-esque. If that’s the case, I apologize. My personal opinion is that this framework is especially useful (of course, since I wrote it 
) for web applications where you have a already have a lot of test data. In that case, you can simply record all your discrete tasks once and then construct different scenarios with them. But if you feel differently and have some constructive criticism, I do look forward to hearing from you! Also, if you’d like to try out the framework I’ve got a tarball and a zip file available for download on the very last page.
Read more…
This is my second post regarding Grinder. In this post I’ll go over the anatomy of a recorder Grinder test-script. If you haven’t read my previous post, please take a look at it. Otherwise this post won’t make much sense!
High-level structure of a Grinder script
The high-level structure of a recorded Grinder-test-script looks like this:
[
...
import statements
...
]
[
...
header definitions
...
]
[
...
url definitions
...
]
[
...
request and test definitions
...
]
class TestRunner:
[
...
method definitions - a method is defined for each recorded page
...
]
def __call__(self):
[
...
calls to defined methods, which actually runs the requests
...
]
[ utility function (I'll go over this later) ]
[
...
calls to utility function to wrap/instrument tests (I'll go over this later)
...
]
About a month ago at work, I was trying out a bunch of different performance-testing tools to figure out which one to use to performance-test our software. I ended up discovering a tool called The Grinder which uses Jython to build performance-testing scripts that you can then use to test your application. I even built a little framework in Jython to make the test scripts more modular and reusable. Over the next few days I’ll be publishing three articles (this one included) that talk about Grinder.
Introduction
In this article I’ll go over installing and setting up Grinder. I am not going to go into too many details since my aim is to provide information that will enable you to have Grinder up and running quickly. If you want more information, you can look at the rather thorough Grinder User Guide. At the end of this guide, you’ll know how to install and set up grinder, record a test, modify (and/or parameterize) it, start running it through the console, and record data from the test. Note: The instructions in this guide relate to a Linux environment. You can run Grinder in Windows; the set-up is not much different. The only differences will be in installation locations and shell scripts. If you want more information about setting up Grinder in a Windows environment, please take a look here.
Read more…
This is an update to my instructions on running the JavaFX 1.0 SDK on Linux. Those instructions do not work on the dmg image for the 1.1 version of the SDK.
Mike (thanks Mike!) posted a comment on that blog mentioning a small change that needed to be made. To get JavaFX 1.1 on Linux, first follow the steps in the original guide. When you need to mount the dmg, you need to provide an offset. So instead of the original command, do the following:
vivin@dauntless ~ $; sudo mount -o loop,offset=$((1024*17)) -t hfsplus javafx_sdk-1_0-macosx-universal.dmg.out javafx
The dmg should be mounted now.
The JavaFX 1.0 SDK was released today. I’ve played with the preview SDK, so I was pretty excited to try out the 1.0 SDK. Inexplicably, and this was the case with the preview SDK as well, Sun hasn’t released a version of the SDK for Linux. However, this wasn’t a problem because it was possible to run the Mac version of the Preview SDK on Linux. The preview SDK came in the form of a zip, but the 1.0 SDK comes in the form of a dmg, so I was initially stumped. But I’ve figured out how to get the Mac version of the SDK to work on Linux. It’s a little more complicated than getting the preview SDK to work, but it works!
The thing about dmg files is that you can easily mount them on Linux since they are essentially stored in the HFS Plus filesystem format. So I immediately set about trying to mount it:
vivin@dauntless ~
$ mkdir javafx
vivin@dauntless ~
$ sudo mount -o loop -t hfsplus javafx_sdk-1_0-macosx-universal.dmg javafx
[sudo] password for vivin:
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Hmm… ok, that wasn’t what I expected, so I tried to see what type of file it was:
vivin@dauntless ~ $; file javafx_sdk-1_0-macosx-universal.dmg javafx_sdk-1_0-macosx-universal.dmg: bzip2 compressed data, block size = 100k
Ok, so it look’s like it’s a bzipped file. All we need to do then, is bunzip it and mount it:
vivin@dauntless ~ $ bunzip2 javafx_sdk-1_0-macosx-universal.dmg bunzip2: Can't guess original name for javafx_sdk-1_0-macosx-universal.dmg -- using javafx_sdk-1_0-macosx-universal.dmg.out bunzip2: javafx_sdk-1_0-macosx-universal.dmg: trailing garbage after EOF ignored vivin@dauntless ~ $ sudo mount -o loop -t hfsplus javafx_sdk-1_0-macosx-universal.dmg.out javafx vivin@dauntless ~ $ ls javafx javafx_sdk-1_0.mpkg
Awesome! So we were able to get the dmg mounted. Now all we need to do is find were the SDK lives. After going through the dmg, I found out that the SDK is stored in a compressed (gzipped) file. You can find it at <mountpoint>/javafx_sdk-1_0.mpkg/Contents/Packages/javafxsdk.pkg/Contents/Archive.pax.gz. Copy this file into another working directory (or wherever you want your SDK to reside. I put mine in /usr/local):
vivin@dauntless ~/working $ cp ~/javafx/javafx_sdk-1_0.mpkg/Contents/Packages/javafxsdk.pkg/Contents/Archive.pax.gz . vivin@dauntless ~/working $ gunzip Archive.pax.gz vivin@dauntless ~/working $ file Archive.pax Archive.pax: ASCII cpio archive (pre-SVR4 or odc)
When I gunzipped the file, I got Archive.pax, and I wasn’t sure what to do with it. So I ran file on it and discovered that it was a cpio file. Some quick Googling and man-page perusal later:
vivin@dauntless ~/working
$ cpio -i <Archive.pax
65687 blocks
vivin@dauntless ~/working
$ ls
Archive.pax COPYRIGHT.html lib profiles samples src.zip timestamp
bin docs LICENSE.txt README.html servicetag THIRDPARTYLICENSEREADME.txt
vivin@dauntless ~/working
$ bin/javafx
Usage: java [-options] class [args...]
(to execute a class)
or java [-options] -jar jarfile [args...]
(to execute a jar file)
where options include:
-d32 use a 32-bit data model if available
-d64 use a 64-bit data model if available
-client to select the "client" VM
-server to select the "server" VM
-hotspot is a synonym for the "client" VM [deprecated]
The default VM is server,
because you are running on a server-class machine.
-cp <class search path of directories and zip/jar files>
-classpath <class search path of directories and zip/jar files>
A : separated list of directories, JAR archives,
and ZIP archives to search for class files.
-D<name>=<value>
set a system property
-verbose[:class|gc|jni]
enable verbose output
-version print product version and exit
-version:<value>
require the specified version to run
-showversion print product version and continue
-jre-restrict-search | -jre-no-restrict-search
include/exclude user private JREs in the version search
-? -help print this help message
-X print help on non-standard options
-ea[:<packagename>...|:<classname>]
-enableassertions[:<packagename>...|:<classname>]
enable assertions
-da[:<packagename>...|:<classname>]
-disableassertions[:<packagename>...|:<classname>]
disable assertions
-esa | -enablesystemassertions
enable system assertions
-dsa | -disablesystemassertions
disable system assertions
-agentlib:<libname>[=<options>]
load native agent library <libname>, e.g. -agentlib:hprof
see also, -agentlib:jdwp=help and -agentlib:hprof=help
-agentpath:<pathname>[=<options>]
load native agent library by full pathname
-javaagent:<jarpath>[=<options>]
load Java programming language agent, see java.lang.instrument
As you can see, you now have a working JavaFX 1.0 SDK on your Linux box!
