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

[Arne Vajhøj]

Compatibility, of course. What else?

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

 

[Mike Schilling]

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?

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.

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

 

[Bent C Dalager]

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.

Cheers,
Bent D

 

[blue indigo]

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]

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.

Cheers,
Bent D

 

[Arne Vajh¸j]

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]

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]

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.

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]

..., 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.

 

[blue indigo]

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.

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.

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.

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.

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.._ | ..::|/ ..---' '---.
`-. .-' .:I (_) ..::m ) | ..::`-. .-'
/ \ ..:/.q ..::w / .| .:' / \
/_.-``-._\..:' ..\ ..::/ / .:| ''---/_.-``-._\
' | ..:.` | ..:`. ..::,' / .::| ..:. `
| ..:| | ..::|`-.__..::-':| / .::' | ..:::|'. ..:\
| ..:J ,' ..:::. ,' ..::/ ..:' ,' ..::::. ) .::b
| ..:/ /____..::::\ /____...:/ .:' /____..:::::/ ..:
|.:,' /.:' / ..:::'
|,' /.' / ..:-'
' ' /,-'
'

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.._ | ..::|/ ..---' '---.
`-. .-' .:I (_) ..::m ) | ..::`-. .-'
/ \ ..:/.q ..::w / .| .:' / \
/_.-``-._\..:' ..\ ..::/ / .:| ''---/_.-``-._\
' | ..:.` | ..:`. ..::,' / .::| ..:. `
| ..:| | ..::|`-.__..::-':| / .::' | ..:::|'. ..:\
| ..:J ,' ..:::. ,' ..::/ ..:' ,' ..::::. ) .::b
| ..:/ /____..::::\ /____...:/ .:' /____..:::::/ ..:
|.:,' /.:' / ..:::'
|,' /.' / ..:-'
' ' /,-'
'

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]

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 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]

On Feb 23, 11:00 am, blue indigo
[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.


Unfortunately, you have numerous false positives.

So what else is new?

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

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

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

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.._    |  ..::|/ ..---'    '---.
 `-.      .-' .:I       (_)   ..::m   )   |       ..::`-.      .-'
   /      \  ..:/.q             ..::w  /   .|       .:'   /      \  
  /_.-``-._\..:' ..\           ..::/  /   .:|       ''---/_.-``-._\  
  ' |  ..:.`  |  ..:`.       ..::,'  /   .::|            ..:.     `  
    |  ..:|   |  ..::|`-.__..::-':| /  .::' |  ..:::|'.   ..:\      
    |  ..:J  ,'  ..:::.   ,'   ..::/ ..:'  ,'  ..::::. )   .::b      
    | ..:/  /____..::::\ /____...:/ .:'   /____..:::::/   ..:      
    |.:,'                        /.:'                /  ..:::'      
    |,'                         /.'                 / ..:-'          
    '                           '                  /,-'              
                                                  '                  

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]

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.)

 

[Arne Vajhøj]

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.


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.

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]

(...) 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.

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.

Cheers,
Bent D

 

[Larry K. Wollensham]

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]

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.

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.

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]

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".

 

[Arne Vajhøj]

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]

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.