immutables / immutables-vavr

Immutables encodings for Vavr

immutables-vavr

A set of Immutables encodings for Vavr.

Note: Prior to a 1.0.0 release, the encodings are still in the experimental phase and therefore should not be relied upon to provide a stable API.

JVM	Platform	Status
OpenJDK LTS	Linux
OpenJDK Current	Linux
OpenJDK Current	Windows

Ten Second Tutorial

Include the encodings in your project:

<dependency>
  <groupId>org.immutables.vavr</groupId>
  <artifactId>vavr-encodings</artifactId>
  <version><!-- Insert latest version here --></version>
  <scope>provided</scope>
</dependency>

Annotate your types with @VavrEncodingEnabled. Alternatively, you can annotate a @Style annotation with @VavrEncodingEnabled and have it apply to any types that are using that style. See Styles.

Now, any use of Vavr collections in your abstract value types will magically result in the generated Builder types being augmented with methods to build immutable collections element-by-element. Use of Vavr's Option type will receive the same special treatment as the standard Java Optional type.

immutables-vavr's Issues

Group name is redundant

Move the Maven groupId org.immutables.immutables-javaslang to org.immutables.javaslang.

Add builder methods for Either

Provide builder methods that allow for setting the left and right values of Either-typed attributes.

Migrate to Github Actions

We're still using Travis CI. This must end!

Publish as a Java 9 module

Depends on:

https://github.com/vavr-io/vavr/milestone/32
immutables/immutables#713

Top-level meta annotation doesn't work

The sources currently contain an annotation that attempts to aggregate the other annotations:

https://github.com/immutables/immutables-javaslang/blob/develop/immutables-javaslang-encodings/src/main/java/org/immutables/javaslang/encodings/JavaslangEncodingEnabled.java

Unfortunately, when applied directly to a type:

https://github.com/immutables/immutables-javaslang/blob/develop/immutables-javaslang-examples/src/main/java/org/immutables/javaslang/examples/ExampleMiscellaneousType.java

... nothing happens! The type does not behave as if it was annotated with all the constituent annotations.

@elucash: Any idea what's going on here? Perhaps I misunderstood what you meant by meta annotation.

NullPointerException in equals(), hashCode() and toString() with @Nullable Vector.

I am creating an Immutable POJO object which needs to support an @Nullable Vector and the toString(), equals() and hashCode() methods are throwing NPEs because they assume the vector will never be null.

Most of the time this isn't an issue because I don't let the Vectors be nullable, but I now have a situation where it is not avoidable. I have worked around it by overriding those three methods, but this is something that I feel should be fixed in the "org.immutables.vavr:vavr-encodings" artifact (i.e. this project).

Thanks for all you do.

Compilation error with maps and lists

https://github.com/io7m/immutables-javaslang-bug-20161226

The generated code ends up as:

  private SMFHeader(SMFHeader.Builder builder) {
    this.schemaIdentifier = builder.schemaIdentifier;
    this.coordinateSystem = builder.coordinateSystem;
    this.attributesInOrder = builder.this.attributesInOrder_list;
    this.attributesByName = builder.this.attributesByName_map;
    if (builder.triangleCountIsSet()) {
      initShim.setTriangleCount(builder.triangleCount);
    }
    if (builder.triangleIndexSizeBitsIsSet()) {
      initShim.setTriangleIndexSizeBits(builder.triangleIndexSizeBits);
    }
    if (builder.vertexCountIsSet()) {
      initShim.setVertexCount(builder.vertexCount);
    }
    if (builder.metaCountIsSet()) {
      initShim.setMetaCount(builder.metaCount);
    }
    this.triangleCount = initShim.triangleCount();
    this.triangleIndexSizeBits = initShim.triangleIndexSizeBits();
    this.vertexCount = initShim.vertexCount();
    this.metaCount = initShim.metaCount();
    this.initShim = null;
  }

[ERROR] /home/someone/git/com.github/io7m/immutables-javaslang-bug-20161226/target/generated-sources/annotations/com/io7m/bugs/immutables_javaslang/SMFHeader.java:[53,30] cannot find symbol
  symbol:   class builder
  location: class com.io7m.bugs.immutables_javaslang.SMFHeader
[ERROR] /home/someone/git/com.github/io7m/immutables-javaslang-bug-20161226/target/generated-sources/annotations/com/io7m/bugs/immutables_javaslang/SMFHeader.java:[54,29] cannot find symbol
  symbol:   class builder
  location: class com.io7m.bugs.immutables_javaslang.SMFHeader

I suspect the generated code should be builder and not builder.this.

@elucash: Is this one a bug in the immutables generator, or in the encodings here?

Make VavrMapEncoding consistent with immutables naming

VavrMapEncoding adds Entry prefix for tuple related operations.
Current solution has some drawbacks:

• it isn't configurable
• it isn't consistent with immutables encoding ( it generates putBar(Map.Entry<? extends K, ? extends V>) method )
• matter of taste, but in my opinion "Entry" doesn't add any value and makes builder too verbose

How about replacing:

@Encoding.Naming(value = "putEntry*", depluralize = true)
with
@Encoding.Naming(standard = Encoding.StandardNaming.PUT)

@Encoding.Naming(value = "setEntries*")
with
@Encoding.Naming(standard = Encoding.StandardNaming.PUT_ALL)
?

Also, I would consider replacing
@Encoding.Naming(value = "setJavaMap*")
with
@Encoding.Naming(standard = Encoding.StandardNaming.PUT_ALL)

Jackson encoding is broken

There is an issue when using immutables-vavr and vavr's jackson encoding. For example:

@Value.Immutable
@VavrEncodingEnabled
@JsonSerialize
@JsonDeserialize
public interface Foo {
    Option<String> bar();
}

Produces the compilation error:

Error:java: Could not generate constructor. Attribute 'bar' does not have default value.

If I specify a default value, the error disappears, but I lose the special treatment that vavr encoding gives me in the builder. This seems to be an incompatbility between the two modules.

This issue is related to this one, where their workaround is to define a custom encoding for vavr types, replacing whatever immutables-vavr brings to the table.

Option type fields allow nulls

Expected behaviour:
A field typed with Option will throw a NullPointerException if you attempt to set null on an immutable object's field using the appropriate .withSomeValue(null) method.

Actual behaviour:
The field will be set with Some(null) and no exception will be thrown.

I'm not actually 100% sure this is a bug but it's inconsistent with the behaviour for java.lang.Optional fields: those will throw an exception if you try to set a null. It's also in my opinion less safe: Some(null) is highly unexpected.

The vavr library itself supports Some(null) deliberately, which has had some significant previous discussion. I'm not sure if this applies to this library though.

I'll write a minimal reproduction of the issue if it helps.

Correct module name

The module name is currently vavr.encodings and should actually be org.immutables.vavr.encodings.

@Value.Default with Option-fields throws NullPointerException

@Value.Default with Option fields throws NullPointerException:

   @Value.Default
   public Option<String> getFoo() {
      return Option.some("foo");
   }

error: org.immutables.value.internal.$processor$.$Processor threw java.lang.NullPointerException
        at org.immutables.value.internal.$processor$.encode.$Instantiation$6.invoke($Instantiation.java:305)
        at org.immutables.value.internal.$generator$.$Intrinsics.$($Intrinsics.java:96)
        at org.immutables.value.internal.$processor$.encode.$Generator_Renderers._t26__wasInit($Generator_Renderers.java:845)
        at org.immutables.value.internal.$processor$.encode.$Generator_Renderers$FragmentDispatch.run($Generator_Renderers.java:1167)

org.immutables:value:2.7.4
org.immutables.vavr;vavr-encodings:0.6.2

Make Option's "with" method behaviour consistent with builder logic

Option's logic when creating object and when using "with" generated method are inconsistent.

Consider this test class:

@VavrOptionEncodingEnabled
@Value.Immutable
interface TestObject {

  Option<Integer> option();
}

This test yields:

ImmutableTestObject testObject = ImmutableTestObject.builder()
  .option((Integer) null)
  .build();

Assert.assertEquals(testObject, testObject.withOption((Integer) null));

expected:<TestObject{option=None}> but was:<TestObject{option=Some(null)}>

I've created pull request to fix it:
#25

Rename project to immutables-vavr?

http://blog.vavr.io/javaslang-changes-name-to-vavr/

Customized with() methods

Can we add customized with methods as explained in the immutables docs: "Customize with methods"?

e.g. for a Set we could add with methods like these:

public final ImmutableExampleSetType withIntegers(Integer... elements) {}
public final ImmutableExampleSetType withIntegers(Iterable<? extends Integer> elements) {}

I've already tried this in a new branch of my fork. See this commit

Options appearing wierdly in builder

When I have an Option as a field in a data structure and I put both @Value.Immutable and @VavrEncodingEnabled, the builder that is generated requires knowing that the field is optional when constructing it. For example

@Value.Immutable
@VavrEncodingEnabled
public interface Example {
    Option<String> thing();
}

generates a builder like this

public final Builder from(Example instance) {
  Objects.requireNonNull(instance, "instance");
  thing(instance.thing());
  return this;
}

public Builder thing(Option<String> opt) {
  this.thing_optional = opt;
  return this;
}

public Builder setValueThing(String x) {
  this.thing_optional = Option.of(x);
  return this;
}

public Builder unsetThing() {
  this.thing_optional = Option.none();
  return this;
}

The what I want is for the thing method in the builder to be the same as the setValueThing method, which makes it invisible to the consumer building theImmutableThing that the data structure uses an Option.

Also, feel free to correct any misconceptions I might have about how this should work; at the end of the day not using setValueX might just be preference, but I personally think that it is an interesting design choice.

Question: Why is there no VavrSetEncodingEnabled?

Is it possible to have an encoding for the Set interface: e.g. VavrSetEncodingEnabled?
We have the same for maps: VavrMapEncodingEnabled

Failing builds

It seems like all the builds for this repo have been failing since November. Is this something to be concerned about?

Upload the releases to maven central

It would be great if the artifacts of immutables-vavr would be uploaded to maven central, as somebody looking for this project could then easily use it in his or her project, without having to build the project locally and then upload it to some local artifact repository.

I've found that some early releases were uploaded to some datastax repository, but none of the new releases can be found there.

Multimap needs proper support

Multimaps aren't creating "add" methods in the builder.

PS: Thanks for creating immutables-javaslang(vavr)

Modularize!

Publish JDK 9 modules.

Depends on: As-yet unreleased version of Immutables.org encodings package that contains an Automatic-Module-Name entry.

vavr 1.0.0 is due out soon

These encodings will need to be updated. The 1.0.0 release will not be backwards compatible with previous vavr versions (they've removed a few collections classes).

inhibit-classpath is too aggressive

vavr-encodings has a "classpath fence" configured for Immutables in the META-INF/extensions/org.immutables.inhibit-classpath file. This prevents the Immutables code generator from using any annotations in that package.

I note from the commit comment that this has something to do with Java9 (likely to do with the split package problem in Jigsaw), but this seems like a pretty blunt instrument, and possibly not even necessary (with the current 2.6.x releases of Immutables, anyway - if the attempt to load the annotation class fails, it silently moves on).

Can this inhibitor be removed? If people need to use this for their environment, then they can add the inhibitor themselves. Forcing it on everyone else just to accommodate Java9 seems wrong.

Option builder fields are not generated for Stage builders / values

Thanks a lot for the vavr encoding, they're helping the the transition from javaslang to vavr a lot! 👍

Option<T> fields inside builders marked as stagedBuilder=true does not have appropriate methods generated to BuildFinal interface.

import io.vavr.control.Option;
import org.immutables.value.Value;
import org.immutables.vavr.encodings.VavrEncodingEnabled;

@Value.Immutable
@Value.Style(stagedBuilder = true)
@VavrEncodingEnabled
public interface StagingBuilderTest {

    @Value.Parameter
    Object testParameter();

    Option<Object> testOption();
}

is compiled into

public final class ImmutableStagingBuilderTest implements StagingBuilderTest {
  private final Object testParameter;
  private final Option<Object> testOption;

  // omitted ...

  public interface TestParameterBuildStage {
    BuildFinal testParameter(Object testParameter);
  }

  public interface BuildFinal {
    ImmutableStagingBuilderTest build();
  }
}

with javaslang 2.0.6 it's complied into

public final class ImmutableStagingBuilderTest implements StagingBuilderTest {
  private final Object testParameter;
  private final Option<Object> testOption;

  // omitted ...

  public interface TestParameterBuildStage {
    BuildFinal testParameter(Object testParameter);
  }

  public interface BuildFinal {
    BuildFinal testOption(Object testOption);
    BuildFinal testOption(Option<? extends Object> testOption);
    ImmutableStagingBuilderTest build();
  }
}

This might be issue also for other supported types (not tested though).

Builder.add with VarArgs

Can we change the builder.add method to accept VarArgs?

So instead of

ImmutableExampleSetType.Builder b = ImmutableExampleSetType.builder()
b.addIntegers(Integer.valueOf(0));
b.addIntegers(Integer.valueOf(1));
b.addIntegers(Integer.valueOf(2));

we can additionally use:

ImmutableExampleSetType.builder();
b.addIntegers(Integer.valueOf(0), Integer.valueOf(1), Integer.valueOf(2));

e.g. In a branch of my fork, I've implemented it for Set: see this changeset

BTW: Is there a reason why you use explicit boxing of integer types in your tests?