We Keep Coding

Is this ok if library has some side effects?

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.

Java code generation

I am looking for nice (java) code generation engine.
I have found cglib but it is very poorly documented and I am not quite sure that it can generate actual java classes (files) and only dynamic classes. If I am wrong maybe someone knows has a link with an example.
Roman

Have a look at codemodel, used with success for my projects.

Didn't really try, but you may want to take a look at another code generation Java framework called Javassist, which also has pretty thorough tutorial. Also Hibernate changed code generation framework from cglib to javassist. Quote, explaining why:
The simple fact of the matter is that development on CGLIB has largely stopped. It happens. Developers for whatever reason (the reasons are their own) move on to new priorities.
Source

I just released cgV19 here: https://github.com/carstenSpraener/cgV19 it's based on a code generator i wrote in 2002 to 2006 and which is still in production use. cgV19 is a re implementation with lessons learned. It has:
Support for gradle
Uses Groovy as a template language
a modular "cartridge" system to add several generator for different aspects
small footprint
Just try it out and give me feedback would be very nice.

Should I be concerned with large number of dependencies?

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.

Best solution for using AOP with OSGI?

I am using Equinox, so the Equinox Aspect project seems like a no-brainer, but that project appears to be inactive and has only one page of documentation that leaves me hanging at the end.
Other than that project, I do not see many options for using AOP in OSGI. Let me know what you all think and what the possibilities are, thanks :)

I don't know of any alternative, but I didn't think Equinox Aspects was inactive. It's even receiving new features in the upcoming Helios release.

The big issue is obviously with the lack of standardized loadtime weaving; Equinox Aspects and the weaver (used by AJDT) has been the only option for now. The good news is that bytecode weaving in all its glory is actively in progress in the OSGi working group and will "soon" be standardized. If you really need something that works reliably right now, your best bet is still compile-time weaving. IMHO that is a much better approach anyway, at least for AOP as design-time activity as it was originally envisioned..

As an alternative, you could also consider using the Apache Felix Dependency Manager, which allows you to at runtime add interceptors to existing OSGi services. Of course this is in no way a full AOP replacement, but for some use cases it might be enough.
You can find more documentation and an example here:
http://felix.apache.org/site/apache-felix-dependency-manager-osgi-design-patterns.html

Grails or Play! for an ex-RoR developer?

I plan to start learning a Java web framework (I love the Java API) I have already used Rails and Django.
I want something close to Java but without all the complexity of J2EE.
I've found 2 frameworks that could be good for me:
Grails
Grails looks great, it uses Groovy which is better than Java for web application (I think..) but it's slower than pure-java based frameworks (Hibernate, Strut, Spring) It looks pretty simple to deploy (send .war and it's ok!), the GSP is great! It's a bit harder to debug (need to restart the server at each modification and stacktraces contain a mix of Java and Groovy traces which is not always the easiest to understand)
Play!
This framework also looks great; it's faster than Grails (It uses Java) but I don't really like how it uses Java, it modifies the source code to transform the property calls as setXXX/getXXX, I do not like that... The framework also has a caching function that Grails does not have. I don't really like the Template Engine.
It's also easer to debug (no need to restart the server, stacktraces are clearer)
What do you recommend?
I am looking for something easy to learn (I have a lot of Ruby experience, not so much Java experience but I love the Java API), fully featured (That's no a problem with all the Java Library available, but if it's bundle and integrated I prefer), has good scalability and is not too slow (faster than Ruby) Ideally I would like to use a framework with a decent community to easily find support.
PS: I am not interested in JRuby on Rails

I switched from Grails to Play and I never looked back. My biggest problem with Grails was overall robustness and developer usability. Most of the time I got bitten by the fact that Grails glues together the usual stack of Spring MVC and Hibernate while trying to hide this fact and giving you a Rails-like API (personal opinion of mine). The problem with this is, once something goes beyond the trivial samples, it easily broke and didnt work for me. Developing with it was like walking on eggs (for me). Whenever I googled for documentation of a feature I needed, I was not redirected to samples, tutorials, blogs, but to the Grails JIRA explaining me why the feature wouldnt work for my use case and that the bug was unresolved since two versions before the one I was using.
While that may not be the overall experience for every developer (I am not writing this to bash Grails, but to give my experiences with it here), I needed something that helped me and would not stand in my way or break down on me when I needed it the most. Thats when I found Play and I have quickly migrated my app to it after I found out about it (around the ~1.0 release).
So far it has been a great ride and for the first time in my web development career, I have stopped looking at other frameworks trying to find something that I would like better.
If I had to close with one thing that Play did better than Grails - at least for me - it would be the fact the Play is built from the ground up with developer usability in mind. It does not sacrifice ease of use for enterprise buzzwords. It has the guts to throw away what does not fit into this paradigm (e.g. ditchting Servlet-based runtimes during development for faster turnaround). It is willing to make compromises in order to guarantee awesomeness. And that is something I have only seen in communities like Rails or Django before I found Play.

I'd suggest Grails. It has a bigger community than the play framework does (~350 plugins covering pretty much every basic need). Also, grails is written almost completely in Java, it just lets you use Groovy for your domain specific implementation.
If you do run into a performance issue where the groovy pages that you've created are the bottleneck, you can always just switch to a Java implementation. Then you're in the same boat that you would have been with the Play framework all the time. You've optimized your development time by putting off the coding of things in Java till you know that you actually need to do it (which, in my experience is very rare).
I'm also not sure where you heard that you need to restart your server for each modification, but that's actually not true. Grails supports reloading of controllers/gsps/services/domain objects, etc without restarting your server.
The mixed stacktraces can get a little long, but tool vendors (like Intellij) have made some recent improvements that strip out all the stacktrace portions that you don't care about.
I've been using grails since the .5 days and have been very happy with the platform.

Take note that the Play! framework now supports using Scala as of 1.1

From my experience with Play it's a great framework. My favorite features are the cool controller system and the template system - both are simple but feature-rich and powerful.
However the most important benefit of Play is definitely the rapid development cycle, where virtually no reloading is needed on code changes. But if you're not careful, this greatness won't last much, and slowness will eventually creep into your code.
Why is that?
With Play there is common use of some plugins with pretty heavy initialization, notably EJB (Hibernate) and Spring. The initialization of these plugins is re-run on every code change before the new code is loaded. As a result of this, as your model and your system configuration grow, this heavy initialization starts to seriously slow down your development. In the system I used 20 seconds were a typical startup time on a virtual machine running on a kickass laptop.
What you can do to avoid this depends on your application, e.g. if you're building a NoSQL application then then EJB plugin should not give you trouble. Spring can be replaced with a custom hard-coded Java plugin, which IMHO is also easier to maintain, or run a Groovy script if scriptability is that important. In any case, watch out for these problems and kill them while the're young - and be sure not to be running your own bulky initializations on every refresh.

If you have used Ruby and Python before, you will probably enjoy Grails better than Play. It very hard to get back to Java once you are used to these dynamic languages.

There is also Lift on Scala.
Imho scala is the best static typed language and lift is a pretty nice framework (for a static typed language).