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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
