Well there's even a Java standard, JSR 107 baking that kind of thing into their spec/API while dropping Enterprise level support for e.g. transactions;-|
We need at a proper way to dynamically add, modify or refresh properties at runtime. Without having to compile the code again;-) Whether a particular reference was then mutable or immutable, is less critical. There's of course always a memory penalty if you have to add or recreate objects rather than updating existing ones, but it seems that kind of waste most developers are happy to pay nowadays, especially on the EE side, probably more careful about that in the Embedded world, but I don't see most of it relevant to even SE Embedded from the recent discussion and scope;-) Werner Am 27.12.2014 12:32 schrieb "Anatole Tresch" <[email protected]>: > As I said, there was certainly demand for it. In reality I think, it is > rarely used, or even worse the consequences of config changes can be > drastic and must be well managed in all more complex cases. So I dont see > it in the API. I can imagine to take it up as an implementation thread. > Perhaps we define some kind of mix-in interface for it, that can be > implemented however useful. But that is just an idea. Also the current code > (aka "dormant", but I will still maintain it and adapt it along the > discussion we have, regardless what Mark thinks on it) has nothing of it in > its API module. > > 2014-12-27 11:29 GMT+01:00 Romain Manni-Bucau <[email protected]>: > > > I guess i am the one having spoken of it so let me make it more explicit > if > > needed. I want it for all the reason you mentionned but I never wanted > it > > in our API. I would have liked it in our APIs. We can...should...split > > write and read API. It also mdans it can wait read paft is clear and > done. > > Le 27 déc. 2014 11:22, "Mark Struberg" <[email protected]> a écrit : > > > > > Hi! > > > > > > Do we need a writable PropertySource in our API? > > > > > > I don't think we do. But let me explain the _why_! > > > > > > > > > I DO understand that administrators and ops lords&ladies need a way to > > > sometimes change certain configuration at runtime. They might even be > > > interested in a graphical UI! > > > > > > But still we don't need that in our API. It would be really easy for > each > > > Container (or even as own jar) to add a new PropertySource with a very > > high > > > ordinal (basically overriding default values). And this > > > MutablePropertySourceImpl could e.g. store the configured values in the > > > database etc. > > > > > > > > > The effect would be that admins could easily tweak those values (and > even > > > make them persistent). And all that without us having to take care of > it. > > > > > > > > > The question is now whether we write this into the spec or let > container > > > vendors deal with it? > > > > > > > > > LieGrue, > > > strub > > > > > > > > > -- > *Anatole Tresch* > Java Engineer & Architect, JSR Spec Lead > Glärnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > <http://javaremarkables.blogspot.ch/>* > > *Google: atsticksMobile +41-76 344 62 79* >
