Make IPath serializable #1100
Make IPath serializable #1100
Conversation
|
I think this is maybe a poor idea. Making something serializable does lead to the assumption that you can serialize and deserialize it anywhere. So while java.net.URI is Serializable, java.nio.file.Path is not. I can see that it might be convenient in some use cases, I think it's potentially misleading. We should solicit more opinions on the matter. |
What will work ... but of course a file path (what can be an URI) might not exist.
I think this is more because you cannot restore a (generic) path without the provider but |
laeubi
force-pushed
the
make_serializable
branch
from
04e44e9 to
3726701
Compare
|
I'm now using |
|
I suppose, that seems better. But when working on Sundays it's still a good idea to give other "normal" committers (who don't work on Sundays) an opportunity to express any concerns they might have. 😕 |
|
This is nothing urgent ... but seems to remove the need for workarounds in some places and does not hurt from my perspective. |
HannesWell
left a comment
HannesWell
left a comment
There was a problem hiding this comment.
java.nio.file.Path is not.
I think this is more because you cannot restore a (generic) path without the provider but
IPathitself has no different providers.
That's one reasons and another reason might be that internally Path is also a wrapper around a String using the Platform's native path element separator, which is different on Unix (/) and Windows (\).
But in general I don't see general problems in making IPath serializable as a file with specific a Path can be removed or altered at any point in time (e.g. by another program). So that it might not exist at de-serialization is something that definitively has to be considered.
| return new PortablePath(toPortableString()); | ||
| } | ||
|
|
||
| static final class PortablePath implements Serializable { |
There was a problem hiding this comment.
Can't we use a simple record here? And if not, can't a regular serialVersionUID be used?
There was a problem hiding this comment.
Why is a record simpler?
And what is a "regular" serialVersionUID or more why is one not a regular one?
There was a problem hiding this comment.
Why is a record simpler?
Well, the usual: Less boiler-plate.
But thinking about it a second time, using Externalizable could be even simpler and would require no magic methods
https://www.baeldung.com/java-externalizable
And what is a "regular" serialVersionUID or more why is one not a regular one?
One is the default ID and should only be used with custom serialization logic and I think this 'inner value holder' uses the 'generated' serialization mechanism and therefore should have a generated non-default ID:
But that's also obsolete if Externalizable is used.
There was a problem hiding this comment.
But thinking about it a second time, using Externalizable could be even simpler and would require no magic methods
Externalizable does not work here as we have all fields final in the class (on purpose).
One is the default ID and should only be used with custom serialization logic
How more custom can it be here? Beside that any number would suffice here, having a more random looking one did not really help here but if a generated one would be preferred why not ... its just a number no one ever will look at really.
There was a problem hiding this comment.
Isn't the generated number somehow dependent on the implementation class details such that if you change it you can generate a new one?
There was a problem hiding this comment.
Isn't the generated number somehow dependent on the implementation class details such that if you change it you can generate a new one?
Java generates one by default based on the classfile and I would assume JDT is using that one algorithm when asking to add one explicitly (!).
If incrementing a number from 1 > 2 is better or deleting the value (hopefully never forget :-P ) and let it make the default explicit again is something I could not judge.
Usually one want to have a stable one so recompilation does not change it and making everything previously saved invalid even if the class structure is not changed.
So usually:
- any number is sufficient
- you should change it to something else if you change the structure and can't live e.g. with new fields becoming
null - If you don't supply one you will get some default.
|
@tjwatson any thoughts? |
3 participants
I noticed that when working on eclipse-pde/eclipse.pde#1898 that we need special handling for reading/writing a
IPath.As
IPathis just a collection of strings and some flags I don't see why we should not support it even though it might not be portable (in wich case one would better use an own serialization way).