Eclipse 2.0 IDE Platform Released

Discussions

News: Eclipse 2.0 IDE Platform Released

  1. Eclipse 2.0 is now available for download. Eclipse is an open extensible IDE that provides building blocks and a foundation for constructing and running integrated software-development tools. Tons of free and third party plugins are available for Eclipse that integrate with the major appservers and development frameworks.

    Download Eclipse 2.0 at http://www.eclipse.org.

    This new release seems to work well with the Genuitec pluggins(http://www.genuitec.com/). Tried out the integration with WebLogic 6.1sp2, just has few differences on where to make the settings changes on the pluggins. SWT works great, consumes relatively lesser memory than an IDE that uses Swing(NetBeans, JDeveloper, etc), maybe Sun should just throw away Swing and adopt SWT.

    Threaded Messages (115)

  2. Version 2.0 has some nice enhancements. SWT is a much nicer alternative to Swing in my opinion (from a usuability and appearance standpoint) I'm no expert in GUI stuff, so I can't speak for the development process. I understand that there are some portability issues, but overall it seems like a very practical option for building GUI apps.

  3. SWT can break the Java standard. SWT, as I know, is very dependent on platform.




  4. <quote>
    SWT can break the Java standard. SWT, as I know, is very dependent on platform.
    </quote>

    So is AWT...

    I'm not sure what you mean by "break the Java standard" and "very dependent". SWT is not part of the JDK and has a different approach to the portable UI toolkit problem that Sun used, but except for this, it's a pretty good UI, especially coupled with JFace.

    --
    Cedric
  5. SWT is very cool[ Go to top ]

    As I understand it.
    AWT's approach is to try and render the UI on it's own and try *not* to use platform specific UI features as far as possible. This allows it to run on all platforms that Java is ported on to.
    SWT utilizes the platform specific features to the fullest extent. The advantages are
    1. your UI gets the look and feel of the platform it's running on.(I know you can get Swing to do this, but it's a lot more work).
    2. You avoid the sluggishness that you usually get with Swing.
    The disadvantage being that there's a lot more effort have to port it to each platform.
    Currently it's only ported on Windows,Linux and a couple of Unices.
    I think SWT can go a long way of advancing Java's cause on the desktop. I would rather have my UI run well on 90% of the desktops rather than run poorly on 100% of the desktops.

    "The SWT can break the Java standard" is Sun FUD. IBM could put it up to the JCP but I don't think it matters. The fact that it's Open Source is reassuring in itself. And if it dosen't run on <insert your platform here> go ahead and port it.

    Regards
    Ravi
  6. SWT is very cool[ Go to top ]

    Sorry. It doesn't run on OS/2 and yes it does break the most important features of Java cross platform. I have not written a single program in Java in the last 4 years that has not ported PERFECTLY to every single platform.

    IBM should have spent more time improving the performance of Swing. They did it with their VMs and I'm sure they could have done it with Swing. If I had to write apps that worked on 90% of all machines, I'd do it C++ on Windows.
  7. SWT is very cool[ Go to top ]

    It's really simple. You can run Eclipse anywhere the SWT has been ported to....

    ...and guess what. You can run a Java program anywhere the JVM has been ported to. Oooooh!

    Now when Java first came out, the JVM was only available on a few platforms. If people took the view displayed in this thread then it would have never gotten off the ground. For the _longest_ time there was no really stable JVM for Linux either.

    There's even posts on this thread saying that java.math classes use JNI. Err, so what? Take a look at the definition of java.lang.Object some time. Most of it is native methods. It's a simple fact of life when you look at the way the VM approach works, that at least a few of the base library classes will be natively implemented. Ecplise simply extends this to the UI. In my opinion (and it's just an opinion guys, before the AWT zealots jump on me) that the SWT approach is a better one. I don't see how the AWT / Swing can ever meet native UI performance.

    When NT4 came out, Microsoft moved their graphics drivers from user space to kernel space, specifically because they couldn't get decent performance without direct hardware access. A similar analogy applies here. You are unlikely to get decent performance out of a generic button rendering function written in Java than you are out of the nice simple "put a button here" function from the OS.

    The Eclipse guys are working on porting the SWT to different platforms, and sooner or later they'll get there (although I would seriously doubt if they'll bother with such platforms as OS/2 simply because there are so few people using it (no offence.))

    Rather than debating the AWT versus SWT thing over and over, let's talk about the actual product they provide...

    1) It's free.

    2) It's quick.

    3) It's incredibly easy to use, once you personalize it to the way you work. On my team I have 3 people. One is from a VAJ background, one from Forte and one from Visual Cafe. Within 10 minutes of me explaining Eclipse basics to me, they had all dragged their windows around and added whatever views were necessary to make it look and feel just like whatever IDE they were used to. Once it was like that they were comfortable and off and running.

    4) From the starting point in 3 it's easy to learn how to use the more powerful features. The refactoring functions are great, and the local history feature is a godsend.

    5) The debugger is bliss. I leave programs running, pop back into Java perspective and edit the code, hot-swap it in, and it doesn't crawl along like a one legged puppy dog while I do it either! It works just fine.

    6) The context sensitive code assist, auto import, import ordering, auto-fix, CVS integration (See below) etc. are all very well integrated.

    7) Can't wait for the JSP / HTML plug-ins to come out! :)


    On the down side...

    1) On one machine I installed it (out of 20) it simply refused to work. No amount of fiddling would make it work and the instructions on how to fiddle are somewhat scarce!

    2) My debugger currently refuses to take the args[] array I specify on the application run dialog, so I have to put a one liner in at the start which initializes it to the values I want. Hopefully that will go away in the new 2.0 release! Only happens on my machine, so here's hoping... :)

    3) If you aren't a CVS fan & user, then the SCC integration is not currently great for you. I hear they have been working on abstracting the SCC layer so you can plug any SCC system in. The only problem I see with that is that the team concept in Eclipse is really built around the optomistic concurrency model it inherited from VAJ / Envy. That approach says it's OK for two developers to work on the same file at the same time, and we provide really great diffing tools (and they really are cool) to help you integrate revisions. The result of this is that you only check files in, you never check them out. You wanna work on the file? Start editing. Now a lot of people don't like this approach. Personally I am OK with it because I think a) Developers ought to communicate with each other when they work in a team so it really shouldn't be an issue that often. b) Once you're used to it, it's a lot more productive than pessimistic locking. It will be interesting to see what the guys have done / are doing to allow both approaches to SCC to work.

    It can sometimes get a little confused during a compile of a project which others depend on and lead to lots of supposed errors in the dependant projects. A simple re-compile of the dependant projects clears the problem though.

    Anyway, that's enough really. As you might guess I am a big Eclipse fan, been using it for well over a year. Besides that I've used Forte, JBuilder, VAJ, vi / emacs(!), and a whole host of other IDEs. Personally, I love Eclipse and I think if you try it for a day or so you will too, since it won't take you too long to make it look and feel just like the IDE you're used to! :)


    OK, so any second now a whole load of AWT folks are going to flame me.

    *puts on flame proof jacket*

    Chz

    Tony
  8. SWT is very cool[ Go to top ]

    Excellent comments Tony. I agree with everything you said. I came from a Jbuilder background to Eclipse and I'm not going back now. The only thing I would trade it in for would be IDEA.

    I think that Eclipse is brilliantly thought out and designed. Erich Gamma, the design pattern guru, was involved with Eclipse (he worked on JFace - the Eclipse UI Framework and Eclipse Java Tooling) and it shows.

    I have always thought that swing/awt was one thing that really lets Java down. Yes, it can be considered a nice toolkit to work with, (with exceptions, just think JTree) but unless you really know what you're doing (e.g. the guys from IDEA, Jbuilder), the performance is dog horrible. I think the SWT approach, making it native, is spot on.

    They've already ported it to Linux, Windows, Solaris, QNX, AIX, HP-UX. OSX is probably planned sometime soon.

    I don't see what the complaint is.
  9. SWT is very cool[ Go to top ]

    <quote>
    I don't see what the complaint is.
    </quote>

    Me neither. My only explanation is that some people for some reason got emotionally attached to Sun, which is warm and fuzzy, and everything done by IBM (or any other villain - just look at the ECPerf threads) is evil by definition.

    Now, what I really want to see are WebLogic plugins. Cedric, any chance of this ever happening?

    --
    Dimitri
  10. SWT is very cool[ Go to top ]

    OSX is probably planned sometime soon


    There is no formal commitment to a Mac port anywhere on the eclipse.org web site. Just a rather non-committal statement that some test work has been done on it.

    That leads to some really weird posts such as this one:
    http://dev.eclipse.org/newslists/news.eclipse.tools/msg09158.html

    This describes someone who is running Virtual PC (a PC emulating program for the Mac) to get Eclipse to run on a Mac.

    The ultimate performance killer would be running Virtual PC in OSX Classic mode (actually, I'm not sure that's possible, but this would be the ultimate extreme).

    If that were to happen, you'd have OSX emulating OS 9 which is running Virtual PC which is running Windows in an emulated Intel environment which is running Eclipse in the Java JVM.

    All this because SWT isn't available for the Mac. And this is Java?

    That's the whole problem with SWT. Unless it's on *all* the platforms that the JDK is on, it's not really Java.
  11. SWT is very cool[ Go to top ]

    <quote>
    That's the whole problem with SWT. Unless it's on *all* the platforms that the JDK is on, it's not really Java.
    </quote>

    Oh really. So Eclipse is not really Java because there's now SWT port that would let you run it on an OS/390? Come off it.

    As with all things there are priorities. By making it work on Windows and Linux they followed the 80/20 rule perfectly well IMHO. Those two combined make up the vast majority (Well over 90%) of all development set-ups. The rest will follow in time, if there is demand.

    Why do people have to bash a product which doesn't quite have "the world" right now? Don't we all subscribe to the concept of architecture first iterative development (or similar.)? That concept states that you get the underpinnings right and then you build from it. That's exactly what Eclipse does and it does it very well (OK I'm back to being an architecture critic here rather than a consumer of the tool.)

    If we (as developers and architects) expect to sell that kind of development methodology to the consumers of the technology we produce then we can't really bash Eclipse for doing exactly that. If you look at their project release charters I think they are doing an excellent job. If some feature you really want is missing then you can do 1 of 2 things.

    1) Submit something to eclipse.org as a feature request.
    2) Write it yourself. It is open source after all!

    That applies to the features of the IDE and the graphics libraries it uses to power the SWT.

    Enough arguing about SWT AWT already. Eclipse uses SWT. Period. The End! :)

    Chz

    Tony
  12. SWT is very cool[ Go to top ]

    <quote>
    Oh really. So Eclipse is not really Java because there's now SWT port that would let you run it on an OS/390?
    </quote>

    You know that's not what I meant, of course.

    <quote>
    By making it work on Windows and Linux they followed the 80/20 rule perfectly well IMHO. Those two combined make up the vast majority (Well over 90%) of all development set-ups. The rest will follow in time, if there is demand.
    </quote>

    What if there's demand but it's not technically feasible or cost effective?

    Did you know that Apple--not Sun--wrote the AWT layer for Java on OS X? Mac OS X is Unix, but with an Apple GUI.

    Can anyone point to an official statement from Eclipse that Mac will definitely be supported? That would be good if it were true. If not, well, it's just not Java, is it?
  13. SWT is very cool[ Go to top ]

    Can anyone point to an official statement from Eclipse that

    > Mac will definitely be supported?

    If you want to be a pedant, you could ask if there is an offical statement saying that Windows will be supported...

    The FAQ page merely states the targets for the existing releases. I see no 'official statement' of Windows support...
  14. SWT is very cool[ Go to top ]

    <quote>
    If you want to be a pedant, you could ask if there is an offical statement saying that Windows will be supported...
    </quote>

    OK, good point, but perhaps what I'm looking for is something more than what's on the page you referenced:

    "MacOS: Still wrestling with getting the initial code base (done by Andre Weinand) into the open source repository."

    and

    "Macintosh port: We are in the process of setting up a JNI/Carbon based implementation of a Macintosh OS X port of SWT which is based on the work of Andre Weinand."

    This doesn't sound like a concerted effort. It sounds like one person's attempt to get it to work.

    I hope Andre doesn't get hit by a bus.

    It's just not credible the way some people put forth SWT as a replacement for--or even a competitor to--AWT unless SWT will be ported to and supported on every Java GUI platform.

    And "Joe's working on it in his spare time" doesn't count. :-)
  15. SWT is very cool[ Go to top ]

    This doesn't sound like a concerted effort. It sounds like

    > one person's attempt to get it to work.
    > I hope Andre doesn't get hit by a bus.

    But surely that's the point of something being Open-Source: individuals can pick up a project and run with it in the direction that they want to. I think you're still locked into the Sun 'corporate control' way of doing things (not necessarily a criticism, btw).

    Open-source stuff isn't really done by official statements and the like. It is mostly down to enough people wanting it to happen (and the SWT port to OSX seems to be going a lot better than the OpenOffice port!). At least the Mac is now being taken seriously as a development environment...

    Let's face it: If Linus Torvalds had been hit by a bus a few years ago, the face of computing today would be very different.

    [Writing from my Mac - no I haven't tried Eclipse on it... yet!]

    /david
  16. SWT is very cool[ Go to top ]

    <quote>
    Did you know that Apple--not Sun--wrote the AWT layer for Java on OS X? Mac OS X is Unix, but with an Apple GUI.
    </quote>

    Now there's an interesting point.

    If Max OS X is Unix, then why didn't they build their UI using the X Windows toolkit and just change the look and feel of the windows etc? Probably because they hadn't got a snowflakes chance in hell of making it look good! :)

    Just thought it was an interesting parallel. :)

    Chz

    Tony
  17. SWT is very cool[ Go to top ]

    There is no formal commitment to a Mac port anywhere on the

    > eclipse.org web site. Just a rather non-committal
    > statement that some test work has been done on it.

    Errrmm, so the downloadable test drop is my imagination then?

    http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt-home/dev.html

    Bottom of page. Yes it is experimental, but it seems more than 'non-committal'...

    > This describes someone who is running Virtual PC (a PC
    > emulating program for the Mac) to get Eclipse to run on a
    > Mac.

    Huh? The description they have (and as they are writing it, I guess than counts) is that they're writing Carbon/JNI layers for SWT.

    > All this because SWT isn't available for the Mac. And this
    > is Java?

    They seem to think that that's what they're doing - porting SWT to Carbon.

    Maybe you should skip the editorial slant and stick to the facts...

    Only question I have (and maybe a Mac expert could answer this) is why are they using Carbon and not Cocoa?

    /david
  18. SWT is very cool[ Go to top ]

    <snip>
    There's even posts on this thread saying that java.math classes use JNI. Err, so what? Take a look at the definition of java.lang.Object some time. Most of it is native methods.
    </snip>

    my point when i mentioned java.math was exactly that since the jdk uses jni, and thus needs to be ported to each platform, then why the fuzz about another technology that does the same?

    plus, realisticly, with regards to eclipse, how many develops code on other platforms than winX/*nix? and perhaps macOS (that also has a port coming)?

    i have used eclipse since r1.0, and have used almost all the stable builds, plus i have weened my entire team on to it (by way of example, not decreet :-)), and i can safely say its the best ide i have worked with, plus i have the ability to see the source PLUS it free.

    i think it all boild down to being discriminate, we develop an application that has to be used by clients over the net, and there we use Swing, while we internally develop using a tool made with SWT, no problem.

    sincerely
    morten wilken

  19. SWT is very cool[ Go to top ]

    <quote>
    <snip>
    There's even posts on this thread saying that java.math classes use JNI. Err, so what? Take a look at the definition of java.lang.Object some time. Most of it is native methods.
    </snip>

    my point when i mentioned java.math was exactly that since the jdk uses jni, and thus needs to be ported to each platform, then why the fuzz about another technology that does the same?
    </quote>

    You're quite right, my apologies. It was 1am in the morning and things were looking a little blurry when I read it. Seems like we're in violent agreement with each other! :)

    I think the decision to stay (pure Java) and the decision to go native is one that everyone working at the level of the language the SWT / AWT teams do have to make on their own, based on their own design considerations. Rather than debate that point we'd all do much better to look at the products they produce and judge it from there.

    I work in the financial services technology arena and I can say for sure that the business people in those businesses don't care (for the most part) if it's Java or COBOL if it helps them make money! If I view myself as the consumer of this tool rather than a critic of it's architecture, then I couldn't care less what it's written in. It does what I want it to do and I like it. :)

    Chz

    Tony
  20. SWT is very cool[ Go to top ]

    Tony wrote (and other said similar things):

    >I work in the financial services technology arena and I
    >can say for sure that the business people in those
    >businesses don't care (for the most part) if it's Java or
    >COBOL if it helps them make money! If I view myself as
    >the consumer of this tool rather than a critic of it's
    >architecture, then I couldn't care less what it's written
    >in. It does what I want it to do and I like it. :)

    But there are actually customers out there who understand that if a program is written in Java they can change their desktop to Linux or their server to Unix/Linux or even a mainframe, expecting it to work with minimal problems if any.
    To many customers this is a major benefit. Even to those who don't know about such changes or plan them any time soon this may become a major benefit down the road.

    Of course the look and feel of a GUI program is important and Sun hasn't exactly been the best providers of this even with Swing. It seems to me that a lot of people coming from a Unix background have a rather limited understanding of the high requirements that must be set for GUI development tools. If SWT changes this it _may_ be a good thing. May be Sun (or others) can make the last effort to make Swing as good as it should have been all along (or enough companies start using SWT that it becomes a real alternative).

    Nils Myklebust


  21. >>it's a pretty good UI, especially coupled with JFace

    Its basically Win32, but written in Java...

    I think that from a programming perspective SWT/JFace is a bit ugly compared to Swing (theres no model for instance - the best you have is callback mode ala win32). Did you notice the hungarian notation? It almost looks like it was generated from win32... :-)


  22. Eclipse 2.0 IDE Platform Released[ Go to top ]

    This all has been discussed many times and many places.

    Eclipse is Free. So it has basic stuff. Yet it is pretty powerful. It uses SWT for its interface but doesn't require you to build apps using it. SWT is to be used for Eclipse plug-ins. I'm pretty sure Eclipse will work with certain standard Linux Distributions. For all of those who think C# is just going to work fine on anything but Windows - here is your clue that it won't.

    If you want more from IBM, you'll have to pay - WSAD. But it is worth it. Get the Business Partner Toolbox and you will get a bunch of tools and this. It is better than MSDN.

    Mark
  23. Eclipse 2.0 IDE Platform Released[ Go to top ]

    <you said>
    If you want more from IBM, you'll have to pay - WSAD. But it is worth it
    </you said>

    not so sure about that. I have at least two examples where WSAD screws up. one is CVS integration: one of the best I've ever seen, superb merge interface and stuff, except for case when you have multiple projects in your workspace and you try to branch those projects. WSAD goes completely nuts, messing up everything. you're not able to import your branches any more, the tags you placed on the trunk are duplicated in all brances, it's hell all over. The second example: I have EJB methods that return interfaces like collection or map. WSAD throws warnings all over the place that the return type and parameters are not serializable. geeez! of course it's not. Collection is an INTERFACE. the client called to complain the code isn't JE22 compliant, cos WSAD sais so. crap. I had to spend time to explain that the dude who wrote that code doesn't know the difference between an interface (which by default cannot be serialized, cos its just a description of a contract) and an object.

    I can understand SUN was bitching all over the place about this tool braking standards.

    anywas...... hope WSAD based on Eclipse 2 will fix some of these issues. WSAD 4 leaved me with the impression of a good but unfinished tool.
  24. does anyone know if either eclipse or netbeans has the feature of converting ant files to projects a.k.a visual C++ which can just open a make file and show u the project in explorer
  25. <quote>
    Its basically Win32, but written in Java...
    </quote>

    Yup.

    <quote>
    I think that from a programming perspective SWT/JFace is a bit ugly compared to Swing (theres no model for instance -
    </quote>

    Not sure what you mean?

    <quote>
    the best you have is callback mode ala win32).
    </quote>

    I still prefer this over the stupid "One object per callback function" aberration that Sun has been pushing on us since 1996. The delegates were one fine idea, and it's ironic to see them show up in JDK 1.4 (finally).

    <quote>
     Did you notice the hungarian notation? It almost looks like it was generated from win32... :-)
    </quote>

    Ah, Nick... forest... trees...

    There are quite a few things I like in SWT/JFace:

    - GridLayout. No more GridBagLayout nonsense, finally a layout manager that makes sense and brings back memories of the oft-missed XmForm from the Motif days.

    - A wizard API. Finally. When are we going to see that in Swing? I bet there are several dozens of implementations floating out there by now.

    - A look and feel that doesn't break all over the place (see the default button tnat never works in the Windows L&F of Swing)

    I won't mention "speed" because Swing can be just as fast (see WebLogic Workshop ;-)) but it sure does feel fast and smooth.

    --
    Cedric






  26. >> Not sure what you mean?

    I just meant that you dont have the elegance of the Swing Abstract<X>Model.
    Take a Table for example.
    In JFace, you either have to do your own for-loop to populate it (push mode) - or you have to work with the clumsy callback mode that just gives you just a row index - you have to then work out which column... use a case statement...
    Whats wrong with getValueAt(int rowIndex, int columnIndex) -I think its just much simpler.

    >> Ah, Nick... forest... trees...

    Hey, it was not a criticism - just an observation. I just thought it was amusing. :-)

    -Nick

    PS:

    >>I still prefer this over the stupid "One object per callback function" aberration that Sun has been pushing on us since 1996. The delegates were one fine idea, and it's ironic to see them show up in JDK 1.4 (finally).

    ;-) Well, this one has been debated to death (wasnt there a court case over this..?). I favour the anti-delegate camp. But, youre saying delegates are now in 1.4?? I didnt know that... where?
  27. Eclipse 2.0 IDE Platform Released[ Go to top ]

    I agree with Cedric. Check out WL Workshop, its built using JDK 1.4 and its pretty impressive
  28. <quote>

    > SWT can break the Java standard. SWT, as I know, is very > dependent on platform.
    > </quote>
    >
    > So is AWT...

    But it's the JVM vendor (Sun) who's going to maintain AWT/Swing, and it's You in case of SWT.

    Any upcoming OS version might break compatibility with that version of the SWT that you shipped and you'll have to be releasing maintenance versions of your software...

    So, i guess, until (if ever - where is the JSR??) SWT/JFace makes it to SE it's not a good idea to use it for anything but Eclipse plugins.

    Right?
  29. In its base install, Eclipse 2.0 GTK will not run on my Linux laptop without manual config fixes, and gives wierd system library errors. I know the errors are probably easy to resolve, but it does not give me a whole lot of confidence with the whole SWT thing.

    -Pete
  30. <quote>
    I know the errors are probably easy to resolve, but it does not give me a whole lot of confidence with the whole SWT thing.
    </quote>

    I'd suggest you try Netbeans. Great IDE.

    -- Igor

  31. Eclipse & Netbeans may be good Java ide but they are not proper j2ee ide check Oracle9i Jdeveloper free without support - it can do anything u need (not promoting! )
    Faisal
  32. Faisal,

    Oracle9i Jdeveloper is not free for commercial use,
    I just checked their license:
    "If you use the applications you develop under this license for any internal data processing or for any commercial or production purposes, or you want to use the programs for any purpose other than as permitted under this agreement, you must contact us, or an Oracle reseller, to obtain the appropriate license."
  33. I have used NetBeans somewhat, and for an IDE written in Swing, it's not bad. The features that Eclipse offers such for refactoring, incremental compilation, debugging, etc. are really hard to beat.
  34. Ray,

    I've found the refactoring tools built into most IDEs pretty lacking. Sure, Eclipse does provide some basic support where as Forte has absolutely none. However, I've started to use RefactorIT (www.refactorit.com) and found that it to be one of the most complete refactoring and code metric tools available (outside of what's built into TogetherJ).

    -m
  35. its not much different than the jdk's... im pretty sure that the java.math classes uses jni calls aswell and so cannot be ported.. you need a platformspecific jdk, so why not a platformspecific guiframework
  36. <quote>
    im pretty sure that the java.math classes uses jni calls aswell
    </quote>

    I think that since 1.3 or so BigInteger doesn't use native methods anymore.

    --
    Dimitri
  37. Hello,

    Eclipse is a lot more than an environment for java development (this is just one plugin) or something that has a nice GUI library (SWT is also just another plugin) - what's nice about it is the plugin architecture which makes it really easy (after the steep initial learning curve) to write cool looking tools of your own based on existing plugins. The tools you write can themselves be reused to create more powerful versions at some later point.

    The framework architecture itself is its strength in my view, not individual plugins like the JDE or SWT or Ant or CVS (though I like the JDE and SWT - I also like the Help plugin).

    Nirmal.
  38. I hate this sentence...It´s no standard...In the modern times it seems that people are NOT allowed to do anything because it´s not standard. Just wait for the gurus... If something doesn´t come from the w3,the ECMA or from this kind of Java community...Its a bad idea. DONT DO IT!!!

    Maybe the standards are a bad thing for the creativity and the innovation.

    ..:Ok this is so much. but there are many people here that treat the standards as a religion.

    There are much religion in Java (and Linux)

    And there are many nice things that never will be standards (Thank you God!!!!)

    Bruno Sanz


  39. Does anyone know if eclipse offers code completion ?
    I gave eclipse 1 a short testdrive once but AFAIK it wasn't there
  40. Yes it does have content assist. The best way to see all of its features is to download it!
    I agree with Cedric on many of his points. For developer productivity, it is very easy to work with, and honestly I see it as the best tool to stack up against the VS.NET tools that seem to be such a big deal.
    Already many open source projects are churning out plugins for the platform. Many of the subprojects are exciting too, such as the GEF toolkit, which is a set of tools for creating drawings (flowcharts, etc.) Also, the C/C++ integration project seems promising.
  41. Well said Bruno!

    Years ago I was a much more creative programmer who didn't pay attention to standards much less even know what they were. But after years of programming within the strict confines of corporate IT my creativity and innovation have suffered from adherence to standards.



  42. >> Years ago I was a much more creative programmer who didn't
    >> pay attention to standards much less even know what they
    >> were. But after years of programming within the strict
    >> confines of corporate IT my creativity and innovation have
    >> suffered from adherence to standards.

    Well, (I say smiling) to be brutally blunt, if you work for a corporate IT department its your job to make money for that company. No more, no less.

    If you want to pursue some form of artistic expression, work for a startup or a software products company where that *is* your job. Standards have strong commercial drivers in corporate IT. Like it or leave it, thats the way it is...


  43. Ok, I spent this afternoon trying it out, and I am not switching off of NetBeans. Here are my nits...

    1. External tools are inconvienent to use
        Excuse me for working at a company that does not worship CVS (I used to work with the original author and even he didn't CVS at his current job). So to get a file in the ide that is currently not checked out I need to either leave the IDE or move my hands off of the keyboard and focus with the mouse onto that tiny external tool button (or menu) and move it again to the right external task to execute "p4 edit $foo" Sounds like I'm whining, but when you do it 100 times a day for a moth solid you can get sloppy. A hot key would be nice, or a single toolbar button that is one click away. Both could be done in NetBeans, but I just use PerForte (it will check it out for me when I try to start typing). And you can make anything you can code in an Ant Script (which is just about anyting) into a toolbar button or a hotkey.

    2. Project to folders relationship is 1 to 1
        Basically this means that if you are editing code in three different directories (test, main, samples) you either need three different projects or mount to a parent folder common to all three, which is fine if they are all on the same drive or the common folder isn't rediculously high (like, lets say '/'). Netbeans would let me do 3 focused mounts under one project. Sure I could chain projects but when I have 20 other projects unrelated I would like to look at the explorer window and not be reminded they exist.

    3. Ant / Make integration
        Ok, I don't use make but some do. Primarily I use Ant, for the principal reason the exact same build setup works on the developers Windows boxes as well as Linux and Sun boxes. You got to get Cygwin to do that for make, which interacts poorly with perforce, but I digress. Netbeans can be easily configured to actually use the build.xml for the project to build all of it's internal classes, so the IDE build is also the same as the "master" build. This causes less build breakages by and far. Eclipse uses neither of these, plus you cannot run Eclipse's custom build process unattended on a linux server (w/o plugin hacking). Having the developers using the exact same build process as on the central build servers is essential to reproducably successful builds.

         It's just three nits, but those three will keep me away from Eclipse. Who cares about SWT and re-factoring if simply using the IDE drops my productivity down from the pace I am used to? It's not just a learning curve thing, it's an efficiency thing.
  44. 1. External tools are inconvienent to use


    Run Ant from within Eclipse is a snap. Other tools, perhaps less so. I expect functionality to come from OTI/IBM or the Eclipse community to improve this (I want more common actions to be toolbar based).

    > 2. Project to folders relationship is 1 to 1

    This is not the case at all; you can have as many source folders as you want; they just all share the same classpath and destination directory (for compiled classes).

    I tend to have Eclipse compile to one common directory, and have the Ant build files for my sub-projects compile to different directories (as well as build JARs, etc.).

    That's what I do at home; at work we have Eclipse compile into the same directories as Ant ... I don't think it works as well.

    The Eclipse build is more complicated ... it does some form of dependency checking so each change causes more compiles (but catches errors much faster).
  45. Hey! It does run Ant. Even from the toolbar!
  46. Hey! It does run Ant. Even from the toolbar!


    What doesn't run Ant? I use Eclipse 2.o every day with Ant. Works fine for me, and from the tool bar.

    Chuck

  47. Note: I don't use Eclipse, I use Intellij IDEA, but some other people in our team use Eclipse and keep up with the latest versions.

    <quote>
    So to get a file in the ide that is currently not checked out I need to either leave the IDE or move my hands off of the keyboard and focus with the mouse onto that tiny external tool button (or menu) and move it again to the right external task to execute "p4 edit $foo"
    </quote>

    There is a VERY nice looking plugin for Eclipse that basically recreates all of the functionality of the P4Win client in Eclipse. It's slick (much more slick than the command line call-outs from IDEA, I'm afraid).

    <quote>
    Project to folders relationship is 1 to 1
    </quote>

    This is a big one for me too, as we break our code up into several code bases. The Eclipse users muddle through somehow (I'll have to ask them), but this is very nicely handled in IDEA.
  48. I'd like Jbuilder7 better. :-)
  49. Eclipse/CVS ... I've been evaluating WSAD (studio) which is based on Eclipse 1.0 and it ships with a cutdown version of clearcase if you don't like CVS. Personally, we use CVS here at work, what I like about it is that I can use WSAD while others use JBuilder. (I don't prefer JBuilder at all). I have Eclipse 2.0 (a pre-release) at home, I don't use any code versioning there at all, though. In my experience with various IDE's version control systems it seems usual that they all support CVS + one or two others in a native (seamless) way. What the 'others' actually are appear to be depends on the IDE actually is. So, I think a good reason to stick with CVS.

    Eclipse/ANT ... the integration is pretty good and seamless as far as I can tell. Using Eclipse and ANT I took this location from using complicated and ugly BATCH FILES to using ANT, including the capability to build straight out from a version in the CVS repository, in less than a couple of days (the biggest amount of time was working out what the batch files where doing so I could replicate the build in Ant).

    Does anyone know when WSAD will be based on Eclipse 2.0 and have EJB 2.0 support? I would like to buy WSAD now but only if I know I can get the upgrade to that feature set for free. Technically here at work we don't qualify for the developer toolbox subscription (well, we couldn't use the tools for our dev work legally) so I'm paying full price; ergo I want full service.
    regs
    scot.
  50. So to get a file in the ide that is currently not checked out


    I could be misunderstanding your requirement here, but won't the Project import (file/Import.. menu) get you up and running with non-cvs local files?

    If you you want a file editor rather than a project IDE then Eclipse is certainly not for you.


    I have pulled my deveopment team off Netbeans/Forte in favour of Eclipse: Here are my reasons:

    - Speed. I had a _lot_ of complaints from my developers about the speed of Forte.

    - Stability. Every installation of Forte seemed to behave slightly differently, especially when using CVS. In fact CVS was so unreliable that it was a project rule not to use Forte for CVS checkins/updates.

    - Productivity. The refactoring/completion/template/search tools are significantly better under Eclipse, leading me to hope for noticable productivity gains once the pain of moving over is complete.

    /david
  51. I could be misunderstanding your requirement here, but

    > won't the Project import (file/Import.. menu) get you up
    > and running with non-cvs local files?

    It does detect the file, but until the files are checked out (not just synched to the local file system) they are read only, which makes the IDE view them only. If the tools were more quicky accessable (like being able to bind them to a one key-stroke sequence or add them directly (as one button, not in a button menu) to the toolbar) then it wouldn't be that big a deal. But otherwies I need to drill down on the tools menu or the drop down button in the tool bar, I can't just go 'ctrl-e' when I need to open it or leave the mouse pointer on the toolbar and click and come back.


    > If you you want a file editor rather than a project IDE
    > then Eclipse is certainly not for you.

    But if I cannot edit files to my satisfaction it becomes another piece of shelfware far removed from the rubber and the pavement. A Project IDE must have as it's foundation the ability to edit files as the user requires, or the user will not use any of the project management features, and quite honestly (as you point out) would be better with vi or emacs.

    > I have pulled my deveopment team off Netbeans/Forte in
    > favour of Eclipse: Here are my reasons:

    Lucky you the job market is so bad. A couple fo years ago I bet some of your developers would have quit rather than being forced to use an IDE, at least make them think they have a choice.

    > - Speed. I had a _lot_ of complaints from my developers
    > about the speed of Forte.

    At least when I change a project directory property in NetBeans/Forte it doesn't spend minutes re-compiling the whole freaking project. As for Forte/NetBeans recent JDKs and more current NetBeans builds have mitigated this problem alot. A newer version of forte is coming out based on this code.

    > - Stability. Every installation of Forte seemed to behave
    > slightly differently, especially when using CVS. In fact
    > CVS was so unreliable that it was a project rule not to use
    > Forte for CVS checkins/updates.

    Sounds like your problem is not Forte but CVS. For something as critical as Source Control one shouldn't be afraid to spend money. And wait until each developer starts adding their favorite Eclipse plug-in, and the revise versions of those plug-ins. This is hardly a problem unique to nor created by NetBeans.

    > - Productivity. The refactoring/completion/template/search
    > tools are significantly better under Eclipse, leading me to
    > hope for noticable productivity gains once the pain of
    > moving over is complete.

    "Leaing me to hope," best wishes man. I would be willing to give those a spin if I could just get customizable keyboard bindings or toolbar bindings, three clicks to check out the file I am currently attempting to edit after using the search tool is two clicks too many. And the more clicks or windows it takes to run the cannoncial build the more and more developers are going to ignore that cannonical build. And real ant integration, not "run this task after two menus and a dialog box" but to use it to do the building both incramentally and in total.



    I'm not saying Eclipse is crap, it looks to be a fine tool, but when it comes to day in/day out development a tool you cannot easily customize to the way you like it is a tool you will be less and less likely to use. The tool should adjust for the developer, not the developer for the tool. I am sure there are many people who are happy with eclipse the way it is, but I am nt one of them.
  52. What is so hard about right clicking on your ant build xml and selecting run ant?
  53. It does detect the file, but until the files are checked out (not just synched to the local file system) they are read only, which makes the IDE view them only.


    OK - like I say, Eclipse is project-based. You want an editor, use VisualSlickEdit or the like.

    > Lucky you the job market is so bad. A couple fo years ago I bet some of your developers would have quit rather than being forced to use an IDE, at least make them think they have a choice.

    Yeah - Prima Donna developer attitudes caused a lot of projects to fail during the dot-com boom.

    > At least when I change a project directory property in NetBeans/Forte it doesn't spend minutes re-compiling the whole freaking project.

    I know some people don't like that (c.f. 'Old dogs, new tricks'). It's a trade-off: What you get in return is a parser DB that's always up-to-date, and an 'intelligent' search/refactoring facility that brings up method (etc) references very quickly. Try renaming an entire package in Forte and see how long it takes you to sort out the broken code...

    If you've used RefactorIt, you'll know how long it takes to rebuild it's DB - why should Eclipse not be excused the time when it's doing a similar thing.

    > A newer version of forte is coming out based on this code.

    Yeah - that's finally why we went to Eclipse: Version 4 had innumerable problems trying to upgrade v3 projects (maybe something to do with the plug-ins we were using)

    > Sounds like your problem is not Forte but CVS.

    No it was Forte. Code-trees kept on going 'off-line' (local) and stuff like that. We had CVS working like clock-work using Tortoise (and hopefully will again using eclipse).

    > For something as critical as Source Control one shouldn't be afraid to spend money

    Agreed - apart from the fact that CVS works, of course!

    >> leading me to
    >> hope for noticable productivity gains once the pain of
    >> moving over is complete.
    > "Leading me to hope," best wishes man.

    My previous experience of VisualAge (and private evaluation of Eclipse for the last 6 months), makes me believe that the kind of basic refactoring/template tools provided by eclipse can take a lot of the tedious effort out of creating the likes of bean classes, etc. A lot of coding we do is 'dumb' in the sense that we know what we want to do, its just typing all the words that the the limitation.

    > The tool should adjust for the developer

    Probably right in theory. I've used so many tools over the years that it's just another one...

    /david
  54. David,

    <quote>
    Lucky you the job market is so bad. A couple fo years ago I bet some of your developers would have quit rather than being forced to use an IDE, at least make them think they have a choice.
    ---
    Yeah - Prima Donna developer attitudes caused a lot of projects to fail during the dot-com boom.
    </quote>

    Sounds like big crap what u are trying to tell us. Are you actually coding applications or are you just the one deciding what IDEs developers should or better said MUST use??

    Do you imagine how much productivity you lose just because
    of switching from a good IDE to another good IDE? A lot! I
    mean a developer capable of neat shortcuts, tools and tricks of a certain IDE will having hard time to reach this level with the new one and why? Despite of the emotional issue with IDEs...

    Just because its fancy to say we all use _the same_ IDE?
    I would have some problems when someone decides what tools i have to use. I havnt done this ever when i was in some development lead.

    Hear the interview of the BEA engineer on this site (who works on the EJB container), he said that some work with Emacs, some with other IDEs. I think thats the normal way out there.

    Hell, i just imagine that my boss comes into my office and telling me that from now on i have to use Jbuilder instead of IDEA... would end in laughing i bet.

    And yes, if the attide in a company is that there is no personal freedom in chosing tools and environments, i would leave without a hassle. It seems that i am a primma-donna then...fine.

    marc
  55. Actually, until the recent flood of low cost / free IDEs came out, the policy of most large companies was PRECISELY that you used the corporate standard. Period. The End. IDEs cost $1000+ so the company negotiated a corporate discount and that's what you used. It was an important cost control measure.

    No offence, but you need to at least acknowledge the fact that there's more at work inside a company than your personal preference of tools to use. At the end of the day the company is trying to make money.

    That said, most corporate IDE decisions leave something to be desired. Fortunately the rules all changed when IDEs became so cheap and even free.

    The rules still apply to databases and other such more expensive products in most companies though. Would you leave a company because the corporate standard was Oracle and you wanted to use SQL Server?

    Fact of life. There are standards in companies. Some you like, some you don't. Some make sense, some are ridiculous. Occaisonally a ridiculous standard can be overturned, but not that often unless you are a) senior and b) brave! :)

    Chz

    Tony
  56. Sounds like big crap what u are trying to tell us. Are you

    > actually coding applications or are you just the one deciding
    > what IDEs developers should or better said MUST use??

    No - I eat my own dogfood, so to speak.

    > Just because its fancy to say we all use _the same_ IDE?

    No - because a free-for-all is a serious project risk.

    * Developers cannot share learning curve - each one has to work out his own set of configs/plugins etc.

    * they cannot piggy-back off the prep-work that I've already done. (I got my developers to provide me a list of the features in Forte that they liked/used regularly, and I have located plug-ins and prepared documents to help them with the change and features that they might miss.)

    * Means a whole load of different project configurations and files. Changes to project config on one tool cannot be easily reflected to another leading to losses in productivity.

    * Also some tools/plug-ins require a particular directory structure to work properly. Conflicts between these can become an absolute pain to sort out. Configuration management in general becomes increasingly difficult.

    * It becomes much more difficult for me to mentor the team if the issues they are bringing to me involve a different tool in each case. I would _like_ to get to go home occasionally!

    > And yes, if the attide in a company is that there is no
    > personal freedom in chosing tools and environments, i would
    > leave without a hassle. It seems that i am a primma-donna
    > then...fine.

    No - probably just young. I used to think the same as you. And if you're the only person on a project, then who cares what you use.

    But software is about delivering solutions. To do that reliably, I have to reduce risks - your approach is very risky in a team environment.

    /david
  57. Sounds like big crap what u are trying to tell us. Are

    >> ou actually coding applications or are you just the one
    >> deciding what IDEs developers should or better said MUST
    >>use??

    > No - I eat my own dogfood, so to speak.

    sorry, the message sounded a little bit agressive,
    perhaps i am emotional with my environment too :)

    I can share some of your thoughts about teamwork,
    but basically developers must agree on a versioning
    system.

    It shouldnt play any role if the developer have different
    project files as long as the primary paths are the
    same like /src /classes or whatever. In a versioning
    system you wont store any project files anyway...

    It would surprise me if the team-members comes to you
    and ask for help on their very own IDEs :) so there
    is no need that you must know different tools IMO.

    I agree with you regarding techtalk between the developers
    regarding the _one_ IDE which can be quite helpful, but i assume that developers know their environment quite fast, so 99% of the question are in the java space, not in the tool space.

    BTW i dont have anything against company standards for things like databases or versioning systems.

    One question still exists: if a very skillfull java
    developer would join your team, but with strong focus
    on linux, would you force him to change to windows?
    (when windows is company guideline)

    I definitely would not, but i think you would ... and
    yes...perhaps its because i am not over 30 years old :)

    see you.

    marc
  58. I have seen this SWT Vs Swing debate many places.
    Take a look at Karmira Bug Seeker. It's look and feel
    is far better than any other Native WIndows Application.
    It was developed in Swing.

    Instead of developing new APIs like this why they do not
    reimplement Swing?

    Here I mean reimplementation means SAME API with different implementation.

    If Swing is bad one has to correct the implementation If
    Swing performance is improved all existing applications written in Swing will benefit. This reinventing of new APIs should be stopped.
  59. Is simple as this:

    Eclipse: FAST!
    NetBeans: SLOOOOOOW

    You decide.
  60. Netbeans. Great IDE.[ Go to top ]

    Not sure it's that simple ... ;-)

    From my experience, I do not see any difference between the speed of native OS GUI and speed of Netbeans.

  61. JDeveloper[ Go to top ]

    I´ve used Netbeans, I´ve used Forte, I´ve used Eclipse. And I´m using JDeveloper. It really shines! Of course, the things I like more with JDeveloper are related to BC4j, and it´s not free, but it´s cheap, and it´s a great development boost.
  62. sorry, the message sounded a little bit agressive,

    > perhaps i am emotional with my environment too :)

    I've got attached to tools in the past (but it's always ended in a separation!).

    > It would surprise me if the team-members comes to you
    > and ask for help on their very own IDEs :) so there
    > is no need that you must know different tools IMO.

    That's the theory. I found with Forte that there were various (usually CVS module) issues I had to help fix.

    The other point that I forgot to mention was that we're building/deploying a J2EE/EJB system, which requires fairly convoluted project/build set-up and files. This led the team to have a common setup which was actually in existence before I joined.

    > but i assume that developers know their environment quite
    > fast, so 99% of the question are in the java space, not in
    > the tool space.

    Agreed up to a point. However as tools become more sophisticated (and the existence of plug-ins for both Eclipse and Forte introduce more and more variables on this).

    Really depends how complicated your project setup and build processes are.

    > One question still exists: if a very skillfull java
    > developer would join your team, but with strong focus
    > on linux, would you force him to change to windows?
    > (when windows is company guideline)

    Tricky. Whichever solution I went for I would be wrong!

    If I allowed him to set-up his own box, he would have to be on his own in terms of support and network integration, which would be fine, but I just know that there would be config issues that would sap his productivity. (For my sins I once ran the only OS/2 box in a totally Windows company. There were reasons for it - honest!)

    If I forced him to go to Windows I would also be sapping his initial productivity, not to mention pissing him off. But at least he would have a lot of support from his colleagues (who are probably also pissed-off ex-Linux people)!

    Tell you what - can't he go and work for your company instead?!!!

    > I definitely would not, but i think you would ... and
    > yes...perhaps its because i am not over 30 years old :)

    If it was to be on the current project that you're probably right - apart from anything else I'm intrigued to know how the eXtreme Programming practice of pair programming would work with radically different set-ups from computer to computer! Anyone out there tried that?

    But I have also been on your side of the argument - working for ........(fill in name of large investment bank here!) a couple of years ago, I brought tools in from home, because none of the ones that were approved by their corporate purchasing would do the job...

    So I do appreciate your sentiment, although I would say that walking out of a job because to are forced to used certain tools would be a bit extreme...

    /david
  63. To Tony Brookes and Marc Logeman,

    I would submit to you both that the issue of letting developers choose operating systems and development tools is really dependant on the situation.

    I used be a development lead for a large company that was primarily windows. Some of the developers wanted to use Linux and their own tools. Management didn't like it, but I made a deal with them just to see how things went. I said, if they support their own stuff, and productivity doesn't get badly impacted, let'em keep it. Otherwise we all go to windows. Unfortunately, there were some junior developers who were spending too much time screwing around learning Linux, so we all went back to windows.

    Didn't really bother me much. And it was kind of an interesting experiment. Now I work at a place where there really are no junior developers. We are a research only institution, so there's a lot of experience. There are people using HPUX, Windows, Solaris, and Linux. There are no problems here. People using JBuilder, IDEA, VI, EMACS, Netbeans, Forte. No problem there either. For the last year I've been working with a group in the midwest, and I'm in Oregon. They work for a different group. How am I going to dictate to them what to use, even though I'm in control of the source, architecture, and development standards. This project worked just fine (just went live last week, yay!)

    I don't let anyone check in development specific files (like a bat/sh file or anything that helps them set up their developmet environment). I wouldn't let them do that even if we were all on the same platform. I want to be able to build cleanly from CVS.

    Essentially what I'm saying is, if you have a group of high level developers that all understand the impacts of the things they do, then let'em use the tools they want. In J2EE projects, there really isn't much of a problem here if managed well.

    If you've gotta group of newbies, then you standardize, or you'll go nuts trying to to keep people developing, and keep your code repository clean.

    -Newt
  64. Jason,
          Your point is entirely valid but does not take into consideration the immediate econommic costs. In a lot of companies I worked for (going back 4 years to when IDEs cost a LOT of money) it was simple economics. Company X has done a deal to get JBuilder for a 50% corporate discount. We all use JBuilder, end of conversation.

    That has all changed now and I can see the merit in letting people choose what tools to use, except that the standards in use on the project must also be considerd.

    For instance, as another poster said, what if you're operating under XP with pair programming. Don't see how that works if you all use different tools. Pair programming requires some degree of homogeneous development environment. There are other examples but this one is good enough to make the point.

    We all accept corporate standards for things like databases, operating systems (for production environments), etc etc. Why? Because we accept that the cost of the software and the cost of supporting it would be too great to allow diversity in these areas. The economic cost of buying the software for IDEs has largely become a none issue, but the cost of supporting it (Be it a central support team or just lost productivity for developers) is still there, if far less quantifiable.

    I agree that more experienced developers should be given more control these days, but, just to play devil's advocate for a moment, is it not also fair to say that an experienced talented developer is capable of working with just about whatever tool you throw at him? To my mind, an "experienced" developer who can't use VI is not experienced at all. The true high worth people to have on your team are those who can be thrown into a mess and make sense of it with the tools they have around.

    For example, take a production internet facing site with a production problem. No tools deployed there. Need someone who can telnet in, work their way around the file system, find the logs, look at them in vi, attach truss to the process and then decipher the output, connect a Java debugger etc, all from the command line with no tools around to "wizardize" it. That's a great person to have on a development team, because sooner or later you WILL get a production problem which requires development teams to get involved to work it out and fix it. If they've no knowledge of anything but their favorite IDE then you're in trouble.

    So, if you have a team of this kind of person, then whatever tools you give them they'll work their magic and produce. That said, I still agree it's not worth making their lives harder than it has to be. But, like the airlines (the planes can all land themselves these days...) they still make the pilot land it every now and again to make sure he knows how. Make sure your development team can still get down and dirty with the CLI. :)

    Chz

    Tony
  65. Tony, another way to put it is, you employ a developer for their development skills not for their IDE skills. Just like a graphic designer is not just a guy who knows photoshop, a developer is not a guy who knows how to use JBuilder. In fact he's not even a guy (or girl) who knows how to write Java.

    But Jason has a valid point there too; which is to say, you always have to take account of the situation. Sometimes it is appropriate (or simply unavoidable or potentially even necessary) to specify to the team what tools they use. Other times, it doesn't matter, or individual developer satisfaction and productivity is more important. Again I think it is simply situational.

    But your original 'dot-commer' comment was spot on, if a developer wants to be a primadonna then get another.
  66. Tony,

    Some very good points there (although I still hate VI, but lets not get into VI v EMACS again). I guess I'll clarify a little bit. I do agree that a good developer should be able to work with anything, and should be able to just get thrown into the mix and do the job. I've done that myself quite a bit. Sometimes you just have to figure it out.

    In terms of economies, I didn't mean that one is better than the other. My sole point was, know your developers and your environment. Then decide on tools (or just to let people run) . I agree that in an XP environment, maybe a standard is best. But again, a good development lead will create the best economies from a number of factors. In my old job, it made sense to standardize (economically and every other way I can think of).

    In my current job, it would be an adverse economy. My marginal cost/developer would likely go up if I tried that (besides the fact that I'd have a mutiny). But I/we do standardize many things, like coding standards yadda, yadda, yadda, to keep the free-for-all in check.


    On a side note, do you actually allow developers to access production machines? My systems people wouldn't hear of it, and I think they're right about that. Last I checked, most professional development groups/companies agree with me there too. We'll often let developers access staging for that purpose, but never production. Are you doing development/production? or development/staging/production.
  67. I think we basically agree with each other.

    In general I would NEVER let a developer have access to a production system. It's ususally the support teams who don't want to know about it.

    But if something really horrible is wrong, the same support team are all for developers logging in with a firefighting account (read only access to everything, password gets changed once the emergency is over.)

    That way your developer (who will know the application best) can see what's going on while he provides stimulus to the system.

    Other than that, the only member of the development team I ever let log into production would be the "project administrator" or "the guy who builds it and deploys it." Sometimes that persons under the development lead, sometimes not. But he kind of needs access to do his job. :)

    I do agree that standards are good in the right environment and bad is others. To put it simply (and in a way I find quite amusing...)

    "There is an exception to every rule.......except this one."

    :)

    Chz

    Tony
  68. I'm gonna have to quote you sometime on that. But I'll attribute the copyright to you...

    -Newt
  69. I have just given Eclipse 2.0 a try, like I did with 1.0 some time ago. But the impression is basically the same: IMHO Eclipse seems unintuitive, especially its project and file system view. Forte's is flexible and simple to setup but a bit slow, IDEA's is the best I have ever seen - intuitive, simple to setup, flexible, fast.

    Eclipse takes lots of time for scanning the project directories and automatic rebuilding. And I have to say "Refresh" if I manually add a file to a project directory to see it *ARGH*. Have a look at IDEA to see how fast and implicit this can be - while maintaining proper directory views and code structure caches for searching and refactoring.

    And where is a selective "Compile" command? Do I have to rebuild the whole project just to see if the class that I currently edit compiles?? Is this not supported in Eclipse or just so hard to find? Why does it sometimes tell "project directory is consistent" and refuse to build?

    Altogether Eclipse is not the stunning Java IDE it promises to be. OK, it's free, it seems faster than NetBeans/Forte, it has some basic refactoring features. But Forte 4 has got really great web application development and debugging features and a lot of other goodies. So IMO there is no clear winner between these two freebies.

    Again: Have a look at IntelliJ IDEA! It may cost 395 USD but it is worth every penny: It has a great Java and JSP editor and the best code navigation, code analysis and refactoring support I have ever seen. And it could be used to define the term "intuitive IDE".

    Personally, I keep working with IDEA as my main IDE and Forte 4 as my JSP source level debugger. BTW it's very easy to configure them for the same project directories and thus be able to switch without overhead. The rest of my team uses either Forte 4 (web developers) or IDEA (thick client/middle tier/database tier developers).

    Regards,
    Juergen
  70. I forgot to mention: version control systems. Eclipse just supports CVS (didn't test that, though) while both IDEA and Forte support MS Visual SourceSafe (used at our company) too. Forte even supports numerous other ones.

    And it's worth noting that Forte 4 supports VSS in its Community Edition, not just in its Enterprise Edition like JBuilder 7. The same applies to web app support: Forte 4 Community Edition gives you excellent JSP/Servlet support for free - JBuilder 7 does so only in its 3000 USD Enterprise Edition. IDEA has VSS support and basic JSP support for 395 USD.

    Juergen

  71. Eclipse takes lots of time for scanning the project directories and automatic rebuilding.


    At first, yes. Wait 'till you've stopped messing around with project settings - you're not using it like a day-to-day user at the moment.

    The best bit about the continual rebuild is when you're making big changes to a module - really hacking it to pieces and rebuilding it. Then you continually have a list of the failures - a task list of the bits you need to fix before it's done. So you always know what you need to fix next, and it really helps give you the confidence that when you think you're done, you are actually done.

    > And I have to say "Refresh" if I manually add a file to a project directory to see it *ARGH*.

    Why on earth would you be adding files from outside the IDE on a regular basis?

    > And where is a selective "Compile" command?

    Why would you wnat one if the file is always compiled when you save it?

    > Do I have to rebuild the whole project just to see if the class that I currently edit compiles?

    No - just save it!

    > Why does it sometimes tell "project directory is consistent" and refuse to build?

    Never seen it. You're not adding files from an external source again, are you?

    > it has some basic refactoring features.

    Actually, I think they qualify as a bit more than 'basic'.

    Re: Non-CVS version control.
    I think you'll find that there are a number of third party version control plug-ins arriving - you need to look around.
    Try http://eclipse-plugins.2y.net/eclipse/index.jsp
    which has a list of plug-ins.


    Remember, Eclipse is not quite an IDE as such. It is a tools platform, and as such a lot of the plug-in tools are at an early stage (or not there!), the only thing that is mature is the Java plug-in that they provide themselves. The workbench has to exist before the plug-ins after all!

    I like it for the core Java stuff it has at the moment, and the potential for the future as an integration platform. But that may not suit you.

    /david
  72. Why on earth would you be adding files from outside the IDE on a regular basis?


    I don't know, maybe from sync'ing to a source code repository?
  73. Why on earth would you be adding files from outside the IDE

    >> on a regular basis?
    > I don't know, maybe from sync'ing to a source code repository?

    I expected someone to mention that scenario. I'll be honest that if my version control system wasn't covered by a plug-in, then I probably wouldn't use Eclipse.

    Especially if the version control was pessimistic, since then the whole 'check-out and make writable' thing would be too much of a hassle.

    /david

  74. This is yet another tool that still cannot beat emacs. I see nothing in it to make me switch.


  75. Eclipse 2.0 IDE Platform Released[ Go to top ]

    Then how about this - http://www.eclipse.org/ajdt/index.html

    If you like it, keep using emacs. Diversity is good. I, on the other hand, love Eclipse. It has some things that are really useful to me. And stepping up to WSAD - Wow. Now all I need is the GUI tool and I will be set.
  76. Eclipse 2.0 IDE Platform Released[ Go to top ]

    The IBM website is a little un-informative regarding WSAD. What does that IDE have / do that Eclipse doesn't. I can't find anything anywhere, not even a screenshot, but then I'm not in the market to buy an IDE so I haven't been looking that hard.

    So what's it do?

    Chz

    Tony
  77. The IBM website is a little un-informative regarding WSAD

    > So what's it do?

    The summary (as I understand it) is the same as Eclipse, but with plugins for Websphere/EJB/WebServices development...

    Quote from the blurb for WSAD Integration Edition for Windows, v4.1:
    "WebSphere Studio Application Developer Integration Edition is designed for Enterprise developers creating and integrating Java and J2EE applications. Application Developer Integration Edition contains visual tools and wizards that generate Java classes, servlets, Java Server Pages (JSP) components, hypertext markup language (HTML) prototypes, eXtensible Markup Language (XML) documents, Web services, and Enterprise JavaBeans (EJB)."

    Main info is at http://www-3.ibm.com/software/ad/studioappdev/


    In my travels I found an interesting page called WebSphere Studio Plug-in Central...

    http://www7b.software.ibm.com/wsdd/downloads/plugin/

    It contains some plug-ins that I've not seen listed for Eclipse: Does anyone have any success to report with any of these (apart from the Rational plug-in that does state it works with Eclipse)?

    /david
  78. Eclipse 2.0 IDE Platform Released[ Go to top ]

    I haven't any experience with any of the other plugins. I do have WSAD and Eclipse. The summary from IBM pretty much covers it. WSAD has everything Eclipse has plus everything listed. I saw a demo on it from IBM a few months back - other than the lack of a GUI builder (and seeing how noone is doing that anyway ;) ) - it is very powerful and I would say with the builtin refactoring, JUnit and now AspectJ it is way beyond VS.Net. I'm only comparing IDEs NOT languages (Because there is a C# plugin).

    A note - the Integrated Edition is a step up from the plain WSAD in that it allows one to do things with CICS, etc.

    Check out this link and look under "WebSphere Studio Application Developer Integration Edition" header.
    (http://www-106.ibm.com/developerworks/ibm/library/i-wsadie/?loc=dwmain)
  79. Eclipse 2.0 IDE Platform Released[ Go to top ]

    Mark,

    Let me ask you for an opinion. I have spent time with Eclipse 1.0 and WebSphere 4.0, but not with WSAD. Based on what I read, one of the major features WSAD offers if you are using WebSphere 4+ is the mapping UI for CMP EJB. I guess it's possible to edit those ulgy mapping files by hand, but I supect that's not optimal... hence the carrot to use WSAD, IMO. So here's my question. If one is not going to use entity EJB's on their project, maybe JDO or RYO persistence layer with plain old java objects, wouldn't the major reason to use WSAD have been eliminated (i.e. CMP EJP mapping)? It would seem a free (Eclipse) would be more than sufficient in a non entity EJB world.

    Mike
  80. Eclipse 2.0 IDE Platform Released[ Go to top ]

    There also is a Web (built in support for Websphere) and XML view and are very good. I've used both and not used EJBs yet (We are doing Persistance Builder and will need to convert) although I've toyed with them. If you have tools to do these things (there is a Tomcat plugin) or don't need them then I would say Eclipse 2.0 (Yes - get 2.0) would be fine. I would still like to see a GUI builder show up. One is promised from IBM but I don't know if it will be WSAD only. There is an opensource GUI tool on SourceForge but I believe it is in its formative stages. So for now we will be using the bridge (Instantiations) from VAJ 4.0 to WSAD to do GUI.

    You don't have to use WebSphere to use WSAD or the other way around. We use WebSphere but could easily switch to something else.

  81. Eclipse 2.0 IDE Platform Released[ Go to top ]

    Mark,

    "So for now we will be using the bridge (Instantiations) from VAJ 4.0 to WSAD to do GUI."

    What is that? Is that a utility to migrate GUI development from VAJ to WSAD? I noticed a local job posting for VAJ 4 and WebSphere 4. I was under the impression that once you moved to WebSphere 4, WSAD would be the appropriate "commercial IDE" offering from IBM. Is it feasible to do WebSphere 4+ development with Visual Age? Seems like VAJ is a tool / skill that will be phased out.

    Mike
  82. Eclipse 2.0 IDE Platform Released[ Go to top ]

    Mike,

    http://www.instantiations.com/

    Instantiations is the company. CodePro is the tool(s). One of the things that CodePro does is, after migrating code to WSAD, launches VAJ 4.0 so that GUI editing can be done with the VCE. It handles it all. VAJ 4.0 comes with WSAD and WSAD is its successor.

    You can use VAJ 4.0 with Websphere 4.0. It really depends on what you do. If you do nothing Websphere specific, which we don't, then there is no issue. If you are doing EJBs, which we aren't, then that might be an issue.

    Deployment will be different. Deployment from VAJ to Websphere is a manual process. WSAD has a real version of Websphere and deployment is an 'automatic' process.

    As a side note, if you can do VAJ you can do WSAD. :)

    Mark
  83. Eclipse 2.0 IDE Platform Released[ Go to top ]

    I've been using Eclipse for about 6 months and so far I had a very pleasant experience. Prior of Eclipse I used some other IDEs (JBuilder, NetBean etc) but in my opinion Eclipse is one of the best.

    I have a couple of questions about Eclipse:

    1. Is anybody used Eclipse with Weblogic Plugin from Genuitec?? How practical is and how much you recommend it??

    2. Starting with Eclipse 2.0 all the perspectives opened at one time displays only one file. For example I can't have opened in the Resource Perspective one file (let's say a jsp) and in Java Perspective another file (java file).

    This restriction is very inconvenient for mine, so I was wandering if anyone knows a way control this behaviour.

    Thank you!
  84. Go to Windows|Preferences

    Then expand Workbench and click on Editors.

    There is an option "Close editors automatically."

    If will be checked.

    Underneath is a text box labelled "Number of opened editors before closing" and will have a 1 in it.

    Two things you can do...

    1) Uncheck the box. You can then open as many editors as you feel like.

    2) Change the 1 to a more reasonable number. I have mine set to 5, otherwise I end up with stacks of open files which is just irritating.

    That ought to sort out your problem.

    Chz

    Tony
  85. <quote>
    This is yet another tool that still cannot beat emacs. I see nothing in it to make me switch.
    </quote>

    Everytime a discussion regarding IDEs occurs, somebody inevitably has a comment similar to the one above. So pardon my ignorance to emacs, but what the hell is it?

    I have never really used it (although some of my co-workers swear by it). I always thought of it as just another text editor, albeit a good one. Something like vi on steroids. Here is what I get from the GNU Emacs site:

    "Emacs is the extensible, customizable, self-documenting real-time display editor."

    If that is the case, it does not seem to warrent a comparison to an IDE. IDEs (Eclipse in this case) seem to do a hell of a lot more than just text editing, such as debugging, incremental compiling, automated refactoring, integrated source control, etc. Unless I am missing something SIGNIFICANT about emacs, than "I see nothing in it to make me switch."

    If I am ignorant to the power of emacs, please enlighten me. And if anybody can enlighted somebody, it would be Albert Einstein :-)

    Ryan
  86. There are some enhancements for EMACS (e.g. Java Development Environment for Emacs -> JDE) that makes emacs look like an IDE. With lots of nice Editor features and JDE Emacs really is a nice IDE for advanced Emacs users who are very familar with its features and the Emacs-Lisp Macro language.
    But I agree with you, that for 99% of the developers Emacs isn't really an alternative to IDE's like Eclipse or IDEA IntelliJ. They have nice editors (I like the Eclipse feature s like code completion, code surroundings, automatic imports, Java Doc comment on Mouse over, refactoring...), good integration with JUnit, Ant, etc. and often good Team programming support, like the CVS integration in Eclipse (ok Emacs has it, too).

    <Mirko/>
  87. Eclipse 2.0 IDE Platform Released[ Go to top ]

    Ryan,
      My 'favorite' thing is seeing a comment like this and then comments complaining how bad Java IDEs are and how they should be like that other one from that one company. Which is it? If we don't need IDEs, why do we need good ones? Why spend money on developing IDEs is no one is/should be using them? Why whine about crappy IDEs (I don't agree that there no good ones) if one really isn't needed?

    Eclipse and Netbeans and the tools built on them are the future of Java IDEs (IMHO). Look at StarOffice/OpenOffice and the response to them.
  88. <quote>
    This is yet another tool that still cannot beat emacs. I see nothing in it to make me switch.
    </quote>

    Use whatever you feel comfortable with. That's a subjective issue.

    Eclipse (and IDE's in general) are light-years ahead of emacs when it comes to Java editing. That's an objective statement.

    Emacs can only know so much about the source file it edits. Its knowledge of the source file is syntactic at best, which limits tremendously the amount of work it can do for you. IDE's know what Java is, they interpret the bytecode, understand the type system, and are able to provide information that emacs users don't even dream of because they are locked in their habits. Tell me about it, I used to think that I would never leave emacs too.

    Of course, theoretically, it's possible to do all that in emacs. In practice, emacs is still two years behind any simple Java IDE, and the gap is widening every day.

    And before you accuse me of not knowing what I'm talking about, know that if you are an emacs user, you are most likely using some of the elisp code that I contributed to it something like ten years ago :-)

    --
    Cedric
  89. <p>
    I have been waiting for this milestone release of version 2 with lot of interest. Eventhough I used to work on Visual Age for Java for a long time, it started to become head ache for me, because of it's repository based system and tight coupling to a particular JDK vis a vis a release of IDE. I shifted to JBuilder. It is pretty good IDE. Simple no non sense funtionality. In the mean time I evaluated NetBeans/Forte product. Eventhough there is nothing bad about these IDE's, they lack tuning ( I am using little car business terminology here). What I mean is for many things they need lot of configuring, some times they provide too much flexibility, which is a head ache.But I always believed IBM people make a great product. Here they are !!
    Eventhough I don't care whether they used AWT or SWT, it works smooth. Right now, technologically, I don't see any merit of Eclipse IDE over NetBeans/Forte. Just because of IBM support and their proven expertise in IDE development, this IDE seems to be promising. I slowly start using it for my everyday work. My request to SUN is to participate in this Eclipse platform development, so that there will be a good tool for Java developers something like MS visual studio.

    Prasad
  90. I apologize, this is really a WSAD question more than an eclipse question... I currently use JBuilder 5 but would very much like to use WSAD as several of my coworkers do.

    The problem for me is that web application development seems very, very slow. Compilation, debugging JSPs, Servlets, beans in a web app, and stopping/restarting the server all seem to be very slow operations in comparison to the seconds I'm used to these steps taking in JBuilder.

    Am I missing something or is there this this performance difference? Is there a way of minimizing it? Is there an improvement coming?
  91.  Codeguide from Omnicore has the same nice features:
    codecompletion,refactoring etc.
    I really like it.
  92. <quote>
    Sorry. It doesn't run on OS/2 and yes it does break the most important features of Java cross platform. I have not written a single program in Java in the last 4 years that has not ported PERFECTLY to every single platform.
    </quote>

    I agree.

    Java success is due it is ON TOP of the operating system and hides it (it is the reason because Microsoft has tried to break Java technology bounding it to Windows first, and next developing a similar and competing technology like Net).

    In practice, Java is like a operating system (on top of other), so it *must* minimize depedencies of underline O.S. (using low level resources) if wants running with the *exactly* same behaviour in all systems.

    Other example is Mozilla 1.0/Netscape 6: it runs with no differences in many platforms and conforms with W3C specifications because it doesn´t use native UI widgets. Is very difficult simulate the very flexible behaviour of W3C standards with native Windows widgets, Microsoft can do it because they can leverage the Windows GUI, Mozilla/Netscape will stay behind ever then.

    It makes difficult evolution and new features: it must be implemented in other platforms.

    Innovation vs standards:

    With innovation you try stay ahead of the industry, with SWT it is not the case, IBM try to make a new standard controlled by them against Swing, there is no innovation here.

    Two open standards, what is the problem?
    The problem is .Net, if Java is breaked with disparate standards, people will have a new reason to change to .Net (totally controlled by Microsoft).





  93. <quote>
    Two open standards, what is the problem?
    The problem is .Net, if Java is breaked with disparate standards, people will have a new reason to change to .Net (totally controlled by Microsoft).

    </quote>
    By the same reasoning we should have just one App Server,One Servlet Container,One persistence mechanism...

    Yes , Portability is important to me, but not at the cost of usability. Most users want a snappy and responsive interface. They don't care that the exact same program can be run on 20 different platforms without making any changes.

  94. <quote>
    Note: I don't use Eclipse, I use Intellij IDEA, but some...
    </quote>

    one of the best decissions you ever made :)

    A friend of mine told me that with Eclipse 1.0 where
    the first version of WSAD based on, wasnt able to
    show up line-numbers ... sounds crazy...
  95. I've never worked with RefactorIT, I am sure that it goes far beyond what Eclipse offers, since that is their specialty. I was viewing Eclipse from the perspective of the marketplace it occupies (open-source, freely available IDEs). For this market, I don't think there is anything that compares to Eclipse in terms of refactoring. In my personal opinion, it has the best usability as well. I must confessed that I don't like 95% of the Swing interfaces out there, so as long as Eclipse runs on Windows & Linux, it works for me. There is a port project for Mac as well, so that should cover most of the desktop systems. If you are still stuck using OS/2, then I feel for you.
    I am sure that it is a lot easier to port SWT to other platforms than it is to port C++ apps to other platforms.
    For the line numbers thing, yes, you could not view line numbers, which of course is stupid. If it makes u feel any better, then you could jump to a specific line # by right-clicking inside the editor. But that's irrelevant now because 2.0 shows you the line numbers too.
    I really think that SWT goes a long way to providing a Java based windowing toolkit. Most people that I know will never trade a C++ fat client for a Swing Fat client just for portability's sake (I'm talking end users here), for the main reason that it just looks crappy. SWT looks clean, professional, responds well, and it is available for most of the platforms on which it is likely to be used.
    My .02.
    Best,
    Ray
  96. Surely you haven't seen IntelliJ IDEA. While Eclipse offers 5 or 6 refactorings, IDEA has close to two dozens of them - what's great they work in comments, strings, renames take EJB cases into account (as IDEA treats EJB class as inheriting from remote interface). I have tried all other major IDEs and none comes close to IDEA in terms of ease of work, code completion and assistance. Plus, it has almost no wizards (though some people can't stand it)
  97. <quote>
    By the same reasoning we should have just one App Server,One Servlet Container,One persistence mechanism...
    </quote>

    It is the reasoning of Microsoft marketing: one operating system (Windows), one hardware platform (Intel, ok Alpha too), one development enviroment (Visual Studio Net), one languaje (C#, ok ASP too), one library and framework (.Net), one deployment environment (IIS .Net), one persistence (SQL Server), one browser client (MSIE). All of them are severely coupled.

    With Microsoft, life is "easy", initially, but you are *totally* locked to one only vendor.

    Java offer:
      - One operating system: Java environment, but running on top of many O.S.
      - Many hardware platform but no need to recompile or port.
      - Many development environments and tools, but the developed code can be ported with no change if you use only standards.
      - One languaje: Java (and many scripting languajes developed on top of Java with bindings to Java, ex. JavaScript Rhino engine), with several implementations and VMs: Sun, IBM, JRockit.
      - One library and framework : J2SE and J2EE, but with several implementations of J2SE (Sun, IBM), and J2EE (application servers).
      - One deployment environment : J2EE application servers, but with many implementations.
      - Several persistence models: JDBC, EJB-BMP-CMP, JCA, JDO, with many types of persistence datastores.
      - Several client browsers : Mozilla, Netscape, MSIE ... (Servlet/JSP specification is not coupled with a browser type, IIS is).

    What is the key?: open standards, one standard to each type of problem (persistence is the only exception).

    <quote>
    Yes , Portability is important to me, but not at the cost of usability. Most users want a snappy and responsive interface. They don't care that the exact same program can be run on 20 different platforms without making any changes.
    </quote>

    Yes *users* don't care, but sofware developers and vendors care:

       Example: development a product to Linux/UNIXes (POSIX, X-Windows) and Windows (Win32) is a duplicated cost and it doesn´t ensure it works equal. Solution: *drop* UNIX versions or use some cross-platform stuff with result of higher costs.

      Java world is breaking this: no platform related costs, freedom of vendor selection, but one framework : Java.




     
       



  98. I get the feeling I'm missing something obvious here, but I can't seem to find a way of building my project. The "Build Project" option is there, but grayed out. I need to set up libraries and build parameters, but can't find the option.

    Where's it gone? Surely I don't _have_ to use Ant?
  99. Arse..... serves me right for only downloading the binaries and not the java dev plugin :-(
  100. Nice eclipse has some problems eclipsing its functionalities:

    * It tries to check and compile everything when I try to compile one single file, means lots of waiting.

    * Tries to compile and recheck everytime I open project even when other class files are present and ok, and I am not interested in them but the one I am working on.

    * I must include all the files in project from src folder, no control over selection.
  101. Eclipse 2.0 IDE Platform Released[ Go to top ]

    Nice eclipse has some problems eclipsing its functionalities:

    * It tries to check and compile everything when I try to compile one single file, means lots of waiting.

    I never have this problem. Incremental compiles or extremely fast for me.

    * Tries to compile and recheck everytime I open project even when other class files are present and ok, and I am not interested in them but the one I am working on.

    Also, never have this problem.

    * I must include all the files in project from src folder, no control over selection.

    I don't see what the problem with this is. If you have files in a directory that is supposed to contain java source files, why shoudln't it use them? I don't see how this is a shortcoming.

    Perhaps you just don't know how to use Eclipse properly?
  102. <quote>
    I don't see what the problem with this is. If you have files in a directory that is supposed to contain java source files, why shoudln't it use them? I don't see how this is a shortcoming
    </quote>

    It is actually a huge shortcoming, and one of the few things that would make Eclipse unusable if there wasn't a workaround (see below).

    If you work on a complex software project (e.g. WebLogic Server in my case), you are most likely only interested in editing and debugging a subset of the whole codebase. It's also very likely that the build process to compile everything is complex and requires many external tools. Needless to say Eclipse utterly fails to compile WLS for these reasons, so having all the sources under its control is not an option.

    I worked around this limitation it by creating Windows soft links to only these src folders I am interested in and telling Eclipse to compile only those. For the rest, I simply set my classpath to supply the rest of the runtime. Still, it is a kludge, and I do hope the OTI guys fix this in the next release.

    --
    Cedric

  103. I guess the scope of my experience does not include projects of this magnitude, i.e. WebLogic Server.

    What would you suggest as a solution? How have other IDEs solved this? Should you be able to select which nodes of your source hierarchy Eclipse should manage.

    For example, say had the following package structure:

    foo.bar.gui
    foo.bar.model

    Say the "gui" package was thousands of classes that you are not interested in managing. You just want to develop with the "model" package. However, these both fall under the same source directory. Would you propose a feature where the user can exclude the "gui" directory. If so, how would manage dependencies on these classes. Include a JAR in the classpath that contains these classes?

    Just curious how this issue can be/has been solved.

    Ryan
  104. <quote>
    What would you suggest as a solution? How have other IDEs solved this? Should you be able to select which nodes of your source hierarchy Eclipse should manage.
    </quote>

    Yes, as simple as that. What I am doing (using soft-links to only expose a subset of my source directories to Eclipse) is a hack, but Eclipse is fine with it, as long as I supply the other classes on my classpath when I compile. Therefore, I don't see why it couldn't be supported natively in Eclipse. I met the Eclipse architect at JavaOne a few months ago and he didn't have a convincing answer either :-)

    <quote>
    Would you propose a feature where the user can exclude the "gui" directory. If so, how would manage dependencies on these classes. Include a JAR in the classpath that contains these classes?
    </quote>

    Exactly. Eclipse will of course have less information about these classes since it doesn't have the sources, but I'm okay with that, but it still has enough information to provide code completion and even breakpoints (very cool!) in classes it doesn't have the source for.

    The problem with my workaround is that my hierarchy is now no longer mapping to the source control hierarchy, so I have to check out files as an external tool (I created a p4edit external tool for that, but it's yet another hack).

    --
    Cedric


  105. One other solution to the "which bit of the code base do I want" problem is to split your source into multiple projects.

    Before you beat me with cyber-sticks, let me elaborate.. :)

    On the project I work on we have a shared code base, which all our components use. We put these in a shared component project, and we build it in specific versions.

    We have our other components in a project each as well. Each component is allowed to include the shared code on it's compile and run time path, but NOT it's peers. There's nothing to say you can't have multiple shared components though.

    The reason we do this is that we release different versions of our components on different schedules, so it was built from the ground up to be that way. We actually spent a lot of time thinking about our dependencies and how to manage releases before we wrote a single line of code. When we want to let other developers build components we just send the the shared JAR file and away they go. Those of us which care about the shared code base have it as a project in our workspaces.

    We have about 8 Eclipse projects on our project, where each project defines either shared code (only 1 of these in our world) or an application / component. We build components using a script which uses a specific version number (which is mapped to a CVS tag) for the component AND a specific version number for the build of the shared code base. Our build processes creates a file which states which version of the shared code base was used to build any of the dependant components so we know when we might have compatibility issues.

    In actuality all of this was decided nearly 20 months ago, before Eclipse was out, it just so happened that this approach meant that Eclipse fitted into our world very well indeed! The only downside is that we only see the packages in the current project in the Packages view (not package explorer, that's the tree view and that's fine.) And in any case, even if I can't see all the packages I can have files from many projects open at once so it's typically not been an issue. Now if I could set the Packages view up so that it showed packages on the build path for the project as well.... :)

    The result is that we never run into the problem Cedric mentions. But his point is still extremely valid. If you're project is pre-existing and can't be sliced up this way, or if it's plain not a way you can sensibly work (you may simply not want to) then you currently have to hack in the manner Cedric outlines.

    Chz

    Tony

    PS. I just spent 4 hours debugging a pig of a problem using Eclipse, and it made my life so much simpler than it otherwise would have been! :-)
  106. I say,
    Awt, Swing: Write Once, Run Nowhere. SWT: write once, at least run decent on major platforms.
    Sun has done a poor job with AWT and Swing which is the main reason why java never got any foor on land in the GUI and desktop market. Maybe it's up to another company now to give it a shot. Wether it's a Sun standard or not.

    Kind regards
  107. Anyone know if there is some work going on for a GUI design plugin for Eclipse?
    I haven't been able to find any information anywhere yet.

    All we need is some rather basic drawing stuff to lay out the components. We intend to do all important coding manually.
    We are currently using Visual Age for Java but of course have to leave that. It's GUI design tool works, but the system with all the lines connecting the GUI component to code and generating a lot of code automatically wasn't ever the best idea.
    Currently I believe the tool should generate only the drawing code and leave all the rest to manual implementation.

    Why we want to be able to draw the GUI graphically is of course mostly for initial design and documentation (before we write much support code) and be able to do this fast and easy.

    I am of course somewhat frightened that those who make such a tool may require that SWT is used and not support Swing, at least not properly.

    SWT looks fine, but the one significant problem with a new thing like this is whether many enough who make smart GUI component (for free or a fee) will use it. I don't want to have to create specialized GUI components only myself.
    The SWT may have most of the things we need now, but there are a lot of advanced stuff available using Swing that we might also need.
    Please don't ask what that might be. We of course do not know, and can't on principle. The idea here is of course to have a large community out there making such components and that we can use one that we find useful for some problem we might have or that simply makes us able to do things we haven't even thought about now.

    Nils Myklebust
  108. Nils,

    I'm not quite sure if this is the exact answer to your needs,
    but there is a sub-project within Eclipse to create an API for easily providing graphical editors...

    "The Graphical Editor Framework (GEF) allows developers to take an existing application model and easily create a rich graphical editor. GEF allows a developer to quickly map any existing model to a graphical editing environment."

    It is provided with 5 example plug-ins - whether these help of not, I do not know.

    http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/gef-home/overview.html?cvsroot=Tools_Project

    Also there is a GEF newsgroup that may be a good area to research potential. Look under

    http://www.eclipse.org/tools/index.html

    Hope that helps
    /david
  109. Thanks a lot David.

    Well GEF seems to be the tool required to build what I want.
    As they say:
    GEF is suitable for creating a wide variety of applications, including: flow builders, GUI builders, UML diagram editors

    of which I asked for a GUI builder for Swing programs.

    As I understand it it's also designed to be able to support things used in the Viusal Age GUI builder.

    The problem here is I can't really hold my breath until a GUI builder is available.
    Would have been nice to hear from anyone doing anything in this direction, but I'll take that on the Eclipse site.

    In the meantime it seems to me that Netbeans is the only alternative for us, at least for GUI design.

    We may look into using both however. It seems like another side of GUI building - for web based interfaces - is best supported using Tapestry and Eclipse with the Spindle plug in. At least some users are hailing it.
    We'll have to test and see what works best.

    Nils Myklebust
  110. In my opinion it's just another great free tool if you want to do some basic stuff. No need to complain about SWT leaving the mainstream - use SWT or not, it's up to you (I personally stick with Swing for reasons that have been mentioned here). Anyway, the platform has lots of cool features and a superior overall design, once one gets used to it. With more free plugins coming up one might even use it for work (I've been using WSAD - based on Eclipse 1.0 - for a while and like the way the IDE is organized, though it seems to be a bit buggy, well, could be just me).
  111. I will wait till the day I can plugin vi as my editor and use it.

    Or is it possible even now..

    anand
  112. After reading most of this thread, it sounds like a lot of the problems people have with Eclipse fall into two categories:

    1. A problem with configuring/interacting with Eclipse's core IDE environment.
    2. Eclipse doesn't do everything they want it to.

    As for the first category...Many people have complained about problems with setting up/configuring Eclipse projects, Eclipse's incremental builds, etc. For me, I have never really had a problem. Yes, AFAIK you must have a single project root. I don't see that as a bad thing. Personally, I think it makes sense to have all related files for a project (or subproject) under a common parent directory. Quite often, this just simply mirrors the version control project root. How hard is this?

    Once this is established, it is quite easy to set up multiple source roots (main, test, examples, etc). As for having one directory for the target classes - so what! Why do you care about where the classes are being compiled. If you need them seperated into different JARs or something, this can be scripted in Ant (and executed from Eclispe!)

    And if there are many projects, it is easy to set this up, too. Projects can be made dependant on other projects.

    As for Eclipse and its "lack of features". Yes, Eclipse does not have everything. It may lack some of the refactorings IDEA has (although it has all of the refactorings that I need). It does not support J2EE out of the box. It does not support VSS, StarTeam or (fill-in-the-CM-tool). Guess what! It isn't supposed to!!! It is a pluggable tools platform that can be extended just about anyway you want!

    If you look at the plugins page, there are plugings for Struts, ClearCase, StarTeam, Resin, Perforce, CVS, PCVS, TeamSite, JProbe, etc. Many more smaller plugins are out there as well, and many more are in the works.

    And as for the whole SWT vs Swing thing...Perhaps SWT does not work on every platform. BFD!!! It works on Windows, and I would imagine a vast majority of developers develop on a flavor of Windows. And from what I have heard, it runs fine on Linux as well. As somebody else said, I would rather have something that runs well on most that crappy on all. And if somebody comes up with another free IDE that is better than Eclipse and and is C++ based and only runs on Windows - sign me up! I'm not a Java bigot nor a purist - just gimme something that makes my life easier. Eclipse does that better than any free altertive I have found so far

    I tried so hard to like NetBeans/Forte, but it was just too damn slow. Eclipse blazes on my machine, does what I need, and is (IMO) pretty easy to use. What more can I ask for?

    Ryan
  113. Please correct me if I am wrong, but doesn't the use of a non-standard graphics lib (SWT) prevent easy integration of existing Swing apps?

    For example, take NetBeans: There is a stand alone Java Swing app for building scene graphs for Java3D. That stand alone program was easily made into a NetBeans plugin, because NetBeans uses AWT/Swing. I assume the only way it could be made an Eclipse plugin is by re-writing the whole program.

    See:

    http://java3d.netbeans.org/module_intro.html

    My point is that if you already have existing AWT/Swing apps, they can easily be made into a NetBeans plugin. I don't know if you can do the same with Eclipse. IBM should have worked on making Swing better, like Apple is doing. Besides, the latest version of Swing are fast, so speed is not even an issue any more (tried SwingSet on JDK 1.4.1? Feels like a native app). The only place where Eclipse may have an advantage is in load time. NetBeans takes a long time to laod. However I don't care because I usually load it once and work with it all day.

    Anyway, I'm sticking with Swing/NetBeans.

    Mike
  114. Just to say that I think the CVS integration in Eclipse is the best I have seen (and I'll readily admit that I haven't used some of the latest non-free IDEs), and that it saved my skin this week...

    Firstly, the ability to see merge conflicts before CVS tries to merge them (and makes a dirty great mess of your source file) is a boon, although setting CVS up to use a merge tool like Araxis Merge can mitigate that one.

    But the thing that has really impressed me is the structural compare on the Eclipse merge tool. Most of the time, it's not needed, but when you have several large files that have been extensively modified in each version of the files, and one set have been reformatted using a code formatter (which re-ordered the methods in the source!), then text compares just don't help...

    But the structural compare actually allowed me to compare each method with it's equivalent in the other version, regardless of it's position in the source file, allowing me to deal with a nightmarish situation accurately and quickly.

    A big thanks to the Eclipse people for that.

      /david
  115. Hi,

    I have tried to download the latest version of eclipse for Windows NT at eclipse.org, but I can't find any version for Windows NT, I just find versions for Windows XP/2000/98...etc.

    Anybody know where can I download eclipse for Windows NT, this matter is urgent! Thanks

    J.C
  116. Did you try the 2000 Version? XP and 2000 are NT technology.