Java consultant: Are we being conned? Please help!

[JavaEnquirer]

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?

1. Java is pass by reference.

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

3. Never heard of SpringLayout

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.

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

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

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

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

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

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.

11. Stated that you can not develop Swing applications using a GUI
builder plug-in with 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.

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

14. Repeatedly described static initialisers as static constructors.

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

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.

 

[Thomas Schodt]

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

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.

 

[Robert]

Java is definitely pass by reference. We use the newest eclipse here
at my work and it's 1.5 compatible. We use milestone builds though.
Your company could have definitely done better. This guy may just be a
gui guy and that's that. I know a gui developer like that who doesn't
think outside the box or stay on the cutting edge. Too bad.

 

[Chris Smith]

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?

The instructor was certainly not experienced in Java. However, a far
more important question arises: if most of the class was unfamiliar with
Java or OO, why did *most* of this stuff come up in a two-day class?
You seem to have covered everything from OO concepts to the Java
language to JDBC, Swing, and user interfaces all in two days. My guess
is that NONE of the other students in the class got anything at all from
the training, because the objectives were WAY out of touch with the time
frame.

Anyway, here are comments on the specifics:

1. Java is pass by reference.

This is a potentially misleading and inaccurate comment, but its use may
be attributed to sloppiness. There are any number of people familiar
with Java programming who would make that statement. As to whether any
of them ought to be teaching a class on Java, that's another question.
I'm tempted to assess that it falls into the difference between an
acceptable class and an outstanding one.

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

While this is technically false, the point being made here is a good
one; namely, that it's pointless to write "new String(...)". Of course,
it would be nice if the instructor were more precise and able to
articulate exactly what the added syntax does, and *why* it is certain
to be useless.

3. Never heard of SpringLayout

SpringLayout is relatively new (1.4) and comparatively little-used in my
experience. This, along with several other points, causes me to suspect
that your instructor hasn't been keeping up on GUI APIs for several
years. Alone, it's certainly not unforgivable...

4. Never heard of the EventHandler utility class and couldn't see why
it would be useful when explained to him.

I was also unfamiliar with any class called EventHandler until I looked
it up in the Java API docs. Even now, I can't believe that anyone could
be reasonably expected to know about java.beans.EventHandler off the top
of their head. In fact, I tend to think that the class is a poor idea
in general, and uses of it should be replaced with anonymous inner
classes.

Something makes me think you meant to say java.util.EventListener. In
that case, someone with a reasonably deep knowledge of the Java event
idiom ought to know about it... but I agree with your instructor
thinking that it is pointless.

He also asserted that you
should only ever use inner classes as event handlers and saw no reason
for using Swing Actions.

It is also possible to write very well-designed applications without
using Action at all. This could be reasonably debated between well-
informed persons. The Action class seems to have some advantage in
separation of concerns, but one could disagree as to whether it draws
those lines of separation at the right place.

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

This is clearly wrong, but I'm unsure what could have been meant by it.

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

This is, again, an opinion. Your instructor, if reasonably familiar
with the field, is entitled to his views on GUI builders. I personally
don't use them and think that they have certain problems, but they also
undeniably have certain benefits.

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

Again, my biggest concern here was that this instructor was dealing with
JDBC at all. Probably a very small percentage of database-oriented
applications use or have any purpose for RowSet, and since it's fairly
new it is understandable (obviously not good, though) for someone with
aging Java experience to not be familiar with it. I get the impression
that your previous experience or some other source has left you with an
inflated opinion of the value of RowSets in JDBC.

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

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

Between these two, it seems your instructor was comparing "old" Java
standard layouts: namely, FlowLayout, GridLayout, BorderLayout,
GridBagLayout, and CardLayout. In that case, he is probably correct.

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.

This does seem odd...

11. Stated that you can not develop Swing applications using a GUI
builder plug-in with 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.

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

Again, with a few years of age taken into account, he was probably right
at some point in the past.

14. Repeatedly described static initialisers as static constructors.

So? Everyone has verbal slips regarding terminology. I don't see the
term as all that confusing.

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

This is true for Internet Explorer. The Java Plugin for IE is an
ActiveX control.

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.

You can make your own judgements here. There are certainly things
involved in this description that ought to be considered suspicious or
dubious. Most concerning to me is the apparent lack of current
knowledge; this guy may have really known this topic two years ago, but
he is short on current knowledge or expertise.

For the third time, though, there appear to have been some serious
problems in course planning long before the instructor arrived.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

Java is definitely pass by reference.

See plenty of past discussion in this newsgroup for the full story here.
Dale King was heavily involved in a lot of it, if that helps your search
to be better defined. The whole thing is summarized at
http://www.yoda.arachsys.com/java/passing.html by Jon Skeet.

The essence of the discussion is this: no, Java does not implement
actual "pass by reference", and those arguing that Java passes by
reference do not generally understand with the term actually means, and
are confused by the fact that references are often passed as parameters
in Java.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tor Iver Wilhelmsen]

1. Java is pass by reference.

No, pass by value only, but the value of a reference/pointer variable
is the pointer value.

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

A quick glance at String.java in src.zip would tell him otherwise.

3. Never heard of SpringLayout

It's not that well-known to people who used Swing prior to 1.3.

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

"Never" is too strong.

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

Irrational. Is the a former Visual Basic head?

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

Stuck in old JDBC then.

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

Manually using GridBagLayout makes development "unmanageable". I used
to love GBL, but have sided more and more with the "nested components
with their own layouts" camp instead.

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

This is somewhat correct. The weight, anchor and cell spannig elements
make it closer to a "HTML Table" type of layout. But Box and Spring
layouts can do most of what GBL does.

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.

That was very strange.

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

IIRC that used to be true, but not lately.

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

That was utter nonsense, yes: Class is more of a metaclass.

14. Repeatedly described static initialisers as static constructors.

He should keep the terms separate.

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

Sort of incorrect, though the plugin does act like such a control.

 

[JavaEnquirer]

Thank you very much for taking time out to reply. Yes, in fairness to
the instructor he had to cram a very large amount into a short period
of time, but the reasons for that are complex. However, if he'd toned
down his assertions, or at least conceded more readily that there were
alternative ways of looking at things, my misgivings would have been
lessened. Apologies also for being a little imprecise in some of my
points.

While this is technically false, the point being made here is a good
one; namely, that it's pointless to write "new String(...)".

Ah, but his slides contained a lot of new Strings(), he saw no harm in
it, whereas, as far as I believe, new String() can in some instances
bypass the JVM's String caching mechanism and hence waste memory. He
insisted it was merely syntactic sugar.

Agreed, however, its a bit annoying when he states that he's never
heard of it in a manner that implies you are being a little foolish for
mentioning it.

I was also unfamiliar with any class called EventHandler until I looked
it up in the Java API docs.

Yep, I was talking about the EventHandler class. I suggested it as a
possible alternative to writing large amounts of inner class code. He
seemed to be biased towards what I call bloated controllers. I would
rather where appropriate, my GUI events getting delegated to classes
which then process the event. The delegate can then be reused by other
GUI controls, or indeed, in some circumstances outside of a GUI
context. You obviously have to be reasonable about things as you can
end up with a kind of class/object cancer littering your package
hierarchy with too many classes.

However, he could not see this. As far as I'm conerned, if you are
spending your life writing loads of boiler plate code, you don't have a
very good GUI framework, and you'd probably end up inventing something
like EventHandler yourself albeit a lot better!

This is clearly wrong, but I'm unsure what could have been meant by

it.

I took it to mean exactly what it says, given that he was very biased
towards GUI builders ( his consultancy has a partnership with a
prominent GUI builder supplier ). He ridiculed the alternative of "hand
coding" GUIs and didn't seem to appreciate that OO ( which he seemed to
understand well ) can extend to the user interface. I like to reuse my
UI components and I want to customise them for bilingual requirements
such as those we have here.

This is, again, an opinion.

Exactly, he should have stated both sides of the argument.

Again, my biggest concern here was that this instructor was dealing with
JDBC at all. Probably a very small percentage of database-oriented
applications use or have any purpose for RowSet, and since it's fairly
new it is understandable (obviously not good, though) for someone with
aging Java experience to not be familiar with it. I get the impression
that your previous experience or some other source has left you with an
inflated opinion of the value of RowSets in JDBC.

One of the attendees asked if you could use offline resultsets in the
manner of ADO recordsets. He said no. I was surprised as I'd heard of
RowSets and mentioned the possibility.

Between these two, it seems your instructor was comparing "old" Java
standard layouts: namely, FlowLayout, GridLayout, BorderLayout,
GridBagLayout, and CardLayout. In that case, he is probably correct.

I'm surprised by this as every Java application I've worked on has
avoided GridBag completely, yet has looked really impresive and the
products have made a lot of money.

constructors.

So? Everyone has verbal slips regarding terminology. I don't see the
term as all that confusing.

If that was his only slip up, fair enough. However, a static
initialiser does not construct, it is that exact opposite, it does not
run against an instance, it initialises "class side" code.

This is true for Internet Explorer. The Java Plugin for IE is an
ActiveX control.

Sorry, I was vague here. He said that you had to write about half a
screen full of code around the APPLET tag in order to launch the
ActiveX control. He ran a program against the html with the Applet tag.
This program added the extra code. I may be missing something here as I
wrote and deployed an applet on IE 6 a few weeks back using only the
APPLET tag in the HTML.

 

[JavaEnquirer]

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.

Take a look at:

http://java.sun.com/developer/JDCTechTips/2001/tt1009.html

http://java.sun.com/docs/books/tutorial/java/javaOO/arguments.html

http://www-106.ibm.com/developerworks/java/library/j-passbyval/

http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html

http://www.jguru.com/faq/view.jsp?EID=430996

Thanks again.

 

[JavaEnquirer]

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

5. His presentation slides stated that you should never modify/extend

any of the base Swing components.

"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 was a bit vague on one point:

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

What I meant to say was, he stated that you had to modify your HTML to
take this into account, simply using the APPLET tag was not enough.

Thanks again.

 

[Bent C Dalager]

Sorry, I was vague here. He said that you had to write about half a
screen full of code around the APPLET tag in order to launch the
ActiveX control. He ran a program against the html with the Applet tag.

Could it have been code intended to automatically download Sun's Java
Plugin if necessary?

Cheers
Bent D

 

[JavaEnquirer]

Ah, you may be right about that. So, am I right in think that it was
around the time of Java 2 that Microsoft stopped shipping JVMs with IE?
If so, that is what he may have been talking about. Probably my fault
in understanding. In fairness, he was rushing a this point.

So, is there a commonly used utility for decorating the APPLET tag with
the necessary "stuff" for dealing with ActiveX and the automatic Java
plug-in download?

 

[Bent C Dalager]

So, is there a commonly used utility for decorating the APPLET tag with
the necessary "stuff" for dealing with ActiveX and the automatic Java
plug-in download?

I'm not sure about applets but I have seen examples on Sun's web site
on how to do the same for Java Web Start apps.

Cheers
Bent D

 

[Joseph Dionne]

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 was a bit vague on one point:




What I meant to say was, he stated that you had to modify your HTML to
take this into account, simply using the APPLET tag was not enough.

Thanks again.

If his advise was not to modify/extend the Sun source, I agree with him.

 

[Joseph Dionne]

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?

[snip]

I think his presentation, based solely on your account, was lacking and
deserving of a strongly worded letter expressing your disappointment
with his services. You should highlight the responses your have
received here, and IMHO, request a partial refund or additional services
at no additional charge. A consultant of any strip should meet you
halfway if only to regain your favorable opinion of his services.

In the future, contracting consultants that are actually in the trenches
and writing marketable products as well as training services would be
advisable. Authors, regardless of their decades of experience, who
simply paraphrase the API docs, and information gleaned from google
searches, should not be your first choice, at any price.

 

[Tim Tyler]

So, is there a commonly used utility for decorating the APPLET tag with
the necessary "stuff" for dealing with ActiveX and the automatic Java
plug-in download?

Yes - see:

``Java Plug-in Software HTML Converter''

- http://java.sun.com/products/plugin/1.2/features.html

 

[Ben_]

So, is there a commonly used utility for decorating the APPLET tag with

the necessary "stuff" for dealing with ActiveX and the automatic Java
plug-in download?

See HTMLConverter in <jdk>\bin.

The Java plug-in also has the ability to register as the default browser VM
(IE, NS, Moz), so that it's not necessary to use the Ojbect tag instead of
the Applet tag. But you're then client-dependant.

 

[Chris Smith]

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.

Whoa! I'd definitely stop well short of this. In fact, much of the
functionality you mention here is outside of what I'd consider doing by
extending a Swing base class. Extending base classes such as JPanel is
quite useful for developing an actual custom component, and a large
number of applications could benefit from such things and seem awkward
when built with standard components. There are also good specific
reasons to subclass specific components (JTable, for example).
Multilingual labels, though, are much better handled by setting the text
from a ResourceBundle, without subclassing the component. Popup menus
may also be implemented by calling methods on the component rather than
subclassing it.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[JavaEnquirer]

If his advise was not to modify/extend the Sun source, I agree with

him.

Ah, he was not saying not to modify the source, he was saying not to
subclass/extend any Swing components and modify their behavior by
overriding.

 

[Joona I Palaste]

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?

1. Java is pass by reference.

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

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

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

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.

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

14. Repeatedly described static initialisers as static constructors.

Based on these points (particularly points 1, 2 and 13 are flat-out
wrong), I think the consultant was not exactly up-to-scratch with Java.
If he presented these points as objective facts, then I think you
should complain to his company about his lack of expertise.

 

[Larry Barowski]

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

coding was a no-no.
Blasphemy!

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

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