why does catching errors that aren't thrown give syntax errors?

yawnmoth

unread,

Feb 15, 2009, 9:29:56 PM2/15/09

to

public class Test01
{
public static void main() {
try {} catch (java.io.IOException e) {}
}
}

When I run that, I get the following:

Test01.java:4: exception java.io.IOException is never thrown in body
of corresponding try statement
try {} catch (java.io.IOException e) {}
^
1 error

My question is... why? Giving a syntax error over this seems about
as appropriate as giving a syntax error for "if (false)". In both
cases, although it may not serve a lot of point in a finished product,
it may be useful for debugging. If I comment out a line that may
(conditionally) throw java.io.IOException, it's annoying having to
comment out a whole slew of other lines, as well. Same thing for "if
(false)". That's easier than commenting out the whole if statement
(especially if there aren't any else's present).

Arne Vajhøj

unread,

Feb 15, 2009, 9:35:28 PM2/15/09

to

The Java language was designed that way.

http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.20

<quote>
It is a compile-time error if a catch clause catches checked exception
type E1 but there exists no checked exception type E2 such that all of
the following hold:

* E2 <: E1
* The try block corresponding to the catch clause can throw E2
* No preceding catch block of the immediately enclosing try
statement catches E2 or a supertype of E2.

unless E1 is the class Exception.
</quote>

The reasons is most likely to avoid not needed catch statement in
final code.

And yes it can be irritating during development.

But apparently the final code has gotten priority over nuisances
for the developer.

And I agree with that.

Arne

Joshua Cranmer

unread,

Feb 15, 2009, 10:09:53 PM2/15/09

to

yawnmoth wrote:
> My question is... why? Giving a syntax error over this seems about
> as appropriate as giving a syntax error for "if (false)".

Well, |if (false)| is not a compile-time error.

In any case, the short answer is that catching a non-thrown exception is
a syntax error as prescribed by the JLS. But you're probably wondering
why it is a syntax error.

I can't claim to know what the Java developers were thinking, but I'm
going to guess:

Most forms of unreachable code are forbidden, probably with the intent
of easing development by getting rid of code that appears to be called
but is, in fact, never called. |if (false)| is specifically allowed on
the pretext that debug-specific code would be run via an if-block like
|if (Util.DEBUG)|, where Util.DEBUG is a static boolean variable.

Catching non-thrown exceptions is probably an example of where the
developers made a mistake, in hindsight.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Patricia Shanahan

unread,

Feb 15, 2009, 10:38:45 PM2/15/09

to

Arne Vajhřj wrote:
> yawnmoth wrote:
>> public class Test01
>> {
>> public static void main() {
>> try {} catch (java.io.IOException e) {}
>> }
>> }
>>
>> When I run that, I get the following:
>>
>> Test01.java:4: exception java.io.IOException is never thrown in body
>> of corresponding try statement
>> try {} catch (java.io.IOException e) {}
>> ^
>> 1 error
>>
>> My question is... why? Giving a syntax error over this seems about
>> as appropriate as giving a syntax error for "if (false)". In both
>> cases, although it may not serve a lot of point in a finished product,
>> it may be useful for debugging. If I comment out a line that may
>> (conditionally) throw java.io.IOException, it's annoying having to
>> comment out a whole slew of other lines, as well. Same thing for "if
>> (false)". That's easier than commenting out the whole if statement
>> (especially if there aren't any else's present).
>
> The Java language was designed that way.

...

> The reasons is most likely to avoid not needed catch statement in
> final code.
>
> And yes it can be irritating during development.
>
> But apparently the final code has gotten priority over nuisances
> for the developer.
>
> And I agree with that.

I don't know the actual reason, but that one does not justify the
choice. The compiler could handle an unreachable catch block in either
of two ways, leave it in or optimize it out. Both are simple and
straightforward.

In general, Java seems to me to have an inconsistent attitude to
unreachable code. It allows "if(false)" but prohibits sticking in an
early return, leaving unreachable code after it, as well as prohibiting
unreachable catch blocks.

Patricia

Mike Schilling

unread,

Feb 15, 2009, 10:48:35 PM2/15/09

to

Patricia Shanahan wrote:
>
> I don't know the actual reason, but that one does not justify the
> choice. The compiler could handle an unreachable catch block in
> either
> of two ways, leave it in or optimize it out. Both are simple and
> straightforward.
>
> In general, Java seems to me to have an inconsistent attitude to
> unreachable code. It allows "if(false)" but prohibits sticking in an
> early return, leaving unreachable code after it, as well as
> prohibiting unreachable catch blocks.

This is explained in the JLS. As a general rule Java forbids
unreachable code. It makes the single exception of "if (false)",
specifically to allow the inclusion of code which can be turned on for
debugging.

Arne Vajhøj

unread,

Feb 15, 2009, 10:52:13 PM2/15/09

to

Yes.

But the code does not make sense from a production code perspective.

To me it is a very good reason to give error on code that does
not make sense - even though it would be easy to generate code
for it.

> In general, Java seems to me to have an inconsistent attitude to
> unreachable code. It allows "if(false)" but prohibits sticking in an
> early return, leaving unreachable code after it, as well as prohibiting
> unreachable catch blocks.

I agree that is inconsistent.

Arne

Patricia Shanahan

unread,

Feb 15, 2009, 11:20:46 PM2/15/09

to

Unfortunately, if(false) is not a good general solution to the temporary
code exclusion problem, because the code it excludes has to be a
compilable statement (including a block statement).

Commenting could be much more general, allowing exclusion of
uncompilable code and code that does not form a block, but leads to the
problem under discussion.

Patricia

Mike Schilling

unread,

Feb 15, 2009, 11:45:22 PM2/15/09

to

Patricia Shanahan wrote:
> Mike Schilling wrote:
>> Patricia Shanahan wrote:
>>> I don't know the actual reason, but that one does not justify the
>>> choice. The compiler could handle an unreachable catch block in
>>> either
>>> of two ways, leave it in or optimize it out. Both are simple and
>>> straightforward.
>>>
>>> In general, Java seems to me to have an inconsistent attitude to
>>> unreachable code. It allows "if(false)" but prohibits sticking in
>>> an
>>> early return, leaving unreachable code after it, as well as
>>> prohibiting unreachable catch blocks.
>>
>> This is explained in the JLS. As a general rule Java forbids
>> unreachable code. It makes the single exception of "if (false)",
>> specifically to allow the inclusion of code which can be turned on
>> for debugging.
>>
>>
>
> Unfortunately, if(false) is not a good general solution to the
> temporary code exclusion problem, because the code it excludes has
> to
> be a compilable statement (including a block statement).

It's still possible to comment out code, but that has the problem that
when you remove the comments, it's quite possible that the code no
longer compiles (or never did.) I find the fact that the syntax is
checked but no bytecode is generated to be a useful feature.

blue indigo

unread,

Feb 16, 2009, 7:48:55 AM2/16/09

to

On Sun, 5647 Sep 1993 19:09:53 -0800, Joshua Cranmer wrote:

> yawnmoth wrote:
>> My question is... why? Giving a syntax error over this seems about
>> as appropriate as giving a syntax error for "if (false)".
>
> Well, |if (false)| is not a compile-time error.

What about wrapping the line that throws the exception in if (false)
instead of commenting it out?

If the catch clause is still an error in that case, then it really is
quite perverse.

--
blue indigo
UA Telecom since 1987

Bent C Dalager

unread,

Feb 16, 2009, 9:45:26 AM2/16/09

to

As I recall, allowing if(false) is more or less an intended idiom to
act as a poor man's #ifdef. That is, you can write
public final static boolean DEBUG = false;
in some central place and then have
if(DEBUG) { /* lots of debug reporting */ }
all over the place that won't make it into the bytecode so long as
DEBUG is false (saving space & cycles).

Or perhaps that is more an evolved consequence of allowing if(false)
then the original intention behind it, that I don't know.

Catching non-thrown exceptions, however, is regarded as just being
sloppy (or more likely confused) and so disallowed since we don't
really want to have software written by sloppy or confused programmers
out there.

Cheers,
Bent D
--
Bent Dalager - b...@pvv.org - http://www.pvv.org/~bcd
powered by emacs

Lew

unread,

Feb 16, 2009, 10:48:02 AM2/16/09

to

On Feb 15, 10:38 pm, Patricia Shanahan <p...@acm.org> wrote:

'if ( false )' was an intentional deviation to allow conditional
compilation, and is explained as such in the JLS:
> This approach would be consistent with the treatment of other control structures.
> However, in order to allow the if statement to be used conveniently for
> "conditional compilation" purposes, the actual rules differ.

It isn't fair to use it as a model for other control structures. They
acknowledge that it's different, they explain why it's different, they
intended it to be different. Complaining then that it's different is
silly.

--
Lew

Lew

unread,

Feb 16, 2009, 10:49:08 AM2/16/09

to

On Feb 15, 9:29 pm, yawnmoth <terra1...@yahoo.com> wrote:
> public class Test01
> {
> public static void main() {
> try {} catch (java.io.IOException e) {}
> }
>
> }
>
> When I run that, I get the following:
>
> Test01.java:4: exception java.io.IOException is never thrown in body
> of corresponding try statement
> try {} catch (java.io.IOException e) {}
> ^
> 1 error
>
> My question is... why?

Because the JLS says so.

--
Lew

Tom Anderson

unread,

Feb 16, 2009, 3:58:28 PM2/16/09

to

On Sun, 15 Feb 2009, yawnmoth wrote:

> public class Test01
> {
> public static void main() {
> try {} catch (java.io.IOException e) {}
> }
> }
>
> When I run that, I get the following:
>
> Test01.java:4: exception java.io.IOException is never thrown in body
> of corresponding try statement
> try {} catch (java.io.IOException e) {}
> ^
> 1 error
>
> My question is... why? Giving a syntax error over this seems about
> as appropriate as giving a syntax error for "if (false)".

As others have said, it's because java won't let you write unreachable
code. The risk would be in cases like:

class FileAccessException extends Exception // *not* an IOException

public void foo() throws FileAccessException { ... }

try {
foo();
}
catch (IOException e) {
// the programmer thinks he'll deal with FileAccessException here,
// but he won't, and that's the kind of thing that leads to bugs
}

Of course, the compiler would still insist on FileAccessException being
handled here, but that's could still get dropped one way or another, once
the programmer's got it in his head that he's dealing with it in that
block.

> In both cases, although it may not serve a lot of point in a finished
> product, it may be useful for debugging. If I comment out a line that
> may (conditionally) throw java.io.IOException, it's annoying having to
> comment out a whole slew of other lines, as well. Same thing for "if
> (false)". That's easier than commenting out the whole if statement
> (especially if there aren't any else's present).

Yes, it's a pain, isn't it. I've been annoyed by this in the past too.
Could you get aikido on java and do something like:

try {
// otherwise empty block
if (false) throw new IOException();
}
catch (IOException e) {
// your catch code here
}

?

tom

--
solvilvitur ambulando. copy a diamond shape, recording angel. .. ..

Thomas Pornin

unread,

Feb 16, 2009, 5:31:37 PM2/16/09

to

According to Tom Anderson <tw...@urchin.earth.li>:

> As others have said, it's because java won't let you write unreachable
> code.

Note, though, that this particular check is performed by the compiler
only, whereas the prohibition of "dead code" is generally enforced by
the JVM during bytecode verification(*).

The analysis which the JVM performs considers that every conditional
jump can be taken or not taken, independantly of all other conditional
jumps. For instance, if an "if (false)" was compiled into bytecode, it
would become a conditional jump, actually always (or never) taken, but
the JVM bytecode verifier, applying the JVM specification, would not
consider the conditional code as unreachable. Similarly, whenever some
code is covered by an exception handler (a line in the exception table),
then the handler is reputed reachable by the JVM.

The Java _compiler_ applies slightly different semantics. It takes care
not to generate code that the JVM would reject as unreachable, but it
also enforces additional rules. In particular, the Java compiler has a
notion of "checked exceptions" (all classes which extend Exception but
not RuntimeException), for which the compiler will require explicit
handling (either catching, or declaration of throwing). The converse of
a checked exception is that if some code is not known by the compiler to
throw a checked exception, and a catch handler is set for that exception
over that code, then the compiler will reject the attempt. This is
what is observed with this code:

try { } catch (IOException ioe) { }

but observe how this code:

try { } catch (RuntimeException re) { }

is accepted by the compiler. This is because the compiler does not keep
track of unchecked exceptions, and thus considers that any unchecked
exception (any Throwable which does not extend Exception, or any
extension of RuntimeException) may happen just about anywhere in any
piece of code, even empty pieces as above.

Regardless of what the compiler thinks about exceptions, the JVM will
happily accept all of these because transgressions of the "checked
exceptions" rules do not impact the safety of the sandbox model that the
JVM implements.

And anyway you can fool the compiler, like this:

public class Thrower {

public Thrower()
throws Exception
{
throw new IOException();
}
}

public class Example {

public void throwHiddenIOException()
{
try {
Thrower.class.newInstance();
} catch (IllegalAccessException iae) {
} catch (InstantiationException ie) {
}
}
}

Here, when you call Example.throwHiddenIOException(), you get a nice,
shiny IOException thrown by a method which notably lacks any kind of
"throws IOException" clause...

All this amounts to my main point: the handling of checked exceptions is
quite disjoint to the notion of "unreachable code" which is what the JVM
enforces, and which is what prevents the use of an early return. The
special handling of "if (false)" by the compiler is yet a _third_
distinct notion.

--Thomas Pornin

(*) In the rt.jar distributed with JDK-1.4.2, there is a class called
java.text.CharSet, which includes a method named "doUnion()". The code
for that method contains an unreachable opcode (at offset 87 within that
method). This means that Sun's tools (the compiler or the code rebuilder
used for compact redistribution) may generate in some situations a dead
opcode, and that Sun's JVM, as distributed with JDK-1.4.2, is able to be
quite lenient on that subject.

Tom Anderson

unread,

Feb 16, 2009, 7:22:53 PM2/16/09

to

On Mon, 16 Feb 2009, Thomas Pornin wrote:

> According to Tom Anderson <tw...@urchin.earth.li>:
>> As others have said, it's because java won't let you write unreachable
>> code.
>
> Note, though, that this particular check is performed by the compiler
> only, whereas the prohibition of "dead code" is generally enforced by
> the JVM during bytecode verification(*).

[snip]

That is some very interesting stuff - thanks! I had no idea that the
validator was concerned with dead code - are you saying that it
can/should/must reject bytecode with unreachable instructions?

tom

--
Well, I'm making a list too. But I'm also preparing appropriate
retribution. -- Graham

unread,

Feb 16, 2009, 8:24:37 PM2/16/09

to

On Mon, 5643 Sep 1993 07:49:08 -0800, Lew wrote:

> On Feb 15, 9:29 pm, yawnmoth <terra1...@yahoo.com> wrote:
>> Test01.java:4: exception java.io.IOException is never thrown in body
>> of corresponding try statement
>>

>> My question is... why?
>
> Because the JLS says so.

The quality of your replies seems to me to be highly variable. Sometimes
really useful and informative. Sometimes just a spelling flame or an
apparently-irrelevant rant about top-posting or multi-posting with no
content actually related to the question being asked. Sometimes feeding
the trolls. And sometimes, like now, simply begging the question.

unread,

Feb 17, 2009, 8:15:30 AM2/17/09

to

According to blue indigo <blue....@uatel.com.nospam.bogus.invalid.invalid.invalid>:

Yes, although a bit indirectly. A JIT compiler translates the bytecode
(which works on a stack-based abstract machine) into instructions
suitable for the actual processor. The first job in that translation
process is to compute the stack depth and types of stack elements for
each opcode, so that the stack abstraction can be converted into local
variables and registers. That operation is a big part of what the
verifier does, and the safety of the JVM is based upon the idea that the
type analyzer does not get it wrong at that point, so that generated
binary opcode for the host CPU need not perform runtime checks. For
unreachable opcodes, this type analysis cannot be performed, hence such
opcodes cannot be translated at all.

So basically, checking that there is no dead code means that the JIT
compiler can safely translate the opcodes since the type information
needed by the JIT compiler is available for all opcodes.

Alternatively, dead code could be tolerated by the JIT compiler by
having an additional per-opcode flag which would be set only for
reachable opcodes; the JIT compiler would have to test that flag, and
would simply omit unreachable opcodes, which would be just dead weight
in the class file. Apparently, Sun's JVM works that way.

--Thomas Pornin

Thomas Pornin

unread,

Feb 17, 2009, 9:20:24 AM2/17/09

to

According to Tom Anderson <tw...@urchin.earth.li>:

> are you saying that it can/should/must reject bytecode with
> unreachable instructions?

It certainly can -- an important part of the verifier is to statically
compute the stack depth and the types of the stack elements and local
variables for each opcode; this is done by a dataflow analysis which
basically retraces all possible paths which reach each opcode.

Any kind of JIT compiler must necessarily do something about dead
opcodes: since type information is not available for such opcodes, they
cannot be translated to machine instructions. The JIT compiler must
either reject the bytecode or explicitely skip dead opcodes. Only the
most basic intepretation model may avoid thinking about dead opcodes
and just let them sit where they are.

The JVM specification is quite unclear about the fine details of
bytecode verification, but it still states that the verifier must
compute the stack depth for each opcode; since such a depth is not
defined for unreachable opcodes, it cannot be computed, and thus,
arguably, the verifier must reject code which contains dead opcodes.

Things change a bit with classfile format 50.0 (the one which Java 6
tools generate and use by default). A new code attribute is defined,
called StackMapTable. This attribute contains type information for
various points in the program. When the StackMapTable attribute is
present, the verifier job is much easier, since it no longer has to
infer types through a dataflow analysis as explained above; instead, it
just needs to _verify_ that the given type information is compatible
with what the opcodes imply. This allows a one-pass verification
process.

Originally, that attribute was defined for J2ME, on the basis that
reduced JVM for mobile phones had to run on low-power devices and thus
needed a more streamlined verification process. The StackMapTable
attribute and the deprecation of the "jsr" opcode allowed for such an
optimized verification. Sun adopted it for plain J2SE, beginning with
version 6.0. The JVM may still perform the dataflow analysis with type
inference, but only when the StackMapTable attribute is absent or the
simplified verification process failed, with some restrictions. This is
meant to support older classfiles, and tools which modify classfiles
without recomputing the StackMapTable attribute.

The bottom-line is that the simplified verification process does not
detect dead opcodes, so dead opcodes will be silently accepted, but only
if the StackMapTable attribute grants them some type information which
is then bogus, by definition. Apparently, the new JVM specification
(from JSR 202) specifies acceptance by the predicates which the type
checker enforces, so bogus but harmless type information would be
accepted, thus making dead code "legally valid". However, the necessity
to produce the new StackMapTable attribute implies that the base
compiler (javac or equivalent) must perform a dataflow analysis, and
thus should itself detect dead code right away.

--Thomas Pornin

Thomas Pornin

unread,

Feb 17, 2009, 9:43:00 AM2/17/09

to

According to Mark Space <mark...@sbc.global.net>:

> Unfortunately the /* */ failed if one tried to comment out a comment.
> So one used #if 0 or similar (#ifdef null). The if(false) construct is
> probably a stylistic hold-over from the early C days.

It is actually the other way round. The early C days had the
preprocessor, and the first compilers were notoriously quite unable to
perform optimisations such as removing a block of code conditioned out
with "if (0)". The "#if 0" method was the canonical way to suppress a
bunch of code from compilation in early C days (a '/* */' would not do
the trick in full generality, since such comments do not nest).

In somewhat later years (say early 1990s), the "Plan9" operating system
development was initiated at Bell Labs, and the team included some major
C contributors, including Kernighan and Ritchie themselves. Ritchie, who
designed the preprocessor in the first place, began advocating that
"if (0)" was a superior technique, because it allowed the performance
gain (now that compilers have enough available RAM and CPU to optimize
away such blocks) while keeping the code under compiler scrutiny, thus
ensuring that commented code does not rot during development.

So the "#if 0" is from early C days, while "if (0)" is the new, reformed
way. Apparently, Sun chose to follow Ritchie's ideas in that matter.

--Thomas Pornin

Lew

unread,

Feb 17, 2009, 11:04:31 AM2/17/09

to

yawnmoth wrote:
>> Test01.java:4: exception java.io.IOException is never thrown in body
>> of corresponding try statement
>> My question is... why?

Lew wrote:
> Because the JLS says so.

blue indigo wrote:

>>> The quality of your replies seems to me to be highly variable. Sometimes
>>> really useful and informative. Sometimes just a spelling flame or an
>>> apparently-irrelevant rant about top-posting or multi-posting with no
>>> content actually related to the question being asked. Sometimes feeding
>>> the trolls. And sometimes, like now, simply begging the question.
>

Lew wrote:
>> Thank you for your /ad hominem/ remarks.
>

blue indigo wrote:
> It was intended as constructive criticism. As, I believe, are some of the
> posts you make that I characterized as spelling flames and similarly, but
> which maybe could be improved upon, for example by never neglecting the
> core point of the preceding post and sometimes by recognizing a lost cause
> (such as attempts to educate spammers and trolls).
>
> Perhaps you don't agree.
>
> Carry on, then.

It seems that in your eagerness to criticize me personally (and, I
notice, not the others who gave the same answer with somewhat more
detail) that you completely ignored the point I made. At least you
use the term "begging the question" correctly. However, I was not
begging the question. I was giving the only actual, valid answer to
the question.

A number of people have offered reasons why the rule *could* have been
made. Others offered reasons why the rule *shouldn't* have been
made. However, without recourse to the reasoning behing the rule, and
I don't see Java's authors responding in this thread yet, no one has
answered the OP's question as to why the rule *was* made.

For some reason, Java engenders more armchair language design than any
other computer language I've used. No one seems to ask, "Why does
Perl have such opaque syntax?" Instead, they argue religiously that
it's far superior by dint of that very opacity. Java is the only
language that receives criticism from its adherents rather than blind
devotion. This is a good thing, and one of its strengths. But
ultimately, the reason why one has to do what one has to do in any
computer language is that that's how the language is defined. "Why is
it that way?" is not a useful question, and always the trivial answer
is the correct one, "Because that's the definition of the language".

Now, were one to ask, "Should this change?" that would be useful.

So next time, blue indigo, do not rush to judgment but consider why I
gave the answer I did, and incorporate the possibility that the answer
was serious, thoughtful and relevant.

--
Lew

blue indigo

unread,

Feb 18, 2009, 3:33:40 AM2/18/09

to

On Tue, 17 Feb 2009 08:04:31 -0800, Lew wrote:

> blue indigo wrote:
>> It was intended as constructive criticism. As, I believe, are some of the
>> posts you make that I characterized as spelling flames and similarly, but
>> which maybe could be improved upon, for example by never neglecting the
>> core point of the preceding post and sometimes by recognizing a lost cause
>> (such as attempts to educate spammers and trolls).
>>
>> Perhaps you don't agree.
>>
>> Carry on, then.
>
> It seems that in your eagerness to criticize me personally (and, I
> notice, not the others who gave the same answer with somewhat more
> detail) that you completely ignored the point I made.

Ah. I see you noticed that it was the lack of detail that made the
difference.

It should be obvious, and apparently it was obvious to several other
people, that the OP wanted to know the rationale behind forbidding the
unreachable catch. "Because the JLS says so" is not then a satisfying
explanation.

It's reminiscent of the kind of nonsense you tend to get when someone
either doesn't want to admit that they don't know the answer to something,
or is just being arbitrary and authoritarian.

"Why?"

"Because the JLS says so."

"But why does the JLS say so?"
"Because someone at Sun thought it was a good idea."
"But WHY???"

If you've ever had, or taught, or been around a small child, you'll know
that this sort of answer never satisfies.

To see one on usenet is somewhat mystifying though. Most of the usual
reasons for such non-answers don't apply. You didn't decide this, so
you're not just putting your foot down and saying "Because I said so ...
JUST BECAUSE!"; maybe you don't know and would rather not say "I don't
know", but you can easily remain silent on usenet and your silence will
probably go unnoticed (whereas your non-answer definitely did not).

> I was giving the only actual, valid answer to the question.

The OP wants to know the reason for something. Because some document says
so is not a real reason; it's just an expression of a decision that
somebody made, the reasoning behind which remains unexplained by your
"answer".

Some of the explanation of the reasoning, in this case, is apparently
described in the text of the JLS, but your post made no reference to this
fact, so I discount it here.

> Java is the only language that receives criticism from its adherents
> rather than blind devotion.

I find this surprising, if true. My expectation would be that any
programming language in widespread practical use is going to be the
subject of debates, criticism, and discussion among its practitioners.
Abnd that there will be some subset that treat it as an object of
religious veneration and are purists and change-resisters, too.

Certainly I've seen web sites asserting that Java is a religion to some
people. It's unsurprising that perl is to others. Probably the only one
that isn't is COBOL. :-)

> "Why is it that way?" is not a useful question

I disagree.

It may not be useful in day-to-day coding, but it is certainly useful when
you take the longer view in which there is a give-and-take between the
user community and the developers. Java, in particular, has a
participatory community process and its bug tracker accepts feature
requests and has an explicit "this is a feature request, not a bug report"
option in it, so in the longer view in which one seeks to influence the
evolution of the language one certainly has use for information about the
reasoning behind various design choices.

On the one hand, knowledge of the reasoning behind a choice might lead one
to decide that one agrees with that reasoning. That might forestall
opposition to something that seems quirky but turns out to have good
reasons behind it. Absent such an explanation, the community process might
make a short-sighted mistake by overturning a rule that turned out to be
more beneficial than it seemed at first blush.

On the other, perhaps the choice was truly arbitrary, or the reasoning
behind it contains an error, in which case it may be wise to revisit it
down the road. It may not -- some arbitrary choices are pointless to
change. For example, which side of the road you drive on in a country. The
choices are basically symmetrical at the outset, so the decision might as
well be made by a flip of the coin, or to be consistent with neighboring
countries, or whatever. Afterward though there's a huge cost and no
benefit to switching, whichever way it was originally set. The choice of
side is an assumption buried in the infrastructure, everywhere there's a
turn lane or a signal light, and lots of other places besides. Businesses
spring up downstream of highway offramps -- gas stations, fast food joints
-- that would suddenly be upstream of an onramp instead after such a
change. Similarly there may be decisions in Java's design that are
similarly arbitrary but not worth revisiting.

And there may be some that are worth revisiting.

Knowing which are which and having an informed debate could be useful for
the future evolution of the language. Stifling such knowledge and
preventing informed debate, out of a misguided belief that it's useless or
that there can be no such knowledge, certainly cannot be useful.

> and always the trivial answer is the correct one, "Because
> that's the definition of the language".

Trivial-and-correct answers are frequently also nearly useless.

> Now, were one to ask, "Should this change?" that would be useful.

I'm glad you realize that. But part of answering "should this change?"
tends to involve answering "why is it this way to begin with?"; if one
does not learn from history one is doomed to repeat it.

> So next time, blue indigo, do not rush to judgment

I don't think I did. I have well-thought-out reasons for nearly everything
I say, as I hope I have now demonstrated.

> but consider why I gave the answer I did, and incorporate the
> possibility that the answer was serious, thoughtful and relevant.

Consider the context. Here we have the OP asking why something is the way
it is in Java, several cogent and detailed responses detailing a
rationale, and then one post from you that amounts to "just because". You
can understand why that does not look particularly serious, thoughtful, or
relevant. Indeed, since others had mentioned that the JLS specified the
behavior in question, it looks more redundant than relevant or much of
anything else.

blue indigo

unread,

Feb 18, 2009, 3:41:38 AM2/18/09

to

On Tue, 17 Feb 2009 14:43:00 +0000, Thomas Pornin wrote:

> The "#if 0" method was the canonical way to suppress a
> bunch of code from compilation in early C days (a '/* */' would not do
> the trick in full generality, since such comments do not nest).

That must rank up there on the "all-time top 100 boneheaded decisions"
list. "Such comments do not nest," that is. They even have a distinct left
and right delimiter, so it would have been trivial to make them nest
appropriately, and doing so would have made it very easy to comment out
large blocks of code containing pre-existing comments. Yet they did not,
probably out of sheer laziness.

// comments were introduced to C++ (and later backported to C) partly to
address this, only to run into their own problems:

- You can now use /* */ to easily comment out a lot of code containing
only // comments.
- You can now use // to comment out a lot of code containing arbitrary types
of comments.
- But it takes a lot more typing to insert "// " at the start of each of
1000 lines than to insert "/*<RET>" at the top and "*/<RET>" at the bottom.

Better would have been to require /* */ comments to nest properly in C++,
and eventually backport THAT to C. It wouldn't have even broken anything,
since */ is not legal outside of a comment, so changing the parsing rules
for comments in the appropriate manner wouldn't have caused valid code to
suddenly become comments in pre-existing compilable code.

Java would have benefited too, since it inherited the C++ system of
commenting syntax.

blue indigo

unread,

Feb 18, 2009, 3:47:14 AM2/18/09

to

On Tue, 17 Feb 2009 13:15:30 +0000, Thomas Pornin wrote:

> According to blue indigo <blue....@uatel.com.nospam.bogus>:

>> On Mon, 5643 Sep 1993 22:31:37 +0000, Thomas Pornin wrote:
>> [snip]
>>
>> > Regardless of what the compiler thinks about exceptions, the JVM will
>> > happily accept all of these because transgressions of the "checked
>> > exceptions" rules do not impact the safety of the sandbox model that the
>> > JVM implements.
>>
>> And transgressions of the "dead code" rules do? How?
>

> Yes, although a bit indirectly. [snip lots of details]

It sounds like it does not actually create a risk of crashes or hacking.
Sure, the dead code can't be verified not to do something bad. Except that
since it's never executed, it will never get the chance.

It also complicates JIT design -- slightly. The obvious thing is for dead
code to not be compiled at all, as an optimization, and it sounds like
this is already the case with Sun's Hotspot JIT.

Frankly, I don't see what the big deal is here.

It seems a bit like worrying about letting elm trees within city limits
because they might potentially harbor Dutch elm disease, which would be
horrible if it somehow afflicted people, despite the fact that it's not
actually transmissible to humans. Or something like that.

Bent C Dalager

unread,

Feb 18, 2009, 5:56:08 AM2/18/09

to

On 2009-02-18, blue indigo <blue....@uatel.com.nospam.bogus.invalid.invalid.invalid> wrote:
>
> Better would have been to require /* */ comments to nest properly in C++,
> and eventually backport THAT to C. It wouldn't have even broken anything,
> since */ is not legal outside of a comment, so changing the parsing rules
> for comments in the appropriate manner wouldn't have caused valid code to
> suddenly become comments in pre-existing compilable code.

/*/*char* txt1 = "*/char* txt2="*/";

blue indigo

unread,

Feb 18, 2009, 7:18:48 AM2/18/09

to

On Wed, 5650 Sep 1993 10:56:08 +0000, Bent C Dalager wrote:

> On 2009-02-18, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>>
>> Better would have been to require /* */ comments to nest properly in C++,
>> and eventually backport THAT to C. It wouldn't have even broken anything,
>> since */ is not legal outside of a comment, so changing the parsing rules
>> for comments in the appropriate manner wouldn't have caused valid code to
>> suddenly become comments in pre-existing compilable code.
>
> /*/*char* txt1 = "*/char* txt2="*/";

Yes, of course it would have to take quotation marks into account as
well as /* and */.

I thought that went without saying, sorry mate.

The corner case you point out ought to be rare in practise. How common is
it for string literals containing C source to occur in C source? Outside
of quines and IOCCC submissions, anyway.

Bent C Dalager

unread,

Feb 18, 2009, 7:47:14 AM2/18/09

to

On 2009-02-18, blue indigo <blue....@uatel.com.nospam.bogus.invalid.invalid.invalid> wrote:

> On Wed, 5650 Sep 1993 10:56:08 +0000, Bent C Dalager wrote:
>
>> On 2009-02-18, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>>>
>>> Better would have been to require /* */ comments to nest properly in C++,
>>> and eventually backport THAT to C. It wouldn't have even broken anything,
>>> since */ is not legal outside of a comment, so changing the parsing rules
>>> for comments in the appropriate manner wouldn't have caused valid code to
>>> suddenly become comments in pre-existing compilable code.
>>
>> /*/*char* txt1 = "*/char* txt2="*/";
>
> Yes, of course it would have to take quotation marks into account as
> well as /* and */.

This then becomes a considerably more complex change than what you
outline above and one that is sure to meet with, shall we say,
spirited debate in the larger C community.

> The corner case you point out ought to be rare in practise. How common is
> it for string literals containing C source to occur in C source? Outside
> of quines and IOCCC submissions, anyway.

That is really of no interest whatsoever. All that needs to be
demonstrated is that there can exist code that will break after the
change and such a demonstration, however eccentric, is sufficient to
disprove the claim that the change can safely be introduced with no
further ado. As a minor point, I also don't think the situation is
quite as rare as you make out(*).

As we have now seen, such a change can only be made after very careful
consideration and thorough discussion in the programmer community.

Cheers,
Bent D

*) C code in string literals is not necessary, it was a consequence of
my example being based on the notion of the programmer commenting out
parts of his code to try an alternative. The same problem would
manifest itself with e.g.
/* these are the operators supported
/* by our calculator */
char* operators = "+-*/=";

Message has been deleted

Wojtek

unread,

Feb 18, 2009, 9:21:55 AM2/18/09

to

blue indigo wrote :

> - But it takes a lot more typing to insert "// " at the start of each of
> 1000 lines than to insert "/*<RET>" at the top and "*/<RET>" at the bottom.

Select, CTRL-/

At least in most modern IDEs. Heck, even the Visual Basic editor from
1999 has this.

--
Wojtek :-)

Patricia Shanahan

unread,

Feb 18, 2009, 10:24:12 AM2/18/09

to

Lew wrote:
...

> For some reason, Java engenders more armchair language design than any
> other computer language I've used. No one seems to ask, "Why does
> Perl have such opaque syntax?" Instead, they argue religiously that
> it's far superior by dint of that very opacity. Java is the only
> language that receives criticism from its adherents rather than blind
> devotion. This is a good thing, and one of its strengths. But
> ultimately, the reason why one has to do what one has to do in any
> computer language is that that's how the language is defined. "Why is
> it that way?" is not a useful question, and always the trivial answer
> is the correct one, "Because that's the definition of the language".

...

How do you define "useful" for a question? One of my main objectives is
improvement in my understanding and thinking about computing. From that
point a view, a question that helps me think about something, or causes
people to post ideas I had not previously considered, is extremely
useful. This newsgroup would be a lot less useful to me if all the
posters accepted "because the JLS says so" as a final answer to any
question that can be answered that way.

Patricia

Roedy Green

unread,

Feb 18, 2009, 10:47:30 AM2/18/09

to

On Sun, 15 Feb 2009 18:29:56 -0800 (PST), yawnmoth
<terr...@yahoo.com> wrote, quoted or indirectly quoted someone who
said :

>
>Test01.java:4: exception java.io.IOException is never thrown in body
>of corresponding try statement

> try {} catch (java.io.IOException e) {}

I too find that annoying. I would like to build a catch, especially
into in interface for an exception I MIGHT want some day.

However, if you use an IDE like IntelliJ Idea, it fairly easy to add
them later. This keep the code simpler.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"By 2040, the Sahara will be moving into Europe, and Berlin
will be as hot as Baghdad. Atlanta will end up a kudzu
jungle. Phoenix will become uninhabitable, as will parts of
Beijing (desert), Miami (rising seas) and London (floods).
Food shortages will drive millions of people north, raising
political tensions."
~ James Lovelock
Lovelock is more pessimistic than the consensus, because he thinks man will
refuse to take significant action to ameliorate global warming.

Daniel Pitts

unread,

Feb 18, 2009, 1:51:41 PM2/18/09

to

It could have broken a lot, actually. I often used mismatched starting
comments on purpose while testing:

I'm willing to bet that such code has made it into production systems.
Changing the meaning of "/* /* */" would break that code, sometimes
without any warning.

doSomething();
// I can easily toggle doSomethingElse and doSomeOtherThing() call by
// adding a */ at the end of the following line
/*
doSomethingElse();
doSomeOtherThing(); /**/
doSomeFinalThing(); // */

Before the change, doSomethingElse, and doSomeOtherThing are ignored,
but if you added nesting, doSomeFinalThing would also be ignored,
without any notice from the compiler.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Arne Vajhøj

unread,

Feb 18, 2009, 9:24:17 PM2/18/09

to

Roedy Green wrote:
> On Sun, 15 Feb 2009 18:29:56 -0800 (PST), yawnmoth
> <terr...@yahoo.com> wrote, quoted or indirectly quoted someone who
> said :
>> Test01.java:4: exception java.io.IOException is never thrown in body
>> of corresponding try statement
>> try {} catch (java.io.IOException e) {}
>
> I too find that annoying. I would like to build a catch, especially
> into in interface for an exception I MIGHT want some day.

Classes do not have to throw all exceptions declared in their
interface.

Arne

Arne Vajhøj

unread,

Feb 18, 2009, 9:29:26 PM2/18/09

to

Changes that impact existing code are generally frowned at no matter
if it is 10%, 0.1% or 0.001% of existing program that will be
impacted.

Arne

Arne Vajhøj

unread,

Feb 18, 2009, 9:40:22 PM2/18/09

to

blue indigo wrote:
> On Tue, 17 Feb 2009 14:43:00 +0000, Thomas Pornin wrote:
>> The "#if 0" method was the canonical way to suppress a
>> bunch of code from compilation in early C days (a '/* */' would not do
>> the trick in full generality, since such comments do not nest).
>
> That must rank up there on the "all-time top 100 boneheaded decisions"
> list. "Such comments do not nest," that is. They even have a distinct left
> and right delimiter, so it would have been trivial to make them nest
> appropriately, and doing so would have made it very easy to comment out
> large blocks of code containing pre-existing comments. Yet they did not,
> probably out of sheer laziness.

It would have meant a fundamental change compared to C. C compatibility
was obviously a goal.

> Better would have been to require /* */ comments to nest properly in C++,
> and eventually backport THAT to C. It wouldn't have even broken anything,
> since */ is not legal outside of a comment,

It is valid with / as start of a comment.

a = a */* multiply with 2 */ 2;

is valid C.

Arne

Mike Schilling

unread,

Feb 18, 2009, 9:41:04 PM2/18/09

to

For obvious reasons.

interface Storage
{
void store(byte[] data) throws IOException;
...
}

class NullDevice implements Storage
{
public void store(byte[] data)
{
return;
}
}

Lew

unread,

Feb 18, 2009, 11:42:46 PM2/18/09

to

Arne Vajhøj wrote:
> Changes that impact existing code are generally frowned at no matter
> if it is 10%, 0.1% or 0.001% of existing program that will be
> impacted.

I just got bitten by a Java 6 change that broke existing code.

We have a bunch of things that rely on a library that has classes that
implement java.sql.Statement.
<http://java.sun.com/javase/6/docs/api/java/sql/Statement.html>

The library is compliant with Java 5. We compile it from source. The
interface has methods that were added in Java 6, so the code doesn't compile
under Java 6.

--
Lew

Steve Wampler

unread,

Feb 19, 2009, 9:20:33 AM2/19/09

to

Lew wrote:
> Arne Vajhøj wrote:
>> Changes that impact existing code are generally frowned at no matter
>> if it is 10%, 0.1% or 0.001% of existing program that will be
>> impacted.
>
> I just got bitten by a Java 6 change that broke existing code.

And I've got code where Integer.parseInt(s) is now throwing a
different exception. The change took place between jdk 1.6.0_10
and jdk 1.6.0_12. My suspicion is that something that was broken
has now been fixed - and the code was written based on the broken
behavior.

--
Steve Wampler -- swam...@noao.edu
The gods that smiled on your birth are now laughing out loud.

blue indigo

unread,

Feb 19, 2009, 11:59:59 AM2/19/09

to

On Wed, 5650 Sep 1993 12:47:14 +0000, Bent C Dalager wrote:

> On 2009-02-18, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>> On Wed, 5650 Sep 1993 10:56:08 +0000, Bent C Dalager wrote:
>>
>>> On 2009-02-18, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>>>>
>>>> Better would have been to require /* */ comments to nest properly in C++,
>>>> and eventually backport THAT to C. It wouldn't have even broken anything,
>>>> since */ is not legal outside of a comment, so changing the parsing rules
>>>> for comments in the appropriate manner wouldn't have caused valid code to
>>>> suddenly become comments in pre-existing compilable code.
>>>
>>> /*/*char* txt1 = "*/char* txt2="*/";
>>
>> Yes, of course it would have to take quotation marks into account as
>> well as /* and */.
>
> This then becomes a considerably more complex change than what you
> outline above and one that is sure to meet with, shall we say,
> spirited debate in the larger C community.

So, tracking two sets of delimeters is "considerably more complex" than
tracking one. I did not know that. Thanks.

> That is really of no interest whatsoever. All that needs to be
> demonstrated is that there can exist code that will break after the
> change and such a demonstration, however eccentric, is sufficient to
> disprove the claim that the change can safely be introduced with no
> further ado. As a minor point, I also don't think the situation is
> quite as rare as you make out(*).
>
> As we have now seen, such a change can only be made after very careful
> consideration and thorough discussion in the programmer community.

Considering that I had suggested that C should have done this from the
outset, before there was any C code to break, and failing that that C++
should have (and C++ had numerous other minor differences from C from the
outset, that would break a bit of the existing C codebases if compiled as
C++), and failing that that Java should have, this isn't really all that
important.

> *) C code in string literals is not necessary, it was a consequence of
> my example being based on the notion of the programmer commenting out
> parts of his code to try an alternative. The same problem would
> manifest itself with e.g.
> /* these are the operators supported
> /* by our calculator */
> char* operators = "+-*/=";

Quote-counting fixes this, as I noted in my previous post. This sort of
code is not especially common, either -- and consider that if five symbols
are listed in arbitrary order, the odds that a particular two will happen
to be adjacent and in a particular order are not particularly high.

In fact, consider the permutations of "12345". There are 5! = 720 of
these. Of these, there are 3! = 6 that begin with "12" and permute only
the "345" at the end. All the permutations that keep 1 and 2 together are
ibtained from these permutations by compounding with an additional cyclic
permutation. There are five such cyclic permutations, but one of the five
splits the "12" up as so: "2xxx1". So there are only 6*4=24 permutations
that have "12" as a substring. That is 1/30th of 720. Not really unlikely,
but somewhat bad luck, comparable to rolling snake eyes.

Another permutation of that string is even more interesting in light of
this debate, though: "+-/*=". (And 23 of its friends.) The C preprocessor
or javac _already_ needs to count quotation marks in order to avoid the /*
internal to that string literal acting as a comment start, using the
_present_ comment parsing rules.

Daniel Pitts had a different sort of corner-case, not involving string
literals:

> doSomething();
> // I can easily toggle doSomethingElse and doSomeOtherThing() call by
> // adding a */ at the end of the following line
> /*
> doSomethingElse();
> doSomeOtherThing(); /**/
> doSomeFinalThing(); // */

I consider that kind of fiddly stuff to be an antipattern. #if(DEBUG) is
far, far better, much cleaner and more readable. Moreover, in the specific
case of Java it is not even applicable.

Bent C Dalager

unread,

Feb 19, 2009, 12:54:34 PM2/19/09

to

On 2009-02-19, blue indigo <blue....@uatel.com.nospam.bogus.invalid.invalid.invalid> wrote:
> On Wed, 5650 Sep 1993 12:47:14 +0000, Bent C Dalager wrote:
>
>> On 2009-02-18, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>>> On Wed, 5650 Sep 1993 10:56:08 +0000, Bent C Dalager wrote:
>>>
>>> Yes, of course it would have to take quotation marks into account as
>>> well as /* and */.
>>
>> This then becomes a considerably more complex change than what you
>> outline above and one that is sure to meet with, shall we say,
>> spirited debate in the larger C community.
>
> So, tracking two sets of delimeters is "considerably more complex" than
> tracking one. I did not know that. Thanks.

You're welcome.

>> As we have now seen, such a change can only be made after very careful
>> consideration and thorough discussion in the programmer community.
>
> Considering that I had suggested that C should have done this from the

> outset (...)

I did not comment on that, my comment was directed at the suggestion
that a retroactive change to accomplish this would be unproblematic.

What C ought to have done from the very beginning is a different
debate.

> (...) This sort of

> code is not especially common, either -- and consider that if five symbols
> are listed in arbitrary order, the odds that a particular two will happen
> to be adjacent and in a particular order are not particularly high.
>

> (...)

>
> Daniel Pitts had a different sort of corner-case, not involving string
> literals:
>

> (...)

>
> I consider that kind of fiddly stuff to be an antipattern. #if(DEBUG) is
> far, far better, much cleaner and more readable. Moreover, in the specific
> case of Java it is not even applicable.

If you had made it clear from the start that your suggestion
/actually/ was "if everyone had written C code in some as yet to be
disclosed manner of my own invention then retroactively making this
change would not have been a problem" - we would not be having this
debate.

Cheers,
Bent D

Arne Vajhøj

unread,

Feb 19, 2009, 8:33:02 PM2/19/09

to

It is not quite the same problem.

But it is unfortunately a real problem.

It will happen when interfaces get stuff added.

I guess the official solution is that a JDBC n.m compliant
JDBC driver must be compiled with a Java version at that
JDBC version and just run on the newest Java version.

But that is highly problematic in real world development
environments.

The alternative would be pretty ugly though:
public interface Statement40 extends Statement30
public interface Statement30 extends Statement20
public interface Statement20 extends Statement

Arne

Arne Vajhøj

unread,

> If you had made it clear from the start that your suggestion
> /actually/ was "if everyone had written C code in some as yet to be
> disclosed manner of my own invention then retroactively making this
> change would not have been a problem" - we would not be having this
> debate.

Yet to be disclosed? I thought I'd made it clear exactly how.

Bent C Dalager

unread,

Feb 20, 2009, 4:28:15 AM2/20/09

to

On 2009-02-20, blue indigo <blue....@uatel.com.nospam.bogus.invalid.invalid.invalid> wrote:
>
> Adding // comments was a not dissimilar change that actually did happen.

And notice how the line
int a = 2//**/1;
compiles fine with gcc -std=c89 but not with gcc -std=c++98.

Which, of course, proves my point yet again: this sort of change
requires language revision, it cannot just be blithely added with no
adverse consequences.

>> If you had made it clear from the start that your suggestion
>> /actually/ was "if everyone had written C code in some as yet to be
>> disclosed manner of my own invention then retroactively making this
>> change would not have been a problem" - we would not be having this
>> debate.
>
> Yet to be disclosed? I thought I'd made it clear exactly how.

You had not, but you do appear to be working on it.

Andreas Leitgeb

unread,

Feb 20, 2009, 4:45:44 AM2/20/09

to

Lew <no...@lewscanon.com> wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> I just got bitten by a Java 6 change that broke existing code.
>>> We have a bunch of things that rely on a library that has classes that
>>> implement java.sql.Statement.

>>> The library is compliant with Java 5. We compile it from source. The
>>> interface has methods that were added in Java 6, so the code doesn't
>>> compile under Java 6.

>> It will happen when interfaces get stuff added.
>> I guess the official solution is that a JDBC n.m compliant
>> JDBC driver must be compiled with a Java version at that
>> JDBC version and just run on the newest Java version.

> I'm going to recommend to the appropriate parties on my project that we use
> the JARs for the code and not rebuild it from source.

But then you still cannot *run* it with an 1.6 JRE, unless I'm mistaken.
Or (of course) you could add implementations for the additional stuff.

As it seems from the Javadoc, 1.5 was the only version so far
that has not added to this interface (didn't show up in a "Since:").
Furthermore, enhancing of interfaces seems to be common practise in
the java.sql package (I looked randomly at a few other interfaces).

Tom Anderson

unread,

Feb 20, 2009, 11:23:20 AM2/20/09

to

On Tue, 17 Feb 2009, Thomas Pornin wrote:

> According to Tom Anderson <tw...@urchin.earth.li>:
>
>> are you saying that it can/should/must reject bytecode with
>> unreachable instructions?
>
> It certainly can -- an important part of the verifier is to statically
> compute the stack depth and the types of the stack elements and local
> variables for each opcode; this is done by a dataflow analysis which
> basically retraces all possible paths which reach each opcode.
>
> Any kind of JIT compiler must necessarily do something about dead
> opcodes: since type information is not available for such opcodes, they
> cannot be translated to machine instructions. The JIT compiler must
> either reject the bytecode or explicitely skip dead opcodes. Only the
> most basic intepretation model may avoid thinking about dead opcodes
> and just let them sit where they are.

I don't believe any but the most naive JIT works by going through the
bytecodes in order and translating them one by one. Rather, they work by
building a representation from the bytecode, in something like single
static assignment form, and then compiling that. Building the
representation is done by pseudo-interpretation, walking all the possible
paths as you say above, and thus it never hits dead bytecodes.

However:

> The JVM specification is quite unclear about the fine details of
> bytecode verification, but it still states that the verifier must
> compute the stack depth for each opcode; since such a depth is not
> defined for unreachable opcodes, it cannot be computed, and thus,
> arguably, the verifier must reject code which contains dead opcodes.

That's an excellent point. I suppose a JVM writer might choose not to do
this, because the stack layout at an unreachable bytecode is irrelevant -
for instance, they might fold stack depth computation into building a
compilable representation as i describe above, in which case unreachable
bytecodes will never have a stack depth, but also won't be added to the
set of things which need compiling - but by the letter of the law, they
should be rejected.

tom

--
A hypothesis or theory is clear, decisive, and positive, but it is
believed by no one but the man who created it. Experimental findings,
on the other hand, are messy, inexact things, which are believed by
everyone except the man who did that work. -- Harlow Shapley

blue indigo

unread,

Feb 20, 2009, 11:25:09 AM2/20/09

to

On Fri, 5652 Sep 1993 09:28:15 +0000, Bent C Dalager wrote:

> On 2009-02-20, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>>
>> Adding // comments was a not dissimilar change that actually did happen.
>
> And notice how the line
> int a = 2//**/1;
> compiles fine with gcc -std=c89 but not with gcc -std=c++98.
>
> Which, of course, proves my point yet again: this sort of change
> requires language revision, it cannot just be blithely added with no
> adverse consequences.

I didn't say it could. I said it might nonetheless be a good choice, if
the adverse consequences are relatively minor and the benefits substantial.

>>> If you had made it clear from the start that your suggestion
>>> /actually/ was "if everyone had written C code in some as yet to be
>>> disclosed manner of my own invention then retroactively making this
>>> change would not have been a problem" - we would not be having this
>>> debate.
>>
>> Yet to be disclosed? I thought I'd made it clear exactly how.
>
> You had not

Sure I had. The change is almost trivial: keep a count of how many /* have
been seen, decrease by one when */ is seen, toggle a boolean when " is
seen, and when the inside-quotes flag is set, don't count /* or */.

It might need further tweaking (character constants can contain multiple
characters I think, so single-quotes may also need to be tracked, for
instance). But it's nothing like as vague a notion as you seem to have
suggested I had.

Tom Anderson

unread,

Feb 20, 2009, 11:33:21 AM2/20/09

to

On Thu, 19 Feb 2009, Arne Vajh?j wrote:

> Lew wrote:

You could imagine having language support for versioned interfaces, so
something like:

import java.sql.Statement;
public class LewsStatement implements Statement # 1.5 {
}

Or:

import java.sql.Statement # 1.5;
public class LewsStatement implements Statement {
}

Then elsewhere:

import java.sql.Statement # 1.4;
public class DatabaseProcessor {
public void Process(Statement stmt) ;
}

And as long as your class implements a version of Statement that's 1.4 or
later, it's a valid parameter. This is essentially syntactic sugar for
your 'ugly' code. It would require backward compatibility for subsequent
versions of an interface. I don't know for sure that this idea works -
we'd need a computer scientists to prove it, really.

Another option might be to have an abstract base class for implementing
the interface, which has concrete stubs for all the methods (which are
either no-op, delegate to other methods where possible, or throw
UnsupportedOperationException), so that as long as you extend that, you
conform to the interface even as it changes, because when the interface is
expanded, so is the base class. This isn't great, though, because the new
methods just have the base class implementations, and so will probably
fail in exciting and unhelpful ways at runtime. Plus, it constrains your
choice of base class.

Arne Vajhøj

unread,

Feb 20, 2009, 9:15:27 PM2/20/09

to

Id it is external code that you can get as a binary dist (jar), then
that is of course fine.

My remark about problematic only applies when it is your
own code.

Arne

Arne Vajhøj

unread,

Feb 20, 2009, 9:17:08 PM2/20/09

to

Andreas Leitgeb wrote:
> Lew <no...@lewscanon.com> wrote:
>> Arne Vajhøj wrote:
>>> Lew wrote:
>>>> I just got bitten by a Java 6 change that broke existing code.
>>>> We have a bunch of things that rely on a library that has classes that
>>>> implement java.sql.Statement.
>>>> The library is compliant with Java 5. We compile it from source. The
>>>> interface has methods that were added in Java 6, so the code doesn't
>>>> compile under Java 6.
>>> It will happen when interfaces get stuff added.
>>> I guess the official solution is that a JDBC n.m compliant
>>> JDBC driver must be compiled with a Java version at that
>>> JDBC version and just run on the newest Java version.
>> I'm going to recommend to the appropriate parties on my project that we use
>> the JARs for the code and not rebuild it from source.
>
> But then you still cannot *run* it with an 1.6 JRE, unless I'm mistaken.

Sure he can.

He are not using any of the new methods.

If he were the code would not be compiling with the old Java version.

> As it seems from the Javadoc, 1.5 was the only version so far
> that has not added to this interface (didn't show up in a "Since:").
> Furthermore, enhancing of interfaces seems to be common practise in
> the java.sql package (I looked randomly at a few other interfaces).

It happen all the time.

But most people use binaries (jars) from JDBC drivers instead
of building themselves.

Arne

Arne Vajhøj

unread,

Feb 20, 2009, 9:20:57 PM2/20/09

to

True.

But somehow I like a version feature in the language better than version
hacks.

The problem is well known in SOA context.

(I would still prefer JDBC version instead of Java version,
but that is besides the point)

> It would require backward compatibility for
> subsequent versions of an interface.

That is a benefit not a restriction !

> I don't know for sure that this
> idea works - we'd need a computer scientists to prove it, really.

:-)

Arne

Arne Vajhøj

unread,

Feb 20, 2009, 10:32:20 PM2/20/09

to

There are already posted examples where counting " and ' will not help.

Arne

Mike Schilling

unread,

Feb 20, 2009, 10:41:55 PM2/20/09

to

It's already the case that // and /* inside a literal string don't
start comments (nor does */ inside a literal string end them.) It's
also the case that " or ' inside a comment don't delimit literal
strings. I'm not convinced that making /* ... */ nest makes the
situation significantly more complicated.

Arne Vajhøj

unread,

Feb 20, 2009, 10:44:33 PM2/20/09

to

True.

But there are other problems.

Arne

Mike Schilling

unread,

Feb 20, 2009, 10:55:50 PM2/20/09

to

The fact that JDK 1.6 added methods to the interface
java.sql.Statement makes me curious about the general case of two
mismatched classes (or, in this case, a mismatched class and
interface.)

Say that at development time I have the class A:

class A implements Iface
{
public static void main(String[] args)
{
Iface i = new A();
i.doit();
}
public void doit()
{
}
}

interface Iface
{
void doit();
}

Clearly, this will compile and run just fine (mod any typos, anyway.)

Now, say that I modify Iface thus:

interface Iface
{
void doit();
int doit2();
}

Now I run the old A.class with the new Iface.class. We all know what
will happen: it will still run fine. When the JVM loads A, it won't
check that it implements all of the Iface methods, and since the only
Iface method called is one that A does implement, all is well. If
something tried to call Iface.doit2() on an A, there would be a
NoSuchMethod error thrown.

My question is whether this behavior is guaranteed and, if so, where
it's defined. Would a JVM be entitled to throw an error at

Iface i = new A();

on the grounds that A doesn't really implement Iface? More generally,
many odd things can happen when class definitions change between
compile time and run time. Is the JVM's behavior for all of them
well-defined?

Mike Schilling

unread,

Feb 20, 2009, 10:56:35 PM2/20/09

to

Compatibility, of course. What else?

Arne Vajhøj

unread,

Feb 20, 2009, 11:03:04 PM2/20/09

to

You will have to dig through JLS and JVM spec to get an
authoritative statement.

But given:

1) it would add huge overhead to verify all methods

2) it would break lot of code

3) http://java.sun.com/javase/6/docs/api/java/lang/NoSuchMethodError.html
wording

then I would not be particular worried.

Arne

Arne Vajhøj

unread,

Feb 20, 2009, 11:03:58 PM2/20/09

to

All the above is about compatibility.

But the comment example is probably not the best example
of a compatibility problem.

I think my example is better.

:-)

Arne

Patricia Shanahan

unread,

Feb 20, 2009, 11:21:32 PM2/20/09

to

Mike Schilling wrote:
...

> Now, say that I modify Iface thus:
>
> interface Iface
> {
> void doit();
> int doit2();
> }
>
> Now I run the old A.class with the new Iface.class. We all know what
> will happen: it will still run fine. When the JVM loads A, it won't
> check that it implements all of the Iface methods, and since the only
> Iface method called is one that A does implement, all is well. If
> something tried to call Iface.doit2() on an A, there would be a
> NoSuchMethod error thrown.
>
> My question is whether this behavior is guaranteed and, if so, where
> it's defined. Would a JVM be entitled to throw an error at
>
> Iface i = new A();
>
> on the grounds that A doesn't really implement Iface? More generally,
> many odd things can happen when class definitions change between
> compile time and run time. Is the JVM's behavior for all of them
> well-defined?

At the Java language level, this is covered in the JLS,
http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.5.3,
"Adding a method to an interface does not break compatibility with
pre-existing binaries.".

More generally, section 13, "Binary Compatibility",
http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html,
discusses the effects on existing binaries of various forms of changes.

Patricia

Mike Schilling

unread,

Feb 20, 2009, 11:21:36 PM2/20/09

to

I'm not worried; I'm something much worse: curious :-)

Bent C Dalager

unread,

Feb 22, 2009, 7:13:05 AM2/22/09

to

On 2009-02-20, blue indigo <blue....@uatel.com.nospam.bogus.invalid.invalid.invalid> wrote:

> On Fri, 5652 Sep 1993 09:28:15 +0000, Bent C Dalager wrote:
>
>> On 2009-02-20, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>>>
>>> Adding // comments was a not dissimilar change that actually did happen.
>>
>> And notice how the line
>> int a = 2//**/1;
>> compiles fine with gcc -std=c89 but not with gcc -std=c++98.
>>
>> Which, of course, proves my point yet again: this sort of change
>> requires language revision, it cannot just be blithely added with no
>> adverse consequences.
>
> I didn't say it could.

What, then, /did/ you mean when you wrote

"Better would have been to require /* */ comments to nest properly in C++,
and eventually backport THAT to C. It wouldn't have even broken anything,
since */ is not legal outside of a comment, so changing the parsing rules
for comments in the appropriate manner wouldn't have caused valid code to
suddenly become comments in pre-existing compilable code."

It is quite clear that you made an erroneous statement and now you're
backpedaling like mad rather than do the decent thing and admit that
you were wrong.

Hopefully we have managed to keep this delusion from spreading too far
and wide and with the above revelation that you don't even realize
what you yourself wrote, further damage control may not be necessary.

blue indigo

unread,

Feb 22, 2009, 2:17:19 PM2/22/09

to

On Sun, 5654 Sep 1993 12:13:05 +0000, Bent C Dalager wrote:

> On 2009-02-20, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>> On Fri, 5652 Sep 1993 09:28:15 +0000, Bent C Dalager wrote:
>>
>>> On 2009-02-20, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>>>>
>>>> Adding // comments was a not dissimilar change that actually did happen.
>>>
>>> And notice how the line
>>> int a = 2//**/1;
>>> compiles fine with gcc -std=c89 but not with gcc -std=c++98.
>>>
>>> Which, of course, proves my point yet again: this sort of change
>>> requires language revision, it cannot just be blithely added with no
>>> adverse consequences.
>>
>> I didn't say it could.
>
> What, then, /did/ you mean

I meant exactly what I said, mate. Assuming string and character
constants, and maybe one or two other things, are handled correctly, the
only code it would break would be code that was exploiting the non-nesting
of comments to do something "sneaky" like togglable compilation that is
better done using #if and friends.

I don't consider the need to rewrite such code to necessarily be "adverse
consequences". Perhaps you do.

If so, we shall simply have to agree to disagree.

Regardless, I don't think making that change even now would be 1/10 as
horrible as you seem to be making it out to be.

P.S. I don't like your tone in your latest few messages, particularly this
last one. It seems an awful lot like browbeating to me. Are you purposely
trying to pick a fight? A quick look around this newsgroup fails to reveal
any recent posts by you that aren't similar to these ones. I form a
suspicion that perhaps you are a troll.

Bent C Dalager

unread,

Feb 22, 2009, 3:49:06 PM2/22/09

to

On 2009-02-22, blue indigo <blue....@uatel.com.nospam.bogus.invalid.invalid.invalid> wrote:
> On Sun, 5654 Sep 1993 12:13:05 +0000, Bent C Dalager wrote:
>
>> On 2009-02-20, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>>> On Fri, 5652 Sep 1993 09:28:15 +0000, Bent C Dalager wrote:
>>>
>>>> Which, of course, proves my point yet again: this sort of change
>>>> requires language revision, it cannot just be blithely added with no
>>>> adverse consequences.
>>>
>>> I didn't say it could.
>>
>> What, then, /did/ you mean
>
> I meant exactly what I said, mate.

This is not reconcilable with the fact that you wrote "It wouldn't
have even broken anything", which it obviously would have.

> Assuming string and character
> constants, and maybe one or two other things, are handled correctly, the
> only code it would break would be code that was exploiting the non-nesting
> of comments to do something "sneaky" like togglable compilation that is
> better done using #if and friends.

I can certainly accept that what you /meant/ to say may have been "in
those cases where it doesn't actually break anything, it wouldn't even
break anything" which is where you are going here.

> I don't consider the need to rewrite such code to necessarily be "adverse
> consequences". Perhaps you do.

Rewriting thousands or even millions of lines of code throughout
thousands of different software packages, yeah, I consider that
adverse consequences. Perhaps you do not :-)

> Regardless, I don't think making that change even now would be 1/10 as
> horrible as you seem to be making it out to be.

Anything that breaks anything in C is generally considered horrible.

> P.S. I don't like your tone in your latest few messages, particularly this
> last one. It seems an awful lot like browbeating to me. Are you purposely
> trying to pick a fight? A quick look around this newsgroup fails to reveal
> any recent posts by you that aren't similar to these ones. I form a
> suspicion that perhaps you are a troll.

Recently I have largely limited myself to promptly correcting
egregious errors when I see them, in the hope that I catch them before
someone is tricked into wasting hours of their life finding out that
they are, indeed, errors.

Of course, some people take being corrected better than others. I
occassionally find myself forced to repeatedly explain why the error
is an error in order to achieve my objective. I do, however, much
prefer to just point it out once and then move on, as evidenced by my
first post to this particular thread which consisted of one single
line demonstrating your mistake.

Arne Vajhøj

unread,

Feb 22, 2009, 8:13:16 PM2/22/09

to

blue indigo wrote:
> On Sun, 5654 Sep 1993 12:13:05 +0000, Bent C Dalager wrote:
>> On 2009-02-20, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>>> On Fri, 5652 Sep 1993 09:28:15 +0000, Bent C Dalager wrote:
>>>> On 2009-02-20, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>>>>> Adding // comments was a not dissimilar change that actually did happen.
>>>> And notice how the line
>>>> int a = 2//**/1;
>>>> compiles fine with gcc -std=c89 but not with gcc -std=c++98.
>>>>
>>>> Which, of course, proves my point yet again: this sort of change
>>>> requires language revision, it cannot just be blithely added with no
>>>> adverse consequences.
>>> I didn't say it could.
>> What, then, /did/ you mean
>
> I meant exactly what I said, mate. Assuming string and character
> constants, and maybe one or two other things, are handled correctly, the
> only code it would break would be code that was exploiting the non-nesting
> of comments to do something "sneaky" like togglable compilation that is
> better done using #if and friends.

I gave a very example of a regular comment just placed at
a special location.

> I don't consider the need to rewrite such code to necessarily be "adverse
> consequences". Perhaps you do.
>
> If so, we shall simply have to agree to disagree.
>
> Regardless, I don't think making that change even now would be 1/10 as
> horrible as you seem to be making it out to be.

Breaking existing code is always bad.

There is a project plan, no hours has been allocated to change
anything in some old code, suddenly if gives build errors, nobody
has touched those X million lines of code for years, first thing
is to find someone that has a clue about how the code works, the
project goes directly over in high risk mode.

Arne

Andreas Leitgeb

unread,

Feb 23, 2009, 3:31:22 AM2/23/09

to

Arne Vajhøj <ar...@vajhoej.dk> wrote:
> Andreas Leitgeb wrote:
>> Lew <no...@lewscanon.com> wrote:
>>> I'm going to recommend to the appropriate parties on my project that we use
>>> the JARs for the code and not rebuild it from source.
>> But then you still cannot *run* it with an 1.6 JRE, unless I'm mistaken.
> Sure he can.

Indeed, Mike pointed it out, that compiled code still works.

Anyway, if people develop with JDK1.6, then it's not too unlikely,
that someone may call one of Statement's new methods (on a thusly-typed
reference), and later, at runtime, when they actually have a
MyDerived_1Dot5er_Statement, they'd get runtime errors.

> He are not using any of the new methods.

But the "appropriate parties on his project" may ...
Ok, Lew will also tell them not to do that...
Just the compiler will not prevent them - afterall, they only
compile against java.sql.Statement, not against the specific
subclass in the driver-JAR.

> If he were the code would not be compiling with the old Java version.

But they use the new Java version, (otherwise they wouldn't have
problems recompiling those JARs)

blue indigo

unread,

Feb 23, 2009, 10:29:15 AM2/23/09

to

On Sun, 22 Feb 2009 20:13:16 -0500, Arne Vajhļæ½j wrote:

> blue indigo wrote:
>> On Sun, 5654 Sep 1993 12:13:05 +0000, Bent C Dalager wrote:
>>> What, then, /did/ you mean
>>
>> I meant exactly what I said, mate. Assuming string and character
>> constants, and maybe one or two other things, are handled correctly, the
>> only code it would break would be code that was exploiting the non-nesting
>> of comments to do something "sneaky" like togglable compilation that is
>> better done using #if and friends.
>
> I gave a very example of a regular comment just placed at
> a special location.

You gave an example that was a) contrived and b) broken by the
introduction of C++'s // comments, not by making /* */ comments nest.

In practise, I would not expect code like "int a = 2//**/1;" to arise
outside of deliberate obfuscation or, of course, contrived examples.

>> Regardless, I don't think making that change even now would be 1/10 as
>> horrible as you seem to be making it out to be.
>
> Breaking existing code is always bad.

Breaking existing production code. I hope nothing like "int a = 2//**/1;"
is actually used in production code.

Usually, though, when a project is mission critical everybody sticks with
known-working versions of everything for that project. This is why we have
projects out there that internally use java 1.3 even though java 6 is
current and 7 is around the corner.

Sometimes also, it's a case of no pain, no gain. There must be SOME reason
why they added a method to the javax.sql.Statement interface, as was
lamented in another thread here recently.

The bar to justification for a change like any of these is higher the more
production code is likely to be impacted, and the harder it would be to
fix that code.

In the case of javax.sql.Statement I'd say that bar was quite a lot higher
than in the case of either introducing // comments to C or hypothetically
making /* */ comments nest. I'd say introducing // comments to C has the
lower bar, though, and /* */ nesting would be in between, but still I'd
expect only a few lines of production code out of every million to be
affected, if that much, and that it would be very easy to find the cause
and fix it. C compilers usually have compatibility flags anyway. (So does
javac --- javac -source 1.3 MyClass.java --- for similar reasons, though
this wouldn't help versus the javax.sql.Statement change since that's a
change to a library class rather than a change to the language syntax or
semantics per se.)

> There is a project plan, no hours has been allocated to change anything
> in some old code, suddenly if gives build errors, nobody has touched
> those X million lines of code for years, first thing is to find someone
> that has a clue about how the code works, the project goes directly over
> in high risk mode.

See above.

Even if so, sometimes a project needs a kick in the compacency. Legacy
code with no experts around to maintain it will rot your project
eventually anyway. Maybe having to get someone to fix something will save
even worse trouble down the line, like the next y2k crisis in around
twenty years when the number of seconds since the epoch starts to not fit
in a 32-bit integer. The guy might spot a bunch of "int time"s instead of
"long time"s and fix them proactively, or something.

Lew

unread,

Feb 23, 2009, 10:59:23 AM2/23/09

to

blue indigo wrote:
> ..., like the next y2k crisis in around

> twenty years when the number of seconds since the epoch starts to not fit
> in a 32-bit integer. The guy might spot a bunch of "int time"s instead of
> "long time"s and fix them proactively, or something.

This is not a Java problem, of course.

--
Lew

blue indigo

unread,

Feb 23, 2009, 11:00:32 AM2/23/09

to

On Sun, 5654 Sep 1993 20:49:06 +0000, Bent C Dalager wrote:

> On 2009-02-22, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>> On Sun, 5654 Sep 1993 12:13:05 +0000, Bent C Dalager wrote:
>>
>>> On 2009-02-20, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>>>> I didn't say it could.
>>>
>>> What, then, /did/ you mean
>>
>> I meant exactly what I said, mate.
>
> This is not reconcilable with the fact that you wrote "It wouldn't
> have even broken anything", which it obviously would have.

I meant anything important, if you'll forgive the ellipsis. As I've
already explained, I don't consider contrived example code, intentionally
obfuscated code, or generally really lousy code to be "anything
important". Any sufficiently-lousy code in actual production is better off
replaced or refactored sooner rather than later, and is bound to cause
trouble of some sort eventually regardless, so I say go ahead and force
that code to be addressed now. It may even be a stitch in time that saves
nine. See what I wrote in response to Arne today.

>> Assuming string and character
>> constants, and maybe one or two other things, are handled correctly, the
>> only code it would break would be code that was exploiting the non-nesting
>> of comments to do something "sneaky" like togglable compilation that is
>> better done using #if and friends.
>
> I can certainly accept that what you /meant/ to say may have been "in
> those cases where it doesn't actually break anything, it wouldn't even
> break anything" which is where you are going here.

Don't be ridiculous. I've explained myself above, and several other times.

I think you are arguing now just for the sake of arguing. I plonked you
once long ago for posting dozens of hundreds-of-lines-long posts a week
for at least two months in response to a troll. If you post any more of
this fight-picking and unconstructive jabbering, you're going straight
back into the plonk bucket, express delivery.

>> I don't consider the need to rewrite such code to
>> necessarily be "adverse consequences". Perhaps you do.
>
> Rewriting thousands or even millions of lines of code

Any project that has "thousands or even millions of lines of code"
affected by the proposed comment-nesting change has "thousands or even
millions of lines" of HORRIBLE code and is probably doomed no matter what.

> yeah, I consider that adverse consequences.

Such a project having to be taken out back and shot like a rabid dingo, or
at least having to be mercilessly refactored, would be a blessing, not an
adverse consequence.

In my opinion, of course.

Of course the lazy buggers will surely just keep using their old compiler,
or their new compiler's --compatibility=C99 switch, or most likely their
old compiler's --compatibility=C89 switch, anyway, so this is all moot.

>> Regardless, I don't think making that change even now would be 1/10 as
>> horrible as you seem to be making it out to be.
>
> Anything that breaks anything in C is generally considered horrible.

Anything that fragile against the changes proposed is generally considered
horrible. If there are thousands or more of lines of code affected by the
changes proposed, the whole codebase can safely be declared horrible.

In most other industries, toxic byproducts and obsolete lead-painted
parts and old asbestos-insulated outhouses are steered clear of, not
carefully guarded against harm.

>> P.S. I don't like your tone in your latest few messages, particularly
>> this last one. It seems an awful lot like browbeating to me. Are you
>> purposely trying to pick a fight? A quick look around this newsgroup
>> fails to reveal any recent posts by you that aren't similar to these
>> ones. I form a suspicion that perhaps you are a troll.
>
> Recently I have largely limited myself to promptly correcting egregious
> errors when I see them

Unfortunately, you have numerous false positives.

> in the hope that I catch them before someone is tricked

Forget waiting another post. You dare accuse me of trying to trick people?
I like to think I'm one of the more helpful, on-topic and cogent
participants in this newsgroup. Certainly I seem to be more such than you
are.

Go to hell, "Bent" or whatever your real name is.

_____________ _____________
`-._ ..::| `-._ ..::| .
`. ..::| `. ..::| /|
| ..::| | ..::| /.|
| ..::| _____ | ..::| / :|
.--------.| ..::|.-' ..::-.---. .-----| ..::| / .:|
| /\ .::. ..:.' ..::`. ' | ..::| / .::| /\
|/ \ .::\../ ..::\ | ..::| / ..::|/ \
.---' '---..::bd _ ..::b.._ | ..::|/ ..---' '---.
`-. .-' .::PI (_) ..::m ) | ..::`-. .-'
/ \ ..:/.q ..::w / .| .:' / \
/_.-``-._\..:' ..\ ..::/ / .:| ''---/_.-``-._\
' | ..:.` | ..:`. ..::,' / .::| ..:. `
| ..:| | ..::|`-.__..::-':| / .::' | ..:::|'. ..:\
| ..:J ,' ..:::. ,' ..::/ ..:' ,' ..::::. ) .::b
| ..:/ /____..::::\ /____...:/ .:' /____..:::::/ ..::P
|.:,' /.:' / ..:::'
|,' /.' / ..:-'
' ' /,-'
'

> Of course, some people take being corrected better than others.

It tends to depend at least partially on whether they actually need to be
corrected, as well as on their personality, and on whether this
"correction" takes place in private or public.

> I occassionally find myself forced to

As in, at gunpoint? Wow. I will see if I can reach the police services in
your area to let them know that there's a hostage situation at the
Norwegian University of Science and Technology, presumably in either an
office or a computer lab on campus. Hopefully they will arrive soon and
successfully disarm the gunman, and you will then be free to go about your
life as you were.

Of course, if you're unlucky, you might get shot, but them's the breaks I
suppose. Being held at gunpoint does tend to create that risk I'm afraid.

> I do, however, much prefer to just point it out once and then move on,

when this option is not removed by pesky terrorists wielding assault
rifles that is,

> as evidenced by my first post to this particular thread which consisted
> of one single line demonstrating your mistake.

I made no mistake.

I was not especially detailed; I did take it as granted that some handling
of string literals would be needed, akin to that already performed to
deal with a "/*" or "//" in a string literal. Apparently I needed to make
that explicit after all, for the C-students in the class. (No pun intended.)

Unfortunately, when I did make it explicit, you just came right back
trying to pick another nit instead of just accepting it and moving on.
That, to me, is the indication that you are not actually on any great
quest to enlighten the masses, but rather, just like to pick fights on
usenet. Well, that, and your past posting history which includes quite a
lot of flamebaiting and trollbaiting, to the detriment of this entire
newsgroup at least once before.

To the point that I have to wonder if you yourself are a troll.
Persistently feeding trolls seems to be one way to troll a newsgroup,
after all, and so does being almost-rational but with some sort of "never
quite gets it" syndrome. (Remind you of anyone else locally infamous?)

Regardless, arguing with you any further is pointless. I've stated my
case, apparently our opinions still differ, and that should be the end of
it. Clearly you're not so much seeking to enlighten me or anyone else so
much as you're gunning for a metal dome trophy engraved "Ferrous Cranus of
the Year, 2009".

And, since you offended me greatly with your unfounded and borderline-
libelous accusation of being here to try to trick people and waste hours
of their time, I certainly won't be reading any more of your rubbish.

As I said before, and now reiterate:

_____________ _____________
`-._ ..::| `-._ ..::| .
`. ..::| `. ..::| /|
| ..::| | ..::| /.|
| ..::| _____ | ..::| / :|
.--------.| ..::|.-' ..::-.---. .-----| ..::| / .:|
| /\ .::. ..:.' ..::`. ' | ..::| / .::| /\
|/ \ .::\../ ..::\ | ..::| / ..::|/ \
.---' '---..::bd _ ..::b.._ | ..::|/ ..---' '---.
`-. .-' .::PI (_) ..::m ) | ..::`-. .-'
/ \ ..:/.q ..::w / .| .:' / \
/_.-``-._\..:' ..\ ..::/ / .:| ''---/_.-``-._\
' | ..:.` | ..:`. ..::,' / .::| ..:. `
| ..:| | ..::|`-.__..::-':| / .::' | ..:::|'. ..:\
| ..:J ,' ..:::. ,' ..::/ ..:' ,' ..::::. ) .::b
| ..:/ /____..::::\ /____...:/ .:' /____..:::::/ ..::P
|.:,' /.:' / ..:::'
|,' /.' / ..:-'
' ' /,-'
'

P.S. In polite society, when someone tries to clarify something or save
face, you let them. You do not browbeat them and you do not back them into
a corner and try to trip them up. That is the action of a troll and
flame-baiter, not a civilized man, and it is probably that kind of
behavior that sometimes turns an ordinary man into a vicious flamer or a
troll in his own turn. It's like kicking a dingo until it eventually
turns, snarling, on you, or on others.

Behaving as you have been doing is not the action of a civilized person
attempting to cooperate with others in an endeavor to better understand
and practise a craft. It is the action of someone who sees himself as at
war with everyone around him, and feels the need to beat people and "win"
something. It is, in fact, remarkably Twisted behavior -- capitalization
intentional.

Larry K. Wollensham

unread,

Feb 23, 2009, 11:28:29 AM2/23/09

to

That depends. The standard library classes all use "long"s for this, but
third-party code may exist that uses "int".

In C, on the other hand, you can't even count on "long" being more than
32 bits. Usually it's only 32 bits. The GNU compiler gcc supports a
"long long" that is 64 bits, but it's nonstandard. Each C implementation
should define time_t and similar typedefs appropriately, and in the
structs some of these reference, use appropriate types for the fields.

Whether most modern Unix kernels and tools are compiled nowadays to use
64-bit-wide representations of seconds since the epoch, I wouldn't know.
(These days most of my work is on Windows boxen, which are even more
opaque about their inner workings. I have no idea if for instance NTFS
modification dates will melt down on Tuesday, January 19, 2038.)

(http://www.irbs.net/internet/info-cyrus/0601/0296.html seems to
indicate that there are some growing pains associated with the gcc
toolchain adopting a 64-bit time_t at least when targeting 64-bit
architectures. Once this shakes out, and 32-bit architectures die out, a
large proportion of unixdom should be Y2K38-proof, including all of
Linuxdom. Regardless, it's better to find and fix these things at
leisure now than in a panic in late 2037.)

Jerry Gerrone

unread,

Feb 23, 2009, 12:17:21 PM2/23/09

to

On Feb 23, 11:00 am, blue indigo
<blue.ind...@uatel.com.nospam.bogus.invalid.invalid.invalid> wrote:
[snip]

You again.

I googled for people talking about me and flaming me "behind my back",
found a cljp thread mentioning me that had previously not come up on
my radar, and found this post.

> On Sun, 5654 Sep 1993 20:49:06 +0000, Bent C Dalager wrote:

You again. Why am I not surprised to see you involved as well?

> [a lot of off-topic arguing about C comment parsing deleted -- this is a
> Java newsgroup, folks!]

>
> I think you are arguing now just for the sake of arguing. I plonked you
> once long ago for posting dozens of hundreds-of-lines-long posts a week
> for at least two months in response to a troll. If you post any more of
> this fight-picking and unconstructive jabbering, you're going straight
> back into the plonk bucket, express delivery.

The mystery is why you ever took him *out*. As you are no doubt
beginning to discover, Bent is, well, bent.

> Of course the lazy buggers will surely just keep using their old compiler,
> or their new compiler's --compatibility=C99 switch, or most likely their
> old compiler's --compatibility=C89 switch, anyway, so this is all moot.

LOL.

> > Recently I have largely limited myself to promptly correcting egregious
> > errors when I see them
>
> Unfortunately, you have numerous false positives.

So what else is new?

> Go to hell, "Bent" or whatever your real name is.
>
> _____________ _____________
> `-._ ..::| `-._ ..::| .
> `. ..::| `. ..::| /|
> | ..::| | ..::| /.|
> | ..::| _____ | ..::| / :|
> .--------.| ..::|.-' ..::-.---. .-----| ..::| / .:|
> | /\ .::. ..:.' ..::`. ' | ..::| / .::| /\
> |/ \ .::\../ ..::\ | ..::| / ..::|/ \
> .---' '---..::bd _ ..::b.._ | ..::|/ ..---' '---.
> `-. .-' .::PI (_) ..::m ) | ..::`-. .-'
> / \ ..:/.q ..::w / .| .:' / \
> /_.-``-._\..:' ..\ ..::/ / .:| ''---/_.-``-._\
> ' | ..:.` | ..:`. ..::,' / .::| ..:. `
> | ..:| | ..::|`-.__..::-':| / .::' | ..:::|'. ..:\
> | ..:J ,' ..:::. ,' ..::/ ..:' ,' ..::::. ) .::b
> | ..:/ /____..::::\ /____...:/ .:' /____..:::::/ ..::P
> |.:,' /.:' / ..:::'
> |,' /.' / ..:-'
> ' ' /,-'
> '

So far, so good. If he doesn't place your honor and reputation at
stake, this is the best way to deal with Bent.

> > I do, however, much prefer to just point it out once and then move on,
>
> when this option is not removed by pesky terrorists wielding assault
> rifles that is,

Ooh, lookie, blue indigo used the T-word. How long before echelon NSA
goons come banging down his door with a "national security letter"
instead of a proper warrant? Wait, though, isn't blue indigo in New
Zealand or someplace like that? Then it'll probably be extraordinary
rendition, instead. Be afraid, be very afraid!

> Unfortunately, when I did make it explicit, you just came right back
> trying to pick another nit instead of just accepting it and moving on.
> That, to me, is the indication that you are not actually on any great
> quest to enlighten the masses, but rather, just like to pick fights on
> usenet. Well, that, and your past posting history which includes quite a

> lot of flamebaiting and [implied insult deleted]

And now the fun begins.

No, you're the troll.

None of the nasty things that you have said or implied about me are at
all true.

(All of the nasty things that you have said or implied about Bent are
true, though.)

> To the point that I have to wonder if you yourself are a troll.

You mean, it's only just clicked?

> [implied insult deleted] seems to be one way to troll a newsgroup

No, you're the troll.

None of the nasty things that you have said or implied about me are at
all true.

> after all, and so does being almost-rational but with some sort of "never

> quite gets it" syndrome. ([implied vicious insult deleted])

No. None of the nasty things that you have said or implied about me
are at all true.

> Regardless, arguing with you any further is pointless. I've stated my
> case, apparently our opinions still differ, and that should be the end of
> it. Clearly you're not so much seeking to enlighten me or anyone else so
> much as you're gunning for a metal dome trophy engraved "Ferrous Cranus of
> the Year, 2009".

To go right next to his Ferrous Cranus of the Year 2007 trophy, of
course, which he won by stubbornly defending *emacs* in a debate about
*usability* -- talk about hopeless causes. :)

> And, since you offended me greatly with your unfounded and borderline-
> libelous accusation of being here to try to trick people and waste hours
> of their time, I certainly won't be reading any more of your rubbish.

He escalates the longer he argues with you. From there it would
proceed to frank namecalling, rude condescension (talking down at you
like you were a three-year-old and the like), and generally insulting
and hostile demeanor, as well as posting 500-line behemoths full of
almost-reasonable nonsense in need of rebutting.

> As I said before, and now reiterate:
>
> _____________ _____________
> `-._ ..::| `-._ ..::| .
> `. ..::| `. ..::| /|
> | ..::| | ..::| /.|
> | ..::| _____ | ..::| / :|
> .--------.| ..::|.-' ..::-.---. .-----| ..::| / .:|
> | /\ .::. ..:.' ..::`. ' | ..::| / .::| /\
> |/ \ .::\../ ..::\ | ..::| / ..::|/ \
> .---' '---..::bd _ ..::b.._ | ..::|/ ..---' '---.
> `-. .-' .::PI (_) ..::m ) | ..::`-. .-'
> / \ ..:/.q ..::w / .| .:' / \
> /_.-``-._\..:' ..\ ..::/ / .:| ''---/_.-``-._\
> ' | ..:.` | ..:`. ..::,' / .::| ..:. `
> | ..:| | ..::|`-.__..::-':| / .::' | ..:::|'. ..:\
> | ..:J ,' ..:::. ,' ..::/ ..:' ,' ..::::. ) .::b
> | ..:/ /____..::::\ /____...:/ .:' /____..:::::/ ..::P
> |.:,' /.:' / ..:::'
> |,' /.' / ..:-'
> ' ' /,-'
> '

But now you've spoiled the little troll's fun by nipping that process
in the bud. Congratulations!

> Behaving as you have been doing is not the action of a civilized person
> attempting to cooperate with others in an endeavor to better understand
> and practise a craft. It is the action of someone who sees himself as at
> war with everyone around him, and feels the need to beat people and "win"
> something.

Like a Ferrous Cranus of the Year 2009 Award? ;)

> It is, in fact, [vicious implied insult deleted]

No! None of the nasty things that you have said or implied about me
are at all true.

Lew

unread,

Feb 23, 2009, 7:43:26 PM2/23/09

to

>
blue indigo wrote:
>>> ..., like the next y2k crisis in around
>>> twenty years when the number of seconds since the epoch starts to not
>>> fit
>>> in a 32-bit integer. The guy might spot a bunch of "int time"s
>>> instead of
>>> "long time"s and fix them proactively, or something.

Lew wrote:
>> This is not a Java problem, of course.

Larry K. Wollensham wrote:
> That depends. The standard library classes all use "long"s for this, but
> third-party code may exist that uses "int".

In which case it would be a third-party library problem, not inherent to Java.

Don't you think it would be strange for a third party to use 'int' for time
when the standard library has APIs in hand that use 'long'?

OTOH, I once evaluated a program in 1999 for Y2K compliance wherein the
developer had (recently) eschewed the native 'DATE', that was compliant, in
favor of a 2-character string for the year with a prepended "19". They had
actually gone through extra work to avoid compliance.

(They also insisted on running a Windows 3.1-native platform in DOS text mode
and did many other interesting things to reduce code quality.)

--
Lew

Arne Vajhøj

unread,

Feb 23, 2009, 7:51:13 PM2/23/09

to

Andreas Leitgeb wrote:
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> Andreas Leitgeb wrote:
>>> Lew <no...@lewscanon.com> wrote:
>>>> I'm going to recommend to the appropriate parties on my project that we use
>>>> the JARs for the code and not rebuild it from source.
>>> But then you still cannot *run* it with an 1.6 JRE, unless I'm mistaken.
>> Sure he can.
>
> Indeed, Mike pointed it out, that compiled code still works.
>
> Anyway, if people develop with JDK1.6, then it's not too unlikely,
> that someone may call one of Statement's new methods (on a thusly-typed
> reference), and later, at runtime, when they actually have a
> MyDerived_1Dot5er_Statement, they'd get runtime errors.
>
>> He are not using any of the new methods.
>
> But the "appropriate parties on his project" may ...
> Ok, Lew will also tell them not to do that...
> Just the compiler will not prevent them - afterall, they only
> compile against java.sql.Statement, not against the specific
> subclass in the driver-JAR.

All true.

But that is how every JDBC driver are.

If the JDBC driver support JDBC x.y, then you better
only use methods supported in JDBC x.y.

>> If he were the code would not be compiling with the old Java version.
> But they use the new Java version, (otherwise they wouldn't have
> problems recompiling those JARs)

I think you misunderstood me.

It is an upgrade from Java A to Java B that creates
the build errors, because standard interfaces used
has added methods in B.

But since the code compiled with A then we know
that they are not using any of the new methods.

Arne

Bent C Dalager

unread,

Feb 23, 2009, 7:57:37 PM2/23/09

to

On 2009-02-23, blue indigo <blue....@uatel.com.nospam.bogus.invalid.invalid.invalid> wrote:
> On Sun, 5654 Sep 1993 20:49:06 +0000, Bent C Dalager wrote:
>> in the hope that I catch them before someone is tricked
>

> (...) You dare accuse me of trying to trick people?

I don't expect it was intentional but that is largely irrelevant when
it nevertheless comes about as an unintended consequence. Right now
you appear to be engaged in some bizarre and elaborate form of self
defence that is helpful to no one.

>> Of course, some people take being corrected better than others.
>
> It tends to depend at least partially on whether they actually need to be
> corrected, as well as on their personality, and on whether this
> "correction" takes place in private or public.

Errors that have entered the public need to be corrected in public,
unfortunately. Not because it is massively important to educate
whoever posted the error (although that would be a welcome effect I am
sure) but to rescue others from buying into a misconception.

> P.S. In polite society, when someone tries to clarify something or save
> face, you let them.

I am not going to let such a serious error stand just because someone
feels the need to save face. This is a technical forum and technical
errors must be expected to come under quite considerable attack.

Larry K. Wollensham

unread,

Feb 23, 2009, 8:05:07 PM2/23/09

to

Lew wrote:
> Larry K. Wollensham wrote:

>> Lew wrote:
>>> blue indigo wrote:
>>>> ..., like the next y2k crisis in around
>>>> twenty years when the number of seconds since the epoch starts to
>>>> not fit
>>>> in a 32-bit integer. The guy might spot a bunch of "int time"s
>>>> instead of
>>>> "long time"s and fix them proactively, or something.
>>>

>>> This is not a Java problem, of course.
>>

>> That depends. The standard library classes all use "long"s for this,
>> but third-party code may exist that uses "int".
>
> In which case it would be a third-party library problem, not inherent to
> Java.

That's true.

The question is, what did you originally mean by "this is not a Java
problem"?

"This is not a problem with Java's own implementation or standard
library" would be a true statement.

"This is not a problem that can occur in Java code at all, the way it
can in C or C++ code" would be incorrect, however.

Ambiguity bedevils us all, especially when we're using a language that
has no compiler to warn us of it. :-)

Arne Vajhøj

unread,

Feb 23, 2009, 8:13:54 PM2/23/09

to

blue indigo wrote:

> On Sun, 22 Feb 2009 20:13:16 -0500, Arne Vajhøj wrote:
>> blue indigo wrote:
>>> On Sun, 5654 Sep 1993 12:13:05 +0000, Bent C Dalager wrote:
>>>> What, then, /did/ you mean
>>> I meant exactly what I said, mate. Assuming string and character
>>> constants, and maybe one or two other things, are handled correctly, the
>>> only code it would break would be code that was exploiting the non-nesting
>>> of comments to do something "sneaky" like togglable compilation that is
>>> better done using #if and friends.
>> I gave a very example of a regular comment just placed at
>> a special location.
>
> You gave an example that was a) contrived and b) broken by the
> introduction of C++'s // comments, not by making /* */ comments nest.

It may be contrived.

But it was not broken by C++'s or C99's // comments. In fact it compiles
great in C++ !

But it would break with your proposal.

> In practise, I would not expect code like "int a = 2//**/1;" to arise
> outside of deliberate obfuscation or, of course, contrived examples.

Neither would I. Among other things because it would not compile
with C++ or a C that has implemented at least that part of C99.

But it is rather irrelevant.

Since it was not the example I gave.

You would gain more credibility in your argumentation, if you
read what you are replying to.

>>> Regardless, I don't think making that change even now would be 1/10 as
>>> horrible as you seem to be making it out to be.
>> Breaking existing code is always bad.
>
> Breaking existing production code. I hope nothing like "int a = 2//**/1;"
> is actually used in production code.

Assuming that we talk about what I wrote - not you invention - then you
never know.

> Usually, though, when a project is mission critical everybody sticks with
> known-working versions of everything for that project. This is why we have
> projects out there that internally use java 1.3 even though java 6 is
> current and 7 is around the corner.

It is often postponed for a long time, but eventually an upgrade
often happen.

new HW => new OS version => new C compiler version

> Sometimes also, it's a case of no pain, no gain. There must be SOME reason
> why they added a method to the javax.sql.Statement interface, as was
> lamented in another thread here recently.

Someone considered it a useful feature.

And as demonstrated here people are not happy about it breaking
existing builds.

And this is a case of something that has always been like that. It
is not a new phenomenon.

> The bar to justification for a change like any of these is higher the more
> production code is likely to be impacted, and the harder it would be to
> fix that code.
>
> In the case of javax.sql.Statement I'd say that bar was quite a lot higher
> than in the case of either introducing // comments to C or hypothetically
> making /* */ comments nest. I'd say introducing // comments to C has the
> lower bar, though, and /* */ nesting would be in between,

Given how development of C and Java are progressing and how they are
used, then I would changes to java.sql way under adding nested comments
to C/C++.

// was added to C 10 years ago.

>> There is a project plan, no hours has been allocated to change anything
>> in some old code, suddenly if gives build errors, nobody has touched
>> those X million lines of code for years, first thing is to find someone
>> that has a clue about how the code works, the project goes directly over
>> in high risk mode.
>
> See above.
>
> Even if so, sometimes a project needs a kick in the compacency. Legacy
> code with no experts around to maintain it will rot your project
> eventually anyway. Maybe having to get someone to fix something will save
> even worse trouble down the line, like the next y2k crisis in around
> twenty years when the number of seconds since the epoch starts to not fit
> in a 32-bit integer. The guy might spot a bunch of "int time"s instead of
> "long time"s and fix them proactively, or something.

Software are not developed for fun but for money.

Something that must be fixed cost money.

And the chance that it will be used as an opportunity to
cleanup the entire code is pretty small.

Arne

Lew

unread,

Feb 23, 2009, 8:24:36 PM2/23/09

to

Larry K. Wollensham wrote:
>>> That depends. The standard library classes all use "long"s for this,
>>> but third-party code may exist that uses "int".

Lew wrote:
>> In which case it would be a third-party library problem, not inherent
>> to Java.

Larry K. Wollensham wrote:
> That's true.
>
> The question is, what did you originally mean by "this is not a Java
> problem"?
>
> "This is not a problem with Java's own implementation or standard
> library" would be a true statement.
>
> "This is not a problem that can occur in Java code at all, the way it
> can in C or C++ code" would be incorrect, however.
>
> Ambiguity bedevils us all, especially when we're using a language that
> has no compiler to warn us of it. :-)

Excellent point.

As it happens I meant "not a problem with Java's own implementation".

--
Lew
I'm just not sure how I feel about ambivalence.

Arne Vajhøj

unread,

Feb 23, 2009, 8:47:16 PM2/23/09

to

Larry K. Wollensham wrote:
> Lew wrote:
>> blue indigo wrote:
>>> ..., like the next y2k crisis in around
>>> twenty years when the number of seconds since the epoch starts to not
>>> fit
>>> in a 32-bit integer. The guy might spot a bunch of "int time"s
>>> instead of
>>> "long time"s and fix them proactively, or something.
>>
>> This is not a Java problem, of course.
>
> That depends. The standard library classes all use "long"s for this, but
> third-party code may exist that uses "int".

Considering that long and Date has been used since Java 1.0, then
the risk is very low.

Most likely there are some code out there. If there exist a bad
practice for code then there are some code somewhere implementing
it.

But it is not going to have y2k dimensions in the Java world.

> In C, on the other hand, you can't even count on "long" being more than
> 32 bits. Usually it's only 32 bits. The GNU compiler gcc supports a
> "long long" that is 64 bits, but it's nonstandard.

long long made it into C99 so it is standard and even though C99
adoption is extremely slow, then long long seems to be pretty
common today.

> Each C implementation
> should define time_t and similar typedefs appropriately, and in the
> structs some of these reference, use appropriate types for the fields.
>
> Whether most modern Unix kernels and tools are compiled nowadays to use
> 64-bit-wide representations of seconds since the epoch, I wouldn't know.

I believe that AIX, Solaris, MacOS X, *BSD all has 64 bit time_t
today in their 64 bit versions.

Arne

Lew

unread,

Feb 23, 2009, 8:53:28 PM2/23/09

to

Arne Vajhøj wrote:
> Software are not developed for fun but for money.
>
> Something that must be fixed cost money.
>
> And the chance that it will be used as an opportunity to
> cleanup the entire code is pretty small.

Apropos of that, there is the notion of "technical debt" - code that was
written less than optimally but basically works. Fixes to that are motivated
by money concerns - it costs more to maintain than fixed code. Delays to such
fixes also are motivated by money concerns - the fix can cost a chunk of money
(effort) that is more painful in the short run than the incremental cost of
dealing with the suboptimal code.

So there is an effect where the overall cost is higher because projects don't
want to expend short-term resources to bring the cost down in the longer term.

One approach is to reduce technical debt in the context of larger, more urgent
changes. For example, if a project migrates to Java 5 or later from version
1.4 or later, don't add generics at first. Later, when there's a database
redesign, add generics to the persistence layer while refactoring the code for
the DB changes. Still later, generify the application logic that uses the
persistence layer while modifying the business logic for the new data
structures and business rules.

This isn't necessarily a complete solution, but it helps keep a project
cleaner overall without the gut-wrenching hit and risk associated with
all-at-once changes.

--
Lew

Arne Vajhøj

unread,

Feb 23, 2009, 9:07:55 PM2/23/09

to

Lew wrote:
> Arne Vajhøj wrote:
>> Software are not developed for fun but for money.
>>
>> Something that must be fixed cost money.
>>
>> And the chance that it will be used as an opportunity to
>> cleanup the entire code is pretty small.
>
> Apropos of that, there is the notion of "technical debt" - code that was
> written less than optimally but basically works. Fixes to that are
> motivated by money concerns - it costs more to maintain than fixed
> code. Delays to such fixes also are motivated by money concerns - the
> fix can cost a chunk of money (effort) that is more painful in the short
> run than the incremental cost of dealing with the suboptimal code.
>
> So there is an effect where the overall cost is higher because projects
> don't want to expend short-term resources to bring the cost down in the
> longer term.

True.

But the estimate to do the fix now is rather solid while the
estimate of the cost living with the code for 10 or 20 years
is very fuzzy.

Arne

Larry K. Wollensham

unread,

Feb 24, 2009, 12:34:23 AM2/24/09

to

Bent C Dalager wrote:
> On 2009-02-23, blue indigo <blue....@uatel.com.nospam.bogus.invalid.invalid.invalid> wrote:

>> Go to hell, "Bent" or whatever your real name is.
>>
>> _____________ _____________
>> `-._ ..::| `-._ ..::| .
>> `. ..::| `. ..::| /|
>> | ..::| | ..::| /.|
>> | ..::| _____ | ..::| / :|
>> .--------.| ..::|.-' ..::-.---. .-----| ..::| / .:|
>> | /\ .::. ..:.' ..::`. ' | ..::| / .::| /\
>> |/ \ .::\../ ..::\ | ..::| / ..::|/ \
>> .---' '---..::bd _ ..::b.._ | ..::|/ ..---' '---.
>> `-. .-' .::PI (_) ..::m ) | ..::`-. .-'
>> / \ ..:/.q ..::w / .| .:' / \
>> /_.-``-._\..:' ..\ ..::/ / .:| ''---/_.-``-._\
>> ' | ..:.` | ..:`. ..::,' / .::| ..:. `
>> | ..:| | ..::|`-.__..::-':| / .::' | ..:::|'. ..:\
>> | ..:J ,' ..:::. ,' ..::/ ..:' ,' ..::::. ) .::b
>> | ..:/ /____..::::\ /____...:/ .:' /____..:::::/ ..::P
>> |.:,' /.:' / ..:::'
>> |,' /.' / ..:-'
>> ' ' /,-'
>> '
>

> Right now you appear to be engaged in some bizarre and elaborate form
> of self defence that is helpful to no one.
>

> Errors that have entered the public need to be corrected in public
>

> I am not going to let such a serious error stand just because someone
> feels the need to save face. This is a technical forum and technical
> errors must be expected to come under quite considerable attack.
>

> [other condescending bullshit in a similar vein, deleted]

Uh, I think it's pretty clear that he's killfiled you, Bent.

It really makes you look bad -- petty and mean -- when you keep right on
flaming someone that's made it clear they are not interested in having a
fight with you, or in anything else you might have to say.

So, may I respectfully suggest that you blow it out your I/O port.

Sincerely,
Larry

P.S. I have to say I was leaning towards blue indigo's side here. I
don't think making C comments nest properly would have too painful
consequences, and it would be beneficial in the long run. Much less
doing the same with Java comments now, or C comments way back when C was
young.

And no, I'm not interested in hearing you argue further about it either,
my mind is made up.

And no, I'm especially not interested in becoming the target of your
personal criticisms and insinuations that my education is somehow not to
your satisfaction, either. At the first sign of such, I will plonk you
as firmly, if not quite as flamboyantly, as blue did.

P.P.S. Not all differences in opinion from yours constitute "errors",
Bent. A quick gloss over your posting-history as revealed through Google
Groups indicates that you have a very hard time accepting anyone who
persistently expresses an opinion that does not rapidly come around to
align with yours once you make yours clear. Instead, you begin to regard
such a person as "obviously" deficient in education, mental functioning,
or both, and to be increasingly public about that opinion too.

It seems you got embroiled in at least one ridiculously long flamewar in
this group before due to this tendency of yours, fought against someone
rather less willing to give up and killfile you than blue.

Might I suggest that you consider carefully next time this sort of thing
happens that perhaps it is YOU that is wrong, or perhaps it is a mere
difference of opinion and that reasonable men may, sometimes, actually
disagree? This particular case looks like an instance of the latter, to
me. Would it break thousands of lines of C code in most C projects to
make the change blue suggested? I don't know. I think probably not. Blue
thought probably not. You seem to think probably yes. Fine, opinions
obviously vary. It's not an "error" that this is so. It is normal in a
population not composed entirely of clones (or sockpuppets). The sooner
you realize this, the better you will be able to get along with other
usenetters. Presuming of course that getting along with others is even a
goal of yours, about which I'm sad to say I have my doubts.

Regardless, sayonara. I'm not interested in debating any of this stuff
with you, let alone any unpleasant personal opinions about me that you
might now wish to relate. I won't be responding any further to this, and
if you do flame me, it will be the last post by you that I ever read in
this or any other thread. Just so you know.

Lew

unread,

Feb 24, 2009, 1:09:54 AM2/24/09

to

Lew wrote:
>> So there is an effect where the overall cost is higher because
>> projects don't want to expend short-term resources to bring the cost
>> down in the longer term.

Arne Vajhøj wrote:
> True.
>
> But the estimate to do the fix now is rather solid while the
> estimate of the cost living with the code for 10 or 20 years
> is very fuzzy.

Perhaps so, but also when the code has been a certain way for a while, the
cost of leaving it that way can be extrapolated from its history.

Often what happens is a small part of the team raises a concern early in the
accumulation of technical debt, but gets overruled. As time goes on, bugs
creep in, workarounds accrete, new features get harder to implement, good
ideas get more likely to be suppressed because they aren't compatible with
existing code.

On the flip side, it's dangerous to eliminate some apparent "cruft" because
it's actually there for a good reason. Not every suggestion to refactor is
the right one.

Competent project management will be alert to both sides of that balance and
look for ways to minimize the technical debt without causing instability.
Amortization of refactoring effort into other more obviously necessary work is
just one useful tactic.

Refusing to reduce technical debt by claiming that it's too fuzzy to calculate
is probably not the best approach. Better is to find ways to estimate it,
with reality checks to make sure that it is not misdiagnosed. It is this sort
of commitment that led to the development of Agile programming, AIUI. A
subject about which I still do not know much.

--
Lew

blue indigo

unread,

Feb 24, 2009, 1:27:07 AM2/24/09

to

On Mon, 5655 Sep 1993 20:13:54 -0500, Arne Vajhøj wrote:

> blue indigo wrote:
>> On Sun, 22 Feb 2009 20:13:16 -0500, Arne Vajhøj wrote:
>>> blue indigo wrote:
>>>> On Sun, 5654 Sep 1993 12:13:05 +0000, Bent C Dalager wrote:
>>>>> What, then, /did/ you mean
>>>> I meant exactly what I said, mate. Assuming string and character
>>>> constants, and maybe one or two other things, are handled correctly, the
>>>> only code it would break would be code that was exploiting the non-nesting
>>>> of comments to do something "sneaky" like togglable compilation that is
>>>> better done using #if and friends.
>>> I gave a very example of a regular comment just placed at
>>> a special location.
>>
>> You gave an example that was a) contrived and b) broken by the
>> introduction of C++'s // comments, not by making /* */ comments nest.
>
> It may be contrived.
>
> But it was not broken by C++'s or C99's // comments. In fact it compiles
> great in C++ !

"int a = 2//**/1;" is treated is "int a = 2/ 1;" by pre-C99 C, and as "int
a = 2" by C99, C++, or Java. The most important thing for the question of
whether it *compiles* or not is actually the missing semicolon. Depending
on what follows, this may or may not be legal. It seems likely to me that
in most plausible contexts, it will result in a syntax error, so no, it
will not compile "great" in C++. On the other hand, there may be contexts
in which it will compile, but the meaning may be altered. It is possible
that in a few contexts it will compile without altered meaning as a gets
assigned 2 in both cases.

In the specific case that the line is followed by a lone ; it will compile
in both cases and assign a the value 2 in both cases, though this would be
equally contrived to the original example.

> But it would break with your proposal.

There is no /* /* */ sequence in there, so no, it would not.

>> In practise, I would not expect code like "int a = 2//**/1;" to arise
>> outside of deliberate obfuscation or, of course, contrived examples.
>
> Neither would I. Among other things because it would not compile
> with C++ or a C that has implemented at least that part of C99.

It will under some circumstances, including if the next line starts with a
semicolon. Empty statements are legal in C, so it would still compile
as C89 in that case as well.

More importantly, it will compile in C89 without the next line having to
start with a ; and C89 is still in widespread use.

> But it is rather irrelevant.
>
> Since it was not the example I gave.

Yes it was.

Your post said:

>>>>> int a = 2//**/1;

>>>> I didn't say it could.

>>> What, then, /did/ you mean
>> I meant exactly what I said, mate.

> I gave a very example of a regular comment just placed at
> a special location.

How else was I to interpret it?

> You would gain more credibility in your argumentation, if you
> read what you are replying to.

I bloody well DID read what I was replying to, you condescending ...
person. And it said

>>>>> int a = 2//**/1;

>>>> I didn't say it could.

>>> What, then, /did/ you mean
>> I meant exactly what I said, mate.

> I gave a very example of a regular comment just placed at
> a special location.

If that is not what you actually *meant*, then you should have written
something difference.

Sorry for losing patience like that mate, but I get frustrated when people
like you and Bent seem determined to make the worst of something, and
especially when you have the gall to accuse and insult me for what I
can only assume was your own failure to communicate clearly.

The only one losing credibility here is you, both because you are
apparently saying one thing and then claiming you said something else a
few posts later and because you are resorting to personal attacks and
calling others' honesty into question when someone continues to disagree
with you.

Not everyone who disagrees with you is an uneducated moron. Sometimes they
simply don't share your opinion and occasionally they are just plain
right, and you wrong.

It would be nice of you to give others the benefit of the doubt and not
start writing messages whose every pore oozes forth your opinion that
someone is an uneducated moron or, worse, a liar, just because you
disagree with them and they don't promptly change their opinions to match
yours. There ARE other reasons why someone might not do that, you know.

>> Breaking existing production code. I hope nothing like "int a =
>> 2//**/1;" is actually used in production code.
>
> Assuming that we talk about what I wrote - not you invention - then you
> never know.

What invention? That line of text is from

>>>>> int a = 2//**/1;

>>>> I didn't say it could.

>>> What, then, /did/ you mean
>> I meant exactly what I said, mate.

> I gave a very example of a regular comment just placed at
> a special location.

It is an odd number of quote-levels deep, you will notice, while my texts
are an even number of quote-levels deep, since this is one of my posts. So
it's quite clear that I did not invent that at all. And you quite clearly
implied that you did, in the last two lines of that excerpt.

I do hope I will not have to repeat that same excerpt a fourth time. If I
do, I may decide to follow it up with a big fat plonk. Reluctantly, to be
sure, since you unlike Bent have made numerous useful posts to this
newsgroup. But if you are going to act like a spoiled child as soon as
someone says "no" to you and won't change his mind, and worse insinuate
that he is a liar for doing so, then I don't care to read anything else
you might have to say. Sorry, mate, but that's the way it is.

>> Usually, though, when a project is mission critical everybody sticks
>> with known-working versions of everything for that project. This is why
>> we have projects out there that internally use java 1.3 even though
>> java 6 is current and 7 is around the corner.
>
> It is often postponed for a long time, but eventually an upgrade often
> happen.

Along with any needed code changes. That would not change, of course.

>> Sometimes also, it's a case of no pain, no gain. There must be SOME
>> reason why they added a method to the javax.sql.Statement interface, as
>> was lamented in another thread here recently.
>
> Someone considered it a useful feature.

And comments that nest properly could also be considered a useful feature.
A much more broadly applicable one, too. Instead of only in database
projects it might come in handy in all projects.

> And as demonstrated here people are not happy about it breaking existing
> builds.

It has not been done yet, and therefore has not broken any existing
builds. All I can see is that *two* people, you and Bent, are not happy
about the *prospect* of it breaking existing builds, which prospect's
allegedly-terrifying nature you have failed to support with much evidence.

The same two people show a tendency towards letting this disagreement
become personal, and a tendency towards insisting upon having the last
word, and several other rather questionable tendencies, though, so I don't
think their disagreement is indication of very much, save possibly that
whatever they are disagreeing with is likely to have some merit.

> And this is a case of something that has always been like that. It is
> not a new phenomenon.

No, it is not. A quick perusal of your posting histories using Google's
archive shows that both of you have a long and sordid history of getting
into online fisticuffs over similarly minor quibbles with a variety of
people over the past several years. Both of you, particularly, have the
un-admirable trait that when anyone holds an opinion that differs from
yours on any subject, you think them ill-educated and in error, and if,
once you have made some effort to educate them and teach them the error of
their ways, they persist in holding an opinoon that differs from yours,
you think them a fool or worse, and moreover loudly and publicly proclaim
this opinion. It is frankly surprising that you do not get in even more
fights, when that is considered.

Bent's posting history to cljp consists of little else but a series of
such fights, hence the ease with which I decided he wasn't worth my time.
You have had rather more useful posts in your history, but still with a
tendency towards this ... I don't know what to call it. Maybe arrogance or
narcissism. Maybe a simple inability to distinguish between facts, which
may be absolutely wrong or right, and opinions, which may differ from
yours and still not be incorrect. Truth be told, though, I think the both
of you are moderately to severely autistic, though at least in Bent's case
without the usual language deficits. Hypergraphia if anything in his case.
That neatly explains both the geeky areas of interest and the inability to
recognize that others' opinions may be valid even when they are dissimilar
to your own, and it explains other more minor things, quirks and in your
case poor language skills.

Yes, I suppose that constitutes a flame. Well, if you don't like it,
perhaps you should think twice next time before opening your trap and
calling some chap a liar like you did to me when you said my credibility
was damaged by what you alleged to be dishonest debating tactics on my
part, which tactics apparently consisted of my a) reading what the quoted
material said were the previous iterations in this exchange and b)
attributing to you what the quote-nesting levels, combined with your own
words, implied was yours. Shockingly dishonest, that.

>> The bar to justification for a change like any of these is higher the
>> more production code is likely to be impacted, and the harder it would
>> be to fix that code.
>>
>> In the case of javax.sql.Statement I'd say that bar was quite a lot
>> higher than in the case of either introducing // comments to C or
>> hypothetically making /* */ comments nest. I'd say introducing //
>> comments to C has the lower bar, though, and /* */ nesting would be in
>> between,
>
> Given how development of C and Java are progressing and how they are
> used, then I would changes to java.sql way under adding nested comments
> to C/C++.

Nonsense. There is enough Java code in production to bury the interior of
Australia miles deep in the stuff, and an awful lot of it deals with
databases. Maybe even "nearly all" of it, for some values of "nearly all".

Whereas there is a lot of C and C++ code with /* */ comments in it but
very little that relies on comments NOT nesting, that is, has /* /* */
somewhere in it.

Furthermore, what C and C++ code does do this could be fixed
literally in minutes with a syntax-highlighting IDE after the hypothetical
transition of a project to a compiler that nests comments, by people with
no knowledge of what the specific code is supposed to do, only that /* and
*/ should come in matched pairs now. A typical project might have five
lines that need changing out of millions.

An automated tool could do it even faster, by locating */s that terminate
comments under the old rules and would no longer do so under the new ones
and doubling them up, tripling them, or more as necessary so that the
comment terminations would remain at the same locations.

Yes, folks, this is such a horrible existing-code-breaking change that it
would take all of TEN MINUTES to update a massive code-base, for anyone
with a little knowledge of C, the C preprocessor's internals, and shell
and/or make. So, basically any C hacker worth his pay. Yes, a whopping TEN
MINUTES! My God, it's the end of the world!

Of course, implementing new methods that were added to an interface, while
adhering to the interface's contract complete with whatever semantics it
requires of those new methods, is much much worse, and certainly not
automatable in any reasonable manner. Auto-generating methods that return
null or throw UnsupportedOperationException is as close as you can get,
but will surely violate the contracts for the new methods, and will blow
up at run-time as soon as the code has to interoperate with code that
actually calls those methods.

> // was added to C 10 years ago.

So?

If comment-nesting were adopted tomorrow, then on February 24, 2019 you
could say comment-nesting was added to C 10 years ago.

>> Even if so, sometimes a project needs a kick in the compacency. Legacy
>> code with no experts around to maintain it will rot your project
>> eventually anyway. Maybe having to get someone to fix something will
>> save even worse trouble down the line, like the next y2k crisis in
>> around twenty years when the number of seconds since the epoch starts
>> to not fit in a 32-bit integer. The guy might spot a bunch of "int
>> time"s instead of "long time"s and fix them proactively, or something.
>
> Software are not developed for fun but for money.

"A stitch in time saves nine" is not, contrary to popular belief,
a reference to saving golf strokes or something like that. It means saving
stitches, and in practise, it tends to mean saving money.

Oh, wait, that isn't popular belief after all. But apparently it is your
belief.

> Something that must be fixed cost money.

Hence why updating the toolchain used with a major project is so
infrequent. Comment-nesting or no comment-nesting.

> And the chance that it will be used as an opportunity to cleanup the
> entire code is pretty small.

Unfortunately.

Fortunately, though, "pretty small" is greater than zero.

blue indigo

unread,

Feb 24, 2009, 1:31:30 AM2/24/09

to

On Tue, 5656 Sep 1993 00:34:23 -0500, Larry K. Wollensham wrote:

> Bent C Dalager wrote:

>> On 2009-02-23, blue indigo <blue....@uatel.com.nospam.bogus> wrote:
>>> Go to hell, "Bent" or whatever your real name is.
>>>
>>> _____________ _____________
>>> `-._ ..::| `-._ ..::| .
>>> `. ..::| `. ..::| /|
>>> | ..::| | ..::| /.|
>>> | ..::| _____ | ..::| / :|
>>> .--------.| ..::|.-' ..::-.---. .-----| ..::| / .:|
>>> | /\ .::. ..:.' ..::`. ' | ..::| / .::| /\
>>> |/ \ .::\../ ..::\ | ..::| / ..::|/ \
>>> .---' '---..::bd _ ..::b.._ | ..::|/ ..---' '---.
>>> `-. .-' .::PI (_) ..::m ) | ..::`-. .-'
>>> / \ ..:/.q ..::w / .| .:' / \
>>> /_.-``-._\..:' ..\ ..::/ / .:| ''---/_.-``-._\
>>> ' | ..:.` | ..:`. ..::,' / .::| ..:. `
>>> | ..:| | ..::|`-.__..::-':| / .::' | ..:::|'. ..:\
>>> | ..:J ,' ..:::. ,' ..::/ ..:' ,' ..::::. ) .::b
>>> | ..:/ /____..::::\ /____...:/ .:' /____..:::::/ ..::P
>>> |.:,' /.:' / ..:::'
>>> |,' /.' / ..:-'
>>> ' ' /,-'
>>> '
>>

>> [other condescending bullshit in a similar vein, deleted]
>
> Uh, I think it's pretty clear that he's killfiled you, Bent.

Uh, I think it's pretty clear that he's a troll, Larry. In case you hadn't
noticed, they breed like wallabys hereabout. I think because people often
feed 'em around here.

> [Rest of long and elaborate attempt to teach Bent the error of his ways
> deleted.]

I'm pretty sure that fell on deaf ears.

Just plonk him like I did, mate.

Andreas Leitgeb

unread,

Feb 24, 2009, 1:33:17 AM2/24/09

to

Arne Vajhøj <ar...@vajhoej.dk> wrote:
> Andreas Leitgeb wrote:
>>> If he were the code would not be compiling with the old Java version.
>> But they use the new Java version, (otherwise they wouldn't have
>> problems recompiling those JARs)

> It is an upgrade from Java A to Java B that creates
> the build errors, because standard interfaces used
> has added methods in B.

This osc^H^H^Hpoint goes to ... Arne Vajhøj :-)

Bent C Dalager

unread,

Feb 24, 2009, 2:52:17 AM2/24/09

to

On 2009-02-24, Larry K. Wollensham <lkw...@gmail.com> wrote:
> P.S. I have to say I was leaning towards blue indigo's side here.

blue indigo
NNTP-Posting-Host: 4wbTGg0MZ1YcMcUA8fzBNg.user.aioe.org

Larry K. Wollensham
NNTP-Posting-Host: 4wbTGg0MZ1YcMcUA8fzBNg.user.aioe.org

Thank you both for your valuable input I suppose.

>At the first sign of such, I will plonk you
>as firmly, if not quite as flamboyantly, as blue did.

You know you want to.

Arne Vajhøj

unread,

Feb 24, 2009, 9:05:58 AM2/24/09

to

Lew wrote:
> Lew wrote:
>>> So there is an effect where the overall cost is higher because
>>> projects don't want to expend short-term resources to bring the cost
>>> down in the longer term.
>
> Arne Vajhøj wrote:
>> True.
>>
>> But the estimate to do the fix now is rather solid while the
>> estimate of the cost living with the code for 10 or 20 years
>> is very fuzzy.
>
> Perhaps so, but also when the code has been a certain way for a while,
> the cost of leaving it that way can be extrapolated from its history.

You need to have an idea about the lifetime of the code
and how many changes that will be done to it in the future.

Very difficult to estimate.

And historic data is not particular good for that purpose.

Arne

Arne Vajhøj

unread,

Feb 24, 2009, 9:33:51 AM2/24/09

to

Bent C Dalager wrote:
> On 2009-02-24, Larry K. Wollensham <lkw...@gmail.com> wrote:
>> P.S. I have to say I was leaning towards blue indigo's side here.
>
> blue indigo
> NNTP-Posting-Host: 4wbTGg0MZ1YcMcUA8fzBNg.user.aioe.org
>
> Larry K. Wollensham
> NNTP-Posting-Host: 4wbTGg0MZ1YcMcUA8fzBNg.user.aioe.org

Hmm. Someone has been talking a lot to himself lately.

Arne

blue indigo

unread,

Feb 24, 2009, 10:39:12 AM2/24/09

to

On Tue, 5656 Sep 1993 15:33:51 +0100, Arne Vajhøj wrote:

> Bent C Dalager wrote:
>> blue indigo
>> NNTP-Posting-Host: 4wbTGg0MZ1YcMcUA8fzBNg.user.aioe.org
>>
>> Larry K. Wollensham
>> NNTP-Posting-Host: 4wbTGg0MZ1YcMcUA8fzBNg.user.aioe.org
>
> Hmm. Someone has been talking a lot to himself lately.

Naw, he's my flatmate, mate! That there would be aioe's mangling of our
home network's router's address.

Arne Vajhøj

unread,

Feb 24, 2009, 12:15:27 PM2/24/09

to

blue indigo wrote:
> On Mon, 5655 Sep 1993 20:13:54 -0500, Arne Vajhøj wrote:
>> blue indigo wrote:
>>> On Sun, 22 Feb 2009 20:13:16 -0500, Arne Vajhøj wrote:
>>>> blue indigo wrote:
>>>>> On Sun, 5654 Sep 1993 12:13:05 +0000, Bent C Dalager wrote:
>>>>>> What, then, /did/ you mean
>>>>> I meant exactly what I said, mate. Assuming string and character
>>>>> constants, and maybe one or two other things, are handled correctly, the
>>>>> only code it would break would be code that was exploiting the non-nesting
>>>>> of comments to do something "sneaky" like togglable compilation that is
>>>>> better done using #if and friends.
>>>> I gave a very example of a regular comment just placed at
>>>> a special location.
>>> You gave an example that was a) contrived and b) broken by the
>>> introduction of C++'s // comments, not by making /* */ comments nest.
>> It may be contrived.
>>
>> But it was not broken by C++'s or C99's // comments. In fact it compiles
>> great in C++ !
>
> "int a = 2//**/1;" is treated is "int a = 2/ 1;" by pre-C99 C,

Yes.

> and as "int
> a = 2" by C99, C++, or Java. The most important thing for the question of
> whether it *compiles* or not is actually the missing semicolon. Depending
> on what follows, this may or may not be legal. It seems likely to me that
> in most plausible contexts, it will result in a syntax error, so no, it
> will not compile "great" in C++.

My example compiles fine on C++.

That you have found some other code that does not is rather
irrelevant.

>> But it would break with your proposal.
>
> There is no /* /* */ sequence in there, so no, it would not.

My example would break with nested comments.

>> But it is rather irrelevant.
>>
>> Since it was not the example I gave.
>
> Yes it was.
>
> Your post said:
>
>>>>>> int a = 2//**/1;
>>>>> I didn't say it could.
>>>> What, then, /did/ you mean
>>> I meant exactly what I said, mate.
>> I gave a very example of a regular comment just placed at
>> a special location.
>
> How else was I to interpret it?

Exactly as written.

I gave an example.

The code above is Bents example not mine.

>> You would gain more credibility in your argumentation, if you
>> read what you are replying to.
>
> I bloody well DID read what I was replying to, you condescending ...
> person.

It seems as you have not read my example.

> And it said
>
>>>>>> int a = 2//**/1;
>>>>> I didn't say it could.
>>>> What, then, /did/ you mean
>>> I meant exactly what I said, mate.
>> I gave a very example of a regular comment just placed at
>> a special location.
>
> If that is not what you actually *meant*, then you should have written
> something difference.

You should read who wrote what.

The example you quote is Bent's example not mine.

> Sorry for losing patience like that mate, but I get frustrated when people
> like you and Bent seem determined to make the worst of something, and
> especially when you have the gall to accuse and insult me for what I
> can only assume was your own failure to communicate clearly.

If you are not able to get the concept that that the example
quote is not my example from:

#Since it was not the example I gave.

then I will put the reason for the communication failure on you.

> The only one losing credibility here is you, both because you are
> apparently saying one thing and then claiming you said something else a
> few posts later and because you are resorting to personal attacks and
> calling others' honesty into question when someone continues to disagree
> with you.

I posted an example.

I referred to that.

My statements about its compilability is correct.

You do not seem able to distinguish between my example and
Bent's example.

That is hardly my problem.

> Not everyone who disagrees with you is an uneducated moron. Sometimes they
> simply don't share your opinion and occasionally they are just plain
> right, and you wrong.

That the code compiles with C++ is objectively observable.

It is not a matter of opinion.

> It would be nice of you to give others the benefit of the doubt and not
> start writing messages whose every pore oozes forth your opinion that
> someone is an uneducated moron or, worse, a liar, just because you
> disagree with them and they don't promptly change their opinions to match
> yours. There ARE other reasons why someone might not do that, you know.

This way of thinking sounds awfully familiar.

>>> Breaking existing production code. I hope nothing like "int a =
>>> 2//**/1;" is actually used in production code.
>> Assuming that we talk about what I wrote - not you invention - then you
>> never know.
>
> What invention? That line of text is from
>
>>>>>> int a = 2//**/1;
>>>>> I didn't say it could.
>>>> What, then, /did/ you mean
>>> I meant exactly what I said, mate.
>> I gave a very example of a regular comment just placed at
>> a special location.
>
> It is an odd number of quote-levels deep, you will notice, while my texts
> are an even number of quote-levels deep, since this is one of my posts. So
> it's quite clear that I did not invent that at all. And you quite clearly
> implied that you did, in the last two lines of that excerpt.

You invented that it was my example.

It is not.

It was Bent's example.

> I do hope I will not have to repeat that same excerpt a fourth time. If I
> do, I may decide to follow it up with a big fat plonk.

Feel free.

>>> Usually, though, when a project is mission critical everybody sticks
>>> with known-working versions of everything for that project. This is why
>>> we have projects out there that internally use java 1.3 even though
>>> java 6 is current and 7 is around the corner.
>> It is often postponed for a long time, but eventually an upgrade often
>> happen.
>
> Along with any needed code changes. That would not change, of course.

Not necessarily.

>>> Sometimes also, it's a case of no pain, no gain. There must be SOME
>>> reason why they added a method to the javax.sql.Statement interface, as
>>> was lamented in another thread here recently.
>> Someone considered it a useful feature.
>
> And comments that nest properly could also be considered a useful feature.
> A much more broadly applicable one, too. Instead of only in database
> projects it might come in handy in all projects.
>
>> And as demonstrated here people are not happy about it breaking existing
>> builds.
>
> It has not been done yet, and therefore has not broken any existing
> builds.

The changes to javax.sql.Statement interface has been done and has
broken builds.

> All I can see is that *two* people, you and Bent, are not happy
> about the *prospect* of it breaking existing builds, which prospect's
> allegedly-terrifying nature you have failed to support with much evidence.

Lew did not sound to happy about his little problem.

>> And this is a case of something that has always been like that. It is
>> not a new phenomenon.
>
> No, it is not. A quick perusal of your posting histories using Google's

> archive shows that both of you have a long and sordid history of ...

My posting history has little relevance to the fact that adding methods
to an interface breaks builds is not a new phenomenon.

> Bent's posting history to cljp consists of little else but a series of
> such fights, hence the ease with which I decided he wasn't worth my time.
> You have had rather more useful posts in your history, but still with a
> tendency towards this ... I don't know what to call it. Maybe arrogance or
> narcissism. Maybe a simple inability to distinguish between facts, which
> may be absolutely wrong or right, and opinions, which may differ from
> yours and still not be incorrect. Truth be told, though, I think the both
> of you are moderately to severely autistic, though at least in Bent's case
> without the usual language deficits. Hypergraphia if anything in his case.
> That neatly explains both the geeky areas of interest and the inability to
> recognize that others' opinions may be valid even when they are dissimilar
> to your own, and it explains other more minor things, quirks and in your
> case poor language skills.

Hello twerpie.

> Yes, I suppose that constitutes a flame. Well, if you don't like it,
> perhaps you should think twice next time before opening your trap and
> calling some chap a liar like you did to me when you said my credibility
> was damaged by what you alleged to be dishonest debating tactics on my
> part, which tactics apparently consisted of my a) reading what the quoted
> material said were the previous iterations in this exchange and b)
> attributing to you what the quote-nesting levels, combined with your own
> words, implied was yours. Shockingly dishonest, that.

Hello twerpie.

>>> The bar to justification for a change like any of these is higher the
>>> more production code is likely to be impacted, and the harder it would
>>> be to fix that code.
>>>
>>> In the case of javax.sql.Statement I'd say that bar was quite a lot
>>> higher than in the case of either introducing // comments to C or
>>> hypothetically making /* */ comments nest. I'd say introducing //
>>> comments to C has the lower bar, though, and /* */ nesting would be in
>>> between,
>> Given how development of C and Java are progressing and how they are
>> used, then I would changes to java.sql way under adding nested comments
>> to C/C++.
>
> Nonsense. There is enough Java code in production to bury the interior of
> Australia miles deep in the stuff, and an awful lot of it deals with
> databases.

Sure. But that is not particular relevant.

The problem only impacts using building a JDBC driver.

> Whereas there is a lot of C and C++ code with /* */ comments in it but
> very little that relies on comments NOT nesting, that is, has /* /* */
> somewhere in it.

Not a very good argument since other examples has been posted.

> Yes, folks, this is such a horrible existing-code-breaking change that it
> would take all of TEN MINUTES to update a massive code-base, for anyone
> with a little knowledge of C, the C preprocessor's internals, and shell
> and/or make. So, basically any C hacker worth his pay. Yes, a whopping TEN
> MINUTES! My God, it's the end of the world!

There are no such thing as 10 minute fixes in professional software
development.

> Of course, implementing new methods that were added to an interface, while
> adhering to the interface's contract complete with whatever semantics it
> requires of those new methods, is much much worse, and certainly not
> automatable in any reasonable manner. Auto-generating methods that return
> null or throw UnsupportedOperationException is as close as you can get,
> but will surely violate the contracts for the new methods, and will blow
> up at run-time as soon as the code has to interoperate with code that
> actually calls those methods.

Lew do not need to make any code changes. He need to use a binary (or
build that part with the correct Java version).

>> // was added to C 10 years ago.
>
> So?

It means that what you wrote:

# I'd say that bar was quite a lot higher
# than in the case of either introducing // comments to C

is a bit out of date.

Arne

Arne Vajhøj

unread,

Feb 24, 2009, 12:16:46 PM2/24/09

to

Yeah yeah.

Multiple accounts, worried about liars hurting his reputation - we
got the picture.

Arne