jdelphi
Project home

This project is currently in the conceptive stages. We are planning to base our work on the existing AbaGuiBuilder. Hopefully, development ought to start soon. Please join the project if you want to get involved, and have a look at the discussion forums. Your help will be much appreciated!

The Java world already has many IDE's, but they all seem to focus far more on web development than stand-alone GUI application development. The idea of JDelphi is to provide an Java IDE on par with the VB or Delphi tools that exist for Windows: visual, simple, but powerful.

This includes many facets. There are many tools and frameworks for Java, but most of them work independantly of one another, and therefore, making them work together can be difficult. Furthermore, most frameworks are very much "code-orientated", that is, they are rather complex to use, and wouldn't integrate very well into a visual tool. For example, the layout system that exists in Swing is usuable if you are designing your GUI directly in your code, but far less so if you are designing it visually.

Here are therefore some of the main features which we plan to make available in JDelphi:

• A visual component library, which would wrap around a lot of existing Java frameworks in a consistent and simple way.
  
• A visual GUI designer, based on the VCL components, allowing to edit GUIs in a 100% WYSIWYG way, and also allowing to edit non-visual components (setting their properties and events) in a visual way (like Delphi). Associated with the window designer would be an object inspector, showing all the available properties of the selected components, as well as all its events.
• The GUI designing would definitely not be two-way. That is, it would not generate Java code. This is messy, and it makes it difficult to make the GUI designer fast, intuitive, WYSIWYG, and easy to use. All the visual GUI design will be written to a resource file, which, with a very simple syntax, would be editable if by hand if necessary.
• The events of each components (visual or not) would appear in the object inspector, and a mere double-click would show the event handler code. All the implementation details regarding listeners and such like would be hidden as much as possible.
• All registered VCL components would appear in a component palette at the top of the screen. All components would be directly available using simple drag and drop.
• Integration into the VCL of certain notable and very useful elements imitated from the Delphi VCL, such as the TDataSet component. This is a simple component (of which there are many variants with specific uses), which provides a simple and clean interface between a data source (the underlying nature of the data source is up to the TDataSet implentation; it can be an SQL database, a flat file DB, a text file, a virtual or memory datasource, or just about anything else), and the visual controls of the GUI. Thus, to make a simple database application, all you have to do is drop a TDataSet descendant on your form, configure it, drop some visual controls, and simply hook them up to the datasource by using the DataSource and DataField properties.
• Integration of many high-level visual controls which are lacking from Java, when contrasted with Delphi. Some of them may be merely an encapsulation of existing Swing controls (with proper default values added, as well perhaps as new features), while other will probably have to be designed from the ground up. Amoung them would be, for example an advanced TDBGrid, comparable in features to the many third-party grid components that exist in the Delphi world.
• Integration of an advanced report designer. This is an important and indispensable feature. It would be powerful, visual, and completely integrated into the IDE. It would also provide the ability to do end-user report designing.
• Advanced debugging and coding features, comparable to other IDEs, such as Eclipse.
• Advanced bug reporting features, allowing the application to show (and optionnaly send by email) a bug report with call stack, screen shot, and miscellaneous logging and system information.
  
• Support for dynamically loading third-party component packs into the JDelphi palette, as well as allowing third-party packages to access/change certain elements of the IDE user interface (comparable to Borland Delphi's OpenTools API). However, I don't want to create a heavy and complex infrastructure like NetBeans or Eclipse. I would rather something much simpler, albeit less powerful. After all, the project is Open Source, so if you really want to make a drastic change to the IDE, why not just make it? :-)

Many more features could be added later, I have many ideas, but this would be a good start.

In particular, another aspect I would like to develop later on, is multi-language capabilities: since there is nothing, technically to stop one from compiling any language other than Java into bytecode, I would like JDelphi to be able to handle any one of these languages. So you could have a project that mixes many different language. I would like to enable any third-party to write and integrate into JDelphi a "compiler pack", that is, a Java package providing a compiler for a certain language, as well as a few language specific functionnalities (such as code insight, error insight, and refactoring). The end user could then load as many different compiler packs as necessary, associating each one with a specific file name extension.

Also, another functionnality I would like to provide would be native compilation. I know there are projects for native compiling to Windows, and perhaps we could use these, but I don't know if any other platforms are supported. So what I would like to start by doing (while waiting for these projects to come to maturity) is to simply provide for each targeted platform a stub executable file, in which we embed the JAR. That way, we can produce a native executable which simply loads the JAR. This means that we can associate with the native executable a specific icon, an application name, etc. This will make for smoother deployment. Since the available features for each native platform will differ, the simplest way would probably be for JDelphi to provide support for what we could call "Native Packs", that is, a Java package that implements the few necessary functions specific to each platform. Thus, by merely compiling a project, the user would be able to produce not only a JAR file, but also native executables for as many platforms as he wishes to target.

This project is still in the conceptive stages. I think this shouldn't be too hard to implement, since we will mostly be relying on existing third-party libraries for doing all (or most of) the hard work. We will mostly just be assembling into a coherent and seemless working environment many heterogenous existing java packages, and adding to the whole thing, the visual development aspect. So please feel free to pitch in, every little bit of help will be appreciated, especially for getting the project off the ground! If you are interesting in helping, please suscribe as a member of the project. You can then have a look at the discussion forums, where you can get in contact with the other developpers, and where we can design the project and organize the development together.