taverna-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stian Soiland-Reyes (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (TAVERNA-896) Use Path instead of java.util.File in API signatures
Date Wed, 17 Feb 2016 13:33:18 GMT

     [ https://issues.apache.org/jira/browse/TAVERNA-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Stian Soiland-Reyes updated TAVERNA-896:
    Fix Version/s: engine 3.1.0
                   osgi 0.2.1

> 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
>             Fix For: osgi 0.2.1, engine 3.1.0
> 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

View raw message