I know JDT regularly revisits defaults
and makes changes over time, so this is good input to take and consider
making changes based on the survey at the JDT level. Also feedback from
JDT on *why* some settings might be off by default is very valuable. For
example a setting may be off because it is new or experimental or not yet
Having said that I don't think JDT *has*
to be the bad guy here that changes defaults for all products. It is quite
reasonable to do this at a product level (EPP). I think it would be a positive
step if the committers implementing the features didn't have to also take
on the product manager role and make these kind of configuration decisions
for users. We've been having a parallel discussion related to UI themes
and the same situation applies there too: the person implementing the ability
to set tab colors isn't necessarily the right person to be deciding on
what initial tab color all users get by default. Having this separate "product
manager" role that is collecting and studying user data and configuring
our EPP products to match a particular community is a good thing in my
mind. The "we will get blamed so we should be the ones to decide"
argument is self-fulfilling but it does not have to be this way. When the
inevitable bug comes in complaining of the change it is easy enough to
redirect the bug to EPP and they will at least be able to point to some
concrete user data behind the decision (which is more than we've ever had
in the past).
Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
12/09/2013 04:32 PM
I will be happy to work on this issue, but, as mentioned several times
right now is the most inappropriate of all moments for additional JDT work.
So, if doing this "after March and before April" is good enough
I'll do my best.
For those who think that this is just about flipping a handful of switches:
I anticipate *significant* work to become necessary in order to adjust
60,000+ tests to new compiler results. We must find a balance between keeping
our tests stable and testing the behavior that will be shipped as the new
Apart from that, experience tells that agreement about more aggressive
is difficult to achieve among the JDT team, but keep in mind: if any new
annoy our users, it will be our team that will be blamed, so please bear
detailed discussion, but let's move it to the bug, OK?
On 12/09/2013 03:45 PM, John Arthorne wrote:
> To be concrete, the survey talked about "Potential programming
problems". In the Potential programming problems section, there are
> currently only the following set to ignore by default:
> Possible accidental boolean assignment e.g., if (a = b)
> Boxing and unboxing conversions
> Empty statement
> Unused object allocation
> Switch missing default case
> Switch case fall through
> Potential resource leak
> Missing synchronized modifier on inherited method
> Class overrides equals but not hashCode
> For the most part these are pretty reasonable warnings, with possible
exception of box/unbox which is warning about simply using a
> feature of the Java language. Just be prepared that there is backlash
*every* time we make a change that introduces warnings for
> people - although at least in this case we have some data to back
up the decision.
> From: Mickael Istria <mistria@xxxxxxxxxx>
> To: Ian Skerrett <ian.skerrett@xxxxxxxxxxx>, "'Discussions
about the IDE'" <ide-dev@xxxxxxxxxxx>, "'Lars Vogel'"
> <lars.vogel@xxxxxxxxx>, "'Daniel Megert'" <daniel_megert@xxxxxxxxxx>,
> Date: 12/09/2013 09:13 AM
> Subject: Re: [ide-dev] Survey results
> Sent by: ide-dev-bounces@xxxxxxxxxxx
> On 12/09/2013 02:53 PM, Ian Skerrett wrote:
> If you implement that change it will definitely annoy this minority.
> And what about the majority?
> Also, due to the nature of the change, my assumption is that a subset
of people that said ‘yes’ did not appreciate the impact of the
> change so when it is implemented they will wish they had voted ‘no’.
> We've all reworked the question several times to make it explicit.
I thought we've agreed the question was good enough so that we
> could trust the outcome of the survey and turn it into a concrete
action (Yes or No to all warnings). Why deciding to almost ignore
> the vote now? Or why even asking the question if it's to ignore 65%
of "Yes" ?
> 65% of people have expressed they'd like all warnings. We've discussed
that the survey and reaction to results would also be a way
> to encourage the community to give feedback. I think letting 35% of
community decide of everything is not fair at all.
> Mickael Istria
> Eclipse developer at _JBoss, by Red Hat_ <http://www.jboss.org/tools>_
> __My blog_ <http://mickaelistria.wordpress.com/>-
> ide-dev mailing list
> ide-dev mailing list