Volunteer for Java Development

[Sarkar]

Hi,

I'm looking for a project to volunteer some time on doing some Java
development. If you know of something, please let me know.

Interested to work on Struts, Spring, Hibernate framework...

regards, Amit J.

 

[Roedy Green]

Interested to work on Struts, Spring, Hibernate framework..

see http://mindprod.com/jgloss/sourceforge.html

fill in "Struts Spring Hibernate volunteer" in the search box.

 

[Lew]

Sarkar wrote, quoted or indirectly quoted someone who said :

see http://mindprod.com/jgloss/sourceforge.html

fill in "Struts Spring Hibernate volunteer" in the search box.

In addition to that, just snooping around the web sites of Apache projects and other such exposes you to a whole lot of good code (and some to not-so-good code). There are a gazillion open-source projects out there. You have to decide for yourself the worthiness of each. The best have ample documentation, both operational and Javadocs, wikis, good packaging and other signs of professionalism.

 

[Sarkar]

Hi Roedy and Lew,

Thanks for reply...

Its not like I just want to work on struts/spring/hibernate community.
Re-correcting my sentence, I have shown interest to any _open-source_
project which is build on top of struts, spring and hibernate
framework.

If you know any of them please suggest...

regards, Amit J.

 

[Lew]

Its not like I just want to work on struts/spring/hibernate community.
Re-correcting my sentence, I have shown interest to any _open-source_
project which is build on top of struts, spring and hibernate
framework.

If you know any of them please suggest...

http://lmgtfy.com/?q=Open-source+project+with+struts+spring+hibernate

Why those particular frameworks? There are others, and better, so why do you focus on those?

Hibernate is not the only JPA player in town, and if you use old-style (pre-
JPA) Hibernate you won't have as good an experience. Use OpenJPA or
EclipseLink.

Struts is obsolete. Use JSF.

Spring sucks.

Why not use good stuff instead?

 

[Roedy Green]

Struts is obsolete. Use JSF.

I was told JSF has hugely more overhead.

 

[Arved Sandstrom]

I was told JSF has hugely more overhead.

What kind of overhead?

1) Size or number of JARs? The days of few and small JARs were over with
many years ago. Besides, assuming reasonable overall size, what does the
exact number of JARs matter anyway? These days a fair few application
servers bundle a suitable JSF implementation; failing that you can
install one server-side; failing that the worst case is that each one of
your web apps that needs JSF grew by a few percent because you had to
include JSF libraries in the WAR. Big deal.

Rather more of an overhead concern would be trying to figure out for any
web app framework *which* JARs to include. This question doesn't get
much simpler than it is for JSF.

2) Application configuration? It doesn't get much easier actually. A
decent IDE will fire out a useful minimal faces-config.xml that you
barely need to touch with JSF 2.0. There's very little configuration
that you need to do prior to starting actual coding of JSF stuff for
your application.

I can myself go a long ways with a nearly empty faces-config.xml.

3) Page complexity?

Let's say that you're using Facelets XHTML pages, which are now included
in JSF. That's absolutely not more complicated than JSPX. If you were
comparing to the use of Spring MVC for your web app framework, with
Velocity as your view technology, JSF Facelets would definitely not be
more complicated. If you were comparing to the use of Struts 2 with,
say, Freemarker as the view technology, JSF Facelets are definitely not
more complicated.

There's no free lunch with any of these view technologies. Provided that
they cleanly separate concerns, which pretty much all of them can do,
the amount of work that a body has to do to define elements in a page,
and their bindings, is comparable.

4) API complexity?

All of the web framework APIs are large, JSF is no exception. But how
much do you need to get a lot done? It seems to me, that once you've
made a decision about component scope, or about a navigation case - all
of which are necessary in *every* web app, including ones that don't use
a framework at all - the translation of those decisions into working
code in JSF is about as easy as it gets. A handful of simple
annotations, and use of JSF 2 implicit and conditional navigation [1],
and you're off to the races.

It seems to me that the same people who make statements about overhead
are the same ones that bandy about terms like "lightweight". In either
case they usually don't even know what they mean.

AHS

1. I fall into the camp of JSF developers that has absolutely no qualms
about hard-coding an implicit navigation rule into a Java action method
in a JSF managed bean. I've seen some commentators state that this
"ties" business objects into the navigation model. They're wrong.

 

[Sarkar]

Hi All,

Thanks for replies...

My initial question wasa : looking for any open source java project to
do some voluntary developement work (prefered project which are build
on top of ayny of framwork like struts/hibernate/spring reason feel
more comfortable on them because having small experience on them).

regards, Amit J.

 

[Arved Sandstrom]

"Lew" wrote in message


Care to elaborate on that postulation?

I'll phrase this differently: Spring is now unnecessary.

It was never _necessary_ - God knows I did enough J2EE 1.2 and 1.3
projects without it. I'm still doing some J2EE 1.4 work but fortunately
those app servers are actually hybrids with EJB 3 support; but all that
is without Spring also.

I have done Spring projects, and I'll be the first one to concede that
back in the day a Spring app with selected good bits of J2EE was (1) a
good way to go, and (2) maybe _the_ way to go. This heyday of Spring
really corresponds to Spring 1.x (e.g 1.2.6 that won justified awards
came out in 2004).

But here's the thing, IMO. With Java EE 5 (2006), Spring (2.0 in Oct
2006, 2.5 in Nov 2007) already became substantially less "necessary",
and less useful. Now, if you were already committed to Spring I would
not have recommended a switch over to Java EE 5, necessarily. But new
adopters of anything would usually have been as happy with Java EE 5 as
with Spring.

And now with Java EE 6 (a year ago) and the best Java EE 6 app servers,
Spring (now up to 3.x) is completely unnecessary.

To be fair Spring people would probably say that Java EE 6 is
unnecessary - except for the component bits that they've liked to use
all along.

This has now become a comparison of two application frameworks that
solve the same problems roughly equally well. By "roughly" I do mean
"roughly" - I personally believe that a full-blown Spring app is
considerably more work to set up than a Java EE 6 application (which may
be part of the reason for Lew's comment). But certainly both can
competently solve the same problems.

The only valid comparison is that done by an individual. I have a
minimal application that I keep in my head that I use to proof Java EE
app servers: when I do the eval I create the app from scratch.
Configuring the app server from scratch is also part of it. Elements of
this proof app are:

1. Reasonably complex front-end, maybe 10-15 Facelets XHTML pages, a
good mix of JSF managed beans in different scopes;

2. A number of stateless and stateful session beans, maybe half a dozen
total;

3. JPA (EclipseLink) and perhaps half a dozen Oracle XE or PostgreSQL
tables;

4. log4j logging;

5. JMX;

6. JMS with one or two MDBs;

7. scheduling (e.g. Quartz or EJB 3.1 timers);

8. web services.

What I would consider to be a good comparison would be to create
essentially the same app with Spring. Since I haven't done this
experiment for a while I think I will go ahead and do it for giggles.
Off the top of my head I'd use Spring Framework 3.x, JPA 2 with
Hibernate (to introduce some extra difficulty, but also because most
people use it), Jetty or Tomcat as the web server (could go Spring MVC
also), probably Atomikos for transaction support (so it'll support JMS
and JPA provider transactions), maybe Wicket for the presentation but
maybe Freemarker with Spring MVC. Other bits like log4j and JMX (the
Spring way) being substantially the same.

I've used Spring Security (which used to be Acegi) before, and IMHO
compared to Java EE security or something like Apache Shiro the Spring
stuff is bloatware, but I'll use it because it's Spring. The Spring-WS
will make use of Spring Security. OTOH Apache Shiro does have good
Spring integration so I might look at that too.

I haven't done Spring this extensively in a few years, although I've
dabbled to keep up, so it'll take longer, and it won't be polished. But
I think I'll end up with something at the end of it that I can look at
and fairly compare to a comparable Java EE 6 job. Part of my paid job is
technical evals so I think I can be reasonably dispassionate about it.

One thing that pops out, and it's one reason I described my thinking, is
that with Java EE - let's assume you've selected a decent Java EE6 app
server - you *have* the stack. With Spring you basically build it, from
a wide variety of available pieces. Ask the question: for someone
relatively new to either technology stack, what's the safer bet?

I'll add one thing - if Spring was *ever* "lightweight", that was over
half a decade ago. But the Spring team still pushes that absurd message:
it is one reason I do have a bias against Spring. It's misleading and
it's wrong. And let's keep in mind, SpringSource is a substantial
company, owned by VMWare for over 2 years, which in turn was acquired by
EMC back in 2004. If there ever was any motivation to keep Spring and
its family clean and small and elegant (and I'd argue that back in the
1.x days it was close), that's down the toilet now: everything about
bloatware that Spring boosters ascribe to Java EE 6 offerings is also
inherent in Spring 3.x.

AHS

 

[Lew]

"Lew" wrote in message


Care to elaborate on that postulation?

Conclusion, not postulation.

I have used Spring on mnay projects. It was always a tangled mess of obscure
references to extrinsic resources to obfuscate logic. This may not be Spring's
fault, but it's a consistent result.

Java EE annotations do everything Spring hopes to, only better, more simply,
with a more flowing mental model, in accordance with the standard.

Slam-dunk, BOOYAH!

Why add yet another framework that provides no additional benefit? Burden of proof - you.

 

[Lew]

I was told JSF has hugely more overhead.

Than Spring? Not in my observation. JSF is much easier to use.

What kind of overhead were you _told_ that JSF introduces?

I have always found it to radically accelerate development, by something like five to one compared to other flows I've used except for Struts, but with much more expressive power and greatly reduced deployment effort. The XHTML variant works even better than the JSP variant.

Really, JSF is a _tour de force_, and with the Tomahawk library there's little you cannot accomplish in the UI. (Other libraries also exist for JSF.)

Plus it's part of the JSF standard. Actually it's any _other_ framework that would have to be considered "overhead", since JSF already comes with. Someone told you exactly backwards.

 

[Sarkar]

Hi All,

Any suggestion for project name where I can contribute?

regards, Amit J.

 

[Tom Anderson]

What kind of overhead?

4) API complexity?

All of the web framework APIs are large

No. Stripes is pretty small.

I've never used JSF, so i have no first-hand evidence. By way of
second-hand evidence, i see a lot of questions on forums from people who
are struggling with some aspect of JSF. I very rarely see questions like
that for action-style frameworks like Struts or Stripes, despite the fact
that such frameworks are very widely used.

Also, correct me if i'm wrong, but doesn't JSF (like other component-style
frameworks) make it harder to precisely control the HTML than action-style
frameworks? The last project i did used an action-style framework. Our web
designers sat down and cranked out finely-tuned HTML for the site, taking
care to make it lean, semantic, portable across browsers, SEO-friendly,
etc. We programmers could pick up their static mockups and made minimal
changes to make the appropriate bits dynamic - replacing a hardcoded value
with a ${}, an <input> with a <webframework:input>, and so on. Can you do
that with JSF?

tom

 

[Arved Sandstrom]

No. Stripes is pretty small.

I've never used JSF, so i have no first-hand evidence. By way of
second-hand evidence, i see a lot of questions on forums from people who
are struggling with some aspect of JSF. I very rarely see questions like
that for action-style frameworks like Struts or Stripes, despite the
fact that such frameworks are very widely used.

I've seen this also. I've encountered a number of people who were/are
top-notch users of frameworks like Struts, and when they had to do their
first JSF project they stumbled, sometimes badly.

I'm really not sure why, other than that these folks are getting
discombobulated by minutiae and don't see the forest for the trees. When
all is said and done the frameworks are mostly all MVC and people
shouldn't be getting all twisted over minor details, and basically the
differences - in the big scheme of things - are minor details.

I don't know how much weight you can put on who is struggling with what,
based on forums volume. It depends on a bunch of factors. All I know,
having used a variety of view technologies and a variety of web
frameworks, is that with the exception of JSPs (even JSPX) as a view
technology, I've found that any competent developer can readily make any
of them work to solve the front-end problem. My personal belief is that
anyone with significant experience who is still having problems with
framework X, or seriously hates view technology Y, that they're copping
an attitude rather than solving real problems.

Just my 2 cents. I have personal biases, sure - I would rather use
ASP.NET MVC than JSF (or any of the Java web frameworks), but if someone
told me that my next contract involved Struts 1 I'd go ahead and do it.
In fact I just finished a project where another team on the project
*did* use Struts 1; they weren't moaning about it. And everyone on that
team has also done extensive work with JSF and they don't moan about
that either.

Not venting at you, Tom, just venting in general. I get so tired of
people who bitch about web frameworks and view technologies but can't be
bothered to learn how to do proper requirements analysis or design or
learn up on how to code properly down in the business logic and
persistence layers.

Also, correct me if i'm wrong, but doesn't JSF (like other
component-style frameworks) make it harder to precisely control the HTML
than action-style frameworks? The last project i did used an
action-style framework. Our web designers sat down and cranked out
finely-tuned HTML for the site, taking care to make it lean, semantic,
portable across browsers, SEO-friendly, etc. We programmers could pick
up their static mockups and made minimal changes to make the appropriate
bits dynamic - replacing a hardcoded value with a ${}, an <input> with a
<webframework:input>, and so on. Can you do that with JSF?

tom

I can change how a component is rendered, but in 4 odd years of using
JSF I've had the need to do that myself exactly zero times. The
available components, including a few fairly esoteric ones (not the
publicly available *Faces sets), have done the trick.

I honestly don't know why the usual JSF components need to be tailored.
They generate very simple HTML actually, and using best practices you
style with CSS. JSF people also tend to do a lot of their tuning with
carefully crafted Facelets components, themselves suitably styled. And
when all is said and done, if you absolutely need very precise control
over some UI element appearance you can "pair up" a visible standard
HTML element and a JSF component, the latter handling the JSF action via
JavaScript.

Again, I've not run across a situation where I couldn't make a page look
like I wanted. Without too much agony.

AHS

 

[Tom Anderson]

Conclusion, not postulation.

I have used Spring on mnay projects. It was always a tangled mess of obscure
references to extrinsic resources to obfuscate logic. This may not be Spring's
fault, but it's a consistent result.

Java EE annotations do everything Spring hopes to, only better, more simply,
with a more flowing mental model, in accordance with the standard.

That is not *quite* true.

CDI replaces some of the fundamental bits of Spring: the dependency
injection, and AOP. Done and dusted.

You could argue that JSF replaces Spring MVC. I don't think it does,
because Spring MVC is an action-style framework, and JSF is a
component-style framework. Rather different beasts. There is no
EE-standard action-style framework, so there is no genuine EE replacement
for Spring MVC. There are other action-style frameworks that are smaller
than spring MVC and more aligned with EE (Stripes with the injection
enhancer, perhaps), so you could argue that modern EE lets them make
Spring MVC obsolete.

But there are many other bits of Spring.

Security? Does JAAS and friends cover everything Acegi does? Don't think
so.

Web Flow? It's a sort of wizard-based web framework. Does JSF address
that? Don't know. Does it address it within an action-based framework? No.

JDBC templates? They're simple, but they apparently really simplify JDBC
programming (for people who need to do raw JDBC).

Spring Integration? Web Services? Batch? I have no idea what they do. I
would be very surprised if *everything* they did was now covered by EE.

So, whilst i agree that EE now does everything the Spring *core* hopes to,
better and more simply, i think there are other bits of Spring which may
still be useful. If the Spring guys have a clue, they will adapt them to
work with EE's DI and AOP mechanisms. Spring has always been a layer on
top of EE; as EE gains the ability to do certain things well, Spring can
simply evolve to do other things.

Which is not to say that Spring is the only way of doing these things, or
is, or will remain, the best way!

tom

 

[Arved Sandstrom]

That is not *quite* true.

CDI replaces some of the fundamental bits of Spring: the dependency
injection, and AOP. Done and dusted.

You could argue that JSF replaces Spring MVC. I don't think it does,
because Spring MVC is an action-style framework, and JSF is a
component-style framework. Rather different beasts. There is no
EE-standard action-style framework, so there is no genuine EE
replacement for Spring MVC. There are other action-style frameworks that
are smaller than spring MVC and more aligned with EE (Stripes with the
injection enhancer, perhaps), so you could argue that modern EE lets
them make Spring MVC obsolete.

I just don't see the web framework as being something that is part of
Java EE, I really don't. Servlet API yes, web framework no. I'm content
that there's a wide choice list out there, and I'd prefer none of them
to be considered as "standard".

But there are many other bits of Spring.

Security? Does JAAS and friends cover everything Acegi does? Don't think
so.

It's sort of apples and oranges, that. "JAAS and friends" are a
foundation, and there isn't much at all that you can't do with them. But
much of the "final mile" stuff needs to be coded up. That's one reason
security frameworks like Spring Security (Acegi really, it was Acegi's
original motivation) and Apache Shiro have appeared.

This of course is something that we've seen before with "standard" Java
APIs, that they supply the API but a weak or non-existent
implementation. Logging has this problem, XML parsing had this problem,
JAAS is sort of in the same ballpark insofar as to customize and shape
the actual solution a fair bit of coding may be needed.

Another motivation behind Acegi and Shiro was ease of use - a lot of
developers struggle with JAAS. They could do what they need to do with
JAAS, they just struggle. My feeling, having used both, is that Shiro is
better than Acegi at ease of use.

I'll bet you though that 90 percent of developers using Spring Security
are solving application security problems that are actually readily done
with JAAS.

Web Flow? It's a sort of wizard-based web framework. Does JSF address
that? Don't know. Does it address it within an action-based framework? No.

I'm not familiar with Web Flow, but part of what it addresses - page
navigation and navigational/conversational state - is very much also a
JSF thing.

On the action-based thing, I think it's worth pointing out that JSF
components aren't involved in the 'C' in MVC. Sure, the components are
sources of action events, but the actual controller logic isn't all that
dissimilar to Struts: you've got an ActionServlet or a FacesServlet
that's (leaving aside filters) the first point of processing for an
incoming request, and further handling is handed off to "actions". We
actually call them actions in Struts, and you have a method in an action
class that is executed; in JSF it's precisely the same as you have a
method in a class that gets executed.

A lot of the things that happen in JSF phases (once the FacesServlet has
started to process the request) are peculiar to the component
processing, and are orthogonal to the "action" type processing that
happens in the JSF INVOKE_APPLICATION phase. Also, navigation concerns
*are* addressed during this "action" phase of JSF.

JDBC templates? They're simple, but they apparently really simplify JDBC
programming (for people who need to do raw JDBC).

No doubt. I've been in situations where I'd prefer iBatis/MyBatis to
JPA. JPA is nice stuff as far as I am concerned but it's not ideal for
100% of all circumstances.

Spring Integration? Web Services? Batch? I have no idea what they do. I
would be very surprised if *everything* they did was now covered by EE.

I'd hope the web services stuff *is* covered by Java EE. I can't think
of anything I've needed to do with web services that isn't covered by
Java EE.

I'm not familiar with Spring Integration or Batch, but a quick skim at
docs tells me that Spring Integration is about external systems, and it
sure looks like aspects of ESBs are being incorporated also. Java EE
does a lot of that, with things like resource adapters and JMS and what
have you. For the other aspects I'd expect to use (and do frequently
use) Java EE to SOA-enable an application and then use existing ESBs to
handle the enterprise messaging and routing and transformations and so
forth. Can't expect Java EE to do everything - big bits of SOA are not
covered by Java EE.

So, whilst i agree that EE now does everything the Spring *core* hopes
to, better and more simply, i think there are other bits of Spring which
may still be useful. If the Spring guys have a clue, they will adapt
them to work with EE's DI and AOP mechanisms. Spring has always been a
layer on top of EE; as EE gains the ability to do certain things well,
Spring can simply evolve to do other things.

The original fundamental motivation for Spring, and a good one it was,
was that EJBs sucked. How do you look them up with JNDI, how do you
configure them, how much boilerplate do you have to write for each
component, an intrusive and frequently unnecessary distributed object
model, etc etc - old-style EJBs sucked.

Spring basically was originally about being able to give POJOs
J2EE-style services, like transactions, in a much less complex fashion.
And it more or less succeeded in being a lot better than J2EE 1.2 and
1.3, probably even 1.4. It clearly made sense then to use those parts of
J2EE that worked, like servlets, and so all that was a happy combination.

I digress in this fashion to indicate that I don't think Spring was a
layer on top of EE, I think it is a distinct enterprise application
framework that right from the gitgo has used solid parts of EE. But now
that Java EE does pretty much all that you really need, the guts of
Spring are not necessary.

So now it's pure competition: Spring versus Java EE.

Which is not to say that Spring is the only way of doing these things,
or is, or will remain, the best way!

tom

Just my opinion, but the Spring team started losing its way back with
2.x. And with 3.x they are completely adrift. J2EE/Java EE has been
moving in the right direction from a rocky start; Spring started out
relatively simple and clean, and now that entire ecosystem is a rambling
mess.

AHS

 

[Arne Vajhøj]

in message


Care to elaborate on that postulation?

Spring today is a bundle of many different pieces of software.

Spring started as a simple DI/IoC framework. But then they started
adding stuff. They must somehow want to make it possible writing
a full app only using Java SE and Spring.

The added stuff are of varying quality.

It has certainly become very huge with the consequence of being
difficult to keep overview.

Certain things has been replaced by standard features in
Java EE 5 and 6.

Some Spring users go completely overboard in using Spring
resulting in very cluttered code.

I don't think Spring sucks.

But I do think that some of Spring sucks.

And I think that a large portion of actual Spring usage
sucks per the above reasons.

Arne

 

[Arne Vajhøj]

Conclusion, not postulation.

Th difference between postulation and conclusion without the arguments
seem rather small to me.

I have used Spring on mnay projects. It was always a tangled mess of obscure
references to extrinsic resources to obfuscate logic. This may not be Spring's
fault, but it's a consistent result.

I have seen that too.

Java EE annotations do everything Spring hopes to, only better, more simply,
with a more flowing mental model, in accordance with the standard.

Slam-dunk, BOOYAH!

Why add yet another framework that provides no additional benefit? Burden of proof - you.

That argument is a little thin.

There are things in Spring that Java EE annotations does not.

And besides that there are also something weird called Java SE apps
that does not benefit much from stuff provided by Java EE containers.

Arne

 

[Arne Vajhøj]

I was told JSF has hugely more overhead.

Latest version of JSF is bigger than a web framework from
10 years ago.

But I don't think it is bigger than other current "big"
frameworks.

And since JSF is a spec with multiple implementations, then
it dos not make much sense to talk about the performance of JSF
as such.

So no hugely more overhead.

Arne

 

[Arne Vajhøj]

No. Stripes is pretty small.

I've never used JSF, so i have no first-hand evidence. By way of
second-hand evidence, i see a lot of questions on forums from people who
are struggling with some aspect of JSF. I very rarely see questions like
that for action-style frameworks like Struts or Stripes, despite the
fact that such frameworks are very widely used.

JSF is a true JCP product for good and bad.

It can be a bit complex to learn to use properly.

JSF + no will to spend time learning the tool = disaster

But when one has done the necessary studies, then it is not
difficult to use.

Also, correct me if i'm wrong, but doesn't JSF (like other
component-style frameworks) make it harder to precisely control the HTML
than action-style frameworks? The last project i did used an
action-style framework. Our web designers sat down and cranked out
finely-tuned HTML for the site, taking care to make it lean, semantic,
portable across browsers, SEO-friendly, etc. We programmers could pick
up their static mockups and made minimal changes to make the appropriate
bits dynamic - replacing a hardcoded value with a ${}, an <input> with a
<webframework:input>, and so on. Can you do that with JSF?

I would say that it depends on the JSF components you decide to use.

If you use the simple 1:1 JSF component-HTML tags, then you can
design the HTML as you want.

An using facelets can actually make the XHTML files be valid and
editable by HTML people XHTML.

If you use some more high level JSF components (incl. extra non
standard components), then you loose control over the HTML (but
may be able to get something done faster).

Your choice.

Arne