Query is slow with JDBC parameters, fast with concatenated SQL
Not a complete answer, but here's some diagnostics and suggestions from looking at the plans.  

You're running SQL 2016, so there's a ton of useful info in the plan. 

First is that you're running a GDR patch for SQL 2016 SP1 (13.0.4224.16).  SQL 2016 SP2 was released on April 24, 2108, almost a year ago, and after 1 year applying the service pack is required for support.  So you can test this on SQL 2016 SP2, or SQL 2017 to see if it behaves differently. 

When optimizing a parameterized query, SQL Server has to pick a plan that will be used for all future values of fooId and likeParameter.  Apparently it's guessing you will often have a selective LIKE predicate, and so using the Name index will, on average, be cheaper.  With the hard-coded values, SQL Server doesn't need to build a plan that works for multiple different LIKE predicates, and so picks a plan that doesn't use a non-clustered index. 

To evaluate the predicate NAME_ LIKE @p SQL Server is range scanning a non-clustustered index on NAME_.  This works great if you happen to pass a LIKE predicate that starts with a few literal characters, but when it starts with a wildcard, will require a complete scan of the index.  Here scanning, and evaluating the LIKE predicate for each of 14M rows.

In the fast plan SQL seeks 21,518 separate components using the clustered index and checks each one's name against the LIKE predicate.

From the plans:

The difference between the plans is a single operator, which accounts for all of the increased cost: a scan of 14,675,300 rows from the index [PDL_COMPONENT].[IDX_COMPONENT_NAME], taking 37sec of CPU time: 

  &lt;RunTimeInformation&gt;
    &lt;RunTimeCountersPerThread 
      Thread="0" 
      ActualRows="741" 
      Batches="0" 
      ActualEndOfScans="1" 
      ActualExecutions="1" 
      ActualExecutionMode="Row" 
      ActualElapsedms="37038" 
      ActualCPUms="37028" /&gt;
  &lt;/RunTimeInformation&gt;


Not parameter sniffing, as the ParameterCompiledValue is the same as ParemeterRuntimeValue:

    &lt;ParameterList&gt;
      &lt;ColumnReference Column="@P1" ParameterDataType="nvarchar(127)" ParameterCompiledValue="N'%geronimo%'" ParameterRuntimeValue="N'%geronimo%'" /&gt;
      &lt;ColumnReference Column="@P0" ParameterDataType="int" ParameterCompiledValue="(9)" ParameterRuntimeValue="(9)" /&gt;
    &lt;/ParameterList&gt;


Using the query with the hard-coded values isn't the worst idea here.  Or you could try a RECOMPILE and turn off plan caching without giving up parameterizing your queries.

And I don't know what the indexes and foreign keys in the database are, but using DISTINCT has really bad code smell, as it often indicates that one or more JOIN is not correct, and it affects the cardinality estimation of the query.