Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] "clean up" again

I think we need to distinguish two things:

A. Adjusting the code structure to changing requirements to work against architectural decay.

B. Mechanical transformations, e.g., in order to use more modern syntax.

We typically consider (A) during *every* code change, at least we should. Sometimes, a quick band-aid is committed and a follow-up ticket filed, to iron out a kludge. Recovering design intentions that have been lost during evolution is one of the hardest tasks, typically involving a lot of time reading through git history and lots of bugs ("software archeology"), and then designing & documenting a better structure. Such changes require review - if not participation - of a senior committer.

I'm not sure how changes in category (B) could possibly work against "code base deteriorating over time".

So rather than speculate, show me an example, where code was hard to read and is significantly easier to read after clean-up. Is improvement in the order of saving one or two seconds here and there, or can you show examples where the change caused "now I understand what this code is doing"?

We have the relevant people with experience of working on JDT code right here in the list. Let's use that opportunity for learning based on specific observations, rather than general statements that could also be found in a text book.


On 28.05.20 08:00, Gayan Perera wrote:
A clean structured code will help new comers to read it easily. I guess for JDT masters it might not make a difference since you have lived with the code and you might have written that code as well. Any code base deteriorate over time how much good you write it. So frequent cleanups and refactoring it essential. I this this problem have not been such a issue if object team had a proper ci pipeline building against latest JDT and these cleanups have been merged much earlier.

Best regards,

On Wed, 27 May 2020 at 20:54, Jeff Johnston <jjohnstn@xxxxxxxxxx <mailto:jjohnstn@xxxxxxxxxx>> wrote:

    Not me personally, but I have been reviewing a number of cleanup changes
    since I started as a JDT committer.  Carsten Hammer has contributed a large
    number of these.
    That said, I have noticed that Carsten has started to test and is opening
    bugs, creating test cases, and has recently started providing the odd patch
    so he is
    gradually dipping his toes into contributing more than just cleanups.

    -- Jeff J.

    On Wed, May 27, 2020 at 2:25 PM Kenneth Styrberg <kenneth@xxxxxxx
    <mailto:kenneth@xxxxxxx>> wrote:

        The main point for me was to fix bugs. At first when I did my first
        patches I also removed all warnings from the code, but was encouraged
        not to do so to simplify reviews.

        To do clean-ups as a starting point wasn't a thing for me.  Maybe a more
        junior programmer finds that more gratifying than me. My main motivation
        to continue was a responsive committer that actually took the time a
        review the patches and came with constructive comments. Even just a
        comment that he/she will look into it later, made it feel good, and that
        my time wasn't wasted.

        I think doing clean-ups doesn't help ju understand the JDT code, you
        just follow a pattern without the need to know what the code actually
        do. Sure you learn how to setup your IDE connect to GIT and commit
        changes to Gerrit, that was also a blocker for which I had to reach out
        for help to solve, so it might be a first entry for some.



        Den 2020-05-27 kl. 19:46, skrev stephan.herrmann@xxxxxxxxx

        Anything in the order of "attracting contributors"?

        Is it more attractive to start working on a component by making clean
        up changes? Do clean up changes help to get involved and serve as
        motivation to start working on functional changes, too?

        Have you observed difficulties in understanding JDT code, that were
        resolved by doing a clean up change first? Examples?


        Am 2020-05-27 16:40, schrieb stephan.herrmann@xxxxxxxxx

        To really get the full picture, I would very much like to hear from
        our new contributors, how they see the connection between clean up
        changes and functional changes / bug fixes.

        Is there any connection or are these disjoint activities?

        If connected, how exactly?


        Am 2020-05-27 16:21, schrieb stephan.herrmann@xxxxxxxxx

            Still one more suggestion / request:

            Let's please discuss this JDT issue as a JDT issue only.

            Platform is different. Hence also the p.o.v. of the Eclipse PMC
            is different from the day-to-day work in JDT.

            Let's find out what's best for JDT.


            Am 2020-05-27 13:10, schrieb stephan.herrmann@xxxxxxxxx

                In my post I mainly wanted to raise awareness that JDT code
                (even if x-internal) is potentially consumed outside JDT, and
                that even seemingly trivial changes can (and do) cause havoc

                Now that the discussion has been broadened to the general
                issue of clean ups, I would like to list three kinds of
                clean-ups that I do consider useful:

                1. Refactorings that help fixing a bug. This could be (a) a
                refactoring as part of the process of understanding some old
                code section, or (b) a refactoring that prepares for the
                desired solution.

                2. Changes that improve the ability to detect potential bugs
                using JDT's own analysis, like avoiding raw types, adding
                null annotations (careful when API is affected!).

                3. Refactorings that are performed for the purpose of testing
                our own functionality in a dog-fooding like approach.

                I suggest that (1) and (2) are encouraged on our productive
                code base, and that branches are created for experiments in
                (3). These branches can be made available for voluntary field
                testing but should not be merged to master.

                Types (1) and (2) need a bugzilla for every change.

                If (3) is performed on a branch, perhaps one umbrella bug can
                cover several experiments.


                Am 2020-05-26 20:55, schrieb Stephan Herrmann:


                    Another episode in the question whether clean up changes
                    are worth the effort they cause.

                    Today the Object Teams build got broken by
           (which doesn't even
                    have a bug that I could re-open).

                    Object Teams has tons of tests for checking that we don't
                    break JDT. In that context we have a subclass of
                    org.eclipse.jdt.testplugin.JavaProjectHelper. This no
                    longer compiles since the above change.

                    Granted, the package is marked x-internal, so JDT has
                    permission to change any way we want.

                    OTOH note that every project that extends JDT is
                    potentially interested in using also code from the JDT
                    test suite. Here we speak of a fairly large number of

                    I would not complain if the change was necessary to
                    implement new functionality or fix a bug, that's
                    certainly covered by x-internal. But I strongly doubt
                    that this "clean up" has a benefit that justifies the

                    What problem is solved by adding private constructors?
                    Are you doing it just because it is possible? The commit
                    message doesn't indicate you even thought of the
                    possibility that s.o. would subclass those classes.

                    It's too late for changing the code, because I need to fix this today for M3.

                    But please keep this in mind when doing further clean-up.

                    jdt-dev mailing list
                    jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
                    To unsubscribe from this list, visit

                jdt-dev mailing list
                jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
                To unsubscribe from this list, visit

            jdt-dev mailing list
            jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
            To unsubscribe from this list, visit

        jdt-dev mailing list
        jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
        To unsubscribe from this list, visit

        jdt-dev mailing list
        jdt-dev@xxxxxxxxxxx  <mailto:jdt-dev@xxxxxxxxxxx>
        To unsubscribe from this list, visit
        jdt-dev mailing list
        jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
        To unsubscribe from this list, visit

    jdt-dev mailing list
    jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
    To unsubscribe from this list, visit

jdt-dev mailing list
To unsubscribe from this list, visit

Back to the top