Dalvik, running java efficiently

The story of virtual machines is beginning to be quite long ; Smalltalk, Lisp, Java, dotNet, ... The idea behind these were to be able to write once and deploy everywhere. In the case of Smalltalk, it was even a step further by including the concept of "image" which is actually a kind of object oriented database.
The drawback of these approaches is mainly the lack of performance, even if many, many improvements has been made to ensure execution celerity (hotspot for instance)... But the constatation is in front of our eyes : eclipse is still a big processor and memory consummer, microsoft doesn't still write its main applications in dotNet, and so on...
One of the avantage of using VM is that the developper can develop quicker and safer (no more memory leaks for instance). We could easily continue to develop this way but by adding a compilation step we could ensure efficiency. It is what Excelsior proposes, but also IS2T with their Icetea technology.
Google followed the same way by providing the Dalvik technology, ie a VM running .dex files directly got from java .class files. This new format is shorter, quicker, more memory efficient but has not just-in-time compiler. This VM enables Google to run java programs on Android efficiently, and also not to pay fees to Sun ;)

HTTPS with Restlets

A new chapter of the Restlets tutorial is just coming to world : how to use HTTPS with Restlets.
Interesting and useful.

JSecurity 0.9 out

JSecurity is a java library developped in order to simplify authentication, authorization and cryptography when a client communicates with a server. It seems quite easy to use, even if it lacks a lot of samples. Someone on the restlet mailing list has emitted the idea to adapt Jsecurity with restlets. I'm waiting for discussions on this subject to have a better understanding on the techno. But it seems promising nevertheless.

Eclipse E4 incubator

Eclipse Ganymede is delivered and widely used.... But what is the future of Eclipse? With Ganymede we reached a point where adding functionnalities would not be enough to confront the future. This future which is already the present is a mix of old and new technologies, ie desktop applications, RCP applications, Light client applications, RIA applications, and so on...
We need from now an unified model enabling with a single paradigm to reach all the goals behind all these technologies. I think that Eclipse could try to achieve this target because of all the underlying technologies used into Eclipse like OSGI, good programming model, the community, ...
It is maybe also the goal that Eclipse 4, E4 for short, will have to take into account.
For this purpose, an incubator project has been initiated, whose the roadmap is the following.

PureMVC Pipes

We've spoken previously about PureMVC, and especially its declination into GWT.
It exists an extension to PureMVC which is Called PureMVC Pipes...but it lacks some examples and tutorial about this. You can find here a good tutorial explaining what the purpose is.
Nevertheles, PureMVC may already be "complex" to use ; pipes don't simplify it :)

RAP (Rich Ajax Plaform) 1.2M2

RAP is a web development plaform based uppon Eclipse and enabling development in a RCP (Rich Client Platform) manner, SWT being "only" replaced by RWT for Rich Widget Toolkit.
The concepts are really interesting and the architecture clever, based uppon server-side OSGI.
I'm not confident by now on the performances of applications developped with RAP, especially on loading and stress tests. But the basis seems good, and could obviously be improved in the future. Personally I would like to see GWT used instead of/in conjunction with qooxdoo, the js library used to implement RWT on the client side.
Concerning Qooxdoo, it seems that a quite similar project to GWT is available for the framework : QWT for Qooxdoo widget toolkit.

Restlets 1.1.0 is out

Good news ; the 1.1.0 version of the restlets framework is ready to download.
Here a panel of the new features :"

• Broader and deeper HTTP support with features such as partial downloads, resumable uploads or content integrity validation.

• Best support for the WADL specification in the industry, allowing an automatic and always in sync documentation of your REST APIs. WADL documents can be generated in XML or converted on the fly to HTML using the popular stylesheet from Yahoo!
• One of the first and most complete implementations of the new JAX-RS 1.0 specification provided for those preferring an annotation-oriented approach.
• New Restlet-GWT module provided, porting the client-side of the Restlet API to the popular Google Web Toolkit 1.5 JavaScript platform, allowing you to invoke RESTful applications right from your Web browser.
• New extensions for easier integration with the JAXB 2.1, JiBX 1.1, Spring 2.5, OAuth, OSGi, Oracle XDB and SSL technologies.
• Improved support for Atom Syndication XML format and for Atom Publishing Protocol. Both formatting and parsing are now available.
• New POP3 connector based on JavaMail to access RESTfully to remote mail boxes.
• New Grizzly HTTP server connector, first to fully leverage the NIO support in the Restlet API, leading to new levels of scalability and performance.
• New internal HTTP client and server connectors to simplify development phases (zero configuration"

A screencast is available for discovering the framework.

Smalltalk is going back

I've been fond of Smalltalk since 20 years but have not the occasion any more to develop with this great language/ide :-(
It seems that people after having tried java, c#, ruby, python, groovy, grails, ruby on rails,..., to solve their development problems reached conclusions that everything or almost was already thought, designed 30 years ago with Smalltalk.
Smalltalk is again in the front of door with Seaside, ther continuation framework firstly built in Squeak.
An IBM internal project still focus on Smalltalk for adapting Smalltalk to the eclipse platform through the STDT project.
I hope that Smalltalk will be back on the market, because it still the best architectured language ever.

For information, below can be found a list of Smalltalk providers :

• Cincom Smalltalk
• VisualAgeSmalltalk
• DolphinSmalltalk
• Smalltalk/X
• (old) Smalltalk MT
• and of course Squeak

"Sun gives Java a REST"

This is the title of an article on SDTimes I enjoin you to read.
We've spoken about Restlets in previous posts ; you also can take a look to the jersey project about REST implementation of the java JSR.
You can also have a glance to this comparison of REST implementations here.

GWT/Google Gears/Restlets

This post is actually a question to the readers of this blog.
I would like to know if you already have tried to use GWT with Google Gears, and more especially if you've tried to used GWT-restlets with Google Gears...
While REST ressources can be cached and stored, I imagine that Google Gears could easily manage these ressources, and then GWT could benefit a lot of this feature to easily develop web application which could run locallyand/or remotely.
Have you experienced this?
regards

material :

• gwt
• gwt-restlets
• google-gears
• gwt google api

MiniG : power of GWT, Osgi and Rest

We talked about a global architecture few posts ago. In this architecture, we pointed out GWT, OSGI, REST, PureMVC, DB4O as basis elements.
I've just read this morning the emergence of a new open source project : miniG, a GMail-like email application.
What is interesting in this project is the technical choices which has been made, ie GWT, OSGI and REST.
I enjoin you to take a glance to this project.

DataNucleus

On a former post, I've had some comments (it's rare :-) ), and especially some from Andy who talked about DataNucleus above DB4O, but also more generally above quite every persistent layer while providing a standardized JPA API for accessing data. I've not yet tried this technology, and I've then no advice about it.
Here can you find what Andy said about DataNucleus :"
What are the benefits of a standardised API ?
So you can in principle swap your persistence process to an alternative implementation. Developers don't need to learn a proprietary API.

What are the benefits of using DataNucleus in this respect?
You can use db4o for persistence, but then also persist data to LDAP, or RDBMS, or XML, or Excel, or ... with a simple change of a URL (no changes to your data model, or persistence code). Also since DataNucleus jars are already OSGi enabled you can just drop them in your container rather than having to add special treatment.

1) more developers who already know standardised APIs (JDO/JPA) and 2) you have other benefits by choosing that route. Please define where the disadvantage is ?

Assuming your developer doesn't know any persistence API, what is the learning curve for the db4o API? about the same as JDO/JPA IMHO, however they'll find more docs for JDO/JPA since there are more implementations. You don't code to DataNucleus proprietary APIs.

Speed ? very little difference to db4o native speed. No need to use db4o transparent persistence/activation since its done for you by DataNucleus. You can have application identity capabilities (define primary key fields in your class) using JDO/JPA and DataNucleus whereas with db4o's API this is impossible.

The DataNucleus site has adequate documentation of the available APIs should you be interested."

I would like to hear experience return from users... Don't hesitate to write comments :-)

Restlet 1.1RC2 out

Release 1.1 RC2 is out, with all known bugs in Restlet closed (more than 20 fixed!). Please help us test this build while be work on the documentation tasks for the final 1.1 release.

Here is a summary of the main changes:

• Added support for HTTP authentication in Restlet-GWT module and fixed compilation issues.
• Fixed socket closing issues with internal HTTP server connector.
• Fully stabilized the Grizzly HTTP server connector.
• Fixed regression with SpringHost due to context refactoring.
• Fixed class-loading regressions.
• WADL extension now properly supports nested resources.
• Updated db4o to version 7.4.58.
• Updated FreeMarker to version 2.3.14.
• Updated JAX-RS API to version 0.11.
• Updated GWT to version 1.5.2 (final).

PureMVC web framework

When developping a web application, we all know that we have several parts to focus on ; presentation flow management, business rules development, data persistence, and so on... It is generally called N-Tiers architecture, N being function of the complexity of the application.
J5EE for instance aims to cover all the scope of web application concerns.
For the ones who don't want a all in one framework, or who develop with other languages than Java, it exists many "little" frameworks which focus on a particular part of the web application development problematics. It is the case especially of Struts, or Wickets, or Spring, etc...
This is in this context that the PureMVC framework occurs ; its scope is only to manage the presentation logics, ie how the developper has to design his application to manage views, actions, controls, ..., in the web pages. It is clearly a replacement of Struts and it is based uppon clear explained design patterns of the Gang of 4 : proxy, médiator, command, facade, observer ; five design patterns for building simple and well structured web applications from the presentation point of view.
The "plus" of the techno is that it has been derived for many languages : Php, Ruby, Java, Flex, ... We may even consider now developping an entire application in different languages (for instance Php and Java) with the same underluing concepts... It could be the case in a SOA approach, eg a web portal (public access) in Php which would focus on referencing, and in java/gwt for the business part of the application (private access).
Another interesting view is that it is ,by construction (it is only based uppon the use of design patterns, not libraries), compatible with other frameworks like Spring or Restlets...
For the best, I would like to make notice that PureMVC has been derived for GWT, ie indirectly for Javascript :-).
So let imagine the following global architecture :)

• GWT for the graphical part
• PureMVC4GWT for controls and UI logics
• Restlets for ressource access on the server(s)
• OSGI for managing component efficiently
  
• DB4O for storing data in database

Is it not a nice proposal? ;-)

Some articles and material about REST architecture

REST explained in few words.
Just a little post to make reference to three articles from Stefan Tilkov. Interesting!

1. a brief introduction to REST
2. REST anti-patterns
3. Addressing Doubts about REST

I recall also in mind that a great and simple REST framework in java exists : Restlets!!! It may even work with GWT too ; see the GWT-Restlet Module. You also can use Restlets with Groovy.

For the ones who want to use REST with Php, the following articles are also nice :

1. Php REST Server part 1
2. Php REST server part 2
3. Php REST server part 3