Guice for platform modules

[Adrian Wilkins]

Ok, so my situation is that I have a rich-client Java app that I want to run on Windows, Mac, and Linux

The original code for this unfortunately has some horrible platform-specifisms.

• The code that works out where the user configuration is
• This isn't too hard to do with a conditional block, but I figure we could just have a different class that does this
• Code that squirts content from the app into an email window
• This uses the COM stuff from Eclipse to automate Outlook, so it's not available from the SWT packages for other platforms
• Code that accesses the Registry for (legacy) config data
• Since the app hasn't been on non-Windows platforms before, we can just keep it to the config files for the other platforms
• This won't even compile on non-Windows platforms because of the JNI bindings
• Code that invokes bits of the Windows HTML help libraries
• Yuk
• Probably the best thing to do here is just replace the help system with something nice...
  

Since the advice is to avoid doing conditional logic about what instances get returned from module bindings, my guess is that the proper practice is to instead have platform-specific modules and decide which ones to use when constructing your Injector (e.g. on Mac / Linux, use GenericEmailLauncherModule and PosixUserEnvironmentModule, on Windows + Outlook use OutlookEmailLauncherModule and WindowsUserEnvironmentModule, if Windows doesn't have Outlook installed, fall back to GenericEmailLauncherModule) . What I didn't see watching the videos or reading anything I've found so far is the best practise for using modules without referring to them directly ; I don't want my main build to depend on the Windows versions of the modules, I just want the Windows module library to be added to the classpath optionally by a profile in my Maven build.

Am I just being rather simple - is it just a matter of calling Class.forName().newInstance() and passing the results?

[Sam Berlin]

Yup, if you want to avoid directly referencing classes, then you'll need to use Class.forName().newInstance() to create the modules.  No way around that.  I don't know of any Maven plugins that can automate module creation.  Though, if you write one, I'm sure folks would love it. :-)

 sam

 

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.

[Cédric Beust ♔]

On Thu, Aug 29, 2013 at 8:08 AM, Adrian Wilkins <adrian....@gmail.com> wrote:

What I didn't see watching the videos or reading anything I've found so far is the best practise for using modules without referring to them directly ; I don't want my main build to depend on the Windows versions of the modules, I just want the Windows module library to be added to the classpath optionally by a profile in my Maven build.

Would a ServiceLoader help? It's not clear to me if you want the classpath to be OS dependent or if concrete implementations are enough, in which case ServiceLoader seems to be a good match.

—
Cedric

-- 

Cédric