Guice 3.0 Beta is currently (nov. 2010) in Beta. And as a Guice 2.0 user I’m especially interested in the new Hibernate persistence integration (As I believe this is the replacement of the Guice Warp project). I have some questions and I really like to hear from people who already work with Guice 3.0:
How stable is the Beta version? Can it be used for production purposes?
Is the API stabilized? Or is it still under development?
Is there any target date for the final release?
I believe everything's quite stable as far as production-readiness. I believe Google's been using the latest code all along, and I know Maven 3.0 and Nexus are using a slightly modified Guice 3.0.
I don't think they've frozen things to the point of saying "there will absolutely be no further API changes before release", but I think anything more than extremely minor changes is unlikely.
Sam Berlin, one of the guys working on Guice, said that he'd like to have 3.0 out by the end of the year... but the more testing of the snapshot and feedback on it on the mailing list they get, the better.
Why not ask this on their mailing list? Anyhow from what I can tell they're pretty close, I know that the JClouds guys have been using it heavily and seem pretty happy with it. I'm using it for the chapter I'm writing on DI for my book and it's passed all of my use cases and tests so far, but I'm not running a production system here :-)
As a general rule you should be wary of using Beta software in production. I think when the Guice team say Beta they really do mean Beta (unlike a Web 2.0 Beta site).
There are possibly still some minor API changes possible, but I think they're pretty much done. If you're using it purely for JSR-330 DI annotation support then you're probably safe here
Not that I've seen on their lists, but I could be blind :-)
Related
I am trying to connect to a broker that is using FIX 5.0
I would like to leverage quickfixj for ease and speed of implementation.
Is this going to work? I am assuming 5.0 extends (so to speak) the features of prior versions, but I do not want to get too far along and wind up causing more issues than it is worth to use quickfix.
I ask this because the current website says that quickFixJ is okay for versions of fix between 4.0 and 4.4.
Will this still work with 5.0?
Many financial institutions use quickfix and it is quite likely that if QuickFix has an issue with version 5.0 the other end has the same issue as it's pretty standard. BTW You can change the implementation fairly easily, if for example you want to improve the performance. (which is ok, but not great)
quickfixj is generating its classes out of the standard fix dictionaries, so there is no limitation in terms of the framework and from my experience it is very accurate, new releases from 1.5.3 to 1.6 seems to have some issues between 4.x and 5.x compatibility but in general it is quite straight in managing a mix of versions and custom fields, it boils down to the version of reference between the counterparties which applies to every message but essentially on the message level all versions can be woven in / customised
I just want to know if the application is going to be developed in Java, is it better to go for Play 1.x.x or 2.x.x?
and How long the version 1.x.x will be supported? Is it an active fork?
Thanks
Start with Play 2+ reason is simple, Play 1.x is NO longer officially developed by Zenexity. It's only in maintenance mode now.
A fork has appeared a couple of months ago : Yalp Framework.
Basically 1.x.x is still around because it is really different from 2.x.x
converting Play1 projects to Play2 is almost recoding everything so Play has to keep on supporting Play1 to keep the "customers" that are already doing production with 1.x.x
If you are starting a project now, be it Java or Scala, I advise to get Play 2.1.x since it has the latest and most awesome features. And it also works with the latest versions of scala (which I am aware is not relevent to your question).
TLDR : 1.x.x is outdated but still supported because a lot of people are still using in production since it is not easy to port a 1.x project to 2.x
First I think you should read What are the major differences between Play Framework 1.0 and 2.0?.
2.x is in active development, how ever if you have trouble you must read the core-code which is scala and you must handle with SBT, which is more Scala Build Tool than Simple Build Tool.
For play 1.x there is a fork yalp, but it's in the beginning and will break with the old api, but it's plain java.
If you need some of the features of play2.x (responsive web in meaning of a server which has a good responsiveness nothing to do with webdesign.) I think play with scala is the best choice. If you have a simple application, play1.x does everything you need.
So check the tutorials to get a feeling.
Given an application using Spring 2.5, when migrating to Spring 3.0 what are the likely areas that will be pain points, i.e. things that the development team will have to spend time on to get things working. Assume the team would not try to take advantage of new Spring features as part of the upgrade, but just get the application to the state where it works as it did on 2.5. Taking advantage of 3.0 features would be the next steps to consider.
Edit: I have revised the question to focus on the pain points of the upgrade, which is what I'm really after.
Probably the biggest change in Spring 3.0 is that it now requires J2SE 5.0.
One of the Spring developers reply for a compatibility question in this blog entry.
Spring 3.0 aims to be 99% backwards
compatible with Spring 2.5. The core
APIs and SPIs will remain stable in
order to keep existing extensions (and
of course also existing application
code) working. Introducing generics
and varargs, as we've done in M1 and
M2, should still preserve binary
compatibility. That said, we generally
recommend rebuilding your applications
for Spring 3.0, in order to catch
potential API issues early. This will
also allow you to get the maximum
benefit from Spring 3.0's Java 5 API
refinements.
If you're lucky, then nothing will need changing, it should all just work. The Spring guys are very careful to retain backwards compatibility.
The biggest reason I can think of for it not working is if you're using code that was deprecated in 2.5, and marked for removal in 3.0 You can find that list here.
Having worked for Java for 7 years I'm now moving into a project in .net. The team I'm working in have recently used a technology stack that we are fairly happy with in the business layer and below:
Spring for dependency injection, transaction management, security and for adding interceptors and for getting the possibility to inject different implementations of interfaces when in unit-test as oppose to deployed on a server.
JUnit for unit tests.
JPA/Hibernate for ORM
Could you use this stack in .net? I've heard of nHibernate, spring.net and nUnit.
Are these the translations into .net? or are those projects dead, bad implementations or what?
Are there other superior techniques/frameworks?
Appreciate your thougts!
You nailed it - NHibernate, Spring.NET and NUnit are all widely used frameworks on the .NET side that compliment their sister frameworks on the java side.
None of those projects are anywhere near dead. I think NUnit just released a new version last month, actually.
I would recommend xUnit.net over nUnit. It has a rationalised approach and some very nice features which set it apart from the other frameworks.
Assert.Throws() is just wonderful (beats [ExpectedException] hands down) and the Extensions assembly provides [Theory] which, combined with [InlineData()], is incredibly powerful. For more info see the project homepage
The frameworks you mention (as far as I'm aware) are still current and active development. I might suggest a few alternates to look at.
Spring.NET is the only thing I'm aware of to do what you're talking about.
nUnit is a good choice. You might want to check out the different versions of Visual Studio. Different versions have different features...some have heavy unit testing functionality built in.
nHibernate is a good .NET ORM. With the release of .NET 3.5, you might want to check out the Entity Framework or LINQ to SQL Classes.
nHibernate and nUnit are very much alive and well. Initially they were ports of their java counterparts, but have evolved since then I believe.
Can't speak to spring.net though..
We are discussing whether it's a good idea to switch from plain portlet development on a liferay installation to spring webmvc portlet based development.
We're starting the development of some portlets soon, so now is the time. But the problem I see is that we'd like to use some of the portlet 2.0 features, which won't work with versions older than spring 3.0. (Right?)
Has anyone insight, if it's worth the waiting? (When is 3.0 scheduled anyway?)
Is the current milestone stable enough?
Our first real release will be in the last quarter of the year, so the springsource guys have some time left to get a final out of the door... ;-)
Any ideas?
UPDATE
So, Spring 3 has been released and it supports all JSR286 features we need. (I think it's a pretty complete support for the JSR286 features)
The only drawback I am seeing is the documentation which is not up to speed in regard to the annotations.
We use Spring Portlet MVC 2.5 on Liferay and we have excellent results. Most of JSR-286 functionality(like events) can be reached be extending DispatcherPortlet class.
There is still a lot of bugs open for upcoming 3.0 release, so I would be rather conservative and stay with stable&mature version 2
The spring framework has an excellent track record of code quality. In the past their M releases were of high quality, so I would not be afraid to use it.
Juergen Hoeller gave Jul 2008 as the estimated release date for Spring 3.0:
http://www.springify.com/archives/15
I think they're late. 8)
Matt Raible lamented the fact in Oct 2008, almost six months ago:
http://raibledesigns.com/rd/entry/the_colorado_software_summit_and
I wonder if the new professional versus open source model has affected availability.
They also have the Spring DM, Spring Blaze, and Spring Integration work going on now.
Given their past history of quality releases, I'd bet that they're resisting the urge to release early in order to make certain the code is up to their standards.
I am just getting to know Portlet MVC with Spring 3.0 M4 and came across a modified PetPortlet sample making use of Spring3 (JSR-286) features and annotations. While it is Mavenized and probably not directly deployable on Liferay, it still provides good examples.
Please comment should you happen to come across any others.