That seems reasonable to me, Ruben. It's not practical to "always specify the template type" because we don't control all of the APIs we use. A JPA query method might return Object, and we cast it because we know the return type. We're not going to change the JPA API, so fixing the annotations in our code seems the most reasonable. Thanks for taking this task on.
Josh 2011/5/4 Rubén Pérez <[email protected]> > Hello, > > Tobias, thanks for your answer (at least I know somebody read me!). I would > like the option 1., but as nobody but you answered, I guess I should go and > do the #2. > > I would like, though, to keep the use of raw types to a minimum, because > it's a good programing practice and less error-prone, but I guess nobody is > willing to re-inspect and modify their code according to that thought... > > I'm creating a ticket and assigning it to myself. This should be done in a > really short while. > > Best regards > > > 2011/5/4 Wunden Tobias <[email protected]> > >> Ruben, >> >> This looks like a good suggestion to me and I think you should execute on >> it. i have come accross this warning too, and fixed in it many places >> already. >> >> Tobias >> >> On 02.05.2011, at 14:55, "Rubén Pérez" <[email protected]<mailto: >> [email protected]>> wrote: >> >> Dear List, >> >> I don't usually pay attention to the warnings that eclipse reports when >> building the system. However, the other day I took a look and I saw that >> quite a lot of them are caused by the annotation: >> @SuppressWarnings('rawtypes'). This annotation is used to avoid the compiler >> warnings about the declaration or instantiation of some variables which >> require template arguments (such as List<type> or Map<typeA, typeB>) but are >> not provided. >> >> I did a little search and found out that this is because "rawtypes" is not >> a standard argument for the annotation @SuppressWarnings. Instead, the >> recommended an official keyword is 'unchecked'. Using a non-standard >> argument is causing that the annotation itself causes a warning, while it is >> not avoiding the warning which it was formerly intending to suppress. So, >> ironically, we end up with to different warnings instead of the single one >> we would get without using the annotation in the first place. >> >> This is not as important as to be called "problem" anyway, but I would >> like to propose to substitute all the @SuppressWarnings('rawtypes') with >> @SuppressWarnings('unchecked'), to avoid this kind of conflicts. However, as >> I feel that I don't know everything and there's probably a good reason for >> that keyword to be used, I would be happy if some of this measures are taken >> (sorted by my level of preference): >> >> 1. Avoid using "raw types" in the first placel. In other words, always >> specify the template type to avoid the warning in the first place. I agree >> that this is not possible in all the cases, but couldn't just try at least? >> :) >> 2. Change all the "rawtypes" appearances to "unchecked", so that no >> warnings are created. This can be done in combination with the option 1. >> where using raw types is unavoidable. This was the original intention when >> the annotation was used, after all. >> 3. If "rawtypes" needs to be kept as it is for some reason: >> * I'd like to know why this is so, and why Eclipse does not like >> it, if it's possible >> * Include at list the two keywords, so that at least the "raw types" >> warning is ignored. I'm talking about the syntax >> "@SuppressWarnings({'unchecked', 'rawtypes'})" that I've seen in some >> places. >> >> I hope that I'm not being too picky with this. >> >> Best regards >> _______________________________________________ >> Matterhorn mailing list >> [email protected]<mailto:[email protected]> >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> [email protected]<mailto: >> [email protected]> >> _______________________________________________ >> _______________________________________________ >> Matterhorn mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> [email protected] >> _______________________________________________ >> > > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
