river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz>
Subject Re: Serialization Formats, Previously: OSGi
Date Sat, 04 Feb 2017 17:33:12 GMT
I cannot disagree with rants about software industry state.

Let's get back to technical solutions to non-technical problems. I am 
interested in providing tools - whether will be used... is a different 
story.

That said...
IMHO Jini - in all its greatness - DID NOT solve the problem of Java 
code mobility in any way.
As has been discussed on this list several time the way how it "solved" 
it is:
- inherently insecure (because object validation is done _after_ code 
execution)
- is not capable of transferring complicated object graphs - hence it 
cannot be used in many different interesting scenarios.

Partial solutions are worse than lack of solutions - they confuse users 
(in our case programmers) and in the end people loose interest.

I am not a big fan of Java containers - be it JEE or any other (OSGI 
included)
The industry seems to understand they are a dead end - escpecially in 
the age of Docker etc - and is moving away from them (not that in a very 
meaningful direction :) ).

I have worked with OSGI for several years and it was a difficult 
relationship :)
Today I prefer simpler solutions: "java -jar 
my-very-complicated-and-important-service.jar" is the way to go.

Thanks,
Michal


Niclas Hedhman wrote:
> (I think wrong thread, so to please Peter, I copied it all into here)
>
> Correct, it is not different. But you are missing the point; CONSTRAINTS.
> And without constraints, developers are capable of doing these good deeds
> (such as your example) and many very poor ones. The knife cuts your meat or
> butcher your neighbor... It is all about the constraints, something that
> few developers are willing to admit that makes our work better.
>
> As for the "leasable and you have..."; The problem is that you are probably
> wrong on that front too, like the OSGi community have learned the hard way.
> There are too many ways software entangle classloading. All kinds of shit
> "registers itself" in the bowels of the runtime, such as with the
> DriverManager, Loggers, URLHandlers or PermGenSpace (might be gone in Java
> 8). Then add 100s of common libraries that also does a poor job in
> releasing "permanent" resources/instances/classes... The stain sticks, but
> the smell is weak, so often we can't tell other than memory leak during
> class updates.
> And why do we have all this mess? IMHO; Lack of constraints, lack of
> lifecycle management in "everything Java" (and most languages) and lack of
> discipline (something Gregg has, and I plus 5 million other Java devs don't
> have). OSGi is not as successful as it "should" (SpringSource gave up)
> because it makes the "stain" stink really badly. OSGi introduces
> constraints and fails spectacular when we try to break or circumvent them.
>
> River as it currently stands has "solved" Java code mobility, Java leases,
> dynamic service registry with query capabilities and much more. But as with
> a lot of good technology, the masses don't buy it. The ignorant masses are
> now in Peter Deutsch's Fallacies of Distributed Computing territory,
> thinking that microservices on JAX-RS is going to save the day (it isn't, I
> am rescuing a project out of it now).
> Distributed OSGi tried to solve this problem, and AFAICT has serious
> problems to work reliably in production environments. What do I learn? This
> is hard, but every 5 years we double in numbers, so half the developer
> population is inexperienced and repeat the same mistakes again and again.
>
> Sorry for highlighting problems, mostly psychological/philosophical rather
> than technological. I don't have the answers, other than; Without
> Constraints Technology Fails. And the better the constraints are defined,
> the better likelihood that it can succeed.
>
>
>
>
> On Sat, Feb 4, 2017 at 8:59 PM, "Michał Kłeczek (XPro Sp. z o. o.)"<
> michal.kleczek@xpro.biz>  wrote:
>
>> Comments below.
>>
>> Niclas Hedhman wrote:
>>
>> see below
>>
>> On Sat, Feb 4, 2017 at 6:21 PM, "Michał Kłeczek (XPro Sp. z o. o.)"<michal.kleczek@xpro.biz>
 wrote:
>>
>> Once you transfer the code with your data - the issue of code version
>>
>> synchronization disappears, doesn't it?
>>
>> It also makes the wire data format irrelevant. At least for "short lived
>>
>> serialized states".
>>
>> Only works if you have no exchange with the environment it is executing.
>> And this is where "sandboxing" concern kicks in. What is the sandbox? In a
>> web browser they try to define it to DOM + handful of other well-defined
>> objects. In case of Java Serialization, it is all classes reachable from
>> the loading classloader. And I think Gregg is trying to argue that if one
>> is very prudent, one need to manage this well.
>>
>>
>> But how is "exchange with the environment it is executing"
>> actually different when installing code on demand from installing it in
>> advance???
>>
>> The whole point IMHO is to shift thinking from "moving data" to "exchange
>> configured software" -
>> think Java specific Docker on steroids.
>>
>> Transferable objects allow you for example to do things like
>> downloading your JDBC driver automagically without the fuss of installing
>> it and managing upgrades.
>> Just publish a DataSource object in your ServiceRegistrar and you are done.
>> Make it leasable and you have automatic upgrades and/or reconfiguration.
>>
>> Thanks,
>> Michal
>>
>
>
>


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message