Giter VIP home page Giter VIP logo

immutables-vavr's Introduction

Read full documentation at http://immutables.org

CI

Modern usage style, aka "sandwich"

// Define abstract value type using interface, abstract class or annotation
@Value.Immutable
public interface ValueObject extends WithValueObject {
  // WithValueObject is not yet generated, We extend With* to inherit `with*` method signatures
  String name();
  List<Integer> counts();
  Optional<String> description();

  class Builder extends ImmutableValueObject.Builder {}
  // ImmutableValueObject.Builder will be generated and
  // our builder will inherit and reexport methods as its own.
  // Static nested Builder will inherit all the public method
  // signatures of ImmutableValueObject.Builder
} 

// Use generated immutable implementation and builder
ValueObject v =
    new ValueObject.Builder()
        .name("Nameless")
        .description("present")
        .addCounts(1)
        .addCounts(2)
        .build();

v = v.withName("Doe");

//fetch values via accessors
List<Integer> counts = v.counts();
Optional<String> description = v.description();

ImmutableValueObject then would not be used outside generated type. See about this and other generation styles here

License

   Copyright 2013-2024 Immutables Authors and Contributors

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.

See releases tab for release history. Archived changelog for earlier releases.

immutables-vavr's People

Contributors

elucash avatar io7m avatar kennymacleod avatar mfashby avatar tmtron avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

immutables-vavr's Issues

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

Modularize!

Publish JDK 9 modules.

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

@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

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).

Failing builds

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

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?

Correct module name

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

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.

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.

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.

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.

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.

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.

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.

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)

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).

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?

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.