Programming with
a dose of satire.
Soapbox
|
| ||||||||
 |
 |
|||||||
|
Soapbox |
||||
10 Things NetBeans Must Do to SurviveBy Matt Stephens Update (November 16, 2003): Since this article was written, a new release of NetBeans, 3.6, has been announced - along with a completely rewritten windowing system. So a couple of items from this article can now be safely crossed off the list. We review an early development release of the new windowing system here.
When I first started using NetBeans (years ago), the alternatives were a text editor with Javac, Visual Café (which sure crashed a lot – it was sometimes referred to as Visual Crashé), or JBuilder (which at the time was doggone slow, and doggone expensive). NetBeans stood head and shoulders above these “alternatives”. However, the competition has been fast catching up for a while. In some cases it’s painfully evident that they have even overtaken, and left NetBeans chewing cud contentedly in their wake. So with that in mind, I’m presenting some open-minded suggestions (in no particular order) for things that I believe NetBeans absolutely must do in order to remain relevant – not just that, but to leap back to the front of the pack, and stay there. This shortlist is really based on a combination of personal frustrations with using NetBeans and programming the OpenAPIs, and observations of the IDE-related things that currently seem to make other programmers "tick". So from that point of view, it's a "personal" shortlist - but I've also tried to be unselfish with the list, and to base it on what I genuinely think the NetBeans project needs to do in the near future. I should also point out that I'm actually a great fan of NetBeans, but here I'm mostly focussing on the negative things - because, well, that's what we do on this site...
1. Improve the windowing system The windowing systems in both Eclipse and IDEA are lovely. They look the part, and they feel kind of groovy when you drag the windows around. When something this fundamental is just right, it almost doesn’t matter if the rest of the IDE is lacking in features. The windowing system has historically been something of a problem in NetBeans. In earlier versions, every window – filesystem explorer, title panel, each Java editor and so on – had its own first-class window (clogging up the Windows taskbar). This was thankfully fixed. In more recent versions, if you drag an editor window across its shiny purple JInternalPane it judders painfully across, even on powerful 2GHz+ PCs. The biggest problem, however, is that the windowing system just doesn’t work the way it should. We ran some usability tests at our company (because one of our projects is based on the NetBeans platform), and it was noticeable that several people were confused by the differences between “attaching” a window and “docking” a window. Why’s there a difference? To make matters worse, windows can also be made to “reside” in different places. There should just be one operational metaphor, and all window operations should cling rigidly to that metaphor. Keep the windowing system as simple as possible, and keep it consistent! Ideally there shouldn’t need to be any menu options at all for manipulating windows (though it’s important to have them there as a secondary control, of course). The user should be able to “snap” windows next to each other, and drag them away again. Where appropriate, they should also be able to “drop” a child window inside a container window (e.g. drop a Properties panel inside the Explorer panel). Once it’s there, it should be easy to simply drag it away again. At the moment in NetBeans, windows are a pain to manipulate. The menu options are non-intuitive, which is a shame because the only way to manipulate the windows is through the menus. Another problem is that the windows love to jump out of the IDE and go exploring in the Windows desktop. Either it’s an MDI application or it isn’t. At the moment NetBeans sits in a sort of undecided middle ground, where it sometimes behaves as a “sovereign” full-screen application, and sometimes behaves like a cluster of separate windows. The windowing system gives the impression that (along with the rest of the UI) it’s been designed by programmers. This wasn’t so bad when NetBeans was “just” an IDE, but now it’s also a platform for building other applications (not just for use by other programmers). Non-technical users are using the platform as we speak, and likely being horribly confused by the confused mess of a UI. The good news is that the NetBeans windowing system is being rewritten for NetBeans 4.0. Apparently an early release of the new system will be available later this year – let’s hope it cuts it in all the right areas! The initial indication, from this interview on netbeans.org, is that the new UI has been designed by programmers again, rather than an independent usability expert. It seems that little thought has been given to the ways in which users will want to use the windows on a day-to-day basis. I’m hoping to be proved wrong though!
2. Improve Usability Despite its great features, NetBeans isn’t always particularly usable. In fact sometimes, it can be really frustrating. I’ve covered the windowing system (which I really do find clunky and embarrassing); other issues include: The Options panel. The options panel is, dare I say it, a confusing mess. Low-level NetBeans platform options are mixed in with application-level options. It’s very difficult to find what you want. Often you think you’ve found the options for a particular item, but it turns out to be just a declaration of that item’s existence! (There are moves afoot to improve the Options panel – these improvements can’t come soon enough). Properties panels. Two problems spring to mind: first, there’s no obvious difference visually between the read-only left side of the panel and the writable right-hand side. The other problem is that when you want to edit something on the right, you have to click the field twice. Why? (To be fair, the Properties panel has actually been rewritten ready for 4.0, and in fact the new version looks amazing. I can’t wait!) The GUI editor. The editor itself is fine, and in fact is one of NetBeans’ strengths. However, the default window layout just always seems wrong, and never seems to be in the same place next time you reload the IDE. Frustrating. The wizards can also have a slightly clunky feel. Sometimes when you intuitively press Enter to confirm something or move to the next panel, the IDE just pings at you instead. (Also see the comment about keyboard use later in this article). I could list several other UI “annoyances”, but this probably isn’t the right place. The right place should be the UI section of netbeans.org, but it doesn’t seem to have a huge amount of activity. True, the UI has improved in recent versions: but it still has a long way to go. To survive, NetBeans really needs to focus on usability. That means approaching everything in its UI from a task-oriented perspective: analyzing what people are doing and why, and removing anything which detracts from those tasks.
3. Improve the Default Look & Feel Unless there’s an unbreakable mandate from Sun that NetBeans must ship with the default Metal look & feel, the team really should follow the example of IntelliJ and ship with a UI that makes the first-time user gasp with joy and appreciation, rather than cringe at this ugly monster facing them. You might think this is a trivial issue, but we programmers are surprisingly driven by form and aesthetics. It matters enough to make programmers like or dislike the IDE from first appearances – and that counts for a lot. This problem might in fact be fixed with the release of JDK 1.5, which supposedly will have an improved default look & feel. They may even get rid of the intense, shiny purple background. We can but hope.
4. Keep Enhancing the Java Editor The NetBeans crew are probably already thinking: “Jeez, there’s no pleasing some people!” In fact, NetBeans’ Java editor is already very, very good. I was using Eclipse recently, and found myself really missing some of NetBeans’ ease-of-use features. But there’s always room for improvement. Get complacent, and the competition will quickly overtake. Additionally, because the Java editor is essentially the core feature of the product, it needs to be the thing that genuinely “wows” people. Its creators need to constantly strive to find new and innovative ways of making Java programming faster and easier (generally this means less keystrokes to achieve repetitive tasks). So, this is a bit of a cop-out suggestion on my part because I don’t have anything specific to suggest – just generally “keep up the good work, but don’t stop there!”
5. Slow Down on the APIs The NetBeans APIs are evolving at a rapid rate. This is, on the surface, a good thing, because it’s a sign that the product is continuing to develop, to have new features added, and also that it’s being redesigned internally to generally make it better. The problem arises because it’s so darned complicated to find out how to do anything in NetBeans. The recently released NetBeans book [amazon.com], though useful and packed with detail, was obsolete in certain details before it even hit the shelves – the APIs are changing that fast. It’s even worse now that NetBeans 3.5 has been released, and the TopManager class has been removed. This means that nearly all the examples in the book don’t even work. Bad decision! (The examples can be made to work via openide-deprecated.jar, but a user who’s just bought the book to learn how to program NetBeans would not know this. Surely the stuff in the book should “just work”?) Really, the team now needs to hit upon the preferred API format (XML seems to have become the preferred choice, allowing modules and UI elements to be plugged into NetBeans in a “declarative” fashion), and concentrate instead on the features. The APIs themselves should not have to change at such fundamental levels any more. Additionally, somebody somewhere really needs to hit the “reset” button, move all the old documentation (including mailing list archives) out to an archive area of the website, and start afresh with relevant, up-to-date documentation focussed exclusively on the latest version. No historical baggage to overwhelm people who just want to find out how to customise the properties panel, for example. Version 4.0 should be a perfect opportunity to do this.
6. Make the APIs Simpler This item conflicts with the previous one, because of course you can’t make the APIs simpler without fundamentally changing the APIs (and probably breaking backwards-compatibility in the process). But NetBeans would definitely benefit from a simpler API. If NetBeans is supposed to be a suitable base for building new applications, it needs to be as easy as possible to build those applications. Currently however, NetBeans’ flexibility (a good thing) makes custom module writing a very complex task (a bad thing). The main competitor for NetBeans in this area isn’t Eclipse, as you might think – it’s simply “rolling your own”, building a Swing application from scratch, adding in APIs as needed rather than building on top of a core platform of APIs. If you’re building a complete application rather than a plug-in module, then currently it only really makes sense to build on top of NetBeans if your application is also a type of IDE. Currently a lot of classes need to be extended just to do fairly simple things (like define a custom file type and launch the file into its own editor). It would be nice just to be able to define, say, a MyFileType class and a MyFileEditor class, and bob’s your uncle. Unfortunately there are a lot more hoops that need to be jumped through. Another issue is that there is an awful lot of crossover between the APIs. From an aspect-oriented perspective, “concerns” twist and turn through the different APIs like ribbons, with no respect for boundaries. To use the previous example of loading a custom file, this relatively simple process involves trekking through various classes in the Filesystems, Explorer, Nodes, Datasystems, Actions and Window APIs to get the job done.
One possibility – which solves the above issues – would be to add a simplification layer in front of the OpenAPIs, so that “power coders” who need this extra flexibility don’t have to lower themselves to a stunted, Visual Basic-style API (from their perspective). For the rest of us, a much simpler “ClosedAPI” would suffice a lot of the time, and sure would speed up development time (not to mention reduce maintenance costs as there’s less code to maintain, and reduce training time to get new recruits up-to-speed on the requisite APIs). Most of these classes should extend what’s in the OpenAPIs, and for the most part should simply provide a default implementation of the stuff that we mostly find we have to implement regularly for various tasks. That would make it easy for the user to override whatever bits they do need to customise.
7. Lose the “NetBeans is slow” stigma Version 3.5 primarily addressed performance and responsiveness issues. And in fact, today’s NetBeans really isn’t too shabby when it comes to that “snappy” feel. But the stigma still remains. Mention NetBeans in a crowd of Java programmers, and the first response will probably still be: “Ugh, slow!” So the slowness stigma is more to do with image and perception than with actual slowness. In fact, now that NetBeans actually is faster and more responsive, the remaining stigma could be addressed by making the UI more aesthetic. If it “seems” whizzy, then users will simply appreciate it more. Similarly, keyboard use should be examined more closely, and attempts made to make the UI more usable using only the keyboard, with as few keystrokes as possible. This means the input caret going to the right place after the previous option was selected. The user will love you for this simple courtesy. And he will get the impression that the IDE is more responsive – because it takes him less effort to get things done. An example of where NetBeans gets this right is when you load a new file into the Java editor. The input caret goes into the editor window, ready for typing without an additional mouse click. But there are loads of other places that should do the same thing, but which don’t. Plus, on a practical note: on startup, the IDE has lots of stuff enabled by default, which makes startup slower. Much of this should be switched off until the user asks for it – Tomcat especially.
8. Offer built-in refactoring support The competition has leapt ahead of NetBeans on this one. Developers have been clamouring after this for a while now. The response on the NetBeans-users mailing list has been that it isn’t that big a deal, and anyway there’s a commercial module available that you can pay for. Refactoring is increasingly a fundamental ingredient of modern programming, and programmers are rightly demanding refactoring tools as a basic standard part of their IDE. Test-Driven Development (TDD), which makes heavy use of refactoring, has been popularised by agile methodologies (particularly extreme programming). People nowadays expect their IDE to offer refactoring as standard. If it doesn’t then the IDE just seems incomplete. NetBeans already has excellent support for JUnit, so it’s a real shame that they seem to be ignoring refactoring.
9. Make More Noise No one’s really talking about NetBeans in the industry. However, everyone’s talking about IDEA and Eclipse. It’s depressingly noticeable. The release of RAVE might help, but then people will be mostly talking about RAVE not NetBeans (even though RAVE is based on NetBeans). NetBeans needs more press releases and interesting projects (refactoring springs to mind!) Eclipse has “bagged” the prestigious AspectJ open source project (even though it isn’t in any way exclusive to Eclipse). NetBeans badly needs to get on the aspects bandwagon. An AOP module, for example, could allow debugging of aspects in some innovative new way. Aspects could also be woven into the NetBeans platform. If it’s built from the ground up with aspects, then NetBeans development should generate developer interest in all the right ways. People also need to be made aware of just what NetBeans is already capable of. The existing projects need to be highlighted more often. We should be seeing articles like “Unit testing with NetBeans” in programmer magazines.
10. Stop using that… brown colour scheme on their website The colour scheme is more important than you might think. It isn’t really a matter of taste (some people are bound to chime in that they like the brownness). Instead, it’s a matter of image. NetBeans needs to put forward an image of hi-tech, modern, cutting-edge software development. The brownness just doesn’t help. This was an affliction that used to affect Java itself, until Sun apparently caught on and moved away from the brownness. The connection was probably Java coffee beans… brown. And probably the same thought process has gone on at NetBeans.org. Unfortunately, the brownness just makes the product seem old-fashioned. It’s great to be different, but not at the expense of your product’s “street-cred.”
NetBeans has the apparent advantage that it’s the official Sun Java IDE. However, this isn’t that big an advantage in reality. Programmers will just use whatever IDE they feel “hits the mark”. A big advantage that NetBeans does have is that it’s still a great IDE. It’s full-featured, well integrated, has good built-in support for CVS, XML, Ant, JUnit and so on. It’s also a decent base on which to build a better IDE. Given what the IDE is already capable of, the suggestions in this article might seem almost trivial. However, they’re also the reason why NetBeans is rapidly losing both market share and developer mindshare. The NetBeans developers (for whom I have a huge amount of respect) need to focus on the right things in order to bring NetBeans back to the head of the pack.
Talkback: Have Your Say Message Index:
The Messages: truthful listFor specific comments about the editor, one need to look no further than eclipse. Quick diff, parameter code completion, code formatting, code indentation, fully integrated problems list, and the outline view are all keeping me from switching back to Netbeans. The sad commentary is that eclipse actually feels slower than Netbeans on linux, particularly in the editor. Anonymous person Tue Oct 28 04:53:22 GMT 2003 As a new netbeans developer.. ..I have to say I agree pretty much competely with all the points raised in this article (although of course I feel a point '11' should be added..) Writing modules in netbeans is not easy, getting accurate documentation to help with this task is *hard*. Struggling through the only book available which is outdated upon release is not an ideal introduction. A simple feature like being able to search all of the archived netbeans mailing lists at once for a keyword would help, since the search on the site does not seem to include these archives. My own IDE improvement requests would include the 'find usages' functionality that I find indispensable in IDEA, and this is probably the major reason I've not completely converted to netbeans yet. I hope that some, if not all, of the points mentioned in this article make it to a subsequent release. Here's looking forward to version 4! Monica monica@edonica.com London, UK Tue Oct 28 10:50:06 GMT 2003 Sun and Eclipse Hello, A while ago I saw an article suggesting that Eclipse would become the definitive OpenSource IDE as Sun have agreed to contibute towards Eclipse while IBM have agreed to release any exclusive interest that they may have had in Eclipse, or something like that. This seems to inidcate that Eclipse becomes more of a strategic choice of IDE. It seems to have industry momentum behind it. Is correcting a list of technical issues sufficient to keep NetBeans ahead of the pack? Bernard McGranaghan bmcgranaghan@o2.ie Tue Oct 28 14:11:00 GMT 2003 re: Sun and Eclipse Keep in mind that Java programmers seem to choose their IDEs by personal preference, rather than by which IDE is "official". For example, NB is currently the "official" Java IDE, but for most programmers that's neither here nor there. So even if Eclipse became Sun's new "official" IDE (which I seriously doubt, by the way), it wouldn't hugely affect programmers' choices. Eclipse currently has industry momentum simply because it's a popular choice of IDE. It has the right "check-marks" for a lot of programmers; and it also has a LOT of publicity, much of it self-generated. NetBeans similarly has the right "check-marks" for many people (myself included), but needs more than a little tweaking, in both technical and marketing areas, to make it the compelling choice for everyone else. Matt Stephens London, England Tue Oct 28 14:21:06 GMT 2003 brown color scheme I don't know if the NetBeans team should bother spending any time on this... or at least it should be at the very bottom of the list priority-wise... Eclipse's web site looks far worse (it's hard to navigate in a addition to having a bland color scheme) and Eclipse is doing great in mindshare Anonymous person Tue Oct 28 15:05:58 GMT 2003 eclipse fan Our team converted to eclipse six months ago, and we all love it. It really would take a lot for us to ever consider moving from eclipse, especially if eclipse adds gui editing. AK ak@ak.com CA Wed Oct 29 01:24:35 GMT 2003 Eclipse plugins don't work or only work with Eclipse 2.0. Netbeans has more features. Ivan Wed Oct 29 05:15:31 GMT 2003 I'll disaggree on some points For starters about the "make more noise" part. Sorry, I'm fed up with technologies that live on hype, instead of merit. (See your own "software fashion" article.) More noise means just that. Some clueless manager will choose NetBeans for us, regardless of what the team wants, because the nice marketing man from Sun told him the usual bulls**t. ("Buy our revolutionary Snake Oil (TM) Enterprise Edition, and you make better programs in half the time, with half the team, with any clueless retards off the street as programmers. Oh, and it will also solve world hunger and help fight AIDS and cancer.") No, thanks. Believe it or not, I've used a ton of IDEs before, including several versions of JBuilder, NetBeans, Symantec's Visual Cafe, and ranging all the way to obscure things like Bluette. When I chose Eclipse, it's because it just works, and does everything like I want it done. Not because of hype, not because of "making noise", not because it's the latest buzzword to have on the resume. It just was better. Whereas NetBeans is a beast that should have been burried at crossroads, with a stake through its chest. Every version I've tried was _that_ bad, clunky, slow, bloated, etc. Maybe 3.5 is now faster, but the bitter taste of the versions I've tried will stay with me for a while. Including one aspect that you don't mention: the retarded idea of saving serialized classes instead of config files. Every single upgrade of either NetBeans or the JVM left it utterly unable to read the existing configs, and had me spending more time configuring the exact same things again. Basically: if you like NetBeans, good for you. I'm not gonna discriminate against you for that. But if you argue that hype should be used to push it down our collective throat, that's just plain wrong. Then the color scheme of the site. Who gives a damn about that? I've used tools and plugins off sites with some ludicrious scheme, like green on neon blue, if the tool was doing the right thing. About the GUI builder, personally I think _all_ current GUI builders should be shot at dawn. They produce code that's a fscking nightmare to extend, maintain, refactor, or apply different look & feel modules to. And most often than not, they encourage novices to just use fixed positions and dimensions, which will be a flipping disaster as soon as you: - internationalize the text (different button sizes) - run the program on another platform (e.g., font sizes are slightly different in Linux or MacOS than on Windows) Which is the whole idea of Java. - run the program on a Windows machine set up to use "Large Fonts" (Yes, some of us actually use large fonts.) - try to change the look & feel etc. Trust me, I've tried almost every IDE available. My advice would be: avoid those nice GUI wizards like the plague. Learn what a layout manager does. Learn that well. That's how good GUIs are made. (Until someone makes a non-retarded GUI builder, but I wouldn't hold my breath.) Moraelin Wed Oct 29 07:46:39 GMT 2003 TopComponent was removed? Correction You probably mean TopManager and not removed but deprecated. TopComponent was not definitely neither removed or deprecated. Marek Thu Oct 30 14:07:41 GMT 2003 re: TopComponent was removed? Correction Yep, I meant TopManager. I've corrected the article - thanks for pointing that out. Matt Stephens London, England Thu Oct 30 14:20:15 GMT 2003 Re: I'll disaggree on some points > personally I think _all_ current GUI builders should be shot at dawn Have you ever used NB GUI builder? It does encourage usage of layout managers and handles them well. Nenik Thu Oct 30 14:50:52 GMT 2003 Re: I'll disaggree on some points >Have you ever used NB GUI builder? It does >encourage usage of layout managers and handles >them well. I agree, the NB GUI builder is particularly good when it comes to layout managers (its "customize GridBagLayout" editor is especially good). I often use the GUI builder to get a quick start on something - for this it's ideal. Then once all the main components are in place and I've moved them around to get the layout right visually, I remove the .form file and the read-only tags, and edit it manually from there. Works well for me, although others might think this is a ludicrous approach! Matt Stephens London, England Thu Oct 30 17:11:00 GMT 2003 NB misses some important features while those present are hard to use I couldn't agree more. I've been wanting to try NetBeans for quite a long time but never got around to. I usually use Eclipse 99% of the time I'm doing Java. Recently I had to do a bit of UI design and that was when I installed NB. UI design was ok. I liked especially the graphical editor for the GridBag layout manager, although that somehow kept changing its own layout. I find the code generated for event handling a bit strange: why introduce a nested class that does nothing but forward the call to a method of the container? But these are peanuts and on the whole I liked the UI editor. But before I could use it, I had to go through the mounting and config hell. It took me quite some time to understand the handling of CVS and especially the role of relative mount points; you don't have to use them and compilation works ok but then code completion fails. No warning or hint, that the packages aren't where NB would like to have them. Of course I compare this with Eclipse, and there it's so much easier: create a project from a CVS resource, check it out and then declare, which are the source folders, which jars to use etc. Pretty much straightforward. And then handling of updates, commits and merges: the synchronize view of Eclipse is extremely valuable, because one can see what will happen before commit, one can choose which files to checkin very nicely and one can even choose which changes to commit or revert. Configuration: I didn't want the classes to go into the same directories as the sources. But the setting is hidden in some compiler option setting, while I would expect this to be a project setting. And btw, I can configure a lot of compilers but I didn't find out till today how to choose the compiler for the project... The features I'd be *really* missing are the refactorings and the code navigation goodies in Eclipse, especially the search for all callers. It's one of my top 10 used features of Eclipse. To sum it up, NB misses some important features while those present seem to me quite convoluted and hard to use. The UI editing is fine as far as I'm concerned. Robert Klemme bob.news@gmx.net NRW, Germany Thu Oct 30 20:55:32 GMT 2003 Agreed about hype I agree, hype is not desirable - hype being defined as getting people to try something by promising something that you don't actually deliver. That nearly always backfires - you can keep people hanging on for a while if they believe that what you promise is just around the corner - but only so long. I'd go so far as to say that's exactly what the tech stock crash was and is about - an entire industry drunk on its own hype, and making so much paper money that actually delivering on the hype was just not interesting, when it was even possible. But lets distinguish hype from marketing. The two are quite distinct, but it is true that a large enough amount of hype can eclipse (small e) communication about real things that can help people solve their problems. Marketing, at its best, is telling people what you *do* deliver so they know that what you deliver is a choice available to them. The fact is that NetBeans offers a lot, and a lot of people don't know how much. There's nothing wrong with with communicating those things - the fact that people posting here know about Eclipse at all is testimony that such communication is an important thing. Tim tboudreau@sun.com Prague, Czech Republic Fri Oct 31 19:37:50 GMT 2003 Eh I don't know NB's latest incarnation of a GUI builder, since the last time I actually used a GUI builder was in 1999. It also ended up with me ripping out that horrible code and replacing it with a my own implementation. That implementation also included a custom LayoutManager implementation. It included the client's style rules for forms in the LayoutManager, and made it far easier to change those rules and have all forms automatically adjust, than going through all that forms with a GUI builder and a magnifying glass. When later they came and wanted more forms, and the existing ones changed, it paid off. However, I still keep seeing newbie implementations that were created with a GUI builder. Invariably they're a bloody disaster. If you see code with hard-coded coordinates and hard-coded colour values in the source files, you can bet that someone used a GUI builder there. Even if some of those people even knew what a LayoutManager does in the first place, after a year of drag-and-drool editing, they've invariably forgot everything and are setting properties (like fonts and colours) directly into the GUI builder, just because they can. Then the client wants a different look and feel. Oops. Now you have to go through hundreds of files, hunting down the hard-coded assignments that the GUI builder generated. Then the client comes (yet again) with different style rules. Like they had a rule that said "the distance between label and field is 3 pixels, except on thursdays with a full moon, when it's 5 pixels", and now they want it change to "the distance between any 2 components is 4 pixels, but the label and the edit field must be accurately aligned at the baseline, not at the (invisible and irrelevant) border of the label." Oops. Now it's back to going through all the forms with a magnifying glass, to align everything to the pixel. Too bad everyone is by now scared silly of writing a layout manager, because they can hardly even remember what one does, eh? So, well, basically I'll still steer clear of them. It also creates an unneeded lock-in. Just as I don't want my final .jar to work on one single platform, I don't want GUI code that can't be even read by a different IDE. Nor even read back by the same IDE after an IDE or JVM upgrade, in some cases. Nor be processed any further by the same IDE if someone dares touch that code by hand. Etc. I've switched IDEs before, and I've worked in teams in which everyone was using a different IDE. (Including the mandatory two Unix guys who use respectively emacs and vi, in a cygwin window.) Do I want to have stuff which can only be edited in one IDE at all? Nope. Do I want to get bogged in endless meetings to decide a standard mandatory IDE for the whole company? Nope. Been there already. With everyone screaming bloody murder and threatening to quit because everyone else's proposals don't support some obscure macro or keyword combination that they absolutely can't live without. Are such meetings and "strategic decisions" even productive anyway? Nope. If someone already has the skills and motivation based on their own favourite editor, forcing them to change is hardly ever productive. Etc. Basically, no thanks. I'll take having clean, well documented code over depending on a particular GUI builder and version thereof. Moraelin Tue Nov 04 00:04:13 GMT 2003 Netbeans, Notbad I haven't tried out eclipse, but I love netbeans. I recently learned Java, and they had us using this truely terrible compiler called Blue-J. (I don't know if this is similar to Bluette but...) It was originally developed for the now dead language, Blue, and transfered to java. Frankly Blue-J is overly simple and slow. Netbeans is quite professional at a glance, and pretty well done. However, many of the things that you might want to be changed will be difficult to find in the jumble of options in Netbeans options window. I enjoy the fact that they will be altering the interface to be more operating system dependant than that horrid Metal, (I don't know why Sun pushes that icky stuff). I personally like the Netbeans site layout. I do wish Netbeans was a little more efficient on older computers though. Sometimes I have to program on an old 200Mhz computer, and frankly that's a pain with netbeans. Most of the time it is alright, but then it does checking which takes 5 minutes then pops up the window telling me everyting about the command I was typing when it started thinking. Also the basic output was a little weird at first as it didn't actually pop up it's own terminal window. I love the wizards though. Caleb Fischer SpaceFalcon2001@hotmail.com Columbus, Ohio, USA Thu Nov 13 06:46:23 GMT 2003 Did you look at the last build of NetBeans Just yesterday, they merged the new windowing system into the trunk. So you can test NetBeans with the new windowing system. Look at here if you want: http://www.netbeans.org/kb/articles/win_sys_quick.html and http://www.netbeans.org/kb/articles/win_sys_screenshots.html I think it solve the main problems you list here. Point 1 can be closed. Point 2 concerning Properties panels can be closed. Point 3 partially closed. And it's not yet finished. Look also at the annoncement concerning NB3.6, and you will note that they will introduce the code folding, tasklist in standard, ...: http://www.netbeans.org/community/planning/proposed/36/index.html Vincent Brabant Brussel, Belgium Fri Nov 14 01:17:16 GMT 2003 re: Did you look at the last build of NetBeans Yep, I'm actually really excited about the new release. The new windowing system is very good. The introduction of a 3.6 release was exactly the right thing to do, and probably just in time as well. Lots of comments have been posted about it here: http://www.javalobby.org/thread.jsp?forum=61&thread=9550 Matt Stephens London, England Fri Nov 14 09:59:38 GMT 2003 Poor documentation NB promises lot of things, i was lured by its general purpose framework for desktop applications. But beleive me, it took 2 days to find out a tutorial and another 2 days wasted to findout what happened to TopManager class that was mentioned in the tutorial. SUN always have decent tutorial that gets you started in couple of hours, but in this case it is just frustration. Kannan kkannan@mailz.net NY, USA Tue Mar 30 05:07:36 BST 2004 NB 3.6 is useless for JSP dev They have removed the JSP compile facility, basically because in their ivory tower no one uses it, and the screams of horror from appauled developers is nothing but the squawking of those too unevolved to understand their grand designs. http://www.netbeans.org/servlets/ReadMsg?msgId=697083&listName=nbusers Dino Fri Apr 02 12:02:23 BST 2004 NB Waste of Time I was looking into using the NB framework for a desktop application. I thought great, NB gives me a free framework. I've now wasted approximately 10 hours of my time reading obsolete and unclear documentation and searching for even one example of how to use the NetBeans Platform; thus my post after arriving here from a google search for TopManager (which btw doesn't show up in the NB IDE as deprecated). Anyway, I will be the first to tell people to stay away from NB because of the poor documentation. At least the easy things, like writing a module to display one panel (that's all I wanted to do), should be easy. Ten Hoursawasted USA Tue May 11 11:55:03 BST 2004 Poor documentation is netbeans BIGGEST problem So NB 3.6 is out and I can't find 1 document about how to develop modules for it. Sure there is the old and crusty Orielly book. Don't waste your time. It is way out of date. The first example I tried, (a simple 10 liner), wasn't even close to being correct for 3.6 All examples I've found on netbeans.org are in a similar state. For software to be valuable, PEOPLE HAVE TO KNOW HOW TO USE IT!!! For NB to be successful, archive all the old docs and get them out of the way. Then make a requirement that EVERY release must have development documentation examples. Not this, "Refer to previous x.xx docs" rhetoric. Jeremy jeremyweek2004@yahoo.com Wed Jun 09 16:25:06 BST 2004 Netbeans surely lacks documentation I can not disagree with the previous messages. The lack of documentation definitely IS the problem with Netbeans. By the way - I know this is not the place for this but - can someone give some links to resources on NB module development ? Looks like it would be really useful to many people (yes, I landed on this page through a Google search...) JB elessaer@aol.com Toulouse, France Tue Jul 13 16:22:11 BST 2004 I need all about NETBEANS please. netbeans its great. miguel maiguel_tueros@hotmail.com peru, huancayo Sat Oct 30 21:39:26 BST 2004 Documentation I've been struggling for about 3 days now to find any documentation about how to get started with Netbeans Platform on 3.6. I can't find even a simple example on how to build a trivial application. This is very frustrating and not too encouraging. Are the modules used with the GUI builder? Can you drag and drop them and modify them from there? How does this nb platform compare with jdnc, eclipse-rcp and spring-rcp? I am really lost. What I am looking for is something to quickly build a Swing app. I was hoping that the platform might handle things like lookups,... without having to code everything yourself. Thanks, Not a very experienced java programmer ;) Kenny Thu Dec 09 11:13:56 GMT 2004 re: Documentation Hi Kenny, I agree, the NetBeans OpenAPI documentation needs to be better, AND more obvious to find, particularly the "getting started" stuff. These links might help: Knowledge base (includes NB platform FAQ): http://www.netbeans.org/kb/platform_use.html OpenAPI mailing list: http://openide.netbeans.org/servlets/SummarizeList?listName=dev The mailing list page has a search option -- I found that it provided the most useful documentation, as most questions have been asked (and answered) before. Plus, if you haven't done so already, download the full IDE source code and try building it (using Ant); then browse the code to see how it's done; basically learn by example. It should be a lot easier than that; the learning curve is steep and the documentation poor... but once you're past the initial "what the **** is going on here?" stage, it gets a lot easier! Matt Stephens London, UK Thu Dec 09 19:46:40 GMT 2004 It's still kinda slow I've noticed with some operations, NetBeans is still kinda slow. Sometimes when I change a line and (I assume) the IDE is looking up all the references and error-checking that line, the program hangs. This is exceedingly annoying when you've finally figured out the answer to the problem and have to wait 10-30 seconds in the middle of typing it in to finish it. Perhaps it's not a problem with NetBeans but the fact that I tend to have a video file and a game program running in the background (I'm using NetBeans to develop for the game and the video helps me feel like there's another person in the room). Doug Bell doug@hawkaloogie.com Wed Mar 30 12:23:01 BST 2005 NetBeans Platform Documentation List So, this page was one of the first that came up when I was looking very hard for info about how to get started with the NetBeans Platform. I stumbled through a french link on the NetBeans Platform site and found the ACTUAL useful documentation list: http://www.netbeans.org/kb/articles/docList.html Hope this helps some folks. Jeremy Vyska Jeremy@falserealities.com Sat Apr 23 05:07:46 BST 2005 Also, NetBeans Book A bit outdated, but this might also be useful: http://www.netbeans.org/download/books/definitive-guide/ Jeremy Vyska Jeremy@falserealities.com Sat Apr 23 15:42:11 BST 2005 re: NetBeans Platform Documentation List Thanks for the documentation links, that's pretty helpful. It's the sort of page which should be prominently linked from the front page of netbeans.org. I think it's fair to say that the NetBeans book was out-of-date before it was even published -- it appeared at a "transitional" time in NetBeans' history when nearly everything about the platform was changing. Apparently they're working on a new, up-to-date book though. Matt Stephens London, England Sat Apr 23 16:55:24 BST 2005 Hopefully It'll be great to see a 4.x version book, so here's hoping. The other tough part that people will have a tough time with right now is that the NetBeans IDE doesn't support code completion with the Open API. They're working on it and have a lot of very interesting plans that they're trying to reach for by June. I know that because of the quirks of working with the platform's API's, I'm actually coding NetBeans modules with a non-NetBeans IDE. It's very sad. Jeremy Vyska Jeremy@falserealities.com Sun Apr 24 20:21:31 BST 2005
|
||||
All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2008 Matt Stephens. ALL RIGHTS RESERVED.