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.javaclass > > there 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 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
