In 1997 I started working for Sun Microsystems doing technical support for hardware swaps, Solaris and then UNIX commands for, system administrators. In 2000 I went to the first level of backline support for legacy compilers spending my most productive time in getting bug reports from front-line engineers to compiler engeneering after further tests were done and returned patches to compilers for the languages supported by gcc, C, C++ Pascal, and Fortran. Sun made about $1 Million a year from the last, which I had once worked with and knew enough to report back and forth between customers and compiler engineering.
In 2002 I was asked to learn Java and to do direct support of users of Sun's java IDE and what would become netbeans. I did see the later again a couple of years ago and see that it had improved greatly. In particular it had a much better linkage between idioms in the language and the documentation of the class libraries that had been supported. At the current time eclipse seems to be the favored IDE for java and netbeans is no longer supported by the vendor for my system.
I had trouble with this assignment not because I didn't know Java, but because the complexity of the class libraries Sun supplied both in the basic language and in the applications was daunting. I didn't want to memorize all that detail and in addition I felt that using the debugging information supplied by the compiler and applications was very hard for me to use with my vision disability of low visual acuity. Because I thought that the design of the Java classes was poor and I didn't agree with the emphesis at the time by Sun on Java as opposed to the other parts of its business, I left in 2004 after letting myself get laid off. I had actually lost faith in Sun earlier, as early as 2002.
This past week I saw that some You Tube videos of lectures for a course at Stanford University School of Engineering was available called "Programming Methodology" was available. I watched the first video and quickly learned that it was an introduction to Java programming, I had taken similar courses at Sun and had a good intorduction to Object Programming via C++ and had explored OOD in perl and python. My interest was perked by the approach advocated by Stanford in the top interface to the programs supplied in acm.jar, an alternative interface to the standard Sun libraries. This was created by a working group at Association for Computing Machinery (ACM) to address some of the difficulaties in teaching Java, namely the inscrutability of constructs most students and novices encounter immediately in using the language as supplied by Sun. It was immediately obvious that acm.jar was a superior interface even though it probably just extends the standard Sun class libraries and for some things one still has to import the standard class libraries, but by treating each device interface as a similar object a one token change in the program allows the same output to work on a consoole, the standard_out and a graphics canvas. This vindicates my view that the Sun libraries were poorly done. Another indication of this is that when Sun open sourced java, which I think was in 2006, that almost immediately libraries were drafted for it as alternatives to the ones shipped by Sun. It is a feature of Java that one can hide features in a class library to create a different encapsulation by extending one of more imports. That is a strength. It is too bad that the people at Sun didn't provide more interfaces. Part of me think that the complexty is intentional part of the security obvscation.
I feelt that the shift in focus made by Sun in 2002 turned out to be its final undoing because it demphesied lucruative, if not sexy aspects, of its business at the same time it was giving away its touted java technology. One of the selling point of java was supposed to be security on the web. So now we are several years after Oracle's acquistion of Sun and this week a major secuirty flaw in the web-plugin was disclosed and at least pratly addressed by patches. The matter was made urgent by the recommendation of late last week from no less than the Office of Homelamd Security via a CERT notification that the browser plugin be disabled. I got updates to two of my systems by this morning that may be adressing this, but it is surly a major embarassment for Oracle and java users world-wide.
When I first heard of Java and OOD in about 1993 I was impressed and I explained the advantages of it to several interested parties, and I liked most aspects of the core language. I had learned C many years before, and the tidyness of that language and the small size of libc was a decent trade off over the myrid ways a careless programmer could hang himself misusing pointers. In fact I had seen an example of an ASCII C program which implemented objects in a disciplined protocol of functions called with pointers and with fixed interfaces that had the same scoping that java would use. I understood java would do away with user's manipulating pointers. The problem with Java and most every OOD language is that the encapsalation can obvescate poor interface design to the class libraries. No langage conventions can fix that.
It is the coding conventions for java coding that caused me the most problems as an engineer. It was specfically camel text, not allowing white space or punctuation in function and variable names and just using tokens that begin with a capital letter. Oh, I know about the use of underscore as an alternative but unless most programmers and editors allow for an easy translation to and from, you are always reading dumps for crashed programs or debugging traces in camel text. Camel text is very hard on people with low vision. just making the font bigger and bolder isn't enough. Even I didn't fully understand that at the time. A visually impaired systems admin I meet later flat out asserted that java was not accessable.