Candie distribution algorithm
Imports


import java.io.*;
import java.util.*;



It's more common to import just what you need.  E.g. 

import java.io.Scanner;


Then a reader can easily see what your dependencies are.  Many IDEs will manage dependencies for you.  

Naming


public class Candie{



The more common spelling is 

public class Candy {


When I first read this problem I was wondering why the children needed candles.  

The space between Candy { won't matter to the compiler but makes it easier for humans to read.  


 static int candieCalculator(int[] numbers) {



As a general rule, objects and classes get noun names (e.g. Candy) while methods get verb names.  Consider 

 static int calculate(int[] ratings) {


We already knew that this involved Candy, so we don't have to say that again in the method name (although you could).  An even better name in this case might be apportion, as that better reflects what we are doing with the candy.  We are apportioning them between students.  We do have to calculate that apportionment, but apportion seems a more specific (less generic) name.  And if we name it apportion, we can still name another method calculate.  

Similarly, numbers is a pretty generic name.  In this case, we know that the numbers represent a "rating score" for each student, so let's base the name on that.  E.g. ratings, scores, or ratingScores.  

Don't Repeat Yourself


        if (i==0) {
            if (numbers[i] &gt; numbers[i+1]) {
                result++;
            }
        }
        else if (i==len-1) {
            if (numbers[i] &gt; numbers[i-1]) {
                result++;
            }
        }
        else {

            if (numbers[i] &gt; numbers[i+1]) {
                result++;
            }

            if (numbers[i] &gt; numbers[i-1]) {
                result++;
            }
        }



This is longer than it needs to be.  You currently check for each edge condition and then apply a general condition if they aren't true.  Instead, consider the real problem:  if i == 0, you don't want to subtract from it as the index would be out of bounds.  So you can just say 

        if (i + 1 &lt; ratings.length) {
            if (ratings[i] &gt; ratings[i+1]) {
                result++;
            }
        }

        if (i &gt; 0) {
            if (ratings[i] &gt; ratings[i-1]) {
                result++;
            }
        }


In the typical case, you'll do the same number of comparisons as previously.  The only time you do more is if i is equal to 0.  But you can make that back by getting rid of 


    if (len==1) {
        return 1;
    }



As the new code will handle that case.  This will do two extra comparisons in that case, but that shouldn't matter as that case is pretty fast regardless.  

Correctness

I don't believe that this returns the desired result for all inputs.  Consider 


  7 1 2 3 4 5 6 7


This has an easy solution of \$1+2+3+4+5+6+7 = 28\$ but your code will instead return 13.  But that's not enough candy!  We can easily see that the first child must have a piece.  So the higher rated second child needs two pieces, etc.  

Dynamic Programming

I would agree that this is not dynamic programming.  As a general rule, dynamic programming is a system to reduce recursive calculations.  This doesn't recurse at all.  

You should think about how to express the problem in terms of subsets of the problem.  For example, if you know the apportionments for all the children less than i and greater than i, then what is the apportionment for i?  

If you figure that out, you will have fixed the bug.  

Hint:  what do you do if the apportionment for i is 0?  Obviously that's an incorrect answer to the problem.  So what should you do in that case?