[ 
https://issues.apache.org/jira/browse/SOLR-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549149#comment-15549149
 ] 

Shawn Heisey commented on SOLR-1236:
------------------------------------

I guess the question is whether we need a specific issue to focus on avoiding 
String and platform-specific representations of paths.  I think it will always 
be relevant to worry about this, but IMHO it's more of a general coding 
guideline than a specific issue.  That approach says we close this issue and 
check whatever documentation we have regarding coding practices.

File objects, the focus of this issue, are now thoroughly outdated.  Lucene has 
switched to NIO2, which utilizes Path.

If it hasn't been done already, then for both LUCENE and SOLR, I think we 
probably need to add File to the forbidden-api list to detect any unwanted 
stragglers and make sure the old APIs don't creep back in.


> stop using strings for filepaths and start using File objects
> -------------------------------------------------------------
>
>                 Key: SOLR-1236
>                 URL: https://issues.apache.org/jira/browse/SOLR-1236
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Hoss Man
>            Priority: Trivial
>
> Catching up on my email after a long hiatus i notice SOLR-1213 and it 
> reminded me that the last time i was digging arround in the code i was 
> frustrated by lots of places in Solr where "String" instances to store a file 
> or directory paths and then manipulated with String operations.  I would be 
> nice to switch all of these member variables and and function params to use 
> genuine File objects to improve the code base readibility, and reduce the 
> likelyhood of OS variant bugs or nonsensical path operations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to