Why Oracle Should Dump JDeveloper For NetBeans

Lately there has been a bit of speculation about what will happen to NetBeans once Oracle has acquired Sun. Personally I am one of the people who is supporting the case for Oracle to support NetBeans, and to drop support for JDeveloper. It seems to me after reading what software developers think of the idea of Oracle supporting NetBeans is that the majority of them are in favor of Oracle supporting NetBeans, and dumping support for JDeveloper. Also many software developers expressed the wish for Oracle to take the best of JDeveloper (namely the DB support) and incorporate it into NetBeans itself.

When considering whether or not to support JDeveloper or NetBeans the following needs to be taken into consideration:

• Quality of support for development of JavaFX applications
• The ability of the IDE to support the big picture (supporting things that will make a difference in the long run for software developers)
• Support of widely used software development techniques (eg Agile development, Test Driven Design (TDD), team collaboration)
• Level of support for Polygot programming
• General IDE platform support
• Support for different types of software development (mobile, web, desktop, TV)
• User uptake of the IDE and IDE platform

JDeveloper Advantages

• Very good support for enterprise software development (for web development)
• Comprehensive support for software diagramming
• Reasonable built in diagnostic tools
• Ready to use out of the box for web development
• Very good support for developing DB based applications
• Good performance

JDeveloper Disadvantages

• No support for mobile and TV development
• Poor support for desktop development
• No support for Polygot programming
• Does not support JavaFX development
• Very limited uptake of IDE and IDE platform
• IDE platform is mainly used in some major Oracle products

NetBeans Advantages

• Reasonable support for enterprise software development (for web development)
• Very good support for desktop, mobile and TV development
• Reasonably good support for JavaFX development (currently #1 IDE) *1
  
• Very good support for Polygot programming (currently supports JavaFX Script, Java, Ruby, PHP, Groovy, C/C++)
• IDE and IDE platform are very widely used (high uptake among businesses and software developers)
• Very good diagnostic tools (including profiler and debugger)
• Excellent usability and out of the box experience
• Reasonably good performance

NetBeans Disadvantages

• Limited support for developing DB based applications
• Limited support for software diagramming

Some major questions remain on the very existance of JDeveloper.

• Why did Oracle create JDeveloper when they could have used Eclipse or NetBeans instead?
• Why is JDeveloper designed to be similar to NetBeans (eg with the user interface)?
• Why does JDeveloper have such poor adoption rates compared to NetBeans?
• Why is Oracle taking such an interest in the NetBeans IDE platform when it directly competes with JDeveloper's IDE platform?
  

For the first time the development of the JavaFX NetBeans plugin has been syncronised with the general development of the NetBeans IDE. It is expected that when NetBeans 6.8 is released that a JavaFX bundle will be available at the same time (on the official downloads web page). Such a change will further bolster the commitment NetBeans has to supporting JavaFX development, and will bring about stronger support in the future. Since Oracle is going to support JavaFX (in a big way) they will find themselves in an very difficult situation should they not support NetBeans (*1).

With the current situation of NetBeans not lagging far behind Eclipse (*2), and the fact that JDeveloper is not one of the top three IDEs is there really room for a 4th IDE (apart from NetBeans, Eclipse, IntelliJ Idea)? Is Oracle willing to get offside with software developers by not supporting NetBeans?

There is a potential risk that if Oracle does not support NetBeans then there could be a mass migration of developers from the Java platform to the .NET platform. Some reasons for this are:

a) NetBeans is more similar to Visual Studio than Eclipse. Why would NetBeans users go to Eclipse when Visual Studio is more familiar? Already there are many Java developers that are doing some software development part time on .NET. Many software developers consider having to use Eclipse (for development on the Java platform) a major step backward from a quality perspective.

b) Possible perception by some software developers that Oracle is not acting in the best interests of the Java platform by removing a major choice, that helps move the platform forward. One can see some of this in the NetBeans Users mailing list, it could be the tip of the iceberg.


*1 - As indicated in an informal poll conducted by Jo Conner
*2 - As indicated in an informal poll by Jo Conner and in a recent poll on java.net

Should There Be A DB API For JavaFX?

I have identified a possible gaping hole when it comes to developing mobile JavaFX applications. Currently there is no DB API that can be used for accessing a database on a CLDC (mobile Java) mobile device. With the mobile part of JavaFX currently targeting mid to high range devices (mobile phones and smart phone) it would make sense to have a database on the devices. After all these devices would have enough resources to run a simple database (one with reduced features and capabilities, compared to its desktop version).

So it is time to start the debate on a DB API for JavaFX. Lets say hypothetically a DB API was to be designed for JavaFX. This DB API would have the following design considerations:

• Provide a consistent API that can provide basic features across all hardware platforms (desktop, mobile, TV)
• Allows advanced DB features to be accessed by desktop JavaFX applications only
• Minimises its footprint and provides as many features as possible, without using too many resources on mobile devices
• Allows seamless conversion between JavaFX Script and DB data types
• Provides reasonably good performance (including on mobile devices)
• Can easily allow syncronisation of data between the JavaFX application and the database in very few steps
• Provides the cabability of querying the DB for internal information without requiring the JavaFX developer to describe the DB structure beforehand
  

Database API Advantages

• Can use a database with a CLDC profile device (mobile JavaFX uses CLDC as the base)
• Can easily use all JavaFX Script and JavaFX features (eg binding, triggers, functional programming)
• Provides an opportunity for JavaFX to gain a major advantage over its RIA rivals
• Can take advantage of Oracle's excellent DB design expertise (when the acquisition of Sun goes through)
• A single DB API that can be used across all hardware platforms (desktop, mobile, TV)
• Able to populate JavaFX controls (both visual and non visual) quickly and easily with very few steps
• Seamless conversion between DB and JavaFX Script data types
• Reasonably good performance with JavaFX having direct access to the DB

Database API Disadvantages

• Will require JavaFX developers to learn a completely new API
• Generics and reflection will not be available to incorporate into the design of the DB API
• DB API will require existing DBs to supply new drivers
• A new DB may need to be created from the ground up to work accross all hardware platforms (incl with CLDC profile devices)
• May require existing DBs to adjust their design/implementation in order to be compatible with the DB API
• Very challenging to design and implement an effective DB API (may take at least a year before it is ready for production use?)

Now the "should there be a DB API for JavaFX" could very well become one of the biggest JavaFX debates of the year. Currently the DB API for JavaFX should not be considered a high priority at the moment, since JavaFX is mainly aimed at creating graphical applications. Therefore stuff like 3D support is a much higher priority for inclusion in JavaFX.

I intend to make it very clear that I am not a member of the Sun JavaFX team. What I have mentioned above is my own opinions and in no way reflects the opinions of the Sun JavaFX team.

What Next For JavaFX? (Update)

After looking through the bug system for JavaFX the majority of changes/additions for the next release are with the controls. Do note that the details on what controls are available may change. Here is the list of controls that will either, be in SoMa (+), not in SoMa (-), highly likely to be in SoMa (*), or may be in SoMa (^).

• Grid Layout (+)
• Spacer (+)
• Separator (+)
• Menu (+)
• Menu Button (+)
• Custom List Cell (*)
• Search Box (*)
• Password Box (+)
• Text Area (+)
• Table (+)
• Spinner (+)
• Dialog (^)
• Multi Style Text Area (*)
• Popup (+)
• Tooltip (^)
• Status Bar (*)
• Tree (+)
• Tool Bar (*)
• Split Menu Button (*)
• Choice Button (^)
• Border (^)
• Split Pane (-)
• Combo Box (+)
• Scroll View (+)

As you can see there are quite a range of controls for the next release! However there is no calendar and tab controls, and some of the controls mentioned above may appear in the internal com.sun package instead. Also note that any controls that end up in the com.sun package are to be considered experimental, just like all the other APIs in com.sun. Luckily from the community there is a Calendar Picker control that is good enough for production use, even though it is currently in beta. For the tab control there is nothing present from the community although it is non trivial to create compared to the calendar control. I do wonder if the Grid Layout control is in fact a new layout.

On to the new and enhanced functionality the majority of the functionality is in the graphics area. Here is the list of functionality that will either, be in SoMa (+), not in SoMa (-), highly likely to be in SoMa (*), or may be in SoMa (^). Do note that this list may change as more information is known about what will be included/not included in SoMa.

• Stage level keyboard and mouse event handlers (*)
• Cloning/duplication of nodes (*)
• Built in callback function variables for state change notification on all controls (+)
• Control key functions are supported in TextBox control (+)
• Controls can be autosized (+)
• 3D transformations for 2D graphics nodes (+)
• Support for 3D bounds (+)
• Can use an image as Paint with 9 slice scaling and tiling for controls (+)
• Perspective and Parallel camera classes for 3D perspective transforms (+)
• Support for 3D rotations (-)
• Non visible controls do not recieve mouse clicks (^)
• Performance tracker for Prism (+)
• Camera/video and microphone capture (-)
• Can remove a parent from a node (+)
• Event bubbling/filtering (-)
• Pixel access (-)
• Support for maps as a core language construct (-)
  

Based on the 3D graphics functionality for the next release JavaFX will start to develop basic support for doing 3D graphics. Currently think of it as 2.5D where JavaFX is going through a transitional phase. Expect the next release after SoMa to have proper support for basic 3D graphics. Just imagine all the interesting possibilities with 3D graphics for JavaFX apps on desktop, mobile and TV :). There will definitely be other functionality that gets included in SoMa where there is no publicly available information about it.

Expect the JavaFX 1.3 release to not be too far away since the JavaFX TV plugin for NB (NetBeans) has been ready since Sept 14, and is going to be available when the JavaFX 1.3 NB plugin is integrated with the IDE. Already the installers are currently being developed for SoMa. It is only a matter of time (in days?) before JavaFX is released.

Coding Conventions For JavaFX Script

With so many people developing applications using JavaFX Script recently it is time to look at some coding conventions. These conventions will include coding standards and best practices. Below I will establish coding conventions that are applicable to JavaFX Script, many of these will come from Java's coding conventions. Remember that what I am about to mention acts as a guide and should be followed where it is applicable.

Naming

Variable and function names should be in camel case (eg isInitialized). Constant names should be in upper case with each word separated by an underscore (eg TIMER_DURATION). Class and Mixin names should be in title case (eg AppUtils). Do note that in JavaFX Script both variables/constants and functions all share the same namespace, therefore you need to name carefully.


Ordering

In a JavaFX Script source file (.fx) the following should be ordered as follows:

1. Source file documentation
   
2. Class/mixin documentation
   
3. Class/mixin
4. Class/mixin constants
5. Class/mixin variables
6. Class/mixin initialisation blocks (init then postinit)
7. Class/Mixin functions

Functions should be ordered by functionality, eg:

function func1(arg1)
{
}

function func1(arg1, arg2)
{
}

function func1(arg1, arg2, arg3)
{
}

function func2()
{
}

When defining a multiple functions of the same name ensure that the function arguments are in exactly the same order in to avoid confusion (see the example above).


Indentation

In general 4 spaces should be used for indenting code. Avoid using lines that are longer than 80 characters, wrap up long lines instead, eg:

function aFunction(argument1, argument2, argument3,
    argument4)
{
}

Long lines can be wrapped by the comma, open perenthesis characters.


Documentation

Preferably all public parts of the API should be documented since other people may use the API in their code. Only comment parts of the code that are not clear from reading it. Where ever possible use clear naming for classes, mixins, functions, variables and constants that indicate exactly what it does. This will help cut down on comments which can quickly go out of date through major code changes. Only include useful information in the comments that make it clear what a piece of code does, and why it is done that way. When handling exceptions that are going to be ignored always including a comment about why it is to be ignored.

Place comments just above the code being documented, not at the right hand side of the code, eg:

// Duration in seconds.
def DURATION;

Declarations

Place no more than one statement per line (this also apples to variable and constant declarations). Variable and constant declarations should only be placed at the beginning of a function, init, postinit, and class/mixin block. Do not declare variables and constants when they are first used (it can confuse people) like this:

if(arg1 > arg2)
{
    var temp;

    temp = arg1;
}

It is good practice to initialise variables when they are declared in order to make it clear what starting value or reference they have.


White Space

Each declared variable, constant, function should be on their own line, and two blank lines should separate variables/contants and blocks/functions, eg:

class aClass
{
    def const1;
    def const2;
    var var1;
    var var2;
   

    init
    {
    }

    postinit
    {
    }

    function func1()
    {
    }

    function func2()
    {
    }
}

Use two blank lines to separate class/mixin definitions in the source file. Each operator that is used needs to be surrounded by a space, eg:

minutes = seconds * 60;

Scoping

Keep internal class/mixin variables and constants private by omitting a scoping keyword unless there is a good reason to expose them externally. If a variable is to be read but not changed externally then use the public-read keyword, else if a variable is only allowed to be set once externally during object creation then use the public-init keyword. If a class/mixin variable or constant is meant to be accessed by sub classes/mixins then use the protected keyword.


Best Practices

• Try to keep recusion in each function to no more than 3 in order to make it simple to understand and maintain
  
• Try to keep nesting to no more than 3 levels with each object literal in order to make it clear what the sequential order is
• Do use variables to reduce object literal nesting by having object literals refer to them instead of embedding an object literal
  
• Avoid using names for variables, constants, functions and classes/mixins that are reserved by JavaFX Script if at all possible
• Minimise the use of binding since it can degrade performance in an application
• Use binding where a variable's value has to be constantly kept in sync with another variable since it reduces unessesary boilerplate code
• Use perenthesis to clarify the operating order for an expression (eg if((a == b) and (c == d)))
• Only use a single return statement (which is the last line) in a function, this makes a function easy to follow in sequential order