vavr-io/vavr

Functional component library for Java 8+.

Nándor Előd Fekete

@nfekete

If you're calculating something cheap, it's probably better to just recalculate it every time, as memoization is costly in terms of memory use and further iterations will be costly because of memory access, which might be much higher than just recalculating something cheap.

No, Iterator is not a lightweight implementation of Stream. Please try to be more precise with formulating these statements.

I use Iterator when I need to do one-shot calculation on a collection of elements. I usually collect the results if I need to reuse them later. I rarely use the memoizing vavr Stream or transformations on eager collections. But there are use cases for those as well, and they are good choices in some circumstances.

Gopal S Akshintala

@overfullstack

Sorry, I don’t mean Iterator is implementation of Stream… I see both have same intent (looping thorugh elements) but different implementations (in terms of how they do it)… I see Iterator is less costlier (light weight) than Stream (Both from VAVR), for one-shot calculation

Nándor Előd Fekete

@nfekete

Yes, Iterator is mostly for one-shot iterations. Stream is actually a lazy collection, so it has much more uses than just one-shot iterations. Remember that it actually stores your elements (lazily) and it's immutable. So you can reuse it as many times as you want.

Gopal S Akshintala

@overfullstack

Awesome! Thanks @nfekete alot :)

Nándor Előd Fekete

@nfekete

@overfullstack you're welcome

Mark Raynsford

@io7m

'ello. is there a sorted map/multimap structure in vavr that allows for efficient (as in not O(n)) range queries like java.util.NavigableMap's subMap methods?

i can't tell if i'm looking straight at them and not seeing them..

Mark Raynsford

@io7m

i see there's a PR vavr-io/vavr#1317 although i'm not entirely clear if the resolution of that meant that the commits made it into a 1.0.0 alpha...

Daniel Dietrich

@danieldietrich

Hi Mark, no, it did not made it into the lib. Adding the interfaces was trivial. But the change needs me to reworks Red/Black Tree a bit which did not take place, yet.

Mark Raynsford

@io7m

ok, thanks

Jakob Brünker

@JakobBruenker

Hey, quick question: With Value.toJavaOptional being deprecated, is there an alternative method that should be used to convert Option to Optional?

Jakob Brünker

@JakobBruenker

I suppose fold(Optional::empty, Optional::of) works

Daniel Dietrich

@danieldietrich

@JakobBruenker please stay tuned. We are still 1.0.0-alpha. The conversion methods will be moved to Try, Option, Either et al. Reworking isn‘t finished, yet.

Jakob Brünker

@JakobBruenker

Cool, thanks

Jakob Brünker

@JakobBruenker

One more thing, it looks like the vavr-match link on the website links to https://github.com/vavr-io/vavr instead of https://github.com/vavr-io/vavr-match

same with vavr-test, actually

Daniel Dietrich

@danieldietrich

thanks for the hint! I will fix that

Kaiyin Zhong

@kindlychung

Does vavr work well with graalvm's native-image?

Daniel Dietrich

@danieldietrich

@kindlychung We did not test it, yet. I see no reason it should not work. We have zero dependencies(!) and only use standard Java features in our implementation. Please share your insights with us!

Jakob Brünker

@JakobBruenker

I'm thinking of adding vavr to an existing, reasonably big springboot project - but it seems springboot automatically adjusts spring data methods to target vavr types if vavr is added as a maven dependency. Anyone know if there's a way to turn that off, so that I can leave existing code as is and only use vavr for new code?
(Admittedly this seems like it's more of a question for the spring community, but I thought someone here might know)

Bob Glamm

@glammr1

I think Spring Data uses the actual types in the repository interface's method signatures, not automatic conversion

We have Vavr in Spring Boot projects and none of the existing types are overridden

Jakob Brünker

@JakobBruenker

Hm, okay.. I get a bunch of Exceptions as soon as I add vavr as a dependency that say

java.lang.IncompatibleClassChangeError: Method io.vavr.control.Option.none()Lio/vavr/control/Option; must be Methodref constant

It seems like that shouldn't be happening if that's true? Maybe I'm misunderstanding something though

I guess I should test with an empty project first anyway to see what's actually breaking it

Bob Glamm

@glammr1

That sounds like the wrong Java version is being used

sorry, let me rephrase: I think the Vavr dependency requires a specific minimum version of Java and the version of Java used is incompatible with it

Jakob Brünker

@JakobBruenker

Okay, I'll see if I can't figure out how to check which version of Java maven uses and how to change it (I'm not actually very familiar with maven)

it says it's using Java version: 11.0.4

I wouldn't expect vavr to require a newer version than that?

Nándor Előd Fekete

@nfekete

IncompatibleClassChangeError: Thrown when an incompatible class change has occurred to some class definition. The definition of some class, on which the currently executing method depends, has since changed.

do you have a clean build compiled against the vavr version that is being used at runtime?

Jakob Brünker

@JakobBruenker

Yes, the exceptions occur in the automated tests that are run after building

uh, it seems to work if I use an older version of vavr though, I think

I tried the newest 1.0.0 alpha before, now I'm using 0.9.0

Jakob Brünker

@JakobBruenker

And 0.10.2 works as well (I can successfully run System.out.println(Some.of("hello")) and then run the rest of the program without exceptions)

Nándor Előd Fekete

@nfekete

1.0.0 line is/was an incompatible experimental line for the future version of vavr, and it's in a pre-alpha stage, not intended to be used in pretty much any way

Jakob Brünker

@JakobBruenker

okay, fair enough

Nándor Előd Fekete

@nfekete

I think it was a mistake to even publish it

but nevertheless, you should have your code compiled against the same version that you'll be using at runtime

Jakob Brünker

@JakobBruenker

okay

Daniel Dietrich

@danieldietrich

The newest 1.0.0-alpha should be compatible to 0.10.x. However, we switched from Maven to Gradle. The tests target java 11, vavr targets java 8. The test target will be fixed to be java 8.

Jakob Brünker

@JakobBruenker

Are you saying that that is likely where the problem came from? (To be clear, when I was talking about tests I meant the tests of the project, not vavr tests)

Daniel Dietrich

@danieldietrich

okay, I confused it. please stick to 0.10.x until spring-data depends on vavr 1.0.0.

Jakob Brünker

@JakobBruenker

okay

While I'm here, another question: Is there a preferred choice between Option(c) and Option.some(c)if it's guaranteed that c is not null?

Daniel Dietrich

@danieldietrich

Option(c) is Scala-like syntax. Option.some(c) is more Java conform.

Jakob Brünker

@JakobBruenker

okay, that makes sense, though I suppose I was more thinking of the semantic difference between explicitly creating a some vs it. being implicitly a some because c is not null (as would also apply to Option.of)

I don't necessarily expect there to be a coding style recommendation here, but I thought I'd check

Where communities thrive

People

Repo info

Activity