JDK/PRT (JPRT) Build/Test System Status

Status updates will be sent to jprt-announce@sun.com, a NetAdmin alias anyone is free to join.

Relationship to existing PRT source

The original Hotspot PRT manual is here: http://j2se.sfbay/web/bin/view/LabEast/PRTManual and the original Hotspot PRT source tree is at /net/prt-web.sfbay/prt/prt2-src. This new JDK/PRT (JPRT) master source tree will be kept at /java/svc/ws/jprt.

Initially I assumed I could just make "less than major" changes to the existing PRT system and add in the ability to build the j2se or JDK source tree. Early on I abandoned that plan and although I am re-using a great deal of the existing PRT system, I have also made extensive changes to what I have used. Much of this is cosmetic, by simply cleaning up code, adding javadoc comments, etc., but to say it is only cosmetic would be misleading, the changes are pretty extensive and beyond the abilities of filemerge to deal with. Some major problems with PRT have been fixed, e.g. the ByteBuffer/nio problems where the files being transferred would cause OOM's.

At first the code merging was acceptable with other PRT changes, but as I started using NetBeans more and more, and I started cleanup up parts of the PRT sources that needed cleanup or simplification, the merging became very time-consuming and de-stabilizing. It just didn't seem worth it to me. Originally the PRT designers had a prt '-jdk' option in mind, it was just never implemented. Unfortunately, this unimplemented '-jdk' option would have negated all the cool hotspot specific building/testing features of the PRT system that I wanted to have in a JDK PRT system. So the '-jdk' option was abandoned in favor of re-working all the existing hotspot specific code in the PRT to be more generic. The ability to select the build targets and the test targets is configured with a make/jprt.properties file in the source tree. The JPRT build process assumes there is a set of 'jprt_build_product', 'jprt_build_fastdebug', and 'jprt_build_debug' targets in the make/Makefile. This allows for the source tree to customize what is built, and also what is bundled. Each of these targets results in a single bundle or zip file that is what is saved on the driver side.

The use of NetBeans 4.1 (and then 5.0 and 5.5) was mostly considered to be an educational experience, but as I used it more and more, it became fairly essential to working on the code. I became 'addicted' so to speak. Inside NetBeans it is easy to re-structure, re-name, format code, fix import statements, encapsulate fields, add javadoc comments, edit javadoc comments, create JUnit tests, etc. This resulted in such massive changes and file movements and file re-names that syncing this up with another source tree was difficult if not impossible. Making it worse, it seems like filemerge isn't horribly helpful with merging Java code, it doesn't know any language syntax, and even if it did, this could be pretty difficult. So I gave up on a formal merged source tree with PRT for the time being and am just working with NetBeans and a raw source tree, mostly on my Mac PowerBook.

Specifically the source has changed in these ways:

I have not paid much attention to the Legacy issue of parsing old build and test target id's. The biggest legacy issue will be dealing with the legacy file layouts, which will be changed pretty severely in this new JPRT system.

What remains to do

So what is left?

Hardware Status

The initial hardware arrived in November 2005. The rack arrived several months later. The rackmount rails had to be ordered special and caused more delays. The hardware is finally being installed now (April 2006). The initial JPRT system with this hardware was up and running in May 2006.