Thanks Peter, you're right, 'simpler' is not always less complex.
Serialized circular object graphs are not required for RMI either (in
our version of RMI, called JERI, which stands for Jini Extensible Remote
Invocation), we found only Throwable used it and were able to work
around it. Anoth
Just from my personal experience…
I am very pleased that the decision to make DTOs non-circular was taken. I have
been using DTOs recently as a core part of my infrastructure. This insight came
from Peter. He made me realize that a business object actually has two APIs: a
behavioral API (the J
Very nice example of something I see too often: choosing a bad solution that
just appears to be ’simpler’ to use. I think the Java world suffers from this
terribly.
We also had a big discussions about circularity in the OSGi for the DTO’s.
Initially they were circular but in the we agreed to n
On 13/04/2018 6:32 PM, Neil Bartlett via osgi-dev wrote:
On Thu, Apr 12, 2018 at 10:12 PM, Mark Raynsford via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:
On 2018-04-12T20:32:13 +0200
Peter Kriens mailto:peter.kri...@aqute.biz>> wrote:
> Caught between a rock and a hard place
On 2018-04-13T14:59:49 +0100
Neil Bartlett wrote:
>
> It's definitely possible that we're talking about different things, but let
> me explain myself a little more...
Understood.
> Yes I agree that's an additional benefit, but I'm not clear on what those
> optimizations might be.
Nonexistent,
On Fri, Apr 13, 2018 at 2:24 PM, Mark Raynsford
wrote:
> On 2018-04-13T12:11:41 +0100
> Neil Bartlett wrote:
> >
> > To be clear, I'm not convinced OSGi would ever want to do this. If we
> did,
> > we would likely invert the default from "closed" to "open". Closing off a
> > bundle to ALL access
On 2018-04-13T12:11:41 +0100
Neil Bartlett wrote:
>
> To be clear, I'm not convinced OSGi would ever want to do this. If we did,
> we would likely invert the default from "closed" to "open". Closing off a
> bundle to ALL access, even reflectively, seems like an extreme measure that
> would only be
On Fri, Apr 13, 2018 at 11:45 AM, Mark Raynsford
wrote:
> On 2018-04-13T09:32:30 +0100
> Neil Bartlett wrote:
> >
> > Interop already works just fine in one direction: OSGi bundles depending
> on
> > JPMS modules...
>
> Please indulge me in a bit of brain storming...
>
> Let's assume hypothetica
On 2018-04-13T09:32:30 +0100
Neil Bartlett wrote:
>
> Interop already works just fine in one direction: OSGi bundles depending on
> JPMS modules...
Please indulge me in a bit of brain storming...
Let's assume hypothetically that the goal now is to produce an OSGi
container that can use (possibly
On Thu, Apr 12, 2018 at 10:12 PM, Mark Raynsford via osgi-dev <
osgi-dev@mail.osgi.org> wrote:
> On 2018-04-12T20:32:13 +0200
> Peter Kriens wrote:
>
> > Caught between a rock and a hard place with only one way forward …
>
> I should make the point that I don't hate the JPMS. I do think that
> it
That's a pretty good summary of it.
Personally, I would have preferred they only use it for the JVM. JPMS
doesn't grok versioning and the jvm doesn't generally break backward
compatibility, so it's ok there, I don't think there will be a lot of
external adoption anyway.
Cheers,
Peter.
On
On 2018-04-12T20:32:13 +0200
Peter Kriens wrote:
> Caught between a rock and a hard place with only one way forward …
I should make the point that I don't hate the JPMS. I do think that
it's just barely the minimum viable product, though.
The JVM really did need a module system, both for the ma
Caught between a rock and a hard place with only one way forward …
Oracle’s strategy is a mystery to me.
Kind regards,
Peter Kriens
> On 12 Apr 2018, at 20:06, Mark Raynsford via osgi-dev
> wrote:
>
> Thought this might be of mild interest to people on this list:
>
> https://blog.io
13 matches
Mail list logo
