[eclipse-dev] commentary on the 3.3 plan

["Brannon King" <brannonking@xxxxxxxxx>]

First, I apologize for not being around to help create the plan. Second, I
apologize for posting this on the platform newsgroup without realizing it
should have been posted to this list instead. Third, this document is
probably offensive, but I mean it in the best way possible. If I were better
with words and feelings, I would change it. Anyway...

First critique: the items listed under "Components" are so general that 
they're immeasurable. I'll assume that their description is filled out in 
their associated bug listings.

I think you are right on the money with the enhancements for launching 
support. The more we can clarify that, simplify that, expand that -- the 
more we can easily create other development tools (and not to mention that 
the thing is darn confusing for first-time users!)

Concerning the port of SWT to win64. That is going to be a beast. It's 
bigger than anyone thinks because all over the place we have hard coded 
pointer sizes. It's especially bad in OpenGL selection code and other custom

io buffer stuff like the nio (and all the uses of it). This is a must-do, 
but it will be the cause of bugs for years to come. I think most projects 
have been smart enough to store their win32 handles in "long", but this will

certainly expose everyone else! The thing is: this issue is going to happen 
all over again when we move to 128bit OS. We need to handle the sizeof issue

right during this fix or we're toast next round.

I think JFace has more fundamental problems than not supporting the entire 
SWT widget set. How about making JFace objects have similar APIs (to reduce 
the learning curve)? Or making their API similar to the SWT widgets (to 
reduce the learning curve)? Or giving reasonable access to the widgets they 
contain?

"GTK Printing". Okay. We have serious issues with printing. This is one area

where cross-platform things fall to pieces. This needs to be addressed in a 
major way. We need cross platform printing APIs that provide a range of 
options (collate, selection, quality, etc.) on all platforms. (They can 
provide the superset if a particular option set is not available on a 
platform.) Bugs like this (basic daily use functionality) that are not fully

supported should be first priority.

The other bug like the printing option support is that of tooltip support. 
"tooltip" does not even show up in the plan, yet a bug search on it shows 87

open bugs. There are some cross-platform issues here again. But 87 bugs! Any

keyword with that many bugs ought to be on the 3.3 plan, don't you think? 
The document in general tends to lead away from bug fixes in favor of new 
features. I'm not real sure that is wise. It seems about time that we step 
back and do a serious bug-fix round. 3.2 is getting wide usage; the bugs are

piling up by the thousands.

"Provide access to more native controls" Uh, to be honest, I think this is 
exactly the opposite of where we want to go. I thought we were working for 
cross-platform execution, not the other way around. I would love a nice 2d 
table widget. Numerous other people would as well, but not at the cost of 
losing cross-platform support. Nobody minds a custom-drawn table that looks 
nice. The current 1d tables in SWT look great. We don't need MS's 
ComCtrl.dll (or whatever) for that.

"Performance Focus". I think performance is doing pretty darn well. The only

time I notice significant delays is on creating contextual help or when the 
reconciler runs. I think those issues are going to go away as we all get 
dual-core processors. If you've got time to work on performance, I'd rather 
have more MMX/SSE/2/3 support in the JVM. It seems to me that is the most 
bang for the buck. Memory is not an issue unless you're an embedded system. 
(And in that case, preferences to disable features are a better way to 
reduce memory.) Heck, let's use more memory for the contextual help, for the

reconciler, the code completion, file streams, etc., and make those faster.

And one more nitpic: From the document: "Java 1.4.2 platforms are used for 
most Eclipse development". Bunk. The 1.5 is good and stable. It's been 
around for a while now. It's on all the development machines in my office. 
Now having said that, I think it's great that we keep things well tested in 
1.4. However, I see no reason for new APIs to support 1.4. And I feel for
all those 
whose company IT nazis have yet to approve 1.5 ;-)

Thanks for the good work.
______________________________
Brannon King
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯