2006-12-29

Transactional Memory - A Contender for The Solution

This unproven technique is apparently implemented in the announced Azul Systems product (supported by IBM and BAE, and sued by Sun). TM may be a valid solution for many situations for multithreaded apps. Here's a biblio:

http://www.cs.wisc.edu/trans-memory/biblio/index.html

TODO evaluate technology - there are a few recent opinions in the java concurrent mailing list.

Update 2007.01.21: ACM article by Intel and Stanford U. - TODO read carefully

2006-12-28

Desktop Java EE Apps Anyone?

Here's an extract from a post by Bill Shannon, Java EE Spec Lead, on Java EE App Clients. I am evaluating the use of Java EE technology on the desktop to reduce the costs of delivering defect free multithreaded apps. The idea is to try to mostly let the Java EE container manage the threads and no server would be used. It's a complete Java EE on the desktop, standalone (no server). The Java EE container(s), server-side and client-side, would be running on the desktop. In the current Java EE design, the Java EE server-side container still runs on a separate host, but not in my experimental design. One could always have the application start the Java EE server-side container if it needs to when it starts (when the app starts that is).

The main difficulties may be in deployment, e.g., very large jars, the automation of the installation the Java EE container (on the desktop), etc., but these may still be simpler than producing defect free multithreaded apps without Java EE.

It looks like *app clients* are applications running in a Java EE client-side container. The other alternative, of course, is to use a browser for the user interface objects via http to the Java EE code (on the desktop), instead of the Java SE GUI offered by an app client.

Finally, here's the post that I promised:

Re: Java EE appclients vs standalone clients
Posted: Nov 27, 2006 1:40 PM

Apparently there's some confusion over application clients. To quote from the Java EE platform spec:

....Application clients are Java programming language
....programs that are typically GUI programs that execute
....on a desktop computer. Application clients offer a
....user experience similar to that of native applications,
....and have access to all of the facilities of the Java EE
....middle tier.

Application clients are not expected to execute on the server, although some people have found that useful in some situations.

Application clients are simply standalone Java applications that execute in an environment that conveniently provides access to the Java EE facilities. It's the application client container that provides Java EE support to the application client program.

Some people want to run "regular" Java SE applications, but have access to Java EE facilities without need for the application client container. Yes, you can do this. There's no magic here. But there is a lot of work. You can duplicate most or all of the work that the application client container is doing for you, and thus run your "standalone" Java EE client application without using the application client container.

...

What we've done in GlassFish, and what we're considering adding to the specification, is add support for Java Web Start for deploying application clients. This allows the client desktop machine to download the application client program on demand.

Some people want to use their own deployment approaches, automated or manual, for deploying their desktop applications. What they'd like is to have a simple, small jar file or other bundle that is their application client, and run that application just like they would run any other Java SE application. This is the case that drives people to "standalone applications" instead of application clients.

What we should do is create a simpler "application client runtime", as similar as possible to the simple "java" command, that could be used to run these applications.

The final deficiency, and one of the harder problems to solve, is that the application client container depends on the application server fairly heavily, e.g., for configuring access to resources. If the server is unavailable (due to network problems or whatever), the application client has no reasonable way to function in any sort of degraded mode until the server is available again. Improving this definitely requires work in the GlassFish implementation, and may also require changes to the Java EE specification.

Bill Shannon
Java EE Spec Lead

Labels: , , , , ,

2006-12-24

security: extended-validation certificate (EV) and alerts

http://news.yahoo.com/s/ap/20061224/ap_on_hi_te/internet_padlocks

because security is another critical issue, specially for online businesses.

update: www.certstation.com - an aggregate of 8 alert services

2006-12-22

Two big steps for a thread-safe object-based app

1) Build well-designed thread-safe objects (classes) for the app.

2) Make sure that the objects interact in a thread-safe way in the application.

This was re-stated by Brian Goetz at Javapolis 2006. Brian proposed that the use of an object-oriented language, good object design, and this two-step process, do help minimize the costs of developing a thread-safe application these days.

It's just that both step 1 and 2 are relatively very expensive and often improperly done, which results in defects. The resulting total costs are comparable to and may surpass the costs of using Java EE correctly. It may be that in 2007 and 2008, the least expensive way to develop thread-safe applications is the use of Java EE version 5, possibly even for desktop apps.

TODO look into ways to use Java EE 5 on the desktop, with and without an http-based user interface (e.g., with Swing).

New Java Tool to Test Synchronization Issues: ConTest

ConcurrentTesting - Advanced Testing for Multi-Threaded Applications

from IBM Alphaworks: http://www.alphaworks.ibm.com/tech/contest

TODO: try and review

2006-12-17

Thread-Safety According to Intel

2006-12-09

Is FORTRESS an Improvement over Java?

Guy Steele describes his FORTRESS programming language as an improvement over FORTRAN and seems to imply that is equivalent to Java, but is it?

Steele has been quoted as saying "FORTRESS is to FORTRAN what Java is to C/C++". But if FORTRESS is as generic as it also has been described and if it is as good at easing the pains of developing concurrent applications as some claim (Hal Stern and James Gosling for example), then it may be worth considering as a replacement for Java also, and not just for FORTRAN?

Sun's CoolThread, Niagara, and the Rock

New Azul Multicore Systems for Java

Note that Sun is suing Azul for patent infrigments.
http://www.theinquirer.net/default.aspx?article=31461

TODO more here on the new Azul systems