Java Web App Framework Millstone 3.0 Released

idot writes "Millstone 3.0 is a java LGPLed library for the development of networked applications. The developer doesn't have to deal with HTML or individual pages, but rather writes a very swing like continous client application. A terminal adapter converts the abstract UI together with a Java Servlet container to the desired themed client side code. In case of Web applications HTML complete with or without JavaScript. Press release millstone home page complex go example game It seems to be a very mature framework, whose first two iterations were used only internally by the developers. It will be interesting to test this library against JSF, tapestry etc. in terms of developer usability and scalability."

Comments

Millstone

[Anonymous Coward]

is actually meant to be a library destroyer, and has been a staple of control players for years.

How does this compare with Echo?

[fuzzbrain]

This seems quite similar to echo which is getting close to reaching 1.0. Can anyone comment as to how the two compare?

Re:How does this compare with Echo?

[travisb]

Millstone does not seam as feature rich. I have downloaded it and after looking at a few classes for some of the features I love in echo I find it lacking for example Button There appears to be no rollover support. It seams that Millstone is a reasonable framework, but I feel that it compares better to AWT then swing where ECHO compares to SWING.

Re:How does this compare with Echo?

[idot]

Thanks for the tip.
Now I will have something to play around with over the holidays.

On the one hand, competition is good. On the other ... I hope somebody will post a comparison of the various frameworks.

Create two, three many petstores!

Re:How does this compare with Echo?

[Anonymous Coward]

Since Millstone has a clean separation between the abstract UI and the actual presentation of it, rollovers would be implemented in the theme, not in the java components.

By using this approach the api is kept to a minimum, and the look & feel is implemented in the theme (for instance by a useability engineer).

Remember that Millstone is designed to support different types of 'terminals' ('platforms'?) trough terminal-adapters -- the web-adapter does HTML, while one could even imageine an X-adapter, XUL-adapter, MIDP-adapter etc...

Look at the overview on the millstone.org website for more information.

Re:How does this compare with Echo?

[jole]

The philosophy of Echo and Millstone are quite different from each other: Echo components include their representation (fonts, colors, rollover efect...). In Millstone all the components are representation independent. The representation is given in adapter (and in web adapters case in web adapter theme).

Using rollover (as well as any other visual efects) in Millstone applications is specified with styles: Just do button.setStyle("rollover") and define "rollover" style as you wish in CSS. If you are just using (extending) the default theme you can do this by adding .button-rollover class definition. You can freely add any CSS style specifications (fonts, colors, layouting, backgrounds, ...). If you want to do more advanced things (DHTML animations, popups, scripted client side logic, sound, ...) you can easily add new button template for your style in theme XSL.

To summarize: in Echo it is easier to turn on limited roll-over effects by the programmer. In Millstone theme designer (not necessarily the programmer) can freely add any visual effects supported by the browsers.

Re:How does this compare with Echo?

[jole]

First a disclaimer: I am one of the head developers of Millstone and CEO of the company behind it.

I see that the difference in the nunber of features between Echo and Millstone is huge -- in favour of Millstone. I think that this can be most easily demonstrated by just going through Millstone feature online demo (also available for download) and Echo Test application. Some of the most obvious differences are: extensive data binding, server side events, tree component and xsl-theme support.

Still Echo is very nice framework and provides good competition for Millstone. I hope that the both frameworks gain popularity.

Re:How does this compare with Echo?

[TodLiebeck]

I see that the difference in the nunber of features between Echo and Millstone is huge -- in favour of Millstone. I think that this can be most easily demonstrated by just going through Millstone feature online demo [millstone.org] (also available for download [sourceforge.net]) and Echo Test application [nextapp.com]. Some of the most obvious differences are: extensive data binding, server side events, tree component and xsl-theme support.

I am the lead developer of Echo. I am therefore, by definition, not qualified to make an unbiased comparison between Millstone and Echo. An analysis by a developer of either product will be flawed because that developer will be significantly more familiar with his/her own product than that of another. Such a developer also has an interest in seeing a particular outcome to any comparison.

That said, I do feel the need to set a few things right. First of all, to perform a feature-for-feature comparison between Millstone and Echo, one also needs to consider EchoPoint. EchoPoint is an LGPL licensed collection of Echo components. It includes features such as the mentioned server-side event generation and a large collection of user-interface components including trees. For more information about these components, visit http://echopoint.sourceforge.net, or specifically http://echopoint.sourceforge.net/LinkedArticles/Us ingEchoPointComponents.html. Also, please note that the TestForEcho application is not intended as a demo. TestForEcho is maintained only as an interactive test application for the framework, and as such, its aesthetics and demonstrative capabilities are quite limited.

As far as the data-binding issue goes, I am not aware of how Millstone distinguishes itself from Echo. Both frameworks use an architecture where data is decoupled from the components themselves, such that developers are not required to create code to update the state of components when their represented data changes.

In the case of XSL stylesheet-baesd themes, you are correct that Echo does not provide this capability in this manner. The reason we have not pursued this course is architectural: Echo goes about rendering the HTML and JavaScript representations of components using Java-based renderers, which take into account the eccentricities of different Web browsers to ensure consistent output. Look-and-feel definition is handled on the "component-side" of the framework, rather than the "rendering-side." Should one desire to fully externalize L&F information, the EchoPoint project provides a package to do so by placing such data into cascading-style-sheet-like resources.

One thing everyone needs to bear in mind when considering Echo or making comparisons against it is that it has been developed for the creation of Web-based applications, not for the creation of Web pages. The term "Web application" is often gratuitously used to describe the spectrum of software between a feedback form and an online banking system. Echo is intended for the latter portion of this spectrum. It was built to offer capabilities previously only available to rich-client (desktop-based) interfaces.

In order to offer a level of capability approaching that of rich-clients, Echo includes features which are to the best of my knowledge not available from any other framework. Echo provides a client-side state management engine, written as a series of cross-browser JavaScript modules which serve to synchronize the state of the client browser with that of the server-side application. This engine is capable of managing multiple browser windows with a degree of control that is far beyond what one would expect from a Web application framework. Echo makes use of a hidden "controller" frame in each browser window to transparently communicate the state of the client to the server, and to allow the server to issue directives back to the client without re-rendering unchanged resources. While my description of these features unfortunately must be quite technical, the real benefit of them is a user and developer experience not unlike that seen with a rich-client interface.

Please understand that my comments are in no way intended to flame or otherwise deride the Millstone framework. I wish you folks nothing but the best.

Best regards

Re:How does this compare with Echo?

[jole]

Echopoint looks very interesting and comprehensive collection of components. With compatible lisence (LGPL) it might event be possible to port some of the components to Millstone.

So to summarize comparison discussion, there is some philosophical (and architectural) differences in the design of the both frameworks. I wish that the both frameworks will find their audiences in the applications they are most suited for.

My boss...

[Randolpho]

Is gonna love this. *sigh* More work for me... ;)

It looks nice!

[jsse]

It uses swing-like api and it doesn't has any overhead with pure java applet.

My friend who is a financial content provider which distribute information with the help of java applets. They just stuck with the problem with XP which does not come with Java support, which is very bad for their business because their users usually don't know(or don't want) to download and install a JRE. Let's see if it can help him.

once again...

[tongue]

the slashvertisements strike again.

Re:once again...

[MacroRex]

Keep in mind that the company open sourced their core product. Would you rather read about closed source products, of which there is no lack in /. anyway?

Great name

[Shimmer]

Millstone: A heavy weight; a burden: "This job is a millstone around my neck."

Re:Great name

[pnatural]

aye, as if Sun(tm) Java(tm) did not already have enough baggage. java needs many things, but Yet Another Framework or TLA (YAFTLA) is not one of them.

Re:Great name

[Miqlo]

Lol, good irony indeed, yet the real etymology of the name, is the name of our company that created it, IT Mill Ltd.

Miq

Re:Great name

[MacroRex]

You know, not all Millstones are not bad. For example, there is the Official Beverage of IT Mill ltd., which is quite good :)

Note: The Millstone-the-UI-library lives in http://www.millstone.org, millstone.com is about something completely different.

Re:Great name

[Anonymous Coward]

Maybe this project is a millstone around competitors neck?

Re:Great name

[jole]

In fact the name was meant to describe a stable core that is spinning inside the mill (Millstone was targeted to be internal tool in the beginning). Anyway - blame me, as I was the one who came up with that name...

Re:Great name

[Shimmer]

Okay, consider yourself blamed. Surely you were aware of the irony when you chose that name?

-- Brian

Re:Great name

[jole]

The product naming would not be taken so seriously. But on the API the good naming is very important. Everybody in IT Mill liked the name and still do.

One related naming issue: we first (in year 2000) called UI-components UI-automatas (UIA) to describe that they contain a state that is changed by sending events to them. Fortunately after the 1.0 we realized that this would be far to academic sounding and decided to rename. One of the name candidates was grain to follow the spirit of mill and millstone as well as Java beans :)

Cookies bad!

[shaper]

The on-line demo / example pages do not appear to work without cookies. Sorry, thank you for playing! One of the cardinal rules of a good general purpose web app framework is that it should not require cookies to work. It may be that the framework itself does not require cookies. If so, it was a poor decision to write demos that do. Oh well. Next player, please!

Re:Cookies bad!

[Randolpho]

You know... cookies are not all that bad, once you get to know them. ;)

Seriously though, the framework, although apparently developed like swing, still outputs HTML and Applets to a browser. Cookies are a valid method of transferring state from one page to the next, although admittedly server-side session tracking is usually a better alternative.

Re:Cookies bad!

[Anonymous Coward]

If you check out the architecture overview, you'll realize that this is due to the theme and/or terminal-adapter (not sure which) in use -- in this case the 'web-adapter' and some default theme. It does not have to require cookies.

The idea is that you can use different adapters for different terminals (html, midp, wap, ...)

I think the state IS maintained serverside, but the cookies are used to identify the session (but I might be wrong)

Re:Cookies bad!

[platypus]

Cookies are a valid method of transferring state from one page to the next, although admittedly server-side session tracking is usually a better alternative.

Uhm, and how does the server know which session he stores belongs to which request?

Yes, right, either cookies hold this information, or the URI, via mangling the displayed links.
If you use session cookies, the two are equivalent privacy wise, it's just that cookies are is far more robust than link rewriting, because the latter can break in a plenty of ways.

Re:Cookies bad!

[Randolpho]

Hey, you're preaching to the choir man! I have no problems with cookies whatsoever. I love 'em. 'Specially with milk. Server-side session tracking *is* the better alternative to cookies, however, if only because of the limit on cookie data. If you have a complex list of user-definable options in your website (as is increasingly the case of late) or a potentially large amount of data you need to transfer from page to page (say a shopping cart), then this can be a problem.

Re:Cookies bad!

[Anonymous Coward]

Applets ?? I did not see any applets in the demos.

Re:Cookies bad!

[jole]

Base Library does not depend on cookies, but the Web Adapter uses cookies for session support. Adding support for URL re-encoding to avoid cookies might be added in future.

Re:Cookies bad!

[Anonymous Coward]

All of the state in any Millstone application is kept on server. Only thing requiring a cookie is the standard JSessionId that is automaticly managed by the servlet container. To make this clear - absolutely no data (except for the sessionid) is kept client-side. This combined to the basic secure nature of Java programming environment makes creation of secure applications easy with J2EE (and thus with Millstone).

Re:Cookies bad!

[Randolpho]

Neither did I, but that doesn't mean it's not possible.

Intentional?

[Lally Singh]

Explain why you'd intentionally make something swing-like. You don't program swing, you fight swing. You fight it with your teeth and nails. Then it decides to resize your button, and you just give up.

Re:Intentional?

[Miqlo]

Aaah, but we only took the good bits :)

None of that pesky relational sizings and layouts to size contained components that *never* works like you expect or even, intend.

Miq

Re:Intentional?

[jole]

Fully agreed.

Millstone is not designed to be Swing-like. Millstone API has been designed from ground up to easier to learn and use than Swing. Using Swing API directly was one of the options (easy one), but we decided not to follow it and to create API better suited for multiterminal environment and easier to use instead.

my personal rant on web forms

[Tablizer]

If anybody is interested, here is my take on the current state of web development and how to make it more client/server-like (Delphi/VB/PB) from a developer's perspective.


http://geocities.com/tablizer/webstif.htm

Re:my personal rant on web forms

[Anonymous Coward]

Interesting article.

You should _really_ take a close look at how Millstone works, you might be positively surprised!
(for instance: the application keeps it's state for the duration of your session, the html-forms retain their state etc...)

Re:my personal rant on web forms

[Tablizer]

You should _really_ take a close look at how Millstone works

Perhaps. But I don't like Java as a language. Will they port it to other languages? Besides, the framework I talk about is not that hard to build yourself. It just might take a few generations of interface experiments to fine-tune.

Clever but possibly misguided

[vbweenie]

If a calculator app which has to make round trips to the server every time you press a button is meant to be a representative demo of this application, then my response has to be: no thanks.

I tried a couple of other demos on the site, like the treeview control which seemed to need to go off to the server every time you expanded a node. Responsiveness is a key issue in usability: anything slower than PDQ (Pretty Damn Quick) ramps up the end-user's frustration levels and makes the interface feel clunky and hostile rather than intuitive and friendly. All of the stuff on their site looked great, but it handled like a pig in treacle.

Maybe they're suffering a slashdotting right now, but that actually doesn't excuse them: if the responsivity of individual elements of your user interface depends on the responsivity of your servers, then the usability of your site is - to my mind - unacceptably fragile.

Is it possible that the developers used this primarily on a small LAN or even spent their time pointing a browser at localhost, and never considered how it would feel to be using it over the web? Surely they must have load-tested it? Surely they must have thought, "hmmm, so that's why client-side scripting was invented"?

Re:Clever but possibly misguided

[Anonymous Coward]

Yes, indeed: some of the examples are a bit dumb -- like the calculator. It's more of a programming example than a framework example, though ('hello world' is not that useful either, yet every language/framework has one).

The reloading of the tree is actually dependant on the theme in use - you could fairly easily implement a theme that does not require a submit if a subtree already has been loaded.

The poor old computer that the examples run on got a little 'slashdotted' when this made the news in Finland, and that was probably less traffic, so I'd expect some lag...

Also note that the performance of different XSLT processors vary greatly -- apparently Saxon is almost 3 times faster than Xalan, which is default in Millstone 3.0.0-

Re:Clever but possibly misguided

[Miqlo]

Misguided not. It would have been possible to create an entirely client-side calculator-app that would be fast as lightning, yet this is not what Millstone is for. I'll conceed that the Calc-app is perhaps a bad example-app as it brings forth sentiments like this. It is only intended to demonstrate and tutor the usage of Millstone, and not, in this case, it's power.

One important aspect of Millstone is that the presentation of an app is separated from the underlying logic. This means that once adapters have been made for different terminals, that same Calculator app, without so much as one line of code changed, will work on your cell-phone, digi-tv and terminals that aren't even imagined yet.

As to the responsiveness of the example application, I'd like to point out that it's running on a single server sitting in the room next to me, in Finland ... so you're bound to get some netlag if your surfing in from the states. Regarding the /. :ing as an excuse, it is if we never really believed that we'd get on here. :)

Realistically, we're too small to make mega $ hardware investments in preparation for high demand, we just have to wait for that demand to realize itself and then respond to it.

Further discussion regarding the speed and efficiency of the ui transformation process can be found in the serverside.com thread.

Regards,
Peter Bäck

Re:Clever but possibly misguided

[vbweenie]

I still have my doubts about the whole approach, but this is to some extent an ideological issue (HTTP/HTML for complex real-time client-server interaction just feels wrong to me) so basta for now.

The promise of multi-channelling GUI components is an alluring one, and Millstone is certainly impressive in its use of HTML/CSS/Javascript as a rendering target. Presumably having abstracted to that level you could retarget the renderer at an SVG or XSL:FO browser?

Re:Clever but possibly misguided

[Miqlo]

vbwwneie wrote: The promise of multi-channelling GUI components is an alluring one, and Millstone is certainly impressive in its use of HTML/CSS/Javascript as a rendering target. Presumably having abstracted to that level you could retarget the renderer at an SVG or XSL:FO browser?

Certainly! To clarify, a Millstone renderer is what we call a Terminal Adapters; an adapters recieves from the appliation an XML representation (that we call UIDL, User Interface Description Language) of the state of each component and translates this XML into whatever the terminal can understand and maintains a map of terminal varibles (content of text-fields, state of checkboxes, etc). In the asynchronous Web-Adapter case, the adapter waits for the terminal to send back the updated set of variables that are then passed back to the application for handling.

However, the terminal may also be synchronous, in that case there will be a continuous stream of variables from the terminal->adapter->application and a continuous stream of UIDL from application->adapter->terminal.

Some of the envisioned terminals are Flash (ofcourse), MIDP (almost implemented), Digi-TV, and my personal pet-project of creating a Win32 native adapter per use of the Eclipse widgets.

As it happends, HTTP/HTML is actually one the hardest terminals to implement because of the inherent statelessness of HTTP (and the erratic behaviour of HTML browers.. :p ). Many other adapters are (in theory) much easier to implement.

Hope that cleared some things up.

Greets,
Peter

Themes

[Anonymous Coward]

Nice to notice that this project has also been investing a lot of the work in appearance and themes/skinnability.

Re:Themes

[Anonymous Coward]

The default theme can be tested with feature browser and screenshots of some other themes are available here.

Swinging strike!

[hayriye]

end of the inning and the game...

Other people agree with you

[RhetoricalQuestion]

I still have my doubts about the whole approach, but this is to some extent an ideological issue (HTTP/HTML for complex real-time client-server interaction just feels wrong to me) so basta for now.

You're not the only one who has doubts about this approach.

Because everything old is new again, many companies are starting to build hybrid J2EE systems which have a Swing GUI as a front-end instead of a broswers. The advantage is (over traditional client-server) that you can have the scalability and transaction-safe benefits of J2EE on the server, but the fast responsiveness and better UI of a GUI on the client. (As well, you can still create purely serverside applications where it's appropriate and reuse the same infrastructure.) It's far fewer roundtrips, since the client only needs to pull or commit data from the server, but can perform all the interim data manipulation and UI work client-side.

To extend your calculator example, imagine a mortgage calculator in a bank branch. The calculator would only need to talk to the server when the bank employee pulls up your customer data, or commits any changes. However, before making changes, you as the customer might want to see how much faster you could pay off the mortgage if you increased your payments, or put in a bigger down payment, or tried a different interest rate plan, etc. All of that should be calculated client-side -- there's very little need to make several server roundtrips for these temporary calculations.

As well, the bank could use that same back-end infrastructure to set up a website to allow you as the customer to check the status of your mortgage and your payments. Customers wouldn't be the same kind of power-user that the bank employee would be, so the number of roundtrips is somewhat less of a problem -- as well, the web version could be a simplified version of the GUI version.

Sun has actually addressed this (they sometimes call this architecture rich-client J2EE) through the JNLP spec and its reference implementatation, Java Web Start. Personally, I think JWS itself has limited use, but the architecture of the rich-client system is nonetheless pretty sound.

DISCLAIMER: I haven't looked at Millstone. I have spent a lot of time with these hybrid, rich-client J2EE systems, though.

Funny... Java libraries... Millstone coffee

[ruiner13]

When I see "Millstone" I think coffee. I wonder if they did that on purpose (Java... beans... etc)... the Java PR people love the coffee terms, and it is only fitting that something that extends Java should use a coffee related term. I'm gonna make a java-based game engine called Starbuck. :)

Features online demo

[jole]

There is an extensive features demonstration online, where the UI components can be tested and configured on fly. This is the fastest way to get a good overview of Millstone capabilities.

Usability of HTML UI

[jole]

All the critique of HTTP/HTML UI is probably correct. HTML is not designed for UI and any continuous event based widget set probably can be used to create better and more responsive UI than possible with transactional HTML/HTTP model.

Millstone is not anyhow limited to HTTP/HTML - the support for continuous events based terminals is being added in the future. Still the reality in many applications, where the number of users is large, is that installing anything (including JVM) to client side is unacceptable. Millstone resolves this problem by providing extensive and easy to program UI library that can offer the best of the both world.

J2ME (MIDP), J2PE and WAP support

[jole]

In fact we created adapter prototypes for WAP, J2PE and J2ME (MIDP) on HP Bazaar Spring Camp (Helsinki, 2002). We tested the adapters with Nokia 6310i prototype and Nokia 9210 as well as Prototype HP Jordana PDA with HP JVM and MIDP environment (Thanks for HP and Nokia for their help!).

The MP3 jukebox example application as well as simple examples like calc were tested. Calc worked out of the box as expected (no recompilation was required), but player UI was just too big for phone screen. Simple solution was to add new window to player and put the control panel to it (the frame with all the buttons). This added just 2 or 3 lines of code to the application. The result was a server-side jukebok that could be controlled with WEB interface as well as mobile phones. J2ME adapter used a little midlet that interpreted UIDL directly and used native Nokia widgets. J2PE was similar, but used AWT.

XSLT performance

[jole]

Version 3.0.1 released yesterday fully supports Saxon 6 and Saxon 7. The XSLT can be selected with normal system preferences (explained in install.txt)