On Thu, Aug 29, 2013 at 11:08 AM, Adrian Wilkins
<[email protected]>wrote:

> 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?
>
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 [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/google-guice.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to