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] [Created] (TAVERNA-896) Use Path instead of java.util.File in API signatures
Date Mon, 15 Feb 2016 09:30:18 GMT
Stian Soiland-Reyes created TAVERNA-896:

             Summary: 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

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).

This message was sent by Atlassian JIRA

View raw message