Mark Bednarczyk's blog

Java Scripting language

I have a new scripting language developed. Its compiled to a proprietary byte code at this moment, but the plan is eventually for it to produce java byte code. The syntax is nearly identical java language. The nice thing is, that with the inclusion of a small jar file you can essentially execute java code in place, out of a string.

It can't interact with local variables in a enclosing java method, but it can interact with class fields and make method calls to java JRE. You can create "local" variable in the script environment of course. Plus all the expression handling is done in place. The user can export any bean to its namespace and those beans and properties immediately become available for the script to interact with (set or get).

Here are a couple of examples:

Script script = new Script();
Namespace ns = script.getNamespace();

ns.addBean("var1", 10);
ns.addBean("var2", 20);

int result = script.exec("(var1 + var2) > 10 ? var1 * var2 : var2 - var1");

The output printed is 200. You can use any arbitrarily complex java expression and it will be evaluated. Here is another short example with a real bean in use:

public class TestBean {
	private boolean value;

	public boolean getValue() {
		return value;

	public void setValue(boolean val) {
		this.value = val;

// And a test expression
Script script = new Script();
Namespace ns = script.getNamespace();

ns.addBean("var1", new TestBean());
ns.addBean("var2", new TestBean());

String result = script.exec("var1.value ^ var2.value ?  "its true": "definitely false");

Formatting of packets

As I'm working on Radius protocol which has thousands of different types of fields (standard and vendor specific), it became obvious that the formatter, especially the JField class needed some slight improvements.

So I'm working currently on making that a little bit more flexible and actually more robust, able to handle more types of field value types. I'm also hoping to finally implement the Field.Priority which defines the fields priority while its being displayed. The purpose of this is so that you can mark certain fields, in a header definition, as low, medium or high priority fields. Low priority fields are only displayed when "full" detail of a packet is needed. Medium when only most common fields needed and high would only include fields of the highest importance.

The Field.Priority and JFormatter.Detail enums play together and determine the kind of detail in the output to produce. This has been in the API for a long time now, but not implemented and everything just defaulted to the highest detail and all fields were high priority. It would finally be nice to implement this and add another dimension to the jnetpcap's packet text display.

Website performance

I have optimized a few things on the website which should make all the pages load much faster then before. The new google's "online page speed" tool, gives a high 89 points (out of 100) on performance.

Any improvement, is a good improvement Smile

1.3.r1315 (rc1) looks good.

We have been testing the latest 1.3 code (1.3.r1315 rc1). Several testers so far have reported positive feedback. For details about what was fixed visit the overview page.

All bugs were fairly minor and nothing serious or hard to fix had been found. The r1315 will be the basis for the full production release 1.3.0. No more betas. The same bug fixes have also been applied to 1.4 codebase. I don't like to release both 1.4 and 1.3 at the same as there is always plenty going on with a single release. So a couple of days after 1.3 is done, I will release the updated 1.4 with the latests as well.

1.3.0 production is almost ready

I have fixed 3 minor bugs in 1.3 beta 4 release and no new bugs have been found. The bugs fixed, will now be tested by the test community and if everything goes OK, we should see a full production/stable release within next few weeks.

Syndicate content