OpenJDK 7 64-bit Mac

I updated the Darwin10Build instructions for building the BSD port of OpenJDK 7 on the OpenJDK wiki at Oracle. I successfully built 32-bit binaries, but decided to see if I could get it to build 64-bit binaries by changing the ARCH_DATA_MODEL=64 parameter to the build script. It worked. It reports that the build is amd64, but it is running on a MacBook Pro Intel Core Duo system. I added my 64-bit build script to the Darwin10Build instructions. Here is an image of my 64-bit build running tomcat. You can see the build is listed 1.7.0-internal-jyeary, and the OS Architecture amd64.

Maven Web Application on NetBeans

I was looking through the nbj2ee forums for NetBeans this morning. One of the items that caught my attention was a question about how to use the taglibs in the editor. It seems that once you add a taglib to the jsp page you get a TagLibraryValidator exception. I would have thought that the default project would have included the required libraries, but it does not. I opened a bug 188765 on it, but it probably should be an enhancement. My only issue is that the default project is a JSP page, and without the JSTL it is simply html. So the addition of the library is required to do something useful. Also, it is not apparent what the issue is with auto-complete without the library.

To get the Editor to work properly, you need to add a dependency to the pom.xml for the standard tag libraries.

<dependency>
<groupid>taglibs</groupid>
<artifactid>standard</artifactid>
<version>1.1.2</version>
<scope>provided</scope>
</dependency>

This should allow the auto-complete functionality to work as expected for the standard tag libraries. Here is an example of the error message:

Java Applet Permissions Mac OS X

I was working on Applets for the first time in a long time the other day. I found that I was getting SecurityException messages, and the applets would not work. This was related to the applet security policies not being set. I thought this should be easy to find and fix. It was not. It appears that this is somewhat arcane knowledge. There are plenty of documents, even release notes from Sun/Oracle on Windows, Linux, and Solaris, but Mac OS X...nothing.

Anyway here is the arcane part you are interested in.

The applet security policy is stored in the user's home directory in a file called .java.policy. Here is a wide open policy which probably should not be used except when absolutely necessary. You can comment the policy out using the /* */ syntax when it is not necessary.

grant {
permission java.security.AllPermission;
};

A more conservative approach would be to use something like this for testing from your localhost development system. The trailing "-" indicates any sub-directory from the top level.

grant codeBase "http://localhost/-" {
permission java.security.AllPermission;
}; 

This allows you to do wide open development and testing, but keeps the permissions limited from code outside of the current machine.

I have attached a NetBeans 6.9 project which includes code from Oracle which demonstrates the Java Security Manager. WriteFileApplet.zip

Mac OS X Leopard/Snow Leopard Web Sharing Forbidden Issues

Forbidden
You don't have permission to access /~username/ on this server.

Have you received an error like the one above, then I may have the solution for you. There are a number of posts on the web around permissions, and Apache configuration files, etc. I found that the solution was really simple, yet not obvious.

It has to do with File Sharing, you need to add the Sites directory to the list of directories which are shared, even if sharing is not turned on. See the example below.

Once you add the Sites directory to the list and turn on Web Sharing, you should be able to see the local sites for users on the local system.

HTML 5

I was looking at the presentation from Google on the HTML5 Rocks site. I found that the demo works for the most part on Firefox. I imagine that the presentation works better on Chrome, but I am not really interested in installing it. I went to the Microsoft site for HTML 5. It has a lot more quirks in it on Firefox.

It is really horrible that we are on the cusp of changing to HTML 5, and I am seeing the same issues that erupted during the browser wars of the 1990s. I am glad that Google has released the free video encoding codec WebM. It is a nice gesture on the part of Google. I only hope the rest of the vendors like Microsoft promote open codecs. It is not likely.

I am bothered that the HTML 5 Working Group at W3C considered putting a requirement for video codecs in the specification for which there was no freely available software. It is a fine demonstration of the the power of influence over standards bodies.  The W3C should work to keep the Internet free.