jsdk1.4.1_01 - jsdk1.4.1_02 NOT compatable????

[DC Dalton]

Got a strange one here & not sure where to post it so I figured the "big brains" would be here. Here's what happened.
Ive been maintaining a large intranet app for about a year using 1.4.1_01 on my developer machine, compiling & testing before upload to our Linux app server (Im on a win 2000 box). Last week I had to whack my machine & re-install windows & when i noticed the 1.4.1_02 on Suns site I said "why not" Installed everything & went back to work. I made some changes to a class & uploaded them to the server (unfortunately my db was down so I couldnt test). As soon as anyone on the server attempted to access the code from this freshly compiled class they got an illegal class change exception that pointed to a StringBuffer. I frantically looked to see what I had screwed up but couldnt find anything. So I re-compiled the supporting class files & uploaded them. Ran fine BUT another class that had also used one of these classes started with the same error, I recompiled it & it was fine. So after hours I started trying to prove my theory. I would recompile ONE class file from each app & see what happened & sure enough I got the same exception. I ended up having to recompile every class file on the server..
So is this a bug? has anyone heard anything about this? What in heavens name is this all about? Now Im afraid to do any changes on any of my other projects beacuse all of them were compiled using 1.4.1_01 & am thinking I have to uninstall the new one & go back to the old...just for peace of mind!
For thos interested here is the offending line of code that threw the exception:
sb = prog.drawPageBottom(sb);
and the method it called:
public StringBuffer drawPageBottom(StringBuffer sb) {
sb.append(PAGE_END);
return sb;
}

The call to the method had been compiled in the new version, the method in the old.
[ April 29, 2003: Message edited by: DC Dalton ]

[Mike Dahmus]

I ran across a similar problem with a StringBuffer convenience conversion (to String) which was, instead, converted into an actual method when compiled with the 1.4.1 JDK -- then if you tried to run that code in 1.3, you got a NoSuchMethod exception.
I'd suggest first doing a complete chart of (compile on JDK X and run on JDK Y) to narrow your options; and then run each through the debugger (the ones that actually run, that is) to see if there's a similar situation going on - that's the only way I was able to find my problem.

[Jim Yingst]

So fat, I haven't come up with any ideas on this one. Can you provide the exact text of one of the errors maybe?

[DC Dalton]

Yes I can...here it is. again this references the above code (the line number in the exception) & worked fine again once I had re-compiled using the new java distro.
[2003/04/28 16:18:29] null
java.lang.IncompatibleClassChangeError
at challenge.DailyReport.doPost(DailyReport.java:123)
at challenge.DailyReport.doGet(DailyReport.java:129)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:126)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:103)
at com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.java:96)
at com.caucho.server.http.Invocation.service(Invocation.java:312)
at com.caucho.server.http.CacheInvocation.service(CacheInvocation.java:135)
at com.caucho.server.http.RunnerRequest.handleRequest(RunnerRequest.java:342)
at com.caucho.server.http.RunnerRequest.handleConnection(RunnerRequest.java:272)
at com.caucho.server.TcpConnection.run(TcpConnection.java:137)
at java.lang.Thread.run(Thread.java:536)

[Michael Morris]

I did a search on the bug parade and am not sure, but this: Bug Id 4800106 may be related to your problem.

[DC Dalton]

Yeah that could be in the same ball park.... looks like the new jvm compiler is getting picky!
I do know that NOTHING else changed. I backed resin & everything else up to my server & even copy & pasted the classpaths into a text file & dropped them back in. EVERYTHING was the same except the version of java. Looks like Ive got a TON of recompiling to do on all the sites I webmaster on! Yikes ...

[Jim Yingst]

Well, bug 4788384 sure seems pertinent, though unfortunately it offers no clue how to proceed. But that's sorta the point...

[DC Dalton]

But even that report is pointing to 1.3.1 (a little late for that!) ... what REALLY bothers me is the fact that this happened on a call to a method with a StringBuffer, talk about rock solid core stuff! I use these like a meter maid uses tickets, as I deal in webapps & slam the html plus program output into them. I find it strange that ANY compiler would create any difference in an object that has been around since day one but sure enough every time I re-compiled one object in each app the exception was thrown at the StringBuffer line... I would love to test it fully & prove the bug but I am up to my eyeballs in work & just dont have the time. I really do appreciate you guys looking into it though... I knew Id get the big boys attention in this section & I figured Id have to get you guys looking to get any kind of decent answer....again many thanks!

[Barry Gaunt]

sb = prog.drawPageBottom(sb);

public StringBuffer drawPageBottom(StringBuffer sb) {
sb.append(PAGE_END);
return sb;
}

It's probably irrelevent but why not:

prog.drawPageBottom(sb);
public void drawPageBottom(StringBuffer sb) {
sb.append(PAGE_END);
}

?

Afterthought: It's probably because you want to chain the method calls, I guess.
(Don't worry, ignore me )
[ May 01, 2003: Message edited by: Barry Gaunt ]