It would be wasteful to always fetch the entire objects.
First I would question this. If your objects are well-designed and not too bloated, the performance and memory overhead of fetching them completely instead of getting them partially is often negligible for most real-world cases. The performance of SQL queries over a network are way more dependend on the number of roundtrips they cause than on the number of columns involved (often it does not even make a huge difference if a query returns 1, 10 or 30 columns, and interestingly, this is often true for the number of rows as well). Investing too much thought into getting only the columns required for certain cases is often just a form of premature optimization.
However, if you really know for sure - (and that means: after profiling!) - in your application that getting model objects partially, or querying tables partially will actually bring you a required performance benefit, then you need to design your repository interface in a way it allows to specify the columns to be queried (and construct the SQL query from that spec). Your model objects should have an extra boolean metadata field for each column which indicates if the column was loaded by the last query or not, and the repositories have to maintain this field accordingly. The "getter" method for each column then can throw an exception if another part of the program will try to access an unloaded column later.
If your data objects map to several parent-child tables and your goal is just to use partial loading for avoiding SQL joins, it is also possible to implement this concept of partially loaded objects in coarser granularity, where extra metadata fields only indicates which child tables are actually loaded and which not.
I don't know if there is an ORM or framework for your environment which supports this out-of-the-box (I guess jdbcTemplates does not), but as you asked for a non-ORM solution I guess you have to implement this concept by yourself either.
The alternative to filling your pre-existing model-objects partially is to have individual, dynamic objects generated automatically for each query. This works best if there is programming language support for this:
as mentioned by @Euphoric, in C# LINQ can be utilized to generate objects of anonymous types for each query, which allows to create a type-safe solution
also in C#, one could utilize the type dynamic for this (see, for example, how the Micro ORM Dapper supports this). This is not type-safe anymore, however.
in almost any major language, query results could be (lists of) instances of dictionaries, where the keys are the column names and the values are the column values of each records (either as strings, or as objects encapsulating the basic scalar datatypes). This can be implemented easily in a generic fashion. Of course, this is even less type safe, but it is a solution which is quite common in many scripting languages.
