Comments (9)
Hmm... This only repros in eclipse for me, running eclipse 4.6.2.
I'm guessing that the version of ecj bundled with that eclipse version isn't supporting parameter name reflection the same way javac does.
from jackson-modules-java8.
Odd. It seems that static method with delegation should work.
But you may want to add explicit mode
in @JsonCreator
(specifically, mode = DELEGATING
), just in case it would otherwise auto-detect it as property-based -- possible, since implicit name is available with parameter names.
Also: when reporting problems please indicate Jackson version in question (... and if not latest patch of minor version, try out the latest patch, since I'll ask for that anyway :) )
from jackson-modules-java8.
Version is 2.9.2. With mode = DELEGATING it works in eclipse. I'm trying to get it to compile with ecj in gradle and run that, not sure if I've done it right, but I haven't gotten that to fail yet.
from jackson-modules-java8.
Stepping through a debugger in eclipse, I see in BeanDeserializerFactory#_addExplicitAnyCreator
// If there's injection or explicit name, should be properties-based
boolean useProps = (paramName != null) || (injectId != null);
if (!useProps && (paramDef != null)) {
// One more thing: if implicit name matches property with a getter
// or field, we'll consider it property-based as well
paramName = candidate.findImplicitParamName(0);
useProps = (paramName != null) && paramDef.couldSerialize();
}
if (useProps) {
SettableBeanProperty[] properties = new SettableBeanProperty[] {
constructCreatorProperty(ctxt, beanDesc, paramName, 0, param, injectId)
};
creators.addPropertyCreator(candidate.creator(), true, properties);
return;
}
_handleSingleArgumentCreator(creators, candidate.creator(), true, true);
Both paramName
and injectId
are null, paramDef
is
[Property 'foo'; ctors: [parameter #0, annotations: [null]][visible=true,ignore=false,explicitName=false], field(s): null, getter(s): [method example.FooTest$Foo#getFoo(0 params)][visible=true,ignore=false,explicitName=false], setter(s): null]
This ends up passing through both if blocks and setting a property creator instead of going through _handleSingleArgumentCreator
which would create a string creator.
from jackson-modules-java8.
@twilson-palantir I have a feeling that one of fixes for jackson-databind
, for 2.9.4
might be relevant here -- there was a case where single-String-argument was not properly detected:
FasterXML/jackson-databind#1853
I am hoping to release 2.9.4
soon. If you are able to locally build 2.9.4-SNAPSHOT
from branch 2.9
it might be worth trying out.
from jackson-modules-java8.
I'm a bit skeptical that will help since when it gets to
switch (creatorMode) {
case DELEGATING:
_addExplicitDelegatingCreator(ctxt, beanDesc, creators,
CreatorCandidate.construct(intr, ctor, null));
break;
case PROPERTIES:
_addExplicitPropertyCreator(ctxt, beanDesc, creators,
CreatorCandidate.construct(intr, ctor, creatorParams.get(ctor)));
break;
default:
_addExplicitAnyCreator(ctxt, beanDesc, creators,
CreatorCandidate.construct(intr, ctor, creatorParams.get(ctor)));
break;
}
it ends up calling _addExplicitAnyCreator
, not _addExplicitDelegatingCreator
, but I'm willing to try it out.
I'm not familiar with building maven projects though and I can't find any build instructions anywhere. Just running mvn install
in jackson-databind
on the 2.9
branch gives me
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for com.fasterxml.jackson.core:jackson-databind:2.9.4-SNAPSHOT: Could not find artifact com.fasterxml.jackson:jackson-base:pom:2.9.4-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 5, column 11
@
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project com.fasterxml.jackson.core:jackson-databind:2.9.4-SNAPSHOT (/Users/twilson/code/jackson-databind/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for com.fasterxml.jackson.core:jackson-databind:2.9.4-SNAPSHOT: Could not find artifact com.fasterxml.jackson:jackson-base:pom:2.9.4-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 5, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
from jackson-modules-java8.
Explicit will ever occur with mode
laid out; otherwise it will be trying to use heuristics to figure out users intent. So that would not change.
In the end I think that adding explicit mode
declaration is the right thing to do: there isn't much benefit in trying to make ambiguous case work.
from jackson-modules-java8.
I'm ok with adding the mode
declaration as the fix for this case. I'm also ok with having no mode declaration result in an error.
I'm less ok with the actual error that got returned since it's simply wrong, there is a string-argument factory constructor. Based on the error I have no way of knowing I might want to set mode = DELEGATING
.
I'm also less ok with this working differently in eclipse and gradle with no explanation as to why they differ. In both cases I ran ecj, I also ran with -verbose:class
to verify that the same jdk and jackson versions were being used and nothing else on the classpath was involved.
from jackson-modules-java8.
mode
is only needed for 1-argument case. And although I would agree that it is unfortunate there is this particular case where combination of parameter names existing (or not!) adding exception would cause way bigger problems for many other users, who are relying on functionality working. And based on feedback (issues reported) I am certain that adding exception even for 3.0 would generate metric tons of complaints on breaking something that used to work.
I don't know how to resolve this for 3.0, either; with one exception that rule for selecting in ambiguous case can be simplified to ALWAYS be Delegating OR ALWAYS Properties-based.
And NOT trying to use heuristics, which are a lost cause due to complexity of everything.
from jackson-modules-java8.
Related Issues (20)
- `LocalDateTime` serialization issue with custom-configured `LocalDateTimeSerializer` HOT 12
- InstantDeserializer fails to parse negative numeric timestamp strings for pre-1970 values. HOT 2
- Custom java time module ignored after upgrade to 2.16 HOT 3
- `Optional` deserialization, serialization ignore `contentConverter` HOT 1
- NPE when serializing a `LocalDate` or `LocalDateTime` using `AsDeductionTypeSerializer` HOT 9
- OffsetTimeSerializer not writing seconds for time object like 15:30:00Z (where seconds is 00) HOT 2
- Implicit name provided by `ParameterNamesModule` overridden by "incomplete" `@JsonProperty` HOT 1
- I don't deserialize java 8 date/time type `java.time.Instant` HOT 2
- ZonedDateTime not serialised as UTC by default HOT 1
- Instants get not deserialized as expected sometimes HOT 2
- Only `DateTimeFormatter.ISO_OFFSET_DATE_TIME` accepted by `ZonedDateTimeKeyDeserializer` HOT 1
- Can't deserialize OffsetDateTime.MIN: Invalid value for EpochDay
- Date and time serialization are very inconsistent HOT 3
- Absent nested optional shennanigans HOT 1
- The serialization of an object of type LocalDate did not record its type HOT 2
- Q on Serializing java.time dates w/o nano parts HOT 2
- Add javaTimeModule.addDeserializer(String.class,...) Error parsing generated later HOT 4
- java.lang.NoSuchFieldError: READ_DATE_TIMESTAMPS_AS_NANOSECONDS after update to 2.16 or 2.17 HOT 3
- Parameter names: Class with a single-parameter implicit constructor fails deserialization, works if more (unused) parameters are added HOT 3
- Inconsistent BeanPropertyDefinition#couldDeserialize and actual deserialization behavior HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jackson-modules-java8.