Category Archives: java

Jul 15 2012
Leave a comment
java, Tech

Maps and Dictionaries

Nope, not musty books, but programming constructs.

When you learn to program in C, you’re exposed to data structures which map easily to underlying hardware. Basic data types are of a fixed size, and locating information within them is based on indexing a number of bytes into them. If you want a variable size data structure, or to find information within a structure based on something other than a count then you need to either build something complex or find a library to use.

Of course keeping mappings between data, and dealing with unpredictable and variable sized collections of data are incredibly common.

When Java came along in the mid 90′s, it dealt with this by modelling the language in the same way on the workings of the machine, but provided a bunch of high quality variable and associative data structures as part of the standard library. These have evolved over the years, and we now have some incredibly capable and flexible data structure available.

However, in 2012, the way they’re available feels increasingly archaic.

Other languages which eschew the direct mapping to the underlying hardware for developer productivity make these structures available as ‘part of the language’. Sometimes these implementations aren’t as fully-functional, but they make simple things simple, and allow leave options open for the more complex cases.

Javascript objects are all dictionaries (maps from string to something). Ruby arrays are variable length. In Scala lists and maps feel like they’re part of the language.

While I have sympathy with the idea of designing a language which maps cleanly to the underlying system, I don’t think it’s a decision which makes sense any more. Good developers will learn/understand how these feature work, and when it’s (in)appropriate to use them. And they won’t adopt/stick with your language when it makes simple things difficult.

Yes, Java 9, I’m pointing at you.

Jun 26 2011
1 Comment
java, osgi

A new OSGi tool… kindof…

After watching the #osgitool session the other day which covered some pretty advanced OSGi tooling, it occurred to me that given the learning and migration curve to use OSGi, there are people a long way from using it, but who could benefit from the OSGi metadata everyone is spending time on.

How so? Well, Eclipse supports ‘Access Rules’ on dependency libraries which essentially mimic the Export-Package property in OSGi. A tool which allows you to easily set up this configuration based on the manifest would allow you to respect the (normally carefully crafted) Export-Package restrictions without going all the way to OSGi. Hopefully this means that you’re less likely to use APIs which are considered internal, and so when you’re upgrading the version of your dependency, there’s less likelihood of accidental incompatibilities.

The source to this (very simple) plugin is on github, and along with a built jar which you can drop in the dropins folder.

Then, to use it, simply right-click on a Java project and select “Refresh OSGi export restrictions”. This will then scan the dependent jars and their manifests, and for OSGi bundles, update the Access Rules to explicitly allow use of exported packages, and forbid use of all other packages (this is visible in the Java Build Path/Libraries tab).

If it’s useful and you have feedback, please use the tracker on github.

Tagged ,
Nov 29 2010
Leave a comment
java, Tech

OSGi, Java Security Manager, and keeping things simple…

I’ve spent the last couple of hours trying to understand Java2 Security in an OSGi environment. There’s a presentation available at [link] which gave me lots of information and hints of what to search for and what to play with. I’ve also had a quick skim to the relevant section of the OSGi 4.2 spec. Here’s a quick summary of what I’ve discovered. It may not be 100% correct… do let me know if i’ve got the wrong end of the stick on something.

In an OSGi 4.2 environment, the Conditional Permission Service is king. Well… kindof. There are 3 sources of permission information to consider:
1. Java2 Security Policy
2. Dynamic(Programmatic) configuration of the Conditional Permission Service
3. Local Permissions. (Static, per bundle policy)

In a relatively static environment it appears that you could pretty much ignore the programmatic Conditional Permission Service and rely on the more static options 1 and 3.

In order to enable OSGi security, you start by enabling Java2 security with an ‘all permissions’ policy file. Yes, I did just say that. It seems counter intuitive, but in order to allow the OSGi Framework to do its thing, it needs full permissions. It seems to be plausible to give just the framework bundle(s) the All Permission in the policy, but this affects (removes) the implied permissions of the other bundles which breaks everything. More investigation required.

So, assuming you already have an OSGi application:

java -jar org.eclipse.osgi_3.6.0.v20100517.jar -Djava.security.manager -Djava.security.policy=all.policy

all.policy:

grant { permission java.security.AllPermission; };

And you’re in an identical situation to before. All code has all permissions. The up side is that it’s just a couple of steps to start restricting the priviledges of your bundles.

Add an empty file “OSGI-INF/permissions.perm” to a bundle, and apart from some implict permissions (e.g. to import packages, read/write the bundle configuration area), that bundle has had its permissions entirely removed. You can the start giving the bundle permissions e.g. by adding a line:

(java.io.FilePermission “/Users/*” “read”)

This provides a very simple way to enumerate the permissions a bundle requires and restrict it to them. It also provides a simple file to audit for each bundle. There are a couple of important things to note:

1. An empty file is not equivalent to no permissions.perm file. Make sure you have a permissions.perm file if you want restricted permissions.

2. The permissions.perm file specifies the maximum permissions the bundle requires. The framework/Conditional Permission Service in conjunction with the system security policy may result in lower available permissions.

This looks great for reducing the risks from exploits in bundles I develop, but clearly doesn’t help much with 3rd party bundles, which is where the Conditional Permission Service should come into its own. More on that once I’ve worked it through.

May 15 2010
7 Comments
apache, java, Tech

OpenJPA, Derby, and getting started fast….

The combination of Apache OpenJPA and Derby provides a fantastic and simple way to prototype database apps in Java. The only downside is that there are a couple of gotchas I keep on finding myself hitting each time I start a new project. Here’s the simplest app I can think of and all the associated files for my later use. If it’s useful to you as well, have fun!

File: src/main/java/test/Account.java

package test;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Entity
public class Account {

private String name;

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private long id;

public Account(String name) {
this.name = name;
}

public String getName() {
return name;
}

public long getId() {
return id;
}
}

File: src/main/java/META-INF/persistence.xml

<persistence version="1.0"
	xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
	<persistence-unit name="account">
		<class>test.Account</class>
		<properties>
			<property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema" />
			<property name="openjpa.ConnectionURL" value="jdbc:derby:testdb;create=true" />
			<property name="openjpa.ConnectionDriverName" value="org.apache.derby.jdbc.EmbeddedDriver" />
		</properties>
	</persistence-unit>
</persistence>

File: src/test/java/test/AccountTest.java

package test;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.EntityTransaction;
import javax.persistence.Persistence;

import junit.framework.TestCase;

public class AccountTest extends TestCase {

	public void testAccount() {
		EntityManagerFactory emf = Persistence.createEntityManagerFactory("account");
		EntityManager em = emf.createEntityManager();
		EntityTransaction et = em.getTransaction();
		et.begin();
		Account a = new Account("Bob");
		em.persist(a);
		et.commit();
		System.out.println("a"+a.getId());
	}
}

File: pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>test</groupId>
	<artifactId>test</artifactId>
	<packaging>jar</packaging>
	<version>1.0-SNAPSHOT</version>
	<name>test</name>
	<dependencies>
		<dependency>
			<groupId>org.apache.openjpa</groupId>
			<artifactId>openjpa-all</artifactId>
			<version>2.0.0</version>
		</dependency>
		<dependency>
			<groupId>org.apache.derby</groupId>
			<artifactId>derby</artifactId>
			<version>10.5.3.0_1</version>
		</dependency>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.8.1</version>
			<type>jar</type>
			<scope>test</scope>
		</dependency>
	</dependencies>
	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<version>2.0.2</version>
				<configuration>
					<source>1.5</source>
					<target>1.5</target>
				</configuration>
			</plugin>
			<plugin>
				<groupId>org.codehaus.mojo</groupId>
				<artifactId>openjpa-maven-plugin</artifactId>
				<version>1.0</version>
				<configuration>
					<includes>**/entities/*.class</includes>
					<excludes>**/entities/XML*.class</excludes>
					<addDefaultConstructor>true</addDefaultConstructor>
					<enforcePropertyRestrictions>true</enforcePropertyRestrictions>
				</configuration>
				<executions>
					<execution>
						<id>enhancer</id>
						<phase>process-classes</phase>
						<goals>
							<goal>enhance</goal>
						</goals>
					</execution>
				</executions>
				<dependencies>
					<dependency>
						<groupId>org.apache.openjpa</groupId>
						<artifactId>openjpa</artifactId>
						<version>2.0.0</version>
					</dependency>
				</dependencies>
			</plugin>
		</plugins>
	</build>
</project>
Mar 13 2010
2 Comments
java, javascript, Tech

Adding a JavaScript host object with Rhino

I’ve been thinking a fair bit about server side JavaScript recently, but haven’t really dug in. One of the things I’ve been wondering is how easy it is to define a host object with Rhino. Turns out it’s trivial:

import org.mozilla.javascript.Context;
import org.mozilla.javascript.ScriptableObject;
public class Test {
public static class TestHost extends ScriptableObject {
  private String val = "";
  public String getClassName() {
    return "TestHost";
  }
  public String jsGet_val() {
    return val;
  }
  public void jsSet_val(String s) {
    val = s;
    System.out.println("from java: " + s);
  }
}

public static void main(String args[]) throws Exception {
  Context c = Context.enter();
  ScriptableObject so = c.initStandardObjects();
  ScriptableObject.defineClass(so, TestHost.class);
  System.out.println(c.evaluateString(so,
      "var t = new TestHost(); t.val='ee';'from script: '+t.val", "",
      1, null));
  }
}

Results in:

from java: ee
from script: ee
Tagged
Jun 21 2007
Leave a comment
java, jsr311, standards, sun, Tech, webservices

JSR 311 is making progress…

… and I’m happy. I shared some concerns when it was announced that the JCP was unlikely to come up with an appropriate spec. Sun have just released a (very) early access version of the RI, and having taken a look at the Javadoc, it meets my main criteria: small, simple, and not tied to the servlet spec. I have a couple of questions about verbosity (defaulting really) which I’ll dig in to over the next <however long it takes to find the spare time>, but thus far it’s looking good – both the design and the participation model. Well done Marc, it looks like you’ll prove the cynic in me wrong.

Update – Some quick thoughts:
MultivaluedMap – Seems like something I’ll use outside of ‘rest programming’.

@DefaultValue – Seems to only work when the value it’s defaulting==null. Therefore doesn’t work with URIParams which seem to default to “”. Odd.

May 29 2007
3 Comments
apache, java, Open Source, openjdk

Open Source is Open Source, right?

Wrong. While it’s not healthy for projects to spend forever arguing about philosophy or politics, community is important for a project to be successful, which is why of the following 2 statements, I prefer the Apache way.

Apache: “community is more important than code”

OpenJDK: “OpenJDK is all about code. Actual bits that do something. The opposite of politics.”

(note, I’m not endorsing any specific ‘politicization’ at OpenJDK, I have no idea who/what is going on there).

Apr 14 2007
2 Comments
apache, harmony, java, Open Source, standards

Open Source and Lawyers

In my recent silence (busy and a holiday), a couple of legal disagreements with open source have come to light. The excellent Gaim project (now Pidgin) has apparently been in a year-long discussion with AOL and now Apache Harmony has publicised a disagreement they’re having with Sun.

Having looked at the public information about both, both have tried to solve the problems in private. It’s taken a very long time in the case of Pidgin and resulted in some form of agreement (though the details aren’t public) and in the case of Apache Harmony, they’ve decided to go public because it’s been ages so far and there’s been no progress.

This has had (imo) a negative impact on both projects. Pidgin has been developed very quietly in the last year and has, in fact, looked dead! I don’t follow Apache Harmony very closely but I know at least some of the project have been wanting to do this testing for a while to help them make progress, so this has held the project back.

So please, to all companies about to deal with open source communities, please take account of the major impact any legal dealings can have, even when you might view them as ‘small’.

To Sun: What Apache are asking for seems entirely reasonable. If you want to be seen as open source friendly you’ve got to walk the walk.

Mar 13 2007
3 Comments
java, jsr311, soa, standards, sun, Tech, webservices

JSR 311 Followup

I blogged a little while ago about the proposed JSR 311, a REST API for Java. I’ve since tried to implement the annotations and processing described by the short example on Marc’s blog.

Now I’m not going to claim that what I’ve done is comprehensive or ‘production ready’, but it proves the point. The point it proves to me is that it’s possible to design small, simple APIs that dramatically simplify application programming (and is easily and cheaply implemented).

I’ve taken a quick look at Restlets and i’m impressed… but it’s a whole new application programming model. Does anyone really want that in JavaEE?

I’ll repeat myself. I think a simple API which can easily be added to JavaEE and which simplifes writing basic REST and HTTP/POX is a good approach. Lets let the more advanced bits be an area for innovation and competition for a little while longer.

Reminder: The contents of this blog reflect my personal opinions, not those of my employer.

Feb 17 2007
2 Comments
java, jsr311, rest, standards, sun, Tech, webservices

JSR 311, Java API for RESTful Web Services

Having met Marc, I’m sure he’s got some great ideas and the best of intentions for this JSR. However, he’s got an uphill struggle given the propensity for the JCP to produce horrible compromise solutions that excite very few people.

I’ve spent some time of the last few days trying to design a java REST API and I’m a little stuck. I keep on defining a higher level HTTP API. That, or a generic object/HTTP mapping a-la RoR. Neither is really a REST API. I suspect that’s what the outcome of the JSR will be, though to keep the servlet api people in Sun happy, they’ll keep the REST name, annoying a number of people and confusing many more. Please Marc, if you’re simply defining a higher level HTTP API, drop the REST name.

As a higher level HTTP API, I do like the example that Marc showed in his blog. It looks pretty simple, and I don’t see why (if you were building an implementation on top of the servlet API), it would take very long to implement. So, I’d encourage Sun to implement it, release it widely very soon, and solicit feedback before even a public review of the spec. You’ll get a lot more feedback from use than from people reviewing a PDF.

I think there’s real scope here for a distinct improvement for people progamming (POX|JSON)/HTTP or REST, and that it can be done pretty simply. This is a proof point for the JCP. If a spec comes out that prereqs JAX-WS, it’ll be a nail in the coffin of this JSR before it ships and will reinforce the view that complexity rather than simplicity is a JEE design goal.

← Older posts
Follow

Get every new post delivered to your Inbox.