NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
You can do all the benchmarks and tests you want but I dont trust google. I stay with Rod Johnson and Spring. Spring Rocks and is more mature and lots of corporations use it today.
Well if you actually spent time looking at the benchmark which by the way I did not write you would quickly realize that there is in fact no XML. The Spring bean factory is implemented via API calls.
The purpose of this article which seems to be lost on a small number with obvious prejudices is that such benchmarks are in fact questionable and that we should question any such publications.
Again the benchmark was first published by Bob Lee and then adapted and tested with the latest release by the "New York Java Consultant" blogger.
Ironically you statement is the basis for the article. We put a lot of trust in the words of a few (including Spring,....) without every questioning and understanding them. This benchmark was written and adapted by two people over the last year has never really be questioned. Numbers were put up and that was it.
I have trust very little trust in anything reported by companies that cannot be verified and validated. But lets be clear Bob did say this was a semi useless benchmark and the figures do clearly show that he has written a clean and efficient dependency injection runtime. Why would you assume the Interface21 team would be anyway different? We all lie to ourselves occasionally and this does perpetuate into public occasionally such as promoting a project & product that processes millions and millions records when in fact the technology plays a very small part in the overall execution pipeline. You are not telling tales but transferring the quality of the actual technologies doing the real work to your own product.
Performance is the least of the reasons you should be using Guice. Unlike Spring, Guice focuses on details, not feature lists. For example, Guice goes out of its way to prevent, catch, and help fix errors early. Spring hasn't matured to this point yet. Spring includes potentially dangerous features like auto-wiring. Good for marketing, bad for users.
Blind faith is no way to make technical decisions.
(I know this isn't really what this thread is about, but since Bob Lee already started, let me add a comment)
Here is a detail I'd like Guice to focus on:
Since Guice relies on the @Inject annotation to know where to inject dependencies, how do I inject a dependency into a component that I can't change the code from? In other words, how do I inject a dependency into third party components where only compiled classes are available?
Let's say you have a class Foo which you can't annotate:
public class Foo {
public Foo(Bar bar, Tee tee) {
...
}
}
In Guice 1.0, you'd have to implement a Provider<Foo> which manually constructs Foo. In Guice 2.0, you'll be able to implement a provider method, which is pretty much just a factory method that can have its parameters injected:
@Provides Foo provideFoo(Bar bar, Tee tee) {
return new Foo(bar, tee);
}
Yes, Guice is much more stable. The design is cleaner and more sound and thread-safe. Guice detects problems sooner, at startup (and possibly even build time), so your application is less likely to blow up at runtime.
Subjective comments eh? Can you backup design being cleaner? Easy to say when you hardy have any features.
Try couching the technical ego, you aren't that good. -ilwe
Ouch. iflifewaseasy, instead of putting me down, you should take 5 minutes to compare the two different APIs and implementations. What's 5 minutes when it comes to such a critical technical decision? That's the beauty of open source.
> You can do all the benchmarks and tests you want but
> I dont trust google. I stay with Rod Johnson and
> Spring. Spring Rocks and is more mature and lots of
> corporations use it today.
Your "trust" in Google seems like a silly reason to choose one framework over the other. If Guice were closed source, trust would be critical, because they could suddenly raise prices with the next version, etc. But Guice is open source, with a small development team, and they are very helpful to people on their forums. When you use Guice, you are not dealing with some faceless huge corporation that you have "trust" issues with. You are dealing with Bob, Kevin, etc. Duh.
Benchmark Analysis: Guice vs Spring
URL: Benchmark Analysis: Guice vs Spring
At 12:57 PM on Oct 31, 2007, Michael Urban wrote:
Fresh Jobs for Developers Post a job opportunity
Read William's article now .
14 replies so far (
Post your own)
Re: Benchmark Analysis: Guice vs Spring
You can do all the benchmarks and tests you want but I dont trust google. I stay with Rod Johnson and Spring. Spring Rocks and is more mature and lots of corporations use it today.Re: Benchmark Analysis: Guice vs Spring
No wonder.Spring needs to parse xml document to get constructing guideline, while guice uses annotation which is implemented by jvm.
But speed is not all that an IoC implementation should care.
Re: Benchmark Analysis: Guice vs Spring
Well if you actually spent time looking at the benchmark which by the way I did not write you would quickly realize that there is in fact no XML. The Spring bean factory is implemented via API calls.The purpose of this article which seems to be lost on a small number with obvious prejudices is that such benchmarks are in fact questionable and that we should question any such publications.
Again the benchmark was first published by Bob Lee and then adapted and tested with the latest release by the "New York Java Consultant" blogger.
regards,
William
Re: Benchmark Analysis: Guice vs Spring
Ironically you statement is the basis for the article. We put a lot of trust in the words of a few (including Spring,....) without every questioning and understanding them. This benchmark was written and adapted by two people over the last year has never really be questioned. Numbers were put up and that was it.I have trust very little trust in anything reported by companies that cannot be verified and validated. But lets be clear Bob did say this was a semi useless benchmark and the figures do clearly show that he has written a clean and efficient dependency injection runtime. Why would you assume the Interface21 team would be anyway different? We all lie to ourselves occasionally and this does perpetuate into public occasionally such as promoting a project & product that processes millions and millions records when in fact the technology plays a very small part in the overall execution pipeline. You are not telling tales but transferring the quality of the actual technologies doing the real work to your own product.
regards,
William
Re: Benchmark Analysis: Guice vs Spring
Performance is the least of the reasons you should be using Guice. Unlike Spring, Guice focuses on details, not feature lists. For example, Guice goes out of its way to prevent, catch, and help fix errors early. Spring hasn't matured to this point yet. Spring includes potentially dangerous features like auto-wiring. Good for marketing, bad for users.Blind faith is no way to make technical decisions.
Re: Benchmark Analysis: Guice vs Spring
(I know this isn't really what this thread is about, but since Bob Lee already started, let me add a comment)Here is a detail I'd like Guice to focus on:
Since Guice relies on the @Inject annotation to know where to inject dependencies, how do I inject a dependency into a component that I can't change the code from? In other words, how do I inject a dependency into third party components where only compiled classes are available?
Re: Benchmark Analysis: Guice vs Spring
Let's say you have a class Foo which you can't annotate:In Guice 1.0, you'd have to implement a Provider<Foo> which manually constructs Foo. In Guice 2.0, you'll be able to implement a provider method, which is pretty much just a factory method that can have its parameters injected:
Compare this to the equivalent Spring XML:
Re: Benchmark Analysis: Guice vs Spring
As my point,the stability is more important than speed.Re: Benchmark Analysis: Guice vs Spring
Yes, Guice is much more stable. The design is cleaner and more sound and thread-safe. Guice detects problems sooner, at startup (and possibly even build time), so your application is less likely to blow up at runtime.Re: Benchmark Analysis: Guice vs Spring
Subjective comments eh? Can you backup design being cleaner? Easy to say when you hardy have any features.Try couching the technical ego, you aren't that good.
-ilwe
Re: Benchmark Analysis: Guice vs Spring
Ouch. iflifewaseasy, instead of putting me down, you should take 5 minutes to compare the two different APIs and implementations. What's 5 minutes when it comes to such a critical technical decision? That's the beauty of open source.Re: Benchmark Analysis: Guice vs Spring
Unless, of course, you actually work on Spring. You did post anonymously with a newly-registered account.Re: Benchmark Analysis: Guice vs Spring
> You can do all the benchmarks and tests you want but> I dont trust google. I stay with Rod Johnson and
> Spring. Spring Rocks and is more mature and lots of
> corporations use it today.
Your "trust" in Google seems like a silly reason to choose one framework over the other. If Guice were closed source, trust would be critical, because they could suddenly raise prices with the next version, etc. But Guice is open source, with a small development team, and they are very helpful to people on their forums. When you use Guice, you are not dealing with some faceless huge corporation that you have "trust" issues with. You are dealing with Bob, Kevin, etc. Duh.
Re: Benchmark Analysis: Guice vs Spring
> Unless, of course, you actually work on Spring. You> did post anonymously with a newly-registered account.
Astroturfing, perhaps? Or just another run-of-the-mill anonymous coward? Can we see IP addresses?