My database does not know of iterators

Question

I am creating a java class in my database, and I am trying to retrieve multiple rows from a table. In the documentation I find that
#sql public iterator IteratorName(String name)
creates an iterator with which I can iterate over multiple names from the table.
the iterator is supposed to be filled with this code:
IteratorName it = null;
#sql it = {SELECT NAME FROM FILES};
for some reason when I try to compile this, I get an error saying that the compiler does not know what an iterator is.
Did I forget an import and if so, which one?

Answer 1

Hello,
I too have had this problem. As far as I can tell, the issue is not with import's as much as it is with getting Oracle to recognize sqlj-styled java source code directly, I think.
I worked around this by taking my source file and compiling it "outside of Oracle" using the sqlj preprocessor.
I took my Java class file (the one that contained the #-prefixed sqlj commands) and saved it with an extension of "sqlj". Then I ran the sqlj preprocessor on it. The sqlj preprocessor generated a .java file, and in that .java file, the iterator class was declared and defined. (You can pass sqlj a "-compile=false" command-line option to prevent it from also invoking the Java compiler to generate .class files. Otherwise, you will also get at least two .class files: one for the class you wrote, and another for the iterator class that sqlj generates.)
I took the generated .java file, and used it to build a "create or replace and compile java source named ..." statement that I could paste directly into a SQL*Plus buffer, and that compiled just fine.
I am still trying to determine whether or not I need to do something else to set java compilation options inside of Oracle, via the dbms_java package, in order to get Oracle to directly compile my "create or replace and compile java source named ..." statement without my having to use sqlj to generate a "plain java" source file from a "sqlj" source file.
I know that your question is several months old... have you worked out a solution in the meantime that is simpler than what I described above?
Regards,
Rich Stewart