Zero dependencies

[mishako]

Pros

• Saves users from dependency hell

Cons

• Harder to develop without libraries

Not sure about slf4j. I don't think I ever wanted my libraries to log anything. But I see how it can be useful for debugging. Maybe use built-in java logging? Guava seems to be doing it.

What about Java's built-in XML capabilities? Does it have everything we need for XML reading and writing? Is Jdom used in Rome only for convenience?

What about JSON Feed? Can we support reading and writing JSON without libraries?

I guess in worst case we can shade and relocate dependencies.

[imk]

I would prefer minimal dependencies over zero dependencies. We should restrict the use of third party libraries to a minimum but we shouldn't reinvent the wheel too much :-)

What we imho shouldn't do: shade and relocate dependencies. When using third party libs, this should be transparent and the user should be able to update a dependency to a compatibel older or newer version without a new Rome release. Especially if there are some vulnerabilities in a dependency, the users should be able to update to the next minor version with the required security fixes.

For some aspects we could follow the approach @PatrickGotthard proposed: Define the dependency as provided, so we can compile against it but it isn't a dependency for the user and activate these functions when we detect that a lib is available at runtime. Of course, that's a little bit dangerous because when you're using something from such an optional lib without checking before if it's really available, you're getting a ClassNotFoundException or something like this at runtime.

XML reading and writing

Jdom had been used because of convenience, it's just simpler to use than org.w3c.dom but I don't know anything that can be done with jdom and not by org.w3c.dom. I don't think we need jdom.

Using one of the other standard java xml approaches like SAX or Stax may be a bit more challenging, at least when integrating modules. It's easier to pass an Element around and every module can read the data it's interested in instead of finding the matching module for every xml event when reading the data (node start, node end, attribute ...).

For android, the use of xml pull parsers instead of dom parsers is recommended because of resource consumption. But Android isn't using the stax API for pull parsers, so we would have to use different APIs for pull parsers on Android and on regular java. But the DOM-API is the same.

So using javax.xml.parsers.DocumentBuilderFactory and org.w3c.dom.* should work on both and we should be able to do everything Rome 1 with jdom can do today.

JSON support

There's an Java JSON Standard today (Java API for JSON Processing) but additional jars are required to use it, so for JSON support, we have to reinvent the wheel or add dependencies.

Logging

There are many discussions about what logging framework to use (or use a framework at all), slf4j, log4j or logback had been created because of JULs deficiencies, I think that's a good overview about the discussion: https://stackoverflow.com/questions/11359187/why-not-use-java-util-logging

For some libraries (like guava), logging really doesn't make too much sense: most of the classes or methods are called and either they're succeeding (no need for logging) or there's an error and I'm getting an exception, so I know what's wrong.

For more complex operations (like parsing a feed), it would be helpful to know that there had been some problems (like some invaild values in the feed that had been ignored). Finding this in logs would be nice. But if there's a programmatic way to get these infos (like the proposed feed.errors()), the user of course can do the logging of those infos himself.

What would be the price of logging via slf4j? Not too high, I haven't seen an application in the last years not allready depending on slf4j. Even when depending on slf4j, no one is forced to use it. There's just a note on startup that there's no logging implementation available. There's an android implementation too.

[mishako]

@imk Thanks for detailed response. This will be extremely helpful!

I think the price of using slf4j is our contribution to dependency hell:
https://duckduckgo.com/?q=dependency+hell+%22slf4j-api%22

[imk]

@mishako After looking again at the API proposals etc, I think there's really no need for logging inside of Rome. When you (as a user of Rome) are interested in the internals:

• you can activate Features.SAVE_ERRORS and have a look at these after parsing the feeds or log them however you want.
• When there's a problem we just can't handle inside Rome, there should be an exception thrown, so you can handle it (and log it if you want)
• When you want to see what had been to original String for parsed values, you can look at the original String values in the value wrappers for Dates etc. (and of course, you can log them, if you want)

All these places where logging in Rome may be of interest can be handled by the proposed API. So logging inside Rome is imho dispensable.

[mishako]

Looks like android has a JSON parser: https://developer.android.com/reference/org/json/JSONObject.html
So potentially we could parse both XML and JSON on android without any additional libraries.

[imk]

For json, android has better native support than regular java :-)

[mishako]

It's hard to conclude anything here before we've tried out different options in the prototype, but some things are clear:

• We want minimal number of dependencies.
• There is XML support both in java and android.
• There is no JSON support in java and we don't want to implement it. We will have to pick a JSON library and ask our users to provide it in the runtime (only if they want to read or write JSON feeds of course).