{"action":"opened","issue":{"url":"https://api.github.com/repos/FasterXML/jackson-dataformat-smile/issues/33","labels_url":"https://api.github.com/repos/FasterXML/jackson-dataformat-smile/issues/33/labels{/name}","comments_url":"https://api.github.com/repos/FasterXML/jackson-dataformat-smile/issues/33/comments","events_url":"https://api.github.com/repos/FasterXML/jackson-dataformat-smile/issues/33/events","html_url":"https://github.com/FasterXML/jackson-dataformat-smile/issues/33","id":129587825,"number":33,"title":"(2.7-regress) Handling of deprecated `SimpleType.construct()` too minimalistic","user":{"login":"cowtowncoder","id":55065,"avatar_url":"https://avatars.githubusercontent.com/u/55065?v=3","gravatar_id":"","url":"https://api.github.com/users/cowtowncoder","html_url":"https://github.com/cowtowncoder","followers_url":"https://api.github.com/users/cowtowncoder/followers","following_url":"https://api.github.com/users/cowtowncoder/following{/other_user}","gists_url":"https://api.github.com/users/cowtowncoder/gists{/gist_id}","starred_url":"https://api.github.com/users/cowtowncoder/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cowtowncoder/subscriptions","organizations_url":"https://api.github.com/users/cowtowncoder/orgs","repos_url":"https://api.github.com/users/cowtowncoder/repos","events_url":"https://api.github.com/users/cowtowncoder/events{/privacy}","received_events_url":"https://api.github.com/users/cowtowncoder/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-01-28T21:28:25Z","updated_at":"2016-01-28T21:28:25Z","closed_at":null,"body":"(note: spun from https://github.com/FasterXML/jackson/issues/48)\r\n\r\nDue to changes in type resolution, most direct construction methods in `JavaType` sub-classes can not be fully supported. Failure modes are typically with complex cases (and expected to be rare), with one exception: use of `SimpleType.construct(Class)`, because:\r\n\r\n1. This is mostly used for complex types, and not just \"well-known\" interfaces like `List`, `Map`; so actual access to at least immediate fields is necessary (and similarly lack of super-type info is problematic), and\r\n2. Its usage is likely to be wide-spread, despite existence of preferable methods (`TypeFactory`)\r\n3. Since refactoring of type resolution was not anticipated early enough in advance, deprecation of methods we want to move users away from could not be done in 2.6, as it should have been (in perfect case)\r\n\r\nExact reasoning behind problems is quite complicated: but the fundamental reason is that `TypeFactory` has all the logic to do the generic resolution; `JavaType` has (and should have) very little if any. Since no reference to the factory is passed via constructors/factory methods, they can not properly delegate resolution tasks. This is why direct calls should only be made with all necessary, pre-resolved information; passing `JavaType`s for elements, not `Class`.\r\nInability to resolve things means that super-types can not be properly resolved, for example. Handling of fields, methods will also be inexact wrt generic types.\r\n\r\nThe first immediate problem is something that should be addressable: introspection by POJO deserializer builder does not find any fields or methods. It should be possible to at least find them, even if type resolution for generic types will not work well. This should be acceptable for the common (and reported) case of constructing element types for `Collection`s and `Map`s: generic parameterization will not be accessible anyway.\r\n\r\nThere are other potential issues to address as best we can, but first things first.\r\n\r\n"}}