"We need to be realistic in recognizing that we're stuck with a set of languages and environments that are not susceptible to a massive change." This is a huge cop-out. Buffer overflows simply can not happen in Java. The same goes for almost all of the security problems that are turned into exploits these days. Instead of applying patches to compilers and yelling at ignorant developers, how about just switching to a development language and runtime environment (e.g. Java and its Virtual Machine) that simply doesn't allow these kinds of mistakes to be made?
The Evolution "Connector" isn't exactly what it sounds like. It doesn't talk directly to the Exchange server; it simply acts as a web client talking to Outlook Web Access. I used it from 11/01 to 9/03 and it barely improved at all during this time. When a new message arrives, the Inbox folder view shows that there are new messages, but they don't show up until you manually refresh the view with the "Send/Receive" button. There are various other annoying problems, but not quite enough to make me stop using it (until 9/03 when I left the company for one that doesn't use an Exchange server (thank God.)) Anyway, here's hoping that opening up the source will help iron out these wrinkles, but going through OWA is still a pretty kludgey solution to the problem no matter what.
One of the more interesting uses of AOP I've heard of was to intercept an Exception, and generate a JUnit test case that recreates the point in the code and the user input that generated the exception.
"Just-in-time (JIT) compilers are essentially fast traditional compilers that translate the Java technology bytecodes into native machine code on the fly. A JIT running on the end user's machine actually executes the bytecodes and compiles each method the first time it is executed... [Hotspot] solves the problems of JIT compilation by taking advantage of an interesting program property. Virtually all programs spend the vast majority of their time executing a minority of their code. Rather than compiling method by method, just in time, the Java HotSpot VM immediately runs the program using an interpreter, and analyzes the code as it runs to detect the critical hot spots in the program. Then it focuses the attention of a global native-code optimizer on the hot spots. By avoiding compilation of infrequently executed code (most of the program), the Java HotSpot compiler can devote more attention to the performance-critical parts of the program, without necessarily increasing the overall compilation time. This hot spot monitoring is continued dynamically as the program runs, so that it literally adapts its performance on the fly to the user's needs."
Once again,/. proves how immeasurably ignorant it is of unbad grammar (very ironic.)
Re:JDO vs EJB Entity Beans?
on
Java Data Objects
·
· Score: 3, Informative
I did a pretty extensive evaluation of both. Turned out the 2 technologies were very similar, as long as you use XDoclet with CMP Entity Beans. JDO's biggest advantage over CMP is built-in support for polymorphism and inheritance. CMP Entity Beans' biggest advantage over JDO is Container Managed Relationships. The code base for both sets of code was basically the same. JDO doesn't have declarative transactions, but I was able to simulate this using an Aspect. We ended up going with EJB, largely because it was more mature, and more good, open-source implementations existed (e.g. JBoss). There isn't even a full open-source JDO implementation yet.
We are going live with the first release of this system on Friday, and the CMP Entity Beans are working like a champ. I'm really sick of people complaining about how terrible Entity Beans are. Everyone who does is either using a crappy implementation or doesn't understand how to use them right. There is nothing "tighter" about JDO.
"...a Spanish-based team using two space-based satellites."
This apparently yielded much better results than the Polish-based team who used two ground-based satellites.
We use Canoo WebTest, which is a very nice extension to HTTPUnit. We used to use Cruise Control for automated builds, but replaced it with Gump from Apache Jakarta as it seems to do a better job. We have been having a lot of trouble, however, trying to get the Canoo web tests integrated as part of the automated Gump builds, as it is very difficult to get all of our servers to shut down reliably every time the tests are done.
Slashdot Mirror
"We need to be realistic in recognizing that we're stuck with a set of languages and environments that are not susceptible to a massive change."
This is a huge cop-out. Buffer overflows simply can not happen in Java. The same goes for almost all of the security problems that are turned into exploits these days. Instead of applying patches to compilers and yelling at ignorant developers, how about just switching to a development language and runtime environment (e.g. Java and its Virtual Machine) that simply doesn't allow these kinds of mistakes to be made?
The Evolution "Connector" isn't exactly what it sounds like. It doesn't talk directly to the Exchange server; it simply acts as a web client talking to Outlook Web Access. I used it from 11/01 to 9/03 and it barely improved at all during this time. When a new message arrives, the Inbox folder view shows that there are new messages, but they don't show up until you manually refresh the view with the "Send/Receive" button. There are various other annoying problems, but not quite enough to make me stop using it (until 9/03 when I left the company for one that doesn't use an Exchange server (thank God.)) Anyway, here's hoping that opening up the source will help iron out these wrinkles, but going through OWA is still a pretty kludgey solution to the problem no matter what.
One of the more interesting uses of AOP I've heard of was to intercept an Exception, and generate a JUnit test case that recreates the point in the code and the user input that generated the exception.
Log4j is all you need.
From
The Java HotSpot Virtual Machine:
"Just-in-time (JIT) compilers are essentially fast traditional compilers that translate the Java technology bytecodes into native machine code on the fly. A JIT running on the end user's machine actually executes the bytecodes and compiles each method the first time it is executed...
[Hotspot] solves the problems of JIT compilation by taking advantage of an interesting program property. Virtually all programs spend the vast majority of their time executing a minority of their code. Rather than compiling method by method, just in time, the Java HotSpot VM immediately runs the program using an interpreter, and analyzes the code as it runs to detect the critical hot spots in the program. Then it focuses the attention of a global native-code optimizer on the hot spots. By avoiding compilation of infrequently executed code (most of the program), the Java HotSpot compiler can devote more attention to the performance-critical parts of the program, without necessarily increasing the overall compilation time. This hot spot monitoring is continued dynamically as the program runs, so that it literally adapts its performance on the fly to the user's needs."
"They only test a highly specific case of small numeric loops that is pretty much the best-case scenario for a JIT compiler."
I think you mean for a Hotspot compiler.
Yes it does, although not directly. Evolution's filters integrate nicely with Spam Assassin.
Once again, /. proves how immeasurably ignorant it is of unbad grammar (very ironic.)
I did a pretty extensive evaluation of both. Turned out the 2 technologies were very similar, as long as you use XDoclet with CMP Entity Beans. JDO's biggest advantage over CMP is built-in support for polymorphism and inheritance. CMP Entity Beans' biggest advantage over JDO is Container Managed Relationships. The code base for both sets of code was basically the same. JDO doesn't have declarative transactions, but I was able to simulate this using an Aspect. We ended up going with EJB, largely because it was more mature, and more good, open-source implementations existed (e.g. JBoss). There isn't even a full open-source JDO implementation yet.
We are going live with the first release of this system on Friday, and the CMP Entity Beans are working like a champ. I'm really sick of people complaining about how terrible Entity Beans are. Everyone who does is either using a crappy implementation or doesn't understand how to use them right. There is nothing "tighter" about JDO.
"...a Spanish-based team using two space-based satellites."
This apparently yielded much better results than the Polish-based team who used two ground-based satellites.
What about wine?
We use Canoo WebTest, which is a very nice extension to HTTPUnit. We used to use Cruise Control for automated builds, but replaced it with Gump from Apache Jakarta as it seems to do a better job. We have been having a lot of trouble, however, trying to get the Canoo web tests integrated as part of the automated Gump builds, as it is very difficult to get all of our servers to shut down reliably every time the tests are done.
It is an affectation. Owen is Obi-Wan's brother.