Research: Joe-e project
I haven’t had much time to work on any personal projects in the past couple of weeks so I figured I would write about the research project that I’ve been working on during this semester. I’m working with one grad student and another undergraduate on a new language that’s supposed to make it easier for developers to reason about security issues in their code. The other undergraduate and I have so far been working on a documentation system for the new language and we’re just about done with that and starting up a much more challenging project.
The language (called Joe-e) is a subset of Java that gives the developer less power in dealing with the system. Joe-e code ascribes to the principle of least authority, which means that objects should by default be given no power (authority) and should be granted authority on a need only basis. Compared with the norm, where objects typically have access to everything and must be explicitly restricted, applying the principle of least authority makes it substantially easier for a developer to reason about which objects have access to other objects. In this sense developers can determine more about each of their classes and thus they have a better idea of what would happen to their code if something went wrong in one of the classes. As I haven’t explicitly worked on the security features yet, I don’t know much more about the language itself, but if you’re interested, feel free to read more about it on the language website.
My partner (the other undergraduate in the group) and I have until now been working on a automated documentation generating system for the language. Since the language is a subset of Java, it makes sense to use javadoc (java’s documentation system) but we had to augment it to include some of the other features that we required. We made our documentation look very similar to Java’s API, so that java developers don’t have a hard time switching from java to Joe-e. Everything that we’ve done has just been added to the standard Java API look in a nice and clean way.
In Joe-e, a lot of the Java library classes have been restricted in accordance with the security principles of Joe-e, and our documentation system needs to indicate which parts of classes have been suppressed and why. So one of the main things that we’ve done in our documentation is mark which methods, constructors and fields have been suppressed and why. Another feature of Joe-e is that library classes can have honorary implementations of certain interfaces that provide information about the classes authority. We’ve added a section in the documentation to indicate which of the Joe-e interfaces this class honorarily implements as well. Other than that, there aren’t many differences between the joe-e API and the java API.
When we started working on this project, both my partner and I thought it would be really easy, but it’s taken us almost three months to finish. We’ve been working on it pretty regularly and dedicatedly, but we’ve run into tons of problems with javadoc’s source code that were serious roadblocks to our progress. For example, one such problem is that the javadoc’s API has been locked making it “impossible” to extend the standard javadoc classes and create your own documentation generation system. We ended up spending a lot of time looking at different ways to bypass this lock without re-writing a lot of code ourselves and finally came up with a pretty good solution. Another big problem was that on sun’s website, the information about customizing javadoc applies to java 1.3 and the javadoc tool has completely changed since then. As a result we had to look through tons of source code in order to figure out all the details of javadoc when all we really needed was an overview of it. There were a couple of other stupid problems that we had to deal with which I guess were pretty educational because I got to see how larger software projects worked but overall I found them to be very annoying.
When we got down to writing our own code, it was very straightforward. We ended up extending all the classes in the javadoc source code and just modified a couple of methods in some of the classes to provide the behavior that we wanted. It really wasn’t that challenging of a project, it was just that we had to deal with all of this random problems that made the project take so much longer than I expected.
So I hope to finish up the project this week and put it up on the Joe-e website on Monday (which will be really cool). My partner and I have already started work on our next project, which sounds a lot more challenging and interesting. Overall, I’m really enjoying my research this semester, and am excited to stay with the team next semester and for the future.