2005/06/12

The BeJUG wiki is now running on the latest version of Confluence.
You can get an overview of the wiki features here.

enjoy,

Stephan

Posted at 12 Jun @ 4:59 PM by Stephan Janssen | 1 comment
  2005/06/26
Last changed: Jun 29, 2005 16:41 by Stephan Janssen

So after our 16 hour flight, together with Robin Mulkers and Gergard Maas, we're back in San Francisco to celibrate the 10th birthday of the Java Language, platform, and way of life!

It was a nice surprise to see that Sun finally has chosen to use Java smartcards for their conference badges, a "primiere" I was thinking of introducing this year at JavaPolis aswell, this means we'll have to come with something more interesting... just joking or am I ?! The JavaOne smarcard needs to be entered in the SunRay if you want to browse, I wonder if they log my browsing activities ?!

This morning during our breakfast at the Handlery hotel we were joined by Rod Johnson who's staying, together with Juergen Hoeller, in the same hotel. These are the nice side-effects of being transparent about your JavaOne travel and living plans. Rod told us about a nice Spring Framework announcement during the JavaOne Conference. However he asked me to wait with a blog post one minute after the announcement, so keep your eyes open on the BeJUG news page. I can give you a hint: if you open the JavaOne conference bag and read the BEA insert it says "BEA is embracing the merging application frameworks and tooling with eclipse-based tooling in BEA WLS 9.0, Aspect Oriented Programming and integration with Struts, Beehive and..... the Spring Framework". This means being a BEA European Technical Director makes (again) sense !! Dieter, the BeJUG portal is again compliant with the BEA strategy I really hope other Java vendors will follow this same route towards simplified J2EE development, I know JCS does

It's also interesting to see that IBM has been added as a last-minute sponsor in the conference eratta. Some new companies on the list are JustSystem (Gold CoSponsor), Axalto, FairIsaac (anybody knows what these companies do ?).

It's probably more expensive than JavaPolis sponsoring because JavaOne this year only has 12 companies on to sponsor list, excluding JBoss and MicroSoft (which is a surprise to me).

So this afternoon we'll do some shopping, watch the San Francisco gay parade (maybe see some 'famous' Java people?), take the cablecar to the bay area and this evening propably go to the Stars Wars movie... let JavaOne begin !!

-Stephan

Posted at 26 Jun @ 1:12 PM by Stephan Janssen | 2 comments
  2005/06/27
Last changed: Jun 29, 2005 16:37 by Stephan Janssen

JSR 277, Java Module System has been submitted this month by Sun. The target is to solve Jar deployment problems. I think that this initiative was needed since a long time. Relationships and dependencies between Jars cannot be enforced and consequently managed properly at deployment time.

But it seems that this JSR is only a part of the solution to this problem.

Let?s take an example. I have a component x.jar that requires log4j-1.2.8 and another component y.jar that requires another version of log4j. What happens if my application uses both x.jar and y.jar ?

Today, it is already possible to define jar dependencies in the jar file manifest. But as soon as we have 2 different log4j implementations with identical names and packages for some interfaces or classes, the class loader will load only one of the 2 implementations according to which jar comes first in the class loading process.

In J2EE, it?s the same behavior, we might have less problems between war files because those web apps get their own private classloader but we still have the problem for EJBs that all share the same classloader.

One of the possibilities is to use different class or package names in each version of the jar files we use (log4j jar files in our example). By doing so, we can perfectly have at the same time different implementations loaded. But who?s doing that? Nobody! Developers hate version numbers in package names and class names for the simple reason that they want to minimize the effort of upgrading to a new version.

The result is that we are now obliged to choose for one single version of log4j and try to have both components happy with it. Could become a painful experience when the number of jars in an application grows.
So having dependencies managed between Jar files is a good thing but the goal should be to let the classloading mechanism follow the move.

I would like to have x.jar and y.jar using each their own version of log4j in their own private virtual machine memory space. This behavior should not be the default behavior but could be configurable before or after the jar creation time.

Relaxing the classloading principles, taking into consideration the where the invocation of a jar file is coming from looks to me as the most challenging part. This change should target J2SE and J2EE from day 1.

Is that the scope of this JSR 277?

I will meet Stanley Ho, who is the spec leader of this JSR today. I will keep you updated.

Posted at 27 Jun @ 11:02 AM by Robin Mulkers | 3 comments
Last changed: Jun 27, 2005 20:19 by Stephan Janssen

Straight from the BEA JavaOne keynote

(view as slideshow)
       
  Mark Carges   Mark Carges and Spring   BEA and Spring
 

BEA will certify and support the open-source frameworks such as Struts and the Spring Framework.

BEA has signed a partnership with Interface21, the company behind the Spring Framework.
This means that developers will receive support via helpdesks and probably SLA's will also
cover these open-source frameworks. The integration with these open-source frameworks will
be available in the next release of the BEA WebLogic Server.

BEA will also support other production deployment environments such as Tomcat and Geronimo
from within the Eclipse BEA plug-in environment. (I'm again happy to be a BEA Technical Director)

Wauw I never would have thought the above open source "products" would be linked to each
other in the same blog post. So is there an Oracle and IBM keynote at JavaOne where Rod will also speak ??!

The only main API which is missing in the BEA portofolio is support for Enterprise Java Beans version 3.
I was hoping to get an announcement that BEA would have acquired an EJB 3.0 company like Solarmetric...
maybe at JavaPolis this year

This means that BEA developers will now have access to new techniques like Aspect Oriented Programming,
Inversion Of Control and wiring of Beans resulting in a very loosely coupled environment.

Good stuff !!!

-Stephan
PS: Thanks to Gerard Maas for the great foto's.

Posted at 27 Jun @ 4:54 PM by Stephan Janssen | 2 comments
Last changed: Jun 29, 2005 16:32 by Stephan Janssen

Free JavaOne Content ??!

Any Sun Developer Network member, which is a free membership, will receive FREE access around
late August 2005 to all of the multimedia sessions from this years JavaOne conference !! PDFs of the
conference content will be made freely available without registration to all web site visitors.

From a spread-the-Java-word perspective this is great news, but I wonder which effect this strategy will
have on the number of attendees during next years JavaOne !? I mean, why would people continue to pay 1.500$
if they can get the content 6 or 8 weeks later... interesting strategy

Stephan

Posted at 27 Jun @ 5:42 PM by Stephan Janssen | 1 comment
Last changed: Jun 29, 2005 16:33 by Stephan Janssen

We had today numerous presentations illustrating the use of annotations in Java Enterprise Edition 5.
The intention is to simplify creation of web applications, to substitute XML files and often code generation by few additional lines of code.

Cool, simplification is definitely needed in Java EE.

I was attending the JAX-WS 2.0 presentation and Roberto Chinicci has showed how to use annotations to configure the security (authentication, integrity and sensitivity) of a web services developed in a Java EE 5 container.

I think we might have been too far here. Should it be the responsibility of a developer to set-up the security of the services implemented in its application ? Moreover, security requirements are not the same in development or production environments. How are we supposed to tackle that issue with annotations?

Annotations is a new way of working, we have no experience, best practices yet. Are we doing the same ?XML deployment descriptors? mistake again but the other way around?

Robin.

Posted at 27 Jun @ 7:13 PM by Robin Mulkers | 2 comments
Last changed: Jun 29, 2005 16:35 by Stephan Janssen

I was really waiting for SOA related content from this 10th edition of JavaOne.
Vendors do have all SOA on their lips for the moment, and I believe there was a lot to be said about Service Oriented Architectures.

The few presentations I have already seen were disappointing at best. I am now getting a very introductory session about SOA, showing that there is still a long way to go in the perception of what a SOA really is.

I was expecting more from a worldwide conference like JavaOne.

The best conversation I had so far about SOA was at the booth, with Microsoft. I am not really a fan of Microsoft tools and technologies that are not really as open as I think they should be.
I must admit that the vision of Microsoft around SOA seems much clearer to me than the vision I get here at JavaOne.

Microsoft is preparing a thing called ?Indigo?. Indigo is a service container. It is only dedicated to hosting services, no BPM in it, no user interfaces and it will be available for free, of course ?free? means that you still have to purchase the Windows operating system.

I am convinced that the Java Community should bring a standard alternative to Indigo. We have right now all the technologies available to make an Indigo killer platform in the Java world. The problem is that Java EE 5 looks like an overkill infrastructure compared to the Microsoft lightweight service container.

On the Java Standard Edition front, nothing will arrive until version 6, due mid-2006. In this release of the Java SE, there will be an implementation of JAX-WS 2.0 and several other Web services related APIs but the lightweight HTTP listener that will be embedded in it will not be robust enough to create a serious alternative for an enterprise class service container.

I am wondering how far Indigo will be a treat to Java on the front of Service Oriented Architectures and I do not think that I will come back home with an answer this time.

Posted at 27 Jun @ 8:35 PM by Robin Mulkers | 0 comments
  2005/06/28
Last changed: Jun 29, 2005 16:51 by Stephan Janssen

My intention is to give a daily overview of the highlights and some thoughts of the sessions I followed at JavaOne. This morning was the official opening of the event. I has expected some queuing lines in front of the Moscone Convention Center, but everything went fine. No queuing, good coffee and comfortable seating.

Every day starts with some general sessions, prior to the parallel individual sessions.
As like the previous years, John Gage is the acting master of ceremony for the general sessions. The morning sessions where ?easy listening? sessions in general injected from time to time with a well intended joke.

After a couple of hours listening, I was convinced that this JavaOne is THE conference of the year dealing with ?lightweight? and ?SOA?. As long as you don?t mix them together, you don?t miss the point.

Also not to forget, Duke is celebrating its 10 anniversary this year! Yes yes yes? Hip hip hoera for Java! The language celebrates its 10 anniversary. The ?green team? has been brought on stage. Nice to see the innovators of what created a multi billion dollar/euro industry.

Still sitting in my chair, I was thinking what I was saying roughly 11 years ago? At that time, I was a hardcore assembler programmer, preferring to program directly the CPU registers instead of using a ?high-level? language like C. At that time other languages where even inexistent to me. One of my statements that put me into trouble with one of my previous employers was declaring Visual Basic as ?a program for graphical artists?. I?m still quite convinced about that. When I heard that there would be a new language that would not be native and that would have an additional layer (byte code) that would be interpreted, I said ?No way! This will be even slower than BASIC!!!?. Today, 11 years, 15kgs and less hair later, sitting in San Francisco, looking around to the huge crowd of Javaists, thinking to who pays my salary actually?. I firmly have to admit that I was totally wrong about Java, 11 years ago.

Some figures illustrate the immense popularity of Java. Consider them for a moment. I was quite impressed?..
4.5 m Java developers
1 b Java cards
2.5 b Java devices
708 m Java operated phones
600 m Java handsets for manufacturers

Another nice Java based thing to see was the Panasonic Blu Ray disc. The next generation storage solution on a DVD size optical disc. Storage capacity ranges from 50 ? 200 GB per disc! This makes it ideal for archiving purposes, but also for consumer usage in a HD DVD recorder/player. The latter was demoed at the Panasonic booth: A HD DVD player powered by Linux and Java.

The session was followed with some product updates from SUN Java Studio. Nice to see, nice to have, but not chocking. This is what we have already a couple of years in BEA WebLogic Workshop.

Another interesting utility was DTrace for Java on Solaris. This tool analyses during program execution what amount of time is spent in native, kernel or Java code. Based on the results, some tuning actions may take place to improve performance. I firmly believe this is a valuable tool, but it?s also worthy to notice that a lot of the Java code that is executed during program execution is not controlled by the developer. Application servers might also be written in Java, etc.

A lot of time has been spent on the updates of the J2SE and J2EE roadmaps. Serious effort has been done for both environments. The feature list contains some really cool topics!

J2SE, J2ME and J2EE Naming conventions have changed?

  • Drop the 2. So, SE, EE and ME
  • Single digit version: Java SE 6

The new naming conventions only apply to new versions. Existing versions remain.
J2SE 5.0 -> J2SE 5.0
J2EE 5.0 -> Jave EE 5

J2SE 5.0 ?Tiger?

  • Shipped last September
  • No 5.1 version
  • Mainly a language update (enrichment)
  • EoD (Ease of Developmen) focus: Introduction of annotations

Jave SE 6 ?Mustang?

  • EoD: Extensive use of annotations
  • Web Services client stack + lightweight server stack to serve callbacks
  • JML support
  • JMX upgrades
  • JConsole. This allows real-time JVM monitoring (see JRockit)
  • Scripting language framework support. ?Rhino? scripting engine is included.
  • Longhorn support, incl. Avalon look and feel.
  • JavaDoc update.
  • JDBC 4.0 support. XML data type and database support. Annotations model
  • Updated license model: easier + added new models
  • GUI upgrades: LCD font rendering support, Windows System tray support, Graphics pipeline boost (Open GL & DirectX)

Java SE 7 ?Dolphin? (tentative)

  • Direct XML support in the VM
  • ?friends? for cross package refs
  • Method references (event handlers)
  • New JVM byte code for better support of dynamic languages (eg. Jython)
  • Bean shell scripting language (JSR-274)
  • More new I/O APIs (JSR-203). Pluggable file systems, file permissions, free disk space
  • New packaging and deployment architecture: Circumvent limitations of JARs and/or EARs, metadata like versions part of the distribution

Java EE 5
Goals:

  • EoD improvements: POJO support; annotations used: to reduce the need of deployment descrptiors, external dependencies, Web Services, DB Mapping, EJB development; resource injection (inversion of control); new APIs and frameworks
  • Simplified Web Services support
  • Simplified EJB development
  • New persistence API (resolved EJB/JDO conflict)
  • Interceptors

Java EE 5 new content:

  • JSP STL (JSR-52)
  • STAX (JSR-173)
  • Web Services Metadata (JSR-181)
  • New persistence API (JSR-220)
  • JAXB (JSR-22)
  • JAX WS (JSR-224)
  • Common (language) annotations (JSR-250)
  • JSF (JSR-252)

Java EE 5 updated content:

  • EJB 3.0 (JSR-220)
  • JSP 2.1 (JSR-245)
  • Minor updates: Mail API, Servlets, ?

Beta: Q4 2005
Final: Q1 2006

SUN also announced to provide a free Java EE 5 compliant application server. This project is called ?Glashfish?.

SUNs Mark Harpner talked about SOA and Java Business Integration (JBI). One of the key building blocks for a SOA is the Enterprise Service Bus (ESB). The ESB are the tools and middleware to develop/manage/deploy and manage composite services. Most of the ESBs are built on a Java platform. Today, several vendors provide an ESB solution each having a different:

  • Tooling
  • Service packaging
  • Service deployment, packaging, management and monitoring
  • ESB extension mechanism
  • ESB monitoring and management.

These bullets are the actual paint points of today?s ESB solutions. Therefore, there is an emerging need for a ?SOA AND the Java platform? standard, which provides support for composite services:

  • Standard service assembly and service wiring
  • Extend ESB collaboration through standard normalized message routing and standard component pluggability.
    The benefits of the approach are modular services and ESBs
    JSR-208 defines a standard for Java Business Integration.

After lunch I went listening to (our) BEAs Mark Carges. Mark talked about two major topics: BEA support for lightweight frameworks and JVM innovations implemented and planned in our BEA JRockit VM.

Investigation proved that most of enterprise developers find that enterprise application development is too complex. In order to resolve that, over 70% use frameworks on the different tiers (web, business, data) of the enterprise application.

Today there is also an increased demand for:

  • POJO support: Allows the use of lightweight containers and a simple component model.
  • Dependency injection: Allows to resolve dependencies in a declarative way, to simplify the source code and to perform fast iterative unit testing
  • Metadata support: Allows to define infrastructure concerns in a declarative way and to code annotations
  • Aspect Oriented Programming support: Enabling technology and code simplification.

Today there are open source frameworks fulfilling above described needs. Hence, BEA provides as from WebLogic Server 9.0 support for Struts, Beehive and Spring.
WebLogic Workshop will be based on Eclipse and will support additional deployment models to support, in addition to WebLogic Server 9.0, Geronimo and Tomcat.

BEA worked together with Interface21 to optimize the Spring support in WLS 9.0. Spring will use the BEA optimized transaction API and the Springbeans can be monitored from within the BEA WebLogic Server Console.

The second topic was dealing with JVMs.
Where JVMs where initially built to support multiple platforms with a ?one size fits all? concept in mind, today?s JVMs focus on performance, specialization and ?always on?.
BEA provides with their JRockit JVM, the fastest (28% faster) JVM available on the market. The JVM has been optimized for Intel architecture CPU and a Sparc version is in the pipeline.
Strong points of the JRockit JVM are:

  • Optimized garbage collection
  • Operational diagnostics support by means of a management console, runtime analyzer, production memory leak detection and trouble spots linked to source code.
  • Stepping into utility computing: Where a cluster provides an answer to scalability to meet SLAs, with CPU virtualization we can take it one step higher.
Just pas the SLAs to the JVM and the JVM will allocate the required resources to fulfill the SLA requirements! Is it good, or is it good?!?!

Next session on the list had to do with the inner details of the JBI spec.
I wanted to see how SUN approached ESB interoperability issues and in what way the SUN architectures matches the BEA AquaLogic Service Bus architecture. Today there?s a lot of hype around ESBs. I think it?s the seasonal buzzword. Next season we?ll have something else? quite sure. From an architectural point of view, an ESB is quite simple. Support for multiple protocols, some routing, and some transformations, stick a label on it and put it in a box.

The heart of the JBI is a ?normalized router?. The router routes based upon ?normalized messages? can be enriched with plug-ins to add addition functionality to the ESB like:

  • Orchestration via BPEL
  • Transformation via XSLT
  • WS-I (Basic SOAP)
  • Business Logic (EJBs)
  • JMS
  • Binding components: Proxy for remote service providers
  • ?

The plug-ins:

  • Can be providers or consumers
  • Supply self describing using WSDL for: Messages, operations and message exchange patterns, services, end points
  • Translate the messages to/from an ?abstract message? model

Normalized message consist of:

  • Abstract message
  • Message metadata: message properties dealing with transactions, security, protocol info

The message itself will not survive a system crash. Persistence should be provided elsewhere in the process. This has been done for performance reasons.

The advantages of a JBI compliant ESB:

  • Portable installation and deployment
  • Services are portable across JBI implementations
  • Plug-ins can operate/integrate across JBI implementations

Next session was dealing with EJB 3.0
The major concerns of EJB 2.1 are the complexity to use it. This is underwritten by an awkward programming model, complex deployment descriptors and al lot of entity bean anti patterns.

EJB 3.0 addresses the pain points and provides an alternative to it.

  • Fewer classes and interfaces:
  • Dependency injection: Use metadata annotations to specify where resources have to be injected.
  • No required container interfaces: No need to code EJBHome and EJBObject methods.
  • No required deployment descriptors: Default behavior requires no deployment descriptors. Alternative behavior can be described via annotations. Deployment descriptors are still supported as well (to override annotations).
  • Focus on the business logic instead of implementation logic
  • No JNDI look-up for client applications. Business methods are defined in an interface. A POJO provided to the client implements that interface.

The EJB 3.0 entities are POJOs. These can also be used detached from the container and used across transactions. So there is no further need to map Entity beans in DTOs.

The EJB persistence layer has been drastically changed with the focus on simplification. Knowledge of JDO, Hibernate and Toplink has been merged to define the new APIs.

O/R Mapping support: Mapping is expressed using metadata annotations or XML. Default mappings are provided.

The last but least session I attended was ?A hitchhikers guide to SOA orchestrating loosely coupled services with BPEL and BPMN.?
A great sounding title with less content. After giving a definition of what BPEL and identifying its shortcomings (BPEL only orchestrates, does almost nothing more), we went over to ACDC worker services triggered by BPEL (Asynchronous Conversational Document Centric) that do the actual business logic execution.

Only interesting point to me was the BPMN or the Business Process Modeling Notification, which standardizes the BPEL process notation format.

I closed the day with Java Card and security features session. This was very interesting given the new eID they?re rolling out in Belgium right now.
Good news to see that Java Cards are evolving!
The next generation cards (+ 2007) will have:

  • 32 bit CPU
  • 16 K RAM
  • 256K ROM
  • >128K EEPROM
  • CPU Clock 50 MHz
  • 1.5 ? 12 Mb/s full duplex connection speed.

In addition to this, the card will have:

  • A servlet based connection interface, making it easier to access the card from a server.
  • More mainstream java programming: Automatic garbage collection, threading
  • Contact less, USB and MMC support
  • Internet enables.

Posted at 28 Jun @ 4:47 AM by Kurt Lefevre | 1 comment

Many larger organisations have chosen J2EE as their enterprise applications platform, but are continously struggling with the complexity of J2EE. As a result, J2EE is often seen as a technology for big enterprises building large applications, but this does not need to be true.

We are happy to see that the Java community is now uniting around a small number of solutions that try to solve this complexity issue, reduce development time, have a much better return-on-investment, and lower the total cost of ownership, in particular the maintenance costs.

Learn how more and more companies are tackling the limitations of J2EE by using open-source initiatives; and have chosen Spring, Hibernate and Struts as the cornerstones for building and successfully delivering J2EE-based projects – faster, cheaper and easier to maintain.

You can find MORE INFORMATION about the "Simplified J2EE Applications using Spring, Hibernate & Struts" seminar that we organize on WEDNESDAY 12 OCTOBER (14-21h) in Business Faculty (Neder-over-Heembeek) at:

http://www.itworks.be/event.php?id=JAVAD32

You can register:

During this ENGLISH-SPOKEN one-day seminar presented by Stephan JANSSEN and Erik JANSSENS of JCS International, you will learn:

  • An overview of the problems with J2EE and EJB today
  • How this led to new concepts such as lightweight containers,
    aspect-oriented programming and inversion-of-control
  • Detailed information on Spring, Hibernate and Struts
  • How you can use these in practice, and what the advantages are

I am looking forward to meet you and/or your colleagues in person at this seminar. If you have any questions, do not hesitate to contact me.

Patrick Van Renterghem - Manager I.T. Works
Send Feedback & Remarks via http://www.itworks.be/feedback.php

Posted at 28 Jun @ 9:01 AM by Niky Patyn | 0 comments
Last changed: Jun 29, 2005 13:33 by Stephan Janssen

James Gosling loves JavaPolis

This morning, before the JavaOne keynote (Day II), I gave a personal copy of the JavaPolis DVD box to Mr. Java himself, James Gosling.

During last years JavaPolis he actually asked some people at Sun Belgium to provide him a JavaPolis t-shirt, James confirmed he had received this killer t-shirt and told me he really liked it! Of course I run around with my personal JavaPolis t-shirt on and James started showing my back to different Sun execs... really funny.

In return, and as an extention to the JavaPolis theme of last year, James gave me a small match-box-folded carbon box gift with the title "Compatibility Matters" printed on it. The actual content was a Java condom. However Sun Microsystems logo was not printed on the box, maybe I need to unfold the content for that

Of course I've asked James if he would be interested to speak again at this years JavaPolis, he told me to drop him an email and he would verify if his agenda would let him. But we do have his blessing, so from now onwards JavaPolis is backed by James Gosling

Stephan


Posted at 28 Jun @ 2:08 PM by Stephan Janssen | 1 comment
Last changed: Jun 29, 2005 13:57 by Stephan Janssen

This year's JavaOne was really a showcase for the Brazil Healthcare Java projects. Scott McNealy had an emotional talk preaching for a technology that could save lives. Fabiane Nardon won a Duke award for that project and the leader of the Brazilian user group, Bruno Souza, was looking like the king of the conference with his Brazilian flag made coat.

I could not imagine Stephan dressed with a Belgian flag at the next Javapolis, maybe we can give him a try at our next workshop?

Brazil was also showing up in several BOFs and I thought it was worth of interest to meet Fabiane.

She gaves me more information about this project. In few words, it was all about creating a big CRM system for Brazilian citizens. This system is used by both public and private healthcare organizations in several Brazilian cities right now and is expanding across the country. Every city has its own database and application server. Replication of the citizen?s data from cities to cities is automated.

For public agencies, applications are pure http/html-based and require a less powerful computer than private companies who use a Flash-based rich internet application. Fabiane told us that Flash was much sexier to 'sell' to private companies. I know a certain Jo Wyns who will have a big smile when reading this. At our previous Rich Client workshop, Jo was stating exactly the same.

In both cases, the business logic is located on the server and is residing in EJBs, it is accessed either through Flash remoting and a server side servlet for the Flash application and through RMI for the web-based application. In total the system contains 2.5 million lines of code but around half of this code was generated.

This talk with Fabiane was very interesting, not only because she was a nice-looking women, I mean the architecture level of the thing.

That's a little bit the kind of person/talk I would like to invite for the Javapolis 2005 architecture track.

Posted at 28 Jun @ 8:17 PM by Robin Mulkers | 1 comment
Last changed: Jun 29, 2005 13:51 by Stephan Janssen

Thomas Kurian, Senior VP development, was up next in the general session room ready to announce some interesting stuff.
The setting was really nice with an Oracle red background image on the huge LCD screen. (anybody has a picture of this ?)

Thomas Kurian announced, as expected, that the JDeveloper IDE environment is now made freely available for all java developers. I must say, that if you want to do some serious JSF development you should check it out! It runs also on Mac, so I should really give it a twirl and see if I can develop as sexy JSF/AJAX enabled web apps like the demo's.

Oracle is also contributing their EJB 3.0 implementation as an open-source Reference Implementation for the EJB 3.0 JCP specification. Next to that, Oracle will release eclipse plugins for EJB 3.0, JSF and BPEL development, it seems Oracle is betting on two horses here.

Other nice demo's shown was the BPEL 'designer' (see also Edwin's talk from last years JavaPolis), secured Web Services using WS-Policy using Oracle's Web Services Manager. Another nice looking demo was a DHTML/AJAX, probably JSF, enabled rich application client demonstrating business activity management. I would love to know what burden this has on the network with all of these XML Http requests !?

To be honest, from what I've seen today, Oracle is a step further than some vendors (to name one, BEA Systems) in the area of JSF, BPEL and especially in the EJB 3 space. And this is not something Hugo asked me to type

It was funny to hear that Thomas also mentioned that Oracle allows you to work with other open-source frameworks like Spring, Tapestry, Struts etc. so buzz-word compliant.

Anyway, great JSF demonstrations and I personally believe at the end, with all of these free tools and plugins, the Java Development Community is the big WINNER !

Cool stuff,

Stephan

Posted at 28 Jun @ 9:09 PM by Stephan Janssen | 1 comment
  2005/06/29
Last changed: Jul 04, 2005 05:45 by Stephan Janssen

JavaOne ? Day 2 Summary

The weather was relatively fine and SUN acquired Seebeyond. What else do we want?
Could this be the reason why SUN is heavily focusing on SOA and integration strategies as well on JBI during this JavaOne event?

Today?s keynote speaker was Scott McNealy. Scott's ever lasting popularity did it again! Full house!! His opening was not too bad: ?We did some analysis of yesterdays sessions and because you all love JBI so much, we bought SeeBeyond last night!?.
SUN firmly believes that the SeeBeyond ICAN suite will strengthen their market position and presence.

First technical session of the day was dealing with ?Achieving great file I/O performance in Java?. Since I?ve always been in love with low level computing, this was a perfect technical session opener of the day for me.

Our BEA Engineer Gregory Brail hosted the session. Gregory focused on some important I/O related topics:

  • How to achieve ?safe? writes?
  • Larger is better.
  • How to achieve the highest write performance for safe writes?
  • How to achieve the highest read performance?
  • Things you can?t normally do with the Java I/O API stack.

A lot of today?s I/O complexity is hidden for most of the Java users. Almost no one takes care about following fundamental aspects of I/O:

  • What is the access pattern? Sequential or random file access?
  • How much data is read/written at once?
  • How much of the file is read/written in one I/O operation?
  • Durability: Do we want to survive a system crash, a power failure?

Most of us don?t think about these issues when performing I/O operations, however? When performance and throughput become critical, these parameters play an important role. The nice thing is that almost all of them can be manipulated by means of the Java I/O APIs. As said? ?almost? all of them?

To come back to the topics;
How to achieve ?safe? writes?

  • Not so easy? both OSes cache all disk write operations, as well do most of the disk drives.
  • APIs let?s you perform ?force writes?, but be careful, this doesn?t work always. The behavior depends on the way the OS, filesystem and disks work.

?Larger? = ?Better?

  • A few large I/O operations are better than many small ones. Every I/O operation has to pass through several software layers which introduces an overhead. Grouping of buffering data in order to reduce I/O calls will reduce this system overhead.
  • Extending a file is slow. When creating a file on disk, the OS just write disk blocks, however, when extending a file, the OS also has to take care about the file size during the writes. This has to be done each time a write operation takes place. Therefore, writing large chunks of data will decrease the overhead involved with this.

How to achieve the highest write performance for safe writes?
Safe writes requires a ?forced write? operation. These can be explicit or implicit.
Explicit force

  • RandomAccessFile.flush(): stores both contents (data) and file metadata (properties).
  • FileChannel.force(): stores contents (data) and optionally file metadata (properties).

Implicit force (when opening a file)

  • RandomAccessFile in ?rws? mode: stores both contents (data) and file metadata (properties).
  • RandomAccessFile in ?rwd? mode: stores contents (data).

After testing and benchmarking, it turned out that RandomAccessFile in ?rwd? mode provides the highest write throughput. It has to remarked that performance may vary, depending on the OS, used hardware and VM implementation.

How to achieve the highest read performance?
After running tests using different Java I/O read APIs, reading a file via the MappedByteBuffer gave the highest read operation throughput. A MappedByteBuffer uses the Virtual Memory features provides by the OS. Again, performance figures may vary depending the OS, the used hardware and the VM. Take into account that the address space limitations (32 bit or 64 bit CPU address space) also limit the size of the file that can be mapped in memory.

Things you can?t normally do with the Java I/O API stack.
Almost every moderns OS has a ?Direct I/O? feature. This is quite equivalent to the ?rwd? write mode, however, the Direct I/O feature bypasses the OS buffer cach, which greatly reduces the CPU usage for large I/O operations.
Direct I/O has been primarily designed to be used in databases and message busses.
Despite the benefits, today NO Java API exist to access this powerful OS feature, since this is not cross OS transparent. Wrapping native I/O calls into a (proprietary) Java is the recommended (and used) way to bring this power to Java developers today. Guess who does to achieve the highest JMS troughput today?. J

The Spring Framework: An introduction to lightweight J2EE Architecture (Rod Johnoson, Juergen Heller)

I?ve to admit that I?ve never been a first-class framework adept. Having almost as much frameworks (lightweight or not) as churches in Belgium, I?ve been always somewhat reluctant to frameworks in general. But, as a BEA employee, since BEA yesterday officially announced it support for Spring, this sessions was definitely one of the ?must attend? ones. I?m quite unfamiliar with Spring and this introduction session gave me a good feeling of what it is all about. As a first impression I would say ?not too bad?.

These days business requirements as well as technology is evolving fast. This market behavior defines a need for ?Agile J2EE?. ?Agile? is definitely one of the hippest words of the last decade. For those of you that missed that train, don?t panic, ?agile? is just synonym for ?fast changing? ?quick anticipation?. So, in order to quickly anticipate on these fast upcoming changes, we need a supporting programming model designed for it. In practice this means that the current J2EE model has to be simplified. Tools that hide the actual J2EE complexity are not a good solution.

?Frameworks? are central to modern J2EE development today, since out-of-the-box J2EE does not provide an ideal programming model. Overtime, this has resulted in
many ?in-house? frameworks, making them expensive to develop, expensive to maintain.
Modern open source lightweight containers/frameworks feature:

  • POJO support
  • Inversion of Control (IoC): This functionality provides sophisticated configuration of POJOs. IoC is often referred as the Hollywood principle, or ?Don?t call me, I call you?. It is the framework that calls your code.
  • Dependency Injection (DI) is a specialized version of IoC. The container injects dependencies into objects using Java methods. This is also known as ?push config?. DI does not require a container API, nor is it depended on a specific container implementation. It provides abstraction of the underlying environment.
  • Aspect Oriented Programming (AOP): APO provides declarative services to POJOs and out-of-the-box features like support for transactions and security.

It this cool or not? Great!!

The Spring Framework:

  • Simplyfies Java development by allowing development based on POJOs.
  • Declarative transaction management.
  • Unique consisten approach to dataaccess with a common exception hierarchy. (Simplifies working with Hibernate, iBATIS, Toplink, JDBC, ?.)
  • IOC/AOP integration
  • Integtation with third party tools like BEA WebLogic Server Administration Console.
  • Requires no deployment, so no deployment descriptors? Isn?t that nice?!

The next session was an easy listening one. It had to do with a real life story of a SOA implementation. Actually good to hear someone talking about the difficulties they experienced during their SOA project implementation. At the end of the session it all boils down to what we at BEA say in our SOA guide: ?SOA is a journey!?, meaning that it is not an out-of-the-box solution that will automatically solve all you integration problems your organization faced the last decade. No, a SOA project is a solution you?ve to implement step by step, putting milestones in the project and take the time to learn from what you did. After each milestone, corrective actions can be taken and additional SOA complexity can be added. A big bang approach to SOA will probably not do the job?

Another session on the ?must attend? list is the session dealing with the latest release of our application server, BEA WebLogic Server 9.0, brought by BEAs Sr. Product Marketing Manager Gary McBride.

With its 9th version of its application server, BEA announces an almost zero downtime enterprise kernel for SOA, robust messaging, enhanced management and much more.

I?ll focus some more on the important enhancement/features that differentiates the BEA WebLogic Server 9.0 from it competitors.

Enterprise-grade kernel:

  • (Almost) Zero downtime
  • High Availability (clustered version)
  • Disruption free application server updates in a cluster
  • Whole server migration
  • WAN/MAN failover support out-of-the box
  • Side by Side application deployment without service disruption. WebLogic Server migrates traffic gradually.
  • Application rollback

Multi service platform:

  • Support for: J2EE, Portal, BPEL, CFML, SIP, WLST, Web Services, Beehive, JFC/Swing, Spring, ?

Multi-programming model interface:

  • Support for Native Web Services, Portal, ?.

Messaging: Messaging goes far beyond JMS. Serious effort has been done on the messaging framework.

  • Store and Forward: enables messaging to potentially unavailable endpoints.
  • Simple administration of remote endpoints.
  • Fully automated migration of failed JMS servers
  • Deployment of JMS queues, topics, JDBC datasources supported via deployment plans.
  • Queue browser: Goes beyond seeing the number of bytes.
  • Enhanced management features expressed via JMX.
  • C API
  • Signification performance increase due to read/write optimization.

SOA:

  • Easy to author and deploy
  • Flexible data binding
  • Enterprise Web Services based on a new Web Services stack with support for WS-ReliableMessaging and WS-Addressing.
  • Integration with the new BEA AquaLogic Service Bus.

Management:

  • Full fledged scripting tool with support for on-line scripting via JMX, or off-line scripting via config.xml editing. The latter one is now also schema validated.
  • Dynamic changes: Almost all configuration changes don?t require a system restart.
  • Management console is BEA Portal based providing the possibility to reuse the management portlets in other applications.
  • Extensible Management console. Easy to add user extensions to the management console.
  • Server management accessible via JMX.
  • Support for deployment plans (JSR-88)
  • WebLogic diagnostics framework: Provides extensive WebLogic Server diagnostics information and allows WebLogic Server introspecting its proper health and adjust resource utilization when required (in order to meet SLAs).

Security: ?Security is a process, not a product?

  • BEA is the sole application server vendor providing a fully pluggable security framework.
  • Audit functionality has been enhanced.
  • Support for Microsoft Identity Assertion (SPNEGO)

The BEA WebLogic Server 9.0 will be available in its final release on August 2005.

Before going to the BEA and SUN drink, the last presentation I attended today was dealing with SOA (again)
Tom Bayens of JBoss talked about Workflow, BPM and Java technology.

Actually, we can distinguish three different domain models:

  • Workflow
  • BPM (has to do with integration)
  • Orchestration (BPEL and JBI related)

The jBPM kernel supports the common denominator of all three domain models, meaning the same kernel services all of the three domain model implementations.

The major limitation of the Java language dealing with one of the three domain models is that Java doesn?t support ?wait states?.

Problem:
Business users use a graphical representation that uses wait states; business analysts have a filtered view on the technical detail.

Traditional solution:
Defines a business language that has a set of constructs and nodes that have a graphical representation.
This approach has following issues:

  • Monolithic
  • Process language is never powerful enough
  • No modeling freedom
  • Turns into visual programming

Alternative solution: Graphic Oriented Programming

  • Define a directed graph
  • Define an executional model using tokens and signals. A token is a path of execution in a single system; a signal is the trigger that resumes resource execution.
  • Aligned with transactions
  • Thread safe; client thread is used for calculation
  • No reinvention
  • Existing Java APIs are leveraged (JMS API for asynchronous communications)
  • ?Actions? hide technical implementation details.
  • ?Actions? are stored in ?events?, and events are hidden from the process view.
  • Implemented as jBPM

JBPM is available in a jar format and is accessible as POJO.

The jBPM implementation looks nice, but I?m missing support for exception handling. The answer to that question was to model the exception routine in the process. This makes things too complex to me. I had expected to see node en process exception handlers as we have in BEA WLI.

k

Posted at 29 Jun @ 5:49 AM by Kurt Lefevre | 0 comments
Last changed: Jun 29, 2005 12:50 by Stephan Janssen

It's amazing how progressive, at least in San Francisco, Sun Microsystems has become.
Last year I received compliants from different Sun employees about our JavaPolis 2004 theme "Only the best get in". It seems Sun wants to prevent the best getting in by releasing Java condoms.

If you unfold the condom, it says "Sun Microsystems, compatibility matt"... I was unable to see the last letters

Java is a way of life !!

-Stephan

PS: Read my previous "James Gosling" blog, to see how I got this condom!!

Posted at 29 Jun @ 12:45 PM by Stephan Janssen | 2 comments

This afternoon, curiosity push me to attend the Wicket session. I've heard about this framework only a week ago reading a post on TSS and as a Tapestry user I wanted to compare both.
The framework is basicly similar to Tapesrty, no JSP pages but plain html pages with special wicket:id in tags and Java code in page-linked classes (swing-like code) to fill the tags in the page with runtime values.

My Conclusion in a few words :

  • Friendly and Fun
  • Clear design
  • Less XML config ... but more Java to write

I was wondering if there was any Wicket user in Belgium that could give his experience building an application with it ...

Posted at 29 Jun @ 5:38 PM by Nicolas Brasseur | 0 comments

Thomas Kurian also presented what the Oracle Fusion Middleware will look like.
The good news is that this technology stack will be based on Java EE, we can expect the whole Oracle/PeopleSoft suite of applications going step by step into that direction.

He named this Fusion middleware a Dynamic SOA. It is composed of Java EE technologies (JSF, EJB3), BPEL, a n ESB and a Metadata repository. The innovative stuff in there is the Common Metadata Repository.

Today, when we add a new attribute to a database table and want to see that attribute on the screen, we have to change all the layers between the screen and the database. An Oracle product manager at the booth told me that this repository was about to manage that case by minimizing as much as possible redundant changes in the different layers.

It looks like Oracle is leveraging its experience in the applications area to J2EE infrastructure and that is really exciting.

But Oracle is also considered today as weaker than other vendors like BEA or IBM on the pure middleware connectivity level. Thomas Kurian has drafted what the future will be, Oracle will integrate a JBI compliant Enterprise Service Bus in this Fusion stack. No details were disclosed about this. Maybe Hugo will give us more info when available.

Posted at 29 Jun @ 5:43 PM by Robin Mulkers | 0 comments
Last changed: Jun 29, 2005 18:14 by Stephan Janssen

The first days of JavaOne where cloudy and I felt the temperature was cold for June. The situation seems to improve since yesterday afternoon but I am not here to blog about the Spring season but well about the Spring framework.

I was a little bit disappointed when looking at the conference program on Monday. There were very few sessions dedicated to Spring planned. I was thinking that maybe Rod Johnson?s criticism against EJBs and Java Enterprise Edition was affecting his popularity amongst the conference selection committee.
Rod is one of the cleverest person in the Java landscape and it was sad not to have him speaking much more here.

But I must recognize that since Monday, I have seen Rod everywhere, from the BEA keynote to obscure JavaSpace-based applications used at Wall Street.

Spring is used in lot of successful Java projects that are presented here. I am blogging right now from the Spring-JSF technical session, the room is completely full!!

I really believe now that Spring is here to stay, this framework uniquely combines inversion of control, aspect-oriented programming and remoting amongst other things.

Spring is so successful that it is currently being ported to .NET, an interesting move that is opening doors for Java professionals to the .NET world (even if .NET might never become as important as Java is today I think).

I was wondering what would be Rod?s opinion about the recent Java (r)evolutions like the use of annotations. I will ask him the question.

Posted at 29 Jun @ 5:51 PM by Robin Mulkers | 2 comments
Last changed: Jul 04, 2005 05:43 by Stephan Janssen

JavaOne ? Day 3 Summary


Belgian Party @ JavaOne

Solarmetric-Tangosol party photo taken by TSS

Yesterday evening, the Belgians (and a lot of people of other nations too) did some ?after dark? acitivities. We went to the parties organized by BEA, ACA-SUN and Solarmetric where we met some really interesting people. Socializing takes time... I wonder how Gerard Maas' yesterday evening pictures will look like?
As a result I missed the introduction of this morning?s keynote. However, .. John Gage hasn?t changed over the last 10 years, so I don?t think I missed a lot.

Nokia in general hosted the keynote. Really really really interesting to see how Java evolves on mobile devices, actually on devices in general. I even noticed ?SOA? and ?mobile devices?. Right know it sounds strange to me having an orchestration layer on my GSM to manage my mobile services, but definitely, I?m convinced that one day we?ll get there.

For those who know me, they know I like figures. I was quite amazed to hear that there are more Java devices out there than there are PCs running Java!!! 2,5b Java devices versus 700m PCs. Think about it!

Today was a quite SOA free day! However... you never get totally rid of it this year.
I took some more really low level oriented sessions, things you know they exist but where you don?t spend time on to think about.

To kick off the sessions today, I started with the ?Java & .NET interoperability using WS-* Web Services Architecture?. Actually, this session was a joint presentation effort of both SUN (Java) and Microsoft (Indigo .Net) guys!
Listed as a ?leading edge? session, it turned out to be a quite basic one. Nevertheless, it was quite interesting.

The initial vision of Web Services was having a transport mechanism allowing transporting whatever kind of data (XML) and metadata (WSDL) in a standardized way (SOAP) between heterogeneous systems having abstraction from the actual transport protocol (HTTP, TCP, SMTP, ?)
Over time, Web Services specifications have been extended with support for transactions, security and reliability.

In the context of service orientation there is a clear convergence between the .Net and Java platform. Both platforms are converging on:

  • Common protocols
  • Common metadata (full XML Schema support)
  • Development simplification by means of annotations based development and GUI support
  • Service protocols: Core SOAP bindings, SOAP Attachment bindings and further QoS bindings
  • Web Services management.

Solving the interoperability issue allows developers focusing on the actual implementation instead of spending effort to solve connectivity issues.

The next ?leading edge? session I selected ?Evolving the Java language? had to to with future language extensions on the Java language. Keep in mind that the Java language is not the same as the Java Platform. The language is part of the platform, but not vice versa.

The Java language has been designed with C++ as one of its major source of inspiration. Lessons learnt from C++ where that Java:

  • Should focus on code ?reading? instead of code ?writing?; meaning priority to readability over easy of programming language constructs.
  • Simplicity matters. However I liked C++ a lot and found it not complicated at all, ?pointers? where for some friends of mine a struggle of life.
  • One language with the same meaning everywhere. No ambiguity.

There will definitely a natural evolution of the Java language, but it will be a slow en controlled process. Things we will probably never see in the Java programming language are:

  • Multiple inheritance
  • Operator overloading
  • AOP
  • Continuation
  • Pre processors
  • Multiple dispatch
  • Multiple return values

Things that we shall probably see in the future releases are:
XML support:
XML support will become part of the Java language. Specific language extends will be added for this. The compiler will do all the necessary work to make it happen.
Coming soon to a JSR near you:

  • Syntax validation
  • Type checking
  • Name spaces
  • Document types
  • Processing instructions
  • Mutability

Other language ideas:

  • Method references/closures
  • Friends: Access control is to strict new; the ?friend? notation à la C++ would make it a lot relax.

New byte code format
What: Better support for other languages, like scripting languages, natively in the JVM.

Why:

  • To broaden the community
  • Performance: Currently other languages run on top of the JVM

How: Still under construction, but by means of dynamic byte code invocation. Currently, the JVM has 4 bytecodes for method invocation:

  • invokevirtual (normal method invocation on an object)
  • invokeinterface: Guess what this does?
  • invokestatic
  • invokespecial (Used for constructor invocation)

The current, not fully worked out idea, it to add a fifth bytecode called ?invokedynamic? to support the dynamic byte code invocation required for native language support in the JVM.

Back to the Java - .Net interoperability. The next session I attended, ?Multiple Platforms, Single Identity: Interoperable Identity?, dealt with single sign on (SSO) solution models for heterogeneous environments.

Some security basic terminology:

  • Identification: Who are we talking to?
  • Authentication: Are you sure, you are who you are? Requires the user to provide a credential. After being authenticated, the server provides a short-life token to represent an authenticated identity
  • Authorization: What am I allowed to do?

In java we have two ways of setting-up security:

  • Declarative security: Delcalred in ejb-jar.xml, web.xml
  • Programmatic security: getCallerPrincipal(), isCallerInRole(), getUserPrincipal(), isUserInRole()

A typical enterprise runs dozens of web applications having different ways of authentication. From a management perspective, this makes it very difficult maintain it. A Singe Sign On solution heavily reduces the maintenance coming along with enterprise wide authentication.

SSO: The web agent/proxy inserts identity information as HTTP headers, accessible from the HttpServletRequest. Identity information can be stored in the EJB context as well. We distinguish Enterprise SSO and web-based SSO.

Desktop SSO:
The user experience:

  • Authenticate to OS desktop
  • Browse to the protected resource
  • Use desktop crendetials
    Standards exist in GSS-API and SPNEGO
    Domain SSO possible on Windows, Solaris, Max OSX
    However? Web SSO using cookies has limitations.

Federation:
Loose coupling (.Net/Java/?) and strong interaction
Federation is the solution to span SSO across domains.

  • Security is built from the ground up
  • Privacy is built in. Mechanisms have been put in place to only reveal the information that is required.
  • Standardized
  • B2B/B2C/B2E scenarios particularly well suited
  • J2EE and federation: Seamless integration! Code can continue run ?as is?.

Identity Federation Frameworks:
SAML 1.x ? 2.0
Standardized by OASIS
Platform independent
Basis of federation:

  • Specification for representing identity assertions in XML
  • Request-Response protocols
  • Browser based SSO
  • Liberty Alliance Project:

  • Leverage existing standards: SOAP, SAML, WS-Security
  • Extends SAML: Single logout, Account linking, Pseudonyms
  • The basis for Identity Federated Web Services (JSR-196 in progress)

The last but least session today, ?Introduction to the Eclipse Web Tools Platform project? by Dr. Tim Wagner, BEA Systems Sr. Manager, focuses on some valuable extensions on the Eclipse IDE.

Why has BEA chosen to join Eclipse?

  • Eclipse is open and transparent
  • Provide collaborative solutions wit other vendors.
  • BEA is board member and contributor

The Web Tools Platform (WTP) will serve as basis platform for the BEA Workshop IDE based on Eclipse.

WTP Themes (0.7 release)

  • Extend Eclispe into the J2EE domain
  • Define servers, runtimes, modules
  • Provide platform tools
  • Provide useful tools for developers

Well done: For a full featured list, I recommend to checkout: http://www.eclipse.org/webtools/

The last session today I selected fits perfectly in one of my favorite Java domains: ?Speculative locking by Azul Systems? in the JVM! Hurrah! Speculative locking deals with postponing or avoiding actual locking to favor performance when multiple threads operate at the same time in the same locked region. Locking takes only place when it?s really required. Normally the first should lock, setting other threads in a wait state, so resulting in a performance and a scalability penalty. Sometimes it turns out that there actually was no real need for locking?

Why do we care?

  • Java applications naturally multi-threaded
  • Multi core CPUs from all major vendors.
  • Amdahl?s law: efficiency = 1/(N*q + (1-q)) where N = #CPUs and q the portion of serialized code. For high efficiency, the amount of serialized (= synchronized blocks) has to be reduced.

Locks are typically too conservative. Locking is done to avoid contention (=interring access to a resource). In practice it turns out that locking takes place without having contention. However, it?s difficult to predict contention.

Let?s take a look how Optimistic/Speculative locking behaves by database transactions:

  • Transaction: atomic group of db operations.
  • Data contentions result in a rollback
  • Software re-executes until successful
  • Optimistic/Speculative locking does scale!

The same principle will be applied in a multi-threading context when the thread want to access a synchronized block.:

  • Uncontended synchronized blocks: Run as fast as before
  • Data contended synchronized blocks: Still serialize
  • Speculative synchronized blocks: Executes in parallel, when collision, a rollback takes place and a retry takes place

Since all the locking logic is handled by the VM, it?s transparent to your Java code, meaning that no code changes are required when replacing a traditional VM by the Azul Systems VM.

This is definitely an improvement in a specific area in the JVM, which will definitely lead to a performance gain. I?m really curious to see in what order performance figures are, compared to the fastest JVM currently available, BEA JRockit?

k

Posted at 29 Jun @ 10:35 PM by Kurt Lefevre | 1 comment
  2005/06/30
Last changed: Jun 30, 2005 14:31 by Stephan Janssen

Just a quick post to announce that the BeJUG/JavaPolis wiki's have of today exceeded the 9.000 milestone of registered Community members. Consolidated, the counter of BeJUG and JavaPolis wiki members has now reached 9.022 !! Now start getting more involved on our wiki's, so we can share more information and thoughts

-Stephan

Posted at 30 Jun @ 2:29 PM by Stephan Janssen | 0 comments
Last changed: Jul 11, 2005 03:58 by Stephan Janssen

A brief update on what's happening this year at JavaOne in the Mobile device space, the domain I was most interested in?
One major announcement - although not completely unexpected - was the convergence of J2ME platforms and variations into one single Mobile Service Architecture implemented through 2 stacks. JSR-248 defines a low-budget, but less flexible mass-market device; JSR-249 defines the functionality for mid to high end devices style SmartPhone with enhanced levels of manageability.

It is exactly this manageability that will be one of the challenges for the next few years. With so many (legacy) variations in the market dealing with embedded software deployment will become an increasingly complex issue. JSR-233 (J2EE Mobile Device Management and Monitoring Specification) and JSR-246 (Device Management APPI) define java interfaces to management systems, the latter for the device, the former for integrating management functions into the back-end infrastructure. JSR-233 extends JSR-124 J2EE Client Provisioning (also known as ?The Vending Machine?)

JSR-232 (Mobile Operation Management) defines embedded service interaction and is based on the OSGi industry standard (http://www.osgi.org). This specification will allow concurrent embedded applications to be deployed in such a way that component dependencies and access control are preserved. This runtime model is currently used by vendors such as Nokia on SmartPhones, SiemensVDO and IBM in Telematics and on residential gateways by e.g. Motorola. Wednesdays keynote showcased both Nokia and IBM showing tools facilitating the development of such applications.

JSR-179 (Location API for J2ME) nicely abstracts the need embedded applications might have for locating themselves from the underlying implantations. Devices (such as phones) might get location data from the network, the local cell and/or (Assisted)GPS. What counts is the desired interval and the required quality of service. Initialization of the GPS (fixing) might take more time then a user might expect (minutes!) and some programming techniques should be applied to work around the latency and storage issues inherent to mobile devices.

One session had an interesting analysis on the current state of the art: MIDP 1 was nice but not realy useful for real application deployment due limited API availability and the lack of security. MIDP 2 solves most of these problems and can very well be used for corporate application. However, for end-user services the deployment is very complicated and for now in practice only possible though the network provider. Read: Business to Consumer will need to be resolved by widely implementing the management API's mentioned earlier in this summary.

What was missing for me this year? Automotive/Telematics. Java will hit the Blu-Ray/Multimedia market before it will proliferate to our cars... It once seemed to be the other way around....

Posted at 30 Jun @ 4:53 PM by Wim De Munck | 0 comments
Last changed: Jul 02, 2005 05:18 by Stephan Janssen

It was also interesting at JavaOne to walk in the exhibit hall where the sponsors explain their product and services.

I'd like to point out a funny story that happened to my at the Sun corner there.
I was impressed with the many clever projects shown at the Sun corner, as the looking glass project.
Then I saw "JavaHelp for desktop" on a wall. Oh, that's interesting: Sun will provide, part of Java SE 6, an integrated help system.
It looks similar to the system proposed by Eclipse RCP.

So I started a dialog with the girl doing the demos:
John: Hey, looks nice.
Girl: Thank you. Do you know JavaHelp ?
John: No, and I?d like to know more. Can you tell me the feature difference between JavaHelp and the Eclipse help system ?
Girl: Hum, .... mmmm .... you know, we propose NetBeans, and ...
John: No, no, I don't mean the Eclipse Java IDE to develop Java programs. I mean the Rich Client Platform that let you run a Java business application into the Eclipse container, so you may benefit, for example, of the help system for your Java application. It's cool that now we can have that with Java SE.
Girl: Hum, .... mmmm .... I don't know, you should ask the question to my colleague, please wait a minute.

An senior man who apparently was more involved in the JavaHelp project came and we started the discussion:
John: Good morning. I just discover the existence of JavaHelp. Interesting. I've a stupid question.
Man: go on.
John: How do you compare, technically, JavaHelp with the Eclipse RCP help system?
The man turned green and looked at me as it I was a Muslim terrorist.
Man: Hum, .... mmmm .... We don't do Eclipse, we work with NetBeans. You should ask your question to the marketing department.
John: I'm sorry, probably my English is too bad and my question is not clear. I don't talk about Eclipse as a Java editor.
Man: I've understood your question, but you have a press/analyst badge and I can't answer to you. Please go and ask your question to a salesman.
John: Oh, I completely forgot. I find your idea of JavaHelp in Java SE pretty and I asked you this question because I practice desktop programming myself. I did not intend to write anything on it.
Man: Please see with a salesman.

I wish I went to the salesman to tell you what happened (because he would not have been able to answer such a technical question), but I didn't.

I'd like to join Robin in his ?SpringOne?? post yesterday. Sun pushes hard to provide what developers needs (at last) for productivity in the standard Java stack. But they look like upset by competition. The only Eclipse session happened in the smallest room of the conference and was fully booked days before the conference begins (pretty rare).

Posted at 30 Jun @ 6:12 PM by John Rizzo | 0 comments
Last changed: Jul 04, 2005 06:03 by Stephan Janssen

JavaOne - Day 4 Summary

Today was the last day of the JavaOne conference 2005. So, this is the final episode of my talk. As usual, the last general sessions are showcases of cool things possible in the different Java domains, consider it as ?toy day?.
It was also difficult to find some interesting sessions today. I?ve the impression that all the sessions that didn?t fit in one of the first three days have to fit in day 4. This is clearly the round-up of the conference. For me, today = mobility day.

This year, the focus of the toy day was on Java in the mobility space. There has been shown 5 hip demos of which almost of them dealt in one way or the other with mobility.

All of the SUN demos were running on the Netbeans IDE; guess why . Of course, it?s their own product and it?s not bad at all, but while SUN is advocating the ?community? spirit during the whole JavaOne conference, SUN is almost the only one that still focus on Netbeans while the rest of the ?community? clearly made the move to Eclispe, well-or-not enriched with a bunch of plug-ins. One day, they?ll get the message I hope, but when I read Cedric Beust's impressions on JavaOne way back in 2002 (http://www.beust.com/javaone2002.html), I found out that he's also referring to anoying Netbeans pop-ups during general sessions.

Talking about plug-ins.. The message is clear: ?Everybody does it, everybody should it? (Just a phrase from George Michael?s ?I want your sex?). Almost every vendor, community or individual is writing plug-ins to do whatever what. Nice to see such a creative and constructive movement!

The first one was a demo where from within the Netbeans IDE you could ?move? a Java application from one machine to another. Here I?m not talking about J2EE applications running on an application server where hot(re)deploy solves this for you, but about straight J2SE applications. The IDE had a visual representation of the two machines and you could simply drag and drop the app from machine A to machine B, just as you drag en drop objects. Really cool!!! Also nice to see, that this all happens at runtime! When moved, you could see the app stopped working on machine A and started on machine B. This creates a lot of opportunities in the mobile space to transfer Java applications among mobile devices.

The second demo had showed the future evolution of Swing using rich Swing components in Netbeans. Nice to see of course; the demo was pretty cool (CD library and integrated player), but this doesn?t add anything that was not present in, let?s say, Visual Basic 3.0 or Delphi almost one decade ago. I admit that this is nice to see these things in the Java world, but at the end of the day, it didn?t add anything more than the basic concepts of visual programming; meaning that you pick a Swing ?component? from a palette, drop it on a canvas and set some properties. Haven?t we done that all 10 years ago when the first visual programming tools appeared on the Windows front?

The third demo was quite impressing. It had to do with J2ME development and debugging. When you develop J2ME applications, you usually build them in an IDE and test and debug them against a software emulation of a mobile device. Well? what we saw today allowed doing real-time debugging of your J2ME application, even wireless via Bluetooth, directly on the device. Is this cool or not?

The last but one demo showed how water sensors in the ocean here in the Bay area do some water analysis and use a mobile device to dial in into the network to transfer the information to an application that monitors the water quality, triggering some alarms when necessary.

The last demo showed the use of Real Time Java for autonomous navigation of unmanned aircrafts. Boeing is doing some experiments (Scan Eagle) with unmanned aircrafts where a RT Java application is the pilot. Scary or not, judge yourself.

The nicest thing about it is that the RT Java application acts as a Web-Service! To me this is the weird web-service I?ve seen so far. Flying back to Belgium tomorrow, I convinced myself that this kind of technology is (still) not used in their 747-400 airliner.

Continuing in the mobility space, I attended the ?Blueprint for creating high-performance portable J2ME applications?.

What are today?s challenges for mobile applications?

  • Fragmentation in both devices (+400 and +20 new devices every month) and operator level (+140). Devices have proprietary operating systems, APIs, ?
  • Optimization challenges: Take into account JAR size limitation, available heap space, processor, screen (resolution size), ?

Portability guidelines for application re-use over different mobile devices:

  • Applications need to be designed with portability and localization in mind.
  • Porting is most efficient when it is a ?no-compile? process; just start from a master copy and then port (also known as ?developer-disconnected? model)
  • Most effective when done by dedicated porting team
  • Following the eight portability guidelines

Eight portability guidelines:

  • Application can dynamically adapt to different screen sizes
  • Don?t hardcode sound data
  • Provision for incoming calls/messages and pressing ?end? button. Just foresee it in case of?
  • Maintain separate data files. Easier to adapt when moving to slower/faster devices
  • Preserve localization issues upfront.
  • Carefully consider device specific API before using them.
  • Recognize size/memory constraints of handsets
  • Pay attention to the operator?s requirements.

How to optimize mobile applications?

  • Four key factors: Performance, JAR size limitation, Heap memory size, screen size
  • Normally, you have to trade one off for the other.
  • Does not mean ?lowest common denominator? implementation. Take advantage of the features provided by the device, don?t use only the features all devices have in common.
  • Delay optimization till the last minute.

Performance optimization:

  • Keep it simple!
  • Use only 1 application thread. When using too many threads, the device grinds to a halt
  • Minimize use of ?synchronized? as much as possible. Appears to be very slow and buggy on a lot of devices.
  • Avoid using the Timer class, an extra thread is created
  • Create background thread in startApp
  • Network thread is the exception cause the network sometimes blocks. It?s handy to have a separate thread to avoid device lock-up.
  • Handle system callbacks. Paint, keyPressed, ? and return asap to avoid slowing down the VM.
  • ?Do not assume? when porting applications from one device to another. Performance may different than expected.
  • I/O: I/O calls are very expensive; read/write operations should be buffered. Streams are extremely slow (sometimes 20 bytes/second)
  • API: Some APIs are considerable slower than others.
  • Avoid unnecessary object creation and/or memory creation

JAR size optimization:

  • Minimize the number of classes
  • Avoid Object Oriented Programming (Euh? )
  • PNG files are not compressible and therefore it?s a good idea to use a PNG optimizer like OptiPNG or PNGCRUSH, to reduce the color depth or combine multiple PNGs into a single resource bundle.
  • The use of an Obfuscator may reduce the JAR file size by 30-50%

Heap memory optimization:

  • Images: Small images are better than larger ones, split large images into multiple small ones
  • Reduce, reuse and recycling of objects and other resources
  • Garbage Collector: Run the GC frequently. Be aware of different GC behavior on different mobile VMs.
  • Disable some features via JAD entry

Screen size optimization (not so much controlled by the developer)

  • Dynamically adapt to different sizes
  • Automate screen scaling
  • Different graphic sets
  • Create two or more reference builds

— The End, Thanks for reading!

My overall impression about J1? Well, as I already stated in my day 1 summary: It was all about ?SOA? and ?lightweight?. SUN was really hard pushing the whole SOA story. Somehow, I can understand this cause other vendors are doing this as well. But what makes SUN really different to me is that they are currently missing the products (or they are not mature at all) to fill in a real SOA implementation. I?ll speak for my own company, but we at BEA have our AquaLogic product range that provides mature building blocks for concrete SOA development; the tools are there! Maybe it will change when SeeBeyond is a full SUN family member after the acquisition phase.
I followed a lot of SOA related sessions, but it was still vague or very limited. I missed the broader picture and some real world examples.
Netbeans? same story. They managed it to get Netbeans in every keynote of the general sessions, while the whole J1 crowd was thinking and dreaming of Eclipse with some cozy plug-ins.
Besides these litte side notes was the conference quite interesting.

k

Posted at 30 Jun @ 8:32 PM by Kurt Lefevre | 0 comments
June 2005
Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    

Jun 26, 2005
Jun 30, 2005

Adaptavist Theme Builder Powered by Atlassian Confluence