Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Make ExecutionContext extends Executor by default? #12665

Open
He-Pin opened this issue Oct 14, 2022 · 3 comments
Open

[Feature request] Make ExecutionContext extends Executor by default? #12665

He-Pin opened this issue Oct 14, 2022 · 3 comments
Milestone

Comments

@He-Pin
Copy link
Contributor

He-Pin commented Oct 14, 2022

Currently there is only ExecutionContextExecutor which does this, but when a method accepts ExecutionContext, then it's not that easy to use it in Java, because In Java, we usually use Executor.

@lrytz
Copy link
Member

lrytz commented Nov 7, 2022

I'm not qualified to have an opinion here, but it seems a reasonable thing to discuss at least.

But we won't be able to do it in the 2.13 standard library for binary compatibility reasons. Since 2.14 is not planned, this could only happen with Scala 3.T (or 4.0), a future version that will break binary compatibility - we don't know when this is going to happen.

@SethTisue where do we store such ideas?

@som-snytt
Copy link

It seems the distinction was intended, but I haven't had a chance to look further.

Executor doc is agnostic on behavior; ExecutionContext says specialized implementations may be sync.

I wonder if I'd understand more if I knew what prepare was originally for.

For this issue, my other question was whether a Java-oriented API should just use Executor.

We will have to add a scala-concurrent-next dependency to Apache Pekko.

@SethTisue SethTisue self-assigned this Jan 13, 2023
@SethTisue SethTisue added this to the 3.x milestone Jun 13, 2023
@SethTisue SethTisue removed their assignment Jun 13, 2023
@SethTisue
Copy link
Member

SethTisue commented Jun 13, 2023

@SethTisue where do we store such ideas?

for now I've left this ticket here and put it on the 3.x milestone, which is one of several buckets we have for such issues

see my remarks at scala/scala-dev#661 (comment) about our lack of a clear approach to this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants