I'm developing some Kotlin libraries and I have the following conceptual issues:
The first library is based on spring's classpath scanner and is intended for use as a spring extension, so it pulls spring-core as a dependency. Is this ok? How would the potential user of my library handle different spring versions?
The second library is based on first and it is intended for use in p2p networks. It synchronizes with other peers and provides a shared state that can be easily retrieved by library user using special pre-defined spring service. Is this ok for a library to have side effect like this? Maybe there are some patterns for implementing/distributing such libraries?
If this is not ok, can you please guide me how to do this right.
Thanks in advance.
This is a bit general question, and having concrete examples would help understand if that's "okay" or "not okay" to do it.
But generally speaking:
It's fine if your library depends on other libraries of specific versions. Most of the libraries do. The question is how heavy and obtrusive this library you depend on is. And unfortunately for you, Spring libraries are known to be both. In case of the end-user of your library, in case of conflicts he'll simply have to choose whether he wants to update his Spring version for your library or not
Having some distributed state is not necessarily a side effect. EhCache is a distributed cache library, for example. The basic pattern is to be as SOLID as possible. When I developed caching for Vert.x WebClient library, I made it rely on interfaces instead of solid implementation, so if someone decides he doesn't want to use your library (Spring component, for example), he could provide an alternative solution.
Again, those are basic guidelines, without seeing your code. If you intend to open source it, feel free to share specific bits to get more concrete insights from StackOverflow community.
Related
I have very general question about managing android library project and I feel it might have pretty simple solution. The library might be used as a base program for other projects, like framework but It could be better described as a group of functionalities that are the same - just to save time.
Lets say we have project where we decide to distinguish base part which is exported as library.
Those library contains activities, network utilities, some preferences and database schema(!).
Is there any pattern how to do this, is it a good idea to do this with database too?
I mean actually I've got the library but almost every method that is dependent from other one has to be overridden what causes to override almost everything.
Maybe the system should be designed with specific cohesion strategy?
Thanks
I've read up on Jonathan Oliver's .NET EventStore library, and I must say the concept appeals to me a lot: having just a simple no-dependencies library which is non-intrusive and just focuses on event sourcing, leaving a lot of freedom when choosing technologies for databases, messaging, etc.
My question: Is something similar also available in the Java world? I know there are all kind of CQRS-related frameworks, like Axon and Jdon, but those do a lot more than just event sourcing... Anyone working on a straightforward port, perhaps?
I'm not aware of any that exist. At the same time, it wouldn't be terribly difficult to write one. The hardest part for me in writing the EventStore was arriving at the correct model. I had two private/internal releases within my company, and then two public releases before I was really satisfied with how things turned out. There are a few Ruby ports and other languages as well, and usually they take a few hours to write because the authors copy the model. If you take the same approach, I don't see why you couldn't write your own within a few hours.
I realize the question is old, but for those in a similar position now:
you could try Greg Young's EventStore (http://geteventstore.com)
It needs .NET or mono to run but there is a JVM-based client library:
https://github.com/EventStore/eventstorejvmclient
You could have a look at Occurrent which is designed to be used as a library. This means that you can use only the event store, and nothing else, and add more components when you find fit.
It's also designed to integrate well with popular frameworks such as Spring Boot if you want to use a framework on top (without necessarily having to use framework-specific code in your domain model).
In theory, it could support messaging, but appears to only support databases currently.
Using JDBC is not that much of an imposition and can wrapped up to suit your needs fairly easily. If you want simplicity, I would use JDBC.
If you want to support JMS (messaging) I would use only that (with an adapting service to any database you want to use) This gives you simple standard event driven interface for all types of messaging (and any database you connect to)
I was just about to include the HtmlUnit library in a project. I unpacked the zip-file and realised that it had no less than 12 dependencies.
I've always been concerned when it comes to introducing dependencies. I suppose I have to ship all these dependencies together with the application (8.7 mb in this particular case). Should I bother checking for, say, security updates for these libraries? Finally (and most importantly, actually what I'm most concerned about): What if I want to include another library which depends on the same libraries as this library, but with different versions? That is, what if for instance HtmlUnit depends on one version of xalan and another library I need, depends on a different version of xalan?
The task HtmlUnit solves for me could be solved "manually" but that would probably not be as elegant.
Should I be concerned about this? What are the best practices in situations like these?
Edit: I'm interested in the general situation, not particularly involving HtmlUnit. I just used it here as an example as that was my current concern.
Handle your dependencies with care. They can bring you much speed, but can be a pain to maintain down the road. Here are my thoughts:
Use some software to maintain your dependencies. Maven is what I would use for Java to do this. Without it you will very soon loose track of your dependencies.
Remember that the various libraries have different licenses. It is not granted that a given license works for your setting. I work for a software house and we cannot use GPL based libraries in any of the software we ship, as the software we sell are closed source. Similarly we should avoid LGPL as well if we can (This is due to some intricate lawyer reasoning, don't ask me why)
For unit testing I'd say go all out. It is not the end of the world if you have to rewrite your tests in the future. It might even be then that that part of the software is either extremely stable or maybe not even maintained no more. Loosing those is not that big of a deal as you already had a huge gain of gaining speed when you got it.
Some libraries are harder to replace later than others. Some are like a marriage that should last the life of the software, but some other are just tools that are easily replaceable. (Think Spring versus an xml library)
Check out how the community support older versions of the library. Are they supporting older versions? What happens when life continues and you are stuck at a version? Is there an active community or do you have the skill to maintain it yourself?
For how long are your software supposed to last? Is it one year, five year, ten year or beyond? If the software has short time span, then you can use more to get where you are going as it is not that important to be able to keep up with upgrading your libraries.
It could be a serious issue if there isn't a active community which does maintain the libraries on long term. It is ok to use libraries, but to be honest you should care to get the sources and put them into your VCS.
Should I bother checking for, say, security updates for these libraries?
In general, it is probably a good idea to do this. But then so should everyone upstream and downstream of you.
In your particular case, we are talking about test code. If potential security flaws in libraries used only in testing are significant, your downstream users are doing something strange ...
Finally (and most importantly, actually what I'm most concerned about): What if I want to include another library which depends on the same libraries as this library, but with different versions? That is, what if for instance HtmlUnit depends on one version of xalan and another library I need, depends on a different version of xalan?
Ah yes. Assuming that you are building your own classpaths, etc by hand, you need to make a decision about which version of the dependent libraries you should use. It is usually safe to just pick the most recent of the versions used. But if the older version is not backwards incompatible with the new (for your use case) then you've got a problem.
Should I be concerned about this?
IMO, for your particular example (where we are talking about test code), no.
What are the best practices in situations like these?
Use Maven! It explicitly exposes the dependencies to the folks who download your code, making it possible for them to deal with the issue. It also tells you when you've got dependency version conflicts and provides a simple "exclude" mechanism for dealing with it.
Maven also removes the need to create distributions. You publish just your artifacts with references to their dependents. The Maven command then downloads the dependent artifacts from wherever they have been published.
EDIT
Obviously, if you are using HtmlUnit for production code (rather than just tests), then you need to pay more attention to security issues.
A similar thing has happened to me actually.
Two of my dependencies had the same 'transitive' dependency but a different version.
My favorite solution is to avoid "dependency creep" by not including too many dependencies. So, the simplest solution would be to remove the one I need less, or the one I could replace with a simple Util class, etc.
Too bad, it's not always that simple. In unfortunate cases where you actually need both libraries, it is possible to try to sync their versions, i.e. downgrade one of them so that dependency versions match.
In my particular case, I manually edited one of the jars, deleted the older dependency from it, and hoped it would still work with new version loaded from other jar. Luckily, it did (i.e. maintainers of the transitive dependency didn't remove any classes or methods that library used).
Was it ugly - Yes (Yuck!), but it worked.
I try to avoid introducing frivolous dependencies, because it is possible to run into conflicts.
One interesting technique I have seen used to avoid conflicts: renaming a library's package (if its license allows you to -- most BSD-style licenses do.) My favorite example of this is what Sun did when they built Xerces into the JRE as the de-facto JAXP XML parser: they renamed the whole of Xerces from org.apache.xerces to com.sun.org.apache.xerces.internal. Is this technique drastic, time consuming, and hard to maintain? Yes. But it gets the job done, and I think it is an important possible alternative to keep in mind.
Another possibility is -- license terms abided -- copying/renaming single classes or even single methods out of a library.
HtmlUnit can do a lot, though. If you are really using a large portion of its functionality on a lot of varied input data, it would be hard to make a case for spending the large amount of time it would take to re-write the functionality from scratch, or repackage it.
As for the security concerns -- you might weigh the chances of a widely used library having problems, vs. the likelihood of your hand-written less-tested code having some security flaw. Ultimately you are responsible for the security of your programs, though -- so do what you feel you must.
I've been given an assignment to create a visual component for a software competition. The only solid requirements I have are that
1. It needs to visualize data given through ActiveMQ
2. The information needs to be organized and visually appealing (information is presented as charts and graphs, and some nice UI elements are desireable, like tabs, accordion menus etc.)
At first, SmartGWT seemed like a good choice, but it seems that I cannot connect it to any messaging service before upgrading to a paid license, for which I do not have the funds.
Considering the fact that the requirements haven't yet been clearly stated and will be redefined probably in the near future, I cannot waste anymore time studying new technologies only to find out that I cannot use them for my needs. I'm considering something as close to Java (or JVM) as possible, as the software competition is Java based.
So, what framework would you recommend for me and why?
Grateful in advance!
Spring MVC ala the Spring framework.
It works in conjunction with ActiveMQ which meets your initial request. In addition the level of separation via the MVC pattern it provides is very nice as well as the ability to plug-in 3rd party components as needed.
Here is an article stating reasons to make use of Spring. You can ignore the J2EE stuff unless it is applicable to you; however note the Dependency Injection, Inversion of Control, and Aspect programming sections.
I have a rather large (80k loc) java desktop app that talks to a database. We're now looking at exposing some parts of the database via a web application, using the existing codebase and preferably not having to modify it.
I have good separation between the data access, business logic and presentation layers, but we haven't used enterprise java beans or anything like that (if that's important).
What's the best way forward? Which of the java web frameworks will be best suited to the problem? Learning curve isn't terribly important, since I haven't done any java development on the web...
To be true, it depends what you already have, and how well is the design of your current desktop application. You might not be able to use any or may be minimal of your existing code without modifying it, if its designed badly, and everything is tightly coupled.
Assuming that you are having a system with a good design, everything is de-coupled well enough. You can look into Stripes to make your presentation for the web, and use your existing data access and business code. I wish you all the luck.
Few other goodies to look into are, Groovy on Grail, Wicket.
I don't recommend anything like Seam and Spring they are more of a container and sophisticated large frameworks, which give you almost everything, solution for almost all of your problems. As you mentioned that you already have a complete system, and you just need to make a web interface to publish it for the web, these are not recommended, IMO.
JSF, is a good framework, but it might drive you nuts and has a big learning curve, according to few folks.
The two frameworks I would recommend would be Grails and Struts 2.
Grails comes with a whole bunch of stuff that it configures under the covers including Hibernate and Spring. It makes generating dynamic pages to send to the browser ridiculously easy. What you are probably going to need to do is set up controllers that call Grails services which reference your existing code as you probably don't want Grails managing your database interactions. The disadvantage with Grails is not so much that it is written in Groovy, which is easy to learn for Java programmers, but that the IDE support for Groovy is still maturing. Still if you want quick productivity this is the route to go down.
Struts 2 offers a clean command pattern framework implementation that talks to JSPs (or velocity or FreeMarker templates) on the front end. To use this you would configure actions to call your existing code. You may want to investigate adding Spring to the mix depending on what you need to do.
There are other choices but these are two that I have had some success with.