I mean I essentially want a language that has no baggage other than a
new compiler. Scala, Clojure, JRuby, Groovy, Fan all fall down on this
point because they drag a (sometimes very large) runtime library with
them. I think java.next needs to compile down to just bytecodes and
have no
First, let me say that I do not think that virtualization has become
commodotized any more than databases have become commodotized.
Although there are free solutions available, companies will always pay
for enterprise capabilities/support. As to wholesale of cloud
computing resources (such as
Hi! We have instrumented cobertura to run under our build process.
It seems to work well, but only really addresses unit tests. We have
packaged our unit tests with the production code in the standard maven
layout of:
production code - {module}/src/main
test code - {module}/src/test
Cobertura
I've never done this myself, but you're playing with a small fire.
Basically, the integration tests are designed to use the
already-packaged-artifact. So what you would need is some kind of
cobertura plugin that spoofs the integration tests with an instrumented
version of this artifact (which
On Aug 14, 6:32 am, Ben Schulz ya...@gmx.net wrote:
I like how you begin the paragraph On the contrary as if disagreeing
with anything I said, insinuating I made the statistical fallacy you
are talking about.
You said x + 0 is still x in the end, which I presumed meant: Even if
speeding is
True, I should have said 'use an annotation to trigger the rewriting'.
That's my issue: you can only try out language features that are
concerned with declarations, since that's all you can annotate. It's
like being a sports car designer but insisting you can only work with
an automatic
I would not run integration tests on any instrumented code, because an
integration test is for integrating the app with the environment (app
server, database, fs). I have it as a requirement that the same
artifact in the integration is going live, later on.
The metric for integration tests is
klaasjan wrote:
I would not run integration tests on any instrumented code, because an
integration test is for integrating the app with the environment (app
server, database, fs). I have it as a requirement that the same
artifact in the integration is going live, later on.
The metric for
This economy makes for strange bedfellows..
I couldn't see how JBoss (professional open source JEE rebel ) and
RedHat (old guard Linux) were compatible at first blush, either. In
fact, at first it felt like the angle was the 'rebel' thing more than
the synergistic software..
I think that's the
Hey, I have some lofty goals. I don't know if lombok can get there. I
sure hope so, though.
The sheer amount of 'coin isn't making changes fast enough' sentiment
here and in the rest of the java community is -staggering-. But, apart
from that, if lombok gets some traction and adds a bunch of
I'm not sure how others feel, but I think pretty soon this conversation will
be finished with any kind of technical merit and turn into name-calling and
one-uping. I usually reserve cuddle pictures of kittens (Everyone Loves
Kittens) just for this kind of debate when it hits the Scala mailing
On Aug 14, 2:20 pm, Reinier Zwitserloot reini...@gmail.com wrote:
The sheer amount of 'coin isn't making changes fast enough' sentiment
here and in the rest of the java community is -staggering-. But, apart
from that, if lombok gets some traction and adds a bunch of useful
features, but this
Hypothesis: There is a central body in charge of (possibly amongst
other things) picking on a case-by-case basis types for which java
should add operator support.
Proof that this hypothesis is false:
Surely, BigInteger and BigDecimal have warranted operator support for
many many years. If a
Hello posse (of The Posse)!
I've been lately discussing about exception handling in Java with my
workmates. And I've noticed that there's some uncertainty about
Exceptions and how to use them. Currently we're working on a quite
traditional three-tier Spring+Hibernate web app (using way too
all,
That last email was meant for Reinier and Alex only. I apologize for
whatever harm may have been caused.
iPhone user #fail
Maybe they should make a do you really want to send this to
everyone? annoying popup for folk like me.
Sent from my iPhone
On Aug 14, 2009, at 5:32 PM, Josh
Are aware of the seminal book Effective Java by Joshua Bloch which
devotes an entire chapter to Java exceptions?
/Casper
On 15 Aug., 02:31, Hannu Leinonen hlein...@gmail.com wrote:
Hello posse (of The Posse)!
I've been lately discussing about exception handling in Java with my
workmates.
Sure, working on reading it. For some reason I haven't read the
Exception chapter yet, but I'll take that one next. Thanks for the
suggestion!
Eventhough I think at least some of my workmates have read that book,
still they don't seem to have that clear view about exceptions.
-Hannu
Casper
These days with build farms and build clouds, this is my preferred
approach too.
On Sat, Aug 15, 2009 at 5:35 AM, Fabrizio
Giudicifabrizio.giud...@tidalwave.it wrote:
klaasjan wrote:
I would not run integration tests on any instrumented code, because an
integration test is for integrating
18 matches
Mail list logo
