Considered that too... the trouble with that is OS X support. It would mean having to install a Java runtime as part of an 'installation' process. On OS X right now it's as simple as running a .app 'bundle' (overloaded term!) inside a DMG. If Java 6 isn't installed already, OS X does the work of installing for you. I sell my software, and I need as low a friction solution as possible.
Dan On Tue, May 14, 2013 at 3:52 PM, Bruce Jackson <[email protected]> wrote: > I'd remove JNotify and replace it with the new filesystem classes in J2SE > 7. That way you'll be able to sort out the thread management yourself. > > > On 14 May 2013, at 15:46, Dan Gravell <[email protected]> wrote: > > > Hmmmm, sorry, don't want to misrepresent things... In neither case do you > > *explicitly* start threads. > > > > JNotify's threads are started by the class initialisers... so load the > > class (as you do when you add a 'watch' via a static method for a > > directory) and the thread starts. > > > > Lift's are started as part of its HTTP request handling. I managed to > patch > > it to stop all the threads upon shutdown of its surrounding servlet > > container (I use Jetty) but this is just code I will have to maintain > going > > forward with new releases. > > > > Neither behaviour is particularly desirable but JNotify's age and lack of > > committers and Lift's usage scenarios are probably good reasons why the > > respective projects' resources are not spent on fixing this. > > > > Dan > > > > > > On Tue, May 14, 2013 at 3:41 PM, Neil Bartlett <[email protected]> > wrote: > > > >> So, they give you API to start a bunch of threads, but not stop them? > >> Awesome... > >> > >> On Tue, May 14, 2013 at 3:35 PM, Dan Gravell <[email protected]> > >> wrote: > >>> In one case (JNotify) I create straight wrappers so the JARs are > >>> 'OSGi-ified', in another case I have the JARs embedded in the bundle > that > >>> uses them (Lift). > >>> > >>> Adding the bundle activator might work if the support to shutdown the > >>> threads is in the API for the code I am using. However, it isn't, and > as > >>> you know Java threads are co-operative so I can't simply stop them. > >>> > >>> Dan > >>> > >>> > >>> On Tue, May 14, 2013 at 2:57 PM, Felix Meschberger <[email protected] > >>> wrote: > >>> > >>>> Hi Dan, > >>>> > >>>> Am 14.05.2013 um 07:16 schrieb Dan Gravell: > >>>> > >>>>>> With respect to when the thread has to stop, think about it the > other > >>>>>> way around... what if you never stop any threads? This would mean > >> that > >>>>>> objects allocated by the thread do not become candidates for garbage > >>>>>> collection; therefore neither do the classes that define those > >>>>>> objects; therefore, neither do the classloaders that loaded those > >>>>>> classes. So you're going to create a lot of garbage on the heap, > >>>>>> eventually resulting in OOME. Also, if a bundle's thread continues > >>>>>> running after the bundle has been stopped/updated then you could get > >>>>>> unexpected exceptions occurring in that thread; e.g. the bundle > >>>>>> classloader might not allow any new classes to be loaded, and calls > >>>>>> into OSGi using your BundleContext will probably throw > >>>>>> IllegalStateException. Generally these exceptions are not harmful > >>>>>> since you wanted the thread to die anyway, but they could cause > >>>>>> confusion if written to a log. > >>>>>> > >>>>> > >>>>> Just to be clear: you're preaching to the converted, I understand why > >> the > >>>>> threads should be stopped. The issue is that I am re-using other > >> projects > >>>>> that don't conform to these rules.... projects that were never > >> written as > >>>>> OSGi bundles. It's a bit like the class loading assumptions you see > in > >>>>> other projects... except arguably more subtle. > >>>> > >>>> So you are using libraries which are not built with OSGi in mind. > Still > >>>> you need OSGi manifests for the libraries to become bundles. So you at > >>>> least wrap the libraries somehow to generate the manifest. > >>>> > >>>> How about adding a BundleActivator as part of this manifest > generation ? > >>>> That BundleActivator could in the stop method stop any running > threads. > >> The > >>>> BundleActivator is part of the bundle so it may be aware of the > library > >>>> internals and be able to stop any running threads. > >>>> > >>>> Regards > >>>> Felix > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > > This e-mail is only intended for the person(s) to whom it is addressed and > may contain CONFIDENTIAL information. Any opinions or views are personal to > the writer and do not represent those of INQ Mobile Limited, Hutchison > Whampoa Limited or its group companies. If you are not the intended > recipient, you are hereby notified that any use, retention, disclosure, > copying, printing, forwarding or dissemination of this communication is > strictly prohibited. If you have received this communication in error, > please erase all copies of the message and its attachments and notify the > sender immediately. INQ Mobile Limited is a company registered in the > British Virgin Islands. www.inqmobile.com. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
