Slashdot Mirror

Unless you have a really good reason (such as writing an IDE), don't do this:

bypassing encapsulation or field and method visibility with reflection

this:

dissecting the binary class file format

or this:

creating post-compilation class "enhancers" like JDO uses

Using the reflection libraries to get around visibility means you're just begging for a maintenance headache in the future.

Dissecting the class file format to see how a particular compiler translated your code can be a useful technique, but you can't depend on the output being the same when you use different compilers on different platforms.

Modifying class files after compilation is also a good way to give yourself a lot of headaches when things go wrong. It becomes very difficult to determine the cause of any problems. If you need to build classes like this, you should either generate Java code and compile that (like most JSP compilers), or use aspect-oriented programming tools like AspectJ.

Basically, you can define an aspect to capture points in your program that are of particular note, and then do debug handling at those points. Aspect oriented programming allows you to break out that debug-handling logic into seperate modules, keeping your main sourcecode nice and clean.

Aspect-oriented programming (AOP) has a lot of other uses too. I think in 5 years or so talking about AOP will be as commonplace as talking about OOP. They are orthogonal concepts.

Cheers, Me

Of course, it's not a true departure from Java... it even recommends that program filenames end in .java . It can compile java code, but not the other way around.

it sounds like you would be interested in Aspect J.

You can do this with AspectJ.

AspectJ enables "the clean modularization of crosscutting concerns such as: error checking and handling, synchronization, context-sensitive behavior, performance optimizations, monitoring and logging, debugging support, multi-object protocols".

Well, AspectJ is doing pretty well, and a new 1.1 version with badly-needed incremental compilation is in the works - it just so happens that, yes, the Xerox PARC research center was spun off as a separate company by Xerox to cut costs. But AspectJ is certainly still alive!

• " ...the guys at Apple, like Bill Atkinson [one of the Lisa programmers who later developed the MacPaint program for the Apple Macintosh computer] -- I think Atkinson is the greatest--and Bill Budge [who programmed Pinball Construction Set for Electronic Arts]. These guys are all great.
  
  We don't have much to talk about. We feel good vibes and exchange three or four words. I know that if one of these guys opens his mouth, he knows what he is talking about. So when he does open his mouth and he does know what he is talking about, it's not a great shock. And since I tend to know what I am talking about, too, I would probably say the same thing, so why bother talking, really? It's like the joke tellers' convention where people sit around and they don't even have to tell a joke. They just say the joke number and everybody laughs. It would be great to be able to work with all these guys, but we are business competitors. I think we could do incredible stuff together. Maybe the Martians will invade and we will have to do a Manhattan project in computers. We would all be shipped to New Mexico. Who knows?"

• ".. A patent was rarely given, so most inventors applied for an author's certificate. The Soviet government owned the intellectual property that the author's certificate documented, so the certificate was merely an acknowledgement of the inventor's contribution. Ironically, it is the simple, direct format of the author certificate that facilitated Altschuller's research into the inventive process ... During the formulation of TRIZ, Altshuller and colleagues reviewed tens of thousands of author's certificates and patents.
  
  In 1946, Altshuller decided that he must create a new science for the theory of invention ... author certificates ... included a cover sheet, a one-page sketch and a short invention description. This simple format made it easy to identify underlying patterns of the inventive process ... Altshuller identified patterns frequently used in the more innovative patents.
  
  ... These patterns identified in the development of a design contain two major components: regularities in design evolution, and principles used in innovative solutions. Altshuller's observations led to an additional breakthrough; since the evolution of engineering design was a process governed by definable laws, it could be taught ... a revolution in the field of inventive problem solving had begun.
  
  ... Altshuller and his boyhood friend, Raphael Shapiro ... in a 1948 letter to Stalin ... criticized the inventive process used throughout the nation and offered some measures to improve the methodology. Their proposed improvements were an embroyonic form of TRIZ. Unfortunately, their patriotism and valuable ideas were not rewarded. Altshuller and Shapiro were charged with "inventing with the purpose to do harm to the country." After a year of interrogation and torture, they were sentenced to 25 years in a prison camp above the Arctic Circle.
  
  What would have been a hellish existence for most people became a time of significant intellectual growth and productivity for Altshuller. The prison camp contained dozens of professors, eminent scientists, musicians, and artists, all of whom were jailed during Stalin's great Purges. As a result, Altschuller's education continued. Because fellow prisoners were happy to have someone who was eager to learn and listen for hours, the prison camp became Altshuller's private university. The worst punishment for Altshuller was the prohibition on writing. A prisoner could be beaten cruelly and placed in a cell if he were found in possession of a notebook. Despite this considerable obstacle, Altshuller continued to develop the science of innovation.
  
  Stalin died in 1953, and Altshuller and Shapiro were released one year later ... publishing their first article on principles of their theory in a 1956 issue of a scientific magazine ... Under the pseudonymn Altov, Altshuller wrote science fiction stories to earn his living. But here again he found an application for TRIZ in the creation of many of the ideas for his futuristic devices and creatures.
  
  ... During the 1970s, translations of Altshuller's books and articles circulated in Germany and Poland, eventually reaching Japan, the U.S.A. and other Western countries ... Only two of Altshuller's books have been translated into English ... key findings are explained in these books, which reflect his study of over 200,000 patents, focusing on 40,000 identified as containined the most innovative design solutions.
  
  Traditional problem solving builds on past experiences ... What if we have never encountered a problem analagous to the one we face? This obvious question reveals the shortcomings of our standard approach to inventive problems. A table of conflicts (Contradiction Table, Appendix D) between 39 design parameters (Table 1) answers this question of how we can face an unfamiliar conflict by offering 1201 generic problems that were solved using at least one of 40 generic principles (Appendix C and Table 2).

• elementary school using TRIZ
• weapons technology, Kowalick
• Cringely on Kowalick updating TRIZ for GM and NASA
• more refs

Could it be that the real reason Simonyi wants away from Microsoft is that he's interested in aspect-oriented programming? And the language that's getting the buzz in aspect-oriented programming is AspectJ, where J stands for Java? And promoting Java would be a career-limiting move at Microsoft for anyone these days?

Instead of the Times article, look at this one in the Washington Post which gets a little closer to this interpretation.

Java by itself is an OOP that doesn't suck as much as it could (it's better than Satan^H^H^H^H^HC++, and is palatable to managers in the same way Smalltalk isn't).

Add AspectJ, and you're really cooking! What do you get? Custom profiling and tracing/logging support. Method dispatch re-writing (yes I know this is the cure, not the disease, which is policy or contract enforcement), mixins, inheritence hierarchy re-writing...

Of course, you could look at Erlang instead. It's a neat functional language that solves multi-threading, communication, event handling, and other issues that you long for when switching from an imperative language. I'm still trying to make this one fly with my bosses...

Another interesting development in programming language features is Aspect or Multidimensional language support. The idea is that not all programming concerns are compositional or hiearchical in nature as Object Oriented Programming requires. Some Software concerns crosscut many objects. The traditional example is logging designs. The 'concern' logging 'crosscuts' the entire object base. Please take a look at AspectJ for information on a java Aspect Engine.

Believe it or not, something similar has actually cropped up in AspectJ:

before (): executions (void foo ()) || executions (void goo ()) {
System.out.println ("I just came from foo() or goo()");
if (blah) throw new RuntimeException
("You can't do foo or goo if blah is true!");
// else continue
}

What I mean by 'round-trip' is that it should be possible to parse the language, make some complex transformation, and spit code back out without loosing a lot of information. This in general is impossible in C and C++ because macros operate at a higher level than the core language, and because a single line of source code in a header file can mean different things depending on the context in which it's included.

The second big advancement is an extension of the OO model called Aspect Oriented programming. There have been a number of studies in the area, and many of them show impressive gains in performance, or reduction in code size. The goal of AO programming is seperating loosely connected tasks that normally have to be interleaved by the programmer, and automating the process, which is called weaving. This is normally done by allowing "after-the-fact" additions to code using glob style operators. For example, it's possible to add interfaces to a class without modifying it's source code, or by 'wrapping' functions or groups of functions in before-after style blocks. Take a look at AspectJ, which is a backwards compatible extension to Java.

And that's where Aspect Oriented programming such as Aspect J will come in. Aspect oriented programming most likely is a big enough leap forward for developers to accept it whenever it goes mainstream. There are some definite clear cut advantages that aspect oriented programming has over OO. But It's late and I don't feel like listing any of them. Visit the site if you haven't already.

--------------------------------------