PlanetJava

OSDir.com - Java: Java VM on way for the iPhone

Thu, 29 Jul 2010 22:01:14 +0000

From the JPhone dept.:

Sun Microsystems is developing a Java Virtual Machine for Apple's iPhone and plans to release the JVM some time after June, enabling Java applications to run on the popular mobile device.

OSDir.com - Java: Java for Mac OS X 10.4, Release 6

Thu, 29 Jul 2010 22:01:14 +0000

From the Fresh Brew dept.:

Time to fire up the 'ole Software Update as Apple has just released a Java update for Mac OS X. This update will fix vulnerabilities in both server and client versions of 10.4. Apple explains that, 'A malicious webpage can remove or insert items in the keychain,' which sure doesn't sound good to us.

OSDir.com - Java: Java 6 Available on OSX

Thu, 29 Jul 2010 22:01:14 +0000

From the Fresh Brew dept.:

Many Mac users have been upset that Apple has not made Java 6 available on the platform. Landon Fuller posts that there is a developer preview release available of Java JDK6 on Mac OSX, Tiger and Leopard. It is based on the BSD port of Sun's Java 6 and is made available under the Java Research License.

OSDir.com - Java: Oracle's big bear hug for Java bodes really well

Thu, 29 Jul 2010 22:01:14 +0000

From the R&D&J dept.:

..."I don't think it's essential that we find a way to make money from [specific Sun] components," Ellison said Wednesday. "We have the money to invest in Java, because Java is a very profitable business for us already. Exactly where additional revenues will come from is less important than simply growing our middleware installed base."

To achieve that growth, Oracle plans to invest $4.3 billion on R&D in the coming year, according to Oracle president Charles Phillips. That's up from $2.8 billion last year -- so you can bet some of that cash will be heading Java's way soon.

OSDir.com - Java: Red Hat CEO Calls on Oracle to Keep Java Open

Thu, 29 Jul 2010 22:01:14 +0000

From the Recipes dept.:

With Oracle set to acquire Sun and gain stewardship over Java, there are many in the tech world with an opinion on how the database giant should handle its new relationship with the programming language.

One of those opinions is being voiced by Red Hat CEO Jim Whitehurst, who is calling on Oracle to keep Java open. During a conference call yesterday to discuss Red Hat's first-quarter fiscal 2010 results, Whitehurst also took aim at Oracle's operating system business.

OSDir.com - Java: Java for Mac OS X 10.5 Update 2

Thu, 29 Jul 2010 22:01:14 +0000

From the Light Lunch dept.:

Apple has just released Java Update 2 for Mac OS X. According to Apple, this update "delivers improved reliability and compatibility for Java SE 6, J2SE 5.0 and J2SE 1.4.2 on Mac OS X 10.5.4 and later."

OSDir.com - Java: Java is finally Free and Open

Thu, 29 Jul 2010 22:01:14 +0000

From the Journey of 1000 Miles... dept.:

...This week the IcedTea Project reached an important milestone - The latest OpenJDK binary included in Fedora 9 (x86 and x86_64) passes the rigorous Java Test Compatibility Kit (TCK). This means that it provides all the required Java APIs and behaves like any other Java SE 6 implementation - in keeping with the portability goal of the Java platform. As of writing, Fedora 9 is the only operating system to include a free and open Java SE 6 implementation that has passed the Java TCK. All of the code that makes this possible has been made available to the IcedTea project so everyone can benefit from the work.

The Java TCK is a complex suite of tools and documentation that verifies that Java implementations conform to the Java specification. It consists of more than 80,000 tests and over 1 million lines of code.

OSDir.com - Java: How to rescue Java from the men in suits

Thu, 29 Jul 2010 22:01:14 +0000

From the Suits Still Control Java dept.:

Members of a JavaOne panel on the JCP, open source and standards have expressed their frustrations with a process they believe puts corporate interests first when it comes to Java. For once, it wasn't just Spring Framework creator and evangelist Rod Johnson calling for change.

Joining him was Sun Microsystems' own, recently recruited, "free and open source software ambassador" Dalibor Topic and representatives from one of the industry's newest Java user group - the Paris JUG - plus one of the largest - Brazil's SouJava. Brazil is a country Sun repeatedly champions when discussing uptake of Java and open source.

OSDir.com - Java: Java SE 6 For Mac OS X

Thu, 29 Jul 2010 22:01:14 +0000

From the 6 dept.:

After a long delay, Apple has finally released a version of Java 6 for OS X. 64-bit Intel Macs are starting to see this pushed out via Software Update...

OSDir.com - Java: Sun looks to free up the rest of Java (again)

Thu, 29 Jul 2010 22:01:14 +0000

From the Buffering.... dept.:

Sun Microsystems is stepping up efforts to boost Java usage in Linux shops by working to remove some final encumbrances in the open-source Java platform.

..."We're hoping to see some movement [with the] Linux distributions in the very near future, hopefully by JavaOne," said Rich Sands, group manager for developer marketing at Sun, in an interview on Tuesday. The JavaOne conference is to be held in San Francisco in two weeks.

alphaWorks-Java: Web Services Validation Tool for WSDL and SOAP

Thu, 29 Jul 2010 22:01:03 +0000

An analysis tool for Web services artifacts, including WSDL and SOAP messages. (UPD: 09/17/2009 in java)

alphaWorks-Java: Web Service Engine for Accelerating SOA System Development

Thu, 29 Jul 2010 22:01:03 +0000

A toolkit that can transform schemas to any desired schema type; drive and stub enterprise applications; facilitate generation of highly customized data files; and reverse-engineer legacy data files. (UPD: 11/05/2009 in java)

alphaWorks-Java: Multicore Software Development Kit

Thu, 29 Jul 2010 22:01:03 +0000

A set of tools to test, debug and analyze applications targeted for multicore hardware systems. (UPD: 09/30/2009 in java)

alphaWorks-Java: IBM Thread and Monitor Dump Analyzer for Java

Thu, 29 Jul 2010 22:01:03 +0000

A tool that allows identification of hangs, deadlocks, resource contention, and bottlenecks in Java threads. (UPD: 09/30/2009 in java)

alphaWorks-Java: HeapAnalyzer

Thu, 29 Jul 2010 22:01:03 +0000

A graphical tool for discovering possible Java heap leaks. (UPD: 09/29/2009 in java)

alphaWorks-Java: GAIAN Database

Thu, 29 Jul 2010 22:01:03 +0000

A distributed federated database using a biologically inspired self-organization principle to minimize management. (UPD: 09/18/2009 in java)

alphaWorks-Java: Visual Performance Analyzer

Thu, 29 Jul 2010 22:01:02 +0000

An Eclipse-based visual performance toolkit. (UPD: 11/27/2009 in java)

alphaWorks-Java: Processor Time Analysis Tool for Linux

Thu, 29 Jul 2010 22:01:02 +0000

A tool to detect Java threads that consume most of the processor resources on Linux. (NEW: 06/17/2009 in java)

alphaWorks-Java: Policy Design Tool

Thu, 29 Jul 2010 22:01:02 +0000

A development tool to model and analyze high-level security requirements and create template policies for access control (NEW: 02/04/2009 in java)

alphaWorks-Java: IBM Real Time Application Execution Optimizer for Java

Thu, 29 Jul 2010 22:01:02 +0000

A tool that operates on compiled Java applications to optimize and verify application deployment in specialized environments. (NEW: 05/20/2009 in java)

alphaWorks-Java: FoCuS

Thu, 29 Jul 2010 22:01:02 +0000

A tool that implements the functional coverage methodology, providing detailed coverage information and improving testing. (UPD: 11/06/2009 in java)

alphaWorks-Java: Policy-Driven File Encryption Explorer Based on OpenPGP for Secure Storage Solutions

Thu, 29 Jul 2010 22:01:02 +0000

A tool to help secure data at rest as well as data in flight, through a user-friendly explorer GUI, with enhanced policy support for file classification based on attributes and content semantics. (NEW: 04/08/2009 in java)

alphaWorks-Java: Common Toolkit for CIM Extrinsic Method Calling

Thu, 29 Jul 2010 22:01:02 +0000

A Java-based toolkit that dramatically simplifies Common Interface Model (CIM) calling. (NEW: 03/31/2009 in java)

alphaWorks-Java: Programming Mapping Tool for CIM to Java

Thu, 29 Jul 2010 22:01:02 +0000

A tool capable of mapping all the CIM objects to their equivalent Java objects using Java source code based on the CIM Class definitions. (NEW: 10/16/2008 in java)

Javable: Java SE 6 Performance White Paper

Thu, 29 Jul 2010 22:01:00 +0000

Java SE 6 Performance White Paper includes detailed

Javable: Google Android SDK is available

Thu, 29 Jul 2010 22:01:00 +0000

The development kit and API for Google mobile platform, Android, has been released.

Javable: Sun phases out mobile Java

Thu, 29 Jul 2010 22:01:00 +0000

Sun will gradually phase out mobile Java (Java Micro Edition) and move respective services to Standard Edition. "We're trying to converge

Javable: Consumer JRE Early Access

Thu, 29 Jul 2010 22:01:00 +0000

Sun has started an early access program to Java SE 6 Update N (formerly known as the "Consumer

Javable: YourKit Java Profiler 7.0 released

Thu, 29 Jul 2010 22:01:00 +0000

The major update to YourKit Java Profiler has been released. Version 7.0 includes

Javable: JUG.RU meeting

Thu, 29 Jul 2010 22:00:59 +0000

JUG.RU will held a scheduled meeting on Feb 23d. Read on for details.

Javable: Happy New Year!

Thu, 29 Jul 2010 22:00:59 +0000

We wish a Happy New Year to all our readers and contributers. Hope to see you all in 2008.

Javable: Ruby on Rails 2.0 released

Thu, 29 Jul 2010 22:00:59 +0000

Ruby on Rails 2.0 has been released. "Rails 2.0 is finally finished

Javable: NetBeans 6.0 released

Thu, 29 Jul 2010 22:00:59 +0000

New version of pure Java IDE has been released, with support for many new

Javable: JUG.RU meeting on November 24th

Thu, 29 Jul 2010 22:00:59 +0000

JUG.RU will be hosting its meeting in Saint Petersburg, Russia, on November 24th. More details in our

The Aquarium: GlassFish Patches now at Oracle Support

Thu, 29 Jul 2010 17:47:07 +0000

SunSolve was, and still is, Sun's way of distributing patches; the equivalent mechanism at Oracle is My Oracle Support (MOS), and Gerry just announced thatSun patches now available there. This includes the GlassFish commercial patches like 128640-20, which is one of the patches in GlassFish 2.1.1 patch 6.

I just looked directly for the patch ID (using Sun's patch number), I'll try to dig more info on how to use MOS and will post it later on.

Java.net Weblogs: JVM Summit'10

Thu, 29 Jul 2010 16:16:17 +0000

The JVM Summit'10 is finished !

As last year and the year before it was fun, amazing and mind blowing to discuss and share ideas with brilliant people of the Java & JVM community.

If you want a fast forward glimpse of the state of the JVM languages future presentations are available on the wiki:

http://wiki.jvmlangsummit.com/Main_Page

cheers,

Rémi

Attachment	Size
800px-Rose-iphone-IMG_0023.jpg	46.11 KB

Planet Eclipse: Jeff, Paul & Simon: Chapter 20 errata

Thu, 29 Jul 2010 15:54:39 +0000

Page 348 — The steps in section 20.3.1 suggest that you should use the Target Platform Export wizard to get the base set of bundles against which you can build your system. It turns out that that wizard is only available in Eclipse 3.6 (Helios) and later. To date we have been unable to back port that function to Eclipse 3.5.2 (Galileo). To work around this, you can either

Start a plain Eclipse 3.6 on your OSGi and Equinox samples workspace, export the target as described and then switch back to using Eclipse 3.5.2 with the Samples Manager installed
Install the Samples Manager into Eclipse 3.6 and work from there.

Note that if you choose the latter approach there may be some minor issues as the book samples and workflows have been tested most rigorously with Eclipse 3.5.2.

InfoQ: Leverage Points: places to intervene in a system

Thu, 29 Jul 2010 13:56:00 +0000

A key decision for software architects involves where and how to introduce change into a system in order to effect a desired change. Leverage points are those places where micro changes can result in macro results. Twelve categories of leverage point are identified along with concerns about the changes. By Dave West

Planet Eclipse: Denis Roy: Winner of the WTF/loc award

Thu, 29 Jul 2010 13:20:06 +0000

To gauge the quality of code, we’ve all seen the metric called WTF/minute.

I’m inventing a new metric, called the WTF/loc, based on this very short snippet of code.

#!/usr/bin/perl
use strict;
my $cmd = "perl " . shift;

my $h = <STDIN>;
while ($_ = <STDIN>) {
        open (S, "| $cmd");
        print S $h;
        print S;
        for (2..1000) {
                last unless $_ = <>;
                print S;
        }
}

A few comments to explain what’s going on would have made this snippet of code much more maintainable.

Planet Eclipse: David Green: Testing REST Web Services with JPA and Spring

noreply@blogger.com (David Green) — Thu, 29 Jul 2010 13:16:13 +0000

REST Web Services can be particularly difficult to test, with the need for networking, a web container, multiple threads and transaction management creating extra complexity beyond your standard unit test. In this article I demonstrate patterns designed to address this complexity while enabling complete testing of your REST web service stack.

The ideal web service unit test will use the same principles discussed in my previous article:

clean database with mocked data so that we can reliably test specific scenarios
rollback to avoid side-effects after our test
in-memory database so that no environment setup is required

In addition, we’ll need to run a web container for our unit test. To maintain a zero-setup test environment, we’ll have our unit test start a web container for the purpose of running our web service. By having each test start and stop the web container, tests become very simple to run and we’re guaranteed that our tests will have a clean environment with no external dependencies.

Web Container

Normally starting a web container is difficult to do in a unit test, and container startup time can be a problem — however with the right choice of web container we can overcome these problems. Winstone is a small, fast web container that is designed to be embedded in Java programs. By using Winstone, we’ll be able to start and stop the web container as part of our unit test setup and tear-down with relative ease.

Starting Winstone is as simple as this:

 Map args = new HashMap();

 args.put("webroot", pathToWebRoot);

 args.put("httpPort", String.valueOf(port));

 Launcher.initLogger(args);



 // start winstone

 winstoneLauncher = new Launcher(args);

Winstone only takes a couple of seconds to start up. Shutting it down is as simple as this:

 if (winstoneLauncher.isRunning()) {

  winstoneLauncher.shutdown();

 }

To hide the details of winstone from our unit tests, we can create a class WebApplicationContainer, which is responsible for starting choosing a port, starting/stopping Winstone, and providing a base URL for our tests:

public class WebApplicationContainer {



 private static final Random random = new Random(System.currentTimeMillis());



 private Launcher winstoneLauncher;



 private File webRoot;



 private int port;

 

 /**

  * start the webserver, guarantees that the webserver is started upon return.

  * @see #stop()

  */

 @SuppressWarnings({ "unchecked", "rawtypes" })

 public void start() {

  if (winstoneLauncher != null) {

   throw new IllegalStateException("already started");

  }

  port = findAvailablePort();

  

  

  Logger log = Logger.getLogger(WebApplicationContainer.class.getName());

  log.fine("Starting web container on "+getBaseUrl());

  

  Map args = new HashMap();

  try {

   args.put("ajp13Port", "-1");

   args.put("useJasper", "false");

   args.put("webroot", webRoot.getAbsolutePath());

   args.put("httpPort", String.valueOf(port));

   Launcher.initLogger(args);



   // start winstone

   winstoneLauncher = new Launcher(args);



   // wait for Winstone to finish starting up

   // we do that by attempting to connect via socket

   final int maxRetries = 150;

   for (int x = 0; x < maxRetries; ++x) {

    if (testForSuccessfulStartup()) {

     break;

    }

    if (x == maxRetries - 1) {

     throw new IllegalStateException(

      String.format("Connection to localhost:%s failed."+

       "  Did the web container start up successfully?"));

    }

    // wait and then try again

    Thread.sleep(100L);

   }

   Logger.getLogger(WebApplicationContainer.class.getName()).

    info("Started web container at "+getBaseUrl());

  } catch (Exception e) {

   throw new IllegalStateException(e);

  }

 }



 private int findAvailablePort() {

  ...

 }

 

 private boolean testForSuccessfulStartup() {

  // test to see if the web container is listening on the address/port combo

  try {

   Socket socket = SocketFactory.getDefault().createSocket("localhost", port);

   socket.close();

   return true;

  } catch (UnknownHostException e) {

   throw new IllegalStateException(e);

  } catch (IOException e) {

   return false;

  }

 }



 /**

  * stop the web container

  * @see #start()

  */

 public void stop() {

  if (winstoneLauncher == null) {

   throw new IllegalStateException();

  }

  

  winstoneLauncher.shutdown();

  winstoneLauncher = null;

 }



 public String getBaseUrl() {

  return String.format("http://localhost:%s/", port);

 }

 ...

}

REST Service Unit Test

A complete test for our web service ends up looking like this:

@RunWith(SpringJUnit4ClassRunner.class)

@Transactional

public class BlogServiceClientTest extends BlogServiceTest {

 @Autowired

 private BlogServiceClient blogServiceClient;



 @Autowired

 private WebApplicationContainer webContainer;



 @Before

 public void before() {

  webContainer.setWebRoot(computeWebRoot());

  webContainer.start();



  blogServiceClient.setBaseUrl(webContainer.getBaseUrl()+"api");

  // use the client instead of the service directly

  service = blogServiceClient;

 }



 @After

 public void after() {

  if (webContainer.isStarted()) {

   webContainer.stop();

  }

 }

}

You might be thinking "where are the @Test methods?". The beauty of our web service test is that it extends our service test: all of the test methods we were running before using direct method calls are now also run over our web service protocol. By using inheritance, other than setup of our web service there’s nothing else to do. In other words, our service tests are run twice: once using Java method calls, and again over-the-wire using our web service. This ensures that we see consistent behaviour in both modes of execution.

BlogServiceClient is an implementation of BlogService (our service interface under test) based on Spring’s RestTemplate. It’s a REST client for our service, implementing the same Java interface as our server-side service. This enables us to substitute the REST client service implementation in our test.

Transaction Management and JPA

Now that we’re able to start our web service and run tests we’re done, right? Not quite: we still need to manage transactions and our test data. This is somewhat more complicated with our web service: recall that we want our unit test to have the following qualities:

clean database on startup
run in a transaction that rolls back after the test
mocks all of its own data

Employing the techniques we’ve already established in Patterns for Better Unit Testing with JPA helps, but is not quite enough.

Our service implementation is running in a web container. The web container services incoming HTTP requests with threads in a thread pool. Our service is pretty much guaranteed to be running on a distinct thread, not the same thread as that running our unit test method. As a result our service bean will be running in it’s own transaction context. There are two problems that arise from this:

our service won’t be able to see the data we’ve mocked up in our test
our service method will commit its transaction

Both of these things are undesirable. To overcome this problem we’ll apply a little trickery: we’ll provide an entity manager that is shared by both the test thread and the web container thread servicing our HTTP requests, and we’ll prevent any commit or rollback from occurring on that entity manager while it’s in use in a unit test. We do this by wrapping the entity manager factory in our test environment:

<bean class="greensopinion.restexample.test.jpa.TestEntityManagerFactory" 

 id="blogDomain">

 <property name="delegate">

  <bean

   class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">

   <property name="dataSource" ref="dataSource" />

   <property name="persistenceXmlLocation" 

    value="classpath*:/persistence-test.xml"/>

  </bean>

 </property>

</bean>

Our TestEntityManagerFactory employs the standard delegate pattern, with the exception that it changes the default behaviour of createEntityManager():

 public EntityManager createEntityManager() {

  if (theEntityManager == null) {

   theEntityManager = delegate.createEntityManager();

  }

  return new TestEntityManager(theEntityManager);

 }

It creates and returns a singleton entity manager instance. This allows us to share a single entity manager between our unit test and the web container. We also wrap the entity manager so that we can control it’s lifecycle (we prevent close()) and that of it’s transaction (we prevent commit() and rollback()).

While we know that the EntityManager is not thread safe, it’s okay to share it between threads providing that no two threads access it at the same time. Since our REST client will block on any calls to the server, we’re not at risk of concurrent access.

Source Code

Complete, working source code demonstrating these patterns and others is available on GitHub:

http://github.com/dgreen99/greensopinion.restexample

The source contains two Eclipse projects: one for the web application, and one for unit tests. The unit tests all run and pass, and the web application can be started and deployed with a MySQL database.

Service Patterns

The service is split into the following:

Service interface – defines the service contract
Service bean – implements the service over JPA
Service controller – exposes the service using Spring REST
Service client – implements client end of the REST service, used in our tests

This gives us a good separation of concerns, and client code need not always know if it’s calling an in-process or out-of-process service.

JPA domain objects are exposed by the service interface. This helps in a few ways:

The service is usable in other parts of the application that deal with the domain
It helps to reduce the amount of code that must be written

However it has drawbacks:

It exposes the design of our domain, limiting our ability to change it in the future
Changes to the domain may inadvertently break the service interface for third-party clients
The service controller must be careful to expose shallow copies of our domain objects

This approach may be feasible for some projects. It’s common to see transfer objects as well, which allows a service to be explicit about it’s data model without exposing the domain implementation details.

Missing Functionality

Notably this sample code is missing two crucial aspects of a normal web application:

Exception handling should be built-in to our service controller so that errors can be propagated gracefully.
Data validation is not performed by the service bean.

These aspects of the sample application are left unimplemented.

Summary

Testing REST web services can be easy by following the following patterns:

implement a web service client to exercise your service from unit tests
run the web service in your tests with a lightweight embedded web container
share the entity manager and transaction context between the service and test

By applying these straight-forward techniques it’s possible to overcome the complexity inherent in testing a web service, enabling better coverage and higher quality applications.

References

Technologies used in this project:

REST services are implemented using Spring REST and Jackson
EclipseLink is used as a JPA provider
JUnit is used for unit tests
Hypersonic is used for an in-memory database
Winstone is used for an embedded web container

Planet Eclipse: Ian Skerrett: Oracle Demostrates Great Community Support and Fixes Eclipse

Thu, 29 Jul 2010 12:44:48 +0000

Every once in a while I am reminded of the lunacy of the Internet, especially headline writers. On Monday of this week, Oracle released an update to the Java 1.6 update 21 that fixes a problem in a previous version that broke Eclipse. All the details can be found in the bug or Neil’s good summary. The good news is that Eclipse is no longer broken!!

The irony however is that the issue just yesterday shows up on Ed Burnette’s ZDNet blog ‘Oracle Rebrands Java, breaks Eclipse‘ and the pillar of all Internet lunacy, slashdot Oracle Java Company Change Beaks Eclipse . Credit to Ed for actually reporting and testing the fix. However, the slashdot posting is the following:

crabel writes “In Java 1.6.0_21, the company field was changed from ‘Sun Microsystems, Inc’ to ‘Oracle.’ Apparently not the best idea, because some applications depend on that field to identify the virtual machine. All Eclipse versions since 3.3 (released 2007) until and including the recent Helios release (2010) have been reported to crash with an OutOfMemoryError due to this change. This is particularly funny since the update is deployed through automatic update and suddenly applications cease to work.

No mention the problem has been fixed and wrong on the fact the update was deployed through automatic update; update 21 hadn’t been pushed out yet via automatic update. Of course the typical slashdot comment ensued, granted some of the comments do point out the reality. However, as with anything on slashdot, people repeat the headline “Oracle’s Java Company Change Breaks Eclipse” on things like twitter, so the meme continues. Let me be clear, the problem is fixed: Oracle Demonstrates Great Community Support and Fixes Eclipse

Eric has already praised Oracle’s response to the situation. I would like to add my thanks to Oracle for quickly resolving the issue. I spoke to Oracle about the issue and I can tell you they had already decided to fix it before I spoke with them. Oracle should be applauded for their response to the bug. This type of bug could have easily lead to lots of finger pointing but Oracle just did the right thing for the community. THANK YOU

Planet Eclipse: Torkild Ulvøy Resheim: Decorating icons with status indicators

noreply@blogger.com (Torkild U. Resheim) — Thu, 29 Jul 2010 09:25:20 +0000

I tend to use IStatus whenever I can to indicate the status of some object. This have two severity states which are worth extra attention; ERROR and WARNING. Usually this object also have a graphical presentation, an icon. So would it not be nice to decorate this icon with an overlay image representing the severity of the status?

JFace's DecorationOverlayIcon comes to help. I usually use it like this:

private  static  final  Point size  = new  Point(16, 16);
private  Image getDecoratedImage(ImageRegistry registry, String baseImageId, 
  IStatus status){ 

  ImageDescriptor overlay = null;
  Image baseImage = registry.get(baseImageId);
  switch (status.getSeverity()) {
  case IStatus.ERROR:
   overlay = PlatformUI.getWorkbench().getSharedImages()
     .getImageDescriptor(ISharedImages.IMG_DEC_FIELD_ERROR);
   break;
  case IStatus.WARNING:
   overlay = PlatformUI.getWorkbench().getSharedImages()
     .getImageDescriptor(ISharedImages.IMG_DEC_FIELD_WARNING);
   break;
  default:
   return baseImage;
  }
  // Construct a new image identifier
  String decoratedImageId = baseImageId.concat(String.valueOf(status
    .getSeverity()));
  // Return the stored image if we have one
  if (registry.get(decoratedImageId) == null) {
   // Otherwise create a new image and store it
   DecorationOverlayIcon decoratedImage = new DecorationOverlayIcon(
     baseImage, new ImageDescriptor[] { null, null, null,
       overlay, null }, size) {
   };
   registry.put(decoratedImageId, decoratedImage);
  }
  return registry.get(decoratedImageId);
}

Since images are system resources we must take care to release these when we no longer need them. So I'm using the image registry of the base image to store the decorated image. This will make the process a little bit faster when the same decorated image is needed again and it will also make sure that the resources are released when then system shuts down.

Planet Eclipse: Eclipse Riena: SWT/Qt as alpha download

Thu, 29 Jul 2010 08:41:11 +0000

We are proud to make the first development version of the SWT/Qt platform available.

If you want to follow the progress of the code donation to the Eclipse Foundation you can track these bugs, CQ (link) and dicussion (link).

Please keep in mind this is a development version. All the core and custom widgets should work. However, it is not feature complete and it may be slow. Some things that are missing or incomplete are: StyledText, drag and drop, browser support, program start (launch external programs).

We provide binary bundles for the following OS:

Windows 32bit, XP and above
Linux 64bit
Mac OSX 32bit

We tested it with the following eclipse packages (Galileo SR2):

Windows 32bit (download)
Linux 64bit (download)
Mac OSX 32bit (download)

You need the SWT bundle (download) and one of the platform specific bundles (includes Qt):

Windows 32bit (download)
Linux 64bit (download)
Max OSX 32bit (download)

For installation, simply replace the SWT bundles in your “eclipse/plugin/” folder with the ones you downloaded from us.

Due to a bug you have to start eclipse with the “-noSplash” parameter:

% eclipse -noSplash

To test the styling capabilities, and we are sure you want to, download the AdvancedStyler plugin (download) and place it in your “eclipse/dropins/” folder (restart required). It will help you playing with the amazing Qt styling. We included some examples for an easy start.

For more information look at the Qt Style Sheet documentation found here.

To launch the AdvanedStyler hit the little paint icon in the toolbar and a dialog will pop up where you can change the styling on the fly.

The AdvancedStyler dialog looks like this

Hitting “Reset” brings you back the default style. “Update” applies the current style to your SWT application.

We would like to know what you are thinking, so please leave a comment. We are also very interessted in how you would use the new possibilities to style an application. So please feel free to post or send us screenshots.

Happy styling …

UPDATE:

Updated the “Advanced Style” plugin. Now with menu item under “Edit”. (download v0.2.1)

Planet Eclipse: Neil Bartlett: The Eclipse/Java 6u21 Blame Game

Thu, 29 Jul 2010 07:00:00 +0000

Ed Burnette published an informative article on ZDNet about the recent incompatibility problem with Eclipse and Java 6 update 21. Unfortunately the comments contain a lot of nasty accusations and finger-pointing, with people variously blaming Oracle or Eclipse or both for the mess… and even Ed’s article title seems a trifle unfair on Oracle.

To address those who accuse Eclipse of inappropriately using an internal variable, consider for a moment why this was done. Here are the facts:

The Sun JVM as shipped does not allow enough PermGen memory for a large application such as Eclipse to run. Incidentally many server applications also need more PermGen than is available by default.
There is no standard option to expand the PermGen. The option on the Sun JVM is -XX:MaxPermSize but the “XX” part indicates this option is specific only to the Sun JVM and is not available on other JVMs such as JRockit, IBM J9 etc. In fact using it with those JVMs can cause them to simply emit an error and exit.
Therefore Eclipse needs to detect whether it is on the Sun JVM specifically before it adds the -XX:MaxPermSize option. This cannot be done in Java because by the time the JVM has started it is too late, so it has to be done in the native launcher executable, i.e. eclipse.exe, which is coded in C. At this point the Java system properties are not yet available, but the properties in the exe/dll file are visible.

So I don’t think Eclipse has done anything particularly wrong here. Neither has Oracle, there was no reasonable way for them to know that a simple rebranding would cause such a problem, and they responded very quickly to fix it.

Of course the fix is only a temporary one, as Oracle are going to want to change that variable eventually. So rather than pointing fingers, perhaps the Java community could try to come up with a real long-term solution. Such as a way to manage the JVM’s memory from within the JVM… or getting rid of the cursed PermGen altogether?

The Aquarium: GlassFish at FISL

Thu, 29 Jul 2010 04:40:22 +0000

Alexis and Arun went to FISL11 at Porto Alegre (Wikipedia, GeoMap) and have provided reports including photos; see Alexis' Back from FISL, and Arun's AFISL 2010 Trip Report.

Alexis's slides are available via SlideShare: GlassFish OSGi - from modular runtime to hybrid applications and The future of the GlassFish community. Arun's presentation was all demos, which he has also made available as a YouTube playlist.

Open Source is very strong in Brazil (see for example this post). As you can see from our GeoMap, GlassFish has a fair amount of adoption, but we need to improve our outreach. If you have suggestions or want to contribute, post them as comments on this entry, or contact us at theaquarium at sun dot com.

Planet Eclipse: Lars Vogel: Eclipse 4.0 Application Platform – Tutorial Updated

Wed, 28 Jul 2010 22:25:17 +0000

As you know the Eclipse 4.0 SDK is out.

It also appears in discussions that some people don’t think Eclipse e4 is a good idea.

Other people seem to like it.

To help you to decide yourself I updated my Eclipse e4 Tutorial to Eclipse 4.0 Application Platform – Tutorial.

Together with Tom Schindls Tutorial you should be able to have a good start with Eclipse 4.0 SDK.

Please remember that the target of the core e4 Project is to improve the programming model of Eclipse and to provide an improved way of influencing the UI. The standard plugins are still the same and behave the same way.

My Tutorial also needs improvements, unfortunately it is not as far and deep as I like, but I hope that is will give you a good start. If you find issues, problems with my tutorial please let me know. The “more to come” section of my tutorial lists my future plans.

DevX - Java: Adobe Buys Day Software to Bolster ECM Portfolio

Wed, 28 Jul 2010 22:18:27 +0000

Adobe Systems shelled out $240 million to acquire Day Software Holding, a Swiss developer of enterprise content management software.

Java.net Weblogs: QA#4: Java EE 6: Developers focus on business logic, Much lower TCO - by Johan Vos

Wed, 28 Jul 2010 21:43:43 +0000

Content available at: http://blogs.sun.com/arungupta/entry/qa_4_java_ee_6

Planet Eclipse: Wayne Beaton: Eclipse is… a Community

Wed, 28 Jul 2010 20:36:16 +0000

Summer madness has force me to leave a gap in the delivery of my award-winning “Eclipse is…” blog series. But I’m back now. In this series, I walk through the many different aspects of Eclipse, starting with the definition that most people are comfortable with: Eclipse is a Java IDE. But, as the series discusses, Eclipse is more than that. Technology-wise, Eclipse is a platform for building IDEs, tools, applications, runtimes, and more. Eclipse is open source projects. Lots and lots of open source projects covering a vast array of topics from modeling to identity management and object-relational persistence.

It’s certainly true that great technology is an important part of what makes Eclipse what it is. However, technology alone isn’t enough. Technology needs to have a community. And at Eclipse, we’ve got community. At Eclipse, we bring the community together to do great things.

Community is about coming together to do things as a group that no single person can do by themselves. Whether it be chasing snakes from a local watering hole, or building great technology and support.

Eclipse is actually a collection of communities that intersect. The Eclipse Development Process defines three different communities: users, adopters, and contributors/committers. Each of these communities has different requirements and expectations from Eclipse.

The first community, users, tends to regard of Eclipse primarily as a consumable product. They are primarily concerned with using an Eclipse-based IDE to build solutions. We estimate the size of this community to be between four and six million in size; though the fact that more than a million downloads of the new Helios packages occurred in the first month of availability leads me to believe that the community is even larger than our estimate.

The adopter community contains individuals and organizations that build solutions based on Eclipse technology. This can be as simple as providing a plug-in that runs in an Eclipse IDE, or as involved as basing an entire product on the Eclipse Rich Client Platform (RCP) or Rich Ajax Platform (RAP). It also includes those individuals and organizations who base a business on providing development assistance and support for Eclipse technology. One way or another, adopters tend to be building Eclipse plug-ins to provide solutions that directly or indirectly leverage Eclipse technology (though this is not necessarily the case as some Eclipse technology–like EclipseLink, and EMF–can be leveraged in plain-old-Java application). We don’t even try to estimate the size of the adopter community; it’s just too hard to do. There are more than a thousand “solutions” in the Eclipse Marketplace. This is really just the tip of the iceberg; it doesn’t include, for example, the bajillions of in-house applications (some of these are captured in case studies) that leverage Eclipse technology.

The contributor/committer community contains that group of individuals and organizations who contribute directly to Eclipse projects. These are the individuals who provide patches and/or contribute new functionality to the various Eclipse projects. Contributors tend to participate directly in an Eclipse project by providing code, ideas, answers to questions in the forums, and more. Committers are a subset of the contributors with write access to the resources maintained by a project (committer access is provided on a project-by-project basis). The idea is that over time, a contributor is invited to become a committer and elected into that position based on credibility established over a period of time. At last count we had almost a thousand committers and thousands of contributors (more than 11,000 individuals have contributed at least one patch to an Eclipse project).

Developing a community is an important part of being an Eclipse project. In fact, an integral part of the Eclipse Development Process. As part of a review process, a project is required to demonstrate their community-building activities, like blogging, speaking opportunities and more.

The graphic on this slide attempts to show that the various communities interact with each other. Users consume the software produced by the contributors/committers and the adopters, and provide feedback. Some subset of those users will provide feedback and other input into the project. Adopters also provide feedback and input. Some number of adopters may become contributors and ultimately committers. Projects with large communities have greater potential to have very diverse committer communities and broad consumption by adopters. There’s really more to it, but I’ll leave this discussion for a later post.

At this point in my presentation, I usually stop and ask the audience how many of them already have Eclipse Bugzilla accounts. Then, noticing that a large number of people haven’t put up their hands, I facetiously marvel that so many people have managed to use Eclipse for so long without ever having encountered any sort of problem. I use this opportunity to tell people that it’s okay to open bug reports (I once tried to use Erich Gamma’s bug-reports-are-like-love-letters analogy but decided that that wasn’t my style).

So, Eclipse is a community. A big community. A growing community. A diverse community. More than a community, though, Eclipse is… an Eco-System.

On a side note… committers: get your talk proposals for Eclipse Summit Europe in today!

Planet Eclipse: Boris Bokowski: Eclipse 4.0 Overview

noreply@blogger.com (Boris Bokowski) — Wed, 28 Jul 2010 19:47:56 +0000

Since I don't have enough energy left to also write a thousand words, here is just an overview picture of the Eclipse SDK 4.0 Early Adopter Release that we shipped today. I hope you find it useful.

Planet Eclipse: Eclipse Announcements: Eclipse SDK 4.0 Now Available for Early Adopters

Wed, 28 Jul 2010 19:44:00 +0000

The Eclipse Foundation is pleased to announce the availability of Eclipse SDK 4.0, the next generation Eclipse platform. Eclipse has a very large and successful ecosystem of plugin providers and RCP application developers. Eclipse 4.0 introduces new features that make it easier for the members of the ecosystem to build and assemble Eclipse plugins and RCP applications.

Planet Eclipse: Ian Skerrett: Eclipse SDK 4.0: The Journey of a New Platform

Wed, 28 Jul 2010 19:07:49 +0000

Today is a very exciting and important day for the Eclipse community. The Eclipse Platform project has released Eclipse SDK 4.0, the next generation of the Eclipse platform. For technical perspective on the release I point you to Mike Wilson’s excellentt blog post ‘Growing the future’.

Congratulations to the entire Eclipse 4.0 team for shipping the release (which of course was on schedule )! It has been a long journey to get to this day. What started out as a ‘blue sky’ BOF at EclipseCon 2007, followed by some more concrete ideas at EclipseCon 2008, the details began to emerge via a series of summits and community discussions. It has been a great community effort.

Not everyone will agree with the decisions, ideas or architecture of Eclipse 4.0. That is to be expected in a healthy community with lots of passionate participants. It is a credit to the team that they have made the tough decisions and ‘shipped the code’.

The journey is far from complete. The next step is to get Eclipse Foundation projects and Eclipse plugins to migrate to Eclipse 4.0. This is why we have named Eclipse 4.0 an ‘early adopter release’. Over the next number of months I am hoping every Eclipse project will migrate their code based to the new platform. There is binary compatibility so it should be a straight forward process. It is great to see some people have already started.

At this time, we don’t expect Eclipse IDE users or even companies to ship products based on Eclipse 4.0. These groups tend to rely on a number of different Eclipse projects/plugins that will need to migrate to the 4.0 platform. In 2011, I would expect the Indigo release train will include an end user release based on Eclipse 4.x.

Congratulations again to the e4 team for shipping Eclipse 4.0. Now it is up to the rest of the community to continue the journey towards the Eclipse 4.0 platform. Make sure you tell us your stories as you begin the process.

Planet Eclipse: Tom Schindl: Eclipse 4.0 and tutorial on writing e4-RCP-application released

Wed, 28 Jul 2010 19:01:35 +0000

The Release

The e4-Team just announced the availability of the Eclipse 4.0 SDK “Early Adopter Release” (Reviewslides) which marks a major platform update since the inception of 3.0 6 years ago.

Just to reiterate what the 4.0 SDK is and to set expectations right. The 4.0 SDK is marked as an “Early adopter release” targeted at Plug-in Developers who want to test their code on the upcoming 4.x platform and report problems because of broken APIs or “APIs” not available anymore because they used internals of the platform.

The 4.0 SDK “Early Adopter Release” is not targeted for use as your Primary IDE so keep this rough edges in mind when giving the 4.0 SDK a try.

When takeing a closer look to the release you’ll notice that in reality multiple different things have been released:

Eclipse 4.0:
- Eclipse 4.0 Application Platform: The new application platform to write OSGi-base (UI-)Applications centered around a new programming model using DI and a modeled application kernel
- Eclipse 4.0 Compatible Rich Client Platform: Compability layer for API clean 3.x bundles to run unmodified on the new Application Platform
- Eclipse 4.0 SDK: Eclipse 4.0 Application Platform + Eclipse 4.0 Compatible Rich Client Platform + PDE 3.6 + JDT 3.6
Eclipse 4.0 Technologies (also called “e4 SDK 0.10″ / “e4 release July 2010″ because the releasing project is e4):
- XWT + Tooling: XAML for SWT/JFace and Visual Designer Tools
- Semantic Filesystem implementation
- Application Modeltooling

A small hint for Plug-in developers who are trying to debug their Plug-In by launching an inner Eclipse and all Eclipse 4.0 Application-Developers. The Eclipse 4.0 SDK misses at the moment the source bundles for the new Eclipse 4.0 components and you need to install it through the p2-repositories pre configured for you.

We recommend to install:

EMF SDK
Modeled Workbench Source
CSS Support Source

to successfully step through the code using the debugger.

My personal main focus in the Eclipse 4.0 development for the last 2 years has been the “Eclipse 4.0 Application Platform” whose goal is to modernize and simplify the development of OSGi-based UI-Application using DI and a modeled application approach. In the last few months I also worked on a tool to make writing applications for the Eclipse 4.0 Application Platform easier.

The model tooling

Since March I’ve been dedicated half of my 4.0 development time implementing support for the application model underpinning the Eclipse 4.0 Application Platform.

The model tooling has not yet graduated out of the e4-incubator and so is not part of the Eclipse 4.0 SDK download and you’ll have to install it using the preconfigured e4-repository – you find it in the “E4 Tools”-category.

The tooling is working in 2 modes:

Design/Development-Time mode: This is the standard mode you are using when developing an application. In this mode you operate on a Application-Model persisted as a XMI-File in your workspace.
Live mode: In this mode you are operating on the live model of a running application and are able to inspect and modify live

The Eclipse 4.0 Modeltooling is written to run native on the Eclipse 4.0 Application Platform (no useage of the Backward-Compat-Layer) but also integrates smoothly in the Eclipse 4.0 SDK.

Probably one of the most remarkable things though is that it runs also in a 3.6 SDK enabled by the so called Forward Compat Layer I started developing who does the opposite of the backward-compat-layer. It allows you to run components using the Eclipse 4.0 Progamming model which is built upon POJOs and DI in a 3.6 environment.

This makes it possible to write Eclipse 4.0 Applications using the 3.6 SDK as the screenshot demonstrates:

All you need is to install the tools using the e4 Update Site which is available on http://download.eclipse.org/e4/updates/2010.

The tutorial

When introducing new technologies we know that it is important to give people a medium sized example application which explains the concepts of the framework and provides them “monkey see, monkey do” example code. That’s why I’ve worked in the last few days/weeks on a tutorial which helps people getting started writing applications using the “Eclipse 4.0 Application Platform”

You can download the tutorial which is released under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 using this link. The sources codes are released under EDL-1.0/EPL-1.0 and are available from github and/or as individual zips (urls found in the PDF).

If you only want to take a look at an application built using the Eclipse 4.0 Application Platform you can downloaded using the links below:

Mac Version (cocoa32bit,cocoa64bit)
Linux Version(32bit,64bit)
Win32 Version(32bit,64bit)

You need Java 6 to run the demo although Eclipse 4.0 itself only needs Java5. To get accounts displayed on the left you should enter the following values in the Preference Dialog:

Username: john
Password: doe
Host: blabla.com

It looks like the update-code triggering of the AccountView is a bit weak so if you are not informed about the opening of the session after clicking around stop and starting the application should help you (I’ll try to work on a solution in the days to come).

Just in case you like the service I’m providing to you for free with this tutorial and you want to donate some cents here’s the button to push:

Planet Eclipse: Eclipse Announcements: Attend Eclipse Testing Day in Darmstadt

Wed, 28 Jul 2010 18:17:00 +0000

Bredex, MicroDoc and the Eclipse Foundation are pleased to announce Eclipse Testing Day in Darmstadt, which takes place September 8, 2010. Eclipse Testing Day is a day-long event for technical developers, testers, architects and managers to learn more about testing with Eclipse and OSGi technology.

Planet Eclipse: Konstantin Komissarchik: Oracle JVM 6u21 and Eclipse

noreply@blogger.com (Konstantin Komissarchik) — Wed, 28 Jul 2010 17:47:00 +0000

A number of users have encountered frequent Eclipse crashes since the recent Oracle JVM 6u21 update. The crash cause is listed as follows:

java.lang.OutOfMemoryError: PermGen space

The underlying problem if that in 6u21 (version 1.6.0_21), the vendor was changed from Sun to Oracle. Eclipse launcher reads the JVM vendor and if it detects a Sun JVM, it adds an extra –XX:MaxPermSize setting that is necessary for Eclipse to function. With the vendor change in 6u21, the launcher is no longer adding the necessary parameter on launch.

There is an Eclipse Platform bug open, but so far it doesn't look like there is going to be an attempt to resolve this until Helios SR1 scheduled for September.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=319514

Fortunately, there is an easy workaround. Open the eclipse.ini file in an editor. You will see something similar to this:

-startup
plugins/org.eclipse.equinox.launcher_1.1.0.v20100307.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100307
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-Xms40m
-Xmx384m

This is setting that's not having any effect after 6u21:

--launcher.XXMaxPermSize
256m

Remove it. In it's place, add -XX:MaxPermSize=256m on a new line after the -Xmx setting. Better yet, while you are in there, bump the memory limits to a higher value. Nothing ruins your train of thought better than your IDE crashing with an OutOfMemoryError. Here is a sample eclipse.ini that works on 6u21.

-startup
plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100503
-showsplash
org.eclipse.platform
--launcher.defaultAction
openFile
-vmargs
-Xms40m
-Xmx1024m
-XX:MaxPermSize=512m

IMPORTANT: I do work for Oracle, but this is not an official Oracle statement on this issue. Just some advice from one Eclipse developer to another.

Update: This problem is specific to Windows. On *nix variants, Eclipse launcher uses slower, but more robust logic for detecting JVM type. More information in Bug 320005 for those who are interested.

Update: Oracle has produced another build of 6u21 JVM that reverts the change that adversely affected Eclipse. If you have reverted back to an older JVM, you can safely move forward to 6u21. The build 1.6.0_21-b07 is safe to use. The version that Eclipse has trouble with is b06. You can check which version you have by running "java -version". More information in Sun Bug 6969236 for those who are interested.

Planet Eclipse: Mike Wilson: Growing the future

Wed, 28 Jul 2010 17:42:56 +0000

Last year, at about this time, I wrote a lengthy, omnibus post called Eclipse has a future. It’s purpose was to capture some of the challenges that are facing the Eclipse community, and describe how the work that we were doing in the e4 Incubator Project could help to address them. Since then, our investment in that work has continued to grow, and we are now ready to ship a new version of the Eclipse SDK, built with technology that has graduated from the incubator, called the Eclipse SDK 4.0 Early Adopter Release.

I’m going to talk about what it is about Eclipse 4 that makes it interesting and important, but first I wanted to say a bit about why we grew the tagline “Early Adopter Release”.

An Early Adopter Release

As I noted last year, the Eclipse Project developers have known for quite a while that we were going to have to innovate in some significant ways in order for the base platform to continue to be compelling in the face of changing pressures in the industry — notably, a range of new technologies for building desktop apps (e.g. AIR, Silverlight, etc.) and the push towards using the web to deliver “desktop grade” applications. At the same time, however, many of our consumers were looking for the strongest possible backwards compatibility / stability so that they could continue to move forward with the release train without needing to invest in responding to changes in our layer (or any other one they depended on, for that matter).

In addition, we had begun to feel that the complexity of the platform code itself was preventing us from growing our community. More than ten years of development had left the code in a brittle state where almost any significant change would break more places than it fixed, making it extremely difficult for new developers to get involved.

The result of this was a conscious splitting of our focus into an ongoing development stream, Eclipse 3.x, where we could continue to offer the strongest possible backwards compatibility and stability, and a brand new project, the e4 Incubator, where we could work on the kinds of major innovations and code transformations that we believed were necessary. As the work in this incubator matured, it would move outward to the most appropriate place: some to other projects at Eclipse.org, some to our Eclipse 3.x SDK (as the flexible resources work did in 3.6), and some to a new “forward looking” Eclipse 4.x SDK, which would “organically” become the focus of Eclipse based development as it proved its worth.

So here we are in 2010. We’ve gone from a prototype — last years “0.9″ release that used significant chunks of old code as “shims” to get things running — to a real Eclipse SDK built on some powerful new underlying technology. The thing is though, this really is new technology. It’s not like we went in and tweaked the implementation a bit; we actually gutted the workbench implementation and started again.

The good news is that it seems like our bet has paid off. If you look at the pace at which the new version of the workbench has come together, it’s obvious that this code is much easier to work with. Personally, I’d say we’ve seen about a milestone’s worth of improvement each week for the last month or so. Over all, the Eclipse SDK 4.0 is completely usable for development. The team has been running on it exclusively for at least a month, and the drive to eat-your-own-dog-food has gone from a painful experience to one that feels just like working with Eclipse 3.x (except that it looks nicer ).

The thing about dog-fooding though, is that it works through the scenarios that are most important for the people working on the code, and basically nothing else. It’s great at getting something we can use, but not so good at covering all of the myriad ways that the community has built on top of us, which gets me back to why we’re calling this an “Early Adopter Release”.

We need your help.

To get from the current state to something that is solid, bug free, and complete enough to be included in a release train (or used to ship product) is going to take your input. We need to know where the changes we’ve made impact you and your uses of Eclipse. We need to know whether there are things that are missing that you must have. We need to know if there have been performance impacts… Basically, we’re asking you to invest enough time to take the Eclipse 4.0 release and load your plug-ins and projects on top of it, and then tell us what is working and what isn’t. And, in case that wasn’t enough, we’re asking you to continue to work with us over the course of this year, re-trying milestone builds and helping us verify that we’re converging to where we need to be.

Now, I wish I could tell you that it would be immediately obvious how this was going to benefit your work. I think there are some very compelling things about the new workbench, but I honestly can’t tell how important they’ll be to you. Really, I’m asking for your help here because I really do believe that this is the future of Eclipse, and I know that it will be great with your help, or it will die on the vine without it.

The one thing I can offer in return is an absolute commitment to be responsive to your input. Our goal is to have every milestone on the road to 4.1 be a “mini-release”; one that is visibly more complete, more capable and more solid than the ones before it. To do this, we will be strongly focused on the issues that you report to us — to the early adopter goes the spoils (er… bug fixes).

What’s there now

If you’re looking for the full list of what’s new in Eclipse 4 you should check out the New and Noteworthy. I’m not going to reiterate all that, but I would like to talk a bit about some of the technological pieces that have graduated from the e4 Incubator, which are the basis for this “newness”.

For example, the most immediately visible change you see when you start up Eclipse 4 is the new look and feel:

This is a great, fresh new look with a modern style and excellent use of whitespace to reduce visual clutter. But, in addition to being some best-of-breed design work [no, I didn't have anything to do with it] this also represents the first time where the appearance of the workbench — everything from the background colour of the main toolbar to the radius of the curve on the folder tabs — is controlled by CSS.

Why we believe this is important, is that it simultaneously gives people building RCP apps and products based on the SDK much more control over the look (i.e. the “branding”) while making the “language” of that control be one that makes sense to designers (i.e. instead of requiring them to know the internals of our Presentation API. Ugh!). It also opens up opportunities for people building apps that contain embedded HTML content to share more of their design resources.

Just as an example, here is an ugly, but definitely um… different look we rolled using only CSS changes:

The underlying SWT changes to support this work were done by the SWT team as part of 3.6 development (with a couple of tweaks since then). The CSS Engine itself was contributed by Angelo Zerr, with ongoing development from several others. To see an example of how you can use this new support in an RCP app, to excellent effect, take a look at Kai Tödter’s Contacts Demo.

Also, if you are interested in pushing the limits of what you can do with the CSS support, please come talk to us. There are definitely places where we would like to provide even more flexibility, and we know the workflows around editing the CSS could use work. Knowing what would be most valuable to the community here would be excellent.

Despite being less immediately visible, the most critical change in Eclipse 4 is the switch to a modelled user interface.

Essentially, the entire structure of the application’s user-interface is represented as an EMF model. This model has been carefully tuned so that it has strong separation between unrelated concerns, and is layered so that Eclipse 4 based applications can incrementally take only those pieces they actually need. This is a significant advance over the “take everything and prune out the bits you don’t need” approach used in Eclipse 3.x (and earlier) RCP applications. What this actually means is that people building new Eclipse 4 based applications do not have to include any of the scaffolding that is specific to the workbench’s use of the model, nor do they have to include any of the code that supports backwards compatibility for 3.x apps, if they don’t need it. We believe this new way to work is sufficiently important that we have christened it the “Eclipse 4 Application Platform”.

Note that this does not imply that you must give up 3.x compatibility in order to build RCP applications in 4.x. We continue to be committed to supporting full API compatibility between 3.x and 4.x, so building Eclipse 4 based, traditional RCP applications is still supported. It’s just that once developers start using the Eclipse 4 Application Platform, the benefits will be obvious.

At the workbench level, the flexibility we get from the use of the modelled user interface, together with another piece of technology newly graduated from the incubator, hierarchical contexts, also opens up brand new capabilities for 3.x compatible applications. In this case, by separating the application code from the context in which it is running, we can remove many of the artificial constraints imposed by the 3.x workbench. Dependency injection is used to provide the application code with the values it needs without requiring it to know where they came from, and in turn, the 3.x compatibility support makes use of this to ensure that all traditional change notification, data binding, etc. behaves as expected.

You know, reading that last paragraph, it’s clear that this is a case where a picture would definitely be worth the proverbial thousand words. Here is an example of a common workflow for us on Eclipse 4.0 that would be simply impossible to do in 3.x:

What you are seeing here is the completely unmodified 3.x Console view being displayed in the same stack as the editors. We like this because it’s a great way to give views like the Console more screen real-estate, but every 3.x user will tell you “You can’t put views in the editor area(!)”.

Really, this is about making the decisions relating to where views and editors show up (for example) a matter of policy rather than being hardwired into the implementation. Because, in 4.0, these policy “add ons” can be done by simply controlling what transforms are possible on the model, the code to implement them is very easy to write, is typically all held in a single class, and can be changed to support the needs of your particular application. For anyone who understands what the equivalent code in 3.x looks like, this is one of the clearest pieces of evidence we have that the new modelled UI is much easier to work with.

Where we go next

Before I go on, I have to say I’m absolutely humbled by how much effort everyone has put in to get us to where we are today. From the “old school” platform committers, to the new ones we gained because their work graduated from the incubator (Brian de Alwis, Kai Tödter, Yves Yang), to all those who continue to work on cool new technology in e4, to the many who have helped us with the design, and the many more who tested (with special thanks to Stefan Mücke), commented, documented… All of you have my greatest respect. I hope you all know we have built something great here, and we ought to be proud of it.

The thing is though, we also know one other important thing: We’re not done.

And we’re not done in an at least three significant ways:

1) plugging the holes

You don’t have to look far when playing with Eclipse 4.0 SDK Early Adopter Release to find places where there are bugs and things that are just outright missing. I’d apologize about this, but the truth is we got as far as we needed to so that our “early adopters” can help to guide us the rest of the way.

We have bugzilla for the bugs and a wiki page that captures the most obvious missing features. We know that there’s lots more work to do, and we’re going to do it.

2) graduating more

Even though we did see some important new capabilities graduate from the incubator, there is lots more work being done there that hasn’t graduated yet. We know that’s the natural order of an incubator — things will graduate when they’re ready — but what’s important is that we continue to push to make the level of investment it takes for that work to reach maturity.

As an example, for those who’ve been following e4 since the beginning, one of the most obvious missing pieces in Eclipse 4.0 is the Eclipse Application Services (a.k.a. “the 20 things”). Fundamentally, we still believe the EAS are going to be important for the future of Eclipse; particularly if we want to start looking at building plug-ins in languages other than Java. We did make some progress on this, this year, but we didn’t get even close to far enough for it to graduate as part of the 4.0 release. I’m disappointed, but I know we won’t let this one go. Stay tuned for more in the weeks ahead.

3) continuing to innovate

So listen, let’s say you’ve got this great idea about the next big innovation that we need, and that you are looking for just the perfect place to make it happen. Well, have I got an incubator for you!

Seriously, the e4 Incubator is intended to be a place to experiment, push the boundaries, whatever-it-takes on an ongoing basis. Just because Eclipse 4.x has started doesn’t mean its one burst of innovation is over. If you have an idea for something new, please come talk to us.

I was very happy to see that Olivier suggested bringing a JDT related project into e4 on improving support for Java-like languages. I think that’s a great idea, and I hope he can get enough critical mass to get it going. If you’re interested in that possibility check out the discussion on jdt-dev.

Anyway, even for me, this has been a marathon post. I hope that it helps to give you an idea of what we’ve been up to. Please give Eclipse SDK 4.0 Early Adopter Release a try, and tell us about your experiences.

Peace,

McQ.

Java.net Weblogs: Oracle Video Challenge: an Opportunity to Attend JavaOne for Free!

Wed, 28 Jul 2010 16:19:45 +0000

The Oracle Video Challenge, which started yesterday and runs through August 9, will provide three winning contestants with a free Oracle OpenWorld or JavaOne and Oracle Develop full conference pass. In addition, everyone who submits a "valid" video will receive a $400+ registration discount.

Here's a brief overview:

Test your power of persuasion. Grab your video camera, and convince your peers why you deserve to go to Oracle OpenWorld, JavaOne or Oracle Develop for FREE. The community will pick the top five finalists in each category (Oracle OpenWorld, JavaOne, and Oracle Develop), and a panel of Oracle judges will pick the final three winners (one for each category). Having trouble thinking of what to say? Tell your peers what session, track, or event you can’t miss out on. Explain how much Oracle OpenWorld, JavaOne, or Oracle Develop will help further your career and/or development skills.

*EXTRA Bonus* - Everyone who submits a valid video entry will get a discount code for Early Bird pricing to use at time of registration for Oracle OpenWorld or JavaOne and Oracle Develop. This is a savings of $400 or more over the onsite price!

Get the complete details at the Oracle Video Challenge site.

Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feed and the java.net blogs feed. You can find historical archives of what has appeared the front page of java.net in the java.net home page archive.

-- Kevin Farnham

Twitter: @kevin_farnham

Planet Eclipse: Eric Rizzo: Tip of the hat to Oracle

noreply@blogger.com (Eric Rizzo) — Wed, 28 Jul 2010 15:14:38 +0000

As most Eclipse community members probably already know, a recent change by Oracle in the JDK/JRE for Windows caused serious problems for Eclipse. But in a sign that Oracle really does understand the importance of Eclipse in the Java community, as well as a nice gesture of cooperation and consideration, they've rolled back the change that caused the problems and released new builds.

I admire Oracle's willingness to respond quickly to this issue, in spite of the fact that Eclipse code was admittedly relying on non-documented and non-API data. Ian Skerret also deserves credit for directly engaging people at Oracle to make this happen.

Hats off to cooperation!

Java.net Weblogs: FISL 2010 Trip Report

Wed, 28 Jul 2010 13:06:08 +0000

Content available at: http://blogs.sun.com/arungupta/entry/fisl_2011_trip_report

Planet Eclipse: Marcel Gorri: Post #11 – More than Strings – 28 Jul, 2010 – 10h00 (GMT-3)

Wed, 28 Jul 2010 13:04:27 +0000

Software localization is the process of converting or preparing a computer program to be suited for a particular region. Localization can sometimes be simply a matter of language translation, but it can also prove to be a much more complex process when it comes to issues such as formatting, currency, date and time, sorting patterns, imperial versus metric standards and so on.

Since Sequoyah already provides a localization framework for strings, and with the goal of providing a more complete and easy to use framework, Sequoyah now intends to deal with other localizable resources besides strings.

In this document we have a proposal of such effort, where we list some user stories describing how we intend to extend the current framework to deal with images, sounds and video in a first moment. In a later moment, the framework will also be capable of treating even other localizable resources, such as formatting, currency, date and time.

If you have any comments or suggestions about this proposal, please contact us through our mailing list.

(Posted by Marcel Gorri)