Shawn Heisey commented on SOLR-9231:

Interesting problem.  I guess the underlying question is ... what sort of API 
guarantees do we intend to honor for SolrJ?

I think the removal of the no-arg constructor fits with a policy of "typical 
API usage will continue to compile with a minor-version update."  IMHO, your 
usage is not typical.  Classloaders and other things that utilize method 
signatures are an advanced kind of Java programming.

A more strict guarantee of "code compiled against SolrJ X.Y will work if the 
jar is upgraded in place to version X.Z" would be required for your usage.  It 
may be reasonable for users to expect this kind of guarantee, but apparently 
whoever removed the constructor did not share this opinion.

> SolrInputDocument no-args constructor removed without notice
> ------------------------------------------------------------
>                 Key: SOLR-9231
>                 URL: https://issues.apache.org/jira/browse/SOLR-9231
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrJ
>    Affects Versions: 6.1
>         Environment: Lucee (or ColdFusion) loading SolrJ using separate 
> URLClassLoader instance)
>            Reporter: Tim Parker
> In 6.0.1 and previous, SolrInputDocument provided two constructors - one with 
> no arguments, the other accepting a Map object.  As of 6.1.0, the 
> no-arguments constructor is replaced with one that accepts zero or more 
> strings.
> With 6.0.1, this worked:
> cls = LoadClass("org.apache.solr.common.SolrInputDocument");
> Constructor foo = cls.getConstructor();
> This fails with Solr 6.1.0
> We get the same error after updating the code to this:
> cls = LoadClass("org.apache.solr.common.SolrInputDocument");
> Class[] argArray = new Class[0];
> Constructor foo = cls.getConstructor(argArray);
> Are we missing something?  If not, please restore the missing no-arguments 
> constructor.

This message was sent by Atlassian JIRA

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

Reply via email to