Eclipse's Classpath File is Retarded

This is a somewhat obscure point, but it's absolutely retarded if you want to share Eclipse projects and not workspaces.

The classpath in Java is the path used to determine where Java libraries are located. It's used to find the code to run. Without it, the Java program can't find its libraries and therefore can't run.

In any case, Eclipse splits itself into a workspace which contains projects. Projects are generally self-contained copies of code, which may rely on various libraries. Eclipse therefore needs a way to specify the classpath of a specific project. It does that in a .classpath file.

As an example, take the following directory structure:

└ Eclipse Workspace
  └ Project
    └ Library
      ├ Library.jar
      └ Library.dll

In this structure, we have a Java library (the .JAR file), and a native library (the .DLL file).

So we need to specify two data points: first, where the Java library is, and secondly, where the native library is.

Here's what it looks like in Eclipse's .classpath file:

<classpathentry kind="lib" path="Library/Library.jar">

Catch that? We're doing two different things here. For the JAR file, we specify the path to the JAR file relative to the project, while for the native library we specify the path of its containing folder relative to the workspace.

Put more simply, you wind up with an entry that looks something like this:

JAR: Library/Library.jar
Native Code: Project/Library

The two path are relative of two different locations!

This is, first of all, confusing. But secondly, it's absolutely retarded.

Say I want to send someone else a project. I zip everything up and send them the project.

They then import the project into Eclipse. Since the JAR libraries are specified by project-relative paths, it'll even load and build correctly. Everything will seem to work!

But when they try and run it, unless they named the imported project the exact same name I did, it won't actually run.





If you zipped everything up, that included the .project file. That file explicitly says what the project is to be named.

It's the default name - but nothing prevents the user importing the file from naming it something else.

Plus I'm not sure what happens if you import the project and don't copy it into your workspace, which for me at least, is far more likely to happen for a variety of reasons.