Thanks Gregg, I realise that Jini may have been a lot more successful had your experiences with desktop applications been given greater consideration.
Any thoughts on JavaFX, fxml for serviceui? Criticism had also in the past, been levelled at the lookup service's inability to perform boolean logic comparisons of Entry fields. Delayed unmarshalling allows local Entry comparisons, improved security and a more responsive ui. I understand why you wouldn't want to "download the internet" (which really means download transitive dependencies at startup) when a user first opens their desktop application, quick start up is important on the desktop. Less so on the server where run time performance is more important. I get that you're not prepared to take a backwards step with desktop start up performance. OSGi support is targeted towards Iot and growing our developer base, it's a convenient time for me to work on that now, as I'm working on a modular maven build, but it's still my understanding that we (River) also intend to continue supporting other developers who don't utilise OSGi or Maven (Rio users). Maven pulls in a lot of unnecessary transitive dependencies (which isn't a problem for a server or build env), OSGi reduces them by using package dependencies at runtime. Classdep can reduce the number further to only the class files necessary, but it doesn't support versioning. Jigsaw is a modular framework that doesn't use ClassLoaders to manage module visibility but it has no versioning support either Containers and modularity are developer concerns, but we need to ensure this is as easy as possible for developers to implement their chosen design and environment. Right now OSGi is difficult because no one has written serialization that takes its ClassLoader visibility into account. OSGi and Maven provide some good tools for automating and simplifying the build process. Bnd generates manifests automatically with package imports and exports for OSGi and also reads annotations. Modules certainly make the code easier to read and understand for the maintainer and allows components that don't change to be released on different timeframes. The qa test suite is still an ant build, which I'm currently working on running with the new jar names on the class path (affects test policy file grants). Clearly tests will need to be written for OSGi. The TCCL classloader will continue to work as it always has, when an OSGi framework is not detected. At the end of the day though, no framework is mandatory and developers can use classdepandjar to package only the classes needed for a client app or proxy into a single jar. The classdepend library (rewritten internals of classdep that uses asm) could be utilised to create a runtime dependency graph as you suggest (which could be serialized) and Jigsaw may yet have a role to play (and I've done some work already to support java 9). The risk with Classdep is, it may not pick up all dependencies in modern bytecode, its only written with consideration for java 6 class files. Jdk 1.9 provides a new tool, jdeps to discover dependencies and this might be utilised to replace Classdep or its internal implementation in the long term, if someone steps up and takes that on. Classdep has developed a bug in recent times that affects the build (occassionally drops deps) and there has been little maintenance on it recently. OSGi could also determine dependency graphs, however would be OSGi specific (package deps) and I'm not yet certain it's necessary. I also think that dependency graphs will tend to be a framework concern, whether they are class, package or module based dependencies they are specific. At this time, choosing a specific container or framework for developers to utilise is a non goal, we're just working on better support for deserialization in an OSGi framework, because there are visibility problems that the TCCL can't completely solve for OSGi. No serialization or Remote method invocation framework currently supports OSGi very well, one that works well and can provide security might gain a lot of new interest from that user base. A modular River also reduces the api users need to learn to get started, which makes River easier to learn for Maven or OSGi developers. In this case they already understand their build tools and probably want to continue using them. It's a non goal to chose any particular modular ity framework for developers to use at this time. Regards, Peter. Sent from my Samsung device . Include original message ---- Original message ---- From: Gregg Wonderly <ge...@cox.net> Sent: 03/02/2017 01:25:35 am To: dev@river.apache.org Subject: Re: OSGi I am a fan of “one jar” because I get real tired of spending time “packaging” when the class loading mechanisms already provide “segregation”. I understand how “pretty” packaging is and how everyone can be completely excited about a clean view of dependencies. However, when I package something that works, I don’t want to hand someone 5 things. The “jar” file has been “click to run” file type for a long time. That, for me means that you should be able to get everything you need from that jar. The problem that clickable jar files suffer from, is that lack of use of Java for desktop apps. Instead, the server mentality of 10s of jars from 10s of places, integration, versioning, etc., have created the “lots of pieces is fine” viewpoint and tooling around that has made it pretty much impossible to easily create one jar, without “custom” packaging. I like to solve problems once, not over and over again. We need to make sure and think about “tools” that make whatever packaging is decided on, trivial to create. Think about using annotations to segregate pieces into the packages that you want them to be in. Think about runtime dependency graphs being expressible in annotations as well, so that we might be able to utilize a composite class loader to “get” dependent jars from an appropriate source. This would allow great, dynamic binding to occur in the class loader, and still provide a single class loader view of the context so that TCCL and other parts of the Java runtime will still work in non-jini packages. Gregg > On Feb 1, 2017, at 7:44 PM, Peter <j...@zeus.net.au> wrote: > > Thanks Gregg, > > I think it's necessary to continue supporting preferred class loading for >those who don't use osgi or maven. Rio already has a maven class resolver >RMIClassLoaderSPI implementation. But we also need to ensure we can still >solve the same problems that preferred class loading addresses in modular >environments. > > We also need to consider how existing implementations can transition to a >modular framework, should developers want to. > > River / Jini's classdepandjar duplicates classes in jar files. Maven or OSGi >modules usually don't. > > In a modular version of Gregg's use case scenario, the shared Entries >wouldn't be included in the proxy codebase but instead be imported from >another module / bundle / package. > > The Entry's would be imported by the client and proxy modules / bundles, >avoiding unnecessary downloads and ensuring shared visibility. The client and >proxy will need to have an overlapping import package version range and the >currently utilised package at the client will need to be within the proxy's >imported version range, so it will be wired / resolved correctly. > > We should look at implementing a modular test case of what your doing, to >test our OSGiClassProvider. > > Supporting OSGi is likely to require delayed unmarshalling. Logical >comparisons of Package version Entry's will be required before proxy's can be >downloaded/ unmarshalled. > > The lookup service only provides exact matching. However it would be >possible to perform a limited range of version matching with wild cards >without delayed unmarshalling. > > Modular frameworks reduce downloads by utilising already downloaded code when >compatible. > > Regards, > > Peter > > Sent from my Samsung device. > > Include original message > ---- Original message ---- > From: Gregg Wonderly <ge...@cox.net> > Sent: 02/02/2017 06:56:43 am > To: dev@river.apache.org > Subject: Re: OSGi > > Part of the “preferred” is to keep downloads from happening. But the other >is the fact that the UI is already using/linked to specific sources of the >Entry classes that it uses for finding the name of the service, the icon and >other details. There are serviceUI classes which are also already bound at >the time of service discovery and the serviceUI for that service needs to >resolve to those classes, not any in the codebase jars for the service. > > Gregg > >> On Feb 1, 2017, at 5:52 AM, Peter <j...@zeus.net.au> wrote: >> >> Gregg, >> >> Have you got some more detail on your Entry classes that need to be >>preferred? >> >> Thanks, >> >> Peter. >> >> Sent from my Samsung device. >> >> Include original message >> ---- Original message ---- >> From: Gregg Wonderly <ge...@cox.net> >> Sent: 31/01/2017 12:56:56 am >> To: dev@river.apache.org >> Subject: Re: OSGi >> >> Maybe you can help me out here by explaining how it is that execution >>context and class visibility are both handled by OSGi bundles. For example, >>one of my client applications is a desktop environment. It does service look >>up for all services registrations providing a “serviceUI”. It then >>integrates all of those services into a desktop view where the UIs are >>running at the same time with each one imbedded in a JDesktopPane or a >>JTabbedPane or a JFrame or JDialog. There are callbacks from parts of that >>environment into my application which in turn is interacting with the >>ServiceUI component. You have AWT event threads which are calling out, into >>the ServiceUIs and lots of other threads of execution which all, ultimately, >>must have different class loading environments so that the ServiceUI >>components can know where to load code from. >> >> It’s exactly TCCL that allows them to know that based on all the other >>class loading standards. The ClassLoader is exactly the thing that all of >>them have in common if you include OSGi bundles as well. The important >>detail, is that if the TCCL is not used as new ClassLoaders are created, then >>there is no context for those new ClassLoaders to reference, universally. >> >> The important details are: >> >> 1) The desktop application has to be able to prefer certain Entry >>classes which define details that are presented to the user. >> 2) When the user double clicks on a services icon, or right clicks and >>selects “Open in new Frame”, an async worker thread needs a TCCL pointing at >>the correct parent class loader for the service’s URLClassLoader to reference >>so that the preferred classes work. >> 3) Anytime that the AWT Event thread might be active inside of the >>services UI implementation, it also needs to indicate the correct parent >>class loader if that UI component causes other class loading to occur. >> 4) I am speaking specifically in the context of deferred class loading >>which is controlled outside of the service discovery moment. >> >> >>> On Jan 30, 2017, at 4:04 AM, Michał Kłeczek (XPro Sp. z o. o.) >>><michal.klec...@xpro.biz> wrote: >>> >>> What I think Jini designers did not realize is that class loading can be >>>treated exactly as any other capability provided by a (possibly remote) >>>service. >>> Once you realize that - it is possible to provide a kind of a "universal >>>container infrastructure" where different class loading implementations may >>>co-exist in a single JVM. >> >> That’s precisely what ClassLoader is for. TCCL is precisely to allow “some >>class” to know what context to associate newly loaded classes with, so that >>in such an environment, any code can load classes on behalf of some other >>code/context. It doesn’t matter if it is TCCL or some other class management >>scheme such as OSGi bundles. We are talking about the same detail, just >>implemented in a different way. >> >>> What's more - these class loading implementations may be dynamic >>>themselves - ie. it is a service that provides the client with a way to load >>>its own (proxy) classes. >>> >>> In other words: "there not enough Jini in Jini itself”. >> >> I am not sure I understand where the short coming is at then. Maybe you >>can illustrate with an example where TCCL fails to allow some piece of code >>to load classes on behalf of another piece of code? >> >> In my desktop application environment, there is a abstract class which is >>used by each serviceUI to allow the desktop to know if it provides the >>ability to open into one of the above mentioned JComponent subclasses.. That >>class is preferred and provided and resolved using the codebase of the >>desktop client. That class loading environment is then the place where the >>service is finally resolved and classes created so that the proxy can be >>handed to the serviceUI component which ultimately only partially resolves >>from the services codebase. >> >> It’s this class compatibility which needs to be lightweight. >> >>> >>> We have _all_ the required pieces in place: >>> - dynamic code loading and execution (ClassLoaders), >>> - security model and implementation that allows restricting rights of the >>>downloaded code, >>> - and a serialization/deserialization which allows sending arbitrary data >>>(and yes - code too) over the wire. >>> >>> It is just the matter of glueing the pieces together. >> >> Correct, but it’s a matter of class compatibility where a client >>environment has to interact with a service and the serviceUI components where >>TCCL excels and providing the ability to create class loaders with the >>correct parent context, for Java based code. OSGi introduces the opportunity >>for some extra bells and whistles. But I don’t see that it can completely >>eliminate the nature of TCCL and how it was intended to be used. >> >>> >>> Thanks, >>> Michal >>> >>> >>> Gregg Wonderly wrote: >>>> <snip> >>>> I am not an OSGi user. I am not trying to be an OSGi opponent. What I >>>>am trying to say is that I consider all the commentary in those articles >>>>about TCCL not working to be just inexperience and argument to try and >>>>justify a different position or interpretation of what the real problem is. >>>> >>>> >>>> The real problem is that there is not one “module” concept in Java >>>>(another one is almost here in JDK 9/Jigsaw). No one is working together >>>>on this, and OSGi is solving problems in a small part of the world of >>>>software. It works well for embedded, static systems. I think OSGi >>>>misses the mark on dynamic systems because of the piecemeal loading and >>>>resolving of classes. I am not sure that OSGi developers really understand >>>>everything that Jini can do because of the choices made (and not made) in >>>>the design. The people who put Jini together had a great deal of years of >>>>experience piecing together systems which needed to work well with a faster >>>>degree of variability and adaptation to the environment then what most >>>>people seem to experience in their classes and work environments which are >>>>locked down by extremely controlled distribution strategies which end up >>>>slowing development in an attempt to control everything that doesn’t >>>>actually cause quality to suffer. >>>> >>>> Gregg >>>> >>>> >>> >> >> > >
