NoClassDefFoundError not listing missing class

I have been working on a game for over ten years. It is written in Java 8. It runs fine using up to Java 16. I recently built a new computer, and on this new one, I cannot compile and run the game in Eclipse using any version of Java I have tried – 8, 11 and 16 so far. The error message I get is as follows.

The problem I have is, “oscg/model” is a package, not a class! So when the exceptions say Java cannot find/load “oscg/model” or “oscg.model” I have no idea where to look to fix the problem.

Anyone seen this before? Any idea how to fix it?

Exception in thread "main" java.lang.NoClassDefFoundError: oscg/model
    at oscg.oscg.setupMainComponents(
    at oscg.oscg.<init>(
    at oscg.oscg.main(
Caused by: java.lang.ClassNotFoundException: oscg.model
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(
    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(
    at java.base/java.lang.ClassLoader.loadClass(
    ... 3 more


This is a bit of a stab in the dark, but given the nature of this question, I think that’s what you’re looking for.

Did you switch to linux or some other unix-like OS from mac or windows, perhaps?

Because this sounds like a casing issue. As a comment already observed, there’s wonky (bad code style) stuff going on, a class should never be named oscg, it should be Oscg, which makes this more likely. If you have this file:

package a.b;

public class Foo {}

and compile it, you get a/b/Foo.class. If you then change the casing on this to e.g. A/b/fOO.class or even a/b/Foo.CLASS, then you get the intriguing property that:

  • On filesystems that are case insensitive (all relevant windows filesystems, most ways including the default way you can configure all relevant mac filesystems, but not the default behaviour on most unixy/linuxy file systems), that doesn’t matter and all continues to work fine.
  • On case sensitive filesystems, you would get that exact error.

If it’s not this, doublecheck for non-ascii characters in your class names; something like public class ThísIßABådIdea {} can work, but not if there’s a discrepancy in charsets somewhere along the line, which is particularly likely when you switch underlying OS or even just computers.


From the stack trace it is rather clear that you have a package named oscg and inside that a class also named oscg. This is an extremely bad idea as it leads to confusion. Given that you do not understand how a class is being confused with a package here, we have ample proof that this confusion happened to you, thus proving that you shouldn’t be doing this. ClassesStartWithACapital and packagesDoNot.

For example, do you have a nested class named class model {} inside class oscg? Various build tools and compilers might get confused. This is somewhat unlikely, but possible: The java spec says this should not happen, but this confusion essentially can only occur if you break a convention 95%+ of all java coders hold to. Ordinarily you won’t run into a compiler / build tool bug given that java is so popular, but if you go out of your way to do things that almost nobody else in the java community does, the odds you are ‘the first’ to run into a bug like this goes up exponentially.

Yet another reason not to do this.