为何getClass().getResource与RandomAccessFile/ReversedLinesFileReader存在兼容问题？

Hey there, let's work through your issue and clear up why those steps are necessary.

First: Why You're Getting FileNotFoundException #

Even though the file exists in /bin/lottery_archives/drawArchive_5x36.txt, there are a few common pitfalls causing this error:

• Incorrect path handling with File class
  A lot of folks make the mistake of using new File("lottery_archives/drawArchive_5x36.txt"). The problem here is that Eclipse runs your program with the project root directory as the working directory, not the /bin folder. So the File class looks for the file in your project root, not the compiled output folder.

  The fix? Use the classloader to access resources from the classpath (which maps to /bin):

  // For non-static methods
  InputStream fileStream = getClass().getResourceAsStream("/lottery_archives/drawArchive_5x36.txt");
  
  // For static methods
  InputStream fileStream = YourClassName.class.getResourceAsStream("/lottery_archives/drawArchive_5x36.txt");
  

  The leading / points to the root of the classpath, so it'll correctly find the file in /bin.

• Case sensitivity mismatches
  Windows ignores filename case, but if you ever deploy to Linux/Unix (or have strict Eclipse configs), a mismatch like drawarchive_5x36.txt vs drawArchive_5x36.txt will break things. Double-check that your code's filename matches the actual file exactly.

• Build path exclusions or custom build scripts
  Even if you marked resources as a source folder, check if Eclipse is excluding the file: Right-click your project → Properties → Java Build Path → Source tab. Look at the Excluded list for the resources folder—if there's a rule targeting your .txt file, that's the issue. Also, if you're using Ant/Maven/Gradle alongside Eclipse, those tools might override Eclipse's default resource copying behavior.

• Classloader context issues
  If this is a web app or uses custom classloaders, the default classloader might not point to /bin. Try using the context classloader instead:

  InputStream fileStream = Thread.currentThread().getContextClassLoader()
      .getResourceAsStream("/lottery_archives/drawArchive_5x36.txt");
  

Second: Why Those "Fussy" Steps Matter #

It might feel tedious, but these steps are there to keep your project reliable:

• Separate code and resources
  Putting resources in a dedicated folder keeps your project organized. You don't want to hunt through Java packages for .txt files, and it makes it easier to manage configs, static data, etc., as your project grows.

• Cross-environment compatibility
  When you package your project into a JAR/WAR, Eclipse (or build tools) automatically bundles resources from the resources folder into the correct location. If you kept files in the project root, they'd likely get left out of the package, breaking your app when deployed.

• Avoid hardcoded paths
  Using classloader resources means your code doesn't depend on absolute paths (like C:\my-project\...). This works whether you're running in Eclipse, on a server, or on another developer's machine—no path edits needed.

• Fix build inconsistencies
  "Clean Project" wipes the old /bin folder, removing cached or corrupted files that might have been left behind from previous builds. Re-building ensures your latest resources are copied correctly, avoiding weird bugs from stale files.

内容的提问来源于stack exchange，提问作者Code Complete