| Eclipse stability [message #988457] |
Thu, 29 November 2012 19:20  |
Eclipse User |
|
|
|
We have been developing a custom application using Java and Eclipse for three years now. Our intention is to convert from a custom app to a mass market app.
We have experienced many issues which make little sense to me. I am not a programmer but reside more at the design and user interface level. I worked extensively with a 4th GL data base language for over 17 years ago back in the late 80's and 90's so my experience is based on my knowledge of this environment.
Issues: we are experiencing a lot of disfunctionality when running the programs often forced to re-start the application to get around the problem.
1) Screen design. Our programmer tells me that he uses math formulaes to design screen layouts. It takes him forever and we find that field lables etc. rarely line up exactly where they need to be. Also Eclipse does some weird things to the screen like change the font size or move a field or drop a field altogether when loading. In the old days, we could design a screen in seconds with language tools that allowed quick definition of the field, the attributes and and a click and drop capability to move fields where ever you wanted. It would only takes minutes not hours or days. Is our programmers' methodology correct or are their better and more stable ways to build screens?
2) The "Enter" key. According to our programmer the "Enter" key has special status (I may not be phrasing this correctly) and requires programming around each "Enter" click to make it work. We need both the "Enter" key and mouse to move the cursor around the screen. This makes little sense to me especailly given the unique nature of the "Enter" key.
We have programmed all our "Enter" statements accordingly but is this true? Is it this big of a pain to get "Enter" statements to work"?
3) We can only output to programs like Excel or Adobe to print reports or internal documents like sales orders and invoices. We cannot make a printout our own reports inside our program. I've never heard of this limitation to a programming language before.
4) General stability - the program has to be re-freshed on a regular basis. From what I can tell the program is not currently compiled. If you look on the task bar there can be 5 - 8 screens open. I can click on any of them and that screen will load. What repurcussions are there if you do not compile the program before running it ie: run time.
We know that there will be a re-write to make the application less customized and more suitable for a mass market so we want to be able to move forward with a better understanding of Eclipse and Java.
Thanks for any and all comments.
Ken
|
|
|
|
| Re: Eclipse stability [message #989917 is a reply to message #988457] |
Sun, 09 December 2012 21:03  |
| Eclipse User |
|
|
|
Hi 'reader',
I'd like to add a short comment. Firstly Extreme Java's contribution is valid the specific queries will be more efficiently resolved/discussed in specific forums.
That said, I too would like to see a more robust Eclipse platform. My motives are simple -- Eclipse is EXACTLY the kind of tooling you want 'everyperson' to access.
My experience to date would not lead me to recommend Eclipse to my historian brother. My experience so far doesn't suggest that eclipse is entirely stable for everyday use by the non-technical majority.
Case in point. At some stage the WindowBuilder Pro add-in stopped working on Juno. Experiments demonstrated that WindowBuilder was working on a clean Juno install, but it was failing on the supposedly up-to-date development platform I was working on. That error came up about August 2012. Very few people can just sit about if a key element of the development tool set fails. It just isn't practical.
For me I had commitments and other things to do. It was only this last week when I had more slack time to look at the challenge that we even determined that WindowBuilder IS working.
The problem logically then is the Eclipse installation with updates, plugins and add-ons I was running. I'm wiped Ecliped (circa august) and reloaded WindowBuilder.
I'm left with many challenging questions about robustness, tracking down conflict and compatibilities. In the wild, I think there needs to be some tools investigated to let 'average' users manage their add-ins, configurations, etc. I was disappointed to find the [Revert] function can cause more problems than it might promise to address.
On the bigger stage, I think the idea of OSGi is a bit too powerful and needs some helper tools to moderate things as a multi-bundle platform such as Eclipse brings in new modules. You can't expect bundle developers to 'know' about every available bundle or new bundles not yet developed. The best thing in my opinion is for a 'management' and 'administration' arm to assist when things get mixed-in or when mysteries manifest.
I trust there will be some sober consideration of these points. Perhpas others are aware of initiatives along the lines I'm encouraging for a robust, 'comfortable' Eclipse.
thanks,
aplatypus
|
|
|
Powered by
FUDForum. Page generated in 0.47662 seconds
Home