Wow, it took them two major versions to find a solution to a short-sighted decision. I am impressed...
A style change that requires so much work like this one is bad. I come from a time were warnings were issued by compiler to plan for future deprecation. Not to force people to implement an inefficient style of programming and requiring hours of dumb conversion work. Given that the "diamond" operator is rather simple to implement using simple text pattern matching, I can just shiver at the # of man/hours spent to maintain/implement this parametrized "code style" since Java 5. Hardly a gem of efficiency to me :) Luc > There's no difference in performance for non-parameterized constructors > because parameterization is implemented with erasure, ie the call is the > same. It actually looks better to me to have it unparameterized, though if > my tooling was complaining as I wrote it, I might be tempted to change the > code for its sake. Oracle was sensitive to this when they introduced the > diamond operator in java 7... > > http://www.javaworld.com/community/node/7567 > > "The requirement that type parameters be duplicated unnecessarily like this > encourages an unfortunate overabundance of static factory methods, simply > because type inference works on method invocations." > > I think it's just a manner of style. For instance, the Whitesmiths > indentation style looked weird to me to for about a week, then I got over > it. Then, I looked at my old C code from years back and noticed I used to > use it. > > On Friday, November 23, 2012 11:55:11 AM UTC-5, Luc wrote: > > > > I maintain a legacy app (written in Java 1.4) with non-parametrized > > constructors > > and I still wonder if there's a real impact on the efficiency of code > > generation > > when running under Java 5. The behavior of the app has not been changed > > whatsoever after the move to Java 5. > > > > The warning about unsafe operations makes me laugh, dynamic casting in the > > code > > might be seen as unsafe, assuming you do not know what you are doing and > > end up with the wrong object type in the cast statement at runtime. > > > > Can't see how it would impact the rest of the code once the cast has been > > done > > and what is the runtime cost difference between an explicit cast and the > > implied one > > in a parametrized constructor and the related code. Maybe someone can shed > > some light on this ? To me it's more a safeguard using the type system > > than > > anything else. > > > > The #man/days to fix these has a real $ cost. In the app above, it's > > several weeks of work > > to get rid of all these warnings plus the QA involvement. Is it really > > worth it ? > > > > Lint type tools are excessively verbose about a bunch of things not really > > impacting > > the behavior of your app. It had some usefulness when I was coding in C, > > the type checking done by the compiler was minimal, I stopped using these > > tools > > years ago. Better compilers and strongly typed languages have made these > > tools quite obsolete. > > > > Now if you want absolute correctness, be prepared to dedicate a > > significant > > bucket of hours at each new version of a compiler. > > > > It's not practical in day to day business. In the case of Clojure, IMO, > > better dedicate > > more time to rewrite the JVM implementation in Clojure to minimize the > > Java > > footprint like what has been done with ClojureScript. > > > > Luc P. > > > > > Hi, Andy. To be clear I'm not talking about bugs but only about > > warnings. > > > > > > On Friday, November 23, 2012 12:54:20 PM UTC+3, Andy Fingerhut wrote: > > > > > > > > I'm not advocating all of the Java coding practices that cause > > warnings in > > > > IDEA, but my guess would be that most folks looking at the Java code > > used > > > > to implement Clojure don't use IDEA. It all compiles without warnings > > > > using javac and ant or Maven. > > > > > > > > > > > But it can't - see below. > > > > > > > > > > Also, in looking at some of these warnings myself in IDEA, out of > > > > curiosity, many of them seem to be wrong. See in-line below for > > details. > > > > > > > > On Nov 23, 2012, at 12:45 AM, Alexander Semenov wrote: > > > > > > > > Hi guys. > > > > > > > > I've opened Clojure source in IDEA and wondered why are there so many > > > > warnings? For example in > > > > > > https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.javaclassthere > > are such perls as > > > > > > > > * manual array copy; > > > > > > > > > > > > A performance warning, sure, but not a bug. > > > > > > > > * initialization of parameterized types using non-parametrized > > constructor > > > > (like ArrayList<Class[]> params = new ArrayList();); > > > > * using for loops where for each is possible; > > > > > > > > > > > > Seems like a style warning. > > > > > > > > > > > It's not a style warning. It will cause compilation warnings. > > > > > > $ cat Test.java > > > import java.util.List; > > > import java.util.ArrayList; > > > > > > public class Test { > > > static List<String> list = new ArrayList(); > > > } > > > $ javac Test.java > > > Note: Test.java uses unchecked or unsafe operations. > > > Note: Recompile with -Xlint:unchecked for details. > > > $ javac -Xlint:unchecked Test.java > > > Test.java:5: warning: [unchecked] unchecked conversion > > > static List<String> list = new ArrayList(); > > > ^ > > > required: List<String> > > > found: ArrayList > > > 1 warning > > > > > > > > > > * a bunch of conditional statements which are always true or false; > > > > > > > > > > > > I saw one warning like this that was actually true (an "if (true)" > > > > statement), and a bunch that seem wrong to me, e.g. like these: > > > > > > > > static public Expr parse(Number form){ > > > > if(form instanceof Integer > > > > || form instanceof Double > > > > || form instanceof Long) > > > > return new NumberExpr(form); > > > > else > > > > return new ConstantExpr(form); > > > > } > > > > > > > > > > > I mean mostly situations where old check is commented and substituted > > with > > > something what's already known to be true or false. There is VCS history > > > for that purpose, I think. Why to leave old code commented and introduce > > > redundant if/then/elses? > > > > > > > > > > IDEA gave warnings that "form instanceOf Integer" is always false. > > Maybe > > > > I'm ignorant of the rules of Java, but Integer is a subclass of > > Number, so > > > > that expression definitely looks like it can be true. Several of the > > > > warnings in that category I looked at seemed to be incorrect. It made > > me > > > > wonder whether this tool was worth the time to look through its > > warnings, > > > > at least in that category. > > > > > > > > * unused parameters and local variables; > > > > * and so on. > > > > > > > > I also agree that this code does its job well, but why is it so > > negligent? > > > > Doesn't being a good programmer also mean to be accurate when writing > > code > > > > and avoid any warnings? Am I misunderstanding something? > > > > > > > > Regards, Alexander. > > > > > > > > > > > > Others more familiar with IntelliJ's warnings can speak more > > accurately on > > > > the issue than I can, but I've definitely used tools before that did > > code > > > > analysis and produced many spurious warnings, such that one learned to > > > > avoid wasting one's time looking at certain categories of warnings > > from the > > > > tool. > > > > > > > > Andy > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clo...@googlegroups.com<javascript:> > > > Note that posts from new members are moderated - please be patient with > > your first post. > > > To unsubscribe from this group, send email to > > > clojure+u...@googlegroups.com <javascript:> > > > For more options, visit this group at > > > http://groups.google.com/group/clojure?hl=en > > -- > > Softaddicts<lprefo...@softaddicts.ca <javascript:>> sent by ibisMail from > > my ipad! > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
