I've been very lucky job wise; I've survived the job slump in the Boston, MA, USA area unscathed.
But I've kept my ears open.
There was a good "Connection" (PBS radio talk show) discussing this; the expert basically came out against spamming.
Better to send one or two resumes, custom tailored to the specific opportunity, that will stand out.
In other words, do the research on the employer and opportunity and juggle your resume to jump out at them.
Of course, I've changed jobs only twice in eleven years so YMMV.
And Together is basing their next implementation on Eclipse. Check out the Eclipse Webcast (a link is available on the eclipse site). They also know a good thing when they see it.
You found the hard way to do something simple. Mostly you add to the classpath for a project from the Project's Properties pane, Java Build Path -> Libraries.
You can add Jars from within the project (i.e., for things that include Jars as part of the distribution), or Jars from arbitrary locations on your hard drive.
Or neater yet (if you develop in a team environment), you can add relative to a classpath variable. That's what you hit. It's similar to Makefile variables... you say (for example), that you need to add JBOSS_DIR/lib/ejb.jar to your classpath, and set JBOSS_DIR to c:/Jboss2.4.3.
Meanwhile, another team member syncs up and gets your classpath definitions, but (being on Unix), sets JBOSS_DIR to/usr/lib/jboss/2.4.3 (or whatever).
Notice, you can keep even a complex classpath configured in Eclipse, and shared via CVS even across platforms. Handy.
I've now been using and proselytizing Eclipse for several months. A "quick" view of it, even a couple of days, does no more to reveal its strength and depth than a similar spin of Emacs. Eclipse is rich in detail.
The technology is very well thought out. What seperates it from things like NetBeans is that plugsins are beyond first-class objects: they are the only type of object.
Let me explain. Everything in Eclipse is a plugin. Plugins publish (as XML) things called "extension points" that other plugins hook into. All that XML is processed at bootup time, and it allows the basic Eclipse engine to do a lot without loading much Java code. Plugins declare new menu items, tool bars, editors, actions, whatever but no Java code is loaded until the user actively selects on of those new options.
I'm personally looking forward to writing some plugsin related to by own open source project, Tapestry.
I've also been very impressed by their very open process. They have an open Bugzilla and very quick response times to bugs and issues. Several suggestions I've made have already made it into the project, and they don't know me from Adam. Eclipse is not perfect, but they are very keen on improving the rough edges.
The interface is very clean and configurable, it really molds to how you, the user, want to run things. All those draggable views and all.
There's already a C/C++ plugin. I'd love to see a Python plugin (perhaps using Jython?). There's a huge amount of functionality that hasn't been documented yet (do I smell an O'Reilly book?).
I find it to be about has fast as Netbeans on my work machine (PIII 1ghz, 512MB) and a lot easier and more intuitive to use and configure. The UI is snappier (and prettier), and its loaded with features. It's like Emacs, you keep discoverring new things it does.
The ability to build new tools that plug into Eclipse... possibly completely unrelated to software development... and the use of the fast, clean SWT instead of big bad Swing is a selling point for this Java developer.
Sounds like you're still in school; if you really don't like CS, find something else.
But if you think you are destined for CS cheer up... you need years of experience to truly get it, no matter what flashy little applets you're putting together today. When it does click, a whole new world opens up.
The superb UI is only part of the story for Eclipse. The level of intergration of all the parts is excellent. What's just as impressive is the indexing system that "knows" about your code; this support awesome refactoring.
For example, rename a method and Eclipse will find every invocation of that method and update the code.
It also has "extract method", "build accessor" and variations on move and rename for methods and classes.
I've been using Eclipse for a couple of weeks now, and the more I use it, the more I like about it. You can be effective in it quickly, but as you learn more about it, you can continue to customize it to fit your needs. Cool as cool gets.
I feel sorry for other IDE developers, they are about to get blown off the map.
IBM's alphaWorks now has a
C/C++ plugin for Eclipse. I haven't used it, but it sounds cool... a pure Java C/C++ parser (used to maintain indexes and such), and the ability to call out to a native compiler.
I've been using Eclipse for a couple of weeks now and it is the most impressive IDE I've used on any platform, for any language.
What's especially exciting (beyond the pending open source release) is that it is designed, from the ground up, to support plugins. In fact, the comparison I make is not to JBuilder or VisualAge, but to Emacs. Small, central kernel; lots of hooks for plugging in new features, major functionality is itself plugins... the whole works.
Eclipse is the IDE I've been waiting for, but I can see it eventually taking the form of "the developer's desktop" with plugins completely unrelated to Java, or even code, development.
I've been very lucky job wise; I've survived the job slump in the Boston, MA, USA area unscathed. But I've kept my ears open. There was a good "Connection" (PBS radio talk show) discussing this; the expert basically came out against spamming. Better to send one or two resumes, custom tailored to the specific opportunity, that will stand out. In other words, do the research on the employer and opportunity and juggle your resume to jump out at them. Of course, I've changed jobs only twice in eleven years so YMMV.
And Together is basing their next implementation on Eclipse. Check out the Eclipse Webcast (a link is available on the eclipse site). They also know a good thing when they see it.
You found the hard way to do something simple. Mostly you add to the classpath for a project from the Project's Properties pane, Java Build Path -> Libraries.
... you say (for example), that you need to add JBOSS_DIR/lib/ejb.jar to your classpath, and set JBOSS_DIR to c:/Jboss2.4.3.
/usr/lib/jboss/2.4.3 (or whatever).
You can add Jars from within the project (i.e., for things that include Jars as part of the distribution), or Jars from arbitrary locations on your hard drive.
Or neater yet (if you develop in a team environment), you can add relative to a classpath variable. That's what you hit. It's similar to Makefile variables
Meanwhile, another team member syncs up and gets your classpath definitions, but (being on Unix), sets JBOSS_DIR to
Notice, you can keep even a complex classpath configured in Eclipse, and shared via CVS even across platforms. Handy.
The technology is very well thought out. What seperates it from things like NetBeans is that plugsins are beyond first-class objects: they are the only type of object.
Let me explain. Everything in Eclipse is a plugin. Plugins publish (as XML) things called "extension points" that other plugins hook into. All that XML is processed at bootup time, and it allows the basic Eclipse engine to do a lot without loading much Java code. Plugins declare new menu items, tool bars, editors, actions, whatever but no Java code is loaded until the user actively selects on of those new options.
I'm personally looking forward to writing some plugsin related to by own open source project, Tapestry.
I've also been very impressed by their very open process. They have an open Bugzilla and very quick response times to bugs and issues. Several suggestions I've made have already made it into the project, and they don't know me from Adam. Eclipse is not perfect, but they are very keen on improving the rough edges.
The interface is very clean and configurable, it really molds to how you, the user, want to run things. All those draggable views and all.
There's already a C/C++ plugin. I'd love to see a Python plugin (perhaps using Jython?). There's a huge amount of functionality that hasn't been documented yet (do I smell an O'Reilly book?).
I find it to be about has fast as Netbeans on my work machine (PIII 1ghz, 512MB) and a lot easier and more intuitive to use and configure. The UI is snappier (and prettier), and its loaded with features. It's like Emacs, you keep discoverring new things it does.
Was my favorite, before Eclipse showed up. Still has some great features that should be incorporated into Eclipse.
The ability to build new tools that plug into Eclipse ... possibly completely unrelated to software development ... and the use of the fast, clean SWT instead of big bad Swing is a selling point for this Java developer.
But if you think you are destined for CS cheer up ... you need years of experience to truly get it, no matter what flashy little applets you're putting together today. When it does click, a whole new world opens up.
I've been using Eclipse for a couple of weeks now, and the more I use it, the more I like about it. You can be effective in it quickly, but as you learn more about it, you can continue to customize it to fit your needs. Cool as cool gets.
I feel sorry for other IDE developers, they are about to get blown off the map.
IBM's alphaWorks now has a C/C++ plugin for Eclipse. I haven't used it, but it sounds cool ... a pure Java C/C++ parser (used to maintain indexes and such), and the ability to call out to a native compiler.
I've been using Eclipse for a couple of weeks now and it is the most impressive IDE I've used on any platform, for any language. What's especially exciting (beyond the pending open source release) is that it is designed, from the ground up, to support plugins. In fact, the comparison I make is not to JBuilder or VisualAge, but to Emacs. Small, central kernel; lots of hooks for plugging in new features, major functionality is itself plugins ... the whole works.
Eclipse is the IDE I've been waiting for, but I can see it eventually taking the form of "the developer's desktop" with plugins completely unrelated to Java, or even code, development.
I'm looking forward to testing and comparing Qt/PyQT vs. WxWindows/WxPython.
However, Qt/PyQT includes a visual form designer and complete GUI. WxPython has Boa, but it is incomplete and buggy (though impressive none the less).
We'll see if either of them is really complete, though.