Google open-sourcing their servlet engine (sort of)(google-opensource.blogspot.com)
google-opensource.blogspot.com
Google open-sourcing their servlet engine (sort of)
http://google-opensource.blogspot.com/2009/01/opengse-released.html
23 comments
They should have used Google Guice! I haven't used it, but it sounds like an interesting framework:
http://video.google.com/videoplay?docid=2948853912335655747&...
http://video.google.com/videoplay?docid=2948853912335655747&...
[deleted]
Quoting from the article, this sums it up:
"For folks outside of Google, there's really no compelling argument to drop Apache Tomcat/Jetty, etc. in favor of OpenGSE's reference servlet engine, but anyone interested in servlet engine and servlet spec compliance would have a fantastic learning resource available to them"
"For folks outside of Google, there's really no compelling argument to drop Apache Tomcat/Jetty, etc. in favor of OpenGSE's reference servlet engine, but anyone interested in servlet engine and servlet spec compliance would have a fantastic learning resource available to them"
I think they are really trying to discourage usage. It used to be a nice, fast, and simple http server (when it was originally written), but from a quick look it appears that they made all "enterprisy" with FactoryFactories and whatnot.
Java the language is ok, but I the culture is dangerous.
Java the language is ok, but I the culture is dangerous.
I've heard this sentiment echoed numerous times (esp. by people who love Python).Could you guys clarify more as to the different things to keep in mind while writing "good" Java? Are there examples of Java projects you'd consider good and worth learning from?
As far as Python (and dynamic languages in general) goes, I haven't heard any good responses to Ted Dziuba's blog post: http://teddziuba.com/2008/12/python-makes-me-nervous.html I can see that a startup would prefer Python/Ruby to Java, but what about bigger projects?
As far as Python (and dynamic languages in general) goes, I haven't heard any good responses to Ted Dziuba's blog post: http://teddziuba.com/2008/12/python-makes-me-nervous.html I can see that a startup would prefer Python/Ruby to Java, but what about bigger projects?
Apache Lucene, Solr and Wicket are all great, light-weight open source Java projects.
Ted Dziuba's argument doesn't seem to be Java vs. Python for large projects - it's more statically typed vs. dynamically typed languages and checked vs. run-time exceptions - or compile-time error checking vs. run-time error checking.
There are several large companies that use Python for X and Java for Y. I don't think either language has significant advantages for large projects that the other doesn't have, assuming that developers can utilize the strengths of the language. I was working with someone who wanted to implement a prepaid card application (the ultimate enterprisy app) and his biggest objection to using Python was the inability to find Python developers in India. He was going to pay the bills, and I didn't have a counter-argument.
Ted Dziuba's argument doesn't seem to be Java vs. Python for large projects - it's more statically typed vs. dynamically typed languages and checked vs. run-time exceptions - or compile-time error checking vs. run-time error checking.
There are several large companies that use Python for X and Java for Y. I don't think either language has significant advantages for large projects that the other doesn't have, assuming that developers can utilize the strengths of the language. I was working with someone who wanted to implement a prepaid card application (the ultimate enterprisy app) and his biggest objection to using Python was the inability to find Python developers in India. He was going to pay the bills, and I didn't have a counter-argument.
Dziuba says "In Java, static typing makes the method signature into a recipe: it's all the shit you need to make this method work."
What definition of "work" are we using?
He also write "As a programmer in a team, you need rules. You need structure. You need order."
Some of us think that the rules matter, that it's not just having rules, but having the right rules.
What definition of "work" are we using?
He also write "As a programmer in a team, you need rules. You need structure. You need order."
Some of us think that the rules matter, that it's not just having rules, but having the right rules.
His definition of "work" appears to be "compile".
I presume that in most cases FactoryFactories exist for testability, and aren't created just to check that off on the enterprise checklist ;)
Once you get many "enterprisy" minds, they will be screwing stuff badly. Startups usually proven to build nice and simple solutions, without fat. ;-)
"the culture"
There is no single Java culture.
There is no single Java culture.
Agreed, but I think paul is referring to the most prevalent culture, which, unfortunately, has a tendency to over-engineer.
Here's a completely unscientific comparison:
Java: http://www.google.com/codesearch?hl=en&lr=&q=Factory...
Python: http://www.google.com/codesearch?hl=en&lr=&q=Factory...
Here's a completely unscientific comparison:
Java: http://www.google.com/codesearch?hl=en&lr=&q=Factory...
Python: http://www.google.com/codesearch?hl=en&lr=&q=Factory...
I understand what he was referring to... but there is a pretty big part of the Java world where things are actually kind of slick. So I don't like seeing such a blanket and semi-derogatory statement.
We probably have different definitions of "slick". Nevertheless, I'm curious where I can find this slick code just in case...
BTW, I'm not just randomly bashing Java. I've actually been using it since 1995, worked briefly at Sun/Javasoft, started one of the largest Java projects at Google, and used to like programming in it. However, the trend that I've noticed is that I like Java less and less because the culture has fallen into a degenerate process of building towering abstractions. Put simply, their metric of "good" seems to be very different from mine.
BTW, I'm not just randomly bashing Java. I've actually been using it since 1995, worked briefly at Sun/Javasoft, started one of the largest Java projects at Google, and used to like programming in it. However, the trend that I've noticed is that I like Java less and less because the culture has fallen into a degenerate process of building towering abstractions. Put simply, their metric of "good" seems to be very different from mine.
Well I'm only on my fifth year with it (at work) so maybe I have not been given as much a chance to get disillusioned.
It's not my choice "as a language": I can't stand using Java with just a text editor whereas that's very nice with Python for example. I'm talking more about the platform. Spring (the small focused parts of it like IoC and AOP), Hibernate, Terracotta, Lucene, Jetty, YourKit, Clover, and many of the OSGI/JMX deployment solutions are all just polished, productive and out of the way to me with very nice integrations into my IDE. Yeah, IntelliJ -- that's probably a big part of my ability to like Java, to be honest.
I'm with you on the abstractions thing, I've avoided J2EE etc.
It's not my choice "as a language": I can't stand using Java with just a text editor whereas that's very nice with Python for example. I'm talking more about the platform. Spring (the small focused parts of it like IoC and AOP), Hibernate, Terracotta, Lucene, Jetty, YourKit, Clover, and many of the OSGI/JMX deployment solutions are all just polished, productive and out of the way to me with very nice integrations into my IDE. Yeah, IntelliJ -- that's probably a big part of my ability to like Java, to be honest.
I'm with you on the abstractions thing, I've avoided J2EE etc.
I can't stand using Java with just a text editor
Same here and imho that's quite an alarming indicator for the "towering abstractions" that paul mentioned. When you can't realistically navigate a significant codebase without tool support anymore then many of the components just aren't "out of the way" as much as they used to be or should be. Personally I jumped ship when java went through the heights of its XML disease which is apparently cooling down nowadays. The available toolchain (part of which you mentioned) is mighty impressive, no question. But it's the amount of boilerplate- and meta-code required to glue the stuff together that's driving many of us away.
Same here and imho that's quite an alarming indicator for the "towering abstractions" that paul mentioned. When you can't realistically navigate a significant codebase without tool support anymore then many of the components just aren't "out of the way" as much as they used to be or should be. Personally I jumped ship when java went through the heights of its XML disease which is apparently cooling down nowadays. The available toolchain (part of which you mentioned) is mighty impressive, no question. But it's the amount of boilerplate- and meta-code required to glue the stuff together that's driving many of us away.
"Towering" implies unweidly or disorganized to me and there are certainly parts of the Java world like that -- to be avoided.
The number of abstractions/libraries seems irrelevant to the discussion if they can indeed be out of your way (you're saying because of all the boilerplate etc. that they aren't, so I guess we're talking about different things). If they're powerful and there's a small surface error for dealing with them then great, that's a high return on investment situation.
Getting to that small surface error takes an IDE sometimes which is unfortunate on some level but I don't find anything fundamentally wrong with it.
Personally, I can't stand even simple programs in Java with a text editor because of the amount of subdirectories you need to suddenly be aware of... org/blah/blah/blah/blah/blah (this is how I learned it originally).
The number of abstractions/libraries seems irrelevant to the discussion if they can indeed be out of your way (you're saying because of all the boilerplate etc. that they aren't, so I guess we're talking about different things). If they're powerful and there's a small surface error for dealing with them then great, that's a high return on investment situation.
Getting to that small surface error takes an IDE sometimes which is unfortunate on some level but I don't find anything fundamentally wrong with it.
Personally, I can't stand even simple programs in Java with a text editor because of the amount of subdirectories you need to suddenly be aware of... org/blah/blah/blah/blah/blah (this is how I learned it originally).
Well, it's been a while since I left the java world. Back then it was all about "inverse of control", Spring and the ilk, and maven was starting out. People were basically competing about who can move the most code from java files to xml descriptors and who had the smartest pom.xml...
Maybe things have bettered since then but from what I see at least the maven disease seems to still be all over the place. I'm not saying that all these things are necessarily bad. I just grew really tired of juggling monstrous xml blobs around while still being forced to write (or generate) metric tons of boilerplate code.
Maybe things have bettered since then but from what I see at least the maven disease seems to still be all over the place. I'm not saying that all these things are necessarily bad. I just grew really tired of juggling monstrous xml blobs around while still being forced to write (or generate) metric tons of boilerplate code.
I want to call out Terracotta especially.
Time to update the project README?
http://code.google.com/p/opengse/source/browse/trunk/README....
... (This is currently a hidden project with members-only access; a Google Account is required in order to become a member and access it.)...
Edit: They just fixed it. The power of open-source.
http://code.google.com/p/opengse/source/browse/trunk/README....
... (This is currently a hidden project with members-only access; a Google Account is required in order to become a member and access it.)...
Edit: They just fixed it. The power of open-source.
Yep. It's obviously not hidden :-)
"... raw HTTP processing and a shell which wraps that inner core and ... the compliance shell... this compliance shell can wrap our internal corporate version, the Google Servlet Engine, ..."
Something wraps something that wraps something else. Sounds familiar from what I've seen in my office. Coincidentally, most developers in my workplace swears by Java.
Something wraps something that wraps something else. Sounds familiar from what I've seen in my office. Coincidentally, most developers in my workplace swears by Java.
http://code.google.com/p/opengse/source/browse/trunk/transpo...