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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#38784

Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> wrote:
> 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?

I did provide the implementation of b() in my posting. It was an SSCCE.
(Reminder: It was empty, except for a /* ... */ comment.)

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

#38785

On 2019-03-04 10:38, Andreas Leitgeb wrote:
> Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> wrote:
>> 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?
> 
> I did provide the implementation of b() in my posting. It was an SSCCE.
> (Reminder: It was empty, except for a /* ... */ comment.)

Hmmm.

For the record, IntelliJ fires off no such warning (then again, its
inspection profiles are configurable).

Do you also get the warning if you used a try-with-resources in the main
of your SSCCE?

-- 
DF.

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

#38792

Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> wrote:
> On 2019-03-04 10:38, Andreas Leitgeb wrote:
>> Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> wrote:
>>> 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?
>> I did provide the implementation of b() in my posting. It was an SSCCE.
>> (Reminder: It was empty, except for a /* ... */ comment.)
> Hmmm.
> For the record, IntelliJ fires off no such warning (then again, its
> inspection profiles are configurable).
> Do you also get the warning if you used a try-with-resources in the main
> of your SSCCE?

Yes. I tried it. The warning is only relevant to helper2, and it
doesn't matter what main(String[] args) looks like.

In case you want to see what it looks like in eclipse:
  https://pasteboard.co/I41cNSn.png   (*)


For what it's worth:

I added a third helper (starting as a copy of helper2) which receives
an Entity-typed parameter instead of the Context, and its first line
changed to Entity ent = e;  then I still get the warning, but if the
initialization of entImpl is also changed to init from "e" rather than
from "ent", then the warning disappears.

 private static void helper3(Entity e) {
    Entity ent = e;
    if (ent instanceof EntityImpl) {
       // the following line gets tagged by eclipse:
       //   "Resource leak: 'entImp' is never closed"
       EntityImpl entImp = (EntityImpl)ent;

       // replacing above line to this lets warning disappear
       //EntityImpl entImp = (EntityImpl)e;

       entImp.b();
    }
 }

Apparently, eclipse's heuristic does take the immediate initialisation
source of the Closeable ref into account.

(*): got this site from google. Reviewing the link didn't work for me,
    but maybe does for others. if it doesn't work, and you're curious,
    feel free to suggest an alternative image upload site.
    

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

#38797

On Tuesday, March 5, 2019 at 9:34:40 AM UTC-5, Andreas Leitgeb wrote:
> I added a third helper (starting as a copy of helper2) which receives
> an Entity-typed parameter instead of the Context, and its first line
> changed to Entity ent = e;  then I still get the warning, but if the
> initialization of entImpl is also changed to init from "e" rather than
> from "ent", then the warning disappears.

That is curious.  Eclipse complains about Closeable variables not getting closed if they're declared locally, not if they're declared in method parameters since it expects the caller to close them...and you can cast a method parameter that is not Closeable into a new variable that is, but if you assign that to another local variable first it complains, even though both local declarations are just pointers to the method parameter...

Short answer was don't let your class implement Closeable unless it's supposed to be closed every time it's accessed.  If it's supposed to stay open to be closed by one cleanup process which casts it to a Closeable subclass that subclass should only be used by the cleanup.

It would be safer to use AutoCloseable so it's guaranteed to be closed, by the process that opened it.  Then have all new instances created by and shared out of a factory class?

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

#38786

On 2/28/2019 11:24 AM, bursejan@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?

The JDBC standard defines that Connection close should call
Statement close and that Statement close should call
ResultSet close.

I believe the normal practice in Java is to close ResultSet
and Statement explicit (including try with resource).

Two possible explanations:
* not everyone reads the JDBC spec so closing explicit
   is nice to readers
* a given driver implementation may have forgotten that part

Arne

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

#38745

Am 27.02.19 um 16:51 schrieb Andreas Leitgeb:
> 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.

It is best practice for connection pooling or other object sharing to 
implement close() in a way that the object is put back for further use. 
A corresponding factory returns this instance on later invocations 
again. You will need however some point where the underlying object is 
actually closed. This could be the end of a web request or even just a 
timeout.

Separating the resource management from the application layer is often a 
good advise. But it is essential that the interface given to the 
application layer still implements Closable because the application need 
to tell the resource management layer when it no longer needs the object.


Marcel

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

#38752

Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
> Am 27.02.19 um 16:51 schrieb Andreas Leitgeb:
>> 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.
>
> It is best practice for connection pooling or other object sharing to 
> implement close() in a way that the object is put back for further use. 
> A corresponding factory returns this instance on later invocations 
> again. You will need however some point where the underlying object is 
> actually closed. This could be the end of a web request or even just a 
> timeout.

I totally agree for a typical "Pool" scenario.

My case can be better characterized in that the Closeable entity is
an attribute of a Context class, and a getter is called by "users" for
the ref of the entity.   Lifetime management of the entity is handled
by the Context.   "Users" (specific methods doing their parts of
the Context's whole task) really shouldn't close() it or they would
spoil it for later users.

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

#38756

On Thursday, February 28, 2019 at 2:10:32 PM UTC-5, Andreas Leitgeb wrote:
> I totally agree for a typical "Pool" scenario.
> 
> My case can be better characterized in that the Closeable entity is
> an attribute of a Context class, and a getter is called by "users" for
> the ref of the entity.   Lifetime management of the entity is handled
> by the Context.   "Users" (specific methods doing their parts of
> the Context's whole task) really shouldn't close() it or they would
> spoil it for later users.

I did mention if you're pooling it, don't open it.  If you declare a Closeable as a class level variable you can open it once then use it many times with that instance.  I have a class level java.sql.Connection which I may open in the constructor, but if I put the open call inside a method Eclipse still doesn't complain if it doesn't get closed.  If you only want to open it when the method gets called, initialize it to null.  Then the method can say if (conn==null){conn=DriverManager.getConnection(connectstring)}.  Remember to synchronize it if the method may be used by multiple threads simultaneously.

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

#38763

Am 28.02.19 um 20:10 schrieb Andreas Leitgeb:
> My case can be better characterized in that the Closeable entity is
> an attribute of a Context class, and a getter is called by "users" for
> the ref of the entity.   Lifetime management of the entity is handled
> by the Context.   "Users" (specific methods doing their parts of
> the Context's whole task) really shouldn't close() it or they would
> spoil it for later users.

In this case do not expose close(). Expose an interface that only 
provides the methods relevant for the users.


Marcel

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

#38769

On 2019-02-28 22:24, Marcel Mueller wrote:
> Am 28.02.19 um 20:10 schrieb Andreas Leitgeb:
>> My case can be better characterized in that the Closeable entity is
>> an attribute of a Context class, and a getter is called by "users" for
>> the ref of the entity.   Lifetime management of the entity is handled
>> by the Context.   "Users" (specific methods doing their parts of
>> the Context's whole task) really shouldn't close() it or they would
>> spoil it for later users.
> 
> In this case do not expose close(). Expose an interface that only
> provides the methods relevant for the users.

Or don't implement Closeable in the first place.

Or just ignore the bloody warning and don't let your tools get in your way.

-- 
DF.

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

#38774

Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> wrote:
> On 2019-02-28 22:24, Marcel Mueller wrote:
>> Am 28.02.19 um 20:10 schrieb Andreas Leitgeb:
>>> My case can be better characterized in that the Closeable entity is
>>> an attribute of a Context class, and a getter is called by "users" for
>>> the ref of the entity.   Lifetime management of the entity is handled
>>> by the Context.   "Users" (specific methods doing their parts of
>>> the Context's whole task) really shouldn't close() it or they would
>>> spoil it for later users.
>> In this case do not expose close(). Expose an interface that only
>> provides the methods relevant for the users.

Indeed, that's what I thought of - only after posting ;-)

> Or don't implement Closeable in the first place.

Well, if that were an option, it would be pretty obvious :)
(The real Entity implementation extends a given Closeable-
implementing class)

> Or just ignore the bloody warning and don't let your tools get in your way.

That's an option I already mentioned in first post of thread.

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

#38760

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?

Here's where it gets ugly.  I've had the "Potential resource leak" error just turned off, now I'm trying to turn it on and change code to make it go away.  I have a class with class level final public static ImageIcon variables.  I initialize each ImageIcon in a static block which calls MyClass.class.getResourceAsStream() to open an InputStream to an image file which is packaged into the jar (so if this ever gets an error you've got serious problems).  I then pass that InputStream into another method in a utility class which uses ImageIO to generate the ImageIcon.  That method closes the stream.  Eclipse complains the stream may be leaked in this class.  I take the close out of that class and try to change this to use the try-with-resources.  I previously needed no try statement in this static block.  When I wrote a try-with-resources for a SQL Statement it didn't ask for any exception clause, but here it's telling me I need to catch IOException.  Now of course my assignment of the ImageIcon must be inside this try block, and if I add a catch clause it's complaining it may not be initialized, so I have to initialize it to null in the constructor and remove the final.

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

#38765

Hint: Don't use MyClass.class.getResourceAsStream.
Use getResource which gives you an URL, and provide
this to ImageIcon.

Swing will create a background worker, and load the
ImageIcon for you. getResource doesn't throw
any error, but it might return null:

   URL url = clazz.getResource("relative path to icon");
   if (url!=null) {
      ImageIcon icon=new ImageIcon(url);
      /* do something with the icon,
         it should already be loaded */
   } else {
      /* your setup is wrong or programming error
         wrong class or wrong relative path */
   }

On Thursday, February 28, 2019 at 9:11:41 PM UTC+1, Eric Douglas 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?
> 
> Here's where it gets ugly.  I've had the "Potential resource leak" error just turned off, now I'm trying to turn it on and change code to make it go away.  I have a class with class level final public static ImageIcon variables.  I initialize each ImageIcon in a static block which calls MyClass.class.getResourceAsStream() to open an InputStream to an image file which is packaged into the jar (so if this ever gets an error you've got serious problems).  I then pass that InputStream into another method in a utility class which uses ImageIO to generate the ImageIcon.  That method closes the stream.  Eclipse complains the stream may be leaked in this class.  I take the close out of that class and try to change this to use the try-with-resources.  I previously needed no try statement in this static block.  When I wrote a try-with-resources for a SQL Statement it didn't ask for any exception clause, but here it's telling me I need to catch IOException.  Now of course my assignment of the ImageIcon must be inside this try block, and if I add a catch clause it's complaining it may not be initialized, so I have to initialize it to null in the constructor and remove the final.

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

#38766

If you need caching, you can cache on icon level.
The same ImageIcon instance can be used in multiple 
places, right?

On Thursday, February 28, 2019 at 10:49:43 PM UTC+1, burs...@gmail.com wrote:
> Hint: Don't use MyClass.class.getResourceAsStream.
> Use getResource which gives you an URL, and provide
> this to ImageIcon.
> 
> Swing will create a background worker, and load the
> ImageIcon for you. getResource doesn't throw
> any error, but it might return null:
> 
>    URL url = clazz.getResource("relative path to icon");
>    if (url!=null) {
>       ImageIcon icon=new ImageIcon(url);
>       /* do something with the icon,
>          it should already be loaded */
>    } else {
>       /* your setup is wrong or programming error
>          wrong class or wrong relative path */
>    }
> 
> On Thursday, February 28, 2019 at 9:11:41 PM UTC+1, Eric Douglas 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?
> > 
> > Here's where it gets ugly.  I've had the "Potential resource leak" error just turned off, now I'm trying to turn it on and change code to make it go away.  I have a class with class level final public static ImageIcon variables.  I initialize each ImageIcon in a static block which calls MyClass.class.getResourceAsStream() to open an InputStream to an image file which is packaged into the jar (so if this ever gets an error you've got serious problems).  I then pass that InputStream into another method in a utility class which uses ImageIO to generate the ImageIcon.  That method closes the stream.  Eclipse complains the stream may be leaked in this class.  I take the close out of that class and try to change this to use the try-with-resources.  I previously needed no try statement in this static block.  When I wrote a try-with-resources for a SQL Statement it didn't ask for any exception clause, but here it's telling me I need to catch IOException.  Now of course my assignment of the ImageIcon must be inside this try block, and if I add a catch clause it's complaining it may not be initialized, so I have to initialize it to null in the constructor and remove the final.

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

#38767

On Thursday, February 28, 2019 at 4:52:14 PM UTC-5, burs...@gmail.com wrote:
> If you need caching, you can cache on icon level.
> The same ImageIcon instance can be used in multiple 
> places, right?
> 
The ImageIcon is a single instance.  I did mention it's creating a public final static variable in a static block.
You're saying I shouldn't want to use javax.imageio.stream.MemoryCacheImageInputStream here?  Perhaps I'm not understanding it's purpose.

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

#38771

Nobody uses MemoryCacheImageInputStream. The idiom
is as I write with url = clazz.getResource. You find
the idiom also here (a slight variation of what

I already posted):

protected ImageIcon createImageIcon(String path,
                                           String description) {
    java.net.URL imgURL = getClass().getResource(path);
    if (imgURL != null) {
        return new ImageIcon(imgURL, description);
    } else {
        System.err.println("Couldn't find file: " + path);
        return null;
    }
}

https://docs.oracle.com/javase/tutorial/uiswing/components/icon.html

On Thursday, February 28, 2019 at 10:59:15 PM UTC+1, Eric Douglas wrote:
> On Thursday, February 28, 2019 at 4:52:14 PM UTC-5, burs...@gmail.com wrote:
> > If you need caching, you can cache on icon level.
> > The same ImageIcon instance can be used in multiple 
> > places, right?
> > 
> The ImageIcon is a single instance.  I did mention it's creating a public final static variable in a static block.
> You're saying I shouldn't want to use javax.imageio.stream.MemoryCacheImageInputStream here?  Perhaps I'm not understanding it's purpose.

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

#38761

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?

One more squirrelly thing in Eclipse and I think we see why I turned off this warning, InputStream.close() throws an IOException.
So I tried writing a method like this and Eclipse warns on the last 3 return statements the stream may not be closed:

// open stream is
if (is == null) {
 return false;
} else {
 // read mybytes from stream
 try {
  is.close();
 } catch (IOException e) {
  return false;
 }
}
if (mybytes == null) {
 return false;
}
return true;

I tried moving the open stream into a try-with-resources but that didn't like it's variable being re-assigned.  I call one method which may open it, then I check if it's null and try a different method to open it.

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

#38764

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?

One last fun scenario.  ImageIO.read actually reads an InputStream and closes it.  So I do this and it works fine, but Eclipse throws a potential resource leak warning on mciis:

try {
 final MemoryCacheImageInputStream mciis = new MemoryCacheImageInputStream(is);
 myBufferedImage = ImageIO.read(mciis);
} catch (final IOException e) {
 return null;
}

Passing in ByteArrayInputStream is containing the bytes of a proper image file, the above code does not hit the exception, and works fine despite the warning.  Now if you attempt to close it to avoid that warning:

try (final MemoryCacheImageInputStream mciis = new MemoryCacheImageInputStream(is)) {
 myBufferedImage = ImageIO.read(mciis);
} catch (final IOException e) {
 return null;
}

This does hit the exception.

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

#38778

close() seems to be anyway a can of worms.

"The current issue is: even with programmers do call 
close() after using FileInputStream, its finalize() 
method will still be called. In other words, still 
get the side effect of the FinalReference being 
registered at FileInputStream allocation time, 
and also reference processing to reclaim the 
FinalReference during GC (any GC solution has 
to deal with this)."
https://issues.apache.org/jira/browse/HDFS-8562

You find finalizer based design in the JRE
at many places. Also JarFile and JarEntry use
it. I wonder how this all is handled in the
future, since finalizer() is deprecated in

JDK 9, and some alternatives are suggested.
Quite confusing, difficult to say whether 
these are first sings of a general bit rot 
of Java, or whether something viable results.

Ha Ha

On Wednesday, February 27, 2019 at 4:52:01 PM UTC+1, 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?

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

#38779

Ok, I see, more control over what is put on
cleaner threads seems to be useful. The finalize()
mark interface, is called even when not needed,

even when the user did call close(). Ok, I agree
a different design, where close() would dequeue
the finalizer from cleaner thread is indeed better...

Oki Doki

So when you call close(), in future releases of
the JDK. You will help the runtime, in that you
keep finalizer queues small, and distribute work

over time, without resulting in some bulk load,
when large finalizer queues are emptied. So I
guess one more close() doesn't hurt!

On Friday, March 1, 2019 at 4:40:30 PM UTC+1, burs...@gmail.com wrote:
> close() seems to be anyway a can of worms.
> 
> "The current issue is: even with programmers do call 
> close() after using FileInputStream, its finalize() 
> method will still be called. In other words, still 
> get the side effect of the FinalReference being 
> registered at FileInputStream allocation time, 
> and also reference processing to reclaim the 
> FinalReference during GC (any GC solution has 
> to deal with this)."
> https://issues.apache.org/jira/browse/HDFS-8562
> 
> You find finalizer based design in the JRE
> at many places. Also JarFile and JarEntry use
> it. I wonder how this all is handled in the
> future, since finalizer() is deprecated in
> 
> JDK 9, and some alternatives are suggested.
> Quite confusing, difficult to say whether 
> these are first sings of a general bit rot 
> of Java, or whether something viable results.
> 
> Ha Ha
> 
> On Wednesday, February 27, 2019 at 4:52:01 PM UTC+1, 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?

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web