[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-jigsaw-dev
Subject:    Re: Portable retrieval of resource bundles across module path and class path
From:       Christian Stein <sormuras () gmail ! com>
Date:       2021-08-31 8:32:19
Message-ID: CAJi8+g5=jzd3vzr4eRyi=wPHu_TpK+A-s1G_xWOOahxQUBG2NA () mail ! gmail ! com
[Download RAW message or body]

Hi Gunnar,

I skimmed your post briefly and will read it in detail later -- though I
wonder
whether my over 4 years old SO question is answered as a side-effect by
your findings.

https://stackoverflow.com/questions/44167502/how-to-configure-resourcebundle-no-fallback-control-in-java-9


Cheers,
Christian

On Tue, Aug 31, 2021 at 10:25 AM Gunnar Morling <gunnar@hibernate.org>
wrote:

> Hi all,
> 
> I've written a quick blog post about my experiences with
> ResourceBundleProvider et al.:
> 
> 
> 
> https://www.morling.dev/blog/resource-bundle-lookups-in-modular-java-applications/
> 
> The scenario I'm describing is that of a "well-structured monolith", with
> each module contributing its own resource bundle(s). It took a while to set
> things up in a way working with Java 9+ (with module and with classpath)
> and Java 8, but I've found my ways in the end.
> 
> Thanks again for all the feedback and input you provided!
> 
> Best,
> 
> --Gunnar
> 
> 
> 
> Am Fr., 23. Juli 2021 um 21:14 Uhr schrieb Mandy Chung <
> mandy.chung@oracle.com>:
> 
> > 
> > 
> > On 7/23/21 4:17 AM, Gunnar Morling wrote:
> > 
> > Thanks a lot for your replies, Mandy and Alan!
> > 
> > > I assume the class path is running on JDK <= 8, right?  Otherwise
> > 
> > Is there something missing after "Otherwise"?
> > 
> > 
> > It was a typo (I should have taken it out).
> > 
> > In fact, I'm looking for a way to run this
> > 
> > - Java 1.8 on classpath
> > - Java 9+ on classpath
> > - Java 9+ on module path
> > 
> > As I've learned by now, ResourceBundleControlProvider implementations on
> > Java 1.8 will only be loaded via the extension mechanism, which often is
> > impractical to use. So it seems I'll need to amend my solution described
> > above to pass in the custom Control explicitly to
> > ResourceBundle.getBundle(). I could use the ResourceBundleControlProvider
> > in a MR JAR, but there seems not much of an advantage to doing that.
> > 
> > > For the migration scenario where the resources are in .properties
> format
> > then the simplest may be to just deploy the JAR files on the module path
> > where they will be treated as automatic modules.
> > 
> > 
> > Right, this is indeed the simplest approach if the JAR file contain
> > resource bundles in .properties format and no .class files in that
> > package.  i.e. you can keep the resource bundles in `dev/morling/greeter`
> > and deploy them as automatic modules.
> > 
> > 
> > In the scenario I have in mind (for educational purposes mainly) the JAR
> > files contain the properties file as well code and should be usable as
> > "proper" (i.e. non-automatic) modules as well as on the classpath.
> > 
> > 
> > It's common to have the resources packaged in separate JARs from the code
> > and also an application includes all resources.   This educational
> purpose
> > demo shows an advanced feature.
> > 
> > 
> > > There are no split package issues unless the resources have been
> > compiled as .class files.
> > 
> > That's very interesting, it's not what I observe. Having the *.properties
> > in one and the same package in multiple modules triggers an error upon
> > start-up:
> > 
> > java.lang.LayerInstantiationException: Package
> dev.morling.greeter.fr
> > <
> https://urldefense.com/v3/__http://dev.morling.greeter.fr__;!!ACWV5N9M2RV99hQ!fILkGEkNjEpD7sQnRSKHS3M4qZY3lXvfXij2Q4XgaGa9P1mVdmrAFrdcvVKsPREq3A$
> 
> > 
> > in both module dev.morling.greeter.german and module
> > dev.morling.greeter.french
> > 
> > 
> > this looks a little suspicious.   GreetingMessages_de.properties should
> be
> > expected in dev.morling.greeter.
> > 
> > Mandy
> > 
> 


[prev in list] [next in list] [prev in thread] [next in thread]