-
Notifications
You must be signed in to change notification settings - Fork 134
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
!str Make flatMapPrefix javadsl using java.util.List #271
base: main
Are you sure you want to change the base?
Conversation
A 1.1.0 change for me and we should continue to include the Old API and deprecate it. |
I think it's source compatible(if lambda is being used), and can't have both because they are the same after being erased. |
@He-Pin @pjfanning So I just noticed this and its kind of annoying because if we do need to do this then it kind of should be done now but I would like more context as to why this is problematic in Java. @He-Pin What exactly is the issue here from Java's side in using Maybe this calls for adding some helper functions to |
I think it is too late to do this in 1.0.0. I really thought we were ready for a 1.0.0 RC and to sneak in changes like this and force us to go through even more testing. I am not too sure we need the change at all - Iterable is an ok return type - I don't see the major benefit and then we have the cost of the API disruption. |
Yeah I want to avoid sneaking this in as well unless it really has ramifications further down the line which is why I want context as to what problem we are solving. If by "easer to work in Java" we just mean saving some lines of code when converting from |
@mdedetrich With List type, it can gives you more methods to be accessible. i come up it with real production code which i have to do a cast instead. And as this is not a binary compatible change after release of 1.0.0 |
I am very much against a 1.0.0 change. I don't think this change justifies delaying the release. It is an API change and I think the majority of Pekko community users just want an Akka like release. |
I have to say it's a mistake when it's Java.lang.Iterable, it should be Java.util.List instead as what we said in the contribution guide. And if it's not landing in 1.0.0, it may never have a chance anymore. |
@mdedetrich It instead liberating the usage on Java side. And prefixAndTail is using java.util.List too, just as the contribution guide. |
We've had months to discuss. Why choose the absolute last minute before the release to discuss this? Akka users have used the existing API for years. I do not understand why this is so important to change in Pekko. The Pekko community seemed to have an agreement to try to get an Akka like release done and to follow up with bigger changes in 1.1.0. We really have to release soon. The Akka CVEs that they are refusing to open source means that there are Akka users who want a quick Pekko release so that they can use a CVE-free alternative. |
This change will not affect who using lamda, but those who using Function Constant. If it has to take long time to discuss, i think we can defer it to next major version, but it still a inherented mistake with using Java.lang.Iterable. |
I would support a 1.1.0 change. There are other places in the code that use Function of Iterable and they should be considered to be changed too - I found 6 and this PR just changes 2. |
@pjfanning PLS reschedule it, i'm away from computer. |
If we do breaking API changes that would need to be 2.0.0 according to semver. The easiest option would be to come up with a different method name and deprecate the older one. |
@pjfanning On this point, should I make a thread on the mailing list talking about semver? I did PR's in the projects setting the versioning scheme of the projects to semver but it sounds a lot of people are not aware of this (either by what semver means or the fact that we follow semver at all). |
@mdedetrich I'd like to keep the mailing threads focused on the release - semver can be discussed at any time. I would be shocked if many people don't expect us to follow semver principles. I think this issue can be fixed at any time by adding new methods and not trying to change the existing ones. A new method could be called |
@pjfanning The thing is, semver is very black and white since we have https://github.com/apache/incubator-pekko/blob/main/build.sbt#L17. Thats why I am bringing this up, if you have The reason why I set that is that Akka follows semver which Pekko was meant to follow and this setting makes it official.
If we decide to do this then its fine ( There are other points that you raised like pekko-connectors, i.e. there is an argument that pekko-connectors probably shouldn't follow semver because of how frequently they change and more importantly how historically frequent those changes have technically broken ABI |
pekko-connectors has docs stating that it is subject to change. pekko core libs have been stable for a long time. We should enable the mima filter checks soon after the 1.0.0 release. Any time we have to add an exception to the mima checks is a very very sad day and should be signed off by the community. And the next release number should be controlled by those binary compatible changes. Any major breakages mean that we need a major release. |
In that case
That means we are going to follow semver.
In that case we either change the function now or add another method name, the latter being much more appealing since it also provides an upgrade path. Regarding new method name, I think that flatMapTakeAndApply` is a good candidate, and is arguably better than the current name in describing what the function actually does. |
I'm begging - can we stop discussing adding a change for this now? We can add a change later - and one that doesn't break binary or source compatibility. The community wants a release. This is not a critical issue. I have never come across a scenario where minor issues are turned into release blockers at the very last minute before a release. We can do a v1.0.1 with an additional API in a few months. |
I never said we should add the change now. I am saying we should be clear about semver, that's it. And the discussion was needed because adding semver to pekko-connectors was a mistake, one that could have been easily forgotten and create a lot of harm/chaos to users. It was suggested earlier to add a breaking change in 1.1.0, I am saying we should not do that. I came up with alternate names if @He-Pin wants to update the PR with an added method and if he follows that course of action its obviously not a priority, it can be done whenever. |
With semver, we may want a mail thread but can we exclude pekko and pekko-http? I think it is fair to say that those 2 libs are very stable and the whole community expects strict semver. These projects are also used by many downstream libs so binary incompatible changes will have big negative impacts. There are questions about the rest of the Pekko repos. You could argue that we impose strict semver now and ramp up version numbers if we have to make binary incompatible changes in future releases. Or we say that 1 or 2 of the repos are still unstable and we can't impose strict semver on them. All in all, binary incompatible changes outside of pekko and pekko-http will have more limited impacts that those for pekko and pekko-http. |
I agree with that, possible pekko-grpc ontop of that as well
I am making a PR to remove semver from pekko-connectors because after skimming through the history, its kind of delusional for it to ever realistically follow semver due to the fact that it supports so many artifacts (via different connectors) inside a single mono repo with a single version (if it did follow semver it would break the major so often that the semver becomes pointless). There is an argument to be made here whether we should gradually split out the connectors into their own versions/repos, but not one that should be had now especially with the amount overhead separate git repos create. As you pointed out, we have bigger fish to fry (i.e. a release). With the other repos we can evaluate on a case by case basis, a lot of them aside of connectors seem quite stable so the risk is lower but it should be looked into properly. |
@pjfanning @mdedetrich Can we do this in the 1.1.0 version? |
Even though the function parameter is an iterable, we passed a Seq while invoking it,and I checked the relevant tests and found that they were all |
I remain -1 on changing the request signature of the method. We can add new methods and deprecate the old ones. |
What about the new method name? |
Thinking about it again, it might be worth keeping the flatMapPrefix without deprecating it - users of Sets and classes like that might still want to use the method. How about calling the new method |
@pjfanning |
@mdedetrich do you have any preferences for function names here? My preference is have something similar to the existing API name (flatMapPrefix). I think it would be confusing to use a different name for the new functions. |
|
I think this change should be binary compatible too, as the function is erased to function[any,any]
|
This will make it easier to work with in Java. And the scaladsl was
seq