Support Vertx Future

[codingxu97]

Future in Vertx 4 was useful enough, I thought that it was better to use official component than others IMHO.

@Override
public <T> T unwrap(Class<T> type) {
	if ( type.isAssignableFrom(Stage.SessionFactory.class) ) {
		return type.cast( new StageSessionFactoryImpl( this ) );
	}
	if ( type.isAssignableFrom(Mutiny.SessionFactory.class) ) {
		return type.cast( new MutinySessionFactoryImpl( this ) );
	}
	return super.unwrap(type);
}

[codingxu97]

Hi, @DavideD !

Was there any plan for this issue? I thought that Vert.x Future was useful enough. I've even implemented this feature based on the source code of Mutiny Uni, just to test in my project. Maybe Vert.x Future could be used as an option in some simple scenario.

[DavideD]

I don't think we had short term plans to add Future but our API is designed to support different facades, so it's not hard per se.

Would it make it easier to work with Vert.x? I guess one wouldn't need to convert a Uni or CompletionStage to a Promise/Future when using Verticles.

If you already have an example you could send a draft PR so that we can see what it looks like.
Maybe you could also add a FutureSessionTest adapting the existing MutintySessionTest or a part of it so that we can have an idea.

@gavinking Any opinion about this?

[DavideD]

Sounds like a nice idea though :-)

[gavinking]

I mean, I'm not against it, if it's useful...

[codingxu97]

Maybe I was used to using Vert.x Future, I will try to add a Test before sending a draft PR.

[DavideD]

@codingxu97 Basically, we need a compelling use case.

That's because once we add something to the project we have to maintain it.

[codingxu97]

Hi, @DavideD !

I'd thought a lot about this issue, and made some attempts.

The projects were only based on Vert.x and other lightweight library in our team, Vert.x Future was enough for us to finish our project, so we didn't use Mutiny or other Reactive library.

But, we have to use Mutiny if we choose Hibernate Reactive, There would be two different reactive code styles in our project. it seems messy, and might be difficult to manage. It would bring huge workload, if we switch all code to Mutiny, even a lot of potential bugs.

On the other hand, Class Future was in Vert.x core Library, so it did't have to import a new jar in order to implement this.

These were some of my humble opinion, thanks!

[DavideD]

You don't have to use Mutiny, you could use CompletionStage. Without changing Hibernate Reactive, you need a facade for Stage.SessionFactory and Stage.Session.

It would actually be easier to do in your project, because you can only delegate the methods that you need. If we add it to Hibernate Reactive, we need to add a lot more code.
Ideally, it should be possible to register the new interfaces without changing the code base of Hibernate Reactive, but I haven't actually tried and I don't know if it works in practice.

This would be equivalent to what we would do in Hibernate Reactive anyway, because internally we use CompletionStage.
You can see this in MutinySessionImpl: we have a delegate returning CompletionStage and we convert the result to Uni.

The reason we are using CompletionStage internally is because we didn't want to be bound to a particular library.
The reason we suggest using Mutiny is because we think the API is better and easier to use.
Maybe we should make the dependency to Mutiny optional.

[DavideD]

I'm going to close this issue because I don't think we are going to do it.
But I've created #1200 that should address this one as well.