barty/D4J-Repair huggingface dataset:
File: src/main/java/com/fasterxml/jackson/core/JsonPointer.java
Issue: An exception is thrown for a valid JsonPointer expression
Json-Patch project leader has noted me that there is a bug on JsonPointer implementation and I have decided to investigate.
Basically if you do something like JsonPointer.compile("/1e0"); it throws a NumberFormatExpcetion which is not true. This is because this piece of code:
private final static int _parseInt(String str)
    {
        final int len = str.length();
        if (len == 0) {
            return -1;
        }
        for (int i = 0; i < len; ++i) {
            char c = str.charAt(i++);
            if (c > '9' || c < '0') {
                return -1;
            }
        }
        // for now, we'll assume 32-bit indexes are fine
        return NumberInput.parseInt(str);
    }
When they found a number it interprets the segment as integer but in reality it should be the whole expression. For this reason I think that the condition should be changed to the inverse condition  (if it doesn't found any char then it is a number.
If you want I can send you a PR as well.
Alex.

Buggy code:
private final static int _parseIndex(String str) {
    final int len = str.length();
    // [Issue#133]: beware of super long indexes; assume we never
    // have arrays over 2 billion entries so ints are fine.
    if (len == 0 || len > 10) {
        return -1;
    }
    for (int i = 0; i < len; ++i) {
        char c = str.charAt(i++);
        if (c > '9' || c < '0') {
            return -1;
        }
    }
    if (len == 10) {
        long l = NumberInput.parseLong(str);
        if (l > Integer.MAX_VALUE) {
            return -1;
        }
    }
    return NumberInput.parseInt(str);
}

Fixed code:
private final static int _parseIndex(String str) {
    final int len = str.length();
    // [Issue#133]: beware of super long indexes; assume we never
    // have arrays over 2 billion entries so ints are fine.
    if (len == 0 || len > 10) {
        return -1;
    }
    for (int i = 0; i < len; ++i) {
        char c = str.charAt(i);
        if (c > '9' || c < '0') {
            return -1;
        }
    }
    if (len == 10) {
        long l = NumberInput.parseLong(str);
        if (l > Integer.MAX_VALUE) {
            return -1;
        }
    }
    return NumberInput.parseInt(str);
}
File: src/main/java/com/fasterxml/jackson/core/JsonPointer.java
Issue: JsonPointer should not consider "00" to be valid index
Although 00 can be parsed as 0 in some cases, it is not a valid JSON number; and is also not legal numeric index for JSON Pointer. As such, JsonPointer class should ensure it can only match property name "00" and not array index.

Buggy code:
private final static int _parseIndex(String str) {
    final int len = str.length();
    // [core#133]: beware of super long indexes; assume we never
    // have arrays over 2 billion entries so ints are fine.
    if (len == 0 || len > 10) {
        return -1;
    }
    // [core#176]: no leading zeroes allowed
    for (int i = 0; i < len; ++i) {
        char c = str.charAt(i);
        if (c > '9' || c < '0') {
            return -1;
        }
    }
    if (len == 10) {
        long l = NumberInput.parseLong(str);
        if (l > Integer.MAX_VALUE) {
            return -1;
        }
    }
    return NumberInput.parseInt(str);
}

Fixed code:
private final static int _parseIndex(String str) {
    final int len = str.length();
    // [core#133]: beware of super long indexes; assume we never
    // have arrays over 2 billion entries so ints are fine.
    if (len == 0 || len > 10) {
        return -1;
    }
    // [core#176]: no leading zeroes allowed
    char c = str.charAt(0);
    if (c <= '0') {
        return (len == 1 && c == '0') ? 0 : -1;
    }
    if (c > '9') {
        return -1;
    }
    for (int i = 1; i < len; ++i) {
        c = str.charAt(i);
        if (c > '9' || c < '0') {
            return -1;
        }
    }
    if (len == 10) {
        long l = NumberInput.parseLong(str);
        if (l > Integer.MAX_VALUE) {
            return -1;
        }
    }
    return NumberInput.parseInt(str);
}
File: src/main/java/com/fasterxml/jackson/core/json/JsonWriteContext.java
Issue: Add a check so JsonGenerator.writeString() won't work if writeFieldName() expected.
Looks like calling writeString() (and perhaps other scalar write methods) results in writing invalid output, instead of throwing an exception. It should instead fail; in future we may want to consider allowing this as an alias, but at any rate it should not produce invalid output.

Buggy code:
public int writeValue() {
    // Most likely, object:
    if (_type == TYPE_OBJECT) {
        _gotName = false;
        ++_index;
        return STATUS_OK_AFTER_COLON;
    }

    // Ok, array?
    if (_type == TYPE_ARRAY) {
        int ix = _index;
        ++_index;
        return (ix < 0) ? STATUS_OK_AS_IS : STATUS_OK_AFTER_COMMA;
    }
    
    // Nope, root context
    // No commas within root context, but need space
    ++_index;
    return (_index == 0) ? STATUS_OK_AS_IS : STATUS_OK_AFTER_SPACE;
}

Fixed code:
public int writeValue() {
    // Most likely, object:
    if (_type == TYPE_OBJECT) {
        if (!_gotName) {
            return STATUS_EXPECT_NAME;
        }
        _gotName = false;
        ++_index;
        return STATUS_OK_AFTER_COLON;
    }

    // Ok, array?
    if (_type == TYPE_ARRAY) {
        int ix = _index;
        ++_index;
        return (ix < 0) ? STATUS_OK_AS_IS : STATUS_OK_AFTER_COMMA;
    }
    
    // Nope, root context
    // No commas within root context, but need space
    ++_index;
    return (_index == 0) ? STATUS_OK_AS_IS : STATUS_OK_AFTER_SPACE;
}
File: src/main/java/com/fasterxml/jackson/core/util/TextBuffer.java
Issue: Inconsistent TextBuffer#getTextBuffer behavior
Hi, I'm using 2.4.2. While I'm working on CBORParser, I noticed that CBORParser#getTextCharacters() returns sometimes null sometimes [] (empty array) when it's parsing empty string "".
While debugging, I noticed that TextBuffer#getTextBuffer behaves inconsistently.
TextBuffer buffer = new TextBuffer(new BufferRecycler());
buffer.resetWithEmpty();
buffer.getTextBuffer(); // returns null
buffer.contentsAsString(); // returns empty string ""
buffer.getTextBuffer(); // returns empty array []

I think getTextBuffer should return the same value. Not sure which (null or []) is expected though.

Buggy code:
public char[] getTextBuffer()
{
    // Are we just using shared input buffer?
    if (_inputStart >= 0) return _inputBuffer;
    if (_resultArray != null)  return _resultArray;
    if (_resultString != null) {
        return (_resultArray = _resultString.toCharArray());
    }
    // Nope; but does it fit in just one segment?
    if (!_hasSegments)  return _currentSegment;
    // Nope, need to have/create a non-segmented array and return it
    return contentsAsArray();
}

Fixed code:
public char[] getTextBuffer()
{
    // Are we just using shared input buffer?
    if (_inputStart >= 0) return _inputBuffer;
    if (_resultArray != null)  return _resultArray;
    if (_resultString != null) {
        return (_resultArray = _resultString.toCharArray());
    }
    // Nope; but does it fit in just one segment?
    if (!_hasSegments && _currentSegment != null)  return _currentSegment;
    // Nope, need to have/create a non-segmented array and return it
    return contentsAsArray();
}
File: src/main/java/com/fasterxml/jackson/databind/node/TreeTraversingParser.java
Issue: TreeTraversingParser does not take base64 variant into account
This affects at least 2.6.4 to current versions. In TreeTraversingParser#getBinaryValue, a Base64Variant is accepted but ignored. The call to n.binaryValue(), when n is a TextNode, then uses the default Base64 variant instead of what's specified. It seems the correct behavior would be to call TextNode#getBinaryValue instead.

Buggy code:
public byte[] getBinaryValue(Base64Variant b64variant)
    throws IOException, JsonParseException
{
    // Multiple possibilities...
    JsonNode n = currentNode();
    if (n != null) {
        // [databind#2096]: although `binaryValue()` works for real binary node
        // and embedded "POJO" node, coercion from TextNode may require variant, so:
        byte[] data = n.binaryValue();
        if (data != null) {
            return data;
        }
        if (n.isPojo()) {
            Object ob = ((POJONode) n).getPojo();
            if (ob instanceof byte[]) {
                return (byte[]) ob;
            }
        }
    }
    // otherwise return null to mark we have no binary content
    return null;
}

Fixed code:
public byte[] getBinaryValue(Base64Variant b64variant)
    throws IOException, JsonParseException
{
    // Multiple possibilities...
    JsonNode n = currentNode();
    if (n != null) {
        // [databind#2096]: although `binaryValue()` works for real binary node
        // and embedded "POJO" node, coercion from TextNode may require variant, so:
        if (n instanceof TextNode) {
            return ((TextNode) n).getBinaryValue(b64variant);
        }
        return n.binaryValue();
    }
    // otherwise return null to mark we have no binary content
    return null;
}
File: src/main/java/com/fasterxml/jackson/databind/deser/std/JdkDeserializers.java
Issue: Illegal reflective access operation warning when using `java.lang.Void` as value type
I'm using Jackson (**2.9.7**) through Spring's RestTemplate:

```java
ResponseEntity<Void> response = getRestTemplate().exchange(
		requestUrl,
		HttpMethod.PATCH,
		new HttpEntity<>(dto, authHeaders),
		Void.class
);
```

When [`Void`](https://docs.oracle.com/javase/7/docs/api/java/lang/Void.html) is used to indicate that the ResponseEntity has no body, the following warning appears in the console:

```
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.fasterxml.jackson.databind.util.ClassUtil (file:/<snip>repository/com/fasterxml/jackson/core/jackson-databind/2.9.7/jackson-databind-2.9.7.jar) to constructor java.lang.Void()
WARNING: Please consider reporting this to the maintainers of com.fasterxml.jackson.databind.util.ClassUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
```

The problem disappears if `String` is used as generic type. 

Buggy code:
public static JsonDeserializer<?> find(Class<?> rawType, String clsName)
    {
        if (_classNames.contains(clsName)) {
            JsonDeserializer<?> d = FromStringDeserializer.findDeserializer(rawType);
            if (d != null) {
                return d;
            }
            if (rawType == UUID.class) {
                return new UUIDDeserializer();
            }
            if (rawType == StackTraceElement.class) {
                return new StackTraceElementDeserializer();
            }
            if (rawType == AtomicBoolean.class) {
                // (note: AtomicInteger/Long work due to single-arg constructor. For now?
                return new AtomicBooleanDeserializer();
            }
            if (rawType == ByteBuffer.class) {
                return new ByteBufferDeserializer();
            }
        }
        return null;
    }

Fixed code:
public static JsonDeserializer<?> find(Class<?> rawType, String clsName)
    {
        if (_classNames.contains(clsName)) {
            JsonDeserializer<?> d = FromStringDeserializer.findDeserializer(rawType);
            if (d != null) {
                return d;
            }
            if (rawType == UUID.class) {
                return new UUIDDeserializer();
            }
            if (rawType == StackTraceElement.class) {
                return new StackTraceElementDeserializer();
            }
            if (rawType == AtomicBoolean.class) {
                // (note: AtomicInteger/Long work due to single-arg constructor. For now?
                return new AtomicBooleanDeserializer();
            }
            if (rawType == ByteBuffer.class) {
                return new ByteBufferDeserializer();
            }
            if (rawType == Void.class) {
                return NullifyingDeserializer.instance;
            }
        }
        return null;
    }
File: src/main/java/com/fasterxml/jackson/databind/ObjectReader.java
Issue: Change of behavior (2.8 -> 2.9) with `ObjectMapper.readTree(input)` with no content
So, it looks like `readTree()` methods in `ObjectMapper`, `ObjectReader` that take input OTHER than `JsonParser`, and are given "empty input" (only white-space available before end), will

* Return `NullNode` (Jackson 2.x up to and including 2.8)
* Return `null` (Jackson 2.9)

Latter behavior is what `readTree(JsonParser)` has and will do; but this accidentally changed other methods due to refactoring that unified underlying call handling (and add checking for new `DeserializationFeature.FAIL_ON_TRAILING_TOKENS`). 
Behavior for this edge case was not being tested, apparently.

Now: since behavior has been changed for all 2.9.x patch versions, I am not sure it should be changed for 2.9 branch. But it seems sub-optimal as behavior, and something to definitely change for 3.0... but probably also for 2.10.

There are multiple things we could do.

1. Change it back to 2.8, to return `NullNode`
2. Change to throw exception, as "not valid" use case
3. Change it to return `MissingNode`
4. Leave as-is, for rest of 2.x.

Although it might seem best to revert it to (1), that seems somewhat wrong, problematic, as it would now not be possible to distinguish between JSON `null` value and missing content.
And although (2) would probably make sense, if designing API from scratch, it is probably too intrusive.

So I think (3) is the best way: it avoids returning `null` or throwing Exception (both being likely to break 2.9 code), but still allows distinguishing between all possible input cases.






Buggy code:
@SuppressWarnings("unchecked")
    @Override
    public <T extends TreeNode> T readTree(JsonParser p) throws IOException {
        return (T) _bindAsTree(p);
    }

Fixed code:
@SuppressWarnings("unchecked")
    @Override
    public <T extends TreeNode> T readTree(JsonParser p) throws IOException {
        return (T) _bindAsTreeOrNull(p);
    }
File: src/main/java/com/fasterxml/jackson/databind/introspect/AnnotationMap.java
Issue: Annotation bundles ignored when added to Mixin
When updating from v 2.4.4 to 2.5.* it appears as though annotation bundles created with @JacksonAnnotationsInside are ignored when placed on a mixin.  Moving the annotation bundel to the actual class seems to resolve the issue.  Below is a simple test that attempts to rename a property.  I have more complicated test cases that are also failing but this should provide some context.
public class Fun {

    @Test
    public void test() throws JsonProcessingException {
        ObjectMapper mapper = new ObjectMapper().addMixIn(Foo.class, FooMixin.class);
        String result = mapper.writeValueAsString(new Foo("result"));
        Assert.assertEquals("{\"bar\":\"result\"}", result);
    }

    @Target(value={ ElementType.CONSTRUCTOR, ElementType.FIELD, ElementType.METHOD })
    @Retention(value=RetentionPolicy.RUNTIME)
    @JacksonAnnotationsInside
    @JsonProperty("bar")
    public @interface ExposeStuff {

    }

    public abstract class FooMixin {
        @ExposeStuff
        public abstract String getStuff();
    }

    public class Foo {

        private String stuff;

        Foo(String stuff) {
            this.stuff = stuff;
        }

        public String getStuff() {
            return stuff;
        }
    }
}
I'm expecting the "stuff" property to be serialized as "bar".
I apologize I haven't been able to identify the culprit (and perhaps it's in my usage).  Let me know your thoughts. I'm always happy to provide more details!

Buggy code:
protected final boolean _add(Annotation ann) {
    if (_annotations == null) {
        _annotations = new HashMap<Class<? extends Annotation>,Annotation>();
    }
    Annotation previous = _annotations.put(ann.annotationType(), ann);
    return (previous != null) && previous.equals(ann);
}

Fixed code:
protected final boolean _add(Annotation ann) {
    if (_annotations == null) {
        _annotations = new HashMap<Class<? extends Annotation>,Annotation>();
    }
    Annotation previous = _annotations.put(ann.annotationType(), ann);
    return (previous == null) || !previous.equals(ann);
}
File: src/main/java/com/fasterxml/jackson/databind/type/TypeFactory.java
Issue: Force value coercion for java.util.Properties, so that values are Strings
Currently there is no custom handling for java.util.Properties, and although it is possible to use it (since it really is a Map under the hood), results are only good if values are already Strings.
The problem here is that Properties is actually declared as Map<String,Object>, probably due to backwards-compatibility constraints.
But Jackson should know better: perhaps by TypeFactory tweaking parameterizations a bit?

Buggy code:
private JavaType _mapType(Class<?> rawClass)
{
    // 28-May-2015, tatu: Properties are special, as per [databind#810]
    JavaType[] typeParams = findTypeParameters(rawClass, Map.class);
    // ok to have no types ("raw")
    if (typeParams == null) {
        return MapType.construct(rawClass, _unknownType(), _unknownType());
    }
    // but exactly 2 types if any found
    if (typeParams.length != 2) {
        throw new IllegalArgumentException("Strange Map type "+rawClass.getName()+": can not determine type parameters");
    }
    return MapType.construct(rawClass, typeParams[0], typeParams[1]);
}

Fixed code:
private JavaType _mapType(Class<?> rawClass)
{
    // 28-May-2015, tatu: Properties are special, as per [databind#810]
    if (rawClass == Properties.class) {
        return MapType.construct(rawClass, CORE_TYPE_STRING, CORE_TYPE_STRING);
    }
    JavaType[] typeParams = findTypeParameters(rawClass, Map.class);
    // ok to have no types ("raw")
    if (typeParams == null) {
        return MapType.construct(rawClass, _unknownType(), _unknownType());
    }
    // but exactly 2 types if any found
    if (typeParams.length != 2) {
        throw new IllegalArgumentException("Strange Map type "+rawClass.getName()+": can not determine type parameters");
    }
    return MapType.construct(rawClass, typeParams[0], typeParams[1]);
}
File: src/main/java/com/fasterxml/jackson/databind/node/ObjectNode.java
Issue: Presence of PropertyNamingStrategy Makes Deserialization Fail
I originally came across this issue using Dropwizard - https://github.com/dropwizard/dropwizard/issues/1095.  But it looks like this is a Jackson issue.  Here's the rerproducer:

``` java
public class TestPropertyNamingStrategyIssue {
  public static class ClassWithObjectNodeField {
    public String id;
    public ObjectNode json;
  }

  @Test
  public void reproducer() throws Exception {
    ObjectMapper mapper = new ObjectMapper();
    mapper.setPropertyNamingStrategy(PropertyNamingStrategy.LOWER_CASE);
    ClassWithObjectNodeField deserialized =
        mapper.readValue(
            "{ \"id\": \"1\", \"json\": { \"foo\": \"bar\", \"baz\": \"bing\" } }",
            ClassWithObjectNodeField.class);
  }
}
```

Looks like the presence of any PropertyNamingStrategy make deserialization to ObjectNode fail.  This works fine if I remove the property naming strategy.


Buggy code:
public JsonNode setAll(Map<String,? extends JsonNode> properties)
    {
        for (Map.Entry<String,? extends JsonNode> en : properties.entrySet()) {
            JsonNode n = en.getValue();
            if (n == null) {
                n = nullNode();
            }
            _children.put(en.getKey(), n);
        }
        return this;
    }

Fixed code:
@JsonIgnore // work-around for [databind#815]
    public JsonNode setAll(Map<String,? extends JsonNode> properties)
    {
        for (Map.Entry<String,? extends JsonNode> en : properties.entrySet()) {
            JsonNode n = en.getValue();
            if (n == null) {
                n = nullNode();
            }
            _children.put(en.getKey(), n);
        }
        return this;
    }
File: src/main/java/com/fasterxml/jackson/databind/cfg/BaseSettings.java
Issue: Configuring an ObjectMapper's DateFormat changes time zone when serialising Joda DateTime
The serialisation of Joda DateTime instances behaves differently in 2.6.0 vs 2.5.4 when the ObjectMapper's had its DateFormat configured. The behaviour change is illustrated by the following code:
public static void main(String[] args) throws JsonProcessingException {
    System.out.println(createObjectMapper()
            .writeValueAsString(new DateTime(1988, 6, 25, 20, 30, DateTimeZone.UTC)));
}

private static ObjectMapper createObjectMapper() {
    ObjectMapper mapper = new ObjectMapper();
    mapper.registerModule(createJodaModule());
    mapper.configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false);
    System.out.println(mapper.getSerializationConfig().getTimeZone());
    mapper.setDateFormat(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));
    System.out.println(mapper.getSerializationConfig().getTimeZone());
    return mapper;
}

private static SimpleModule createJodaModule() {
    SimpleModule module = new SimpleModule();
    module.addSerializer(DateTime.class, new DateTimeSerializer(
            new JacksonJodaDateFormat(DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss")
                    .withZoneUTC())));
        return module;
    }
When run with Jackson 2.5.4 the output is:
sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
"1988-06-25 20:30:00"

When run with Jackson 2.6.0 the output is:
sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
sun.util.calendar.ZoneInfo[id="Europe/London",offset=0,dstSavings=3600000,useDaylight=true,transitions=242,lastRule=java.util.SimpleTimeZone[id=Europe/London,offset=0,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]]
"1988-06-25 21:30:00"

It looks like the fix for #824 is the cause. In 2.6, the call to mapper.setDateFormat causes the ObjectMapper's time zone to be set to the JVM's default time zone. In 2.5.x, calling mapper.setDateFormat has no effect on its time zone.

Buggy code:
public BaseSettings withDateFormat(DateFormat df) {
    if (_dateFormat == df) {
        return this;
    }
    TimeZone tz = (df == null) ? _timeZone : df.getTimeZone();
    return new BaseSettings(_classIntrospector, _annotationIntrospector, _visibilityChecker, _propertyNamingStrategy, _typeFactory,
            _typeResolverBuilder, df, _handlerInstantiator, _locale,
            tz, _defaultBase64);
}

Fixed code:
public BaseSettings withDateFormat(DateFormat df) {
    if (_dateFormat == df) {
        return this;
    }
    return new BaseSettings(_classIntrospector, _annotationIntrospector, _visibilityChecker, _propertyNamingStrategy, _typeFactory,
            _typeResolverBuilder, df, _handlerInstantiator, _locale,
            _timeZone, _defaultBase64);
}