Skip to Main Content

Java Programming

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Default methods

baftosMar 27 2014 — edited Apr 9 2014

I read the Java tutorial on default methods and I think I understand how interfaces may evolve without loss of backward compatibility. My question refers rather to how should we design our interfaces from scratch. If and when should we define default methods? As an extreme example, why not design MyNewInterface with all default methods? If some operation makes sense, fine, stick the appropriate code in there, and if not, just do nothing, return null, return 0, return false. This would give the implementers of my interface quite some freedom what to care about, depending on their application needs and would make their apps less verbose (kind of like what the awt Adapter classes achieve). I don't look for an approval of this approach, but at some guidelines. Hope this makes sense.

Edit: And one more question from someone involved a lot with libraries for external clients. Does it make sense to rewrite old interfaces in a new release of the library and turn some methods into default methods containing code that makes sense? This option was not available so far and users had to write sometimes trivial implementations.

Comments

thatJeffSmith-Oracle
I understand what you want, however I don't think we have an answer that will give you what you want.

PL/SQL blocks aren't SQL - you're not going to get a resultset back like what if you had run a query in SQL*Plus or SQL Developer.

HOWEVER, if you have your program return the resultset as a REFCURSOR - SQL Developer will 'catch' that output and place it in a 'grid.'

You're other option is to output the format to file or to the output buffer however which way you want - but that's code you're going to have to write yourself.

Here's an example of what REFCURSOR output looks like in SQL Developer

http://www.thatjeffsmith.com/archive/2011/12/sql-developer-tip-viewing-refcursor-output/
unknown-7404
Welcome to the forum!

Whenever you post provide your full sql developer version.
>
But output via PL/SQL is usually done via dbms_output.
>
No - it isn't.

The DBMS_OUTPUT package should NOT be used at all in production code. You should only enable and use it very sparingly and only then for debugging purposes when developing and testing your code.

A line like this:
    dbms_output.put_line(i || ' ' || i*i);
does nothing more than put text into a buffer in Oracle and uses expensive PGA memory to store it. There is a small default limit on the size of that buffer and you run the risk of an exception if you fill it up.

The client software (sql*plus, sql developer) has to actually access that buffer to get the text or it will NEVER get displayed. And it normally only gets displayed AFTER the completion of the code, not during the execution.

If you are using DBMS_OUTPUT as a general-purpose 'display' mechanism then you are misusing it and should find another alternative.
>
How to get the resulting table not shown in the "dbms output" window, but in the "query result" window?
>
There is no 'table' and there is no 'query result'. If you want a query result put the results into a table or use a REF CURSOR to return them.
thatJeffSmith-Oracle
No - it isn't.
Good catch. Although unfortunately too many folks do rely on this. And of course it's never in production. Sigh.
1 - 3
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on May 7 2014
Added on Mar 27 2014
10 comments
4,328 views