We can address package changes in the geode-old-client-support module.
That module is integrated with our serialization for this very purpose.
Most of our DataSerializable classes implement DataSerializableFixedID,
so they can be repackaged w/o any ramifications. Classes that don't fit
that
Geode-core provides suitable public alternatives, I'm sure Spring Data
Geode would be able to adapt and use the certified public API's.
--Udo
On 11/26/18 15:48, Dan Smith wrote:
Our wire format and disk format generally does *not* depend on class names
or packages. Internal classes implement
Our wire format and disk format generally does *not* depend on class names
or packages. Internal classes implement DataSerializableFixedID and are
sent using a fixed integer ID. So we should be able to move these classes
around without affecting the on the wire format.
I don't think we should shy
One problem about moving around internal classes is that Geode uses
(proprietary and Java-based) serialization on the wire instead of defining
a wire-format that isn't dependent on class names/structures/packages.
I for one would love to move to a real wire-format with a well-defined
protocol but
@Galen - If a method is added to a Java interface (e.g. CacheListener),
then classes implementing the interface must define the method, or a
compile error will occur. This is true in the case where 1) the class
implements CacheListener directly rather than extending CacheListenerAdapter
and 2) whe
Before we get to far off the intention of this discussion, let's refocus. The
purpose of the this discussion isn’t to find the “best” modules solution but
rather to find one that is “good enough” to allow Geode 1.x to work in a Java
11 world with a reasonable user experience. While we can run th
>
> If you want to
> maintain an API as internal, then you should properly protect that API with
> the appropriate *Java* access modifiers (private, package-private and
> protected).
>
Hopefully modules will allow us to do this better, by restricting which
*classes* are visible outside the module.
*> Most of these are in internal packages, which means we can change the
package of these classes without breaking users.*
I don't agree with this.
Some functionality in Geode required by an application, or framework, is
only available in an "internal" package, unfortunately. This has to do
with
I need more time to think about this clearly (currently juggling multiple
things), but I would say this...
I don't think there should be "internal" APIs, as in o.a.g.*.internal.
There are only APIs/SPIs and implementations, period. If you want to
maintain an API as internal, then you should prope
On Mon, Nov 26, 2018 at 11:23 AM Udo Kohlmeyer
wrote:
> Imo, no module should export "internal". Maybe a stretch goal, but
> something we should keep in mind.
>
Yes, agreed, but outside the scope of this current discussion.
Imo, no module should export "internal". Maybe a stretch goal, but
something we should keep in mind.
On 11/26/18 10:50, Jacob Barrett wrote:
One lingering question I have around jigsaw is the split package issue
recursive? In that I mean if a module exports "org.apache.geode.internal"
and anot
If Dan's assertions are correct, and we can in fact refactor all these
packages without API changes, then I am all for giving it a shot. Worst
case we have done a little of the work we will have to do for a 2.0 api
change anyway and have to revert to the idea of an uber jar.
On Mon, Nov 19, 2018 a
One lingering question I have around jigsaw is the split package issue
recursive? In that I mean if a module exports "org.apache.geode.internal"
and another module exports "org.apache.geode.internal.foo" is this legal?
On Mon, Nov 19, 2018 at 5:21 PM Dan Smith wrote:
> I think we can actually fi
I think we can actually fix most of these issues without geode-2.0. Most of
these are in internal packages, which means we can change the package of
these classes without breaking users. The only concerning one is
org.apache.geode.cache.util, which is a public package. However, the
AutoBalancer is
To package Geode as Java 11 Jigsaw module(s), a major hurdle is the requirement
that packages cannot be split across modules.
If we simply map existing Geode jars to Modules, we have about 10 split
packages (see table below). Any restructuring would potentially have to wait
until Geode 2.0.
A
15 matches
Mail list logo
