HybridJava is not built on top of JSP or JSP 2.0, but only on top of Servlets. Of all the Servlet API features the technology uses only Request, Response and Session objects.

HybridJava technology is not aggravated with any kind of configuration. In fact, the compiler internally generates configuration based merely on the set of .page, .widget and .java files available. Neither does HybridJava technology camouflage configuration as Java annotations. In particular, HybridJava is XML free.

HybridJava is not a client-side technology though its framework relies on some basic JavaScript. HybridJava is transparent to any client-side technologies (like AJAX or FLEX).

HybridJava is not about data persistence beyond Servlet session scope. Its domain lies strictly within the Presentation Layer. It does not matter if behind the Presentation Layer the application uses Hibernate, EJB or JDBC.

HybridJava Framework does not include page navigation (workflow) which in our opinion belongs to some other technology layer. Same is true about authentication, authorization and many other things from the REST of Computer Science.

HybridJava is not a "template engine" - it capitalizes upon real compilation and thus upon a deep formalized understanding of the application code. All the operations on static content are executed at compile time so there is no room for such a thing as HTML caching - by the runtime all the static content is embedded into the bytecode in the .class file of the page.

Neither HybridJava widgets nor HybridJava components do return String values - all the values are passed directly to the Servlet's output PrintWriter object. The HybridJava Compiler is not supposed to generate any operations on Strings.

HybridJava technology does not provide any predefined widgets. Those included into the release .zip file are just samples. Our presumption is that a web technology should make it easier to write your own set of widgets than to study those predefined. We suggest that the priorities of widget reuse are: firstly reuse widgets within one application, secondly - within a company, and only then between different companies.

In our framework component instances are created only for those widgets that really need them because they have state. Pure presentation widgets in HybridJava are truly lightweight: they are compiled into nothing more than parts of the single rendering method of the page. Generated code accesses presentation data directly, so no JavaBeans of any kind are used and no interfaces like in JSF/Facelets.

HybridJava does not build DOM of the HTML page at the runtime. No "Listener classes" are attached to buttons. The page may have many HTML controls, and still only one listener instance for a given session. Unlike Wicket, HybridJava doesn't treat every Java loop as a component. Unlike JSF 2.0 and many others HybridJava doesn't treat every button as a component.

HybridJava does not have anything like a Value Stack of Struts 2 - JVM stack is quite sufficient for keeping contexts and works faster.

HybridJava programmer does not have to manually deal with IDs of components. The Framework does it for you, even if a component is used in loops or recursively. Based on these IDs the framework automatically dispatches input data to components.

HybridJava does NOT use forward, redirect, XSLT, DTO, "Filters", "Helper classes", Servlet mapping, XML-style namespaces. Nothing like TagSupport class (JSP 2) or UIComponentTag class (JSF) is used. No "Maps of attributes". There is no such thing as Fragments (Wicket etc.). There is no "Restore View" phase (JSF) - by default instances are stored in the Session between hits. You may easily modify the run-time source to store the state elsewhere, for instance in the HTML of the page itself.

We do not have any special Expression Language(EL). Java is the best Expression Language we know. In HybridJava you simply use Java expressions.

There is no special mechanism of "Layout" like in JSF, Tapestry, Struts/Tiles or ASP.NET MVC/Razor. With named sockets feature each widget may have layout, not only the "Master Page".

HybridJava technology does not recommend using multiple HTML forms in one page. This way the Framework ensures that all the user actions on the page are delivered to proper handlers.

HybridJava will never require 800 pages of manual. Not even 40. Thus HybridJava is a Green technology.

© 2012 HybridServerPages Group. All rights reserved.