[
https://issues.apache.org/jira/browse/TAVERNA-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated TAVERNA-896:
----------------------------------------
Description:
Several of our interfaces that are about to be released under taverna-osgi and
taverna-engine had methods with {{java.io.File}} in their signatures - however
I don't think there should be any reason why this should not be the more modern
{{java.nio.file.Path}}
It's easy to move between File and Path as there's {{file.toPath()}} and
{{path.toFile()}} methods that work well with local file:/// paths.
I had a quick search-replace across the interface signatures inside {{*-api}}
of taverna-osgi and taverna-engine, but didn't change the implementations
beyond doing {{.toFile()}} on the incoming Path's - so the implementations
don't currently support non-file:// Paths (e.g. would not support Paths from
inside an robundle).
(When changing from File to Path in implementation, be aware that Path have
more explicit exceptions, while File could silently fail - e.g. file.mkdir()
would just return no matter if it worked or not)
Although changing to use Path everywhere probably is good for stability
(explicitly handling exceptions where needed), that is a bigger job, so
I think at least changing the API interface signatures now means we would be
allowed to later change the implementations without affecting the callers.
I have updated the commandline to the modified calls - but not the workbench
(which has other compile issues).
was:
Several of our interfaces that are about to be released under taverna-osgi and
taverna-engine had methods with java.io.File in their signatures - however I
don't think there should be any reason why this should not be the more modern
java.nio.file.Path
It's easy to move between File and Path as there's .toPath() and .toFile()
methods that work well with local file:/// paths.
I had a quick search-replace across the interface signatures inside *-api of
taverna-osgi and taverna-engine, but didn't change the implementations beyond
doing .toFile() on the incoming Path's - so the implementations don't currently
support non-file:// Paths (e.g. would not support Paths from inside an
robundle).
(When changing from File to Path in implementation, be aware that Path have
more explicit exceptions, while File could silently fail - e.g. file.mkdir()
would just return no matter if it worked or not)
Although changing to use Path everywhere probably is good for stability
(explicitly handling exceptions where needed), that is a bigger job, so
I think at least changing the API interface signatures now means we would be
allowed to later change the implementations without affecting the callers.
I have updated the commandline to the modified calls - but not the workbench
(which has other compile issues).
> Use Path instead of java.util.File in API signatures
> ----------------------------------------------------
>
> Key: TAVERNA-896
> URL: https://issues.apache.org/jira/browse/TAVERNA-896
> Project: Apache Taverna
> Issue Type: Bug
> Components: Taverna Engine, Taverna OSGi
> Reporter: Stian Soiland-Reyes
> Assignee: Stian Soiland-Reyes
> Labels: file, path
>
> Several of our interfaces that are about to be released under taverna-osgi
> and taverna-engine had methods with {{java.io.File}} in their signatures -
> however I don't think there should be any reason why this should not be the
> more modern {{java.nio.file.Path}}
> It's easy to move between File and Path as there's {{file.toPath()}} and
> {{path.toFile()}} methods that work well with local file:/// paths.
> I had a quick search-replace across the interface signatures inside {{*-api}}
> of taverna-osgi and taverna-engine, but didn't change the implementations
> beyond doing {{.toFile()}} on the incoming Path's - so the implementations
> don't currently support non-file:// Paths (e.g. would not support Paths from
> inside an robundle).
> (When changing from File to Path in implementation, be aware that Path have
> more explicit exceptions, while File could silently fail - e.g. file.mkdir()
> would just return no matter if it worked or not)
> Although changing to use Path everywhere probably is good for stability
> (explicitly handling exceptions where needed), that is a bigger job, so
> I think at least changing the API interface signatures now means we would be
> allowed to later change the implementations without affecting the callers.
> I have updated the commandline to the modified calls - but not the workbench
> (which has other compile issues).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
