When exploring a code, sometimes you end up in a decompiled code from a JAR for which there’s no source code attached. Previously you had to:
- 1. go find the source JAR on the Web
2. download it to your disk
3. go to your project structure settings
4. attach the JAR to the library of interest
A bit too much, isn’t it? Now (in the next EAP) IntelliJ IDEA 11 does it all for you:
This is the best thing ever!
Guys, you do not seize to amaze me every time I think that there’s nothing more to be done to improve the Java development experience. This is awesome.
Pretty amazing that you can still find ‘wow, how obvious now that I see it’ kind of features still. Nice work.
Is it configurable? What libraries will be supported from out-of-box? Could list automatically updated from the server?
Joining xBlackCat: How does the tool know where to download the sources from?
How do you know which sources to download (e.g. when multiple versions exist)? Do you calculate some kind of signature of the local jar and then compare it to the signature of the jar in repository to figure correct sources?
Igor, we just get version and artifact ID from jar’s name.
Yes. If class file is located say in some-component-3.2.jar then sources for version 3.2 will be downloaded. Also, there is another quick fix available in IntelliJ IDEA 11 – you can find, download and setup a library for “red code” like shown here http://go.stalk.ru/psR7di
Hi, this is cool. However does this feature will manage sources not packaged in the maven way. For example the source jar of CGLIB 2.2.2, which is downloaded from central, you have to point to the correct folder in the jar to get the root of the sources :
cglib-2.2.2.jar/src/proxy
Anyway, thx for this feature
please also support specifying the source location (artifactory repository, for example) for us guys on disconnected network environments
Now, if only there was a decent decompiler bundled, that alone would justify an upgrade to version 11 for me. I gave up using decompiler plugins, because they have never worked correctly. Now I am using jd-gui whenever I need to have a look at decompiled sources, but I really really wish it was part of IDEA.
Excellent. Reminds me the function
nality I developped with my team in a now defunct plugin (worldofjava). But we used the jar md5 to identify it (relying on the name is error prone IMHO).
As vaguely suggested above, finding/downloading the jar using the local copy’s checksum would be pretty neat, as it could also work for non-mavenized artifacts.
@sergei_ivanov
Agreed, a good decompiler plugin would be awesome.
For information JD-GUI is available here http://java.decompiler.free.fr/ as well as the eclipse plugin.
Brice, of course we support this case. Sources for cglib-2.2.2.jar will be added correctly.
@Sergey Cool, that’s awesome. I got the case again in my maven project on the source artifact of stripes.
@Sergey
Nice feature, thanks. Instead of version and artifact ID from name (sometimes version is missing in the name or it is not maven-like), maybe SHA1 checksum could also be used to identify a jar (groupId/artifactId/version) and find sources…
I like this jarfinder plugin. The only problem I have is that its not fetching sources for me at work (behind a firewall/proxy).
2012-01-24 15:27:02,827 [ 57407] WARN – #com.intellij.jarFinder.SonatypeAttachSourceProvider – Connection timed out: connect
java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:564)
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:141)
at sun.net.NetworkClient.doConnect(NetworkClient.java:163)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:395)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
at sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:272)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:329)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:172)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:911)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
at com.intellij.jarFinder.SonatypeAttachSourceProvider$1$1.readDocumentCancelable(SonatypeAttachSourceProvider.java:212)
at com.intellij.jarFinder.SonatypeAttachSourceProvider$1$1.run(SonatypeAttachSourceProvider.java:124)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$TaskRunnable.run(ProgressManagerImpl.java:457)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$5.run(ProgressManagerImpl.java:276)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$2.run(ProgressManagerImpl.java:178)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:206)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.runProcess(ProgressManagerImpl.java:169)
at com.intellij.openapi.application.impl.ApplicationImpl$8$1.run(ApplicationImpl.java:629)
at com.intellij.openapi.application.impl.ApplicationImpl$6.run(ApplicationImpl.java:422)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:137)
Now all we need is to be able to configure which repos it looks in. Sonatype’s repo is pretty good, but they are versions behind on some dependencies. Predictably enough, the exact ones I’m interested in.
+1 on being able to configure the repo to Sonatype alternatives.
how do you know what the extension is to the name. most times it’s sources but not always. do you just try a bunch?
This would be a great feature (if it was actually reliable), but alas it is not (reliable). For most legacy apps (which is 98% of the work in the IT world) the jars are available but the sources are not or they are now supported by a different group, so you must go find them and download them to your machine anyway.
you can download the jar files from this site http://jar-download.com/ by pasting the maven xml