VFS - minor performance improvement

[adrian.brock]

Can we add a VFS/VirtualFile.getChild() that doesn't throw an IOException?

/**
* Get a child
*
* @return the child or <code>null</code> if not found
* @throws IOException if a real problem occurs
*/
public VirtualFile getChild() throws IOException {}

I imagine the construction of the all the IOExceptions to say "file not found"
from findChild() is pretty slow. :-)

[alesj]

Can we add a VFS/VirtualFile.getChild() that doesn't throw an IOException?

/**
* Get a child
*
* @return the child or <code>null</code> if not found
* @throws IOException if a real problem occurs
*/
public VirtualFile getChild() throws IOException {}

I can add this, and we can then slowly move the findChild usage to this new getChild + null check.

And I guess you mean getChild(String path)? ;-)

[starksm64]

I thought we talked about changing getChild(...) to not throw the IOException.

[alesj]

I thought we talked about changing getChild(...) to not throw the IOException.

There is no getChild() method yet in VFS.
Only findChild(), which most of the code expects to throw IOE if the child is not found, so the direct change would probably introduce a lot of NPEs.

[adrian.brock]

I thought we talked about changing getChild(...) to not throw the IOException.

You're thinking of the isLeaf() checking for child operations. It current throws an IOE if you
do findChild(), getChildren(), visit(), etc. on a leaf.
We should probably keep for that for findChild (backwards compatibilty - null is not an
expected return value) but return null, Collections.emptyList() or do a no-op visit
in the other methods.

[alesj]

It current throws an IOE if you
do findChild(), getChildren(), visit(), etc. on a leaf.
We should probably keep for that for findChild (backwards compatibilty - null is not an
expected return value) but return null, Collections.emptyList() or do a no-op visit
in the other methods.

I've added a getChild to VFS and VirtualFile.

The current code has some duplicates.
I'll remove the findChild from spi parts, just leaving the findChild on the api.

[alesj]

"alesj" wrote:
I'll remove the findChild from spi parts, just leaving the findChild on the api.

I've got the MC and AS5 fixes in place, just need to do a release.
I can do a VFS beta7, or still deploy a snapshot for some additional changes?
Still waiting for some caching input. :-)

I'll also put changes from beta6 into our new VFS JIRA space.

[dimitris]

I'd prefer to have a tagged VFS Beta7 without caching changes first, then experiment with that part, so we can rollback if needed.

[alesj]

I'd prefer to have a tagged VFS Beta7 without caching changes first, then experiment with that part, so we can rollback if needed.

OK, once I've cleanup the findChild/getChild mess, I'll do a beta7 release + change the MC, AS5 usages that make sense.

[starksm64]

I created a post for an mc 2.0.0.Beta10 release due next Monday. Lets coordinate on that as I need some metavalue changes.

[alesj]

Lets coordinate on that as I need some metavalue changes.

How does this effect VFS?

[starksm64]

It does not affect the vfs release, that can be done anytime. I was referring to the mc update comment.

[alesj]

I was referring to the mc update comment.

I basically just changed the usage of findChild to getChild where it made absolute sense.
And since the method doesn't throw IOE for not finding the resource, I had to change the try/catch parts a bit + handling the null return.

[alesj]

Should I return null for reverse path tokens going over the top as well?

 if (PathTokenizer.isReverseToken(tokens[index))
 {
 VirtualFileHandler parent = current.getParent();
 if (parent == null) // TODO - still IOE or null?
 throw new IOException("Using reverse path on top file handler: " + current + ", " + path);
 else
 current = parent;
 }

I guess since this is a rare usage, and you probably expect the reverse path to work, I could be still useful to throw IOE.