Execution of static blocks - java

Why is this code a compilation error?
class Test1{
static {
System.out.println(x);
}
static int x = 10;
}
While the below code compiles and runs fine?
class Test2{
static int x = 10;
static {
m1();
System.out.println("base SB");
}
public static void main(String args[]){
m1();
System.out.println("base main method");
}
public static void m1(){
System.out.println(y);
}
static int y = 20;
}
If it declares y here, why not in the previous code.
The output of below code is:
0
base SB
20
base main method
I think Java does not support forward referencing.

It may be an unsatisfying answer, but this is just how the language was defined, specifically here.
The restrictions above are designed to catch, at compile time, circular or otherwise malformed initializations
But you can get around the restriction quite easily like in the question, or just by using Test21.x instead of just x, so it is not particularly robust:
class Test21{
static {
// This is legal, but it is uninitialized, and thus prints 0.
System.out.println(Test21.x);
}
static int x=10;
}
On balance, it is probably better to force you to jump through a small hoop, to make you stop and think about what you are doing, and only to proceed if you really intend to do that.
Ultimately, the language can't entirely stop you shooting yourself in the foot. It can only make it harder to do so.

Your second test case prints zero first which I would assume would not be idiomatic for most people.
This is simply a case of the compiler not being smart enough to catch a probable mistake which you have made.
It is able to detect the forward reference in the first case -- lucky! If it didn't, your program would have printed zero at runtime since the variable would not have been initialized yet. So the compiler saved you from a probable bug.
It is not able to detect it in the second case, since you have introduced a level of indirection with the additional method call to m1 -- unlucky!
In an ideal world, the second code sample wouldn't compile either.

Related

Why Must this method be static(Java)?

For some background, I'm currently on chapter 8 in my book, we finished talking about arraylists, arrays, if statements, loops etc. Now this part of the book talks about call by reference,value and some other pretty neat things that seem odd to me at first.I've read What situation to use static and some other SO questions, and learned quite a bit as well.
Consider the following example my book gave (among many examples)
There is another reason why static methods are sometimes necessary. If
a method manipulates a class that you do not own, you cannot add it to
that class. Consider a method that computes the area of a rectangle.
The Rectangle class in the standard library has no such feature, and
we cannot modify that class. A static method solves this problem:
public class Geometry
{
public static double area(Rectangle rect)
{
return rect.getWidth() * rect.getHeight();
}
// More geometry methods can be added here.
}
Now we can tell you why the main method is static. When the program
starts, there aren’t any objects. Therefore, the first method in the
program must be a static method.
Ok, thats pretty cool, up until now I've just been really blindly putting public in front of all my methods, so this is great to know. But the review small problem on the next page caught my attention
The following method computes the average of an array list of numbers:
public static double average(ArrayList<Double> values)
Why must it be a static method?
Here I was like wait a sec. I'm pretty sure I did this without using static before. So I tried doing this again and pretty easily came up with the following
import java.util.ArrayList;
class ArrList
{
private double sum;
public ArrList()
{
sum = 0;
}
public double average(ArrayList <Double> values)
{
for(int i = 0; i < values.size() ; i++)
{
sum+=values.get(i);
}
return sum / values.size();
}
}
public class Average
{
public static void main(String [] args)
{
ArrList arrListObj = new ArrList();
ArrayList<Double> testArrList = new ArrayList<Double>();
testArrList.add(10.0);
testArrList.add(50.0);
testArrList.add(20.0);
testArrList.add(20.0);
System.out.println(arrListObj.average(testArrList));
}
}
TLDR
Why does my book say that public static double average(ArrayList<Double> values) needs to be static?
ATTEMPT AT USING STATIC
public class Average
{
public static void main(String [] args)
{
ArrayList<Double> testArrList = new ArrayList<Double>();
ArrayList<Double> testArrListTwo = new ArrayList<Double>();
testArrList.add(10.0);
testArrList.add(50.0);
testArrList.add(20.0);
testArrList.add(20.0);
testArrListTwo.add(20.0);
testArrListTwo.add(20.0);
testArrListTwo.add(20.0);
System.out.println(ArrList.average(testArrList));
System.out.println(ArrList.average(testArrListTwo)); // we don't get 20, we get 53.3333!
}
}
It doesn't.
The only method which needs to be static is the initial main() method. Anything and everything else is up to you as the programmer to decide what makes sense in your design.
static has nothing to do with public accessors (as you allude to), and it has nothing to do with the technical operation being performed. It has everything to do with the semantics of the operation and the class which holds it.
An instance (non-static) method exists on a particular instance of a class. Semantically it should perform operations related to that specific instance. A static method exists on a class in general and is more conceptual. It doesn't do anything to a particular instance (unless it's provided an instance of something as a method argument of course).
So you really just need to ask yourself about the semantics of the operation. Should you need new instance of an object to perform an operation? Or should the operation be available without an instance? That depends on the operation, on what the objects represent, etc.
If it is not static, then any other class that wants to use this method must first create an instance of this object.
From some other class:
Average.average(new ArrayList<Double>()); // legal only if static
new Average().average(new ArrayList<Double>()); // necessary if not static
// and only makes sense if Average can be instantiated in the first place
It's legal to make it an instance (i.e. not static) variable, but the method is actually harder to understand. If it is static then whoever reads the code knows it does not use any member variables of the class.
// In the class body
int x = 0; // member variable
public static double average() {
x = x + 1; // illegal
}
The less something can do, the easier to understand what it does do.
Static methods like the area, average are usually utility functions. You don't need any object to use an utility function. For example consider Math.pow you don't need to instantiate any object to use the power function, just use Math.pow(10.0, 2.0) to get (10.0)^2
In short :
Static method means class method, that is no instance of that object is needed to invoke.
whereas your average method is an instance method, you need an object to invoke that method.

eclipse acting weird when creating methods

I don't see what could be wrong here, I was working on a different method but had some problems so I tried to simplify it to check where could the mistake be but I ended going up into this very simple method and still I have the same error.
When I put the mouse over the redX at line 6 I get a message saying:
multiple markers at this line
-Syntax error on token "(",;expected
-Syntax error on token ")",;expected`
mouse at line 7 says:
void method cannot return a value
2 quick fixes available
change method return type to 'int'
change to 'return;'
I changed public static void to public static int and also changed the method's modifier but the error at line 6 appears everytime.
I don't see anything wrong here but I think I'm making a mistake that just needs a simple fix, am I going crazy? never had this particular problem before
The problem is that you are declaring a method called y within the main method. In Java, you cannot nest method declerations.
You will have to move it outside the main method scope or else, declare a private inner class which will hold your y method.
In short:
public class gat {
public static void main(String args[]) {
...
}
int y(int a) {
return a + 5;
}
}
Or:
public class gat {
public static void main(String args[]) {
class inner {
int y (int a) {
return a + 5;
}
}
}
}
The first approach is the most common, however you sometimes do end up using the second approach, especially when dealing with Swing Events and other threading aspects.

While loop boolean evaluation

Example 1:
public class ExampleWhile {
public static void main(String args[]) {
int a = 10, b = 20;
while (a < b)
{
System.out.println("hello");
}
System.out.println("hi");
}
}
Example 2:
public class ExampleWhile2 {
public static void main(String args[]) {
while (true)
{
System.out.println("hello");
}
System.out.println("hi"); // Compile time error saying unreachable statement
}
}
Why there is a compile time error in example 2 when example 1 runs without error?
Because the compiler is "clever" enough to know that while(true) is an infinite loop, hence System.out.println("hi"); would never be executed.
It is not clever enough to infer the same with variables, even when scoped to the method.
With compile-time constants (static final int makes the integer a compile-time constant. Compile time constants will be available as part of the byte-code itself), it's another story:
static final int A = 0;
static final int B = 1;
public static void main(String[] args) {
while (B > A) {
}
// won't compile!
System.out.println("Foo");
}
The compiler does not know about the values of a and b, so it doesn't see it as an infinite loop with an unreachable statement.
With while(true), on the other hand, the compiler knows there 'll be trouble.
The Java Language Specification gives specific rules, in 14.21. Unreachable Statements, for the compile time error.
The rule that applies to the sample code is:
A while statement can complete normally iff at least one of the
following is true:
The while statement is reachable and the condition expression is not a constant expression (§15.28) with value true.
There is a reachable break statement that exits the while statement.
The first of the two conditions is true for Example 1, but false for Example 2. The second condition is false for both examples. As far as the language specification is concerned, there is a possibility that the first loop might complete normally, allowing control to reach the following statement. There is no such possibility for the second example.
The rules achieve two benefits. There is a single set of rules for whether a sequence of characters constitutes a compilable Java program, regardless of the choice of compiler. The rules can be implemented very simply.

What is the purpose of void?

public class test
{
public static void main(String[] args)
{
int x = 5;
int y = 10;
multiply(x,y);
}
public static void multiply(int x, int y)
{
int z = x*y;
System.out.println(z);
}
}
I am new to programming and I am confused on a few things.
Why is it correct to use void? I thought void is used in order to specify that nothing will be returned but, the multiply method returns z.
Do all programs require that you have exactly "public static void main(String[] args)"? What exactly is the purpose of the main method and what do the parameters "String[] args" mean? Would the program work if the main method was removed?
Thank You!
First, the multiply method does not return anything; it prints the product, but does not return any value.
public static void multiply(int x, int y)
{
int z = x*y;
System.out.println(z); //may look like a return, but actually is a side-effect of the function.
} //there is no return inside this block
Secondly, public static void main provides an entry point into your program. Without it, you cannot run your program. Refer to the Java documentation for more information on the usage of public static void main.
The String[] args here means that it captures the command line arguments and stores it as an array of strings (refer to the same link posted above, in the same section). This array is called args inside your main method (or whatever else you call it. Oracle cites argv as an alternate name)
System.out.print tells the program to print something to the console, while return is the result of the method. For example, if you added print all over your method to debug (a common practice), you are printing things while the program runs, but this does not affect what the program returns, or the result of the program.
Imagine a math problem - every step of the way you are "print"ing your work out onto the paper, but the result - the "answer" - is what you ultimately return.
When a method does not return anything, you specify its return type as "void". Your multiply method is not returning anything. Its last line is a print statement, which simply prints the value of its arguments on the standard output. If the method ended with the line "return z", then you would not be able to compile the program with the "void" return type. You would need to change the method signature to public static int multiply(int x, int y).
All Java programs do require the public static void main(String[] args) if they are to be executable. It is the starting point of any runnable Java program. Here's what it means:
a. public - the main method is callable from any class. main should always be public because it is the method called by the operating system.
b. static - the main method should be static, which means the operating system need not form an object of the class it belongs to. It can call it without making an object.
c. void - the main method does not return anything (although it may throw an Exception which is caught by the operating system)
d. String[] args - when you run the program, you can pass arguments from the command line. For example, if your program is called Run, you can execute the command java Run 3 4. In that case, the arguments would be passed to the program Run in the form of an array of Strings. You would have "3" in args[0] and "4" in args[1].
That said, you could have a Java program without a main, which will not be runnable.
I hope that helps.
Why is it correct to use void? I thought void is used in order to specify that nothing will be returned but, the multiply method returns z.
No
multiply method does not return z. However, you are correct, void is in fact used to specify that nothing will be returned.
Do all programs require that you have exactly "public static void main(String[] args)"? What exactly is the purpose of the main method and what do the parameters "String[] args" mean? Would the program work if the main method was removed?
yes, all programs must have a main function that looks like public static void main(String[] args).
Like others said, the multiply method does NOT return anything. The other answers explained why that is.
However it would also be helpful to mention that when you use void that method can not return anything. In contrast, if you set your method to return anything (not to void) you are required to return that type of value.
For example:
public static void main(String[] args){
int a;
a = returnInt();
}//End Method
public static int returnInt(){
int z = 5;
return z;
}//End Method
The main method does not return anything, which is why we use void. The returnInt method returns an integer. The integer that the method returns is z. In the main method where a = returnInt(); that sets the value of a to the value returned from returnInt(), in this case, a would equal 5.
Tried to keep it simple, hope it makes sense.
public means that the method is visible and can be called from other objects of other types. Other alternatives are private, protected, package and package-private. See here for more details.
static means that the method is associated with the class, not a specific instance (object) of that class. This means that you can call a static method without creating an object of the class.
void means that the method has no return value. If the method returned an int you would write int instead of void.
The combination of all three of these is most commonly seen on the main method which most tutorials will include.
credits to Mark Bayres
The multiply() method in your example does not return the value of z to the calling method, rather it outputs the value of z (e.g., prints it to the screen).
As you said, the void type keyword means that the method will not return a value. Methods like this are intended to "just do something". In the case of main(), the method will not return a value, because there is no calling method to return it to -- that's where your program begins.
OK, technically, that last comment is not accurate; it actually is possible to have your main return a value to the operating system or process that launched the program, but it isn't always necessary to do so -- especially for simpler console-based programs like those you'll write when you're just getting started! :)
Void class is an uninstantiable class that hold a reference to the Class object representing the primitive Java type void.
and The Main method is the method in which execution to any java program begins.
A main method declaration looks like this
public static void main(String args[]){
}
The method is public because it be accessible to the JVM to begin execution of the program.
It is Static because it be available for execution without an object instance. you may know that you need an object instance to invoke any method. So you cannot begin execution of a class without its object if the main method was not static.
It returns only a void because, once the main method execution is over, the program terminates. So there can be no data that can be returned by the Main method
The last parameter is String args[]. This is used to signify that the user may opt to enter parameters to the java program at command line. We can use both String[] args or String args[]. The Java compiler would accept both forms.
Why is it correct to use void? I thought void is used in order to
specify that nothing will be returned but, the multiply method returns
z.
Your multiply method is correct to have void since it is returning nothing, it is just printing to the console.
Returning something means gives out a result to the programm for further computation.
For example your methode with return of the result would look like this:
public static int multiply(int x, int y)
{
int z = x*y; //multipling x and y
System.out.println(z); //printing the restult to the console
return z; //returning the result to the programm
}
this "new" method can be used like this for example:
public static void main(String[] args)
{
int x = 5;
int y = 10;
int result = multiply(x,y); //storing the returnen value of multiply in result
int a = result + 2; //adding 2 to the result and storing it in a
System.out.println(a); //printing a to the console
}
Output:
50
52
Do all programs require that you have exactly "public static void
main(String[] args)"? What exactly is the purpose of the main method
and what do the parameters "String[] args" mean? Would the program
work if the main method was removed?
This mehtod seves a the etry point for your programm. This meas the first thing that is executet of your programm is this mehtod, removing it would make the programm unrunneable.
String[] args stands for the commandline arguments you can give to you programm befor starting over the OS (OS = Windows for example)
The exact purpose of all of the words is very well explained in the other answers here.

Are Java static calls more or less expensive than non-static calls?

Is there any performance benefit one way or another? Is it compiler/VM specific? I am using Hotspot.
First: you shouldn't be making the choice of static vs non-static on the basis of performance.
Second: in practice, it won't make any difference. Hotspot may choose to optimize in ways that make static calls faster for one method, non-static calls faster for another.
Third: much of the mythos surrounding static versus non-static are based either on very old JVMs (which did not do anywhere near the optimization that Hotspot does), or some remembered trivia about C++ (in which a dynamic call uses one more memory access than a static call).
Four years later...
Okay, in the hope of settling this question once and forever, I have written a benchmark which shows how the different kinds of calls (virtual, non-virtual, static) compare to each other.
I ran it on ideone, and this is what I got:
(Larger number of iterations is better.)
Success time: 3.12 memory: 320576 signal:0
Name | Iterations
VirtualTest | 128009996
NonVirtualTest | 301765679
StaticTest | 352298601
Done.
As expected, virtual method calls are the slowest, non-virtual method calls are faster, and static method calls are even faster.
What I did not expect was the differences to be so pronounced: Virtual method calls were measured to run at less than half the speed of non-virtual method calls, which in turn were measured to run a whole 15% slower than static calls. That's what these measurements show; the actual differences must in fact be slightly more pronounced, since for each virtual, nonvirtual, and static method call, my benchmarking code has an additional constant overhead of incrementing one integer variable, checking a boolean variable, and looping if not true.
I suppose the results will vary from CPU to CPU, and from JVM to JVM, so give it a try and see what you get:
import java.io.*;
class StaticVsInstanceBenchmark
{
public static void main( String[] args ) throws Exception
{
StaticVsInstanceBenchmark program = new StaticVsInstanceBenchmark();
program.run();
}
static final int DURATION = 1000;
public void run() throws Exception
{
doBenchmark( new VirtualTest( new ClassWithVirtualMethod() ),
new NonVirtualTest( new ClassWithNonVirtualMethod() ),
new StaticTest() );
}
void doBenchmark( Test... tests ) throws Exception
{
System.out.println( " Name | Iterations" );
doBenchmark2( devNull, 1, tests ); //warmup
doBenchmark2( System.out, DURATION, tests );
System.out.println( "Done." );
}
void doBenchmark2( PrintStream printStream, int duration, Test[] tests ) throws Exception
{
for( Test test : tests )
{
long iterations = runTest( duration, test );
printStream.printf( "%15s | %10d\n", test.getClass().getSimpleName(), iterations );
}
}
long runTest( int duration, Test test ) throws Exception
{
test.terminate = false;
test.count = 0;
Thread thread = new Thread( test );
thread.start();
Thread.sleep( duration );
test.terminate = true;
thread.join();
return test.count;
}
static abstract class Test implements Runnable
{
boolean terminate = false;
long count = 0;
}
static class ClassWithStaticStuff
{
static int staticDummy;
static void staticMethod() { staticDummy++; }
}
static class StaticTest extends Test
{
#Override
public void run()
{
for( count = 0; !terminate; count++ )
{
ClassWithStaticStuff.staticMethod();
}
}
}
static class ClassWithVirtualMethod implements Runnable
{
int instanceDummy;
#Override public void run() { instanceDummy++; }
}
static class VirtualTest extends Test
{
final Runnable runnable;
VirtualTest( Runnable runnable )
{
this.runnable = runnable;
}
#Override
public void run()
{
for( count = 0; !terminate; count++ )
{
runnable.run();
}
}
}
static class ClassWithNonVirtualMethod
{
int instanceDummy;
final void nonVirtualMethod() { instanceDummy++; }
}
static class NonVirtualTest extends Test
{
final ClassWithNonVirtualMethod objectWithNonVirtualMethod;
NonVirtualTest( ClassWithNonVirtualMethod objectWithNonVirtualMethod )
{
this.objectWithNonVirtualMethod = objectWithNonVirtualMethod;
}
#Override
public void run()
{
for( count = 0; !terminate; count++ )
{
objectWithNonVirtualMethod.nonVirtualMethod();
}
}
}
static final PrintStream devNull = new PrintStream( new OutputStream()
{
public void write(int b) {}
} );
}
It is worth noting that this performance difference is only applicable to code which does nothing other than invoking parameterless methods. Whatever other code you have between the invocations will dilute the differences, and this includes parameter passing. Actually, the 15% difference between static and nonvirtual calls is probably explained in full by the fact that the this pointer does not have to be passed to the static method. So, it would only take a fairly small amount of code doing trivial stuff in between calls for the difference between different kinds of calls to be diluted to the point of having no net impact whatsoever.
Also, virtual method calls exist for a reason; they do have a purpose to serve, and they are implemented using the most efficient means provided by the underlying hardware. (The CPU instruction set.) If, in your desire to eliminate them by replacing them with nonvirtual or static calls, you end up having to add as much as an iota of extra code to emulate their functionality, then your resulting net overhead is bound to be not less, but more. Quite possibly, much, much, unfathomably much, more.
Well, static calls can't be overridden (so are always candidates for inlining), and don't require any nullity checks. HotSpot does a bunch of cool optimizations for instance methods which may well negate these advantages, but they're possible reasons why a static call may be faster.
However, that shouldn't affect your design - code in the most readable, natural way - and only worry about this sort of micro-optimization if you have just cause (which you almost never will).
It is compiler/VM specific.
In theory, a static call can be made
slightly more efficient because it
doesn't need to do a virtual function
lookup, and it can also avoid the
overhead of the hidden "this"
parameter.
In practice, many compilers will
optimize this out anyway.
Hence it's probably not worth bothering about unless you have identified this as a truly critical performance issue in your application. Premature optimization is the root of all evil etc...
However I have seen this optimization give a substantial performance increase in the following situation:
Method performing a very simple mathematical calculation with no memory accesses
Method being invoked millions of times per second in a tight inner loop
CPU bound application where every bit of performance mattered
If the above applies to you, it may be worth testing.
There is also one other good (and potentially even more important!) reason to use a static method - if the method actually has static semantics (i.e. logically is not connected to a given instance of the class) then it makes sense to make it static to reflect this fact. Experienced Java programmers will then notice the static modifier and immediately think "aha! this method is static so it doesn't need an instance and presumably doesn't manipulate instance specific state". So you will have communicated the static nature of the method effectively....
7 years later...
I don't have a huge degree of confidence in the results that Mike Nakis found because they don't address some common issues relating to Hotspot optimisations. I've instrumented benchmarks using JMH and found the overhead of an instance method to be about 0.75% on my machine vs a static call. Given that low overhead I think except in the most latency sensitive operations it's arguably not the biggest concern in an applications design. The summary results from my JMH benchmark are as follows;
java -jar target/benchmark.jar
# -- snip --
Benchmark Mode Cnt Score Error Units
MyBenchmark.testInstanceMethod thrpt 200 414036562.933 ± 2198178.163 ops/s
MyBenchmark.testStaticMethod thrpt 200 417194553.496 ± 1055872.594 ops/s
You can look at the code here on Github;
https://github.com/nfisher/svsi
The benchmark itself is pretty simple but aims to minimise dead code elimination and constant folding. There are possibly other optimisations that I've missed/overlooked and these results are likely to vary per JVM release and OS.
package ca.junctionbox.svsi;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.infra.Blackhole;
class InstanceSum {
public int sum(final int a, final int b) {
return a + b;
}
}
class StaticSum {
public static int sum(final int a, final int b) {
return a + b;
}
}
public class MyBenchmark {
private static final InstanceSum impl = new InstanceSum();
#State(Scope.Thread)
public static class Input {
public int a = 1;
public int b = 2;
}
#Benchmark
public void testStaticMethod(Input i, Blackhole blackhole) {
int sum = StaticSum.sum(i.a, i.b);
blackhole.consume(sum);
}
#Benchmark
public void testInstanceMethod(Input i, Blackhole blackhole) {
int sum = impl.sum(i.a, i.b);
blackhole.consume(sum);
}
}
As previous posters have said: This seems like a premature optimization.
However, there is one difference (a part from the fact that non-static invokations require an additional push of a callee-object onto the operand stack):
Since static methods can't be overridden, there will not be any virtual lookups in runtime for a static method call. This may result in an observable difference under some circumstances.
The difference on a byte-code level is that a non-static method call is done through INVOKEVIRTUAL, INVOKEINTERFACE or INVOKESPECIAL while a static method call is done through INVOKESTATIC.
It is unbelievably unlikely that any difference in the performance of static versus non-static calls is making a difference in your application. Remember that "premature optimization is the root of all evil".
For the decision if a method should be static, the performance aspect should be irrelevant. If you have a performance problem, making lots of methods static isn't going to save the day. That said, static methods are almost certainly not slower than any instance method, in most cases marginally faster:
1.) Static methods are not polymorphic, so the JVM has less decisions to make to find the actual code to execute. This is a moot point in the Age of Hotspot, since Hotspot will optimize instance method calls that have only one implementation site, so they will perform the same.
2.) Another subtle difference is that static methods obviously have no "this" reference. This results in a stack frame one slot smaller than that of an instance method with the same signature and body ("this" is put in slot 0 of the local variables on the bytecode level, whereas for static methods slot 0 is used for the first parameter of the method).
There might be a difference, and it might go either way for any particular piece of code, and it might change with even a minor release of the JVM.
This is most definitely part of the 97% of small efficiencies that you should forget about.
In theory, less expensive.
Static initialization is going to be done even if you create an instance of the object, whereas static methods will not do any initialization normally done in a constructor.
However, I haven't tested this.
As Jon notes, static methods can't be overridden, so simply invoking a static method may be -- on a sufficiently naive Java runtime -- faster than invoking an instance method.
But then, even assuming you're at the point where you care about messing up your design to save a few nanoseconds, that just brings up another question: will you need method overriding yourself? If you change your code around to make an instance method into a static method to save a nanosecond here and there, and then turn around and implement your own dispatcher on top of that, yours is almost certainly going to be less efficient than the one built into your Java runtime already.
I would like to add to the other great answers here that it also depends on your flow, for example:
Public class MyDao {
private String sql = "select * from MY_ITEM";
public List<MyItem> getAllItems() {
springJdbcTemplate.query(sql, new MyRowMapper());
};
};
Pay attention that you create a new MyRowMapper object per each call.
Instead, I suggest to use here a static field.
Public class MyDao {
private static RowMapper myRowMapper = new MyRowMapper();
private String sql = "select * from MY_ITEM";
public List<MyItem> getAllItems() {
springJdbcTemplate.query(sql, myRowMapper);
};
};

Categories