On Dec 15, 2007, at 3:09 AM, Michael Poil wrote:
----------------------SNIP--------------------------------
As for the criticism "JAVA was probably rewritten for the MF
without the
years and years of experienced IBM design philosophy and
debugging", I am
in a privileged position where I can see the amount of work that
has been
invested in its design over many years, I can assure you that your
assertion is untrue. If you were allowed to visit the lab and see for
yourself, you might change your mind.
Well OK I reserve judgement until then but if true they are looking
extremely guilty right now just with the surface discussion on here,
IMO.
No trace tables, no Messages and Codes, No SAG, no MANUALS PERIOD.
(If there are I sure have not heard of any), NO CLASSES (IBM) (Steve
here is your que). Especially no debugging classes (big call to
Steve), It should would embarrass IBM to have a 3rd party offer
something.
IBM has let loose a product nobody can put their hands on. This is
extremely unlike IBM, if this is the future I hate to say it maybe
its time for the MF to die.
One of the big problems was that the Java design required it to
support
"lazy" programming whereby the programmer did not have to clean up
dynamically-allocated data areas (thus avoiding user storage creep
- see I
am using the "right" terminology now). This resulted in the need for a
large pool of storage (the JVM heap) and very complex and
sophisticated
code to do what the programmers should have been doing (Garbage
Collection). The OO design also costs due to its complexity versus
more
traditional languages.
That still doesn't sound like the traditional IBM any old time (IMO)
would have made a method o this apparent madness for debugging
purposes when this is let (wait its too kate) go to the customer.
What I am understanding from your writing there is no way to debug
this monster and we are essentially buying a pig in a poke. Don't
ever open a PMR as it will certainly never be closed (with a fix).
The totally portable byte code (Sun design) was initially
interpreted and
was too slow, so various techniques were used to compile the byte code
into machine code, resulting in the JIT which compiles on the fly;
again
complex and needing storage for compilation and storing the compiled
results.
All software products in this category need yet more storage to
function,
I worked in CICS a few years back and I know that it is the case,
it has
to manage the environment and this costs.
I could hark back to my System/360 with 64K of memory and Assembler
- we
managed to get applications to work with real memory, none of this
Virtual
Storage nonsense etc. etc. etc. Technology moves on, and the extra
sophistication costs, but we now have the hardware and OS to match the
demands.
No language is perfect, but Java provides a write-once-run-anywhere
facility that would have been undreamed of back in the early days.
I even
had to convert COBOL to run on different platforms, never mind all the
other myriad languages that were available somewhere but not
everywhere.
Unless it can be debugged (in a timelyt fashion) it is a non
dependable (ie production) product and should never be used in that
environment, IMO.
I have a feeling that there are possibly a large number that I am
never
going to convince, but I can't just sit back and ignore assertions
like
the above that are made due to lack of knowledge. Probably going to
get a
load of flack about this, but I will never be Politically Correct,
I tend
to speak my mind.
We are willing to be convinced but like I said before the dragon has
no clothes.
Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
