NetBeans sets up projects by menu choice according to the Sun Java Blueprints
standard or the Apache Tomcat standard.  Eclipse likewise follows the standard
layouts for various types of Java projects.  Other than the defaults for the
names of certain non-deployed directories, which are easily changed in the
options, the two create the same directory structures.

The IDE-specific directories, such as "nbproject/" for NetBeans, aren't even
portable within their own IDE, I've found.  So much of the specific workspace
is bound up in them.  Likewise with the "workspace/" directories in Eclipse.
Oh, the project files transfer, but somehow you just never can change the
build or packaging.  OTOH, when you create a new IDE-specific project tree for
each workspace, NB or Eclipse, then you can filter that out when you transfer
the project around.  Ant is your friend, and it don't need your stinkin'
project dirs.  That's how you get true portability.

Mind you, NB uses Ant for its project management files, so it really is
portable.  Uhh, except that their Ant files are structured the way they like,
and pull in all this stuff you might not necessarily need for your production
builds, say.  So even though Ant uses your build files portably, your build
files might not be portable.  So, you leave the IDE project files out, too,
even build.xml, and use your own build.xml for test and production builds, and
you do not transfer the IDE build.xml between workspaces.

I have never had trouble accessing the Java source directory, always distinct
from deployment directories, disk-specific project information, doc
directories and other source trees such as SQL, for the same project equally
well from NetBeans and Eclipse.  It's always a separate directory, and both
products read it just fine, without any strain on my part.

They also keep their build and deployment directories separate.

The fault, dear Brutus, lies not in our IDEs, but in ourselves.

"Finally"?  Redhat was the only distro with a functional java package
(rather than the binary installer) for a long time.  Sun and Redhat
have been playing nicey-nice with each other for ages, relative to the
linux community at large. :)

*dons asbestos undergarments*

People who voluntarily store critical parts of their source (like GUI
layouts) in such a way that only one tool can possibly build it are
creating their own problem, regardless of language.

*removes asbestos undergarments*

For myself, I've solved both of these issues with Apache Maven, which
is capable of generating projects for several IDEs from a common
codebase and project file.  The process for getting a working eclipse
environment for the projects I'm working on right now is:
1. check out.
2. mvn eclipse:eclipse
3. Eclipse/Import/Existing Projects

I found plugins for IDEA and Netbeans project generation, too.

Rather than impose a specific standard source layout on every single
tool[0], we should probably demand simpler, better-documented formats
for project metadata and clearer conceptual mappings between tool-
specific concepts (like Netbeans' "modules") and standard concepts
(like "JAR").

[0] I expect to be burned at the stake by other maven users for
uttering that sentence.  :)