I've sent in a pull request for this:
https://github.com/apache/geode/pull/1119
I've added the old serialVersionUID to the FunctionAdapter, under the
assumption that anyone in 1.0-1.3 would have seen that the FunctionAdapter
had been deprecated and not used it. The 1.0-1.3 users could also easily
+1 to not removing deprecated apis in minor releases.
The semver policy Alexander describes seems reasonable.
In the past of we have had something deprecated for a long time we have
felt free to remove it whenever we want but I think the semver policy is a
better way to decide when we are free to r
Even though the class is deprecated, you should be able to go from one
minor version to another without having to worry about anything breaking.
The point of semver is to provide information about things breaking or not
without having to read the changelog. If we remove APIs in a minor version
beca
Since the class was deprecated and is technically only there for pre-1.0
compatibly then the behavior of this class should be consistent with the
pre-1.0 version. This will break 1.0 to 1.3 but anyone coding to a post-1.0
version should not be using this deprecated class.
> On Nov 28, 2017, at
*With your proposoal 1.0 - 1.3 users would have modify their source code on
the client and the server forthe function, correct?*
If they start a new geode server 1.4+ and happened to extend
functionAdapter (it was deprecated in 1.0) then they would have to
recompile their client to not use functio
Dan, yeah, the suggested change in the stack overflow answer does work and
I was able to put an if with the exact serialVersionUid before posting the
proposal, but it is pretty hacky and may affect another class that somehow
generated the same uid. I can make that change too but I'd prefer not to
I agree I don't think we can get rid of FunctionAdapter until the next
major version.
I was thinking FunctionAdapter is rather widely used, but then I'm
surprised no one has hit this yet.
All of the options kinda suck here - either pre 1.0 users have a
compatibility issue or 1.0-1.3 users do. Wit
Anil, I am not sure following. I think FunctionAdapter already is
deprecated. Isn't it? Anthony is right though that we shouldn't remove
anything customer facing unless we are doing a major release. Otherwise we
are violating the contract provided by semantic versioning.
On Tue, Nov 28, 2017 at 1:
I haven't seen many uses of FunctionAdapter; if its not used much, I think
we should deprecate this...
It only provided default implementation for few of the methods; this could
be added in the docs/release notes to help application to move to function
implementation.
-Anil.
On Tue, Nov 28, 201
I think we should wait for a major release to remove API’s. If we broke a
public API, we should fix that IMO.
Anthony
> On Nov 28, 2017, at 11:40 AM, Patrick Rhomberg wrote:
>
> +1 to removing a long-deprecated class from the Geode side.
>
> On Tue, Nov 28, 2017 at 8:04 AM, Bruce Schuchardt
+1 to removing a long-deprecated class from the Geode side.
On Tue, Nov 28, 2017 at 8:04 AM, Bruce Schuchardt
wrote:
> How about just getting rid of this class? After all it was marked as
> being deprecated in 1.0. Pivotal could add a compatible FunctionAdapter
> class in their GemFire builds
How about just getting rid of this class? After all it was marked as
being deprecated in 1.0. Pivotal could add a compatible FunctionAdapter
class in their GemFire builds to support these old clients.
On 11/27/17 10:18 AM, Jason Huynh wrote:
This is a discussion for the fix to GEODE-4008:
I
This is a discussion for the fix to GEODE-4008:
InvalidClassException when deserializing FunctionAdapter from pre Geode
clients
There was a change to deprecate FunctionAdapter in Geode (before 1.0), and
this also removed the method signatures in the class. This caused Java to
generate a new serial
13 matches
Mail list logo
