Hmmm... I've only installed NetBeans on a Mac twice, for my wife and son's classes. I had no issues whatsoever in either case.
When I tried Eclipse and NetBeans I tried both on Windows (a core platform for both) head-to-head. I couldn't get /anywhere /with Eclipse at the time in the 4 hours allotted, whereas in the same time I was all set in NetBeans. A lot has changed since then in both IDEs since then -- and in my development needs. At this point I might love Eclipse if I tried it fresh -- and if I didn't need good integration with our Ant build scripts, e.g. so compilation of selected files does just what it should, not what the IDE decides it should do as a one-size-fits-all solution. I eschew compile on save for similar reasons. -- Jess Holle Reinier Zwitserloot wrote: > Jess, that doesn't really make sense to me. > > The stated reason for this usability screwup (stated by the eclipse > distro team) is that they don't have any mac users. As utterly > incomprehensible as it sounds, that does make some sort of sense, > though it begs the question: Then who developed the swt-cocoa > bindings? > > At any rate, that shocker has gotten a few mac eclipse users involved > so it shouldn't happen again. > > On to netbeans. On macs, it's.... an unusable horrid mess of crap. As > nice as netbeans is, the basic usability problems on macs are thrown > in your face even before you run it - it is deployed as an installer > script which no mac app is ever distributed as - only drivers and > crazy apps like Parallels. This installer will also put netbeans in a > strange place, and if you manually move it, stuff breaks. Yich. > > You then start up netbeans, and it asks you to register it. Okay, but, > it never remembers. You can pick 'never', or you can actually > register, it doesn't matter, you'll have to click 'never register' > every single time you turn netbeans on. > > Only then do you actually see the netbeans IDE. At this point, you > decide to turn on compile-on-save (because, really, why the heck would > you not) and after some headaches you figure out that setting does > nothing on mac os x. > > At that point, you take your netbeans install and pitch it into the > trashcan. > > CAVEAT: This rant applies to macs, and I've held it before. I actually > like a lot of the netbeans philosophy far more than what the eclipse > team has been doing since about eclipse 2.3, which is quite a while > ago. I'd love nothing more than for someone who knows how to do UX and > owns a mac to have a look at this stuff and fix it. > > Really, as far as new-user usability goes, eclipse is an absolute > master. It's netbeans that sucks ass. Even for advanced use, eclipse > has plenty of UX niceties; for example, unlike netbeans, eclipse > almost never blocks, especially if you turn on 'run tasks in > background' in the settings. Heck (no, seriously, this is absolutely > true) - the eclipse compiler is far better than javac. (In that it is > much closer to the official JLS than javac!) > > The problems with eclipse are to be found elesewhere, and are > relatively minor in comparison to the ailments of netbeans. > > As far as I can remember (which is a very, VERY long time ago), the > JDT has ALWAYS, *ALWAYS* either been in all offered eclipse downloads, > or in the majority of them (e.g. its not in the eclipse-for-php > download bundle, but, duh). So, I guess you're not recalling that one > correctly. > > > In fact, other than a number of obscure but worrying problems, what, > exactly, is everybody's problem with eclipse? It's compiler is more > JLS-spec than javac, its editor is almost as good as netbeans', its > waaay faster than netbeans and does most things in the background > (unlike netbeans), its debugger is spot-on, it has far better project > management tools (in that you can have projects be dependent on other > projects, a feat I never managed in netbeans). > > The biggest bits of beef I have with eclipse are in fact that its > parser gets rather confused when you use a lot of inner classes, > though netbeans isn't that much better at this, lack of VCS support > (CVS doesn't count. SVN definitely doesn't count), though that's being > worked on, and a horrid plugin selection interface. Relatively minor > things, really. > > > In fact, eclipse is even the most forward looking java IDE out there > today; it is for example the only major IDE that has proper support > for the annotations JSR: Eclipse can run annotation processors on > save, something neither IDEA nor Netbeans do - they only run them when > you do a full project build (which starts ant). Uh, yeah, sure. That > doesn't count, obviously. > > > On Aug 11, 1:55 pm, Jess Holle <[email protected]> wrote: > >> This in a nutshell is the kind of "usability screwup" (as you put it >> Reinier) that led me to use NetBeans instead of Eclipse many years ago. >> >> At the time Eclipse's downloads were much worse than today -- with the >> Java perspective being a separate download, etc. That and the whole >> messed up "perspective" experience when I tried to actually use the IDE >> drove me to NetBeans (which I downloaded, installed, and became >> sufficiently productive with in the morning and had dedicated the >> afternoon to doing the same with Eclipse -- and couldn't). >> >> Now NetBeans has ticked me off innumerable times since -- it's far from >> perfect, but it has never quite pushed me to Eclipse. [It has come >> close on some occasions due to its scanning issues, though. Why can't >> the NB team apply some real focus on making scanning block nothing in >> the GUI and be fully incremental in nature? I can only assume the >> marketeers and others with an overt lust for new feature bullet items >> are in charge of priorities...] >> >> -- >> Jess Holle >> >> >> >> Reinier Zwitserloot wrote: >> >>> Bill: That is indeed it, but it's being released only by the eclipse >>> core team, which is why only the 'classic' bundle offers that >>> download. >>> >>> If you want another bundle, you're out of luck. You have to take the >>> classic bundle, and then use the plugin architecture to grab the rest. >>> >>> On Aug 11, 6:46 am, Bill Robertson <[email protected]> wrote: >>> >>>> Gentlemen please be nice. >>>> >>>> At the bottom, I do see a "Mac Cocoa 32bit 64bit" link in the >>>> "Eclipse Classic 3.5.0 (161 MB)" section. Perhaps that's it. >>>> >>>> On Aug 10, 7:14 pm, Reinier Zwitserloot <[email protected]> wrote: >>>> >>>>> I'm not out of date; that's the same eclipse I run. >>>>> >>>>> It isn't, however, anywhere on the standard eclipse download pages. >>>>> >>>>> It would therefore be a proposterous usability screwup if you demanded >>>>> your users to somehow find that download. >>>>> >>>>> On Aug 10, 3:45 pm, Neil Bartlett <[email protected]> wrote: >>>>> >>>>>> Reinier, you're out of date. Eclipse Galileo supports Cocoa and runs >>>>>> on 64 bit Java 6 VMs on Mac OS. I've been running Eclipse under Java 6 >>>>>> for about 6 months already. So the only "hoop" that Eclipse users have >>>>>> to jump through is to download the current release version. >>>>>> >>>>>> Regards >>>>>> Neil >>>>>> >>>>>> On Aug 9, 2:05 pm, Reinier Zwitserloot <[email protected]> wrote: >>>>>> >>>>>>> Until /very/ recently, the default JVM used to start java apps on mac >>>>>>> os x was 1.5; 1.6 has been on macs for ages, but unless you use a >>>>>>> mechanism where you can specify which VM you want (e.g. webstart), >>>>>>> you'd get 1.5. Fortunately, at least today, any leopard user that has >>>>>>> not got automatic updates turned off (Like 90% of all mac os x >>>>>>> deployments out there have leopard with automatic updates on, so >>>>>>> that's good) have 1.6 as a default. >>>>>>> >>>>>>> There's still the Mac Os X 1.4 tiger folks, the folks with a 32-bit >>>>>>> CPU, and the need to run with 32-bit libraries (such as *ALL* eclipse >>>>>>> installations - if you're writing an eclipse plugin, do NOT USE 1.6 >>>>>>> only features, or mac users have to jump through a lot of hoops to use >>>>>>> your plugin), but that's more of a niche thing at this point. >>>>>>> >>>>>>> So, yes, just since this month, 1.6 is okay. >>>>>>> >>>>>>> Having said that, project lombok runs in 1.5 and 1.6, and I even >>>>>>> replicated the SPI service loader mechanism which is 1.6 only to avoid >>>>>>> a 1.6 dependency, because of that eclipse issue. >>>>>>> >>>>>>> On Aug 9, 11:05 am, "Vince O'Sullivan" <[email protected]> wrote: >>>>>>> >>>>>>>>> Personally, I'm still supporting Java 5 for a number of libraries >>>>>>>>> (BetterBeansBinding, jrawio, Mistral) because Java 5 is not yet EOL >>>>>>>>> for >>>>>>>>> a couple of months ;-) but above all because I presume a lot of people >>>>>>>>> will keep on using it for several time. At the moment I don't need >>>>>>>>> specific Java 6 features for those projects and running "matrix" tests >>>>>>>>> with Hudson makes not too hard to maintain this stuff - with the >>>>>>>>> exception of a specific problem. >>>>>>>>> >>>>>>>>> For my own applications I've moved to Java 6 several months ago. >>>>>>>>> >>>>>>>> I'm in much the same position. >>>>>>>> 1.6 at home, since it came out. >>>>>>>> 1.6 on our departmental UAT server since Friday (2009-08-07) but >>>>>>>> without any development targeting it yet (chicken and egg situation). >>>>>>>> 1.5 on our departmental live server (and all the other servers in the >>>>>>>> company that I'm aware of) for the forseeable future. >>>>>>>> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
