I've been working as a Java developer for just short of a year now and am gradually trying to increase my knowledge to speed up development times. One of the habits I find myself doing is forcing an occasional clean without really knowing if I need it.
I get that if you use it, your project will be completely re-built, however I don't fully understand under what circumstances I would want to use it.
If I understand correctly, most, if not all, changes to a project will be built automatically, so with that there should only be a rare occasion that I would actually need to use a project clean.
Clean is useful if some external tool modifies your output folder. For example, you are using Eclipse, but occasinally compile via command line compiler into the same folder. In this case Eclipse may fail to do incremental build and display errors in code when they are actually absent.
Another case is working around some bug in Eclipse compiler itself. In very rare cases and in specific Eclipse versions/updates some classes which are necessary to be recompiled after specific code changes might be overlooked by compiler. If you were (un)happy enough to encounter such case, clean will help you.
It is for example useful if you delete a class, and then you forget to remove a reference to it in another class. If you do not clean the project, your local copy will still work, but what you actually did is that you just broke the build. ;)
Your local copy of the project will still work because the .class of the deleted class will still be there. To find out problems like this, is usually a good thing to compile the project from scratch on the integration system.
Related
Sorry if this question is kind of vague. Let me know if I can provide any additional relevant details.
Basically, every so often (at least once every few weeks), when I open my Eclipse workspace I am greeted with a large number of errors. It often says that almost every single one of my projects have errors even though they were working just the day before. I understand that something is getting messed up in the build-path because it gives me errors such as The type java.lang.Object cannot be resolved. However, I don't understand why restarting Eclipse would cause this build-path to get messed up. It also seems fairly common for me to get errors on imports for various Android classes even though I have included the Android SDK in the project.
I guess what I am asking is twofold:
1) Why is this happening and is there anything that I can do to stop this from happening?
2) When this does happen, is there an easy way that I can resolve it? I know that I can go into the Preferences for an individual project and add libraries to the build-path but I can't figure out how to easily do this for all of my projects at once, and I feel like I'm just trying things until they work, so it would be good to have a more defined procedure for dealing with these sorts of problems.
EDIT:
Does anyone have any ideas?
You might need a valid JRE or JDK defined in the Java Build Path of your project.
I use Eclipse and have some project compiled and running. Then I decide to modify some class.
It seems that running project doesn't catch up changes, but if I run another instance of project then it does see changes.
The question, how does Eclipse rule this out?
Because I see that .class files are stored as single instance and later changes just overwrite previous. It maybe JVM who load classes in memory and don't touch them even if they changed. But I would like to hear complete story.
When a program runs, it reads the .class file into memory and uses that copy from then on.
If you change, it doesn't re-read the file and load/link it again, that would be more complicated. There are class loaders which do this automagically, but this is not default behaviour. (It is also very unreliable as you might change the class in an incompatible way e.g. modify a field, or method signature)
Generally speaking, software is implemented in the simplest way imaginable. It is more likely to work and be understood if it is simple. This should be your guiding principle when trying to understand how computers work.
After looking at the Play! framework I find it really productive that the development server that it comes with automatically is able to compile .java files and show the changes, immediately. There's no hot deployer scanner that runs every tot seconds or so. The compilation happens when you hit refresh and it's extremely faster than my incremental mvn package. How do they do this?
I would like to know, well because I'm interested in knowing, but also because I don't want to use the entire Play! framework for my small project. I'm only interested in their development compilation process because I would like to adopt it :).
Any ideas?
I was reading about this just this morning. It actually takes your changed source files and uses the Eclipse Java Compiler (ECJ) internally before spitting out the compiled files to the built-in dev server.
The thing is, you probably don't want to go to the effort of wiring the ECJ into your "small project".
You can definitely approximate it though - the trick is to not do a mvn package, instead you want to be dropping the changed .class files into your webapp's exploded warfile directory on the filesystem.
If you're not tied to a particular app server/container, have a look at the Eclipse Jetty Plugin - looks like it's what you need, and Jetty is quick
JDT -- Play! uses Eclipse JDT to compile and load classes dynamically. Much the same way you code in Eclipse and you see an error or warning messages as soon as you type in something not desirable. See ApplicationCompiler class.
You may also want to look into JDT.
Play uses the Eclipse compiler to compile code at run-time.
Take a look at the following class, that is used by Play to perform the necessary compilation at run time.
https://github.com/playframework/play/blob/master/framework/src/play/classloading/ApplicationCompiler.java
The way they do it is by using a custom classloader that will detect changes to source files, use the Eclipse Java Compiler to compile the files and then hot swap the appropriate classes in the JVM. If you are looking for something similar, checkout ZeroTurnaround's JRebel
it is not free, but well worth the time savings when you need to redeploy a large project.
I'm not a Play developer however Struts2 is also capable of this but though the struts2-spring-plugin. Since the class reloading is provided by Spring it might be possible to use this spring feature by any project.
http://struts.apache.org/2.2.1/docs/spring-plugin.html
Search the page for "Class Reloading".
I'm working on a couple of web services that use JAXB bindings for the messages (in JAX-WS or spring-ws). When using these bindings there's always some code that is automatically generated from the WSDL to bind the message objects. I'm struggling to figure out the best way I can make this work so that it's easy to work with, hard to break and integrates nicely with IDEs (mostly using eclipse).
I think there are a couple of ways to go about this. The three main options I see right now are:
Generate code, keep the source artifacts and check them into the repository. Pros: integrates easily with IDEs (source highlighting etc), works within the build system. Cons: generated code changes each time you regenerate it, possibly creating noisy commits. It's also redundant since the WSDL file is already checked in, usually.
Generate code as part of the build process. Don't keep source artifacts or only keep them in output directories. Pros: fixes all the cons from the previous one. Cons: harder to integrate with IDE, though maybe this build step can be run automatically? I currently use this on one of my projects but the first time I checkout the project it appears broken, which is a minor nuisance.
Keep generated bindings in separate libraries (jars) included with maven or manually updated jars, depending on your build process. I got the idea from a thread on java.net. This seems more stable and uses explicit versioning but seems a bit heavyweight.
Which one of these options would you implement and how? We're currently using maven and eclipse, so any ideas in that regard would be great. I think this problem generalises to most other build systems and IDE combinations though, even other languages perhaps.
I went for option 3. If you already host your own repository (and optionally CI), it's not that heavyweight. All it takes is a simple POM. It's even possible to include some utility/wrapper/builder classes (that often make life easier with generated classes) and use them in several projects.
I'd go for option 2 and generate code in the "standard" ${project.build.directory}/generated-sources/<toolname> location as part of the build process. Using generated sources is well supported by m2eclipse (use Maven > Update Project Configuration once sources have been generated) and, if I remember well, by the maven eclipse plugin as well (i.e. the folder will be added to the Java Build Path). Actually, I think NetBeans also handle this fine. Not sure for Idea.
For the generation itself, you may need the maven-jaxb2-plugin if I understood correctly.
I guess this is kind of a follow-on to question 1522329.
That question talked about getting a list of all classes used at runtime via the java -verbose:class option.
What I'm interested in is automating the build of a JAR file which contains my class(es), and all other classes they rely on. Typically, this would be where I am using code from some third party open source product's "client logic" but they haven't provided a clean set of client API objects. Their complete set of code goes server-side, but I only need the necessary client bits.
This would seem a common issue but I haven't seen anything (e.g. in Eclipse) which helps with this. Am I missing something?
Of course I can still do it manually by: biting the bullet and including all the third-party code in a massive JAR (offending my purist sensibilities) / source walkthrough / trial and error / -verbose:class type stuff (but the latter wouldn't work where, say, my code runs as part of a J2EE servlet, and thus I only want to see this for a given Tomcat webapp and, ideally, only for classes related to my classes therein).
I would recommend using a build system such as Ant or Maven. Maven is designed with Java in mind, and is what I use pretty much exclusively. You can even have Maven assemble (using the assembly plugin) all of the dependent classes into one large jar file, so you don't have to worry about dependencies.
http://maven.apache.org/
Edit:
Regarding the servlet, you can also define which dependencies you want packaged up with your jar, and if you are making a stand alone application you can have the jar tool make an executable jar.
note: yes, I am a bit of a Maven advocate, as it has made the project I work on much easier. No I do not work on the project personally. :)
Take a look at ProGuard.
ProGuard is a free Java class file shrinker, optimizer, obfuscator, and preverifier. It detects and removes unused classes, fields, methods, and attributes. It optimizes bytecode and removes unused instructions. It renames the remaining classes, fields, and methods using short meaningless names. Finally, it preverifies the processed code for Java 6 or for Java Micro Edition.
What you want is not only to include the classes you rely on but also the classes, the classes you rely on, rely on. And so on, and so forth.
So that's not really a build problem, but more a dependency one. To answer your question, you can either solve this with Maven (apparently) or Ant + Ivy.
I work with Ivy and I sometimes build "ueber-jar" using the zipgroupfileset functionality of the Ant Jar task. Not very elegant would say some, but it's done in 10 seconds :-)