When people mention that Spring is a lightweight containter compared to other frameworks, do they mean? That it occupies less memory in the system or it does not have the operations like start stop that we have for EJB containers and it doesn't use a special container?
What makes Spring a lightweight container?
Whether it is "lightweight" or "heavyweight", it is all about comparison. We consider Spring to be lightweight when we are comparing to normal J2EE container. It is lightweight in the sense of extra memory footprint for the facilities provided (e.g. Transaction Control, Life Cycle, Component dependency management)
However, there are sometimes other criteria to compare for the "weight" of a container, e.g. intrusiveness in design and implementation; facilities provided etc.
Ironically, Spring is sometimes treated as heavy weight container when compared to other POJO-based container, like Guice and Plexus.
Spring calls itself 'lightweight' because you don't need all of Spring to use part of it. For example, you can use Spring JDBC without Spring MVC.
Spring provides various modules for different purposes; you can just inject dependencies according to your required module. That is, you don't need to download or inject all dependencies or all JARs to use a particular module.
If you want to run a Java EE application, you can't just create a small application that will run on its own. You will need a Java EE application server to run your application, such as Glassfish, WebLogic or WebSphere. Most application servers are big and complex pieces of software, that are not trivial to install or configure.
You don't need such a thing with Spring. You can use Spring dependency injection, for example, in any small, standalone program.
I think "lightweight" is mostly a buzz-word. It's meaning is highly subjective and based on context. It can mean "low memory footprint", it can be low execution overhead, low start-up overhead. People also use it to differentiate between some perceived level of complexity and/or learning-curve. In any case, it's assuredly relative as there is no defined point on any scale where "light" becomes "heavy" in terms of "weight".
I personally think it's a dangerous word since it has no real, quantifiable meaning. It's something people throw into architecture proposals to beef up the "pro" section of a certain framework they want to use anyway. If you see or hear it being used in any such situation, it's a perfect opportunity to ask "what does that mean?". If you get an angry or frustrated response (combined with rolling of eyes and shaking of head), it means that the person has decided on a certain architecture, but hasn't managed to formulate coherent or objective reasons for it.
EDIT: not sure I would categorize spring as a "container" either, but that's a similar apples and oranges discussion. I'd call it a framework.
Spring is light weight becouse other J2ee container especially EJB2.1 require more configuration, It can have lot of do nothing code to ,it have complex directory structure for packing applications, overall it took extra memory;on other hand spring minimizes all this things.so it light weight.
I think one can also say that spring is light weight because it uses POJO(Plain old java object) .POJO class does not require to implement,extends technologies specific API(Interfaces,Classes) or it is not bounded to any technology specific API
Related
My project has requirement to deploy a Java Based application as an operating system Job (and not use any container). The application need to have following capabilities:-
Scheduling
Few HTTPS based services
Ability to make JMX calls
Storage: Data for last 5 to 10 minutes of transactions (not more than 600 rows X 20 columns). Something like embedded H2 or in-memory options
Decision Tree: Something like Drools..
My manager wants to write this application as a core Java with OSGized Jetty version. I am suggesting to use Spring Boot with embedded Jetty(which will give me ready to use capabilities for Scheduling, JMX Integration and REST Services).
His bend towards core Java is emerging from the requirement that this application needs to be extremely efficient, fast and self-contained. He wants to reduce dependency on any open source. I have never worked directly on OSGI but have used products coming out of it - like eclipse.
Can somebody guide how OSGI based development might benefit over SpringBoot?
For many people, OSGi is superfluous, because they don't see the value in being modular. Not being worth the trouble.
Think about the application lifecycle, more or less being plan-develop-test-deploy.
How many developers you have? If many, OSGi helps a lot, because being modular make the boundaries very clear. You can delegate things very easily.
If outsourcing is your thing, you can just handle the module APIs and tell them to develop against it. They will never know how the rest was implemented, no fear of secrets being leaked.
Unit tests are so easy. You obviously see what you can test, every else you mock/stub/spy/fake. Unit tests can be can be reused in Integration tests, of course that isn't news, but the trick is running Unit tests outside the OSGi container, and Integration tests inside. So if you decide OSGi was not worth it, your code stills works fine (unit tests being the proof).
You can make your app a collection of modules, and every module having independent versioning and source repositories. Makes easier to handle and find bugs. For example, the current app crashed, you find out that sub-module-1.2 is throwing errors, try with version sub-module-1.1(still bad), then version 1.0(good), bug was introduced in 1.1 (avoids bisecting the source code). Programmers don't need to be perfectly synchronized with each other if they are working in different modules.
How do you plan to update the app? Most frameworks are of the all-or-nothing approach, where you have to stop the world, update, then restart the app. If you make things modular, you just need to update that thing. Making the downtime very small, and sometimes even zero.
If you need to make a big change in your app, but can't afford to refactor everything right now. With OSGi you can run the system with both my-module-1.0 and my-module-2.0. You can even adapt my-module-1.0 to redirect calls to my-module-2.0, but that is a kind of last resort hack (just saying that you can, if you want to).
I can do everything you say without OSGi, right? Well, probably you can, but in the end, would be something like OSGi.
I love the Dependency Injection of my framework. No problem, OSGi have something like that.
I hate Dependency Injection, it kills my app perfomance. No problem, you can use something like osgi.getService(MyService.class);. The OSGi container isn't concerned about intercepting every call of your app.
OSGi is like Java++, Java plus modules.
You can mix Spring Boot with OSGi, can't say if this is good or bad. There are many libraries and frameworks that fit your list, many will work out-of-the-box with OSGi.
Is it sensible to use Spring in the server side of an in memory data grid based application?
My gut feeling tells me that it is nonsense in a low latency high performance system. A colleague of mine is insisting on including Spring in it. What are the pros and cons of such inclusion?
My position is that Spring is OK to be used in the client but it is too heavy for the server, it brings too many dependancies and is one more leaky abstraction to think of.
Data Grid systems are memory and I/O intensive in general. Using Spring does not affect that (you may argue that Spring creates a lot of beans but with proper Garbage Collection tuning this is not a problem).
On the other hand using Spring (or any other DI) helps you structure and test your code.
So if you are using implementing some sort of server based on Data Grid systems, pay attention to properly adjusting GC, sockets in your OS (memory buffers and socket memories). Those will give you much more benefits than cutting down DI.
First, I'm surprised by the "leaky abstraction" comment. I've never heard anyone criticize Spring for this. In fact, it's just the opposite. Spring removes the implementation details of infrastructure such as data grids from your application code and provides a consistent and familiar programming model, allowing you to focus on business logic. Spring does a lot to enhance configuration and access to data grids, especially Gemfire, and generally does not create any runtime overhead per se. During initialization of a Spring application, Spring uses tools like reflection and AOP internally which may increase the start up time of an application, but this has no impact on runtime performance. Spring has been proven in many high-throughput, low-latency production applications. In extreme cases, things like network latency and serialization, concerns external to Spring, are normally the biggest factors affecting performance.
"Spring brings in too many dependencies" is a common complaint, but is a fallacy. I would say Spring brings in the exact right amount of dependencies for what it needs to do. Additionally, Spring Boot starters and the platform BOM do a lot to simplify dependency management so you don't need to worry about version incompatibilities or explicitly declaring common dependencies. I'll have to side with your colleague on this one.
I've been reading/learning more about Spring lately, and how one would use Spring in combination with other open-source tools like Tomcat and Hibernate. I'm evaluating whether or not Spring MVC could be a possible replacement technology for the project I work on, which uses WebLogic and a LOT of custom-rolled Java EE code. The thing is, I've always suspected that our solution is over-engineered and WAY more complex than it needs to be. Amazingly, it's 2009, and yet, we're writing our own transaction-handling and thread-pooling classes. And it's not like we're Amazon, eBay, or Google, if you know what I mean. Thus, I'm investigating a "simpler is better" option.
So here's my question: I'd like to hear opinions on how you make the decision that a full-blown Java EE application server is necessary, or not. How do you "measure" the size/load/demand on a Java EE app? Number of concurrent users? Total daily transactions? How "heavy" does an app need to get before you throw up your hands in surrender and say, "OK, Tomcat just isn't cutting it, we need JBoss/WebLogic/WebSphere"?
I don't think that the decision to use a full-fledged Java EE server or not should be based on number of users or transactions. Rather it should be based on whether you need the functionality.
In my current project we're actually moving away from JBoss to vanilla Tomcat because we realized we weren't using any of the Java EE functionality beyond basic servlets anyway. We are, however, using Spring. Between Spring's basic object management, transaction handling and JDBC capabilities, we aren't seeing a compelling need for EJB. We currently use Struts 2 rather than Spring's MVC, but I've heard great things about that. At any rate, Spring integrates well with a number of Java web frameworks.
Spring does not attempt to replace certain advanced parts of the JavaEE spec, such as JMS and JTA. Instead, it builds on those, making them consistent with the "Spring way", and generally making them easier to use.
If your application requires the power of the likes of JMS and JTA, then you can easily use them via Spring. Not a problem with that.
Google open sources a lot of their code. If you're writing low-level things yourself, instead of implementing code that's already written, you're often overthinking the problem.
Back to the actual question, Walmart.com, etrade.com, The Weather Channel and quite a few others just use Tomcat. Marketing and sales guys from IBM would have you believe different, perhaps, but there's no upper limit on Tomcat.
Except for EJB, I'm not sure what Tomcat is missing, and I'm not a fan of EJB.
What tomcat does not offer apart from the more exotic elements of Java EE is session beans (aka EJBs). Session beans allow you to isolate your processing efficiently. So you could have one box for the front end, another for the session beans (business logic) and another for the database.
You would want to do this for at least 2 reasons:
Performance; You're finding that one box to handle everything is loading the box too much. Separating the different layers onto different boxes would allow you to scale out. Session beans are also able to load balance at a more fine grained level. Tomcat and other web services of that ilk don't have clustering out of the box.
Flexibility; Now that you've moved your business logic into its own environment you could develop an alternate front end which used the same layer, but say, was a thick client front end for example. Or maybe other contexts would like to make use of the session beans.
Though I should probably point out that if you use web services to communicate with that middle tier, it could also be on tomcat!
The only reason to use a full blown Java EE server is if you need distributed XA transactions, if you don't need XA transactions then you can use Spring + JPA + Tomcat + Bean Validation + JSTL + EL + JSP + Java Mail.
Also a Java EE server is supposed to implement JMS but it does not make sense to run the JMS server in the same VM as the rest of the app server so if you need JMS you should have a separate JMS server.
I strongly disagree with all answers given here.
Everything can be added to Tomcat, including EJB, CDI, JTA, Bean Validation, JAX-RS, etc.
The question is: do you want this? Do you want to assemble all those dependencies in the right versions and test that it all works together, when others have already done this?
Let's be clear: nobody uses only Tomcat! Everyone always adds a web framework, an ioc container, an orm, a transaction manager, web services, etc etc
Lightweight Java EE servers like TomEE already include all of that and makes the full stack experience of having all those things integrated so much better.
Maybe this can be of interest:
http://onjava.com/onjava/2006/02/08/j2ee-without-application-server.html
HTH
I'm looking to make a website that will probably get some heavy, repetitive traffic. Is grails up to the task?
I agree with lael, also because it's built on java technologies there are a lot of proven clustering and 'enterprisey' tools available which allow you to easily scale across multiple application services.
The cloud tools around Grails are also becoming very good and make deploying to a cloud like EC2 very easy. I've recently been using Cloud Foundry and found it very good.
As the first poster points out however, you can write a badly performing application in any framework/language. One thing I'd recommend is getting a good understanding of Hibernate which is the underlying persistence library. If you understand how that works, it should help you avoid making any silly mistakes at the DB level. On this side of things, a tool like p6spy is great for checking what the database is up to during normal use. It should help you spot any repetitive queries.
The scalability of your web application won't really depend on what language/framework you choose to use, but rather how your application is built. You can build a scalable web application in Grails, just as you can build an incredibly slow application in C++. If Grails is the framework you would like to use, then use it; you can always rewrite the slow parts in Java or another fast language, if need be. (After all, that's what Twitter did with Scala.)
Disclaimer: I've never actually used Grails.
Grails is essentially a thin layer on top of the Spring Framework, which many consider to be a very scalable framework in the enterprise world. Spring + Hibernate has become a standard in many Java shops around the globe.
If you run into performance bottlenecks in Groovy, you can always rewrite those parts in Java.
Take a look at the Success Stories for examples of sites that were written in Grails. The Testamonials are also a good place to look for examples. You will use a little more memory(heap and permgen) than a vanilla Java app, but you can tune it just like you would any other Java application.
On the low end you aren't going to find $3/month Hosting options that you could with PHP stack (for example). That said, there are some good caching solutions for Grails apps EhCache, MemCache, etc. Beyond that you can also setup an Apache layer to caches static resources or whatever you need.
Don't mean to pile on here. You've already got some great answers but I just want to add on thing that I was reminded of recently. Scalability depends not only on the software you write (regardless of language/framework) but also on the deployment environment. A very well written application deployed on an undersized or poorly configured server will not scale at all. If you do use Grails or any other Java based framework, the default settings on your container (Tomcat, JBoss, etc.) will probably not be what you need.
Just something to keep in mind,
Dave
Grails run on the JVM. Simply put, you will not find a more scalable, solid and robust runtime platform than the JVM, anywhere. That's Grails's big advantage over, say, PHP or RoR.
We have started to use spring aop for cross cutting aspects of our application (security & caching at the moment).
My manager worries about the performance impact of this technology although he fully understands the benefits.
My question, did you encounter performance problems introduced by the use of aop (specifically spring aop)?
As long as you have control of your AOP I think it's efficient. We did have performance problems anyway, so by own reasoning we were not fully in control ;) This was mostly because it's important that anyone that writes aspects has full understanding of all the other aspects in the system and how they interrelate. If you start doing "smart" things you can outsmart yourself in a jiffy. Doing smart things in a large project with lots of people who only see small parts of the system can be very dangerous performance-wise. This advice probably applies without AOP too, but AOP lets you shoot yourself in the foot in some real elegant ways.
Spring also uses proxying for scope-manipluations and thats an area where it's easy to get undesired performance losses.
But given that you have control, the only real pain point with AOP is the effect on debugging.
If performance is going to be a concern, we have used AspectJ to great effect.
Because it uses bytecode weaving (compile time vs. runtime makes quite the difference) it's one of the fastest AOP frameworks out there. See: AOP Benchmarks
When I used it, I didn't - but then my application isn't your application.
If you use it for calls which are used in a very tight loop, there's the opportunity for a significant performance hit. If it's just used to check security once per request and cache various things, I can't see how it's likely to be significant - but that's why you should profile and benchmark your app.
I realise that "measure with your app" probably isn't the answer you were looking for, but it may well be the one you guessed you'd get :)
If you are using proxy-based AOP, you are talking about 1 additional Java method invocation per aspect applied. The performance impact there is pretty negligible. The only real concern is the creation of the proxies but this usually happens just once on application startup. The SpringSource blog has a great post on this:
http://blog.springsource.com/2007/07/19/debunking-myths-proxies-impact-performance/
In theory, if you use AOP do to what you could do with hard coupling, there is no performance issue, no overhead and no extra method calls unless you weave for nothing. AOP Framework offers you a way to remove the hard coupling and factorize your cross-cutting concern.
In practice, AOP Framework can introduce 3 types of overhead:
fire-time
interception mechanic
consumer integration (way to develop an advice)
For more details you can refer to when-is-aop-code-executed.
Just be careful how you implement an advice because transversal code is a temptation for boxing/unboxing and reflection (expensive in term of performance).
Without an AOP Framework (hard coupling your cross-cutting concerns) you can develop your presumed advices (dedicated for each treatment) easier without boxing/unboxing and reflection.
You have to know that most AOP Framework don't offer the way to avoid totally boxing/unboxing and reflection.
I developed one to respond to most of missing needs concentrated to 3 things :
user friendly (lightweight, easy to learn)
transparent (no breaking code to include)
efficient (no boxing/unboxing, no reflection in nominal user code and good interception mechanic)
You can find my open source project here : Puresharp API .net 4.5.2+ previously NConcern .NET AOP Framework
11 years after the question, look how degenerated this situation is.
Example: the vast majority think it is ok and normal to put a simple #Transactional spring java annotation to some method and let spring do the bridge between caller and callee proxied components. Now they have 20+ stackframes of undebuggable 'magic' code. The JIT compiler is rapidly exceeded and can no longer attempt inlining, or ends up bloating memory with tons of generated classes.
There is no limit to lazyness in this era of 'framework users'. No wonder e2e times for trivial http calls went from 100ms to 10 seconds. No wonder you need 2GB to run a lousy servlet container that used to run in 128MB. And don't get me started on the cost of logging exception stacktraces...
Have you ever thought about an AOP tools that adding aspects to object at runtime when you need? There is one for .net "Add Aspects to Object Using Dynamic Decorator" (http://www.codeproject.com/KB/architecture/aspectddecorator.aspx). I believe you can write a similiar one for Java.
If you are using some one framework for aspects there can be some performance issues .Next if you are creating abstraction above some one framework and aspects handling is done from framework then its very difficult to find out the cause of the problem relating to performance issues . If you are really concern about performance and small time slice concern more ,i suggest to write own aspects .No one want to reinvent the wheel but sometime for better it can be best.You can write own implementation of AOP alliance abstraction .
i have used spring AOP in a batch process in my current project to transaction manage a database.
At first, it was figured that there wouldn't be a performance problem, but we didn't figure into the equation that we called the database thousands of times. one aspect call in aop doesn't affect performance much, but multiply that by thousands, and it turns out the new system was worse than the old one, due to these extra method calls.
I'd say that aop is a great system to use, but try to take note on how many methods calls are added to your application