Andrew, thanks for summarizing the various topics!
+1 for GitHub. I think it would be much more familiar to anyone outside the Eclipse community
> Eclipse project 2022-06 requires Java 17
+1 - also from me no objections to move to a more recent version
> Eclipse project websites from www.eclipse.org to websites.eclipseprojects.io
I can look into this one.
> Removal of pack – pack200 deprecated in Java 11, removed in Java 14
I will have a look.
Not sure about the deprecations. I guess we’ll need to fix them over time, but at the moment I can’t spend time on these
Regards,
Krum
From: mat-dev <mat-dev-bounces@xxxxxxxxxxx> on behalf of Memory list <mat-dev@xxxxxxxxxxx>
Reply to: Memory list <mat-dev@xxxxxxxxxxx>
Date: Wednesday, 24. August 2022 at 19:04
To: Memory list <mat-dev@xxxxxxxxxxx>
Subject: Re: [mat-dev] Keeping Memory Analyzer up to date
User / contributor opinion:
On Wed, Aug 24, 2022 at 7:59 AM Kevin Grigorenko wrote:
> Migrate from
git.eclipse.org and Bugzilla to GitLab or GitHub [...] Do current committers or contributors have a preference? Which is likely to be easier to use? Which could bring us more contributors? Github.com is an external site [...] GitLab is hosted by Eclipse.org
No preference but GitHub reduces contribution friction a bit as a new contributor usually wouldn't need to create an Eclipse GitLab account and most developers
have a GitHub account.
+1 to this. the Github PR process is much more familiar to me and I would guess other developers too.
> Eclipse project 2022-06 requires Java 17 – implications if we need a security fix for stand-alone MAT, for example fixes for Eclipse Help / Jetty. Are we happy
to require Java 17 to run MAT?
In my opinion, since we've already "broken the seal" on Java 8, I think MAT users should be more comfortable downloading and using different versions of JDKs,
especially now that there are so many easy-to-use public download options, so I think Java 17 is okay, although we'll have to see how DTFJ handles it as it has some module magic that might require some additional JVM launch arguments.
+1 to this also, I think most tools in the development ecosystem target current / newer LTS releases.
I don't have an opinion on the Eclipse framework deprecations (as I don't fully understand it). The asserts seem easy to fix.
For Java the changes seem simple enough, and I if you give the green light I'm happy to get started on these.
- parser - SeekableStream finalize deprecation I think we can do away with, it implements Closeable. We might look at switching to try-with-resources pattern where possible to get some extra Java support for ensuring it's closed correctly
whenever it needs to be.
- oql - MethodCallExpression instantiates AccessControlException which is now deprecated, we should use an alternative exception.
- ui - NotesView implements Observer/Observable - but I can't see a reference anywhere else in the MAT codebase; seems like this might be dead code?
- tests - PrimitiveMapTests uses deprecated constructors instead of newer .of() calls.
Kevin Grigorenko
IBM App Platform SWAT
