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