I'm very new to java. starting from yesterday! i installed eclipse and imported spring libraries inside it. but a weird problem happened. in import statement there was an error telling The type org.springframework.context.ApplicationContext is not accessible. after running the project another error happened (related to same subject ApplicationContext cannot be resolved to a type).
Anyway! i was confused. it took one day for me. searching forums such as stackoverflow and googling didn't resolve my problem. suddenly i saw a popup message in eclipse suggesting some solutions. ignoring some worthless one of them was adding module to module-info.java file. unbelievably that solved the problem! strangest thing was that i never saw this solution in related forums! and most annoying thing is that what if i never saw that popup? where did i do a mistake? and why this solution doesn't exist on the internet?
Lots of thanks!
Java modules are a new feature of Java 9; they allow you to specify exactly which dependencies you need for your program, hence allowing greater control of the size of your application - no need to bring along library code you don't use. That seems to imply that you need to explicitly say what you want, I guess so that you realise that you are pulling in more modules.
So the reason that you don't see much information about modules in general is that they are comparatively new and doubt that I'm alone in being a long-standing Java developer who has never seen a module-info file!
I wonder whether Eclipse gave you some options when you were creating your project and you inadvertently took an option meaning "yes I want the extra control of doing mocules and I don't mind doing a bit more work."
Related
In my case there are two reason for doing that:
Sometimes people by mistake import classes which present in macbooks JDKs but absent in Linux. That causes build to fail on ci servers which are Linux based boxes. I doesn’t happen frequently, but when it does happened I'm thinking that there should be some smarter way to find out that earlier.
Unused imports trigger warning in IDE/code analysis. From time to time somebody need to spend time on cleaning up this stuff. Even if its just single right click in IDE you still need to commit your changes and make sure everything alright on build.
I'm curious if there is any way to find unused imports programmatically (lets say from unit test) and fail locally if there are any.
Maybe failing a build because of unused import sounds harsh, but if it saves time for team overall it makes sens to do so (would love to hear opinion on that as well).
UPDATE:
I followed yegor256 suggestion and incorporated Checkstyle task with initially small subset of Sun Code Conventions (unused imports is one of them) and made it break a build if violations found.
After one week of trial we've got zero unused imports in our codebase and surprisingly zero complaints about this rule (by the way, Checkstyle is really fast: analyzing ~100KLoc taking less than one second).
As for using IDE for such analysis: yes, it good choice, but having this kind of checks run as part of automated build is better.
What you're trying to do is called static code analysis. Checkstyle can help you. If you're using Maven, this plugin will do the automation for you: http://maven.apache.org/plugins/maven-checkstyle-plugin/
You can also take a look at qulice.com (I'm one of its developers), which integrates a few static analysis tools and pre-configures them (incl. Checkstyle, PMD, FindBugs).
If you are using eclipse IDE or IntelliJ IDEA, you can configure them to
1a. organize imports / remove unused imports on save or before commit (see cleanup preferences)
1b. switch the "unused imports" warning to an error (see error settings)
2a. configure a jre which does not include com.* stuff
2b. configure the warning of proprietary api usage from the jre to be an error
You might still want to check that on the build server, though. In this case the more complicated stuff like configuring CheckStyle would still be necessary.
I'm curious if there is any way to find unused imports programmatically (lets say from unit test) and fail build locally if there are any.
I use IntelliJ to organise imports, this removes all the unused imports. You can do this with one hot key from the top of you code base to correct all the imports. (It also has over 700 other types of static checks and fixes)
Maybe failing a build because of unused import sounds harsh, but if it saves time for team overall it makes sens to do so (would love to hear opinion on that as well).
I have IntelliJ check in code which formatted and with imports organised so the issue never arises in the first place. ;)
In Computer Science the name given to such a process of analyzing the code without executing is known as static code analysis.
Try using an IDE, I am using Eclipse, which marks all the Unused imports and Unused Variables or methods in with a Yellow color underline....
Aren't these unrelated questions? If you import classes only present in the local JDK, these imports are used (just unsatisfied). For either problem, I recommend solving it in the IDE so the problem will be detected when code is written, rather than prior to checkin (the earlier the detection, the easier the fix ...).
In eclipse, you could prevent unsatisfied imports with access rules, and automatically fix imports whenever a source file is saved by enabling the appropriate save action. If you check these settings into version control, you can easily share them with the team.
I see lot of comments in same way that use this IDE or that IDE. But all my friends try to understand the difference. Doing something programmatically is different and using IDE is different.
If I want a process to be programmatic then suggestion of IDE is not useful. It might be possible some one is asking this question because he is building complete process and this step is part of it. How opening IDE would help him on different machines and OS where CI is working?
I too building one tool on similar lines. I achieved it up to some level but it programmatically open IDE and close it automatically and fixes source code too. But opening same in Linux might be a question for me.
Understanding some one's view before answering is really very important.
I'm working on a library and I would like to have the class Node. Most of the times it works fine but sometimes it gives the error Node cannot be resolved to a type on every place where I use a node.
The strange thing is that if I rename the class to DNode, for example, and rename every Node to DNode and then change everything back again to just Node, it's like the way it was before but the errors saying Node cannot be resolved to a type are gone (until a certain time).
Compiling is also no problem btw, it seems to be an Eclipse bug or something.
I know there is this Node class, but I don't import it so I can't see why that would form a problem.
I hope someone can help.
I've seen similar behaviour in the past and know of two possible reasons:
Your build path has somehow changed, leaving out your Node class, or the project providing it has compile errors, or similar. Given your description of the problem, this probably isn't relevant in your case.
Some Eclipse screwup. For me, this was always solved by doing a clean build of the project (possibly also any dependent projects) at which point things resolved themselves. You can do this by going to the Project menu and selecting Clean. This isn't a proper solution, but strikes me as quicker than your Node->DNode->Node workaround.
It seems several people described this problem (and a solution) a few years ago. For example, this describes the problem and found that doing a Refresh in Eclipse fixed it. In his case, he caused the problem by creating a top-level folder in his Eclipse Project directory - outside of Eclipse. It sounds like an Eclipse bug that's been there for a few years.
The problem scienario is as follows (Note: this is not a cross-jar dependency issue, so tools like JarAnalyzer, ClassDep or Tattletale would not help. Thanks).
I have a big project which is compiled into 10 or more jar artifacts. All jars depend on each other and form a dependency hierarchy.
Whenever I need to modify one of the jars, I would check out the relevant source code and the source code for projects that depend on it. Modify the code, compile, repackage the jars. So far so good.
The problem is: I may forget to check one of the dependent projects, because inter-jar dependencies can be quite long, and may change with time. If this happens some jars may go "out-of-sync" and I will eventually get a NoSuchMethodException or a some other class incompatibility issue at run-time, which is what I want to avoid.
The only solution I can think of, the most straighforward one, is to check out all projects, and recompile the bunch. But this takes time, especially if I re-build it every small change. I do have a continuous integration server, that could do this for me, but it's shared with other developers, so seeing if the build breaks is not an option for me.
However, I do have all the jars so hypothetically it should be possible to verify jars which depend on the code that I modified have an inconsistency in method signature, class names, etc. But how could I perform such check?
Has anyone faced a similar problem before? If so, how did you solve it? Any tools or methodologies would be appreciated.
Let me know if you need clarification. Thanks.
EDIT:
I would like to clarify my question a little bit.
The ultimate goal of this task is to check that the changes that I have made will compile against the whole project. I am looking for a tool/technique that would aid me perform such check.
Consider this example:
You have 2 projects: A and B which are deployed as A.jar and B.jar respectively. A depends on B.
You wish to modify B, so you check it out and modify a method signature that A happens to depend on. You can compile B and run all tests by itself without any problems because B itself does not depend on anything. So you happily commit your changes.
In a few hours the complete project integration fails because A could not be compiled!
How do I avoid this?
The kind of tool I am looking for would retrieve A.jar and check that all dependencies in A on the new modified B are still fine. Like a potential compilation error that would happen if I were to recompile A and B sources together.
Another solution, as was suggested by many of you, is to set up a local continuous integration system that would recompile the whole project locally. I don't mind doing this, but I want to avoid doing it inside my workspace. On the other hand, if I check-out all sources to another temporary workspace, then I need to mirror my local changes to the temporary workspace.
This is quite a big issue in my team, as builds break very often because somebody forgot to check out (or open in Eclipse) the right set of projects. I tried persuading people to check-out source and recompile the bunch before commits, but not only it takes time, it needs running quite a few commands so most people just find it too troublesome to do. If the technique is not easy or automated, then it's unusable.
If you do not want to use your shared continuous integration server you should set up a local one on your developer machine where you perform the rebuild processes on change.
I know Jenkins - it is easy to setup (just start) on a local machine and I would advice to run it locally if no one is provided in the IT infrastructure that fits your needs.
Checking signatures is unfortunately not enough. Having the correct signatures does not mean it'll work. It's all about contracts and not just signatures. I mean what happens if the new version of a library has the same method signature, but accepts an ArrayList parameter now in reversed order? You will run into issues - sooner or later. I guess you maybe consider implementing tools like Ivy or Maven:
http://ant.apache.org/ivy/
http://maven.apache.org/
Yes it can be pain to implement it but once you have it it will "guard" your versions forever. You should never run into such an issue. But even those build tools are not 100% accurate. The only proper way of dealing with incompatible libraries, I know you won't like my answer, is extensive regression testing. For this you need bunch of testing tools. There are plenty of them out there: from very basic unit testing (JUnit) to database testing (JDBC Proxy) and UI testing frameworks like SWTBot (depends if your app is a web app or thick client).
Please note if your project gets really huge and you have large amount of dependencies you always not using all of the code there. Trying to check all interfaces and all signatures is way too much. Its not necessary to test it all when your code use lets say 30 % of the library code. What you need is to test what you really use. And this can be only done with extensive regression testing.
I have finally found a whole treasure box of answers at this post. Thanks for help, everyone!
The bounty goes to K. Claszen for the quickest and most input.
I'm also think that just setup local Jenkins is a best idea. What tool you use for build? Maybe you can improve you situation with switching to Maven as build tool? In more smart and don't recompile full project if you don't ask it directly. But switch to in can be HUGE paint in the neck - it hardly depends on how you project organized now...
And about VCS- exist Mercurial/SVN bridge - so you can use local Mercurial for you development ....
check this link: https://www.mercurial-scm.org/wiki/WorkingWithSubversion
There is a solution, jarjar, which allows to have different versions of the same library to be included multiple times in the dependency graph.
I use IntelliJ, not Eclipse, so maybe my answer is too IDE-specific. But in IntelliJ, I would simply include the modules from B into A, so that when I make changes to A, it breaks B immediately when compiling in the IDE. Modules can belong to multiple projects, so this is not anything like duplication, it's just adding references in the IDE to modules in other projects.
a simple question but Ive realised im not sure of the answer for this one....
If I am creating an android application with a library package named
com.example.one
and then i create another app and include another package with the name
com.example.one
which has a slightly refactored class, could this cause any problems in either of the apps?
The reason i ask is recently I had a problem with some google source code and it was down to the fact that a device manufactorer had included the same libs in the custom OS that I had used in my apk, and it was not happy! (or so i was told)
If anyone can fill me in here, as i obviosuly dont understand something quite findamental here :)
thankx
EDIT: a good link on the diff between Android and Java package names http://blog.javia.org/android-package-name/
The classloader can't load two versions of the same class. It picks just one. But which one gets picked is undefined. So yes - it causes troubles.
Some platforms (java-ee) have options to specify jar precendence for these cases. I don't know about android.
Update: If my initial understanding is not correct, i.e. you are not having the same jar (library) twice on the classpath, but instead are starting 2 separate apps with different versions of the jar - then they won't interfere with each other (and hence no problems)
Actually, it shouldn't cause problems in the case of two separate Android apps. Android Apps run in Sandboxes, i.e. the Classloader of app A does not see any classes of app B and vice-versa.
This is obviously different for system wide-libraries. They are accessible by the classloader (of course) and will cause troubles if you have the same class in your app.
Yes, this can cause problems, but only if you have classnames that conflict within the package.
This doesn't seem to be an issue with your app though as you have two apps and two libraries (see answer from LordT)
Any easy workaround is to include the the app/library name in the package. For example:
com.app1.example.one
com.app2.example.one
That eliminates confusion & interference between the two packages.
I have a rather complex J2EE app I don't have any documentation for and I am trying to get it to run.
I have gotten the ant build script to compile a EAR file that contains a WAR file, but this application even though I get "successfully deployed" on weblogic console is still not working.
There are many required jars missing from the EAR file, hence I get errors about missing classes on the console log when I deploy the app. Sometimes even after I check a particular class is there I still get the error.
What is a best way to debug and get this application running?
Is there any shortcuts in J2EE/Java to "find all dependencies", apps anybody knows to analyze code and find dependencies or anything like that?
Is there any shortcuts in J2EE/Java to "find all dependencies", apps anybody knows to analyze code and find dependencies or anything like that?
Do you mean a compiler? I'm actually semi serious here (even if the compiler won't give you the name of a missing JAR). Indeed, if you are compiling that application successfully with Ant, then you likely have all dependencies required at compile time (you may need more of them at runtime but, well, you'll need to execute the code to identify them). Maybe you just need to add more of them in the EAR during the packaging. Or maybe you need to add more dependencies at the app server classpath level.
In both case, search engines like jarFinder.com or Docjar.com or Jarhoo.com might help you to identify missing JARs and to solve your ClassNotFoundException or NoClassDefFoundError.
You should actually give readers more details about the missing classes, I'm sure people will be able to give you some hints and point you in the right direction.
I know of no easy way to deal with this. If the application provides an ant task build the EAR then the result should be a self-contained deployable application EAR. It is possible that the EAR requires extra libraries to be added to some class path, without documentation it's really hard to know what.
This phrase is, I guess, at the heart of the problem: "Sometimes even after I check a particular class is there I still get the error." Exactly what do you mean?
You are getting a class not found error but you can see the class in the EAR file? If that's the case then things are really difficult, and may well be some kind of classloader issue. I don't know WebLogic at all, but in WebSphere when deploying an application you have a choice of whether to give precedence to JARs in the EAR or to the same JAR in WebSphere itself. Some Applications demand one or the other setting. If there's anything like that in WebLogic then this may be your problem.
Another possible problem is that the app may depend on infrastructure libraries (Eg. XML parsers) that are supplied by WebLogic, but expects a different version that is supplied with the WebLogic version you are using.
Without documentation that the app is supported on the version of WebLogic you are using, I fear you're fighting a long, hard (or even a losing) battle.
I'd assume you managed to get this application put together and compiled in an IDE, maybe Eclipse. Why not simply put all the Jars that you had available at build time, into the EAR?
If you're having to debug this by trial and error, you can look at the list of missing classes and figure out which jars they belong to by Googling for the class names, or maybe you can find them in your IDE too.
If you have a lot of trouble identifying some classes, post the class names (or the error messages) here and someone should be able to tell you where to find the Jar it belongs in.
If you are able to successfully build and deploy the app, but still getting the errors about missing classes, probably some of the jar classes are called through reflection. You may want to search for reflection API calls in the Project through your IDE.
These calls may be something like,
"Class cls = Class.forName(..); cls.newInstance()."
Sometimes even after I check a
particular class is there I still get
the error.
This may be a deployment issue. check the classpath. Some of the jars may be missing from the Classpath.
Is there any shortcuts in J2EE/Java to
"find all dependencies", apps anybody
knows to analyze code and find
dependencies or anything like that?
I'd start by having another go at getting documentation ... or help ... from the original developers, if you can find them. [IMO, people who develop / provide software without any documentation deserve to be bugged incessantly by people asking silly questions.] But I guess you've already tried that.
Then there are the jarfinder.com and other services as mentioned in another answer. (New to me!)
If that fails, I'd try doing a Google search on the FQNs. The chances are that if the missing classes are part of a commonly used library you will hit the Javadocs ... or a posting from someone else with a similar problem to yours.
If the "Google it" approach fails, use the clues in the package naming for the missing classes to try and find where they come from. If they follow the Sun recommendations, the names should map to a company or (real or pseudo-) organization that you can locate by a web search.