Thanks for the response Brent. Yes, this is absolutely something I can make myself. In fact I do, many times over. It is because I use it so many times that I thought it might be useful to add to the JDK.
Preferences are extremely useful for making GUI's, to the point where every ui I have made since has at least a few. All I want to do is smooth out the pathway to using them by adding one single interface and an instance method with <=5 lines of implementation code. And ultimately, I am not trying to add functionality as much as add an interface that developers can use as a defined pathway to de/serialize preferences. The implemention should only ever be provided by the developer. Here is the exact change I would want to make. 1. An interface with 2 unimplemented methods. 2. Add a transform method to Preferences that takes in 2 j.u.f.Function instances, and creates an anonymous class of that interface. I think that that is a really cheap cost in exchange for making code safer to write and prevent bugs. By all means, if you still don't think it would be very useful, I won't push it. All I am saying is that the implementation cost is so small that I think it is worth it to prevent bugs like the ones I described in my original post. On Tue, Nov 3, 2026, 8:19 PM Brent Christian <[email protected]> wrote: > Hi, David > > Thank you for bringing this suggestion to core-libs-dev. > > However, I think adding separate serialization functionality just for use > by java.prefs would be too > limited a use-case. I don't anticipate this feature seeing sufficient use > to merit its addition to > the platform. > > But as far as I can tell, it should be possible to create such > functionality on one's own. > > Thanks, > -Brent > > On 10/22/26 10:22 AM, David Alayachew wrote: > > Hello @core-libs-dev <[email protected]>, > > > > *(For minor enhancement suggestions like this, should I make an entry on > > JBS, or should I talk about it here? Both? Neither? Please let me know.)* > > > > I first discovered the java.prefs module a while ago, and it has been > > great. It fits that perfect middle ground between a full serialization > > framework and just writing stuff to a file. Ideal for things like user > > settings for desktop applications. > > > > However, the second I need to store anything other than the common > > primitive data types is when things get slightly annoying. I keep finding > > myself creating some sort of wrapper around Preferences to just give > myself > > a way to "serialize" or "deserialize" data. > > > > For example, a common thing I want to do is store the user's last used > > location. Easy enough, I just store the java.nio.file.Path via > toString(). > > > > Oh wait, I need to use Path.toAbsolutePath(). Now, I need to go find all > > the places in my code that update it and change them. > > > > It would be nice if there was a simple class added to java.prefs -- let's > > call it PreferencesTransformer<T>. It would be constructed from a > > Preferences object and a key, serving as both a serializer and > deserializer. > > > > We'd need an unimplemented public String serialize(T object) and public T > > deserialize(String serializedTextFormOfObject). > > > > This would be especially nice because it is entirely opt-in -- the > > Preferences class doesn't have to change at all. Maybe add a public <T> > > PreferencesTransformer<T> transformer(String key, Function<String, T> > > deserializer, Function<T, String> serializer) method, just for > convenience > > sake. But otherwise, unchanged. > > > > I think this is a clean enhancement that makes code safer and easier. > > Please let me know if this makes good sense to you all. > > > > Thank you for your time and consideration. > > David Alayachew > > >
