Hi,
On Thu, Mar 18, 2021 at 6:22 AM Daniel Widdis wrote:
> ...Regarding "Apache" = "Quality", I'd be careful. Apache asserts [1] a
> maxim of "Community over code"
FWIW, the Maturity Model at [1] emphasizes being honest about the
quality of a project's modules (QU10).
As mentioned there,
Hi,
On Thu, Mar 18, 2021 at 6:08 AM leerho wrote:
> ...I am seriously looking at *redesigning* our JDK8 Library using Java Modules
> leveraging JDK16+/Panama/FMA and completely replacing the need for Unsafe,
> etc. (Not just adapting our JDK8 code to run on JDK9+ and accessing Java
> internals
JPMS is flat out a PITA. I’ve tried to get Log4j to fully support it and am
continuing to work on that. Our current 2.x releases tolerate it primarily by
declaring their names in the Manifest but that really isn’t full support.
If I were starting out on a brand new project JPMS might be a lot
I did find one small library that shows some of the useful
possibilities of adding proper module info to something for 9+
runtimes (especially when using modules):
https://github.com/cryptography-cafe/curve25519-elisabeth
On Thu, 18 Mar 2021 at 09:36, wrote:
>
> Agree, and if you want to check
Hi,
If it helps, JPMS has still a lot of blockers IMHO, as soon as you quit
unamed module land you break most frameworks out there.
If your lib is a standalone functional set of utilities it can not be
bothering but if you use any reflection or meta programming I would
recommend to stick to
Agree, and if you want to check some Apache projects related to OSGi you
can take a look to:
- Apache Karaf : https://karaf.apache.org
- Apache Felix : https://felix.apache.org
regards,
François
fpa...@apache.org
Le 18/03/2021 à 15:25, Serge Huber a écrit :
> I was also going to mention OSGi.
I was also going to mention OSGi. It enforces better lifecycle management
than JPMS. If you can do it with OSGi you can certainly use it with JPMS
Regards,
Serge...
On Thu, Mar 18, 2021 at 3:19 PM Matt Sicker wrote:
> Perhaps the various OSGi-related projects here might be similar to what
>
Perhaps the various OSGi-related projects here might be similar to what
you’re looking for since those have enforced modularity for a long time.
That module system is more advanced than JPMS, but the concepts are fairly
similar.
We’ve also been looking into this for log4j 3.0, but that’s not out
After considering this email I wrote, I regret sending it and want to apologize
if I have overstepped any bounds.
I am not a member of the IPMC or associated in any formal way with Apache and
am certainly not in any position to make any judgments regarding code quality
or your wise choice to
Thanks for your clarifications.
Regarding "Apache" = "Quality", I'd be careful. Apache asserts [1] a maxim of
"Community over code". While certainly a broad community inevitably leads to
better code, and Apache is a good starting point, given the specificity of your
request I might start
Daniel,
Thank you for your reply.
> Can you clarify what you mean by an "Apache Java project"?
I would prefer to examine a project that has a formal release process and
an active community. So a TLP or incubating project would be great. In
this case I was equating "Apache" = "Quality" :)
Can you clarify what you mean by an "Apache Java project"?
- A TLP?
- An incubating project?
- A project anywhere that is released under the Apache license?
There's actually no need to "migrate code" in many cases, just add some
files. Is there a particular use case you are interested in?
On
Folks,
Is anyone aware of an Apache Java project that has actually migrated their
code from Java 8 to the Java Platform Module System (JPMS)?
Thanks,
Lee.
13 matches
Mail list logo
