The Angular Mini-Book is a
guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and
deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.
Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.
For book updates, follow @angular_book on Twitter.
The JHipster Mini-Book is a
guide to getting started with hip technologies today: Angular, Bootstrap, and Spring
Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.
This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.
For book updates, follow @jhipster-book on Twitter.
One of the major issues in XDoclet's JIRA has been the fact that XDoclet doesn't work with JDK 5.0 syntax. After many comments and lots of debate, Anton Adamansky has submitted a patch. If you want to use XDoclet with JDK 5.0 - you might want to give this patch a run for its money. Hopefully we can get it included in XDoclet in the near future.
It looks like the Struts guys are going to base Struts 2.0 on JSF (detailed proposal, wiki). It should be interesting to see a web framework developed on top of another web framework. Of course, it's been done before. The two things I really like in this proposal are 1) a built-in IoC container and 2) the security stuff (remember me, user registration). Here's the details from the proposal:
3.5 Service Provisioning APIs
Inversion of Control (IoC) containers (the techniques are also referred
to as Dependency Injection) are becoming a popular mechanism for assembling
the required services and logic of an application. If Struts included such
a framework, it would provide a solid basis for building maintainable apps,
as well as allowing the framework to configure itself using the same
capabilities.
Rather than building such a container ourselves, we should seek to
incorporate an existing one that is license-compatible and which can
be integrated into the JSF managed beans facilities (so that value binding
and method binding expressions can leverage the facilities of this
container transparently). From my research so far, I like Spring's
capabilities in this area the best, but am open to other suggestions.
3.6 Authentication and Authorization APIs
In order to support reasonably complete solutions for applications that
wish to provide their own authentication and authorization services (as well
as interact with container managed security), we need APIs available for
performing user registration, implementing "remember me" features, and
represent the results via a wrapped request (so that apps depending on
getRemoteUser(), getUserPrincipal(), and isUserInRole() will still work).
Using JDK 1.4 as a base platform would allow us to integrate mechanisms
like JAAS. Other alternatives include plugins like SecurityFilter.
I added the emphsis on Spring. I'm all for this because 1) I'm on the JSF Expert Group (as of last week) and 2) it'd be nice to see JSF stretched, poked and prodded. IMO, JSF needs more "real-world" usage and the popularity of Struts will give it that. By "real-world" usage - I mean it needs to be used by developers that aren't cooped up in some cube with a fancy IDE. I also like the proposal because there's tons of Struts apps out there - and many of them might want to "upgrade". This means more (potential) work for me. Of course, I also plan on spending more time with Tapestry so I can offer client's an "educated" suggestion. BTW, the reason I joined the JSF EG is to be the "developer's voice" among the IDE Vendors. So if you'd like your voice to be heard - send me your suggestions, I'm all ears.
The question is - when will Shale be released? Of course, since it's open-source, the answer is "when it's ready". My guess is 1 year from today. I'm thinking of making AppFuse 2.0 use this new stuff. Of course, it'll have Tapestry and JSF options long before that.
If nothing else, the Shale proposal should motivate other web framework developers to highlight their roadmaps and what's new and cool on their horizons.
As part of AppFuse 1.6, I was hoping to supply the option to use Resin instead of Tomcat. In reality, hardly anyone has asked for this on the mailing list - but since so many folks say that "Resin is better" - I figured I'd give it a whirl. I hate to be the guy that spoils all the Resin users mantra, but it seems like Tomcat is the better server. Why? Speed, compliance and shit works. Here are some things I found:
I did have to hack a number of things to even run the tests (which verifies titles, success messages, etc.) on Resin. First of all, SiteMesh seems to puke with if you try to use <dispatcher>FORWARD</dispatcher> on the filter-mapping. I had to comment this out, resulting in a lots of HTML Tidy errors during the tests ( Error: <content> is not recognized!). I also had to turn off Resin's fast-jstl to bypass this bug. Finally, I had to revert the displaytag to using the non-EL version (which required changing titleKey -> title and name="${listName}" -> name="listName"). It seems that Resin enables EL even if you're using a 2.3 DTD. With Tomcat, and I believe the spec says this, EL is only enabled if you use a 2.4 XSD.
So there you have it folks, not only is Resin 3.0.9 slower than Tomcat 5.0.28 (JDK 1.4.2, Windows XP), but it's not standards compliant. Of course, the speed could be due to my using the open source version (with performance enhancements turned off) - but I'd think the other (albeit minor) stuff should be easy to fix. Everytime I try to use Resin, I end up finding bugs and going back to Tomcat. I guess this is another one of those days. I don't think I'll include a Resin installer as part of 1.6, but I might distribute one later if I can get these issues solved. I wonder if I should give Orion a run for its money?
P.S. Since I know people are going to ask: Tomcat 5.5.3 with JDK 5.0 took 9 seconds to startup. Running "test-canoo"? First run: 37 seconds, second: 14 seconds. Looks like the new compiler is quite a bit faster.
Download · Release Notes · Learn More · Project Weblog. I've been looking for something like Cargo for a while now - mainly so I could provide an easy way to test JSPs (and therefore the whole app) in-container. For the last couple of years, I've been using Cactus' <runservertests> task, but it requires you to configure your own startup and shutdown targets - which can be difficult for the different containers. Cargo makes this easy. So easy that I've added it as a topic to Chapter 8 of Spring Live. BTW, the MyUsers sample app shows you how to use jMock and Easy Mock for isolating Manager tests and Action/Controller tests - something that I might eventually move to with AppFuse.
In 1.5, AppFuse's build.xml is tightly coupled to Tomcat for running Cactus tests and Canoo WebTests. There are only a couple of Cactus tests in the Spring and WebWork versions - LoginServletTest and ActionFilterTest and I believe I can use Spring Mocks to refactor those and test them out-of-container.
Using Spring's ContextLoaderPlugin for Struts, I should be able start testing the Struts Actions using MockStrutsTestCase too. This means that the only in-container tests will be Canoo WebTests. As part of 1.6, hopefully you'll be able to run the "test-web" target sans container. Right now it sounds like quite a challenge, but being able to run Spring's Controllers and WebWorks Actions out-of-container is a really nice feature. Furthermore, removing Cactus as a dependency would open the doors for using JDK 5.0.
I'm also hoping to add support for switching containers - by running a simple script that nips and tucks the build.xml. For 1.6, I'll try to add an installer for Resin. If it's easy, I might take a stab at Jetty and Orion too.
Update: Cactus is gone - there's no need for it anymore as all actions/controllers, filters and listeners can be tested out-of-container. The best part is I didn't have to change any application code - just a few tests. Sweet!
I did some experimenting this evening with JDK 5.0 and Tomcat 5.5.2. The good news is that AppFuse compiles fine with JDK 5.0 and runs on Tomcat 5.5.2 nicely too. Here's a couple of things I found:
JDK 5.0
I received a number of interesting errors from the new JDK. Here's one of them:
[javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details.
I received a few other messages that were deprecation warnings. The wierd thing is that it was telling me what's deprecated in HttpServletResponse, rather than what's deprecated in my code. Huh - what's the point?
Unfortunately, I found that Cactus won't run on JDK 5.0. Too bad, everything else seems to work fine.
Tomcat 5.5.2
I like the speediness of the new Tomcat, but I was disappointed to find out that they changed the DTD for the context.xml file. The old one works fine on Tomcat 4.1.x and 5.0.x, but you have to make some modifications for it to work on 5.5.x. To be fair, the new syntax is shorter and more concise. I've updated AppFuse's build.xml to detect Tomcat 5.5 and swap context files as appropriate.
Because of the Cactus bug, I think I'll be sticking with JDK 1.4.2 and Tomcat 5.0.28 for now - but it's cool to know that everything else will work once Cactus is fixed.
Last night I attended the local Denver JUG meeting.
Chris Huston gave a presentation on JMX and
Dion gave a presentation on JDO 2.0. Below are my notes from the event.
-----------------------------
Java Management Extensions one of the first JSRs and now included in to JDK 5. Monitors health of the system. Alter sys-admin of error conditions. Provides capability of to view and modify runtime parameters.
MBeans are deployed in an MBeanServer and their capabilities are exposed through Connectors. Then tools talk to these connectors to get their information.
JMX is covered by two separate specifications: JSR-3 (MBeans) and JSR-160 (Connectors). BTW, Chris has some good slide-making capabilities - I'll have to get some tips from him for my next preso. For example, he shows an entire class and its methods, then he fades it and zooms in on certain methods and highlights them to explain what they do.
Four types of MBeans: Standard MBeans, Dynamic MBeans, Model MBeans and Open MBeans. More info on these Mbeans can be found at http://docs.sun.com.
Standard MBean: All you need to do create an interface for your class your class name with "MBean" appended to it.
In order to deploy, you need to create and configure an MBeanServer.
You can create an MBeanServer using javax.management.MBeanServerFactory.createMBeanServer().
MBeanServers keep track of MBeans
using a javax.management.ObjectName.
After creating and configuring an MBeanServer, you simply need to
register your MBean using an Agent. All pretty simple so far, right? Now you have to use a Connector
to expose your MBean to the outside world.
"Connectors are the fly in the ointment." MX4J is an open source project that has good Connectors: i.e. RMIAdaptor and HTTPAdaptor. There's also SNMP Adapters from a number of commercial vendors. In order to solve the current lack of good Connectors we have JSR-160: Distributed Services Specification. This JSR defines one connector: JMXConnector (part of JDK 5).
Chris is now showing us a counter widget deployed as a Swing app and managed using MX4J's web interfaces. Very cool stuff - the ability manipulate runtime parameters. As Chris stated - the real power of JMX will come from the tools. I wonder if there's MBeans available for monitoring webapps - seems like there'd be quite a market for management beans you could just drop in and deploy.
Notifications are another feature of MBeans and can be sent by an MBean. Two important interfaces: NotificationEmitter and NotificationListener.
Chris gave a good introduction to JMX, but I don't see myself using it anytime soon. It seems to be something that framework and container developers might use, but not many application developers. Maybe I'm wrong - are you deploying MBeans as part of your web applications? Chris mentioned that Hibernate and Spring have MBeans as part of their distribution - anyone using these? If nothing else, it's great to know that JMX is available if I ever do need to monitor and control applications.
-----------------------------
Now Dion's up after a 1/2 hour break with announcements. Dion is talking about JDO 2.0. I think JDO would
be a lot more popular if it wasn't for Hibernate. Hibernate seems to have done JDO better and faster.
What is JDO?
JDO Main Objectives:
Other Objectives:
When JDO first started, a bad thing happened - the object database guys were heavily involved. JDO 1.0 had 80% of its Expert Group from object database vendors. JDO 2.0 got object guys off the committee and real-world (relational) folks onto it.
JDO 1.0: Most of it is not very new - just a standard way of implementing persistence. Other proprietary tools already accomplish most of what JDO is.
JDO 2.0 Strategic Goals:
JDO 2 Status: First Early Draft Review is out there. Soon there's going to be a Community Review - then things
will start rolling after that.
JDO 2.0 Goals:
Dion's take on politics between EJB 3 and JDO 2
Why are people even arguing about it? Money. Because companies have invested a lot of time
and money into X technology and therefore they bash the other. This problem might be solved
by an O/R Mapping JSR that both EJB and JDO have to adhere to.
JDBC vs. JDO
| JDBC | JDO |
|---|---|
| SQL-oriented | Object-oriented |
| Explicit intrusive code | Fully transparent |
| Manual mapping | Automatic mapping (automatic == create XML file) |
| RDBMS-centric | Universal |
JDO will use all J2EE services inside a container.
Deployment time scalability - database becomes bottleneck as number of users increases. JDO middle tier
can relieve this load on the databse. JDO's configuration can be altered at deploy time to handle better
scalability through caching.
JDO 2.0 Multi-tier Development - big thing is disconnected objects through attach/detach. Very simple API
for detaching and re-attaching objects. Internally there's a version that's used to determine if the object
is the same one.
JDO and EJB
As opposed to Entity bean, JDO instances...
And as of JDO 2 (new and improved object modeling!)
Some argue that JDO is what Entity Beans should have been!
Some argue that JDO complements Entity Beans because Entity beans can use JDO.
EJB3 is totally moving directorys with regards to Entity Beans, and they are much more like JDO.
EJB3 EntityManager == JDO PersistenceManager == Hibernate Session
JDO and Connector Architecture -
JDO is NOT a framework, but plays well with others!
The JDO architecture uses the J2EE Connector architecture for application servers. The JDO PersistenceManager is a caching manager as defined
by the J2EE Connector architecture.
A PersistenceManager may define the following Connector components:
Persistence Contract (behind the scenes)
- To achieve transparence, JDO:
PersistenceCapable interface
- Declares any fields available for persistence storeage
- Defines methods that allow JDO instance management
JDO has a number of callbacks that you can implement: jdoPostLoad(), jdoPreStore(), jdoPreClear(), jdoPreDelete().
In JDO 1: one interface: InstanceCallbacks
In JDO 2: InstanceCallbacks purely extend interfaces: LoadCallback, StoreCallback, etc.
Ways to make classes persistence capable: byte code enhancement, annotations (maybe for JDO 2.1).
JDO Interfaces: PersistenceManagerFactory, PersistenceManager, Transaction (new set/getRollbackOnly() in JDO 2)
and JDOHelper (class with static methods, for use by persistence-aware classes), Query, Extent. You'll probably
never use an Extent; like "select * from table". Represents all instances of a class or subclasses.
A persistence cabable class is just a POJO - you could use the same class for JDO and/or Hibernate. A default
contructor is required in JDO 1, but not in 2.
JDO 2.0 has "use cases" for lazy-loading. This enables you to configure fetching based on certain situations.
Sounds pretty cool.
Extent is usually optimized for better performance. If you're selecting all records from a table, you're
probably better of using Extent vs. Query in order to avoid OutOfMemory errors.
New in JDO 2: ability to specify query filters in other languages - i.e. SQL or HQL or user-defined. These
languages are up to the JDO vendor to implement.
JDO can use stored procedures if you map it in your metadata.
JDO 2.0's Query API looks very rich. It allows you to limit your results to certain properties/columns, as well
as set what type of to return.
JDO 2.0 supports obtaining a java.sql.Connection from PersistenceManager. However, this may reduce portability
since not all SQL is portable b/w databases.
Overall, I thought this was a great talk by Dion. If you're looking to start working with JDO 2.0, I'd recommend
JPOX (also see JPOX with Spring or Tapestry). Unfortunately, their implementation still requires you to "enhance" your
classes at build-time, but hopefully they'll have a transparent mechanism for manipulation (i.e. cglib) soon.
Mac Rumors: No G5 PowerBooks Anytime Soon. If I had a vote, I'd say it's time to give up on the G5 for the PowerBook and make OS X run on Intel or AMD chips - then produce an Intel/AMD version of the PowerBook. Apple makes great hardware, but their laptops are much slower than their Intel counterparts (for Java at least). All I want is a PowerBook that can keep up with an Intel-based laptop - is that too much to ask?
I'm sitting at the Denver JUG
meeting and Joshua Bloch
and Neal Gafter just finished a talk on "Java
Puzzlers". I didn't show up until halfway through - but it was still a
great half hour. They had a bunch of slides with problems that had
seemingly easy answers. They'd both have a good dialog about their
proposed answers - and then asked the crowd what they thought. The
problems were mostly due to dumb (but real world mistakes) - the kind of
thing you'd slap your fellow programmer for writing. These guys are
definitely fun to listen to - next up is Tiger and what's new in 1.5 (I
thought it was 5.0?). Boy, it's a full room tonight - I'd bet there's
around 120-150 people here.
Taming the Tiger
Major theme of "JDK 5" is ease of development with features like generics, for-each loop,
autoboxing/unboxing, enums, varargs, static imports and annotations.
It's designed to make programs clearer, shorter and safer by providing linguistic support for commong idioms. Sidenote:
Joshua said that Neal wrote the compiler - and they've basically made it more rigorous so it writes
the boilerplate code for you. New features do no sacrifice compatibility or
compromise the spirit of the language. Neal has been using these features for a couple of years now and
he says he's really enjoyed them.
Goal of this talk is to make it easy for us to understand JDK 5 so we can start using it in our development. Let's look at the different features of 5.0.
Generics, For-Each and Autoboxing/unboxing
Generics allow you to specify the element type of collection. Rather than specifying a List - you specify
it's contents - i.e. String. It's basically stronger typing with less typing which enforces the specification
at compile time. For example, the following code using the new for-each syntax to iterate through a list of TimerTasks
in a collection. Notice the lack of casting and easy-to-read loop syntax.
void cancellAll(Collection<TimerTask> c) {
for (TimerTask task : c) {
task.cancel();
}
}
Bytecode is the same as it is in 1.4 - 5.0 merely converts the code for you. One question that these guys
have heard a lot is why ":" rather than "in". The answer is twofold - because "in" is already
a keyword (for example, System.in) and they didn't want to introduce a new keyword. Because 'in' is an identifier that is already in widespread use, and thus they could not make it a keyword without serious impact. Only new
keyword in JDK 5 is enum.
The Collection Interface has been Generified. All existing code should still work, but you
can also use the new stuff if you like. I haven't listened much to what's new in 5.0 - but this is
wicked cool. You might say it sucks because now you end up with strongly typed stuff, but at least
you won't have any more ClassCastExceptions.
For example, you can now easily do the following:
Integer i = new Integer(5);
Map map = new HashMap();
map.put("result", i+1);
Notice that the Integer type is converted to an int for the addition, and then back to an Integer when it gets
put into the Map. Cool, huh?
JDK 5 also simplifies reflection. Class Class has been generified -
Class literal Foo.class is of type Class<Foo>. This enables compile-time
type-safe reflection w/o casting. The following used to return an Object and required casting.
Foo foo = Foo.class.newInstance();
This enables strongly typed static factories. I wonder if this can be
used with Spring so you don't have to cast a bean when grabbing it from the ApplicationContext?
When should you use Generics? Any time you can - unless you need to run on a pre-5.0 VM. The extra
effor in generifying code is worth it - especially b/c of increased clarity and type safety.
When to use for-each loop? Any time you can b/c it really beautifies code and makes it much
easier to write. It's probably the smallest new feature in 5.0, but likely to be a favorite.
You can't use for-each for these cases:
The lack of an index seems to rub the crowd wrong. Joshua and Neal's response is they tried to
design something very simple that would capture 80% of usage. If you need an index, just use
the old for loop - it ain't that hard; we've been doing it for years!
If you want to use for-each in your APIs - i.e. if you're writing a framework, a class should implement
the new Iterable class.
When should you use autoboxing? When there is an impedance mismatch b/w reference types
and primitives. Not
appropriate for scientific computing. An Integer is not a substitute for an int. It simply hides
the distinction between wrappers and primitives. A null unboxes by returning a NullPointerException.
They did consider setting it to the primitive's default, but the community voted 50-1 to for NPE.
Enums
JDK 5 includes linguistic support for enumerated types. Advanced OO features include the ability to
add methods and fields to enums. Much clearer, safer, more powerful than existing alternatives (i.e. int enums).
enum Season { WINTER, SPRING, SUMMER, FALL }
I just noticed that it's boiling in here - A/C must be out again in the auditorium. It's 8:20 right now, I hope this is over soon, I can feel sweat beading on my forehead.
Enums are Comparable and Serializable. Enum constants should be named similar to constants. Enums are basically
a new type of class. As far as I can tell, I have no use for Enums in my code. There's lots of gasps
from the crowd as Joshua is describing the features of Enums (i.e. constant-specific methods). Sure
it looks cool, but I still don't think I have a use for it. Maybe framework developers will find this
useful. BTW, there's two high-performance collection classes: EnumSet (bit-vector) and EnumMap (array).
EnumSet replaces traditional bit-flags: i.e. EnumSet.of(Style.BOLD, Style.ITALIC).
When should you use Enums?
Quote of the night: "It's extraordinarily rare that you'll need to cast when programming with JDK 5".
Varargs
A method that takes an arbitrary number of values requires you to create an array. Varargs automates
and hides the process. James Gosling contributed the ... syntax. Varargs always has to be the last
parameter. MessageFormat.format has been retrofitted with varargs in JDK 5:
public static String format(String pattern, Object... arguments);
String result = MessageFormat.format("At {1,time} on {1,date}, there was {2} on planet "
+ "{0,number,integer}.", 7, new Date(),
"a disturbance in the Force");
Reflection is now much easier with Varargs - so you can call c.getMethod("test").invoke(c.newInstance())
instead of c.getMethod("test", new Object[0]).invoke(c.newInstance(), new Object[0])).
When should you use Varargs?
Static Imports
Clients must qualify static members with class name (Math.PI).
To avoid this, some programmers put constants in an interface and implement it. BAD - "Constant Interface Antipattern".
They've made this mistake in the JDK - java.util.jar has this pattern. Static import allows unqualified access to
static member w/o extending a type. All static fields, methods, etc. will be available for your
class using static imports. For example:
import static java.lang.Math.*; r = cos(PI * theta);
When should you use Static Imports?
Metadata
Decorates programs with additional information. Annotations don't directly affect program semantics. They *can*
affect treatment by tools and libraries. Can be read from: source, class files, or reflectively. Ad hoc examples:
transient, @deprecated. Tiger provides a general purpose metadata facility.
Why Metadata?
Metadata encourages a declarative programming style - tell a computer what to do, now how to do it.
Annotation Type Declarations are similar to interface declarations.
Special kinds of annotations include Marker annotations and Single-element annotations.
The main reason for annotations is for tools providers.
Neal thought that JDK 5 Beta 3 or Release Candidate was available at
http://java.sun.com/j2se/1.5.0, but it looks like Beta 2 is the latest release. The fact that he said that implies that a new release should be available shortly. Neal
also mentioned that JDK 5 (final) would be shipping soon.
Random fact:
Google uses a lot of Java - entire Ads front-end is done in Java.
This was a great talk about all the new features of JDK 5 - I can't wait to start using them. It might be awhile before
I can convert AppFuse to JSP 2.0 and JDK 5, but it'll be a good day when I can write my apps using these technologies. Tonight was the best overview of JDK 5 that I've seen so far - in print or person.
Update: Presentations PDFs have been published: Programming Puzzles and Taming the Tiger.
For those of you looking for an AppFuse Light, I have good news for you. I've actually been sitting on it for several months now, but now I'm prepared to release it. It's name is Equinox and it's much, much simpler than AppFuse. Equinox has only one build-time dependency (CATALINA_HOME being set for the servlet-api.jar). There's no code generation and no features - not even security. However, it supports building, testing and deploying from Ant, and even has support for managing Tomcat out-of-the-box.
To get started with Equinox, you can download the QuickStart Chapter from Spring Live. This chapter shows you how to develop a simple webapp using Struts, Spring and Hibernate - which talks to an HSQL database. Struts and Spring are integrated using the ContextLoaderPlugin and all tests are designed to be run out-of-container using JUnit and StrutsTestCase. Equinox ships with project files for both Eclipse and IDEA so you can develop and run the tests in either of these top-notch IDEs. There's also a demo available. Thanks to Boér Attila for the kick-ass CSS.
If you like what you see in the QuickStart Chapter, there's much more in the other ERP chapters of Spring Live - now available for download. Too see what's in the other chapters, checkout the Chapter Summaries.
This is a nice milestone - feels good to have made it this far. Have a good weekend!
Went to bed at 4 a.m., up at 7 a.m. and woke up w/o a hangover - it's going to be a good day. Last night was spent at the Thirsty Bear, followed by beers until 3 with Matt and James from SourceBeat. The wireless connection sucks - too many people I'm guessing.
I'm sitting in the keynote by Jonathan Schwartz - what's the big announcement? My bet is that the tiger/tiger thing is JDK 1.5 is going to be released - and it's going to be released on the Mac at the same time.
Schwartz's speech is fairly boring - it's definitely a whole lotta marketing. I'm falling asleep - give us something good!
The number of Java Developers grew by 30% last year - from 3 to 4 million. Schwartz thinks that Java will "roar" into the automotive industry next. Some guy just drove in a BMW and they're demoing a Java-based entertainment system. Basically, it's a just a voice-controlled system for communication, climate, navigation and entertainment. Looks cool I guess. It'd be sweet to get a gig developing apps for cars, wouldn't it?
Now Schwartz is back on stage. Java.com gets 9 million hits enough, and 6-7 million click the "get it now" button to get/install Java. After sitting in this thing for the last hour - I can see why people skip it. OK, this is cool - Project Looking Glass is going to be open-sourced, but you probably already knew that since Java 3D has been open sourced.
If you want to say hi today, I'm wearing a brown Hawaiian shirt and shorts.