Top 10 Obstacles to Sql Developer Becoming a World-class Tool

Question

I've been working with Sql Developer day and night for the last 6 months.
On a positive note, the SqlDeveloper team has been the most responsive Oracle product team I've worked with in the 19 years I've been working with Oracle tools. They pay attention to their customers. It's noticed and much appreciated!
I thought I would share the biggest problems that I face with the tool on a daily basis, the kind of problems that make me want to work with a different tool each and every day.
My intent isn't to gripe, it's to focus attention on the biggest productivity drains I face using the tool. Others may have a different list, based on their needs. Without further ado, here is my top 10 problems list:
1) Quality Control.
I cannot count on critical portions of the tool working correctly. This includes an oracle database development tool that is incapable of extracting oracle ddl correctly and which is incapable of correctly displaying information about SQL Server data and database objects. It also includes destroying connection files and losing keyboard settings. When the product was installed, it was incapable of properly displaying code in a worksheet when I scrolled thru the code. The details are listed in other postings of mine.
2) Quality Control.
See #1.
3) Quality Control.
See #1.
4) Very badly done threading.
The tool locks up on a constant basis when it does a many tasks. Rather than let me work on some other task, I have to wait for it to complete. My current work-around is to have two or three sql developer windows open. That sucks life out of my RAM supply, but at least I can get some work done. And, of course, it will often completely lock up and never return, which means I lose all unsaved worksheets. This forum is full of postings about these issues.
5) Memory Leaks / Internal memory corruption.
If I've had the tool open for a few days, or really worked it hard for a day, I will get bizarre compilation errors that make no sense. If I exit the tool, re-enter the tool, and compile the exact same code all will be well.
6) Awkward and slow data entry interface for frequently performed tasks.
Example: I create a new table and want to start defining columns for it. I remove my hands from the keyboard to press the + button, then I have to set focus on the column name field (it should do that for me!). Now that my hands are back on the keyboard, I have to backspace the dummy "column name" value in the column name field (it should ditch that dummy value for me). Only after all that can I actually enter a column name. When I want to add a new column, it's back to the mouse again, for the same drill. The down arrow key should take me to a new column record, as should pressing return at the end of the last field in the column row.
7) Destroys code
Changing a column datatype from varchar2 to nvarchar2 destroys the length of the column. Changing a field on a view destroys the instead of triggers. This is bad. There is no warning that this this is about to happen, which would at least give us a chance to avoid the problem. Better still, of course, would be not destroying that data.
8) Inaccurate checking for record locking.
When I try to edit records in a data grid for a table, I often get an error message telling me the data was modified in another session. It is simply not true. A hand-written update statement in a sql worksheet will work just fine. I've seen posts in the forum discussing this issue. An Oracle database development tool unable to reliably update oracle data tables is embarrassing. See Obstacle #1.
9) Unicode support
Sql Developer is heads above all the other tools I've tried out on this topic.
However, the configuration of the tool to provide unicode support needs to be simplified.
The tool needs to recognize the encoding of the files that are being opened up. On Windows Vista, Notepad seems to infallibly pick the right encoding for the file when I open it. Sql Developer should do the same. Files have specific encodings, the tool should have a default encoding (that I can override). Right now, the tool has a specific encoding and expects all files to match it. Extracting ddl to a worksheet does not respect the encoding choices of the tool, either. It only works with a limited set of tool encoding choices.
10) Resources
Does the sql developer team have the resources they need to compete with vendors like Microsoft? One really big reason for picking sqlserver over oracle is the ease of use of the Microsoft front-end tools. It's not until later that they may realize that Oracle has more capability, but that's still a lost sale.

Answer 1

We are acutely aware of quality and with each release work at improving this. Providing a polished, professional and ultimately user friendly and useful tool is our constant goal.
The broader our customer base grows, the more demands we have. This is a good and exciting position to be in, although it might mean that we need to slow down on our release cycles.
Release 2.0 should address more of the threading and memory leaks displayed as the team have rewritten some of the sections. As for resources, it's true we're a small team and we get on with the work that we do.It might be a little slower than some would like, but I'm not convinced that having large team is necessarily always the answer.
As ever, some of the points mentioned could be added to the Exchange. We'll be reviewing and updating the Exchange again in the New Year.
I think there is another point to add to your list. A lot of what the tool is and will become is from a positive customer interaction we have had to date. While we continue to grow this, I think the product will grow and improve. The forum and all the positive interactions that happen here are key to taking the product forward.
Regards
Sue