Reading SQL file using injection and utility reader
The idea to extract SQL queries from the code into in a separate resource is good in general. Its main advantage is that when there is a non-substantial change at the database side, it might be enough to change the resource file, without recompiling the code.

However, it slightly reduces the readability: the query is in a separate file, you do not have it immediately visible near the instructions that process the ResultSet. That can become confusing if the query is passed to a PreparedStatement with a number of parameters, but everything finally depends on each case. This discussion can easily end up with arguing whether inline SQL is better than using an ORM :)

For the solution that you submitted, I can observe the following:


each *.sql file can contain only one query. If there are a lot of queries used by objects within a package, this can easily pollute the folder and you'll need to be careful when choosing a naming convention for the files, otherwise one will be easily lost among them. selectStatement.sql is just an example and real resources should have names like selectBookByAuthor.sql etc.
a single string with plain and directly usable SQL is replaced with two values which are not obvious to change and maintain if necessary: the class name (com.mycompany.SqlReader) and the file name (com/mycompany/selectStatement.sql), because both are packed in the same string expression. Would you rely on your IDE or make all changes manually for each occurrence when these two values are changing?
the UnsupportedOperationException is not the best choice for this case. Logically, the operation is supported, but something gone wrong here and the expected predefined statement could not be read. The application is thus in an invalid state: the .sql was not included in the build sequence or a typo in the file name... I think that IllegalStateException is much better here. It also should be moved inside the catch block and chained with the IOE (throw new IllegalStateException(ioexception);). You should probably consider adding to the catch block other exception types, if any, that can result from calling FileUtils.readFileToString.


Another Approach

I can suggest another approach that has more or less the same result of externalizing SQL queries, but can be achieved without the dedicated SqlReader class, only by using the features of Spring.

The fields representing SQL queries can be initialized from property file sources:

@Value("${sql.select.products}")
private String selectProductsQuery;


The properties file must contain the key sql.select.products.

The annotation @PropertySource is used to point to the properties file to look in:

@PropertySource("classpath:/queries.properties")
public class TestDAO { ... }


In queries.properties you just specify the queries to use:

sql.select.products=SELECT p.id, p.name ... FROM product p...


The advantages:


it's all managed by Spring, once the configuration is set up properly.
You have all the queries in the same file.