Archive for the 'java' Category

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.

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.

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>

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

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.

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).

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.

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.

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.

The IcedTea question.

So there’s more information about the Java (TM) announcement and I’m going to assume the best.

Before I go any further, let me again acknowledge that it’s a big step and I have strong hopes that the things that are not perfect will get sorted out over time. Also, as always these comments are my own and don’t reflect IBM’s position etc etc.

As I said earlier in the day, governance is key and it seems Sun’s model is not changing in the short term i.e. Only Sun employees can commit changes and shared copyright assignment. They say that the former is intended to change over time but one of the charts on the site uses the word ‘eventually’ which isn’t encouraging. I think that these factors make it likely that Kaffe+Classpath will continue to be actively developed until there is more of a level playing field but I believe that’s healthy anyway.

Sam Ruby jokes (I think) that Debian will end up calling their build of the OpenJDK sources IcedTea rather than Java (TM) but the Sun FAQ is pretty clear on this question

Q: What must I do to call my software based on code from the OpenJDK or phoneME projects “Java”?

A: The requirements for the use of the “Java” trademark and name have not changed with the open sourcing of the JDK and Java ME source code. The GPL v2 does not include a trademark license – no OSI-approved open-source licenses do. Sun does not currently have a licensing program that permits the use of the “Java” mark in your product or company name. You can use a truthful “tagline” however associating your product or company with Java technology, according to Sun’s standard terms for use for trademarks. Please see http://www.sun.com/policies/trademarks/ for more details.

This more than suggests that even if you build OpenJDK from a set of sources you get verbatim from Sun you can’t call it Java (TM) (or java.exe ?) . It sounds to me like Distributors, to call something Java will have to use Binaries of Sun’s builds (which are potentially a fork themselves) under the DLJ… which makes things really complicated. Not legal questions I want to be anywhere near.

For the moment I’m very happy that Apache Harmony exists and is doing so well. It’s through competition and challenging Sun that Java (TM) will gain most.

Next Page »


About

I’m David Illsley, I’m a Software Engineer, currently working for Morgan Stanley in London. In the past I worked for IBM developing products in the WebSphere family, and before that I studied at Edinburgh University. I'm also a PMC member @TheASF, and outside the realms of technology, enjoy skulking around the dark corners of theatre...

Archives

c

Disclaimer

The postings on this site solely reflect the personal views of the author and do not necessarily represent the views, positions, strategies or opinions of my employer.

Twitter Updates


Follow

Get every new post delivered to your Inbox.