Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  java.lang.IncompatibleClassChangeError  (Read 2727 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Posted 2004-01-27 11:55:09 »

I've just had my first run-in with this delightful Error...

I'd made the fatal mistake of running javac against my *.java sources. Ahem. (If you're wondering how this can happen, scroll to the bottom...)

AFAICS, I'm pretty sure I'm running into the age old bug in javac that it thinks it knows which classes needs recompiling, but if sometimes doesn't, and requires you to manually (and recursively, obviously, if you have packages) delete every affected class file before trying again.

(At this point, Jeff will probably tell me this is not a bug, it's a feature, and it's really good too Wink.)

I don't mind the behaviour normally, but when it gets it wrong (which happens to me on average about once every month or two) it's a royal PITA. Obviously IDE's can automatically delete all classes for you before you start, which is one solution, but I'm hoping there's some undocumented switch on javac that turns off this behaviour?

It's not just a mild annoyance for compilation...we're also experimenting with a new SCM which doesn't accept incremental compilation, and the authors have pointed out that if we want java to work with it really nicely, we need to disable the incremental compile (for fairly obvious reasons, given it's an SCM...). They're all C++ programmers, and would like to know if we find a way of doing this...

Any suggestions?

EDIT: explanation of error: I upgraded a 3rd party library since my last compile of the sources; I think it altered a base abstract class in such a way that the subclass in my source is no longer a valid subclass. One aspect of javac's bug appears to be that it does NOT recompile sources when the JAR file that they depend on changes - it only works on raw class files.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #1 - Posted 2004-01-27 12:03:47 »

PS If anyone knows the appropriate unix command to recursively delete all *.class files...?

malloc will be first against the wall when the revolution comes...
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #2 - Posted 2004-01-27 12:25:59 »

Quote
PS If anyone knows the appropriate unix command to recursively delete all *.class files...?


<palandir> find <directory> -iname '*.class' -exec rm -f {} \;

Dunno if it works that way... however palandir usually knows what he's talking about Smiley

edit: it's an irc quote. palandir is the nickname :>

弾幕 ☆ @mahonnaiseblog
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #3 - Posted 2004-01-27 13:05:01 »

Quote


<palandir> find <directory> -iname '*.class' -exec rm -f {} \;


Thanks. That worked great.

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2004-01-27 13:59:14 »

That's why none of us actually use Javac to compile our code any more Smiley Wot you need, is a proper IDE Kiss

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #5 - Posted 2004-01-27 14:38:00 »

Quote
That's why none of us actually use Javac to compile our code any more Smiley Wot you need, is a proper IDE Kiss

Cas Smiley


Actually I was testing a script (aiming for LCD - were it not for this Error I could make one file that runs on both windows and unix Smiley) that could be bundled into a deployment package; it's easier to support something when you know you're including enough tools to guarantee anyone can get it to work. But your point still stands, of course...

However. The other problem remains - how to take full advantage of an SCM (i.e. something a lot better than CVS, VSS, etc, but in a similar vein) with javac. How to disable incremental compilation?

malloc will be first against the wall when the revolution comes...
Offline Jeff

JGO Coder




Got any cats?


« Reply #6 - Posted 2004-01-27 21:48:25 »

Terms are confusing me here.

Do you really mean incremental compilation or do you mean dependancy compilation?

AFAIK we don't do incremental compilation.  The only Java system I know that does is IBM's  VisualAGE.

In terms of compiling dependancies, I've never run into a problem with it (and we compile the entire JDK on the command line) but I'll take your word for it that the problem exists.  I don't know of any way to stop the compiler from trying to compile dependancies if it thinks it needs them.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #7 - Posted 2004-01-27 22:39:58 »

Quote
Terms are confusing me here.


Sorry, that is the terminology that THEY used to describe this aspect of java, I was only parroting their term; they cited it as a common feature of sun's javac and others like jikes. To me incremental compilation means no more than "you only compile the things that need compiling", which fits what I'm describing, but I've hardly ever heard the term w.r.t java, so...

Quote

Do you really mean incremental compilation or do you mean dependancy compilation?


Well, if you think the terminology's wrong, why don't you explain what it means to you? I don't know if I/they/we mean what you think we do Smiley. FOLDOC and others have empty definitions for the terms Sad, although I found one site that suggested incremental compilation meant "compiling individual methods" and having multiple copies of the same method inside a classfile, but changing function pointers to ensure that the "newest" versions were used.

By that definition, I certainly don't mean incremental compilation...

Quote

In terms of compiling dependancies, I've never run into a problem with it (and we compile the entire JDK on the command line) but I'll take your word for it that the problem exists.  I don't know of any way to stop the compiler from trying to compile dependancies if it thinks it needs them.


In general, as I said, I'm not bothered by this class of problems; if I see weird behaviour in mine or someone else's code I first type "java -version" and then try redirecting the build classfiles to a new, empty, directory Smiley. I don't really think about it, and it could be that 99% of the cases I see are user error where people are trusting javac to be sentient Smiley (c.f. next para).

FYI A common problem I've seen is when an old class file gets left around for a class that no longer exists (because of recent refactoring) where unless/until you manually (or a script of yours automatically) deletes said file, other classes dependent on that classfile won't recompile. It makes perfect sense when you realise what's happening, but I've seen it really upset more than one person (days of debugging and muttering "this can't be possible" Smiley until they see the light).

There have always been some problems in this area (although e.g. the one I describe above is user-error and not any kind of javac bug) since I started developing in java. My understanding is that . IIRC javac uses the datestamps (amongst other data) to make decisions of what to compile, so another example is with mounted FS's (and flakey OS's) where these may be sufficiently inaccurate as to screw things up (again, more of a user error). The first example I recall hearing (2nd hand) was of compiling sources partly from a mounted remote FS and partly from the local one, where disparity in the clocks of the two machines caused certain files not to recompile, with no compiler warnings etc of course, producing really strange bugs (until you worked out the cause).

PS w.r.t the example I had today with the ICCError it could have been another user-error case; I didn't check for orphaned classfiles, for instance, although I do know that I updated a jar file and javac didn't recompile several files that were dependent on classes contained therein; if I had a definite precise test case of these build problems (and they caused more serious pain than they do Smiley)  I'd file a bug report Smiley. As Cas pointed out, it's usually just a cosmetic thing.

FWIW I'm not even convinced this dependency compilation should be a problem for the SCM. However, it's an SCM where the entire repository is transparently mapped into your FS (nb: unix only), so the problems could come from the fact that results of previous compiles are in the classpath for future compiles and there's no way of turning this off without breaking several features of the SCM Sad. (nb: we are trying to find ways around this, e.g. by de-mapping pre-existing classfiles from the FS. Dunno if this is going to work or not, though...)

malloc will be first against the wall when the revolution comes...
Offline Jeff

JGO Coder




Got any cats?


« Reply #8 - Posted 2004-01-28 06:35:24 »

Incremental compilation has traditionally meant the compilation of aprts of the rpgoram as it was written or modified.  It generally implies the abilty to do substitution of code in mid-run.

IBM's VisualAge does this.  If you re-write a method in a  running program that method instantly changes.  SmallTalk systems traditionally did this.  There was a product a while back called somethign liek InstantC which was a C environment that used threaded compilation and also did such replacement, in its case a line of code add a time resulting in a psuedo-interpreted like environment for fiddling with C code.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #9 - Posted 2004-01-28 06:38:31 »

Ah, i follow your problem soem now.  yes, if a class file of a date later then your current .java file exists and ist a dependancy for another class then its not going to get recompiled.  You would have to do a clean or manually recompile it yourself.  We've seen soem problems like thsi wehn usign code from multipel build environments that aren't well time-synchronized.  usually doing a clean sovles the problm.

Im abit surprised that your putting your .class files in your SCM though as they aren't "source"...

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #10 - Posted 2004-01-28 11:38:53 »

Quote
Ah, i follow your problem soem now.


Cool Smiley. As I said, it's usually just a minor niggle (so long as you recognize it and don't waste days discovering the problem!). Thanks for clearing up the incremental-compilation definition...

Quote

Im abit surprised that your putting your .class files in your SCM though as they aren't "source"...


That's part of why this is such a special SCM Smiley...in fact, you have to check-in your *compiler* too. It aims for (and, allegedly, easily achieves) 100% repeatable builds (even if you originally built it on JDK 1.0.0, and find it's now no longer available for download Smiley). Of course, this feature was designed for C programmers, not Java, since this can be a really big problem in C dev.

We're still evaluating it, but my initial impressions are that it's a bit of a killer app in the SCM world (hint: it's free, but with several of the good features I miss from my days working at big corporates who had monstrously expensive SCM's).

Still, we're still getting to grips with it; it's not mainstream at all, and so documentation is good but very sparse. Once we've used it in anger, if it's still any good, I'll post to the tools forum with info Smiley. Right now, my experience with it is too brief to be able to say much about what it does and doesn't do.

malloc will be first against the wall when the revolution comes...
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (23 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (43 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!