Job Placement Home Page

Job Placement home page redesign

The Job Placement home page has been redesigned to feature a new layout.

The redesign was undertaken in response to user comments and usage data about the home page. The new design achieves some specific goals:

* It improves use of screen space and makes some important links more prominent.
* The font size is larger, improving readability.

The new page was designed and programmed by LionAlquds.

Feedback will help improve this critical service; visitors to the site are invited to send comments.

Sun unveils first real-time Java implementation

Sun on Tuesday in the US released its first Java platform that offers real-time capabilities. The platform, Java Real-Time System 1.0, implements the Real-time Specification for Java (RTSJ), a blueprint for how Java can be extended to support real-time application programming.

This is one of the oldest JSRs (JSR-1!), indicating that real-time for Java is either very low priority or that it's a "hard problem." (Probably the latter.) Real-time systems aren't required to be fast, but are required to be predictable, which can be much harder than it sounds, especially given Java's thread model.

The real-time implementation looks to be closer to Java Micro Edition than Java SE, such that programmers will have to directly handle things like memory allocation.

A case against Annotations

I’d see a case for replacing XML, and annotations. Annotations will be seen as litter on the Java landscape. One thing that strikes me about the move from XML to annotations is the shift from having a many-one relationship between code and XML to a one-one relationship between code and annotations, as well as the move from weakly-typed to more strongly-typed enforced configuration. I believe that there is a better intermediate solution that keeps a many-one relationship between code and XML as well as strongly typed configuration.

A better solution for Sun would have been to come up with an XML-like structure that could be coded into Java. This would give all the benefits of rigorous type enforcement, and the benefits of a many-one relationship between code and configuration, and the benefits of separating the configuration data out of business objects.

I would see these XML structures as being defined by something with similar semantics to XML schemas, but they would be implemented something like nested static classes containing defaults. When I look at the XML schema semantics and extended Java nested static classes, they do seem like they have similar semantics.

Extended nested static classes would provide type safety. They could be overridden by specific implementations. They could be available to introspection. Configuration would be kept in Java. I believe it would be worth exploring extending the semantics of Java nested static classes to do the job of XML configurations in a more rigorous manner than annotations provide.