On 1/29/20 3:15 PM, Alex Scheel wrote:
I lump the Java SE platform into "roughly" what I was
calling the JVM
team. You're roughly the group that does what'd be the "core" work in
other languages: maintains the compilers and the stdlib. My terminology
there was incorrect; I suppose "JRE" is more correct.
Is it correct to say that your team and immediate coworkers don't
maintain say, the Apache libraries, the various build systems, IDEs,
and the JBoss libraries?
Yes, it's exactly right. However, we (the Java SE team) are part of
the Red Hat Middleware division, who do indeed maintain the JBoss
libraries.
My point is that some language SIGs/teams take a more active role in
making sure a decent amount of non-stdlib software runs and is
maintained by them. The "core" Java (JVM + JRE) team doesn't seem to
engage in other places. Which is totally fine, from my PoV, as long
as there is communication between the two parts and between the group
and the wider Fedora community, and the overall experience is inclusive.
The issue here is as much about separation of concerns as anything
else. There's a limit to how much different stuff people can possibly
do, and we all have to draw the boundary somewhere. Of course we want
people to use Java, and to that end we ensure that it meets its
specification, performs well, and so on. One of the most important
things we do is maintain compatibility as much as we can, so that
packagers have a solid platform on which to build.
The wider Java community has created an amazing ecosystem of packages,
build tools, and so on. Some of these tools have, er, interesting
properties, and I think it's fair to say that the designers of Java
itself probably wouldn't have done it that way. However, such tools
are testament to the remarkable flexibility of the Java platform, and
in a way that flexibility is part of the problem.
Instead, most of the library support falls to Joe's team,
including
Mikolaj. That's where most of the shortcomings in Java packaging are
seen, including unfriendly, non-inclusive modularization policies.
They're the ones that have orphaned large segments of packages, which
ultimately lead to starting this mail thread. :-)
Even the word "modularization" is problematic here: I guess you mean
Fedora modules, not Java modules. Can you provide (or point me to) a
brief explanation of where Fedora's modularization policy conflicts
with Java's needs?
Perhaps putting words in Bill's mouth here, but I don't
subscribe any
of his issues to the JRE team. They're mostly caused by issues in a
lot of packages disappearing, and Matt Booth trying his best to clean
up after that (with the help of Stewardship SIG). But we're all busy
folks and sometimes we can handle that new package load and sometimes
we can't.
Sure, I get that. There is inevitable tension between Red Hat's desire
to make Fedora a true community effort and the fact that sometimes
packaging is hard, and so needs full-time attention. This is
especially because of tools things like Maven, where the design of Maven
and Fedora packaging seem sometimes to be diametrically opposed. I
don't know enough about this to suggest a solution, but I am sure it
is a hard problem.
And yes, you do a lot of great work in other places too. I thank you
for that the few times I need to touch Java on non-Linux platforms. :-)
Keep up the good work,
Thanks!
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <
https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671