Failed: InputStream in = getClass().getResourceAsStream("1.txt");

[Roedy Green]

imageName

image name will be something like "dalmatian.jpg"
It will be a resource living in the jar file under a name like:
com/mindprod/mypackage/dalmatian.jpg

It will not be called 1.txt. It is a picture, not text.

 

[Roedy Green]

imageSource = getClass().getResourceAsStream(imageName);

Let's do a simple getResource to help you understand what is
happening:

URL url = this.getClass().getResource( "blueball.gif" );

System.out.println( url );

Your first problem is to find the resource. If 1.txt truly is an
image, pleace rename it to the proper .png .jpg .gif suffix and put it
in the jar in the same package as your code.

See http://mindprod.com/jgloss/image.html
for what sort of response you should expect.

 

[Roedy Green]

Use some kind of logical sorting order for your imports, and use this order
consistently. Interleaving java.* and javax.* imports is a no-no in my book.
I also import home-grown packages first (your de.*) to highlight the fact
that the current source file relies on non-standard packages.

This is most easily fixed by an IDE such as Eclipse that will sort and
expand *s for you.

 

[Roedy Green]

Never catch everything like this, use explicit sub-exception types.

Never is perhaps too strong a word, but as generic advice, you want to
avoid being overly greedy in the exception nets you cast. Throwable
includes even extremely fatal situations you can't recover from. Best
just let them flow.

 

[Roedy Green]

Hi,
I am really no good on java....

Nobody is to start. Just keep plugging. People would not be spending
so much time on you if they did not think you had promise.

 

[Roedy Green]

Thank you very much, but no luck on me....

sigh..... just to read a file...

The funny thing is ONCE YOU GET IT GOING, you will wonder what all the
fuss was about and why you had so much trouble. It is like tripping
over a paperclip.

 

[Roedy Green]

I just change 1.txt to a.jpg ( and put a.jpg to the same folder )

and I can read it !!!!!!!

Congratulations:

To cap your success, please read http://mindprod.com/jgloss/image.html
that will explain to you WHY it worked, and other similar useful
information. Read it now while the pain is still fresh.

 

[jan V]

Use some kind of logical sorting order for your imports, and use this
order

This is most easily fixed by an IDE such as Eclipse that will sort and
expand *s for you.

Sure thing. One side-effect of such IDE support that I've noticed in
colleagues (though not in me..) is that people start not to give a f*ck
about what's in their imports anymore. The IDE deals with that to such an
extreme extent that the programmer can completely forget that part of the
language.

.... and that's the problem.

When you start ignoring your imports, you start ignoring a decent source of
dependency information. A class which needs a list of imports the size of
your Christmas shopping list is a diseased class (most likely).

Call me old-fashioned, but I like to keep an eye on my imports, even if it
means sorting and formatting them myself.

 

[jan V]

What the pig,

I just change 1.txt to a.jpg ( and put a.jpg to the same folder )

and I can read it !!!!!!!

Life's a bitch, a lot of the time. I'm happy you're a step closer to reading
that mysterious 1.txt though ;-)

 

[Patricia Shanahan]

Sure thing. One side-effect of such IDE support that I've noticed in
colleagues (though not in me..) is that people start not to give a f*ck
about what's in their imports anymore. The IDE deals with that to such an
extreme extent that the programmer can completely forget that part of the
language.

... and that's the problem.

When you start ignoring your imports, you start ignoring a decent source of
dependency information. A class which needs a list of imports the size of
your Christmas shopping list is a diseased class (most likely).

Call me old-fashioned, but I like to keep an eye on my imports, even if it
means sorting and formatting them myself.

I had the opposite experience. When I did the imports by hand, I tended
to use on-demand imports, such as "java.util.*". With Eclipse doing the
bookkeeping, I stick to single class imports. The length of the import
list is a much better indication of the number of imported classes.

Patricia

 

[jan V]

Call me old-fashioned, but I like to keep an eye on my imports, even if
it

I had the opposite experience. When I did the imports by hand, I tended
to use on-demand imports, such as "java.util.*". With Eclipse doing the
bookkeeping, I stick to single class imports. The length of the import
list is a much better indication of the number of imported classes.

I've always used on-demand imports (except when needing to disambiguate
collisions).. simply because for 95% of my Java career I've used an editor
which did not help me with the imports side of coding [Multi-Edit for
Windows, aka MEW].

Although I can see your argument, I'm not going to start changing my style.
The reason isn't ego or stubborness but as follows ;-)

When you only use single class imports, then most real-life classes will
have an import list that will easily exceed one screen full (50 lines?). I'd
like to guess that a lot of your classes may even have lists longer than two
screen fulls, and there's no way I would consider this a readable
alternative to my neat, compact lists. Here's a typical import "section" in
my code (the comments are vertically aligned on my screen):

import org.lv.lego.*; // TimeAndDateKit
import org.lv.lego.adt.*; // Pair
import org.lv.lego.debug.*; // DebugSupport, Debugable
import org.lv.lego.math.*; // MathKit
import org.lv.lego.selftest.*; // Testable, SelfTestPrintStream

import java.awt.*; // Canvas, Graphics2D
import java.awt.event.*; // MouseMotionListener, KeyListener
import java.awt.geom.*; // GeneralPath
import java.beans.*; // PropertyChangeSupport

// avoid collision with AWT
import java.util.List;


... as you can see, I like to add notes of which *key* classes I import via
the on-demand style. I don't know any IDE which does that kind of thing, so
I'm stuck doing it manually. The net result is a compact, informative
listing which can be read very quickly to get the essential info without
having to scroll down a huge list.

Your fully explicit style contains a lot of "information noise".. for
example when doing AWT or Swing work, you'll almost invariably be using
Colour... but I really don't want to have to read this in my imports list,
because that's a trivial dependency. The same applies to many other types
(like IOException, InputStream, etc..). I want my imports to be compact and
show me the essence of what I need to know to get a picture of what kind of
other things the current class is relying on.

 

[pkriens]

Wow, that is a pedantic reply ... Though I understand most of your
underlying reasoning, it is still very much a trade off in most cases
that is not black and white.

imports, agree could be better because many are not necessary and
redundancy is causing problems and makes it harder to understand.

Private fields. Never understood why. Package private is the default
for a reason. Encapsulation is good because it keeps you in control for
a next version. Package private gives you this just as much as private
with less clutter and it makes testing code easier because it can have
access to variables.

Setting a field to null. Though unnecessary, it can provide some
documentation that you really assume null in your code.

Constant for 1024? Why? A constant is overhead and clutter that is only
balanced when you need the same value in multiple places. This 1024 is
just a random number that is a decent buffer size. I'd rather see the
1024 here then BUFFER_SIZE_CONSTANT and then figuring out where it is
defined. (Though Eclipse does a good job at that nowadays).

Catching Throwable. Why do you want to clutter your code with sub
catches?? He is only interested in failure, not really why it failed?
In this case, he would have to repeat the print stack trace in every
clause, which is redundant and clutters his intentions.

Again, I am not saying that you are completely wrong, but stating that
this is the only way is not very helpful when in the end it is a trade
off between evils. I wish it was as easy as just following a number of
hard rules that work in all cases.

Kind regards,

Peter Kriens

 

[Andrea Desole]

Private fields. Never understood why. Package private is the default
for a reason. Encapsulation is good because it keeps you in control for
a next version. Package private gives you this just as much as private
with less clutter and it makes testing code easier because it can have
access to variables.

the problem here is more information hiding than encapsulation. If you
give a field package visibility you still have the same problems you
have with public visibility (that is, you are exposing more
implementation details than necessary). You reduce them because you
reduce the visibility, but they are still there

 

[jan V]

Private fields. Never understood why. Package private is the default

for a reason.

Too true: Gosling & Co. goofed on that one. There should not have been a
default scope whatsoever.

Again, I am not saying that you are completely wrong, but stating that
this is the only way is not very helpful when in the end it is a trade
off between evils. I wish it was as easy as just following a number of
hard rules that work in all cases.

Peter, I think you *may* want to be aware that your opinions on the
"unnecessariness" of my suggestions almost consistently go against advice by
top authorities like Steve McConnell (of "Code Complete" fame).

Of course, I don;t mind you having different opinions, it's a free(ish)
world after all.

Last but not least, I'll leave you with a famous quote from Ralph Nader: "If
you choose between the lesser of two evils, at the end of the day, you still
have evil."

 

[bokiteam]

Hi Jan V,

I can only say "Thank you very much, and I will follow all the
suggestions!"

Best regards,
Boki