My Top 5 JDeveloper Tech Preview 3 Annoyances March 4
Tech Preview 3 of JDeveloper was released around Christmas, which made a nice present for those of us concerned with such things, but as much as I hoped it would fix some basic issues, instead, it added some missing features that I didn’t really need yet and did not address some of the more, in my humble opinion, important issues.
Of course, some of this is perfectly understandable, but I hope the good developers and product team over at Oracle realize that there are a couple of basics that need to be addressed if JDeveloper is ever going to make it to the mainstream. Here is a short list of some of the items I found in Jdeveloper that bug me.
1. Fix the in-editor code checking. Sometimes I swear this actually works, actually, I know it does sometimes, but other times it doesn’t pick up on basic errors (like duplicate method signatures in a class) until the compiler finds it. This is a basic of all great IDE’s and is one of the biggest issues I have with JDeveloper right now.
On the plus side, it has a somewhat decent editor checker for some of the declaritive properties and Groovy expressions which leads me to my second point.
2. The expression editor is cool and great idea, but at the moment, it doesn’t provide all of the functionality it should. For instance, not all the keywords available are in the editor and sometimes it marks things as invalid (though does not prevent you from using them) even when they are actually valid. Having everything that you could use in the current expression available to you in the editor would be a huge help, instead I find myself combing the web for “Tips and Tricks” articles to find those keywords I need.
3. Fix the property editor. As nice as it is to have the property editor so you don’t need to worry about the names of all those properties and edit the source code directly, it would be nicer if you could fill in a property and not need to click on something else (or remember to press enter) in the property panel to get JDeveloper to recognize the change. While it becomes second-nature after a while (as does saving after virtually every change), it is really a problem that needs to be addressed.
4. CVS integration leaves a little to be desired. The synching with the server doesn’t seem to work right, and files that are found under the .adf folder and src folders are not added to the project, or if they are, aren’t updated or synced correctly. Other times, synchronization with the CVS server seems to be a little flakey, it doesn’t always catch all the changes and sometimes you need to restart JDeveloper to force it to. On the plus side, some of the merging works really well. And yes, I know, CVS is sooo 2005, but it’s what we happen to be using right now.
5. It may be a little ahead of it’s time. I say this because it apparently was developed with the idea that all developer have 3600X2100 screens to develop on. I unfortunately am limited to 1680×1050 when my laptop is docked and it just isn’t enough real estate for JDeveloper. Maybe in 5 years when my montior is double the size and I have an updated video card I could make use of all the panels that are displayed at once. What I may do in the intermin is hook up another monitor and see if detaching some of those panels and putting them on another screen helps at all, I assume it should but I wonder how well that will work.
As I mentioned, this is a Tech Preview of the product (Tech Preview 3) so there is ample opportunity for them to fix some of these issues and I am sure a few of them will be addressed. I just thought I’d throw them out there to vent a little and see what the rest of the community has to say.