Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Failed: InputStream in = getClass().getResourceAsStream("1.txt");

Reply
Thread Tools

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

 
 
jan V
Guest
Posts: n/a
 
      09-05-2005
> > 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.


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.


 
Reply With Quote
 
 
 
 
pkriens@gmail.com
Guest
Posts: n/a
 
      09-06-2005
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

 
Reply With Quote
 
 
 
 
Andrea Desole
Guest
Posts: n/a
 
      09-06-2005


http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> 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
 
Reply With Quote
 
jan V
Guest
Posts: n/a
 
      09-06-2005
> 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."


 
Reply With Quote
 
bokiteam@ms21.hinet.net
Guest
Posts: n/a
 
      09-06-2005
Hi Jan V,

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

Best regards,
Boki

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
confused: Socket InputStream != ServerSocker InputStream R Java 5 03-13-2005 07:26 AM
ASP.NET InputStream is not a stream Steve Drake ASP .Net 7 10-18-2004 06:57 AM
changing Request.InputStream karahan celikel ASP .Net 4 03-04-2004 05:24 PM
Email attachment from InputStream? steven shingler ASP .Net 1 01-20-2004 06:58 AM
Re: Accessing Request.InputStream / Request.BinaryRead *as the request is occuring*: How??? Brian Birtle ASP .Net 2 10-16-2003 02:11 PM



Advertisments