Java: Recommended Skeptic Papers

There is a programming language lifecycle. Understanding and predicting this lifecycle is tremendously important for IT directors and technical architects. It is even more important for those with a vested interested in the language succeeding, to know when to switch to a new language.

"Those with the most to lose are the slowest to recognise change"

Many languages have been through lifecycles. Languages have met purposes, and languages have continued to fulfil purposes.

But those with the most to lose are often the slowest to recognise change when it occurs. Most people simply follow the herd, but vendors and companies who are sufficiently aware can take market leading positions.

The older you get the faster time flies. Having been involved in the lifecycles of several languages, I'm beginning to recognise some of the signs and wonder where Java is.

Often the time to change is when you least expect to. I was involved in the end of the 'C' lifecycle, and involved at the beginning of the C++ lifecycle. I remember sitting at a desk in 1988 thinking "These C stuct pointers are such a pain"; six months later I was handed Borland's C++ pre-compiler at a conference.

I was also involved at the end of the C++ cycle and beginning of the Java lifecycle when I adopted the Beta versions of Java back in 1996.I remember programming on a trading floor in 1995 thinking: "These C++ libraries are such a pain"; six months later I found the Oak project (which later turned into Java).

"New languages must compete with older languages"

The stages of any lifecycle are based on the natural principles of growth, maturation and decay. Whilst these stages are not a judgement on the language, they do reflect a general community opinion. The same processes of natural advantage and mutation operate in the world of programming languages in the same way that they operate in the biologic domain.

In the case of languages, the main forces are efficiency of expression vs. profitable adoption. New languages must compete with older languages; if they are general purpose, functional, expressive and marketed then they stand a chance of being adopted.

Interestingly, it is the application market that drives language evolution. This is because the application market is where the profitable adoption is most significant. Beyond that, Investment Banks are often at the forefront of profitable adoption because with such high profits, they can afford to pay for maturation costs.

I have divided the lifecycle into the following stages:

Conception
Adoption
Acceptance
Maturation
Inefficiency
Deprecation
Decay

Conception
A language is conceived to meet a requirement that other languages do not meet. Countless languages have been written but of those C++, MFC, Java have been backed by budgets.

Adoption
Languages are adopted to make the programmer more efficient. This is driven by the programmers because they are bright and don't like mundane coding. Languages have API's back into the libraries of those they are replacing.

Acceptance
Once the market sees that tools are sufficiently bug free and early adopters have made profits, there is a general acceptance of a language. Green field projects expose requirements and ideas for tools, and libraries are conceived.

Maturation
Languages, libraries and tools mature. They are capable and deliver profitable solutions. There is an increased demand for functionality, rather than efficiency, in order to reap profits. Standards bodies attempt to control the spread of ideas.

Inefficiency
Development has become slow as libraries become more inefficient. The rush to provide functionality has created a market that is subtly fragmented by vendors implementing standards differently. There is a large increase in the number of case tools and code generators.

Deprecation
Developers start to understand that it is costly to develop using the language. Frustration begins to set in, and designers take a deeper look at the issues causing the inefficiencies.

Decay
A young pretender appears and challenges the leader. Lean, mean and fast, the new language has apparently come from a research department of a large technology company. Marketing departments lock horns and invariably the old order is overthrown.

 

"A relationship with general economic cycles"

Interestingly, I have noticed that programming language lifecycles have a relationship with general economic cycles. Competition between languages takes place when a language has become inefficient.

At the beginning of the upturn in an economic cycle, resources are scarce and development is required. It is then that the more efficient languages win out.

Going into a recession, resources are cheap, efficiency and expressiveness are not high priorities, and languages become bloated and inefficient.

C, C++ and Java were all taken up by the early adopters at the start of an economic upturn. Fundamentally a new language is smaller, lightweight and more efficient. The choice between an old and a new language is often one between a ready made, but inefficient architecture and architectural building blocks.

So where does that leave Java?

"A young pretender will emerge from a research project"

Certainly we are now getting into the Inefficiency phase of the Java Lifecycle. J2EE and EJB form a ready made architecture that is expensive to develop. It would be hard to see small companies justifying the current development costs when we come out of the downturn in a year or so.

I believe that a similar event will occur as with previous language-shifts: a young pretender will appear from a research project, probably as early as the beginning of next year. As with the last shift, the new language will adopt the hard-learnt application semantics from the previous languages.

For C++ this was OO, for Java this was libraries and standardised API's. For the next language, the clear application semantics 'discovered' by Java is the bean/EJB semantics of properties, events, homes and sessions.

.NET from Microsoft has several bean-like properties built into the language, making it a potential contender. Like Java's adoption of C++ syntax, C# has adopted Java's libraries. However, I believe Microsoft made a strategic error in adopting Java's libraries, and not building bean/EJB-like semantics deeper into the .NET language. They could now be leveraging this functionality to automatically persist and deploy beans.

I don't really see C# as being significantly better than Java to challenge it on that basis.

Similarly, I believe Sun made a strategic error in sitting back and not developing a Java++ language that builds bean/EJB-like muscle into the language rather than fat on top of it, as EJB does.

Given the history of language evolution, the shift from C to C++ marked a requirement for extensive libraries to be made available. Having said that, both C++ and Java made an effort to reuse the existing code base of their predecessor.

"Component-Oriented Languages"

One of the most promising areas of research is the design of the so called 'component-oriented' languages. These differ from object-oriented languages in that they offer messaging, properties, events, sessions and homes all built into the language.

Importantly, they also distinguish between definition of the components and the components implementation. This means that it will be possible to define an application without actually saying what will be rendered into the technology; for example how it is presented or how it will be persisted.

Whatever happens next, the next few years are going to be interesting.

About the author:
Robin Sharp is the Managing Director of Javelin Software (http://www.javelinsoft.com).
He can be reached at [email protected]

 

Talkback:

Post a new message

Message Index:

Like Moore's Law....
Laurence Vanhelsuwe

Totally agreed to Mr. Vanhelsuwe
Sidney Fortes

Agreed
robin.sharp [email protected]

Why no mentioning of scripting languages?
Jack Herrington [email protected]

2cents
Joubin [email protected]

The Messages:

Like Moore's Law....
Your article contains an interesting concept, i.e. that of lifecycles of programming languages, and the "survival of the fittest" over time.

Lest people get the impression that every 10 years we will have new languages to play with, your article hints at a roadblock for this scenario: libraries, and a general (exponential?) increase in complexity built-in to the language. Niklaus Wirth "knocked up" Pascal in a few months, C++ took quite a bit longer. Java has taken years (chiefly because of library design and implementation, and JVM work). Future languages will not pop out of the ground like mushrooms. Future successful programming languages will be astronomically costly software systems to invent and develop.

Experienced programmers like myself who 10-15 years ago could have toyed with the idea of designing a better language in one's bedroom, so to speak, have no hope in hell today. Language evolution is slowing down, not speeding up. Gone forever are the 60s and 70s where one or two individuals could design and implement a new language, and make it fly in the real world.

Nowadays, the libraries are the Achilles heel: without great libraries, no self-respecting Java programmer is going to abandon Java to go to a "better" language. Great libraries, as Sun knows all too well, cost not only fortunes to develop, but also many, many years.

My opinion is therefore that we are approaching a horizon where man-designed programming languages will be born less and less frequently. Maybe it's time for computers to start designing these things for us? ;-)


Laurence Vanhelsuwe
Scotland
Sat May 11 11:00:07 BST 2002

---

Totally agreed to Mr. Vanhelsuwe
Just wanna add my 2 cents to Mr. Vanhelsuwe.
Like Dr. Stroustrup says in his book,"A general purpose language will never be the best one for a specialized area", there are trade-offs and wiser is the IT manager who can analize and decide which programming language is going to be used for a specific project.
I believe that if we take this "programming language war" personally, we are just contributing for failure in our next projects.
Sidney Fortes
Sr. Software Engineer - Miami, FL, US
Mon May 20 16:51:50 BST 2002

---

Agreed
I agree with what you say about programming languages slowing down. The jump from C to C++ and C++ to Java and Java to C# has been one of modification.

In the later articles I describe how I think these modifications create qualitative shifts. For example component orientation adds certain features, and domain orientation doesn't really add to the language (per se) at all, but to its usage.

robin.sharp [email protected]
UK
Mon Jul 01 11:04:36 BST 2002

---

Why no mentioning of scripting languages?
 completely centers around the C, C++, Java, C# line of language development. This is only one thin sliver of the language tree.

What about the exciting work being done in Python, Perl 6, Ruby, Javascript and the other interpreted languages.
Jack Herrington [email protected]
Bay Area, CA, USA
Sat Sep 07 22:33:04 BST 2002

---

2cents
Thank you Mr. Sharp for sharing your insights. I found the correlation between economic and language cycles quite interesting.

Regarding Mr. Vanhelsuwe's remarks: I say **Reuse!**

For example, I clearly agree w/ the paper's prediction regarding emergence of CO languages. If you think about C.Orientation, you realize that it has little to do with 'libraries' (i.e. functionality) and everything to do with development (thus the new CO language), and the packaging, assembly, deployment, etc., of these functionalities in an **adaptive** manner. (This, BTW, is the whole point aparentlly completely misunderstood, and flawed, EJB specs.)

The 'pretender' needs only a clear mind to grasp the patterns and devise the language that builds on top of an existing OO infrastructure. And being a 'lone pretender', there is little incentive to warp the vision to accomidate alliances, market realities, etc. (Issues which Sun clearly faced when developing J2EE.)

I.e. The 'next step' will be an abstraction effort, as opposed to a grounds-up effort, and should be properly mapped to the transition of building _suport for OO_ on top of procedural (C->C++), as opposed to defining a native object system (C++->Java). (This distinction in language transitions, BTW, is a point that Mr. Sharp failed to address in his paper.)

I further agree with Mr. Harrington regarding the apparent blinders regarding scripting. Even though I certainly do not envision a purely scripting future, it is imo CLEAR that in the future we will have Adaptive Component architects, and Scripting assemblers: A 2-tiered development world (comprised of few talented Engineers and great many handy Mechanics) addressing the reality of levels of understanding and capabilities of software developers -- this is a point that Microsoft clearly understands quite well. You don't need deep understanding of software to use .Net. But clearly you require a very deep understanding if you use EJBs.

The days of 'artisan' computing are nearly over. And the 'model T' is just over the horizon.

Peace.
Joubin [email protected]

A critique of Java

Conclusions

Good programming requires using a good language. The way to understand a language is a good indicator of how well it is designed; ideally, one should be able to learn incrementally, building constructively on past learning. Simple things should be easy, complex things should not conflict with simple things. But with Java, one is always having to revise one's "knowledge" of it as more is learnt.

The problem with a complex language like Java is that so much is unsaid. Sometimes this results in clearer and more compact programs. They don't need to mention garbage collection, and they can't get it wrong. But sometimes it leads to incredible but hidden complexity -- such as the obscure rules for inheritance.

If we regret some aspects of Java's design, then we must ensure that future designers take better account of good design practice. Many Java programmers believe Java is a great success. Yet their programs are usually written in a Java-like subset of C. They surely gain by not having the risks of pointers and unchecked array subscripting. Thus, we cannot conclude it is just the design of Java to blame: much of the poor quality of programming (including the rough-and-ready implementations of Java and its packages) is due to lack of programming skill. "Proper" computing science, including human computer interaction and software engineering, have been taught long enough to be well known; it is now time well-trained designers and programmers start to raise standards. They need to be taught not just what is, but what could be.

We started with a quote from Tony Hoare, and we end with one from the same 1980 Turing Award lecture:² "I conclude that there are two ways of constructing a software design: One way is to make it so simple there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." The concern about Java is that it is a third way: it looks simple yet is complicated enough to conceal obvious deficiencies.

Java Hate Page Things I hate about Java & Java bytecode

This list is mostly based on experience with JDK 1.0.2.

1. No parameterised types!
2. A constructor does not implicitly call its superclass' constructor with the same signature when available. Thus to properly inherit a constructor that takes an argument, you need to redefine it to explicitly call the corresponding constructor in the superclass.
3. No parameterised types!
4. The file structure is forced to match the name structure.
5. No parameterised types!
6. There is nooo... point 6.
7. It is not obvious whether a lone .class file is generated from another .java file, or has had its source file deleted.
8. The basic types are not objects, and it is slow and bothersome to use them as such.
9. An abstract method called in another method will have to be redefined in any subclass, even if that, too, is abstract.
10. Once you make a subpackage, as in foo.bar, that subtype only knows of things it imports and at its own level, not of those on a higher level. This makes it difficult to split large class collections into managable parts, which means you'll end up with a terribly large directory for all your classes or with a lot of public fields/methods.
11. No unions. I can't have e.g. an array of bytes in a superclass, and then have the childs give meaning to parts of them.
12. System.exit is not recognized as a non-returning procedure, so bogus returns and initializations may need to be inserted.
13. The dead-code elimination provided by the compiler is not a good substitute for #ifdef, since it only works within a method. There is no good way to have different fields, methodnames, parameters, classnames, protections or inheritance chains for different setups. For instance, in a program with two primary functions that share some much-used object, fields that are only used by one of the functions could be #ifdef'd to save memory for the other. Our particular example would not have been a problem if there were parameterised types, but other may not.
14. The Javac compiler tries to recompile files as required when changes have occured, but doesn't always find all the relevant files.
15. Even if a class defines the necessary functions for an interface, one cannot get it accepted as implementing that interface without recompilation. For instance, it is impossible to make an 'Equality' interface that includes system classes with the 'equals' method.
16. There is no simple way to make a consistent toString function for arrays. You would have to make your own toString, as e.g. Vector.toString can't be made to call a good toString for arrays.

The standard class libraries suck so much, they have their own list

1. The class libraries lack several important structures, such as binary tree, sorted list, heap etc.
2. Many parts of the class libraries are final, making it impossible to reuse them for making further structures. Why not have a final class which is secure, and a non-final version which is good for extending?
3. Furthermore, such a simple function as recursive 'equals' does not exist for Vector.
4. The elements() method of Vector doesn't produce an enumerator that is stable towards removeElement().
5. Bitset doesn't have simple things such as lessThan, allSet etc,

The Software View: Java's past, present, and future

The Java Hall of Shame

java sucks

A Quick Critique of Java

The Next Worst Part of Java: Too Many Pointers, Too Little Pointer Support

Java syntax resembles C++ syntax, except it is missing pointer math and has almost no pointer support. Of course, that's like saying FORTRAN resembles 'C', except for it doesn't have pointers. :-) Pointers are not some small after thought or accident in 'C', they are a fundamental part of one of the most beautifully powerful and elegant languages ever created. (If it wasn't obvious by now, I'm a hard-core 'C' fan. :-)

Although you might have heard that Java has no pointers, that's actually untrue. Java is riddled with pointers. You cannot declare a structure or object on the stack, but instead you must declare a pointer to the structure on the stack and then use "new" to allocate the memory for the structure in the heap, and then let the garbage collector free the structure sometime after the method finishes. Also, the designers of Java decided it was not useful to have an array of structures (hard to believe, but true), so in Java you cannot have an array of structures or objects, but instead you must have an array of pointers to objects which you therefore must allocate from the heap using "new".

In other words, the only way to refer to objects in Java is by pointers, but Java calls them "references to objects" in a lame attempt to pretend they are not pointers. Experienced programmers will see through this immediately, while Java will confuse less experienced programmers. Below is a Java code snippet dealing with the class "Point" which is a simple structure containing an "x" and "y" integer. This example shows how the Java designers gratuitously diverged from the C++ syntax in a misguided attempt to hide pointers from the programmer.

        Point p1, p2; // declare p1 and p2 as references to a "Point" obj
        
        p1 = new Point(1, 2); 
        System.out.println("x=" + p1.x + " y=" + p1.y); // print p1's coords
        
        p2 = p1;      // am I assigning a pointer? Or copying the obj??
        p2.x = 3;
        p2.y = 4;
        System.out.println("x=" + p1.x + " y=" + p1.y); // print p1's coords

In my opinion, the Java designers made a fairly large mistake when they decided not to copy C++ syntax more closely. Here is the same code snippet in C++ where I avoid using the shorthand "->" symbol for clarity:

        Point *p1, *p2; // declare p1 and p2 as pointers to a "Point" obj
        
        p1 = new Point(1, 2); 
        printf("x=%d y=%d\n", (*p1).x, (*p1).y); // print p1's coords
        
        p2 = p1;        // clearly assigning a pointer
        (*p2).x = 3;
        (*p2).y = 4;
        printf("x=%d y=%d\n", (*p1).x, (*p1).y); // print p1's coords

Although at first glance the Java notation *SEEMS* cleaner because it has less symbols, my claim is that it is not consistent and therefore less clear than the C++ syntax especially in more complex code examples. In C++, the two points are clearly defined as pointers that don't have associated objects unless you call "new Point()", while in Java this is not clear. Also, in C++ it is made clear when you de-reference the pointer to get at the contents, vs. assigning two pointers to the same object. The Java syntax is less clear, and depends on the situation which is annoying to say the least. Also, the Java syntax does not allow the useful structure copy: "*p2 = *p1" and in fact there is no way to copy a structure in Java (except by assigning each individual field of course).

One of the claims I've heard is that pointers and pointer math open a language up to security issues. Although this is used as an excuse, this would not cause the deviation from 'C++' syntax shown in the above example. The example shows that the changes were gratuitous, and had no real justifiable reason. The following quote from page 71 in "Teach Yourself Java in 21 Days" might shed some light on what the Java designers were thinking:

"There are no pointers in Java ... with Java arrays you have most of the capabilities that you have with pointers [in 'C'] without the confusion and lurking bugs that ... pointers can create."

This statement shows a complete lack of appreciation for the beauty and power and elegance of pointers in 'C'. Although this came from one book, I suspect it reflects the Java designers' attitudes towards pointers, which is that pointers cause confusion and are really not all that useful.

I could believe Java was designed by a bunch of LISP-heads, who never understood the whole darn point of 'C'. They didn't understand the elegance and speed and economy of syntax of walking down a list pointing to the CORRECT part of the object immediately with a dereference of a field and an "&" in the right place. And after my first 4,000 line Java applet, I hate them for their lack of understanding.

Java's Schizoid GUI Toolkit

Java provides a standard GUI toolkit, which means that you can write portable applets that will run on PC clones, Macintosh, and UNIX all with exactly the same source code. This is a good thing. The unfortunate part is that this GUI toolkit was designed by engineers from Sun Microsystems, which is world renowned for the most putridly awful graphical interfaces on the planet. Seriously, in the OpenWindows project that has now been abandoned, Sun created what nobody thought was possible: a windowing system that was WORSE than Microsoft Windows. If you ever want to laugh yourself unconscious, find an old Sun running OpenWindows and play with the scrollbar. But I digress...

The Java GUI toolkit is called "AWT" (a windowing toolkit?) and it's fairly easy to use when it does what you want it to. However, it feels as though the designers have not actually used the AWT to do anything, because it falls so short of providing a decent set of functionality. For example, it would be nice to have a one line way of posting a dialog with a simple message and an "Ok" button (and optionally a "Cancel" button). But that would make sense and be easy, so instead the Java designers force you to do the following:

To post a dialog, you must subclass the "Dialog" class. In Java you *MUST* have a new source file for each class, so to post a dialog just forced you to create a new source file and add it to your development environment. Inside your subclass, you have to override the event loop to get the ButtonPress events in the "Ok" button, which of course you had to add to the dialog by hand after calling the Dialog super-class constructor. Finally, you have to instantiate, and even *CENTER* the dialog by hand, map it, and worry about when it will be unmapped and freed by the garbage collector. Entering the realm of the weird, the "Dialog" super-class takes a "Frame" as an argument (for no apparent reason), so you actually (and this is gruesome) walk up your widget chain from your applet to find the frame which is hidden someplace up inside the Netscape browser. All to do what should take *EXACTLY* one line of code.

Another missing component any GUI programmer would miss within a few hours of using Java to create interfaces is the "Separator" widget (the horizontal line in a dialog above the "Ok" and "Cancel" buttons). And also there is no way of grouping widgets together like a "Frame" in Motif. Grouping of widgets appears in every modern interface I've ever seen (open up your Netscape "General Preferences" and you will see many groups of widgets), I cannot imagine why it was left out of Java.

But even when a component is present, the API is schizoid. You can draw lines in Java, and you can even draw any arbitrary edged filled polygon, but you cannot draw lines wider than one pixel?!! Huh?? That's insane. Every graphics system on earth can draw wide lines, except for Java. And Java provides fairly nice Font support, but doesn't specify that even *ONE* font will be available. To point out how silly this oversight is, the Netscape your applet is running in requires that a minimum set of varied fonts be available to any WWW page (for headings, body, fixed width text, etc), but Java applets have NO WAY OF ACCESSING those fonts. So the applet designer has no idea what fonts are available for use, or which fonts are recommended. One of the main reasons WWW pages look so much better than email is a small, well chosen, guaranteed set of fonts for headers and paragraph bodies. But Java screwed this up.

Method Parameters: by Reference or by Value?

All method parameters in Java are passed by value, just like in C (not C++). Of course, the reason 'C' could get away with this was the "&" operator, which is missing from Java. So how do you write a method that modifies it's arguments? Here is the one line function call in 'C':

        int i = 0;
        
        incrementInt(&i); /* elegance, grace, beauty and perfect clarity */
        
        /* complete implementation of "incrementInt" */
        void incrementInt(int *i) 
        {
            (*i)++; 
        }  

Here is the same code in Java:

        int i = 0, intPtr = new int[1];
        
        intPtr[0] = i; // wrap the call with gruesome array glue
        incrementInt(intPtr); 
        i = intPtr[0];
        
        /* complete implementation of "incrementInt" */
        void incrementInt(int i[]) 
        {
            (i[0])++; 
        } 

I'm mystified why the Java designers don't allow programmers to use the 'C' shorthand, which is just a little syntactic sugar on top of this disgusting hack. They must not think it is common to modify an argument inside of a function call? How would you return more than one value from a function call?

Java's Threads Disaster

A "thread" is a part of your program that can run concurrently with other parts of your program. For example, a "timer" thread could wake up every second and update a clock display in an application, even while the rest of the application is busy doing something else.

While this might seem like a handy thing that you could use all over the place, threaded code is INCREDIBLY hard to "get right" for reasons I don't want to get into. If you are thinking of putting threads into your application, DON'T!! Find a different way of achieving the same functionality. In the above example, a superior way to update a clock is through a "timer" callback which executes in the same thread as the rest of the application. But in a very, very small number of cases (less than you might think) threads are a necessary evil. In these tiny corner cases, Java supports threads, including the ability to guarantee mutual exclusion on a function, or on any random code block.

But the Java designers really screwed up when it came to threads. Java *FORCES* programmers to use threads by not supplying them with the very simple tools to avoid using them, such as timer callbacks and what Motif calls "workprocs". The ramifications of this boggle my mind. Java applets will be riddled with fatal bugs and instability because poor programmers were forced to use a capability I've seen precious few programmers master.

Here is a quote from page 361 in "Teach Yourself Java in 21 Days" found in the Multithreading chapter:

"A good rule of thumb is that whenever you're doing something that CAN be done in a separate thread, it probably SHOULD be... Threads in Java are relatively cheap ... so don't use them too sparingly."

In my 10 years as a professional software engineer, that is the most offensively irresponsible advice I've ever heard uttered from somebody who claims they know how to program a computer. The author of this chapter, Charles Perkins, is a moron. And not surprisingly, I noticed several bugs in his thread example code in this chapter. Sheesh! Here is another gem of a quote from Charles on page 354:

"threads have only recently been accepted into the mainstream. What's odd about this is that they are extremely valuable, and programs written with them are noticeably better, even to the casual user."

Charles is wrong. What I usually notice as a user of multithreaded applications is that they crash a whole lot, and are slower and less responsive than single threaded applications.

A final note about thread support in Java: the syntax for spawning a new thread is unnecessarily complex and limited. Most thread packages have the ability to "fork" your process into two parts, or launch a thread on a function call. This is simple. Java has this (misguided) idea that threads should relate to the object hierarchy, so you can only launch "Threads" that are objects, and therefore you cannot launch a method off as a new thread, but instead you must create a whole new class which will be run concurrently. Thread objects can inherit from the "Thread" class, or implement the "Runnable Interface" which has several obvious methods like "start()" and "stop()" and "suspend()".

Separating Java Hype From Reality

In fact, significant parts of Java are already being rejected as inadequate. The best example is the AWT window toolkit. Many in the know expect AWT to be replaced by a toolkit that is more flexible, more object-oriented and generally easier to use. Even members of the original Sun team admit that AWT is a hack. They blame the weakness of AWT and other parts of the standard library on the limited amount of time before they had to deliver software to Netscape.

With all the excitement about Java it's easy to miss the fact that it isn't Java that deserves the excitement; it's the ability to produce interactive distributed applications using the web. Java is one way to achieve this. (Or at least it will be when all the missing pieces are in place.) Java isn't the ultimate solution; it's just one more step along a long and tortuous path.

Implementing Assertions for Java in Dr Dobbs Journal Jan 98 - Java Programming By Jeffery E. Payne, Michael A. Schatz, and Matthew N. Schmid Assertions act like watchdogs that assist you in finding bugs earlier in the development process. Unfortunatly Java currently doesn't have them. The authors show how to implement assertions for Java.

Java Reflection - Not just for tool developers in Dr Dobbs Journal Jan 98 - Java Programming By Paul Tremblett With the JDK 1.1 Reflection API, you can not only discover the fields, methods and constructors of loaded classes, but also dynamically manipulate them within the basic security framework. Chris Howard adds a note on the relationship between reflection and JavaBeans. See also Reflecting on Beans

A Taste of Java by Barry Cornelius

Java Native Interface - standard programming interface for writing Java native methods and embedding the Java virtual machine into native applications.

Getting Started with Java

Java Basics by Kevin Karl Lechler

• Encapsulating Java on Embedded Systems - A White Paper from niscom
• Java Products for the Embedded Market by niscom

• Developing Distributed Systems with Java by Barry Cornelius
• Data Structures in Java by: Thomas A. Standish, Uni. of California at Irvine, 555 pages, 1998
• Data Structures and Problem Solving Using Java by Mark Allen Weiss, Florida International Uni., 779 pages, 1998

OOP

• The Essence of Object-Oriented Programming by Bruce Wampler
• The Second A-ha! of Object-Oriented Design: Teaching the fundamental insights of how objects associate in a complex system by David Van Camp
   

Reuse

• Reusing the Wheel by David Van Camp<

  Software developers often proclaim: “Don’t reinvent the wheel!” But the inverse of reinvention is reuse. And, reuse is often easier to proclaim than it is to achieve.
  
  ...
  
  An even more common technique -- perhaps the most common of all -- is to find some code which does almost what we need, then copy and modify it. Those of you who have worked with me know I have a tongue-in-cheek name for this, “inheritance the old-fashioned way.”

Style

• Recommended C Style and Coding Standards
• C++ Coding Standard by Reza Sarmadi

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019