Interpreting compiler errors and exception messages is challenging for novice programmers. Presenting examples of how other programmers have corrected similar errors may help novices understand and correct such errors. This paper introduces HelpMeOut, a social recommender system that aids the debugging of error messages by suggesting solutions that peers have applied in the past. HelpMeOut comprises IDE instrumentation to collect examples of code changes that fix errors; a central database that stores fix reports from many users; and a suggestion interface that, given an error, queries the database for a list of relevant fixes and presents these to the programmer. We report on implementations of this architecture for two programming languages. An evaluation with novice programmers found that the technique can suggest useful fixes for 47 % of errors after 39 person-hours of programming in an instrumented environment.

Since version 1.5, generics (parametric polymorphism) are part of the Java language. Experience with implementations of the Java Language Specification such as ejc and javac have shown that the type error messages provided by these tools leave more than a little to be desired. Type error messages are often uninformative and sometimes show artifacts of the type checking process in the messages. Evidently, providing good type error messages for a language as large and complex as Java currently is, is not as easy as one would hope. To alleviate the problem, we describe a number of heuristics that suggest fixes for generic method invocations in Generic Java, and illustrate their effect by means of examples. The heuristics are part of an extension to the original type checking process that has been implemented into the JastAdd Extensible Java Compiler. Keywords: generics compilers, type checking, error reporting, error correcting, heuristics, Java 1 <T> List<T> foo(Map<T, ? super T> a){} Map<Number, Integer> m = null; List<Integer> ret = foo(m); javac: cxt_heuristic/Test1.java:6: <T>foo(Map<T,? super T>) in Test1 cannot be applied to (Map<Number,Integer>) ejc: The method foo(Map<T, ? super T) in the type Test1 is not applicable for the arguments (Map<Number,Integer>) 1

Java is known to be a strongly type safe language, but there are some coding conventions and when these are used in some applications like persistent storage through serialization may generate unreliable or wrong output. Such cases should be caught and modified as per requirement to produce a modified safe program. This can be achieved by designing a translator tool which can catch unsafe code segments and produce a modified safe code segment. When a singleton class is serialized it is necessary to include a special method from serializable interface within it then only it gives us right result. If this method is not there within the class then it produces unpredictable results. Such results may violate type safe property of object oriented programming. Here the translator is designed using ANTLR which is going to check availability of this method in the input java file. If this method is not found then add the method and generate a type safe program at output.The same translator can be applicable for generics and their limitations. Here the translator is going to trace if there are any unchecked warnings or runtime exception then modify the input program to generate a safe program at output. This will lead to minimize limitations of java generics.