By the way, I did want to highlight -- this isn't serialization functionality. It is just a wrapper around Preferences that delegates commands to it. Any de/serialization logic is all user provided.
My proposal serves no other purpose than making Preferences safer to use. I keep running into the same bugs when using Preferences, and I keep on making/using the same tool to solve that bug. I imagine others are too, which is why adding this to the STD LIB makes sense to me. On Wed, Nov 4, 2026, 7:54 AM David Alayachew <[email protected]> wrote: > 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 >> >> >>
