Scientific Calculator in Minecraft by a 16 year old

This is a  very interesting fact:

"New submitter petval tips another amazing Minecraft project: a functioning scientific/graphing calculator. "On a virtual scale, the functional device is enormous — enough so that anyone in the real world would become a red blot of meat and bone staining the road if they fell from the very top. Honestly, his virtual machine looks more like a giant cargo ship ripped from a sci-fi movie than a working calculator. Yet type your problem out on the keypad, and the answer appears on a large white display mounted on the side of the monstrous brick structure." The creator says it can do "6-digit addition and subtraction, 3-digit multiplication, division and trigonometric/scientific functions ... Graphing y=mx+c functions, quadratic functions, and equation solving of the form mx+c=0." We've previously discussed the creation of a 16-bit ALU in Minecraft."
 

Open Source Software Evaluation

Recently I had to evaluate a number of open source software to recommend the adoption of a solution suitable for the existing requirements.

During the evaluation I've extracted the following methodology which may be useful for future evaluations:

• Community support - how much support is provided by the community
• Access to the latest code - whether the up to date code is available to the community
• Documentation - how extensive is the documentation if any
• Coding Standards  - any well established open source software should have coding standards and guidelines for development.
• Development team - it is important to determine the size of the development team and the number of contributors to determine the adoption 
• User interface - how intuitive is the user interface to enable the adoption and eventually the success of the solution
• Functionality - does it cover the requirements and level of sophistication (simple is better)
• Security - how secure is the solution according to the current standards. In case of web application solution how much it covers the OWASP (Open Web Application Security Project) and WASC(Web Application Security Consortium) guidelines to cover all the latest security aspects and to be able to pass ISO certification if requiredImplementation programming language - to determine the skills required, security level, software robustness (strongly typed language are in general more robust) etc.
• Technologies -  analyze used technologies to determine their quality
• Contemporary methodologies and technologies - does the solution uses the latest methodologies and technologies.
• Adoption - how many success stories from well known organizations
• Build methodology - how good is the documentation and how easy is to perform a build
• Debug -  how easy is to debug this software
• Learning curve - how easy is to learn existing implementation
• Scalability - how scalable is the solution
• Testing coverage - how much testing coverage has the solution
• Responsiveness - how performant is the solution using performance tools
• Architecture - determine the architectural quality of the software, how many tiers has the application and how decoupled are various components
• Open issues - determine the amount of open issues (critical and high priority) and how contemporary are the issues (to determine if there is real support for the software). It is important to determine if there is an issue tracking system.
• Versions/Releases - how many versions per year and how many versions in the last year (to make sure the software is in an active state), latest stable release
• Installation - analyze installation process to determine how easy is to install
• Operating System -  platform independence
• Browser compatibility - in case of web application whether or not all the popular browsers are supported
• Licensing - this is a very important aspect in case this will be used as a commercial solution
• Pricing - some of the open sources solutions offer services, software modules for a certain price in addition to the open source solution.
• Maturity - how mature is the software, for how log has been released (first release date) 
• API/SDK - does the software provide means to extend the existing functionality without touching the existing code. 
• Forum - is there any forum for this software to address existing questions 
• Roadmap - is there any roadmap for the software 
• Version control system - which version control system is used  if any 
• Software maintenance utilities - are there any utilities to simplify maintenance 
• Visible problems - how many issues discovered during the software trial
• Language -  determine the extent of language support if this is necessary
• Code quality:
• Error handling - level of sophistication, detail and how well is done
• Comments - how extensive is the code commented if any
• Class/function size
• General Code Smoke Test - does the code build correctly? Execute as expected? Is it understandable?
• Resource Leaks - is allocated memory freed? Are objects released more than once
• Control Structures - are loop ending conditions accurate? No unintended infinite loops?
• Performance - do recursive functions run within a reasonable amount of stack space? Is blocking system calls used?
• Reinvents the Wheel -does the code recreate some function that exists in a library included in the code base (or perhaps something from a utility library)

• Certification program - is there any certification program
• Commercial manuals - whether or not there are commercial manuals available
• Online help - whether or not it provides help online
• Users conference - whether or not community organizes conferences for user
• Reliance on non-open source software - determine if it requires to function with other software which is not open source (can be a database).

Memory leaks in Java

I would like to discuss here a few points regarding memory management in Java.

As a C++ veteran, one of my favorite subjects is memory management provided for a programming language. One of the reasons why I've adopted Java is that its Runtime provides a state of art garbage collection mechanism.
Memory allocation in C++ was sometimes a burden, always prone to memory leaks and dangling pointers. Even when C++11 introduced better garbage collection through smart pointers, automatic garbage collection in Java becomes a superior concept and programming is achieved at a higher level. This new level means that you don't need to deal with memory management at all or so it seems.

Is it possible to leak memory in Java?

Well the answer here is YES for the following reasons:

• Java as a garbage collected languages have difficulty to release scarce system resources (database handlers, graphic resources, file handlers etc.), as it is difficult to define (or determine) when or if a finalizer method might be called.    
• Java uses manual memory management for scarce system resources; any object which manages graphic resources for example is expected to implement dispose method, which releases any such resources and marks the object as inactive. Usually developers are expected to invoke dispose manually as appropriate; to prevent "leaking" of scarce graphics resources.
• If a program holds a reference to a heap chunk that is not used during the rest of its life, it is considered a memory leak because the memory could have been freed and reused. The garbage collector won't reclaim it due to the reference being held by the program. A Java program could run out of memory due to such leaks.

Let's try next to come up with some specific examples of memory leaks:

• Not calling the finalize method (depending how Java implements finalizers) to release graphics resources.
• A database connection which is never released
• A file handler open and never closed
• The application creates a long-running threads or thread pool.
• The thread loads a class using ClassLoader.
• Caches or reflective utilities some times hold a reference to ClassLoader or a variant of ClassLoader (like WebappClassLoader, ThreadContextClassLoader). When those references cannot be claimed memory leak happens.
• The class allocates a large chunk of memory, stores a strong reference to it in a static field, and then stores a reference to itself in a ThreadLocal. Allocating the extra memory is optional (leaking the Class instance is enough), but it will make the leak work that much faster.
• The thread clears all references to the custom class or the ClassLoader it was loaded from.

Java Exceptions Best Practices

Exceptions were introduced into the Java language to separate the functional code from error-handling code. They allow for clear propagation path of a specific error.
There are two types of exceptions: checked exceptions - compiler enforced exceptions that are instances of the Exception class or one of its subclasses and the unchecked exceptions, runtime exceptions like RuntimeException and its subclasses and Error and its subclasses.
A compiler for the Java programming language checks, at compile time, that a program contains handlers for checked exceptions.

Many times in my carrier as a software developer I had to read, debug, review code from some other developers. Many times I've seen silenced exceptions like:

try {
    someFunction();   // may throw an exception 
} catch (Exception e) {                  
    // do nothing}

I believe this type of code is Evil. Something happens in the code and the developer decides that the best way to go is to do nothing. If this code influences other code there will be no way to know what really happened with the code. If the code does not influence other code it is still no way to know that some functionality was not executed. The least a programmer can do in such situation is to write some minimal information to the log file.
Imagine that you are not able to debug a code that runs in production environment, the only means to investigate a problem is the log files. Every time a checked exception is correctly handled your job will be easier to investigate potential issues.

I have next a number of advices to follow when dealing with exceptions:

• NEVER SILENCE AN EXCEPTION like in my above example.
• Only throw checked exceptions (not derived from RuntimeException), if the caller has a chance to handle it.

     class ApplicatioException extends Exception { // classic checked exception
        public ApplicationException (String str) {

            super (str);

        }
     }

     ...

     

     class  Application {

        public void doSomeAction () throws ApplicationException {

            ...

            if (bad) {

                throw new ApplicationException ();

            }

        } 

        public void someOtherAction () {

            try {

              this.doSomeAction();                            

            } catch (ApplicatioException ex) {

              logger.error("doSomeAction failed miserably!"); // log information

            }

        }

     }

     

• Checked exceptions are an official part of the interface, therefore do not propagate checked exceptions from one abstraction layer to another, because usually this would break the lower abstraction. E.g. do not propagate SQLException to another layer, because SQLExceptions are an implementation detail, that may change in the future and such changes should not affect the interfaces and their callers.

     class DBUtil{
        public static void closeConnection
        (Connection conn){
        try{
            conn.close();
        } catch(SQLException ex){
            throw new DBUtilException(ex); // propagate exception to the next level
        }
     }

•  Never throw NullPointerException or RuntimeException. Use either IllegalArgumentException, or NullArgumentEception (which is a subclass of IllegalArgumentException anyway). If there isn't a suitable subclass available for representing an exception, create your own.

     class DBUtil{
        public static void closeConnection
        (Connection conn){
           try{
              conn.close();
           } catch(SQLException ex){

               throw new RuntimeException(ex); // never throw an exception like this    

        }
     }

        

• Only if it is not possible to return special result values cleanly, use checked exceptions to force the caller to decide the situation. The caller should deescalate the situation by catching and handling one or more checked exceptions, e.g. with special result values or by escalating with an unchecked exception, because the situation is an error, that can not be handled.
• Exceptions that signal programming errors or system failures usually cannot be handled/repaired at runtime -> unchecked exception.
• Do NOT throw an exception, if you only suppose the caller of your code could have a problem with a special result. Try to return a special result value instead e.g., null, and let the caller decide with a regular if-else-statement. If the caller really has a problem, HE WILL throw an exception on his own.

    class Example{
        public Result exampleAction (){

            Result result = null;

            ...                               // some result processing

            return result;                    // return the result in any form

            }
        }

        

        public boolean processResult () throw ResultException {

            Result result = exampleAction();

            if (result == null) {

                return new ResultException (); // caller has a problem here; unexpected result

            }

            else if (!isValid(result)) {

                return fail;                   // result failure

            }

             

            return success;

        }
     }

• The intention of exception-handling is to separate real error-handling from the regular part of the code, so don't force the caller to mix it with unnecessary exceptions.

• Only if your code really has a problem to continue e.g., when a parameter is invalid, feel free to throw an exception!
•  Don't catch generic exceptions. Sometimes it is tempting to be lazy when catching exceptions and do something like this:

  try {
      someIOFunction();        // throws IOException 
      someParsingFunction();   // throws ParsingException 
      someSecurityFunction();  // throws SecurityException  
  } catch (Exception e) {      // catch all exceptions 
      handleError();           // with one generic handler!
  }

  You should not do this. In almost all cases it is inappropriate to catch generic Exception or Throwable. Throwable includes Error exceptions as well. It is very dangerous. It means that Exceptions you never expected (including RuntimeExceptions like ClassCastException) end up getting caught in application-level error handling. It obscures the failure handling properties of your code. It means if someone adds a new type of Exception in the code you're calling, the compiler won't help you realize you need to handle that error differently. And in most cases you shouldn't be handling different types of exception the same way, anyway.

I believe proper exception handling is a good indicator that a programmer understands the programming language he/she uses and is able to do good job.