Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #38739 > unrolled thread

it's Closeable, but I don't want to close() it yet.

Back to article view | Back to comp.lang.java.programmer

Contents

  it's Closeable, but I don't want to close() it yet. Andreas Leitgeb <avl@logic.at> - 2019-02-27 15:51 +0000
    Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-27 08:48 -0800
      Re: it's Closeable, but I don't want to close() it yet. Andreas Leitgeb <avl@logic.at> - 2019-02-27 19:03 +0000
        Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-27 11:09 -0800
          Re: it's Closeable, but I don't want to close() it yet. Andreas Leitgeb <avl@logic.at> - 2019-02-28 12:20 +0000
            Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-28 06:19 -0800
              Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-28 06:52 -0800
                Re: it's Closeable, but I don't want to close() it yet. bursejan@gmail.com - 2019-02-28 08:24 -0800
                  Re: it's Closeable, but I don't want to close() it yet. bursejan@gmail.com - 2019-02-28 08:34 -0800
                    Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-28 09:00 -0800
                      Re: it's Closeable, but I don't want to close() it yet. bursejan@gmail.com - 2019-02-28 11:12 -0800
                        Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-28 11:26 -0800
                          Re: it's Closeable, but I don't want to close() it yet. bursejan@gmail.com - 2019-02-28 11:33 -0800
                            Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-28 11:37 -0800
                            Re: it's Closeable, but I don't want to close() it yet. bursejan@gmail.com - 2019-02-28 11:41 -0800
                              Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-28 11:48 -0800
                              Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-28 12:51 -0800
                                Re: it's Closeable, but I don't want to close() it yet. Andreas Leitgeb <avl@logic.at> - 2019-03-01 08:47 +0000
                  Re: it's Closeable, but I don't want to close() it yet. Andreas Leitgeb <avl@logic.at> - 2019-03-01 09:31 +0000
                    Re: it's Closeable, but I don't want to close() it yet. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2019-03-03 02:01 +0100
                      Re: it's Closeable, but I don't want to close() it yet. Andreas Leitgeb <avl@logic.at> - 2019-03-04 09:38 +0000
                        Re: it's Closeable, but I don't want to close() it yet. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2019-03-04 12:26 +0100
                          Re: it's Closeable, but I don't want to close() it yet. Andreas Leitgeb <avl@logic.at> - 2019-03-05 14:34 +0000
                            Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-03-05 07:34 -0800
                  Re: it's Closeable, but I don't want to close() it yet. Arne Vajhøj <arne@vajhoej.dk> - 2019-03-04 13:59 -0500
    Re: it's Closeable, but I don't want to close() it yet. Marcel Mueller <news.5.maazl@spamgourmet.org> - 2019-02-28 08:30 +0100
      Re: it's Closeable, but I don't want to close() it yet. Andreas Leitgeb <avl@logic.at> - 2019-02-28 19:10 +0000
        Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-28 11:34 -0800
        Re: it's Closeable, but I don't want to close() it yet. Marcel Mueller <news.5.maazl@spamgourmet.org> - 2019-02-28 22:24 +0100
          Re: it's Closeable, but I don't want to close() it yet. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2019-02-28 23:25 +0100
            Re: it's Closeable, but I don't want to close() it yet. Andreas Leitgeb <avl@logic.at> - 2019-03-01 09:43 +0000
    Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-28 12:11 -0800
      Re: it's Closeable, but I don't want to close() it yet. bursejan@gmail.com - 2019-02-28 13:49 -0800
        Re: it's Closeable, but I don't want to close() it yet. bursejan@gmail.com - 2019-02-28 13:52 -0800
          Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-28 13:59 -0800
            Re: it's Closeable, but I don't want to close() it yet. bursejan@gmail.com - 2019-02-28 16:17 -0800
    Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-28 12:26 -0800
    Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-02-28 13:44 -0800
    Re: it's Closeable, but I don't want to close() it yet. bursejan@gmail.com - 2019-03-01 07:40 -0800
      Re: it's Closeable, but I don't want to close() it yet. bursejan@gmail.com - 2019-03-01 08:34 -0800
    Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-03-11 06:27 -0700
      Re: it's Closeable, but I don't want to close() it yet. Eric Douglas <e.d.programmer@gmail.com> - 2019-03-11 07:24 -0700

Page 1 of 3  [1] 2 3  Next page →

#38739 — it's Closeable, but I don't want to close() it yet.

In my application there exists an entity that is Closeable.
It is kept in some class, and other parts of my application
request a ref to the entity and do actions on it, then drop
their ref, leaving the entity intact.

Everything runs fine, except eclipse warns me about spots
where the entity is requested, used, and then dropped.
Eclipse thinks it might need to be close()d.

Apart from ignoring the warning per eclipse settings or
adding @SuppressWarnings, is there maybe a way to tell
the compiler that a certain ref is not meant to be close()d?
Letting it know that - despite the entity's ultimate fate of
being eventually closed - this is not yet the time&place for it?

[toc] | [next] | [standalone]

#38740

On Wednesday, February 27, 2019 at 10:52:01 AM UTC-5, Andreas Leitgeb wrote:
> In my application there exists an entity that is Closeable.
> It is kept in some class, and other parts of my application
> request a ref to the entity and do actions on it, then drop
> their ref, leaving the entity intact.
> 
> Everything runs fine, except eclipse warns me about spots
> where the entity is requested, used, and then dropped.
> Eclipse thinks it might need to be close()d.
> 
> Apart from ignoring the warning per eclipse settings or
> adding @SuppressWarnings, is there maybe a way to tell
> the compiler that a certain ref is not meant to be close()d?
> Letting it know that - despite the entity's ultimate fate of
> being eventually closed - this is not yet the time&place for it?

You probably don't want to ignore the warning type entirely.  It sounds like if it's getting used in one method and you'll guarantee it gets closed elsewhere, you'll just want to add a SuppressWarnings to that method.

[toc] | [prev] | [next] | [standalone]

#38741

Eric Douglas <e.d.programmer@gmail.com> wrote:
> On Wednesday, February 27, 2019 at 10:52:01 AM UTC-5, Andreas Leitgeb wrote:
>> In my application there exists an entity that is Closeable.
>> It is kept in some class, and other parts of my application
>> request a ref to the entity and do actions on it, then drop
>> their ref, leaving the entity intact.
>> 
>> Everything runs fine, except eclipse warns me about spots
>> where the entity is requested, used, and then dropped.
>> Eclipse thinks it might need to be close()d.
>> 
>> Apart from ignoring the warning per eclipse settings or
>> adding @SuppressWarnings, is there maybe a way to tell
>> the compiler that a certain ref is not meant to be close()d?
>> Letting it know that - despite the entity's ultimate fate of
>> being eventually closed - this is not yet the time&place for it?
>
> You probably don't want to ignore the warning type entirely.  It sounds
> like if it's getting used in one method and you'll guarantee it gets
> closed elsewhere, you'll just want to add a SuppressWarnings to that
> method.

In the meantime, I could think of another solution:
- create an interface that only offers those methods of the entity
    that are really needed for its "use", e.g.   EntityUse
- let the entity retriever method return the entity with a
    static type EntityUse
- Then the "use"-part isn't aware of the entity's Closeability,
    and as an extra bonus, calling other methods is at least
    hidden behind the threshold of an explicit cast..

PS: I just added the @SuppressWarnings, but I feel better now
  knowing there would be also a clean "OO"-solution.

[toc] | [prev] | [next] | [standalone]

#38742

On Wednesday, February 27, 2019 at 2:03:35 PM UTC-5, Andreas Leitgeb wrote:
> In the meantime, I could think of another solution:
> - create an interface that only offers those methods of the entity
>     that are really needed for its "use", e.g.   EntityUse
> - let the entity retriever method return the entity with a
>     static type EntityUse
> - Then the "use"-part isn't aware of the entity's Closeability,
>     and as an extra bonus, calling other methods is at least
>     hidden behind the threshold of an explicit cast..
> 
> PS: I just added the @SuppressWarnings, but I feel better now
>   knowing there would be also a clean "OO"-solution.

I haven't seen that warning lately.  Does it only warn you to close it if you explicitly call an open method?  You could just use a custom method/class to open and close so it doesn't see that.

[toc] | [prev] | [next] | [standalone]

#38746

Eric Douglas <e.d.programmer@gmail.com> wrote:
> On Wednesday, February 27, 2019 at 2:03:35 PM UTC-5, Andreas Leitgeb wrote:
>> In the meantime, I could think of another solution:
>> - create an interface that only offers those methods of the entity
>>     that are really needed for its "use", e.g.   EntityUse
>> - let the entity retriever method return the entity with a
>>     static type EntityUse
>> - Then the "use"-part isn't aware of the entity's Closeability,
>>     and as an extra bonus, calling other methods is at least
>>     hidden behind the threshold of an explicit cast..
>> PS: I just added the @SuppressWarnings, but I feel better now
>>   knowing there would be also a clean "OO"-solution.
> I haven't seen that warning lately.

I only started to notice it after an upgrade from a rather old
eclipse to a more current one.  (That doesn't mean that it wasn't
there before. Maybe it wasn't, maybe I just didn't notice it.)

> Does it only warn you to close it if you explicitly call an
> open method?  You could just use a custom method/class to open
> and close so it doesn't see that.

The Closeable interface does not provide any concept of opening.
Eclipse just sees a local variable of a Closeable type that
goes out of scope without .close() being called on it.

[toc] | [prev] | [next] | [standalone]

#38747

On Thursday, February 28, 2019 at 7:20:35 AM UTC-5, Andreas Leitgeb wrote:
> The Closeable interface does not provide any concept of opening.
> Eclipse just sees a local variable of a Closeable type that
> goes out of scope without .close() being called on it.

Whether Eclipse cares depends on the scope.

I had the "Potential Resource Leak" error set to ignore because it was flagging potential leaks which should not be leaks.  For example I had 2 methods opening different kinds of InputStream, passing their streams into one common method to read them. The method reading the streams was guaranteed to close the stream for them using a try-finally block, but I didn't see a way to tell Eclipse that, so it complained about the methods which opened the streams.  The only way to avoid that warning is to put the method that opens the stream in yet another try-finally block that attempts to close it again.  I don't know if this logic makes sense, or if the method that only reads the streams should never close them, but it seems tedious.

In another class where I really didn't want to close the resource, I opened it in the constructor.  It didn't complain about that.  If you want to create one java.sql.Connection to use for multiple queries, declare it outside of your method and there's no warning.  It doesn't warn to close it if I open it in the method and it's declared outside (class level variable).

Obviously it's a big deal if you open multiple instances of java.sql.Connection without closing them.  I'm not sure the impact of the other classes.  In order to execute a query, I open the Connection, then I open a java.sql.Statement, then I open a java.sql.ResultSet.  Eclipse shows all 3 of these require their own close.  What happens if you don't close the Statement, does it eat up excess memory?  Does it keep all query results in memory indefinitely if you don't close the ResultSet?  These classes are AutoCloseable, so you can do a try with resources to close them.  Eclipse doesn't care if they're closed if you declare them as class level, and doesn't expect them to close if they're the return value, though I'm not sure about embedded values.  Can you create multiple closeable objects and pass them out in an array or map?

One way or the other, all closeable resources must get closed.  If you have another method to guarantee they get closed outside of where they're declared, the simple answer is suppress the warning.

[toc] | [prev] | [next] | [standalone]

#38748

On Thursday, February 28, 2019 at 9:19:24 AM UTC-5, Eric Douglas wrote:
> On Thursday, February 28, 2019 at 7:20:35 AM UTC-5, Andreas Leitgeb wrote:
> > The Closeable interface does not provide any concept of opening.
> > Eclipse just sees a local variable of a Closeable type that
> > goes out of scope without .close() being called on it.

Now, it is possible to confuse Eclipse.  I tried this method and got a warning.  Is there a better way to do this?

     public void testQuery(final String db_connect_string) {
          try (Connection conn = DriverManager.getConnection(db_connect_string)) {
               final String queryString = "select * from Log limit 10000 offset ?";
               try (PreparedStatement statement = conn.prepareStatement(queryString, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY)) {
                    int r = 0;
                    int r2 = -1;
                    statement.setInt(1, 0);
                    ResultSet rs = statement.executeQuery();
                    while (r != r2) {
                         r2 = r;
                         while (rs.next()) {
                              r++;
                         }
                         rs.close();
                         statement.setInt(1, r);
                         rs = statement.executeQuery();
                    }
                    rs.close();
               }
          } catch (SQLException e) {
               e.printStackTrace();
          }
     }

[toc] | [prev] | [next] | [standalone]

#38749

Actually you use try (resource), which does automatically
always a close. Its internally implemented with try finally
and does exceptiong piggy packing.

But JDBC says, if you close a statement, I guess result
sets are also closed. And if you close a connection, statements
are also closed. So what is this fuzz about?

What would be helpful, if the warning from the IDE would
be shown as well. Could the OP please give the full test case,
including its outcome?

On Thursday, February 28, 2019 at 3:52:24 PM UTC+1, Eric Douglas wrote:
> On Thursday, February 28, 2019 at 9:19:24 AM UTC-5, Eric Douglas wrote:
> > On Thursday, February 28, 2019 at 7:20:35 AM UTC-5, Andreas Leitgeb wrote:
> > > The Closeable interface does not provide any concept of opening.
> > > Eclipse just sees a local variable of a Closeable type that
> > > goes out of scope without .close() being called on it.
> 
> Now, it is possible to confuse Eclipse.  I tried this method and got a warning.  Is there a better way to do this?
> 
>      public void testQuery(final String db_connect_string) {
>           try (Connection conn = DriverManager.getConnection(db_connect_string)) {
>                final String queryString = "select * from Log limit 10000 offset ?";
>                try (PreparedStatement statement = conn.prepareStatement(queryString, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY)) {
>                     int r = 0;
>                     int r2 = -1;
>                     statement.setInt(1, 0);
>                     ResultSet rs = statement.executeQuery();
>                     while (r != r2) {
>                          r2 = r;
>                          while (rs.next()) {
>                               r++;
>                          }
>                          rs.close();
>                          statement.setInt(1, r);
>                          rs = statement.executeQuery();
>                     }
>                     rs.close();
>                }
>           } catch (SQLException e) {
>                e.printStackTrace();
>           }
>      }

[toc] | [prev] | [next] | [standalone]

#38750

See also:

Must JDBC Resultsets and Statements be closed 
separately although the Connection is closed afterwards?
https://stackoverflow.com/q/4507440/502187

The clean OO-solution, in case you dont need
the result set later, is to use  try-with-resources statement.
I dont recommend using result sets later, since

database systems usually have a dead man's handling.
There can be timeouts on all kind of layer levels.
Usually these tomeouts have a special error code,

and you should then do retry. It could be that your
connection pooling product does this already for you.
But it might not apply to result sets.

So somehow the eclipse warning makes sense.

On Thursday, February 28, 2019 at 5:24:29 PM UTC+1, burs...@gmail.com wrote:
> Actually you use try (resource), which does automatically
> always a close. Its internally implemented with try finally
> and does exceptiong piggy packing.
> 
> But JDBC says, if you close a statement, I guess result
> sets are also closed. And if you close a connection, statements
> are also closed. So what is this fuzz about?
> 
> What would be helpful, if the warning from the IDE would
> be shown as well. Could the OP please give the full test case,
> including its outcome?
> 
> On Thursday, February 28, 2019 at 3:52:24 PM UTC+1, Eric Douglas wrote:
> > On Thursday, February 28, 2019 at 9:19:24 AM UTC-5, Eric Douglas wrote:
> > > On Thursday, February 28, 2019 at 7:20:35 AM UTC-5, Andreas Leitgeb wrote:
> > > > The Closeable interface does not provide any concept of opening.
> > > > Eclipse just sees a local variable of a Closeable type that
> > > > goes out of scope without .close() being called on it.
> > 
> > Now, it is possible to confuse Eclipse.  I tried this method and got a warning.  Is there a better way to do this?
> > 
> >      public void testQuery(final String db_connect_string) {
> >           try (Connection conn = DriverManager.getConnection(db_connect_string)) {
> >                final String queryString = "select * from Log limit 10000 offset ?";
> >                try (PreparedStatement statement = conn.prepareStatement(queryString, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY)) {
> >                     int r = 0;
> >                     int r2 = -1;
> >                     statement.setInt(1, 0);
> >                     ResultSet rs = statement.executeQuery();
> >                     while (r != r2) {
> >                          r2 = r;
> >                          while (rs.next()) {
> >                               r++;
> >                          }
> >                          rs.close();
> >                          statement.setInt(1, r);
> >                          rs = statement.executeQuery();
> >                     }
> >                     rs.close();
> >                }
> >           } catch (SQLException e) {
> >                e.printStackTrace();
> >           }
> >      }

[toc] | [prev] | [next] | [standalone]

#38751

On Thursday, February 28, 2019 at 11:34:22 AM UTC-5, burs...@gmail.com wrote:
> See also:
> 
> Must JDBC Resultsets and Statements be closed 
> separately although the Connection is closed afterwards?
> https://stackoverflow.com/q/4507440/502187
> 
> The clean OO-solution, in case you dont need
> the result set later, is to use  try-with-resources statement.
> I dont recommend using result sets later, since
> 
> database systems usually have a dead man's handling.
> There can be timeouts on all kind of layer levels.
> Usually these tomeouts have a special error code,
> 
> and you should then do retry. It could be that your
> connection pooling product does this already for you.
> But it might not apply to result sets.
> 
> So somehow the eclipse warning makes sense.
> 
> On Thursday, February 28, 2019 at 5:24:29 PM UTC+1, burs...@gmail.com wrote:
> > Actually you use try (resource), which does automatically
> > always a close. Its internally implemented with try finally
> > and does exceptiong piggy packing.
> > 
> > But JDBC says, if you close a statement, I guess result
> > sets are also closed. And if you close a connection, statements
> > are also closed. So what is this fuzz about?
> > 
> > What would be helpful, if the warning from the IDE would
> > be shown as well. Could the OP please give the full test case,
> > including its outcome?
> > 
> > On Thursday, February 28, 2019 at 3:52:24 PM UTC+1, Eric Douglas wrote:
> > > On Thursday, February 28, 2019 at 9:19:24 AM UTC-5, Eric Douglas wrote:
> > > > On Thursday, February 28, 2019 at 7:20:35 AM UTC-5, Andreas Leitgeb wrote:
> > > > > The Closeable interface does not provide any concept of opening.
> > > > > Eclipse just sees a local variable of a Closeable type that
> > > > > goes out of scope without .close() being called on it.
> > > 
> > > Now, it is possible to confuse Eclipse.  I tried this method and got a warning.  Is there a better way to do this?
> > > 
> > >      public void testQuery(final String db_connect_string) {
> > >           try (Connection conn = DriverManager.getConnection(db_connect_string)) {
> > >                final String queryString = "select * from Log limit 10000 offset ?";
> > >                try (PreparedStatement statement = conn.prepareStatement(queryString, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY)) {
> > >                     int r = 0;
> > >                     int r2 = -1;
> > >                     statement.setInt(1, 0);
> > >                     ResultSet rs = statement.executeQuery();
> > >                     while (r != r2) {
> > >                          r2 = r;
> > >                          while (rs.next()) {
> > >                               r++;
> > >                          }
> > >                          rs.close();
> > >                          statement.setInt(1, r);
> > >                          rs = statement.executeQuery();
> > >                     }
> > >                     rs.close();
> > >                }
> > >           } catch (SQLException e) {
> > >                e.printStackTrace();
> > >           }
> > >      }

While my ugly loop to reuse the ResultSet variable should work properly, Eclipse didn't recognize that it closed properly.  That error message is "Potential resource leak: 'rs' may not be closed"

I'm guessing the clean way to paginate the table (my while loop uses POI to write the records to Excel, the r variable is actually the row number there) could look like this?
     
     public void testQuery(final String db_connect_string) {
          final String queryString = "select * from Log limit 10000 offset ?";
          try (Connection conn = DriverManager.getConnection(db_connect_string);PreparedStatement statement = conn.prepareStatement(queryString, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY)) {
               int r = 0;
               int r2 = -1;
               while (r != r2) {
                    r2 = r;
                    statement.setInt(1, r);
                    try (ResultSet rs = statement.executeQuery()) {
                         while (rs.next()) {
                              r++;
                         }
                    }
               }
          } catch (SQLException e) {
               e.printStackTrace();
          }
     }

[toc] | [prev] | [next] | [standalone]

#38753

Yes in the old code you had:

                         while (rs.next()) {
                              r++;
                         }
                         rs.close();

And since rs.next() can throw an exception,
it could escape a closing.

But try-resource has the ability to close
as well, when the try-resource block

has an exception.

There were nice blog entries in the past
from Oracle John Rose, but cant find any
of them anymore. The Oracle blogs currently

look like shit, what did they do?

On Thursday, February 28, 2019 at 6:01:03 PM UTC+1, Eric Douglas wrote:
> On Thursday, February 28, 2019 at 11:34:22 AM UTC-5, burs...@gmail.com wrote:
> > See also:
> > 
> > Must JDBC Resultsets and Statements be closed 
> > separately although the Connection is closed afterwards?
> > https://stackoverflow.com/q/4507440/502187
> > 
> > The clean OO-solution, in case you dont need
> > the result set later, is to use  try-with-resources statement.
> > I dont recommend using result sets later, since
> > 
> > database systems usually have a dead man's handling.
> > There can be timeouts on all kind of layer levels.
> > Usually these tomeouts have a special error code,
> > 
> > and you should then do retry. It could be that your
> > connection pooling product does this already for you.
> > But it might not apply to result sets.
> > 
> > So somehow the eclipse warning makes sense.
> > 
> > On Thursday, February 28, 2019 at 5:24:29 PM UTC+1, burs...@gmail.com wrote:
> > > Actually you use try (resource), which does automatically
> > > always a close. Its internally implemented with try finally
> > > and does exceptiong piggy packing.
> > > 
> > > But JDBC says, if you close a statement, I guess result
> > > sets are also closed. And if you close a connection, statements
> > > are also closed. So what is this fuzz about?
> > > 
> > > What would be helpful, if the warning from the IDE would
> > > be shown as well. Could the OP please give the full test case,
> > > including its outcome?
> > > 
> > > On Thursday, February 28, 2019 at 3:52:24 PM UTC+1, Eric Douglas wrote:
> > > > On Thursday, February 28, 2019 at 9:19:24 AM UTC-5, Eric Douglas wrote:
> > > > > On Thursday, February 28, 2019 at 7:20:35 AM UTC-5, Andreas Leitgeb wrote:
> > > > > > The Closeable interface does not provide any concept of opening.
> > > > > > Eclipse just sees a local variable of a Closeable type that
> > > > > > goes out of scope without .close() being called on it.
> > > > 
> > > > Now, it is possible to confuse Eclipse.  I tried this method and got a warning.  Is there a better way to do this?
> > > > 
> > > >      public void testQuery(final String db_connect_string) {
> > > >           try (Connection conn = DriverManager.getConnection(db_connect_string)) {
> > > >                final String queryString = "select * from Log limit 10000 offset ?";
> > > >                try (PreparedStatement statement = conn.prepareStatement(queryString, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY)) {
> > > >                     int r = 0;
> > > >                     int r2 = -1;
> > > >                     statement.setInt(1, 0);
> > > >                     ResultSet rs = statement.executeQuery();
> > > >                     while (r != r2) {
> > > >                          r2 = r;
> > > >                          while (rs.next()) {
> > > >                               r++;
> > > >                          }
> > > >                          rs.close();
> > > >                          statement.setInt(1, r);
> > > >                          rs = statement.executeQuery();
> > > >                     }
> > > >                     rs.close();
> > > >                }
> > > >           } catch (SQLException e) {
> > > >                e.printStackTrace();
> > > >           }
> > > >      }
> 
> While my ugly loop to reuse the ResultSet variable should work properly, Eclipse didn't recognize that it closed properly.  That error message is "Potential resource leak: 'rs' may not be closed"
> 
> I'm guessing the clean way to paginate the table (my while loop uses POI to write the records to Excel, the r variable is actually the row number there) could look like this?
>      
>      public void testQuery(final String db_connect_string) {
>           final String queryString = "select * from Log limit 10000 offset ?";
>           try (Connection conn = DriverManager.getConnection(db_connect_string);PreparedStatement statement = conn.prepareStatement(queryString, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY)) {
>                int r = 0;
>                int r2 = -1;
>                while (r != r2) {
>                     r2 = r;
>                     statement.setInt(1, r);
>                     try (ResultSet rs = statement.executeQuery()) {
>                          while (rs.next()) {
>                               r++;
>                          }
>                     }
>                }
>           } catch (SQLException e) {
>                e.printStackTrace();
>           }
>      }

[toc] | [prev] | [next] | [standalone]

#38754

On Thursday, February 28, 2019 at 2:12:55 PM UTC-5, burs...@gmail.com wrote:
> Yes in the old code you had:
> 
>                          while (rs.next()) {
>                               r++;
>                          }
>                          rs.close();
> 
> And since rs.next() can throw an exception,
> it could escape a closing.
> 
> But try-resource has the ability to close
> as well, when the try-resource block
> 
> has an exception.
> 
> There were nice blog entries in the past
> from Oracle John Rose, but cant find any
> of them anymore. The Oracle blogs currently
> 
> look like shit, what did they do?
> 

1) Is the confusion with Eclipse or Oracle?  I googled it and it went straight to Oracle (https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html) which even specifically mentioned my scenario, simply putting an executeQuery inside the try block, for which Eclipse complains not explicitly closing a ResultSet is a potential resource leak.

2) I don't see the scenario in the Oracle doc for re-using a variable.  Should I be able to close a RecordSet and call executeQuery again to that same variable in that same method?

3) How should we close a resource such as InputStream or OutputStream?  I had written the API in such a way if I'm passing them into a method to be read once, that method is closing them.  We should never close them while reading/writing them and expect them to get closed after the call by the method that opened them?

[toc] | [prev] | [next] | [standalone]

#38755

Since Eclipse says "potential", it is not sure about its
judgement. Probably it uses some heuristics to find
close leaking, and in your case,

it produces maybe a false positive. All these checks
that different IDEs offer work by inspecting a small
part of your code and work by producing

a best guess, through some hand coded heuristics,
that there could be a problem.

They are not theorem provers that 100% can tell
whether something is a problem or not.

On Thursday, February 28, 2019 at 8:26:34 PM UTC+1, Eric Douglas wrote:
> On Thursday, February 28, 2019 at 2:12:55 PM UTC-5, burs...@gmail.com wrote:
> > Yes in the old code you had:
> > 
> >                          while (rs.next()) {
> >                               r++;
> >                          }
> >                          rs.close();
> > 
> > And since rs.next() can throw an exception,
> > it could escape a closing.
> > 
> > But try-resource has the ability to close
> > as well, when the try-resource block
> > 
> > has an exception.
> > 
> > There were nice blog entries in the past
> > from Oracle John Rose, but cant find any
> > of them anymore. The Oracle blogs currently
> > 
> > look like shit, what did they do?
> > 
> 
> 1) Is the confusion with Eclipse or Oracle?  I googled it and it went straight to Oracle (https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html) which even specifically mentioned my scenario, simply putting an executeQuery inside the try block, for which Eclipse complains not explicitly closing a ResultSet is a potential resource leak.
> 
> 2) I don't see the scenario in the Oracle doc for re-using a variable.  Should I be able to close a RecordSet and call executeQuery again to that same variable in that same method?
> 
> 3) How should we close a resource such as InputStream or OutputStream?  I had written the API in such a way if I'm passing them into a method to be read once, that method is closing them.  We should never close them while reading/writing them and expect them to get closed after the call by the method that opened them?

[toc] | [prev] | [next] | [standalone]

#38757

On Thursday, February 28, 2019 at 2:33:44 PM UTC-5, burs...@gmail.com wrote:
> Since Eclipse says "potential", it is not sure about its
> judgement. Probably it uses some heuristics to find
> close leaking, and in your case,
> 
> it produces maybe a false positive. All these checks
> that different IDEs offer work by inspecting a small
> part of your code and work by producing
> 
> a best guess, through some hand coded heuristics,
> that there could be a problem.
> 
> They are not theorem provers that 100% can tell
> whether something is a problem or not.
> 
> On Thursday, February 28, 2019 at 8:26:34 PM UTC+1, Eric Douglas wrote:
> > On Thursday, February 28, 2019 at 2:12:55 PM UTC-5, burs...@gmail.com wrote:
> > > Yes in the old code you had:
> > > 
> > >                          while (rs.next()) {
> > >                               r++;
> > >                          }
> > >                          rs.close();
> > > 
> > > And since rs.next() can throw an exception,
> > > it could escape a closing.
> > > 
> > > But try-resource has the ability to close
> > > as well, when the try-resource block
> > > 
> > > has an exception.
> > > 
> > > There were nice blog entries in the past
> > > from Oracle John Rose, but cant find any
> > > of them anymore. The Oracle blogs currently
> > > 
> > > look like shit, what did they do?
> > > 
> > 
> > 1) Is the confusion with Eclipse or Oracle?  I googled it and it went straight to Oracle (https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html) which even specifically mentioned my scenario, simply putting an executeQuery inside the try block, for which Eclipse complains not explicitly closing a ResultSet is a potential resource leak.
> > 

So the ResultSet shouldn't have to be closed, and Oracle's docs being correct would mean it does automatically close when you close the Statement, and if we don't want to explicitly close it, we should need a SuppressWarnings on Eclipse which should not cause any problems in executing.

[toc] | [prev] | [next] | [standalone]

#38758

Mostlikely ResultSet is anyway auto closing in the
sense that when you have reached the last row,
it will anyway close. Not sure about that.

But it should be automatically closed when you read 
the next page via the same prepared statement, 
since the documentation says:

"A ResultSet object is automatically closed when 
the Statement object that generated it is closed, 
re-executed, or used to retrieve the next result 
from a sequence of multiple results." 
https://docs.oracle.com/javase/7/docs/api/java/sql/ResultSet.html

On Thursday, February 28, 2019 at 8:33:44 PM UTC+1, burs...@gmail.com wrote:
> Since Eclipse says "potential", it is not sure about its
> judgement. Probably it uses some heuristics to find
> close leaking, and in your case,
> 
> it produces maybe a false positive. All these checks
> that different IDEs offer work by inspecting a small
> part of your code and work by producing
> 
> a best guess, through some hand coded heuristics,
> that there could be a problem.
> 
> They are not theorem provers that 100% can tell
> whether something is a problem or not.
> 
> On Thursday, February 28, 2019 at 8:26:34 PM UTC+1, Eric Douglas wrote:
> > On Thursday, February 28, 2019 at 2:12:55 PM UTC-5, burs...@gmail.com wrote:
> > > Yes in the old code you had:
> > > 
> > >                          while (rs.next()) {
> > >                               r++;
> > >                          }
> > >                          rs.close();
> > > 
> > > And since rs.next() can throw an exception,
> > > it could escape a closing.
> > > 
> > > But try-resource has the ability to close
> > > as well, when the try-resource block
> > > 
> > > has an exception.
> > > 
> > > There were nice blog entries in the past
> > > from Oracle John Rose, but cant find any
> > > of them anymore. The Oracle blogs currently
> > > 
> > > look like shit, what did they do?
> > > 
> > 
> > 1) Is the confusion with Eclipse or Oracle?  I googled it and it went straight to Oracle (https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html) which even specifically mentioned my scenario, simply putting an executeQuery inside the try block, for which Eclipse complains not explicitly closing a ResultSet is a potential resource leak.
> > 
> > 2) I don't see the scenario in the Oracle doc for re-using a variable.  Should I be able to close a RecordSet and call executeQuery again to that same variable in that same method?
> > 
> > 3) How should we close a resource such as InputStream or OutputStream?  I had written the API in such a way if I'm passing them into a method to be read once, that method is closing them.  We should never close them while reading/writing them and expect them to get closed after the call by the method that opened them?

[toc] | [prev] | [next] | [standalone]

#38759

On Thursday, February 28, 2019 at 2:41:22 PM UTC-5, burs...@gmail.com wrote:
> Mostlikely ResultSet is anyway auto closing in the
> sense that when you have reached the last row,
> it will anyway close. Not sure about that.
> 
It may, depending on the type.

> But it should be automatically closed when you read 
> the next page via the same prepared statement, 
> since the documentation says:
> 
So yes, Oracle closes 2 objects together which must be opened separately, which buggers up Eclipse checking.

[toc] | [prev] | [next] | [standalone]

#38762

On Thursday, February 28, 2019 at 2:41:22 PM UTC-5, burs...@gmail.com wrote:
> Mostlikely ResultSet is anyway auto closing in the
> sense that when you have reached the last row,
> it will anyway close. Not sure about that.
> 
> But it should be automatically closed when you read 
> the next page via the same prepared statement, 
> since the documentation says:
> 
> "A ResultSet object is automatically closed when 
> the Statement object that generated it is closed, 
> re-executed, or used to retrieve the next result 
> from a sequence of multiple results." 
> https://docs.oracle.com/javase/7/docs/api/java/sql/ResultSet.html
> 
I see some old stackoverflow threads that say if you don't explicitly close the ResultSet and keep creating new ones it had a problem with a "too many open cursors" error.  Is that still true?

[toc] | [prev] | [next] | [standalone]

#38772

Eric Douglas <e.d.programmer@gmail.com> wrote:
> I see some old stackoverflow threads that say if you don't
> explicitly close the ResultSet and keep creating new ones
> it had a problem with a "too many open cursors" error.
> Is that still true?

I'd suspect that the respective asker misrepresented the
situation. Maybe they really created new PreparedStatements,
without close()ing, rather than new ResultSets.

[toc] | [prev] | [next] | [standalone]

#38773

bursejan@gmail.com <bursejan@gmail.com> wrote:
> Could the OP please give the full test case,
> including its outcome?

Note ahead: I don't really have a problem with the code. I just
wanted to improve my understanding of details, and I wanted to
know that for (at least almost) every warning, there is a way
to do it properly without warning. (An exception to this are
generics-warnings on dynamically "born" instances.)

The original code is "long and boring", but this "sligthly shorter
and still boring" code comes pretty close to my real situation:
(I've added a theoretical solution behind a spoiler-marker,
but in my real code I just added the @Suppress... anno)

interface Entity {
      public void a();
}
class EntityImpl implements Entity, java.io.Closeable {
      public void a() { /* ... */ }
      public void b() { /* ... */ } // semantically doesn't fit in Entity.
      public void close() { /* ... */ }
}
class Context {
   private final Entity m_ent;
   public Context(Entity ent) { m_ent = ent; }
   public Entity getEnt() { return m_ent; }
}
public class Foo {
   public static void main(String[] args) {
      EntityImpl ei = new EntityImpl();
      Context ctx = new Context( ei );
      helper1(ctx);
      helper2(ctx);
      ei.close();
   }
   private static void helper1(Context ctx) {
      ctx.getEnt().a();
   }
   private static void helper2(Context ctx) {
       Entity ent = ctx.getEnt();
       if (ent instanceof EntityImpl) {
          // the following line gets tagged by eclipse:
          //  "Resource leak: 'entImp' is never closed"
          EntityImpl entImp = (EntityImpl)ent;
          entImp.b();
       }
    }
}



The proper(tm) solution here is to define a second interface EntityB
that declares method b(). Add EntityB to EntityImpl's "implements"
list and in helper2, use EntityB instead of EntityImpl.

[toc] | [prev] | [next] | [standalone]

#38783

On 2019-03-01 10:31, Andreas Leitgeb wrote:
>    private static void helper2(Context ctx) {
>        Entity ent = ctx.getEnt();
>        if (ent instanceof EntityImpl) {
>           // the following line gets tagged by eclipse:
>           //  "Resource leak: 'entImp' is never closed"
>           EntityImpl entImp = (EntityImpl)ent;
>           entImp.b();
>        }
>     }
> }

Colour me agnostic, but that warning seems absolutely ridiculous to me.
Are you sure that's the cause of it? Could EntityImpl#b perhaps be doing
something funky?

-- 
DF.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web