[: GaB :]

It is a natural need when designing views in JSPs to include parts of the page programatically. For example having one index.jsp page defining the layout, and then including from there the content providing header, menu, content etc. jsp views.
When I first encountered this, Spring documentation encouraged me to use Tiles. However Tiles is a complex framework (for example allowing inheritance between views), which is an overkill in most situations. There is a much simpler way of including parts of the pages dynamically. Let's compare the possibilities:

<c:import url="menu.jsp"/>
<c:import url="http://www.example.com/menu"/>

This import facility issues a completely new HTTP request for the requested resource originating from the application server. When not prefixed with a protocol, the root of the request will be the directory of the current jsp file, the url attribute is a bit misleading in that case. Our current model attributes will be not available for the requested entity, therefore collision or unintended exposure are not possible. EL expressions are possible in the URL. Other protocols such as FTP are supported (depending on the application server's capabilities). You can also store the returned content in a variable (instead of including it), just add a var="variable" attribute. This comes handy to parse for example a fetched XML document.

<%@include file="menu.jsp" %>
<jsp:include page="menu.jsp"/>

This directive includes the requested entity relative from our current path. With a JSP it forwards the current parameters of the internal servlet request on the level of java function calls. (Non JSP-s are statically included.) As a consequence there is no new request and all model attributes are available. As far as I understand are these two directives semantically equivalent. However the latter has more potential. Consider the following example that can display a different menu for different screen sizes (i.e. desktop, mobile page types):

<jsp:include page="menu${pageType}.jsp">
	<jsp:param name="foo" value="bar"/>
</jsp:include>

I was designing the architecture for a simple but yet wannabe powerful web application, delivering some interactive multimedia content. So one considers Java, because of the nice language, portability, adoption and reliable environment.

Let's consider how we can do it: a Java applet.

I know, applets should be dead, but they are not. There is no alternative for it in Java 6, not until common Java/JavaFX replaces it in Java 7 8. Currently this is the only way to deliver Java content *in* the browser. Swing JApplets are just fine for our needs.

So we need support for:

• real time audio streams
• basic voice codecs
• basic IP packetizers
• reliable sound I/O (I and O at the same time)
• being able to layer these

First I consider the JRE standard JavaSound. As old as dumb. No device discovery, no direct support for streaming, no real codecs and packetizers. I saw it having problems with when both recording and playing in real-time.

So we come to the much more promising Java Multimedia Framework (JMF). It supports every single need of us. Basically I just would have to align interfaces and forward events. Sweet.

But then comes the shock: it is _not_ part of the JRE. At all. Moreover, it contains native libs, not deployable with .jar-s for an applet. (It does have a platform independent version, missing most of the codecs and DirectSound support.)
To use JMF, Sun expects from the users of my software to click on a link, to select the right platform from a combo box, to accept some terms of use, download an .exe file, run in, install an unknown peace of software in English, and then reload the browser. This is a no-go in 2009. Developers need components to build up systems. From (and only from) the users' perspective it has to just work.

Why is this not part of the JRE?!

There is no other option, then to wait for a Java Media Components (JMC) to arrive. And hope that it will fulfill our needs.

Why don't I just use Java Web Start? For two reasons:

• It requires an additional click. When triggering a .jnlp reference it first pops a window prompting the user to either "Save File" or by default "Open with OpenJDK Java 6 Web Start (default)". If Java is already installing a plugin into the browsers (for the applets), why not have a handler in the browser for application/x-java-jnlp-file file types to directly start with Java Web Start? Then application could start whenever I want not requiring the user to click.
• JNLP does not solve our problem. You can not deliver JMF with JNLP either. A Java desktop application started with JNLP would still require the prior, manual installation of JMF.

As of today, there is no way in Java to deliver basic multimedia content on the web. This is not the way you can challenge Silverlight, not to mention Flash.

Simly create this interface, and use that as your own serializable marker in GWT:

package eu.gablog.java;
 
import java.io.Serializable;
 
public interface IsSerializable extends Serializable,
                com.google.gwt.user.client.rpc.IsSerializable {
 
}