"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:Any comments?
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Stevens Miller wrote:Any comments?
Yes: your lines are far too long.![]()
I've broken them up as best I can.
I'm afraid I'm no expert on XMLEncoder (and I'll have to read Item 78 of EJ again), but if I see anything (else) that leaps out at me, I'll post further.
"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:Dang it, Winston! I paid a lot of money for this widescreen monitor. What good is it to me if you keep cramming everything into the left-hand side?
I am trying to devise a clean and easy-to-use scheme to record selected persistent fields of my object...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:Unless "selected" is by some characteristic (eg public), surely you need some way of "telling" the persisting class which fields you actually want to save.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:One thing I'm having a bit of trouble working out is why reflection would help in this case...
Unless "selected" is by some characteristic (eg public), surely you need some way of "telling" the persisting class which fields you actually want to save. In that case, the proxy pattern would seem to be ideal, since you simply define them in your proxy class. Obviously this means that you have to keep your proxy up to date if you ever add any new ones...
TBH:
(a) If you plan on doing that a lot, any serialization system is likely to struggle.
(b) Surely you'd still need to update something to say that the new field is "persistent".
Like I say, this isn't really my area of expertise, but I'm not quite sure what these other patterns give you over the proxy one (which also has the advantage of being a published, tested technique).
"Il y a peu de choses qui me soient impossibles..."
Winston Gutkowski wrote:
Winston Gutkowski wrote:Unless "selected" is by some characteristic (eg public), surely you need some way of "telling" the persisting class which fields you actually want to save.
Ah. One thought occurred to me: Could you use an annotation? (eg, @Persist). That might give you the best of both worlds (I say 'might' because I've never tried it) - a generic way of indicating that a field needs to be saved that can be handled reflectively.
"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:That seems like a very appealing idea (though I know little about annotations). The problem that doesn't solve, however, is that of getters/setters that match the JavaBeans spec. XMLEncoder will encode those (even if they don't actually get/set a field in your object).
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
So you can have pretty pictures, movies, e-mail etc. on the right half? Or even the API documentation?Stevens Miller wrote:Dang it, Winston! I paid a lot of money for this widescreen monitor. What good is it to me if you keep cramming everything into the left-hand side?
Campbell Ritchie wrote:
So you can have pretty pictures, movies, e-mail etc. on the right half? Or even the API documentation?Stevens Miller wrote:Dang it, Winston! I paid a lot of money for this widescreen monitor. What good is it to me if you keep cramming everything into the left-hand side?
Or so you can turn it and read 387458734685376 lines simultaneously?
"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:That stuff all goes on the right-hand monitor, not the right-hand half of the left-hand monitor.
![]()
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:OK, I've had a night to sleep on this and, as I see it, your problem is this:
1. You want a simple, generic (two adjectives that rarely correlate in programming) mechanism for persisting a Java object to XML.
2. XMLEncoder is really simple to use, but essentially requires the persisted object to be a bean.
3. You don't want to implement the bean specification just to make an object "persistable" (at least, certainly not as part of its public API).
The first thing that occurred to me is that this kind of problem (the need to persist non-bean objects) must have already come up. Indeed, JPA arose for precisely this purpose; it's just not specifically geared for XML output.
The second thing I thought was: when it comes to something as fundamental (and fiddly, and potentially "crackable") as serialization, I certainly wouldn't want to "roll my own".
A bit of Googling found me this Stackoveflow thread
which links to XStream, which looks like it might well do what you want.
Alternatively, the tutorials seem to suggest that you can customise XMLEncoder to do this kind of thing.
And yet another possibility is JAXB.
Like I say: it's not something I've ever tried, and I suspect you'll need to read a fair bit to work out which solution is closest to your needs; but my basic advice would be this:
Unless you're willing to spend the time to become a real expert on this stuff, don't roll your own, because there are just too many things that (as a non-expert) you could get wrong.
"Il y a peu de choses qui me soient impossibles..."
Winston Gutkowski wrote:
Stevens Miller wrote:That stuff all goes on the right-hand monitor, not the right-hand half of the left-hand monitor.
![]()
Bloody lawyers. Get all their toys by charging us poor jobbing programmers 200 bucks an hour.....
I'm sure you've heard it before: What's the difference between a lawyer and a catfish?
One's a scum-sucking bottom-feeder, and the other one's a fish.
Winston
"Il y a peu de choses qui me soient impossibles..."
Winston Gutkowski wrote:No offence meant of course...
![]()
"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:
And yet another possibility is JAXB.
Jesper pointed me to that a short while ago. Yeesh! Too much learning curve for me to handle...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Stevens Miller wrote:Hey! I just noticed I got a third cow! Who gave me a third cow? (And thanks!)
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Stevens Miller wrote:
And yet another possibility is JAXB.
Jesper pointed me to that a short while ago. Yeesh! Too much learning curve for me to handle...
I hate to say Stevens (or is it Miller? (Japanese style))
but most of what I hear from your last post are the things that you don't want to do to solve your problem - you don't trust 3rd party software; you don't fancy customizing XMLEncoder; and you really don't like the learning curve of JAXB - and it's not a great platform to start from.
Well, let me tell you: after a lifetime in programming and database design and administration - it AIN'T [simple]
Yes, the basic business of saving an object is reasonably straightforward (but probably not as simple as you think); but retrieving and re-instantiating are hellishly more complex - especially when this is usually the place when you also have to guard against potential "cracking" attacks.
I fear I've come to the limits of what I can advise; but I wish you luck, and I applaud your enterprise.
And if you do come up with a "better mousetrap", do tell.![]()
"Il y a peu de choses qui me soient impossibles..."
Winston Gutkowski wrote:
Stevens Miller wrote:Hey! I just noticed I got a third cow! Who gave me a third cow? (And thanks!)
Campbell. Send him a candy-cane by purple-post.
I notice he hasn't bothered to give me one though (probably because I still detest Scanners).
A parting shot before I get back to the Wimbledon final:
What the difference between a dead dog in the road, and a dead lawyer in the road?
Skidmarks in front of the dog.
"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:
Yes, the basic business of saving an object is reasonably straightforward (but probably not as simple as you think); but retrieving and re-instantiating are hellishly more complex - especially when this is usually the place when you also have to guard against potential "cracking" attacks.
I fear I've come to the limits of what I can advise; but I wish you luck, and I applaud your enterprise.
And if you do come up with a "better mousetrap", do tell.![]()
As always, your help is much appreciated. My mousetraps work pretty well, but they tend to be limited in application to mice of very specific varieties. They may not be better than other traps for other mice, but they are often the best for me and my own vermin.
Stevens Miller wrote:After a lifetime in programming myself, I do still find that relying on my own code works better for me than trying to learn a lot of libraries. Those that are mature must be approached with respect. That means (despite what their sales forces might say), expecting them to take more than a few minutes to master. Unfortunately, my experience has been than most tend not to solve my problems any more easily than if I had simply hunkered down and written something suited to my needs on my own.
One reason I do that is that I am flying solo here. In a larger setting, there might be a programmer working with me whose job was to be the XStream guru. Another might be the JPA DBA, and so on...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Stevens Miller wrote:After a lifetime in programming myself, I do still find that relying on my own code works better for me than trying to learn a lot of libraries. Those that are mature must be approached with respect. That means (despite what their sales forces might say), expecting them to take more than a few minutes to master. Unfortunately, my experience has been than most tend not to solve my problems any more easily than if I had simply hunkered down and written something suited to my needs on my own.
Which is why I suggested XStream, which (AFAICG) is an open-source solution.
One reason I do that is that I am flying solo here. In a larger setting, there might be a programmer working with me whose job was to be the XStream guru. Another might be the JPA DBA, and so on...
Since I've worked in both environments, the one thing I'll say for the "corporate" system is that you live in an environment where people are allowed to tell you that your code (or approach) is crap - or indeed, wrong - and because it can happen every day, it breeds humility.
If you don't have that, you can get into an insular, "I know best" mentality, since you're the only arbiter of your code. But what if you fall under a bus? Is your company (or your code) ready for someone else to take over?
PS: And on a similar subject, you might be interested in this article.
"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:Oh, please. You are more expert at Java than I am, but, if you are going to cross swords with me over lawyer-jokes, you are going to have to do better than that...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
"Il y a peu de choses qui me soient impossibles..."
It sure was nice of your sister to lend us her car. Let's show our appreciation by sharing this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|