Dmitry Jemerov's Weblog

JavaOne multimedia presentations now available

Sun has just made available the technical presentations from JavaOne, including my presentation on Team Server. You can view the slides, listen to the multimedia presentation, or read the transcript. To listen to the audio, you’ll need a Sun Developer Network login – you can register for free if you don’t have one.

Unfortunately the presentations do not include video for the demos, so you won’t be able to see the Remote Run and Delayed Commit functionality in action.

Pythonid plugin released

Pythonid, the plugin providing support of the Python language in IntelliJ IDEA, has finally been released. You can download it from the IntelliJ IDEA Plugin Manager (Settings | Plugins), or from the plugin repository.

The plugin is currently compatible only with IDEA 5.1.x. Demetra compatibility will be provided in the next build of Demetra.

Pythonid was developed by me and Keith Lea. This is not an official JetBrains product; I work on the plugin only in my spare time. The plugin is open-source, and the source code is available at http://pythonid.dev.java.net. People willing to contribute to the plugin development are very much welcome; if you're interested, please contact me to discuss the details.

Team Server / IntelliJ IDEA presentation on Google Video

Yesterday I’ve returned from California, where I was at JavaOne conference. This was quite a “deep dive” for me - despite the fact that it was my first time at an international conference, I came there to give a talk, and my talk was scheduled on the first day of the conference. The talk went well, though, and I also enjoyed the remaining part of the conference quite a lot.

Before JavaOne, we gave presentations on our products at the Google office. I spoke about Team Server, and Mike Aizatsky demonstrated the HTML, CSS and JavaScript features of IntelliJ IDEA. Our talk was recorded, and the recording is currently available on Google Video.

Enjoy watching, and if you have any comments, feel free to leave them here.

So what is "Support for JGoodies Forms"?

One more very common request for the UI Designer is the request to support JGoodies Forms. This request shares a common trait with many other requests to support something that we receive for other areas of IntelliJ IDEA: it lacks any details. For example, what does “Spring support” mean? Is the Spring-specific resolve and completion available since version 5.0.2 sufficient, or does the requester need something more, and if so, what exactly?

As for JGoodies Forms, there is one kind of support that we can provide with very little effort. We can make it possible to generate source code and bytecode which uses the JGoodies Forms layout manager without making any additions to the design-time experience. (We already support GridBagLayout in a similar way – if you’re curious, look at GridBagLayoutCodeGenerator and GridBagConverter classes in redist\src\src_javac2.zip.) The only issue is that I don’t quite understand what problem it would solve.

Now, of course, JGoodies Forms has a number of features which are not supported by our designer (for example, row/column groups). And if what you really need are these additional features, it will probably make the most sense to support them in our own layout manager, in addition to providing JGoodies Forms support.

So, my request is: if you’re interested in JGoodies Forms support, could you please leave a comment here and describe what exactly you need from such a support?

And in the meantime, here’s a small preview of a different new feature that I’ve been working on today:

IntelliJ IDEA 6.0 "Demetra" UI Designer: Custom component creation

One of the problems which made it impossible for people to use previous versions of the IntelliJ IDEA UI Designer in their projects was the lack of support for custom component creation code. The designer could only work with components which had no-argument public constructors, and could not handle components created by constructors with arguments, component factories and so on.

We continued to receive feedback on this issue during our work on the version 6.0, and finally we’ve come to a solution for this issue that doesn’t break any of our design principles. The solution works equally well for source code generation and bytecode instrumentation, and does not involve storing source code in the form files.

The solution is in fact very simple. Every component now has a property called “Custom Create”:

If the property is set for a component, the UI Designer does not generate the constructor call for this component. Instead, if at least one component has the “Custom Create” flag set, IntelliJ IDEA creates a special method called createUIComponents(), and inserts a call to this method in the beginning of the generated UI initialization method. The code of createUIComponents() is written by the user, and the user needs to assign values to fields bound to all custom-created components. (A component with the “Custom Create” flag must be bound to a field.)

In design time, components which do not have a public default constructor are represented by instances of superclasses which do have such a constructor, or by JPanel instances if there is no such superclass. The property list shown in the inspector is still taken from the exact class of the component, so you’ll be able to set the values for all properties (although the values of properties that don’t exist in the superclass will not affect the design-time appearance of the component).

A related change that also makes the UI Designer more flexible is a small modification to the source code generation algorithm. Now, if any of the user-written constructors of a class bound to a form calls the UI initialization method explicitly, IntelliJ IDEA no longer generate a class initializer block with a call to the UI initialization method. This allows to initialize the UI at a somewhat later time (for example, after values of the parameters passed to the bound class constructor have been processed).

This solution will become available in the next EAP build of Demetra. In the meantime, feel free to leave feedback here, particularly if the solution does not cover some of the scenarios found in your projects.