Java Blog

Adobe Ajax Android Anwendung Apache API C++ Community Developer Eclipse Eclipse Foundation Embedded English Enterprise Entwickler Equinox Galileo Google Handy IBM IDE Individual Java Member Microsoft Mobile Modeling NetBeans News Open …

As I mentioned a while back, Eclipse Helios M5 was made available for Download. There are number of New and Noteworthy features, but one really big feature was omitted from the N&N. The Eclipse provisioning platform, p2, finally has API! Really, go take a look at the code… all those internal.provisional packages are now gone!  This was actually a huge milestone for the p2 team, and Pascal did a great job steering us towards the API.

What does this mean to you? Well, if you are building anything on top of p2 you should grab M5 and see how the new API feels. We are going to be pushing hard to finalize the API for M6, so if there is anything missing, speak up now.

John Arthorne even started a Migration guide: http://wiki.eclipse.org/Equinox/p2/Helios_Migration_Guide

Ein Blick in die Java-User-Group-Szene belegt wieder einmal eindrucksvoll den hohen Aktivitätsgrad der verschiedenen Gruppen im deutschsprachigen Raum. Hier sind die anstehenden Treffen im Überblick:

Bei der JUG Karlsruhe redet Papick Taboada …

In case you missed the news, Symbian has achieved it’s goal of being a fully open source operating system. Before I start, I have to congratulate Lars Kurth (former CDT guy) and the gang at the Symbian Foundation. It’s an incredible effort to take a commercial product and clean it up to be consumable under an open source license. To finish ahead of schedule is a tribute to the passion and dedication the Symbian guys have for this new direction. Very cool.

But as much as I appreciate the work they did, I do worry how well it’ll succeed. Yes, I’m open source guy and am a huge fan of open source projects and working with diverse communities coming together for a common goal. But at times, I don’t think it’s enough in order to be successful, especially if you are in the platform business.

Funny enough, while I was calling people “Apple Fanboys”, someone called me a “Microsoft Fanboy” (I didn’t even know it was possible for someone to be a Microsoft fanboy). But yeah, I appreciated how Microsoft built up their app developer ecosystem. Even though it’s all closed, Windows is still massively successful, thanks mainly to the apps people build for it. The same is true for Apple, obviously. There’s a reason why 150,000 iPhone apps headlines their marketing material.

The important difference I’m starting to realize is that open source platforms appeal to platform developers, the guys that port the platforms to new devices. Having an open source platform helps get you on to more and more devices as the barrier to entry is much lower, or at least the run-time royalties are much lower.

But it’s applications that drive device sales and application developers are a different bunch. You need a great set of tools and a great set of APIs and a great ecosystem with promises of riches to appeal to application developers. And that’s independent from how open your platform is I’m afraid.

With all these mobile platforms entering the mainstream, it’s a big fight for app developer mindshare right now. And that’s a much bigger fight than for platform developers. Either way, it’s a great day to be software developer!

Das Java-basierte Open Source Webdav-API Milton ist in Version 1.5.1 erschienen. Milton wird dazu genutzt, Daten via Webdav auf die Web-Applikation zu laden. Diese Daten können von einer Datenbank, einem File-System oder einer anderen Quelle …

I recently rewatched “How to Design Good APIs and Why it Matters” (youtube video embedded below).

There are many lessons that can be learned from designing a good api, one of the tips is to make sure that your method names make sense. I ran across some code today in a test case, named:

createStuff

Great, I used to write these types of method names when I was starting out. Figuring they were throw away, or just funny. However, over the years I tend to avoid these names. Why, because 6 months later I’m trying to remember what type of stuff is being created. The same thing goes with naming variables:

that

While it is cute, especially when you are comparing this to that, it can be harder to figure out 6 months later what that really entails depending on the code. Choosing proper names does help with the overall maintainability of the code. A computer may not care, but a human has to know quickly what is going on.

Another favourite I’ve seen lately is naming a variable soup. What is soup? What does it contain? Is it vegetable, egg drop, beef, or chicken noodle? Descriptive variables help yourself and those that have to maintain the code after you leave.

If you are not using a static analysis tool to help detect possible bugs ahead of time, why not? If you are looking for a way to help contribute to an open source project, but are not sure where to start, consider running FindBugs or PMD against that code base. Submit some patches to the committers. It is amazing the type of Homer Simpson “DOH!” moments these tools find.

An example:

  if (someNullClass == null) {    _log.info("Error getting class name" + someNullClass.getName());  }

Obviously if this code ever was hit, it would toss a NullPointerException. However, I found similar code that had been in place for 3 years.

Your build system can help you out with reporting these types of issues. Hudson has the ability to display both FindBugs and PMD reports. These types of tools can really help clean up your existing code, and help to catch bugs before they can happen. I’ve also seen them help increase performance on some code bases. A very common pattern I keep seeing is string concatination in Loops. This is particularly nasty depending on the number of iterations, and is an easy thing to fix, by making sure you use StringBuilder or StringBuffer instead.

Here is a suggestion. Since for those that are on the Helios release train, M7 is supposed to be for bug fixes and documentation. Why not take a part of that time to run FindBugs or PMD against your code, and try to address as many of these bugs as possible. If you haven’t run these tools against your code base, you might be surprised what they find.

A constant gripe I hear from committers is that there is not enough resources to fix all the bugs, but how about we try to prevent some from ocurring in the first place. Then you can have more time to work on your features and that killer E4 application.

As the model for the e4 workbench stabilizes we’re back working hard on the compatibility layer. Right now it consists of the gutted org.eclipse.ui.workbench plugin. The idea is to support the API we have in org.eclipse.workbench, but based on the e4 workbench model and e4 services, instead of the mass of internal code in parts, perspectives, and presentations.

We’re taking a 2 pronged approach. Creating an e4 IDE application and slowly adding useful views and actions, seeing what is needed to bring them up. We want to support a useful number of views (like the Project Explorer and Problems view) sooner rather than later.

We’re also running the org.eclipse.ui.tests.api.ApiTestSuite (after cleaning up internal references in the tests themselves with the aid of a tweaklet). ApiTestSuite covers the most common scenarios (opening and closing windows, perspectives, views, and editors), and supporting our API is a good way to help 3.x plugins run on e4 with the compatibility layer.

There’s always a lot to do, so if you are interested please check out http://wiki.eclipse.org/E4/Compatibility/Running_the_compatibility_layer. You can also post to the e4-dev mailing list, or join us on irc at irc://freenode.net/#eclipse-e4

The RAP team just announced the availability of RAP 1.3 M5!

If you’re interested in single-sourcing Eclipse-based applications, please give it a try.

In the 1.3 M5 release, the RAP team added more SWT API to make single sourcing existing applications easier:

• Composite#layout( Control[], int )
• MouseEvent#stateMask
• Widget#reskin( int ) and SWT.Skin event
• ImageData
• ImageLoader
• ImageLoaderEvent

The team also added IApplication support which simply translates into one less extension point you have to use to create a RAP application. In the past, RAP had its own entrypoint extension point which performed a similar role to what the application support does in Equinox already.  This should make RAP even easier for RCP developers to get into.

RAP is also taking advantage of the Equinox extension registry is able to handle multiple locales.

So please give RAP a try if you’re interested in bringing your RCP application to the web.

Freitag… wieder eine neue Challenge bei Fun with Shapes and more zum Thema Herzen & Streifen…. • Stempel: Whiff of Joy, Magnolia, Stampin Up, Heindesign • Stempelkissen: Memories Black, Versa Magic Wheat, Versa Magic Sahara Sand, Versa Magic Jumbo Java • Papier: Canson Mi-Teintes, Conqueror, Melissa Frances • Schneidemaschinen: Cuttlebug, Spellbinders Nestabilities • Stanzer: Retro Flower von…

Hinter Verside verbirgt sich ein neues Entwicklungstool für Datenbank-getriebene Webanwendungen, das auf Open-jACOB aufbaut, wiederum ein freies RAD-Framework (Rapid Application Development) für RIA-Anwendungen, das auf Eclipse basiert. …

Like the title already says the latest nightly build comes with 2 amazing features one already part of the code base since a long time (XPath to traverse the UI-DOM) the second one just hit SVN (plugable model-item mapping). I’m going to discuss them in short in this blog posting.

Plugable Model-Item-Mapping

You probably ask yourself. What’s this and why should I care. To understand the problem you must know how the current JFace-Viewers are working internally and which problems this can cause.

JFace-Viewers store strong Java-References between the domain model and the SWT-Item using TableItem#setData(Object)/TreeItem#setData(Object) and additionally if you turn on hashlookup (to speed up setting of selections, …) in an internal HashTable.

The problem with this is that your domain model stays resident in memory as long as the TableItem exists even if no one really needs it until you e.g. want to update the table-item. This implementation detail of current JFace-Viewers makes the use of CDO in UI less ideal because CDO can’t apply it’s clever memory management because your UI code holds strong references into your domain-object graph.

One can overcome this problem in JFace-Viewer world as well by writing some clever Content- and LabelProviders (The implementation is also available from our repository but not part of a build yet) but in my opinion not ideal from a users point of view. Moreover I think a viewer framework should have the possibility to plug-in “your” mapping strategy (e.g. provided by the domain-technoloy project you are using) according to the use case.

That’s why I decided that this feature has to be part of the core UFaceKit-Viewer-Framework and the support of it has just hit the SVN-Repository and is part of my shining new nightly athena build.

/*******************************************************************************
 * Copyright (c) 2010, BestSolution.at and others
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * http://www.eclipse.org/legal/epl-v10.html
 *
 * Contributors:
 *     Tom Schindl <tom.schindl@bestsolution.at> - Initial API and implementation
 *******************************************************************************/
package org.eclipse.ufacekit.ui.jface.cdo.viewers;

import java.util.Collection;
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;

import org.eclipse.emf.cdo.CDOObject;
import org.eclipse.emf.cdo.common.id.CDOID;
import org.eclipse.emf.cdo.view.CDOView;
import org.eclipse.ufacekit.ui.jface.viewers.Viewer;
import org.eclipse.ufacekit.ui.jface.viewers.mapping.AbstractTableItemModelMapping;

public class CdoModelTableItemMapping<ModelElement extends CDOObject,Item extends org.eclipse.swt.widgets.Item> extends AbstractTableItemModelMapping<ModelElement, Item> {
  private CDOView view;
  private Map<CDOID, Item> map;

  public CdoModelTableItemMapping( CDOView view, Viewer<ModelElement, ?> viewer) {
    super(viewer);
    this.view = view;
    this.map = new HashMap<CDOID, Item>();
  }

  @Override
  public void associate(ModelElement model, Item item) {
    if (map.containsKey(model.cdoID())) {
      throw new IllegalStateException("This mapping only supports one instance of a model element");
    }
    item.setData(model.cdoID());
    map.put(model.cdoID(), item);
  }

  @Override
  public void disassociate(Item item) {
    map.remove(item.getData());
    item.setData(null);
  }

  @Override
  public void disassociateAll() {
    map.clear();
  }

  @SuppressWarnings("unchecked")
  @Override
  public ModelElement lookup(Item item) {
    return (ModelElement) view.getObject( (CDOID)item.getData() );
  }

  @Override
  public Collection<Item> lookup(ModelElement element) {
    Item item = (Item) map.get(element);
    if( item != null ) {
      return Collections.singleton(item);
    }

    return Collections.emptyList();
  }
}

This implementation is completely untested but I think you should get the point because we are not restoring the domain object but look it up from our local CDOView we can once more rely on CDOs clever memory management. Nice isn’t it?

XPath support to traverse your UI-DOM

This feature is part of UFaceKit sources since day one in the SVN-Repository but I added it not into the first nightly builds. I think the XPath support for UIs is a fairly unique feature of UFaceKit and the reflective API makes it extremly easy to implement it operations like e.g. applying changes to a many widgets.

package testproject;

import java.util.Iterator;

import org.eclipse.core.runtime.IStatus;
import org.eclipse.core.runtime.Status;
import org.eclipse.equinox.app.IApplication;
import org.eclipse.equinox.app.IApplicationContext;
import org.eclipse.ufacekit.core.xpath.common.XPathContext;
import org.eclipse.ufacekit.core.xpath.common.XPathContextFactory;
import org.eclipse.ufacekit.ui.core.UIDesktop;
import org.eclipse.ufacekit.ui.core.UIFactory;
import org.eclipse.ufacekit.ui.core.UIRunnable;
import org.eclipse.ufacekit.ui.core.UIWidget;
import org.eclipse.ufacekit.ui.core.controls.UIApplicationWindow;
import org.eclipse.ufacekit.ui.core.controls.UIButton;
import org.eclipse.ufacekit.ui.core.controls.UIComposite;
import org.eclipse.ufacekit.ui.core.controls.UIInputField;
import org.eclipse.ufacekit.ui.core.controls.UILabel;
import org.eclipse.ufacekit.ui.core.controls.UIApplicationWindow.ApplicationWindowUIInfo;
import org.eclipse.ufacekit.ui.core.controls.util.Rectangle;
import org.eclipse.ufacekit.ui.core.form.UIGridFormBuilder;
import org.eclipse.ufacekit.ui.core.layouts.GridLayoutData;
import org.eclipse.ufacekit.ui.core.layouts.UIFillLayout;
import org.eclipse.ufacekit.ui.core.layouts.GridLayoutData.Alignment;
import org.eclipse.ufacekit.ui.core.xpath.UFacekitXPathContextFactory;
import org.eclipse.ufacekit.ui.jface.core.JFaceFactory;
import org.eclipse.ufacekit.ui.uform.UBeanForm; 

public class Application implements IApplication {

  public Object start(IApplicationContext context) throws Exception {
    JFaceFactory factory = new JFaceFactory();

    final UIDesktop desktop = factory.newDesktop();
    desktop.runWithDefaultRealm(new UIRunnable<UIDesktop>() {
      @Override
      protected IStatus run(UIDesktop arg0) {
        createUI(arg0);
        return Status.OK_STATUS;
      }
    });
    desktop.run();

    return IApplication.EXIT_OK;
  }

  private void createUI(UIDesktop d) {
    UIFactory<?> f = d.getFactory();

    UIFillLayout l = f.newFillLayout();
    final UIApplicationWindow window = f.newApplicationWindow(d, new ApplicationWindowUIInfo(l));
    window.setText("UFaceKit - Hello World");

    UIComposite comp = f.newComposite(window, new UIComposite.CompositeUIInfo(null, f.newGridLayout(1)));
    UILabel label = f.newLabel(comp, new UILabel.LabelUIInfo(GridLayoutData.fillHorizontalData()));
    label.setText("Form Example");

    UBeanForm form = new UBeanForm(f);		

     UIGridFormBuilder builder = UIGridFormBuilder.newInstance(comp, GridLayoutData.fillHorizontalData(), form);
     builder.newLabel("Firstname");
     builder.newInputField(UIInputField.InputFieldBindingInfo.newTextFieldInfo(form.detailValue(Person.FIRSTNAME, String.class)) );

      builder.newLabel("Surname");
      builder.newInputField(UIInputField.InputFieldBindingInfo.newTextFieldInfo(form.detailValue(Person.SURNAME, String.class)) );

      UIButton button = f.newButton(comp, new UIButton.ButtonUIInfo(new GridLayoutData(Alignment.END, Alignment.DEFAULT)));
      button.setText("Save");
      button.setActionRunnable(new UIRunnable<UIButton>() {

      @Override
      protected IStatus run(UIButton b) {
        XPathContextFactory<UIWidget> factory = UFacekitXPathContextFactory.newInstance();
        XPathContext context = factory.newContext(b.getParent());

        Iterator<?> iterator = context.iterate("UIComposite/UIInputField");
        boolean flag = true;
        while( iterator.hasNext() ) {
          UIInputField field = (UIInputField) iterator.next();
          if( field.getText().equals("") ) {
            flag = false;
            field.getStyle().setBackground("#ff0000");
          } else {
            field.getStyle().setBackgroundColor(null);
          }
        }

        if( ! flag ) {
          b.getDesktop().showErrorDialog(
            b.getWindow(),
            "Validation Error",
            "Required fields are marked read",
            new Status(IStatus.ERROR, Activator.PLUGIN_ID, ""),
            null );
        }

        return Status.OK_STATUS;
      }
    });
    window.open();
    window.setBounds(new Rectangle(500, 400, 400, 250));
  }

  public void stop() {
    // nothing to do
  }
}

This creates an UI like this:

Are you interested in SWT API for the Windows Ribbon Framework? If yes please raise your voice in bug 293637. It looks like the Ribbon can’t be used in the SDK or any other Eclipse project at the moment. However, it’s still unclear if it can be part of the SWT API.

We proudly present Riena 2.0 M5 – the first release in the 2.0 stream. As you can see by the long New & Noteworthy, we have been very active in last six weeks. Read on for my five favorite new things:

1. Pluggable Marker Decorations

The new BorderMarkerSupport draws red-borders around a widget and replaces the standard ControlDecoration. You can select either error decoration style via the Look-and-Feel settings.

2. Enhanced Master/Details Widget

The Master/Details Widget automatically links a table with the details area on the bottom (or top). It is used heavily by some of Riena’s consumers. As a result we have been receiving good feedback and have added several requested features on this milestone:

• nicer border (includes button area, separates table from buttons with a single line)
• API to participate in the life-cycle (before / after selection, apply, remove, new)
• API to ’suggest’ a new entry – it will show in the details area and Apply will enable
• API to tweak the margin and spacing of the Master/Details widget

3. Image Button Widget

The SWT Buttons have a system-defined look that is hard to customize (for example the background color cannot be changed). Riena’s ImageButton Widget emulates a button using three images (standard, hover, pushed state).

4. Multiple Default Buttons per Controller

Riena’s Controllers have a new API that supports several default buttons per controller. The default button has a blue glow when enabled. In that state it will automatically be pushed when the user hits ENTER (anywhere).

5. Controller Testing

Controller testing is now very straightforward and has been decoupled from the UI (widgets). Just subclass AbstractSubModuleControllerTest to get started. In addition your controller has to use the new API getRidget(Class, String) instead of getRidget(String). The package org.eclipse.riena.client.controller.test in the org.eclipse.riena.tests bundle has several examples.

Read the New & Noteworthy for additional details on these items.

Book: IBM Lotus Notes and Domino 8.5.1, The Upgraders Guide.

I will start by saying this book is a good resource for anyone wanting to know what features are in Lotus Notes and Domino 8.5.1.  The book pretty much covers most areas you would expect in Lotus Notes and is a great overall summary with many examples.  I really love the format of the book, it was very easy to follow, very well written, and easy to read.  I loved the appendix!  The different chapters about add-on products was a great benefit. There were at times I felt like I read some things in one chapter and almost the same thing in another chapter with little value added.  I really wish there was more around development techniques and best practices and in general I would have preferred a little more depth in some areas.  For instance, there was a lot of material about Composite Applications but most of the information was based on 8.0.x stuff.

There is also a free chapter you can preview: Chapter 8 – which is an extracted Chapter that anyone can check out here, it covers a lot of information and should be quite useful for developers.

Ok, here is my constructive feedback.  I will first say that the product documentation is something that needs to be addressed and I can see why many of these areas were not covered, but if you follow the yellowverse you will see the many blogs from IBMer’s, partners, and customers talking about these topics.  Since this is an “upgraders guide” it was difficult for me to figure out how hard I should judge on some of the areas.  The book clearly hits end user, admins, and developers so I took the liberty to just throw it all out there!

End user and Administrative areas:

Managed Settings – using Domino policies you can push down Eclipse plug-in preferences.  They definitely should have mentioned this or walked through the policy screen like they did the Widget policies.

LiveText, Toolbox, and Widgets – arguably one of the most popular areas of the 8.x release and I see a small mention of it in this book.  This probably deserves its own chapter considering the new options that were added in 8.5.1.  Creating your own recognizers is also a popular topic in the forums.

Serviceability - it would have been nice if the book included a chapter on serviceability.  For instance, what the directory structures are, where to find logs, how to look at and evaluate the output from the IBM support assistant.  In my experience this stuff is very valuable to companies and admins supporting a rich client.

Developer areas: being a developer myself I would have wanted to get some detailed information about the following areas.  It looks like the title of the book was changed from 8.5 to 8.5.1 because the developer chapter only talks about 8.5 and really the content is based on 8.0.  So I would update this chapter in a revision to include some of the 8.5.1 enhancements.

XPages - even though this could be an entire book on its own, I think it warranted at least its own chapter.  With the introduction to XPages on the client in 8.5.1 this should have been clearly highlighted! You will have to settle for the yellowverse, product documentation and the Designer Wiki.

Eclipse plug-in development – It would have been nice to have a chapter to primer the Eclipse/Java developers – or the want-to-be’s.  plugins, Java UI, extensions.  On Page 151, the screen shot not the CAE Palette in 8.5.1.  It looks like a palette from 8.0 with all of the views in the system loaded into it.

Composite applications – None of the following was mentioned in the book: Container framework, Containers (Document and View, HOD, Symphony, Web), NSF Update Site.NTF, Side bar control.  I recommend hitting the Composite Application Wiki, Lotus Expeditor Wiki, and Designer Wiki for these areas.

Lotus Symphony – even though Symphony could be its own book.  It would have been nice to see integration with Composite Applications or how to extend Symphony with Eclipse and the JUNO API’s.

Lotus Expeditor – it would have been nice if they mentioned how Portal can manage composite applications for role based application support and also explain the value-add over base Eclipse.

Lastly, for many of the areas I mention about Composite Applications you can get it from the CA Wiki: What’s new in Lotus Notes 8.5.1 & Expeditor 6.2.1.  The Domino Designer wiki is filled with XPage material – not too mention many of the business partner bloggers constantly write about XPages.

Also, this review and opinion is my own personal opinion and does not reflect the opinion of my employer or anyone else.

technorati tags: book, Domino, eclipse, lotus notes, review

Java/J2EE-Portalentwickler (m/w), Europa Capital Group GmbH, Düsseldorf: Europa Capital Group GmbH.

In der Cassandra-Mailingliste wurde vor kurzem über die Zukunft von Apache Cassandra abgestimmt. Das Cassandra-Projekt ist eine Art hybride, hoch skalierbare Open-Source-Datenbank, die von einem der Autoren des Dynamo-Papiers entworfen und …

As Jens mentioned in his recent blog post, parts of the Draw3D renderer have been rewritten in the past weeks. The initial motivation was to improve the visual rendering quality of 2D content (embedded GEF editors) and text, but during development it turned out that a lot of optimization would be necessary to keep the performance at acceptable levels. Eventually, I rewrote the renderer to take advantage of some advanced OpenGL features and now the performance is a lot better than it ever was.

In this blog post I will briefly explain how the 2D rendering system was redesigned over the course of GEF3D’s existence and how it was possible to achieve both a gain in the visual quality and the rendering performance at the same time.

First, let me introduce the initial 2D rendering system that Jens designed before I came on board. GEF uses an instance of the abstract class Graphics to draw all figures. Actually, figures draw themselves using their paint method whose only parameter is an instance of Graphics (this is defined in the IFigure interface). The Graphics class provides a lot of methods to draw graphical primitives like lines, rectangles, polygons and so forth, as well as methods to manage the state of a graphics object. Usually, GEF passes an instance of SWTGraphics to the root of the figure subtree that needs redrawing. SWTGraphics uses a graphics context to draw graphical primitives, and the graphics context usually draws directly onto some graphics resource like an image or a canvas.

So what Jens did when he wanted to allow 2D content in GEF3D was that he simply passed an instance of SWTGraphics to the 2D figures that rendered into an image in memory. This image was then transferred to the graphics card and used as a texture. This system was very simple and required hardly any additional coding at all. The problem with this approach however is that whenever the 2D content needed redrawing (after some model change for example), the entire image had to be redrawn and uploaded to the graphics card again, which is a very costly process. First, the image has to be converted into a ByteBuffer and that buffer must then be uploaded from system to video memory through the bus. For normal-sized image, this can take up to 500ms.

To alleviate this problem, I wrote another Graphics subclass that uses OpenGL to render the 2D primitives directly into a texture image in video memory. This eliminates the uploading step and thus improved performance considerably, especially the delay after any model change when the texture image had to be uploaded into video memory. But it did not help with the second major problem: It still used textures. The problem with using textures to display 2D content in 3D is that while the texture image may look sharp and very good by itself, it gets blurry and distorted when it is projected into 3D space due to all the filtering that has to take place. Especially images that contain text become very hard to read in this approach, as you can see in this screenshot:

Another approach to rendering 2D content in 3D is not to use textures at all, but to render all 2D primitives directly into 3D space in every frame (so far, only the texture had to be redrawn only after a model change occurred). This eliminates all problems related to texture filtering and blurring once and for all. Combined with vector fonts (to be described in another blog post), direct rendering results in the best possible visual quality. The problem is that everything needs to be rendered in every frame all the time. I quickly discovered that simply sending all geometry data to OpenGL in every frame (this is also called OpenGL immediate mode) would kill performance – even in small diagrams, navigation became sluggish.

Essentially, the FPS in GEF3D are limited not by the triangle throughput of the video card (how many triangles can be rendered per second?), but by the bus speed (how much data can we send to the video card in a second?). If you send all your geometry, color and texture data to the video card on every frame, your performance will be very bad because sending large amounts of data to the video card is very expensive. The more data you can store permanently in video memory, the better your performance will be (until you get limited by triangle throughput). So we had to find a way to store as much data as possible in video memory and just execute simple drawing instructions on every frame.

Of course, OpenGL provides several ways to do this. The first and oldest approach is to use display lists, which is basically a way to tell OpenGL to compile a number of instructions and data into a function that resides in video memory. It’s like a stored procedure that we can call every time we need some stuff rendered. The problem with display lists is that they are fine for small stuff like rendering a cube or something. 2D diagrams however consist of large amounts of arbitrary geometry, which cannot be compiled into display lists at all. So this approach was not useful for us.

The best way to store geometry data in video memory is called a vertex buffer object (VBO) in OpenGL. Essentially, a VBO is one (or more) buffer that contains vertices (and other data like colors and texture coordinates). These buffers only need to be uploaded into video memory once (or when some geometry changes) and can then be drawn by issuing as little as five commands in every frame. We decided to adopt this approach and try it for our 2D diagrams by storing the 2D primitives in vertex buffers in video memory. Rendering a 2D diagram would then be very fast and simple, because hardly any data must be sent to the video card per frame. This is how the pros do it, so it should work for us too!

In theory, that is correct. But in practice, it is very hard to actually create a vertex buffer out of the 2D content of a 2D diagram. Since a vertex buffer can only contain a series of graphical primitives (triangles, quadrilaterals, lines) of the same type and the primitives that make up the 2D diagram are drawn in random order, the primitives need to be sorted properly so that we can create large vertex buffers from them. Unfortunately, the primitives cannot simply be sorted by their type and then converted into vertex buffers because there are dependencies between such primitives that intersect. To cut a long story short, I had to think of a way to sort primitives into disjunct sets. Each set contains only primitives of the same type and each set should be maximal so that you end up with a small number of large buffers because that’s how you achieve maximum performance.

The end result is impressive: We used to have performance problems with diagrams that contain more than 2000 2D nodes, and now we can display 4000 2D nodes at 120 FPS, and all that with much better visual quality. To get an idea of how much better the quality of the 2D diagrams is in this version, check out the following screenshot:

Pen-based/Tablet technology it’s been around for a long time, but recently this ‘touch-oriented interaction’ has been gaining more attention, with all the buzz around iPad. So if we’re starting to interact to devices with our hands, we are not clicking anymore — perhaps our interfaces should start to be less click-oriented? How can we take advantage of the popularity of those devices? Wouldn’t be nice if we had sketching recognition withing Eclipse?

I think so, I’ve been working on sketch recognition for GEF/GMF editors while creating the MoLIC editor, take a look:

Sketch API (former OmniModeling) on MoLIC Editor from Ugo Sangiorgi on Vimeo.

There are other posts on this blog reporting the evolution until this point — the API is able to recognize shapes the way you draw, learning withing the process if it cant recognize it upfront. It can recognize any shape, really, you will ‘teach’ it how.

Omnimodeling: Multi-Agent Recognition from Ugo Sangiorgi on Vimeo.

So it’s on! I decided to contribute to Eclipse by proposing a Sketch API for GEF/GMF using the former OmniModeling project base, take a look at the proposal we are working on. Mariot Chauvin and Chris Aniszczyk are helping me through, thank you so much guys!

Comments and contributions are welcome

I should acknowledge Simone D.J. Barbosa for the kind support during the OmniModeling project, as well as my colleagues at the Semiotic Engineering Group of PUCRio.

Last week the Eclipse Foundation published the proposal for the Remus project. In the following I will show you what the goals of the project are and how simple it is to build Eclipse based applications with this technology. We highly appreciate your feedback, suggestions, discussion at the Eclipse Community forums, see http://www.eclipse.org/forums/index.php?t=thread&frm_id=166

The goals of this project can be divided into two big parts:

1. Provide an out-of-the box set of bundles that can be installed into an Eclipse instance, for example your IDE, for daily information management. This tooling will be also available as standalone RCP application. There is already a build of a full-blown application built on Remus available, see http://www.remus-software.org.
2. The probably more relevant part is that we want to provide a framework and several APIs for building applications for viewing, editing, catgorizing, searching and synchronizing any datastructures. I’ll show you an example how to build your Hello-Remus bundle in just a few minutes.

The approach

The theoretical apporoach is that we assume that every unit of information can be described with a structure-definition. This definition holds the definition how a specific type of information is organized internally. Based on a structure-definition Remus can create business objects a navigatable information-structure, editing-ui and even a rule engine for manipulating these objects. Every structure-definition is typed, that means it can handled by the framework regarding visualization, indexing or synchronization in a different way.

Example

Ok, we’ve had enough of words, let’s start. Our “Hello World” application will be a RCP application for one single information type: A book review.

Step 1 – Creating the plugin and a structure definition.

We create a bundle using the plugin-wizard for a RCP with a single view. After the bundle was created we define our structure definition. This definition is done by a tree-based editor, but since the underlying technology is emf you can use alternative editing methods, for example with textual plugins like Xtext. A review has the following information-items

1. Title of the Review
2. Date
3. Author
4. Reviewed book
5. Review

We can create now this structure definition (see picture)

Step 2 – Navigation and first start

The first thing we have to do is to tell Remus about this new information type. We create a new extension, defining name and type of this information and point to the structure definition. Thats all for the moment. After that definition we already can add, edit and save information units. These operations are executed by default on a command-stack and can be un- or redone. The underlying data store mechanisms need no customization.

With a few lines you can create your first business objects:

As you can see we aquire an instance of a manager for setting values to an information unit. This manager checks our inputs against the underlying structure definition of this information type. A the end you’ll see that we generate a command and execute it. This command is checked for correctness and is executed on a command stack.

If we start now our RCP application we will see already a good result:

Step 3 – Editor

Remus provides some editor infrastructure to visualize and edit the given information unit. Note that these editors have already the basic functionalitites you know from other applications, like automatic refresh, close, undo-redo,…
Remus has no API for building UI elements you can use your preferred toolkit, but comes with a very handy API for binding UI elements to structure items defined by your information type. Editors are injected by a separate extension-point. For making an information type editable with an editor you have to extend 1 class and overwrite 2 methods (one for generating the ui and one for binding the ui-elements)

Due to the separation between the definition of ui elements and the binding to information structure elements you can use also third-party-tools like SWT designer.

The binding is very easy. You just have to bind a ui control to a structure element of your information type, a 2-liner:

After defining this editor you can now open this information unit from your navigation. As you can see in the screenshot the editor becomes dirty after an edit.

In addition Remus provides some additional API to forward the data of a information unit to a HTML Template Engine for pretty information visualization (if you want to browse through the data, complex forms are not appreciated) and to integrate the HTML Output into an editor.

Step 4 – Search

Integrating a search is also very easy. In general you only have to include the relevant bundles and Remus tries to index your information unit. By defining another extension point you can tell Remus which structure items need to be indexed. If you like you can use the default search view which is shipped with the framework. Also the result listing can be reused (if you like). If you use the search bundles you autmatically get a search history, a search for references, a search context with key bindings to navigate through results, …

By adding the search view to your perspective layout, you see the Search-View

Conclusion

Of course there are many other things you can use, for example linking between information units, support for files, integration of third-party-editors, data-encryption, semantical structures, synchronization with remote information pools,… I’ll post some documentation soon.

The components of Remus can be used to build RCP applications, Eclipse plugins, RAP applications or even a headless information repository running on a server for information distribution. We also provide an ODA Driver to query information structures with the Eclipse Data Tools Platform; this makes especially the BIRT integration very easy.

We are currently in the proposal phase of the Eclipse Development process and need your feedback. If you have questions about features, architecture, use cases, etc don’t hestitate to post your thoughts at the Newsgroup or the Eclipse Community Forums; and if you want to see what we’ve already done with this framework take a look at http://remus-software.org, the projects current home. We’re looking forward hearing from you.

I’m happy to announce that Pascal Rapicault, lead of the Equinox p2 team, is going to be joining Sonatype.   As lead of p2, Pascal’s work has helped define the way that components are designed, developed, and deployed within the Eclipse framework.  I’m confident that his work is going to be an essential part of what allows Sonatype to create some of the Next Generation development infrastructure I’ve been describing over the past few weeks.

Here’s an excerpt from Pascal’s blog announcing his arrival at Sonatype:

I’m very excited about the opportunity to join Sonatype because they have an exciting portfolio of products and a commitment to open source (Maven, m2eclipse, …). Therefore I will continue to be heavily involved in the Eclipse community and provide leadership for the p2 project. I look forward to being a part of the Eclipse team from a new perspective and have no doubt that I will run into other members of the Eclipse team in the future.

We’re happy to have him on board, and you can look forward to see his work and his writing on this blog in the months to come.

At the end of the week I will be leaving IBM / OTI. I have truly been honored to be part of the Eclipse Platform team and through this experience redefine the IDE, deliver RCP, shape up Java componentry and perform many other stunts. It has been 7 fantastic years.As hard as it is to leave, I’m very excited about the opportunity to join Sonatype [1] because they have an exciting portfolio of

Habe soeben den Java Framework TWNcidSchnittstelle für NCID Server freigegeben. Die Javadoc liegt hier.