Java consultant: Are we being conned? Please help!

[Larry Barowski]

6. Stated that you should only ever use GUI builder tools and that hand

I've tried a few IDEs. They slow development down for me.
I do the main part of my source editing in vi.
I still use Eclipse from time to time.

But then again I'm not developing Java GUI stuff.

In my experience, the more GUI-intensive the project,
the more harmful a GUI builder is.

 

[Dale King]

Thanks for the reply. I agree, I think that he was a little too
enclosed inside a box for a consultant.

However, Java is not technically pass by reference, it is pass by
value. For most of the Java code you will ever write, it appears to be
and works just like pass by reference, however, when you pass a
reference to a method, you are passing a copy of the reference, not the
reference itself. So, inside the receiving method, you can modify what
the reference points at, but not the original reference itself.

I think it is best to explain it by pointing out that the entire
question about whether Java passes objects by value or by reference is
bogus question. Java cannot pass objects at all. Understanding why that
is will help you understand the semantics of Java.

 

[iamfractal]

Our organisation recently recieved a two day Java training course from
an external consultancy. Myself aside, most of the attendees were
unfamiliar with Java and OO. ortable
moments. In the interest of fairness I won't mention any names and I
hope I have represented the training course accurately.

Why not point him to this thread in this newsgroup and let's see what
he has to say? He may learn something.

So might we.

..ed

www.EdmundKirwan.com - Home of The Fractal Class Composition.

 

[John C. Bollinger]

Hi and thanks for your reply. I agree almost entirely with you. I
disagree on one thing though:




"Never" is too strong.

In fact, I'd be tempted to say ALWAYS extend the base Swing components,
even if you have no obvious apparent need to. Doing so allows you to
plug in extra functionality in the future i.e. make all of your labels
multilingual, or add word processor style functionality to all text
panes via a popup menu.

I agree with Tor that "never" is too strong a word, but I definitely
disagree with your position. My rule would be more like "avoid
subclassing Swing components where possible." I certainly would not
advocate ever creating trivial subclasses as *placeholders* for future
functionality. There is quite a lot you can do with the standard Swing
components, and when you want to add a new, general-purpose feature
across all components of one kind, it is fairly easy to search and
replace all the instantiations of any particular class.

I especially dislike the practice of extending Swing subclasses for the
purpose of creating a specific GUI element. For instance, a JDialog
subclass distinguished mainly by the fact that it initializes itself
with the particular content and subcomponents that I want for a
particular function.

 

[Tor Iver Wilhelmsen]

This is true (assuming he meant awt and swing layout managers only).
Distributing "extra space" in specified proportions would be one example.

With slightly more labor you can get that with Box or Spring layouts
as well I think.

 

[Eric Sosman]

Our organisation recently recieved a two day Java training course from
an external consultancy. Myself aside, most of the attendees were
unfamiliar with Java and OO. I have been away from Java for 2 years or
so, and am a little rusty. However, I felt disturbed by many of the
things that he repeatedly asserted as fact, despite my attempts to pose
alternative views. Which of us is lacking?
[... claptrap and balderdash ...]
I do not expect a consultant to get everything right all of the time.
However, when paying several thousands of pounds ( more in US dollars )
for a consultant with 10 years Java experience, [...]

Grant him this much credit: He knew enough not
to claim twenty years of Java experience ;-)

 

[.]

Our organisation recently recieved a two day Java training course from
an external consultancy. Myself aside, most of the attendees were
unfamiliar with Java and OO. I have been away from Java for 2 years or
so, and am a little rusty. However, I felt disturbed by many of the
things that he repeatedly asserted as fact, despite my attempts to pose
alternative views. Which of us is lacking?

I find it difficult to believe that anyone is going to learn Java
programming in 2 days. Even books claim 'learn Java in 21 days' and that
tends to be a bit of an exaggeration.

1. Java is pass by reference.

Yes and no. If I pass an object to a method then it is pass by reference.
If I pass a builtin data type, e.g. int, long, double, then it is pass by
value.

2. String s1 = "Fred" is always the same as String s1 = new
String("Fred")

From a high level point of view, sure. It would be safer to say that the
first format is 'syntactic sugar' for the second format.

3. Never heard of SpringLayout

Who? You or your instructor? The SpringLayout was added on v1.4. If your
instructor had never heard of it then they are not keeping current.
There are a lot of people out there still using v1.3.1 and maybe your
instructor is one of them.

4. Never heard of the EventHandler utility class and couldn't see why
it would be useful when explained to him. He also asserted that you
should only ever use inner classes as event handlers and saw no reason
for using Swing Actions.

Another v1.4 addition. I also learned Java originally on 1.0.2 through
1.1. I dropped out of the Java scene for a while and came back in 1.4.2. I
used to teach Java 1.1 so when I brushed up on 1.4.2 the sight of inner
classes seemed odd to me. After a bit of real life use I saw how nicely
they could be used and got used to the idea. Sounds to me like your
instructor is old school and not open to change.

5. His presentation slides stated that you should never modify/extend
any of the base Swing components.

Hmmm, this just sounds wrong. Mind you, I read a few books on 1.4.2 and
most did not cover this. This strikes me as something not to be covered in
a 2 day course. I can see him not covering it but it is wrong to say it
should never happen.

6. Stated that you should only ever use GUI builder tools and that hand
coding was a no-no.

This is a matter of opinion. I know that there is a lot to remember and I
appreciate the fact that a GUI builder tool helps with a lot of tedious
details but I'm a strong believer in doing it old school and then having a
tool do it for you. If you depend on the tool you are limited to what the
tool will let you do.

7. Never heard of JDBC RowSet or any of its subinterfaces.

If you are doing a 2 day course on J2SE then JDBC might not be something
that gets covered. It is sounding more and more like the person teaching
the course knows just enough (or maybe a little less) to teach a 2 day
course on J2SE and not much else.

I've seen this a lot. I've received training at work and often the
instructor is just smart enough to teach the material in the course
outline. If you ask them questions outside the course material they have
no idea and suggest you attend some more advanced course (taught by
someone else).

8. Stated that if you do not use GridbagLayout your GUI will look
appaling and developing it will be unmanageable.

Is he assuming you are programming a particular application? If he is
stating that generally you should use GridBagLayout then he is an idiot.
Why would they have other layouts if no one is supposed to use them?

9. Stated that GridBagLayout could do things that other layout managers
couldn't do ( even in combination )

Doubtful. See second sentence in response to point 8.

10. Though currently writing a book on Java 1.5, he didn't know the
syntax for a simple generics example e.g List<String> myString etc. I
had to help him out.

What was this guys name? I'd really like to know what book to never
recommend to someone. If you tell me it is Herbert Schildt I'll hurt
myself laughing.

11. Stated that you can not develop Swing applications using a GUI
builder plug-in with Eclipse.

Therefore, based on point 6, you should never use Eclipse.

12. Though using Eclipse as his training IDE, he was unaware whether or
not any version of Eclipse was up-to-speed with generics.

Wait a second. He uses Eclipse for training, tells you to always use the
GUI build tools but that Eclipse cannot develop Swing applications. See
response to point 9.

13. Stated that the class Class was the base class for all classes ( as
opposed to Object being the base class for all objects )

Maybe you misunderstood him. Or more likely, maybe he is a little
confused.

14. Repeatedly described static initialisers as static constructors.

Obviously not detail oriented?

15. Asserted that any Java 2 applets deployed in internet explorer must
be launched via an ActiveX control.

Don't know anything about Java 2 applets but this sounds wrong to me...
even without all the other garbage I've read so far.

I do not expect a consultant to get everything right all of the time.
However, when paying several thousands of pounds ( more in US dollars )
for a consultant with 10 years Java experience, and currently
co-writing a book on Java 1.5 with a well-known, established author, a
better quality of service should have been delivered. Please help as
I'm beginning to question my own judgements! In fairness, he did
partially back-track on some of his assertions after some uncomfortable
moments. In the interest of fairness I won't mention any names and I
hope I have represented the training course accurately.

Ask for a refund. Seriously. Additionally, make sure your management knows
what a waste of time this training was.

 

[Tor Iver Wilhelmsen]

Yes and no. If I pass an object to a method then it is pass by reference.
If I pass a builtin data type, e.g. int, long, double, then it is pass by
value.

No, everything is by value, you never pass objects around. Primitives
and pointers, that is all - not anything "by reference" as the term is
understood in other languages.

From a high level point of view, sure. It would be safer to say that the
first format is 'syntactic sugar' for the second format.

It's not since the constructor String(String) creates a new object.
The assignment to a String literal on the other hand will point to the
interned String pool object.

 

[Larry Barowski]

example.

With slightly more labor you can get that with Box or Spring layouts
as well I think.

You could do this with SpringLayout if you change the maximum
width of the components to some fractions of a large int. I suppose the
easiest way would be to create a Spring subclass similar to that returned by
Spring.width(Component), that returns a specified fraction of
Integer.MAX_VALUE instead of the component's maximum width for
getMaximumValue(). But that goes a bit beyond just using SpringLayout.

 

[Chris Smith]

Yes and no. If I pass an object to a method then it is pass by reference.
If I pass a builtin data type, e.g. int, long, double, then it is pass by
value.

Okay, for the record, here's the situation again.

The definition of "pass by reference" is well known and well accepted
across programming languages. It is this: the lvalue of the formal
parameter is the same as the lvalue of the actual parameter. The term
"lvalue" denotes, roughly speaking, the meaning of using an expression
on the left-hand side of the assignment operator. In Java, this is NOT
true. For example:

public void someMethod(String param)
{
param = "some test";
}

That method uses the formal parameter (param) on the left-hand side of
an assignment operator, and yet its result is NOT the same as using the
actual parameter on the left-hand side of the assignment operator. In
other words, ' s = "some test"; ' does something different than the
method call ' someMethod(s); '.

This mistake is often made, because the parameter passing scheme does
involve a reference (that's what is passed), so the individual words in
the phrase "pass by reference" all fit. In a similar way, it's almost
certain that Richard Erlenmeyer used all sorts of flasks, but only one
of them is properly called an "Erlenmeyer flask".

Regardless of how many ill-informed CS professors and book authors have
said otherwise, Java NEVER implements pass by reference. Saying that it
does is simply a redefinition of language, and serves to confuse rather
than clarify.

(As I said in an earlier post, this is not a particularly hideous
mistake, but it is one worth correcting.)

And on a side note...

I used to teach Java 1.1 so when I brushed up on 1.4.2 the sight of inner
classes seemed odd to me.

Incidentally, inner classes were widely used in Java 1.1. I don't know
why you didn't see them before Java 1.4.2.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation