Member Avatar for leiger

Basically I've got a text editor which revolves around a jTextArea. There are some settings (e.g. whether line wrap is enabled) that I'd like to save to a file when the application closes, and then load up again when it runs next.

I've spent a few hours trying to get it to work by saving to a plain text file and failed, then tried using a serialisable class (which probably isn't even meant to work that way) - and have eventually given up on getting it working without help :)

There are two main questions I have:

1. How should I implement the whole process of saving the settings before I quit, and loading them up again when the program starts up next? Is a plain text file the best solution?

The main problem I had earlier with this was with retrieving the information. I was able to save the settings to the file properly, but kept getting NullReferenceErrors when trying to read values back in. I worked out that the file was being found successfully and opened, but the data was being read in as 'null' for some reason.

2. What is the best way to let the user modify these settings?

I've been trying to implement it using a modal JDialog. Is that the best way, or would you suggest something else?

--
Keep in mind that I'm doing this to teach myself the language. So please don't just give me answers :) I'd rather just be pointed in the right direction if possible.

Cheers,
leiger

  • 2 Contributors
  • 2 Replies
  • 217 Views
  • 7 Hours Discussion Span
  • Latest Post Latest Post by leiger

Dani AI

Generated

Short answer: use a small, well-defined settings model + a simple on-disk format (Preferences or a properties/JSON file) and a modal dialog that edits that model. That keeps UI, persistence and the editor decoupled so you can load defaults on startup, apply changes in one place, and save atomically on exit.

I agree with that the Preferences API is convenient for tiny key/value pairs; it’s fine if you want platform-backed storage and don’t need a human-editable file. As you discovered, , Preferences won’t hold a File object directly — store the file path as a string and reconstruct the File on load.

If you prefer an editable config file, use java.util.Properties or JSON. Example (Properties, Java 7+):

Path cfg = Paths.get(System.getProperty("user.home"), ".myeditor", "settings.properties");
Files.createDirectories(cfg.getParent());
Properties p = new Properties();

// save
p.setProperty("lineWrap", Boolean.toString(settings.isLineWrap()));
try (OutputStream out = Files.newOutputStream(cfg)) { p.store(out, "myEditor settings"); }

// load
try (InputStream in = Files.newInputStream(cfg)) { p.load(in);
settings.setLineWrap(Boolean.parseBoolean(p.getProperty("lineWrap", "false"))); }

Troubleshooting the “read returns null” problem: confirm the file exists and isn’t empty, print/log exceptions instead of swallowing them, ensure you’re reading the same path the writer created (watch working directory), and use safe I/O (try-with-resources). If you used Java serialization, beware of class-version issues and prefer simple formats for settings.

UI notes: a modal JDialog is simplest for a settings dialog. Keep a Settings POJO and let the dialog edit a copy—apply changes on OK, cancel without side effects, and persist on successful close. For robustness, write to a temp file and move/replace the real file to avoid corruption on crashes.

Recommended Answers

All 2 Replies

Member Avatar for JamesCherrill

Java has a Preferences class that's ideal for what you need. It's as easy as

Preferences prefs = Preferences.userRoot().node("myEditor");
prefs.putBoolean("lineWrap", true);
...
if (prefs.getBoolean("lineWrap", false)) ...

UI should be a dialog, and keeping it modal makes coding, and using, it easier.

Member Avatar for leiger

Thanks! If that supports objects as well as primitive data types it'll be perfect... though I could always work around that. Am looking up the API on it now.

--

And it doesn't seem to support objects (in particular I wanted to store a File object) - but storing the filepath as a string will probably be enough.

Thanks again! :)

Edited by leiger because: n/a
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.