The curse of constant fields

T

Tom Anderson

Any idea how fast, compared to Sun's?

Not a clue. I read that Jasper, the Apache JSP engine, moved from javac to
JDT and got something like a twofold speedup, but that might be because
they no longer had to launch a separate process for compilation, rather
than the compilation itself being faster. Or it might have been because
the compilation was faster, i don't know.

tom
 
L

Lew

Tom said:
Not a clue. I read that Jasper, the Apache JSP engine, moved from javac
to JDT and got something like a twofold speedup, but that might be
because they no longer had to launch a separate process for compilation,
rather than the compilation itself being faster. Or it might have been
because the compilation was faster, i don't know.

To eliminate differences due to in-process vs. out-of-process compilation, one
could compare JDT to Java 6's internal compilation rather than to javac.
 
T

Tom Anderson

To eliminate differences due to in-process vs. out-of-process
compilation, one could compare JDT to Java 6's internal compilation
rather than to javac.

Or use JDT from the command line. It's a 1 MB download and uses the same
flags as javac. Do let us know what you find out. :)

tom
 
T

Tom Anderson

Tom Anderson said:
news:p[email protected]... [ SNIP ]
By hand? No automated testing of the complete app through its web
interface?

The idea of using automated tests for the web GUI has been bruited,
but in our environment it would be unrealistic.

Interesting. Can i ask why?

The original writers of the app - they converted a mainframe legacy app
over to a J2EE one - never saw fit to write web tests, only a reasonably
comprehensive set of JUnit tests. Also, the pages have been more of a
moving target. Now that there are completely different people adding to,
and fixing, the application, none of whom had a hand in writing it
originally, and there aren't many of us, we have no time to write a
sufficient body of web tests (and there would have to be hundreds).

Aah, i see. Fair enough. I had the idea you meant technical reasons, but
organisational reasons are just as good!
They'd be nice to have...nobody denies that. We were also left with no
documentation...what saves us is the fact that we're surrounded by
people who know what the app is supposed to do in the business sense,
since it's not like the rules for motor vehicles changed all that much
in the transition from legacy to J2EE. But web tests would help document
those business rules, and also assist maintenance programmers who have a
hard time reproducing errors in what is quite a complex front-end.

Having had to put some thought into my replies, I'm getting more convinced
that we really need to have a good set of web tests. Our human testers are
fantastic, but it takes many weeks to completely regression test the
application. The JUnit tests miss most of the business logic, quite frankly,
since that is linked into the interplay of JSF managed beans and session
beans. The fact that all of our thousands of JUnit tests pass has to be held
up alongside the fact that there are hundreds of listed defects.

So code coverage linked with a good set of *web* tests is, I believe,
the way to go for a J2EE app. The JUnit tests are still necessary, but
by themselves they don't help much.

My company has been working on maintaining a large ecommerce site for a
few years - since long before i joined. When we inherited it, it had no
tests. The approach taken was to follow the traditional XP rule that you
can't work on something unless you have a test to tell you if you've
broken it, and a test to tell you when you've completed your task. In
other words, incrementally building a test suite as work was done on the
code. Since the initial contract was for some large-scale redesign of the
site, this led to fairly wide coverage.

Something similar might perhaps work for you. Initially, it will involve a
lot of overhead, but once you have a critical mass of tests built,
building more is greatly aided by reuse of code from existing tests - all
the boilerplate of logging in, going through the typical workflows,
validating key pages, etc. It never becomes trivial (i spent half a day
yesterday writing one test), but it can become fairly effortless.

tom
 
A

Arne Vajhøj

Lew said:
To eliminate differences due to in-process vs. out-of-process
compilation, one could compare JDT to Java 6's internal compilation
rather than to javac.

I would have expected also th eold Tomcat to use in-process
compilation unless the JSP servlet init param fork was set to
true.

Implementation must have been using the undocumented compiler
in tools.jar.

Arne
 
A

Arne Vajhøj

Mike said:
Can you explain that situation further? Multiple source files for the
same class sounds like a serious problems to me.

Weird things happens !

Let us say that one set of copies are mockups for the
other set.

Arne
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top