Why do i need library file with -sources suffix? - java

I don't understand why there are often two files in libraries, one with -sources suffix.
Here's what i mean

The sources are useful if you want to step into the library when debugging. You don't need them, but they might save you if you can't understand why the library behaves in a certain way.

To add to the answer below, the -source archive is the actual source code, while the other file is the compiled version of it.

Related

Is there a way to use external libraries in IntelliJ without downloading their .jars?

I am trying to write a standalone Java application in IntelliJ using edu.stanford.nlp.trees.GrammaticalStructure. Therefore, I have imported the module:
import edu.stanford.nlp.trees.GrammaticalStructure;
Currently, Intellij doesn't recognize this and many others of the imported external libraries (cannot resolve the symbols) and is also not able to automatically download/import them.
Is there a way to use the GrammaticalStructure class without having to download the entire Stanford CoreNLP .jar and adding it to the project as a library? This question applies to other dependencies as well, since I want to use other external libraries but avoid including their .jar files as much as possible (to minimize the size of the final application, given that it will be standalone). Unfortunately, all the solutions I have found proposed exactly that.
Apologies if I have overlooked some basic setting or setup steps, it has been a while since I have worked with Java.
Any help is greatly appreciated.
If you want to use it means you want to execute the code in them. How is the runtime supposed to execute code that is does not have? How is the compiler supposed to know how the code is defined (e.g. what the classes look like)? This is simply impossible. If you want to use the code you have to provide it to the compiler as well as the runtime.
If you just dont want to include all of that code into your application, you need either access to the sources and just pick the class you need or you need some kind of JAR minimizer as #CrazyCoder suggested.

What are the criteria(in the programming point of view) that one should keep in mind while creating a java jar(as library) file for android

I know how to create a jar file using Eclipse.
I was trying to create a share library so that I can avoid redundant source code. I have figured out that a jar should be :-
independent
should not make call to external class attributes(properties)/methods except the standard library imports.
The resources should be given as a parameter to jar file to perform a action.
Should work as a independent entity.
I tried to well organised my code in different packages also added MANIFEST.MF file.
This is first time I'm trying for data abstraction.
I would like to request suggestions/instructions as per the programmer point of view, what are the criteria that jar code should have ?
Is it good idea that my jar is or depend on another jar (viz java mail api jar) ?
Thanks in advance.
As you've tagged this with Android, I assume that Android is the intended use case.
The easiest way to share your code between several projects is probably to create a library project, this way you can keep the source code at hand too (less convenient to attach source to the jar every time you use it).

Downloading part of guava-libraries

Current version (14.0.1) of guava-libraries is 2 MB. It is not huge, it is not small neither. Especially when I want to use it in an exemplary project for my students and only need "Strings" part of it for parsing some input.
Are there any smaller parts of Guava available as JAR-s with compiled code, or I have to use all of it, or compile and prepare my own bundle (e.g. using ProGuard)?
According to Maven Repository there does not seem to be any smaller jar files that the Guava library is depending on.
So I would say no, there are no smaller portions of the Guava library that you can use. You will have to build your own jar files with only the classes you need.
So ProGuard seems to be the right solution for you.

Is it possible to edit a pre-existing .class file from within my program?

This may seem like an odd thing to ask, but it'd take me forever to explain why I need it...
What I need is a way to edit a pre-existing Java .class file within its JAR file, with either a command prompt, or within my Python program. I need it to happen automatically, once the user pushes a button.
I have absolutely no clue how to do this, or if it's possible.
A jar file is a zip package, you need only to extract the file, edit the content and put it back. The harder part is how to edit the .class file. The java .class file is a binary format , there're several libraries may help you.
Yes you can do this. Now how you gonna do it depends upon what you want to do. For your cross-cutting issues look at AspectJ. Using AspectJ you can add your custom code even after the class is compiled.
You have a problem with this approach, if the class has already been loaded by a JVM classloader, as it may not actually reread the .class file again until the application has been rerun.
I know that there exists the BCEL but I've not used it, so I dont know if it can be used a) from python, or b) during runtime.
EDIT: Actually, Jeffrey's list is better as it provides a much more comprehensive list of Byte Code manipulators.

How to modify the class file?

I was working on the project in eclipse in which I have added this maven dependency for PDFBOX
Maven dependency
<dependency>
<groupId>org.apache.pdfbox</groupId>
<artifactId>pdfbox</artifactId>
<version>1.6.0</version>
</dependency>
And I was getting the error on some pdf file as:
Parsing Error, Skipping Object
java.io.IOException: expected='endstream' actual='' org.apache.pdfbox.io.PushBackInputStream#1b8d77fe
at org.apache.pdfbox.pdfparser.BaseParser.parseCOSStream(BaseParser.java:439)
at org.apache.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:552)
at org.apache.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:184)
at org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:1088)
at org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:1053)
at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:74)
at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:197)
at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:197)
at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:135)
at org.apache.tika.Tika.parseToString(Tika.java:357)
at edu.uci.ics.crawler4j.crawler.BinaryParser.parse(BinaryParser.java:37)
at edu.uci.ics.crawler4j.crawler.WebCrawler.handleBinary(WebCrawler.java:223)
at edu.uci.ics.crawler4j.crawler.WebCrawler.processPage(WebCrawler.java:460)
at edu.uci.ics.crawler4j.crawler.WebCrawler.run(WebCrawler.java:129)
at java.lang.Thread.run(Thread.java:662)
So when I google it, I found there was some bug in BaseParser.java file, So they have given the patch(https://issues.apache.org/jira/browse/PDFBOX-195) for this java file only.. So my question is how can I modify this java file only.. I can see the BaseParser.class file in eclipse as I have attached the source doc for that PDFBOX-Issue. Any suggestions will be appreciated.
Given that BaseParser.java is an Apache file, there is absolutely no reason why you cannot download the source, make your changes and re-compile it. I have done this with Apache code in the past. It was pretty straight forward and took me only a few minutes. Remember to submit your fix back to Apache so that way it will be included in the release.
You can:
create subclass manual (and use it if it possible)
download source, fix it, recompile, and finally, overwrite it in jar
create subclass programmaticly (using cglib or asm)
download only BasicParser, mock all depends (just create empty class files with needs methods), recompile it and put in jar (or ./ext ./endorsed dir in jvm, if you want)
Generally, one doesn't modify a class file directly, they download the source code and then rebuild the class file with javac. Yes, it is possible to modify class files without doing such a thing; but, patch files are not generally binary patch files, they are generally source code patch files.
Stefanglase has mentioned that the release you are working with should have the patch applied, but there is a small chance that a recent change reintroduced the issue. You might want to verify that you're not solving the wrong problem before you get too deep into it.
On the rare odds that you really want to modify a binary, you open it with a hexadecimal editor, or a hexeditor for short. Basically this allows you to set any byte in the file to any value, which means you must have a strong knowledge of the file's internal format, what is allowed / disallowed, and how to make allowable changes that actually implement your expected behavior. In short, you'll be doing a compiler's work manually, by hand.
It can be done, but it is the sort of task that generally requires a lot of knowledge, and few people have that knowledge already, so the costs of learning that knowledge and successfully implementing the change is likely much higher than rebuilding from available patched source. Even the costs of successfully implementing the change with the knowledge of the general principals and techniques already present isn't something that one can say with certainty is less than the costs of rebuilding the entire library with patched source.
Good Luck.

Categories