Home

I attended the JavaOne show this week, after a 4 year gap. What a difference - who knew Java could be so boring? On the other hand, this is what it feels like to go to a show for a technology that has lost half of its market share in the last 4 years (at least when measured by O'Reilly book sales - not a particularly reliable source but better than no source at all. [Editor's note: note that other publishers' data offers different data, and job posting boards also indicate that this isn't the case.]) If you don't like that source, check out Andi Gutman's recent post that Java is losing the battle for the modern web. [Editor's note: see TSS' post on the same subject, as Andi's slightly biased.]
Aisle after aisle was populated almost solely by people in ugly sports shirts wearing a vacant gaze that we all reserve for particularly humiliating situations. In fact, the only booth which seemed to have any mojo was the - you guessed it - schwag booth from Sun.
This morning, I found out what was wrong. I got one of those delightful ALL CAPS emails from JavaOne informing me that we had all been the subject of a viral attack by the dreaded Norovirus. So that was it!
There is something seriously wrong, not just with JavaOne, but with Java. After 10 years, Java remains an extremely complex development environment with nothing even approaching an easy learning curve. Microsoft has gleefully filled this vacuum, driving a vast J2EE to .Net migration at the low end of the market that nobody in the Java world seems willing to acknowledge.
The Sun promise to put Java runtimes everywhere is meaningless if nobody wants to develop for those runtimes. Adobe and Microsoft are doing a far better job making their tools simple enough for mere mortals and focusing on the presentation layer.
Here is my prescription for curing the Java Flu:

Fight for the low end: in modern warfare, death may come from above. In technology, death comes from below. Ten years from now, who will have more power over IT - web designers or core developers? If Microsoft and Adobe win the designers today, Java developers will be the COBOL developers of tomorrow.

Make Java easier to get started with: something is wrong when very useful but also very complex code frameworks like Spring are considered the "easy" way to do Java development. Java needs to be easy enough for your mother to build her web-based phone list with it. I'm talking Hypercard/Filemaker/Access easy.

Make Java prettier: just put a bullet in JavaFX and adopt something with momentum like Dojo or Ext. If you just can't stomach Javascript, then adopt GWT.

Make Java fun: can't do this without doing the first three items. For an example of one attempt to make Java easy, check out the WaveMaker download.

Well, TSS readers? Pretty harsh words - and while I'm not sure "being the next COBOL" is the epithet that I think it's meant to be here, it's probably not what people want, either. What do you think?

It is true to some degree. I admit that front end development is kind of pain in Java. I am talking about web front end here. Asp.net is not necessarily better than JSF. It is just that you have a much better IDE for Asp.net than for JSF. For a lot of small applications, drag and drop makes a lot of sense. There is no need to use some many tiers for small apps. There are a few JSF IDEs out there. None of them is remotely comparable to MS studio in terms of smoothness. Without that IDE, .NET would be nothing.
That is why people are switching to Adobe Flex. Java only lacks in the front end development area. For the middle tier, I prefer Java over .NET any day. The author mentioned "Spring". I believe Spring has been ported to .NET. Spring does have a MVC framework. But it is not what you use Spring for. Spring's strengths lie in the middle tier. And if it is difficult to use in Java, it is difficult in .NET too since .NET has 0 advantage over Java in the middler tier.
A few good things here I like about java
1: The community is so large that you do NOT need to buy a book to learn java.
2: The community is so vibrant that you can find quality free open source of almost anything from app servers to orms. For a small web app, it can be implemented in a total ly free stack that consists only of quality open source programs.
The stack I prefer now is Flex + Spring + Ibatis/Hibternate

I admit that front end development is kind of pain in Java. I am talking about web front end here. Asp.net is not necessarily better than JSF. It is just that you have a much better IDE for Asp.net than for JSF. For a lot of small applications, drag and drop makes a lot of sense.

Hi Yan,
Have you tried JSFToolbox for Dreamweaver? We developed this suite of design and coding extensions in response to what we felt was a lack of web designer-friendly tools for JSF development.
Personally, I really enjoy designing the UI for my JSF projects in Adobe Dreamweaver. Many of our customers have also found this change agreeable. JSFToolbox supports drag-and-drop, UI component binding, backing bean introspection, and many other features.
Ian Hlavats
--
Read my article on JSFCentral.com - Designing User Interfaces with JSF, Dreamweaver, and the JSFToolbox

Both Grails and Flex are good suggestions - my main point is that Java shouldn't cede the front end. If you want to make Java truly accessible to all programming levels, an integrated solution (MS Access for Java) is needed, but that is by no means the only way to go (and truly visual development environments are often annoying to hardcore coders).

Nobody need to learn anything other than writing an object.
All Stuff whatever we have learned may not be needed.
I dont think in future ..anybody needs to learn much in Java and enterprise technologies as such.
Everything would be simple and flexible.

Well, TSS readers? Pretty harsh words - and while I'm not sure "being the next COBOL" is the epithet that I think it's meant to be here, it's probably not what people want, either. What do you think?

The problem are not harsh words: the problem is that they are just plain unsupported assertions (and, oh my God, the book selling arguments is ridiculous and has been debated to death: I must assume some people really don't have arguments). I'm in the Java business since 1996 and the only big mistake of my life has been around 2000 when people started the mantra "Java is dead". I wasted some months by going deepen in the argument and maybe searching for some other horse to ride, just to find out it was FUD. Since that year, more or less, people is continuously repeating this mantra, and - you get it - every year it has proven to be wrong. I know eventually Java will die (or just transform) as everything in the world, but just repeating every day "tomorrow it will rain" until it does, after months and months and months of sun, doesn't make you a good weather forecaster.
Java is boring? Well, in twelve years I've done: enterprise projects for finance, telcos and other corporates (you know, EJB, JSP, Web Services, Struts, Spring, Wicket, what else); a near real time project for Formula One telemetry (Jini); projects in the palm and mobile market; now I'm exploring and enjoying the desktop (Swing, NetBeans RCP) and I'm going to focus on that pretty-interesting thing that is semantic web. All of this by using different components of the same technology (and not because I didn't want to learn something else, just because Java performed pretty pretty well in all of these fields). Now, if somebody did all of these things in the latest ten years with, who knows, Microsoft stuff? Ruby? Adobe? Well, tell me, I'm curious. My bigger problem isn't Java, but to find the fucking time to do all those things (and pursuing customers to pay my bills, but I suppose it's just a typical italian problem). For all the rest my career is just fun, fun, fun.
BTW, I don't want that the above stuff is interpreted by showing off me. I'm just showing off Java. I don't feel I'm an exceptional guy and I don't ever have the geek look. At the JavaOne, while a few people apparently got bored, I met a lot of incredible people who's much smarter than me and is probably making much more fun than me (BTW the same happened at JavaPolis/Javoxx, Jazoon and other european conferences, where it appears that people do not get bored). Just to be trivial (and excluding the usual enterprise stuff), one could just look at what people are doing at NASA, Boeing, CERN. The latest Gosling video from friday morning sums this thing pretty well. Now, again, anybody could please care to show me another single technology allowing to fly from and to all those market segments?

Harsh words, yes. Perhaps I exaggerate a bit for effect ;-)
I freely admit that book sales is a poor proxy of actual use, but it may not be a bad indicator of buzz. My point is that the dispirited Java show was to me an indicator of broader problems in Java land.
Java is still a hugely important and powerful language, but it seems to be just giving up on being an exciting and fun language. That is not a battle it *has* to lose.
You mention a number of very impressive project you have worked on and all the smart people you talked to at the Java show. And you are enjoying Swing????
That's all very well, but have you been to a Ruby show lately? Have you gone to a Google code camp? Those events hat all the energy that Java shows had five years ago.
We should be expecting more out of Java, the Java community and out of JavaOne. There is nothing that decrees that all the cool projects get written in Rails.
As other commenters have pointed out, there are great new technologies available for Java developers like Grails and Flex (and yes WaveMaker). The problem is that the community seems to thing that Swing is "fun, fun, fun" and that it makes sense to wait another year for JavaFX while Flex and Silverlight suck all the oxygen out of the presentation market.
Think what would happpen if Sun shot JavaFX and adopted an existing open standard like Dojo, Ext or even GWT!
Are you looking at what people are building on the web? Don't you think that those technologies and architectures are going to affect your finance/telco/big dollar implementations? Don't you think that Cobol programmers used to take comfort in all their DoD contracts with NASA?
I am not at all worried that Java will die. I am much more worried that it will be crumple under the weight of mediocre expectations.

I didn't find the conference boring at all. It might just be your perspective. If your focus is on Bubble 2.0 (a.k. Web 2.0) then I can see why it might be boring to you. I would note that the conference contained a number of sessions were about JRuby or included JRuby discussions. I'm a Jython guy so I focused more on that.
I agree that there is a lot less hype around Java than other 'newer' languages but that's not really a problem. Java is finally settling in as the solid hype-free basis for the future.
Java has never been good for building good interfaces. Honestly, why would you even want to build user interfaces with Java? I've done it and given the other options out there, you are wasting time if you choose it for that. However, Java remains a very good platform for the kind of challenges that face developers with other priorities besides building fancy web sites.

I am. I would rather do that than any web framework (well, not including Echo3, RAP and the like cause those are basically Swing programming). Swing is incredible flexible and, if you can google the slightest, not that difficult.

If developers are finding work boring, be it Java or something else, get a new job. If you find programming in general tedious, then change professions. What's all this non-sense with people moaning "Java isn't sexy" like a model dressed in a thong bikini. Get over it already.
Programming will never be sexy, but if you love to program, it can be rewarding. If your day job bores you, then change jobs. If you like your day job, but want something fun to do, then start your own open source project. Every programming language gets boring after a while, it's human nature. Those who focus solely on the language and tools are missing the point of being a developer. The job of the programmer is to produce something of value. The tool is just the tool, it's not the end goal, unless you're job is building tools.
Java doesn't have a flu. It's the programmers that have the flu.
peter

Although I didn't go this year, I went to the first 2 Java One's and from 2002-2007. Java One has *always* been boring if u just go to the talks. The talks are always about stuff I've already researched or can find more information about on the web.
Its about meeting people and partying. Creating business and personal relationships. Which is why I stopped going to talks a long time ago and just hung out at the JBoss booth.
As far as Java not being sexy? Well.... I bet people who say this stuff were still in high school 10 years ago. As far as server-side development goes, we are *lightyears* evolved from 10 years ago.... UI side? Well, I've always thought modern web applications were awful architectures and ridiculously unproductive compared to the VB, PB, and even VC++ days 10 years ago.

Bill Burke is right on in this area. I went to J1 and attended 20 sessions and the pavilion was the part that I'll remember. There were a few sessions that I was very glad that I went to, however, there were about 10 that I'd wished I'd never gone to. Next year, I'll be going to far less sessions and spend more time meeting the people out on the pavilion floor...talk to you then Bill!!

I'll admit that if you go to J1 and sit through the presentations for the full duration, of even one full day for that matter you're going to be pretty sick of Java by the end of it.
J1, like most conferences is a socialising event. Most J1 socialites sleep through the morning events, turn up for lunch only to realise Sun served it on the East coast timezone and wonder off to find a bite to eat in the afternoon. The remainder of the day might be wondering around the hall looking for friends, gadgets and toys for the kids or if you're brave a late afternoon talk.
Finally, the evening, usually a long list of vendor parties, so many that you usually have to move from one to the other before finally ending up back in the Thirsty Bear, Kate O'Briens down the road or the W. The only annoying thing about San Francisco is their obsession for calling a hard stop at 2am.
So if you think of J1 in those terms it hasn't changed much. In fact that part might be considered boring when you compare it to TSS's Symposium which is in Prague this year, now that's a place to party and the talks are better too.
Now as for the language, if Java was as easy as VB then we'd have just as many idiots programming in it. At least the slightly difficult curve to get kick started in Java, which is let's face it the language of the server, it keeps those awful visual programmers out that you find all over the MS languages. To be honest, I vote to make it more difficult then, like C++ and Linux it will be easier to sort the good from the bad.
Java IS fun, perhaps you should try one of the more pretty languages, they might be more to your taste. :-)
-John-
A die hard Java on Linux programmer charging Architects fees :-)

I agree with the last two comments. It was my first JavaOne and I enjoyed it. There were some very interesting technical sessions, others very boring to the point that I fell asleep. The other thing that I enjoyed doing is networking everywhere Pavillon, lunch time, parties and at the end of technical sessions.

Let's be honest. Java has had the flu for quite sometime now, and you know what? Most Java programmers don't give a stuff. They are in it for the beer. Pure and simple.
Anyone who gets a blast from programming would have looked beyond Java long ago. I use to be a Java evangelist back in 1997, but the rot set in when Sun decided that getting the client side right was too much like hard work and that there was plenty of easy money to be made on the Server.
Since then we have been buried under a mass of frameworks and APIs. Bruce Tate published his don't make me eat the elephant again article back in 2004, and since then things have just got worst. Over complex J2EE is being replaced with annotation/xml based over complex proprietary Spring and we call this progress.
Don't get me wrong. Java will continue to rein in certain quarters in the same way that IBM reined in the 80's and Microsoft in the 90's as the "safe bet". But people that are passionate about what they do: Small independent startups and the like, will continue to choose Java less and less.
This is no bad thing IMO. It provides choice. Steady Eddy who just wants to pay the mortgage can learn yet another Java API and still find work. Whilst those who get a kick out of finding a "better way" can look elsewhere.
If I was starting out today, faced with the J2EE mountain to climb, would I climb it from scratch or would I look for something much simpler and more fun?
Paul.

If I was starting out today, faced with the J2EE mountain to climb, would I climb it from scratch or would I look for something much simpler and more fun?

Paul.

Could You name it? Something even remotely comparable with J2EE? Would take a look at it, definitely.
People want Java solve all the problems - from the one side they want Java be sexy and fit easily into niche where Flex lives (btw. never, ever seen real-life flex app, yet - note that I haven't looked hard - I'm just average User Joe in the Client side... So I'm not convinced that Java should learn anything from Flex, actually) - to dead end server side. Talking all the time about different examples. Java should be like Flex or Silverlight, on client side, like Rails on the Web side, like [put here Your favorite yet another sexy stack here] on the server side. It's ridiculous.
Java is... java and has it's own path. Java has also it's own problems. But Java's biggest problem is not lack of Access (like first post tries to suggest), definitely...
Artur

If I was starting out today, faced with the J2EE mountain to climb, would I climb it from scratch or would I look for something much simpler and more fun?

Paul.

Could You name it?

Yes. It's called the simplest thing that can possibly work! This varies from scenario to scenario, but it is very seldom a full J2EE technology stack. One size doesn't fit all, and I think this is where Java has gone wrong.
Many of Java's problems stem from the language itself. Fortunately with languages like Groovy, JRuby and Scala on the JVM the language problem is being addressed.
I agree Java is Java and should be left as is. But the JVM as a cross language platform is an all new ball game. I here good things about Lift (Scala) and Grails (Groovy), and of course Rails (JRuby) so there are several alternatives out there even on the JVM.

I'm not sure I buy this. I guess you'd have to define the "many problems" (Lack of sexiness?) Certainly not productivity. There are things a scripting language can do to make code much more concise but I don't think I've ever hit the wall where I said, "Java (the language) just can't solve this problem".
IDE support is for Java is so advanced that most of the really annoying java language idioms are done for you (e.g. writing a bazillion getters/setters, refactoring methods/constructors etc.)
I guess my feeling is that you can (and should) play with the new-comers when you can but you'll never go hungry being an expert at java.
That said I predict strongly that the next couple of years will see additional languages on the JVM as the major story in Java (if that isn't already the case). I've found much joy in using Groovy, JRuby, and some Scala to work with the tons of traditional, time-tested frameworks and libraries.
Personally I hope Scala sees some significant IDE backing this year. Being statically typed it would probably be the easiest to approach Java's current level of IDE support.

It always feels good to hear developers throw away their religious sentiments and whine about how crappy their platform really is.
I stumbled upon Flex 2 years ago and boy was I hooked!The guys at Macromedia/Adobe obviously understand what is really important- delivering apps that work,look pretty,smell pretty,
are easy to develop with an easy-to-work-with IDE and tools and u know- not a heck of a pain to do.
I couldnt believe my eyes at the layout I did overnight,the AdvancedDataGrid I could populate with data from a 3 line call to a .Net webservice and thanks to the great guys at TheMidnightCoders, I get to call in to my server-side code with little or no hassles.You get effects and filters for free,no more CSS hacks and counter-hacks, browser-compatibility issues-ur app displays the same in all browsers, how u want it and where u want it.
Heard of OLAPDataGrid?BI for mere mortals.
If I felt like it, I could swap my C# server-side code with Java(not a bad thing) or PHP( a very good thing) or Ruby(!).
Flex rocks!Long live Flex!It has been an enjoyable experience.
And then there was Silverlight!Granted the smart guys from Redmond took a cue or two from Adobe's Flex and went to the moon with it, Silverlight is poised to be the next big thing in rich client app development.What with a functional (albeit downsized) CLR, full access to .Net system libraries,LINQ(more on this later) and an intuitive+productive+RAD-enabled IDE, developing with Silverlight is looking to be a pleasure ride.
Throw into the mix a couple of readily available controls,
ability to extend default controls or write ur own from scratch,support for WCF(a mighty good thing),Windows Workflow Foundation(sweet and sexy) and ofcourse WPF-u get a bang platform for building next gen apps.
U see, the world has moved on from where we were years back.Problem is some people are still stuck at the bus stops the train passed 5 years ago.I would love to do JEE(honestly I tried and I tried),so why do I see Java/JEE as we know it as a no no for serious app development(!)?
Was it the language? or the IDE? or the myriad frameworks?
I dunno,may be someone does(I should ask Bruce Eckel for his opinion on this).
I like to take a holistic view of things, sort of keep things in line with the "on-going" reality.And in that view I think the real problem with Java is-simply this lack of evolution.Say evolution-capability.Sun and co seem to be adepts at inventing complexity,looks like they get thier trips from over-engineering or under-engineering stuff.And the end of the day-they get it all wrong or at least half-wrong.
Organisms adapt to changes in their environment to survive.Some grow new appendages, some shed their old skins and some move to Dubai(aka change their habitats).
Java/J2EE/JEE which surprisingly still manages to get a mention on sites that matter on the web and has a large developer community has simply refused to evolve.Imagine Sun rejecting Microsoft's proposal for including delegates in the spec and then the debate over closures!
U see, that's the real problem with Java(I should say Sun),
it has refused to adapt to its environment in a successful way and the few attempts were actually aimed at coercing the environment to adapt to it.

Java/J2EE/JEE which surprisingly still manages to get a mention on sites that matter on the web and has a large developer community has simply refused to evolve.

Maybe you are the one who has refused to see anything new that has come in Java ove the last 5 years. Sun is playing catch-up with RIAs, but thats just one part of the big picture.

Oh sure there have been a couple of new old things in the JEE world over the last 5 years.
There was EJB3, see Bruce Tates article
Don't Make me Eat the Elephant Again
for expert analysis on why that is an new old thing.
There was JPA which is firstly a glorified Hibernate+ hack and secondly an attempt at making the appserver do the work of the database.Did u ever hear about query plans,re-used query plans,SQL optimization?What ever happened to simple DTOs, do I have to model my relational data in my business logic code?Is my RDBMS not good enough?
U see commercial RDBMSs handle relational data best, handle SQL best and best understand normalized relationships.It doesnt make sense to model again my relational database structure in code-just to access the same data.
No to forget JSF- the would be catch-up to ASP.Net, looked promising when it came out, looks promising still and yes still looks like the UI framework that can.
I could mention Spring(which is fortunately a third-party product) but I wont,thought it definitely brightened the J2EE landscape.
There was the lame generics implementation, the dumb auto-boxing and unboxing implementation in 1.5 and ofcourse there was the lack of many good things that could have been in Java.Do I need to mention closures?Functional programming?Dynamic scripting?U fill up the rest.
And just for the laughs there was JavaFx which I definitely think Sun is getting wrong-idea, implementation and all(I could be proved wrong though).
Which of these do u mean?

Don't Make me Eat the Elephant Again
for expert analysis on why that is an new old thing.
Please tell me you are basing your entire opinion of EJB 3.0 on a three year old article by a disgruntled programming book author you wants to sell books are you?

There was JPA which is firstly a glorified Hibernate+ hack and secondly an attempt at making the appserver do the work of the database.

If you dont see the advantages of a standards-based ORM tool for a certain class of applications, then probablly nothing I can say would enlighten you. I personally think JPA is the best thing Sun has done in years. I wouldnt use it for every type of application, but then business requirements are complex enough, an ORM layer is very convienient.

They became unessisary when people stopped adding unessisary layering to simple applications.

do I have to model my relational data in my business logic code?Is my RDBMS not good enough?

Structured data is structured data. Sometimes that structiured data needs to be persisted in a relation database and sometimes it needs to be interacted with programatically as objects. Depending on the complexity of your application you have various ways to do this. Sometimes the object model is basically a mirror of the relational model in which you use an active record type pattern and sometimes it isnt and you need to do more sophisticated mapping.

commercial RDBMSs *persist* data the best. Object oriented programming languages apply business logic to that data the best. If it ever comes to pass that you need to write a system with lots of busiess logic, I think you will find that its nice to interact with the data in an object oriented manner. For simple CRUD applications, its perfectly reasonable not have an ORM or even an active record layer, but for lots of types of applications it make development much more pleasant.

It doesnt make sense to model again my relational database structure in code-just to access the same data.

Again, it depends on your needs. Sometomes you do, sometimes you dont.

No to forget JSF- the would be catch-up to ASP.Net, looked promising when it came out, looks promising still and yes still looks like the UI framework that can.

Ive never been a big fan of JSF. A good example of why design by commitee can sometimes produce crap. Without a WYSIWYG editor is a pain to work with. Thank god its not the only MVC technology in the Java world.

I could mention Spring(which is fortunately a third-party product) but I wont,thought it definitely brightened the J2EE landscape.

Why not memtion it? Spring is been a core technology in the enterprise java world. The open source community has been in the drivers seat for a number of years now.

There was the lame generics implementation

I agree, generics were poorly implemented.

the dumb auto-boxing and unboxing implementation in 1.5

Well, it has certainly reduced the amount of typing Ive had to do.

Do I need to mention closures?

Not everyone agress closures are needed, but I agree that it would have been nice to have them from the get-go.

Functional programming?Dynamic scripting?

I guess you are unaware of:
JRuby
JPython
Groovy
Scala
So all in all, I feel that people like you are just as dogmatic as the over-engineering types. There isnt a single approach to every problem. Java is an ecosytem with lots of approaches to solving application development needs. But since you seem to have a closed mind and an axe to grind I dont expect you to see this.

Yes, I have, why do you ask?
In real world applications, database schemas change-more than twice after deployment.Most times you only get to talk to the database through updatable views your DBA gives you access to.
Your DBA wants to monitor which queries are consuming the most resources, identify which queries are potential bottlenecks,identify which queries are under-using indexes and the like, I could go on and on.
The fact is data access is ultimately specific to the RDBMS you're trying to access.That means you can't take generic SQL statements that are not optimized for the particular RDBMS you are using and hope to scale with that.
The performance of you app is directly linked to business logic shared between server-side code and stored procedures and SQL functions that are written in database prioprietary languages like PL/SQL or T-SQL.
I think it's a pretty fragile design choice to tie the relational model to an exact replica in server-side code.
And ofcourse I did'nt mention concurrency issues and distributed transactions- though most apps will never need the later.(More on this later).
In every app development cycle two issues relating to data always come up:
1.Data access
2.Data manipulation (on data pulled from the persistence store from 1. above, this can be done in code
3.Data persistence
While there are more than one way to get all these done, it has been my experience that the what works best
is the tool that gives u the greatest flexibility-I might say lets you do what you want and how you want it, without imposing a sleuth of constraints on you.I got a taste of that while working with Joomla.Heck you just want to pull out data from the store and u don't have to model the table in code to do that!
If you have'nt caught the hint- you can do all three in most instances without re-modelling your relational database structure.
On some people's scale 3.(data persistence) might be most important, and for that I think if you want to go for a generic implementation(which you call standards-based), you should use a server-side data structure that understands relational database structure.This saves you the pain of modelling tables-again.Think of stuff like .Net's DataSet,DataTable and DataRowCollection or even better typed DataSets.
With these structures you can do 2.(data manipulation and that includes sorting and filter and extending with new columns with full referential integrity) far better than you can with classes mimicking database tables.
While JPA did bring some improvements to the table, it's still IMO under-engineered if not ill-fitting.It could benefit from more innovation.While I'm not necessarily trying to compare technologies, I think MS's got it LINQ with link.IMO Sun needs this kind of innovation-awesome stuff that brings you inspiration when writing business logic for customer apps.
I'm for stuff that works and works with a bang.The whole point of the criticism was to call for a better implementation of existing technologies.So that line about me having a closed mind is off key IMO.
Cheers,
Ozzy

Most times you only get to talk to the database through updatable views your DBA gives you access to.Your DBA wants to monitor which queries are consuming the most resources, identify which queries are potential bottlenecks,identify which queries are under-using indexes and the like....The fact is data access is ultimately specific to the RDBMS you're trying to access. That means you can't take generic SQL statements that are not optimized for the particular RDBMS you are using and hope to scale with that

I think the issues you are discussing here are vitally important in certain contexts, (though I would disagree that most applications only talk to the database through views), but my point is about being flexible with choosing a technology stack that fits your needs.
If a particular project has constraints like a hard-headed DBA or high volumn activity requring complex SQL optimazation, then these concearns can outweigh the advantages of dealing with data as objects. In that case you shold use pure SQL in strategic areas of your application or not use ORM at all.
The point is that there isnt a one-size-fits-all approach to application architecture that fits all projects. Every project has different needs and contraints and a smart developer takes a flexible approach to choosing technologies and patterns when comming up with a solution.
There is certainly room for improvement and Java can learn from other language/frameworks, but the truth is that the Java ecosystem has lots of different approaches to software development and I think it will only get better.

You've probably seen quite a few Flex apps and didn't know it. Flex is just another way of doing Flash/ActionScript in a more developer/IDE/friendly way. (Or at least that is how I look at it)
For the record the company I'm working for has developing a pretty intense flex app. (I'm the back end though so don't ask me for details :-)

People want Java solve all the problems - from the one side they want Java be sexy and fit easily into niche where Flex lives (btw. never, ever seen real-life flex app, yet - note that I haven't looked hard - I'm just average User Joe in the Client side... So I'm not convinced that Java should learn anything from Flex, actually)

Well, I'm currently working on 3 Flex/J2EE projects for french companies. Two of these web-applications are already released. I personaly have no doubt about the strength of the Flex framework for the presentation tier.
I'm actualy working as a JEE architect, and started using Flex a year ago (never did any Flash development before).
In my opinion, Java do have some litte things to learn from Flex... For exemple, data-binding (JSR 295 is working in that way), UI layout described by XML, easy creation and re-use of custom visual component, etc.
Having used core Servlet/JSP, Struts and JSF to build webapps, I really feel Flex (framework and tooling) brings a lot in the webapp framework landscape.
It's quite simple to learn, allows for rapid prototyping and globally enhance productivity (framework consistency, very good tooling, clear separation of concerns between presentation tier and middle-tier).
Franck

"That's all very well, but have you been to a Ruby show lately? Have you gone to a Google code camp? Those events hat all the energy that Java shows had five years ago."
Glad to hear people is enjoying. Glad to here there could be competition. You say that those events have more energy: it seems pretty obvious, if a "new" thing had less energy than consolidated ones, it would be a dead born puppy. Then, I think everybody has in mind that one thing is to have an energetic meeting, anothe is to be one of the most spread technologies in the world. At the moment many hyper-hyped technologies are just at the first stage, but if you look at numbers, they involve one-digit fractions of the total developers; we have to wait for some years before being able to tell something about them. And as somebody pointed out, Java-the-platform can run them all: Ruby, Python, Groovy, Scala, whatever. Sun is supporting all of them with NetBeans. As it seems that JRuby outperforms Ruby, it seems that Java can do it even better. Frankly speaking, I could bet that if ever one of those technology win, they'll do on the Java platform (technically speaking, this reasoning holds true for the Microsoft CLR thing too).
"The problem is that the community seems to thing that Swing is "fun, fun, fun" and that it makes sense to wait another year for JavaFX while Flex and Silverlight suck all the oxygen out of the presentation market."
Personally I care more if a technology works rather than it is fun; if it's also fun, well, it's even better. Swing is fun and _potentially_ (see below) works better than others. We have to point out that when comparing web-based technologies such as GWT, Flex and Swing we are comparing two very different modes of doing a desktop application, not only two alternate technologies. To me it's clear that today the dominating one is the web based, which is BTW the one I'm making more money with (and BTW I find it pretty boring) - but I think it's good only for a specific, while wide, target of applications. I think that for anything that requires a deeper interaction and computational power, the old "rich desktop" model is still the better, this is the way I like Swing and other related things and I believe they can just deliver. Then, I perfectly realize that the better technical model is not necessarily the one that wins (see OS/2 vs Windows) - in other words, I'm perfectly aware that Sun's bet to conquer again the desktop is not easy to win. Only time will tell.
"Think what would happpen if Sun shot JavaFX and adopted an existing open standard like Dojo, Ext or even GWT!"
Well, think just what would have happened if Microsoft didn't do its best to kill Java in the late '90s. 90% of people would probably just use Swing for every desktop application and AJAX would have never been born. This "what if ten years ago..." argument is nothing that catches me.
"Java doesn't have a flu. It's the programmers that have the flu."
Great comment by Peter.

Thanks for the compliment. I don't know about others, but I work as a consultant for a specific reason. It keeps me from getting bored and lets me work on new projects every 1-2 years. It's not for everyone, but for those who feel like Java is dead or boring, there's a simple solution. Quit your job and get a different one. Of course, that isn't always possible and people have families to support.
Blaming java for one's own bordem isn't going to solve the problem. The only solution is to change jobs or create the excitement yourself. Sun isn't obligated to make Java sexy or fun for developers. It's the developer's job to make their job fun and interesting.
One thing people that haven't mentioned is that businesses aren't there to create interesting work for developers. Businesses are there to make money and get the job done. Sometimes the work is fun and interesting and other times it's not. At the end though, it all comes back to the developers. You make your own destiny and excitement.
peter

Overall I really like being a Java developer, but Im always surprised when people who work with enterprise java have never been annoyed with it. Im not sure I get "bored" but I certainly get annoyed. The apex of that was when I had no choice but to do the XML hell->view->controller->business delegate->transfer object->session facade->ejb->entity object->DAO->RDBMS twostep for EVERY project I worked on. And I have never fully drank the kool-aid with Spring either. While I think its focus on POJOs, DI and unit testability has substantially moved technology in a positive direction, Spring was always too XML centric for my tastes and I never liked the MVC solution from that camp.
But I feel beter about Java than I have for a while. The industry is becomming wiser and more and more we are allowed to use the the right tools for tasks at hand. I think we have more maturing to do in that respect, but I like the way the industry is moving these days.

I agree with you.I recently changed jobs, but had a great run at my last place. From 2002 until 2007, I learned Struts, Spring, Hibernate, GWT, and a variety of smaller OS projects utilizing a slew of new(new and new to me) techniques across 4 or 5 projects.
I had a great time, but when the sameness of the work started to bore me, I moved on.
I think Java has plenty of life left and personally scoff at the suggestion that Ruby, JRuby, or Groovy is where the action is.
The action is where you make it.

Not objective. The same type of article was written at infoworld, saying Ruby was the Java killer, an harkened Java programmers today were soon to be destined to be crusty old cobol programmers.
As a comparison to the sports shirt wearing folks, I'm sure the 10 sided dice and werewolf is tons of fun at Ruby conventions, paid for on your company's dime.
Let's come to grips. Like it or not, our field is maturing. Ours was a new field that peaked in the 90s and early 2000s with rapid changes in hardware, operating systems, and programming. But I find myself hard-pressed to find what killer technologies have been created in the past few years. SQL? RDBMS? Napster? Ebay? MP3 players? Digital cameras? XML? XHTML? Webcams? All been around for several years to a decade to beyond.
The Wii for sure, but beyond that...I'm scratching my head about great, new, widely accepted technical innovations. Suggestions invited!
With our field maturing, change has become less rapid. That includes creation and implementation of new programming languages and platforms. Try to explain to your CFO & CIO why Ruby / RoR / a new VM needs to be used when your team's expert knowledge, hardware, and software costs are all sunk into Java. RoR had the capacity to become something greater but failed to capture that momentum for reasons that are captured by Zed's infamous ghetto rant.
The lack of momentum feels unnatural to me as well. I've been using Java since 1999. I never thought I'd be programming with it this long. At the end of the day, Java gives me 3 times more jobs on dice.com in the metro Detroit area than the closest competing language (C#).
So what's my point?
If a new language is actually that great, it will be adopted and replace the old technologies, just as it used to in days of old. Programmer will learn it because of demand.
Because our field is maturing...we haven't seen such a widespread adoption because it's becoming harder and harder to top what we've done (multi-core versus Ghz, anyone?)

With our field maturing, change has become less rapid. That includes creation and implementation of new programming languages and platforms.

I dont know....
Five years ago I think it would have been unthinkable that POJOs, DI, convention or configuration, a focus on simple solutions and multiple languages on the VM would have been part of the accepted orthodoxy in the java world.
I think alot has changed. While we might not get another disruptive technology like the internet again any time soon, Java has come a long way and the day to day life of a java developer has gotten alot beter and continues to do so IMO.

With our field maturing, change has become less rapid. That includes creation and implementation of new programming languages and platforms.

I dont know....

Five years ago I think it would have been unthinkable that POJOs, DI, convention or configuration, a focus on simple solutions and multiple languages on the VM would have been part of the accepted orthodoxy in the java world.

I think alot has changed. While we might not get another disruptive technology like the internet again any time soon, Java has come a long way and the day to day life of a java developer has gotten alot beter and continues to do so IMO.

I think we are still absorbing the best way to use the stuff. Take GWT, everyone is still trying to really exploit the technology. One things like this firm up, then new innovation will follow.
You have to understand the current stuff to understand the weaknesses. Addressing those weaknesses will cause innovation.

POJOs have been around since Oak, but not named POJOs until the advent of EJB2 confusion.
DI / Dependancy Injection - Spring 1.0 was released in 2004.
Convention over configuration - that is a new idea, thanks to RoR. The concept isn't unique to RoR, and can be applied elsewhere (i.e. Grails). Microsoft creates plenty of code behind the scenes when you use Visual Studio to drag and drop GUI controls; it puts them out of the way with partial classes and such. Microsoft's been doing this since early versons of VB, so I'm not sure if we can call convention over configuration new, or simply something finally applied correctly to platforms other than Microsoft (Ruby, Java).
I agree, Java has come a long way. And it's been dominant for quite awhile. It seems like there's a lot of people (Ruby fanboys?) who'd like to see it go away, but when you sit down and look at it from a resource perspective, what the heck are you gaining (on paper) to move your Java platform and expertise over to a new platform?

Why Java is so complicated? It is because Java is a language that can make an applications still maintainable, scalable, and easy to debug even they grow to a size with more than millions line of code. Java is a language that always remind you to think big even when you start small. And the best part of Java is: the evolution of Java is being drive by the market, not by just one or two vendors.
That's why Java is not for web designers to do stuff causally.
Alex Hui

Why Java is so complicated? It is because Java is a language that can make an applications still maintainable, scalable, and easy to debug even they grow to a size with more than millions line of code. Java is a language that always remind you to think big even when you start small. And the best part of Java is: the evolution of Java is being drive by the market, not by just one or two vendors.

That's why Java is not for web designers to do stuff causally.

Alex Hui

I fundamentally disagree with this additude. There is NOTHING inherent in the Java language that makes a poor choice of "casual" projects. I beleieve 100% that Java has the inherent capability for elegant and agile solutions. The problem is not with the language, its with dogmatic additudes that lead to the overengineering of so many applications/projects.
Thankfully enough people are waking up from from the evil matrix-like world where every appliction has the be developed as if it is a mission-critical system with millions of concurrent users.

Why Java is so complicated? It is because Java is a language that can make an applications still maintainable, scalable, and easy to debug even they grow to a size with more than millions line of code. Java is a language that always remind you to think big even when you start small. And the best part of Java is: the evolution of Java is being drive by the market, not by just one or two vendors.

That's why Java is not for web designers to do stuff causally.

Alex Hui

I fundamentally disagree with this additude. There is NOTHING inherent in the Java language that makes a poor choice of "casual" projects. I beleieve 100% that Java has the inherent capability for elegant and agile solutions. The problem is not with the language, its with dogmatic additudes that lead to the overengineering of so many applications/projects.

Thankfully enough people are waking up from from the evil matrix-like world where every appliction has the be developed as if it is a mission-critical system with millions of concurrent users.

In fact, if you give it enough thought, you can create a common code base for simple and complex systems alike. At my last job, I used the same Struts(before moving to GWT)0Spring-Hibernate code base for projects small to medium. Even the simplest app had all the security, caching, error notification abilities of the larger apps. When I decided to move my most recent work to GWT, I only had to swap out the front-end with GWT and learn GWT. I still had all the cool back-end stuff.
Start simple and add features as needed and you not only will not over-engineer, but you can scale some of the more advanced features down to simpler apps, developing them faster and make them more feature laden, making it easier to win customers.
One of our biggest selling points was that we could focus on the business solution while given the customer battle-testing code using well known frameworks.

In fact, if you give it enough thought, you can create a common code base for simple and complex systems alike. At my last job, I used the same Struts(before moving to GWT)0Spring-Hibernate code base for projects small to medium. Even the simplest app had all the security, caching, error notification abilities of the larger apps. When I decided to move my most recent work to GWT, I only had to swap out the front-end with GWT and learn GWT. I still had all the cool back-end stuff.

Start simple and add features as needed and you not only will not over-engineer, but you can scale some of the more advanced features down to simpler apps, developing them faster and make them more feature laden, making it easier to win customers.

One of our biggest selling points was that we could focus on the business solution while given the customer battle-testing code using well known frameworks.

In your example, I think you've already have the expansion roadmap in your mind when you do your very first design. And you have been following some kind of Java best practice too. These is what I called "Think big when you start small". Which I think it is a good thing for application design in most case.

"After 10 years, Java remains an extremely complex development environment with nothing even approaching an easy learning curve."
For building web apps, I could suggest you take a look at the web4j web application framework. It has a philosophy of deep simplicity, and tries hard to address problems of low productivity.
- John

... well, in this case it's "Java has the flu". Same thing, slightly different wording.
The O'Reilly metric is completely useless.
The last 4-5 years O'Reilly has been woefully pathetic in keeping their Java catalogue up to date. For instance, they just released their first full book (other than Developers Notebook) on Hibernate. Likewise, there's nothing on Spring, GWT, Wicket, new Swing stuff, Glassfish, etc. Also, their titles on things like NetBeans (their book is 6 years old) and Eclipse are way out of date. How about a new Struts (2) book? Nope, their struts book is like 5 years old. The only up to date, high quality O'Reilly Java book is the EJB 3 book (by Bill Burke), which is actually quite excellent.
In short, O'Reilly Java book sales are down simply because O'Reilly has pretty much neglected the Java space.
Contrast that with Manning, who always have up to date Java titles. I'm sure their Java titles sell really well.
Book publisher numbers aside, Java seems to be doing increadibly well, thank you very much.
The Tiobe index, for what it's worth, ranks Java as the number one language.
Dice, Monster, HotJobs, return more Java jobs in searches than any other language.
Evans data ranked Swing (Swing!) as the largest market share for new GUI development.
The Java open source space is increadibly rich and healthy.
And on and on ...
Contrast that with so called "hot" technologies. Just how many matches do Dice Ruby searches return. Flex? ... the answer is, not many. Where do they rank on the Tiobe index? ... not that high, actually.
As has been mentioned before, the "Java is dead" mantra has been around since 2000. Here we are 8 years later, and Java is healthier than ever.

I mean, if the future of Java is just handling complex and high volume business then I'm missing the downside.
Is it boring? Hell yeah, totally boring, but boring pays the light bill. Boring like COBOL keeps you employed for 50 years. They even hold that boring SHARE conference twice a year.
Prettier? Easier? Fun? Since when did Java need to go after the same target audience as Elmo?
And if Java's got the flu, then what's .NET's diagnosis? Tuberculosis? Make no mistake about it, Spring, Rails and open source in general have turned .NET into a neither-nor platform. It's not capable of handling complexity like Java and it's relatively bulky compared to the new kids in town.
Who's going to have more power in IT 10 years from now? The same people who have always had it -- the folks who can deliver applications and systems that support a profitable business. And slapping a pretty front end on a shoddy app won't impress anyone.
It's no secret that enterprise Java as it's existed this century will go through some major changes and that it will need to accommodate lightweight programming models that allow developers to do easy things more easily. Yet there's the entire realm of difficult to do programming where Java's reach and reliability have no parallel. That stuff isn't pretty, easy or fun. It's ugly, nearly impossible and excruciating ... which is why the people who can do it tend to get paid well ... like those COBOL folks.

I mean, if the future of Java is just handling complex and high volume business then I'm missing the downside.

The downside is that the majority of websites and web applications are neither highly complex nor are high volumne. Many people feel that for small to medium sized web applications, Java doesnt have a compelling choice that has a low barrier to entry.

The downside is that the majority of websites and web applications are neither highly complex nor are high volumne. Many people feel that for small to medium sized web applications, Java doesnt have a compelling choice that has a low barrier to entry.

Sure, there's lots of low hanging fruit and it isn't going to take a lot of skill to pick it. Who wants to fight over that?
Use the tool du jour for the simple stuff. That's Microsoft's problem. It's in a race to the bottom. There's always going to be a simpler, less expensive way to tackle the basics.
Meanwhile Java looks to have enduring strength because it thrives in money situations. That's where I fail to see the downside. If there was a problem at JavaOne it was that Sun seemingly has lost all sight of the sector of the market where developers get paid the big bucks to do the tough jobs. Oracle, which keynoted on the second day, hasn't. It's even bought BEA in an effort to improve its technology and market share in that sector. Now there's a company that seems to think development becomes more "fun" every time you add another zero.

The downside is that the majority of websites and web applications are neither highly complex nor are high volumne. Many people feel that for small to medium sized web applications, Java doesnt have a compelling choice that has a low barrier to entry.

Sure, there's lots of low hanging fruit and it isn't going to take a lot of skill to pick it. Who wants to fight over that?

Use the tool du jour for the simple stuff. That's Microsoft's problem. It's in a race to the bottom. There's always going to be a simpler, less expensive way to tackle the basics.

Meanwhile Java looks to have enduring strength because it thrives in money situations. That's where I fail to see the downside. If there was a problem at JavaOne it was that Sun seemingly has lost all sight of the sector of the market where developers get paid the big bucks to do the tough jobs. Oracle, which keynoted on the second day, hasn't. It's even bought BEA in an effort to improve its technology and market share in that sector. Now there's a company that seems to think development becomes more "fun" every time you add another zero.

Very good points. For the heavy lifting stuff, and jobs that pay the bills, Java is still king.
Again, how many paying jobs for RoR are out there? How many jobs for J2EE, JEE, Spring/Hibernate (and even Swing) are out there.
The real world shows the later is the much larger number, by a country mile.

The downside is that the majority of websites and web applications are neither highly complex nor are high volumne. Many people feel that for small to medium sized web applications, Java doesnt have a compelling choice that has a low barrier to entry.

Sure, there's lots of low hanging fruit and it isn't going to take a lot of skill to pick it. Who wants to fight over that?

You may feel anything that isnt a 10 million dollar mission critical system with life and death consequences is beneath you, but the majority of IT projects are small to medium sized and it is absured the Java world doesnt have a fantastic solution for that space. Maybe Im just lazy, but I hate having to thinking harder than is nessisary to or type type more than I have to. I like simple and I like intuitive. Mostly, I like easy yet maintainale.
Beyond that, from a non-business perspective, I do various small projects that involve creating database-backed websites and I like to use Java there because that is the language I know best and feel most comfortable with. There is no reason I should have to use ASP, PHP or Ruby at that level.
In general, Id like to see Java ubiquous. The more traction the platform has, the better. Aside from the immediate bennifits of serving the low to the medium space, if java cedes this realm to other platforms, eventually those platforms will scale up and make Java a nitch legacy system that only old grumpy men are interested in and one that no new projects are started with.

You may feel anything that isnt a 10 million dollar mission critical system with life and death consequences is beneath you, but the majority of IT projects are small to medium sized and it is absured the Java world doesnt have a fantastic solution for that space. Maybe Im just lazy, but I hate having to thinking harder than is nessisary to or type type more than I have to. I like simple and I like intuitive. Mostly, I like easy yet maintainale.

I'm not arguing that anyone should make anything harder than it needs to be, but maybe we're putting a little too much emphasis on the UI here. What's the critical functionality you're trying to get at? Can it scale? We've all run into countless versions of the simple app that can't but suddenly needs to. To me, that's where Java needs to be.
What are the essential apps that will be built in the future and what's the best way to build them? If anything, that's what I thought was missing from J1, at least in terms of being front and center.

You may feel anything that isnt a 10 million dollar mission critical system with life and death consequences is beneath you, but the majority of IT projects are small to medium sized and it is absured the Java world doesnt have a fantastic solution for that space. Maybe Im just lazy, but I hate having to thinking harder than is nessisary to or type type more than I have to. I like simple and I like intuitive. Mostly, I like easy yet maintainale.

I'm not arguing that anyone should make anything harder than it needs to be, but maybe we're putting a little too much emphasis on the UI here. What's the critical functionality you're trying to get at? Can it scale? We've all run into countless versions of the simple app that can't but suddenly needs to. To me, that's where Java needs to be.

What are the essential apps that will be built in the future and what's the best way to build them? If anything, that's what I thought was missing from J1, at least in terms of being front and center.

I am doing the small to medium size apps and Java is perfect for that. Maybe i do less pure web apps than the rest. I do applications that might have a web front-end. Even small ones. I always find occasion to reuse code in small applications.

I mean, if the future of Java is just handling complex and high volume business then I'm missing the downside.

The downside is that the majority of websites and web applications are neither highly complex nor are high volumne. Many people feel that for small to medium sized web applications, Java doesnt have a compelling choice that has a low barrier to entry.

+1.
Right on the mark Berry!
You know, I always wondered what Drupal smell like if it had been done in Java?
Or if Joomla would have garnered the same popularity it has now if it had been a J2EE web application?
Guesses any one?

The downside is that the majority of websites and web applications are neither highly complex nor are high volumne. Many people feel that for small to medium sized web applications, Java doesnt have a compelling choice that has a low barrier to entry.

The title of article is misleading, it should be: Java Web/UI development has Flu.

The title of article is misleading, it should be: Java Web/UI development has Flu.

You are absolutely right - I had meant to have a civilized debate about Java/Ajax regaining momentum in the Web 2.0 dev world. Instead, we devolved into a silly argument over an equally silly factoid (interesting but highly suspect O'Reilly numbers).
I was hoping that people would read past the first paragraph to my proposed "cure". Instead, my intemperate opening salvo instantly set fingers hammering indignantly over spittle-flecked keyboards.
What this thread has proven is that much of the Java community has more passion around denying that there are any problems in Java than in discussing what the possible solutions could be.
I will saddle up on Rosanante and ride off in search of another windmill. Sigh...

What this thread has proven is that much of the Java community has more passion around denying that there are any problems in Java than in discussing what the possible solutions could be.

I will saddle up on Rosanante and ride off in search of another windmill. Sigh...

Yes, The TSS/Java community has a sad habit of shooting the messenger. Look what happened to Bruce Tate!
Complacency is the thing. When you've been earning good money for old rope for such a long time, why would you want to rock the boat?
Chris, you are talking to the wrong crowd. The ones interested in improving things have left already and are busy using Flex:)
Hell, I only came back here out of curiosity and the mistaken belief that the Java community were now ready to discuss the issues. Ahh well, I'll pop back and take another look in 6 months :) Maybe they'll be ready then!

What this thread has proven is that much of the Java community has more passion around denying that there are any problems in Java than in discussing what the possible solutions could be.

Sure. The usual "You don't agree with me so you are not passionate". Honestly, I didn't see very many of the usual people here. I think most people in Javaland are tired of being told we are stupid because we have not move to Ruby/Scala/Flex/etc. I really don't think this thread was that bad. Great? No.

What this thread has proven is that much of the Java community has more passion around denying that there are any problems in Java than in discussing what the possible solutions could be.

May be,may be not.
While it does'nt make sense to discuss problems without offering possible solutions, threads like this create awareness about current issues and foster intelligent discussions among peers.Atleast you get to know what someone thinks of a tool you thought was the greatest thing since sliced bread.
I think Java has a bright future if(and that's a big IF) Sun and the big players tackle the real issues and quit playing catch up.
Java the language needs to be revamped.When you listen to programmers and understand their needs, it only makes sense to respond with a positive bias.Functional programming works and greatly simplifies code,closures make a heck of a lot of things possible, it shouldn't take a genius to realize these
are greatly needed in Java.Though some people will disagree with the above point, I think Java is supposed to be a community-driven language, so why the bureacracy?
The JVM needs to be re-architected to be the next-gen work horse execution engine, sort of a final replacement for CRT and it's C++ sibling.Certain features have to be baked right into the JVM,stuff like support for dynamic languages without resorting to hacks like JGroovy and JRuby(hope I don't get blasted for saying that).The goal should be to produce a general purpose, cross platform execution engine for running anything-loosely typed,strongly typed,embedded, beyond what is available today.
Finally, I think Sun should consider investing in Linux to tackle the MSFT menace.Linux holds promise-cos of the huge number of people convinced it is a viable alternative to Windows.Ubuntu with a few strategic technologies and some deft marketing can definitely take a bite from the MSFT pie.I mean using Linux to target the emerging market of connected devices-from the desktop to smart clients to IPods.No frigging bluish-purple Swing UIs here,no crappy AWT API stuff- I'm talking about a new, sexy, easy to like and use UI.If they want to compete favourably, to be frank-WPF must be bested.And that is just that.
We need easy-to-use data visualization controls, intuitive data presentation controls and the like.Concise, compact APIs that just work.
Imagine Autodesk on Ubuntu or any of the popular CAD tools on Fedora?Would'nt that be sweet?

Functional programming works and greatly simplifies code,closures make a heck of a lot of things possible, it shouldn't take a genius to realize these
are greatly needed in Java.

I asked once one of my professors teaching functional programming on college whether functional programming will ever hit the main stream, and his answer was simple NO.
One simply has to take into the consideration global/IT market and economy, and simply functional programming is not suited for 90% of software development working force on today's global market, a.k.a. not suited for Joe the Average.

Quote from PB :
"Anyone who gets a blast from programming would have looked beyond Java long ago."
RoR makes reading and presenting data from database some kind of innovation? Yeah, that is hard to grasp, have you heard about frameworks like GridGain, Hadoop, that is innovation, not some mickey mouse tools.
Summary of your talk is as follows: While millions of people are writing 1000s of books with 10000s of pages on daily basis, you question whether letter A is defined correctly, and if we should perhaps change it in some way.
If someone says "I know letter A ain't perfect, but lets use it as it is cause we will innovate now at the higher level of abstraction (aka business and framework level) because of the solid foundation it has, you call him deluded or ignorant"

I asked once one of my professors teaching functional programming on college whether functional programming will ever hit the main stream, and his answer was simple NO.

One simply has to take into the consideration global/IT market and economy, and simply functional programming is not suited for 90% of software development working force on today's global market, a.k.a. not suited for Joe the Average.

Your professor has been proven wrong. FP is being mixed with OO to become a powerful coctail. JavaFX, Python and Ruby may be seen as examples of this. In .NET, LINQ is a pristine example of this:
var seniorNames =
people
.Where(p => p.DateOfBirth >= cutDate.AddYears(-60))
.OrderBy(p => p.LastName)
.Select(p => p.FirstName.Substring(0,1) + ". " + p.LastName);
This statement selects seniors (above 60 years at the cutoff date) from the people collection; which may actually be a database table. It then orders them by their last names and finally returns names synthesized from the first initial and last name. The type of seniorNames will be IEnumerable.
The statement uses three inline lambda functions/closures, one which takes a Person and returns true/false indicating senior status, another which simple selects the lastname so that OrderBy can sort on that and finally a third which takes a Person instance and returns the synthesized name.
Maybe fully functional programming languages will not go mainstream, but functional programming as a discipline is definately breaking through in mainstream development. In just comes in through the back door by mainstream languages integrating the paradigm.
Functional programming also seems to hold distinctive advantages when developing multithreaded programs to take advantage of multiple cores.
However, Sun/JCP seems to have abandoned that kind of innovation for Java, instead focusing on scripting languages and JVM as a platform. It may actually work, but it is a dangerous strategy which risks alienating some loyal customers.
Many shops have deep investments in Java. If Java the language and some of the major APIs are being left to die (lacking innovation) they will soon be in the legacy category. That will prompt shops to come up with new strategies, and this time around there are some mighty stiff competition both in the enterprise and in the RIA space.

I asked once one of my professors teaching functional programming on college whether functional programming will ever hit the main stream, and his answer was simple NO.

One simply has to take into the consideration global/IT market and economy, and simply functional programming is not suited for 90% of software development working force on today's global market, a.k.a. not suited for Joe the Average.

Your professor has been proven wrong. FP is being mixed with OO to become a powerful coctail. JavaFX, Python and Ruby may be seen as examples of this. In .NET, LINQ is a pristine example of this:

This statement selects seniors (above 60 years at the cutoff date) from the people collection; which may actually be a database table. It then orders them by their last names and finally returns names synthesized from the first initial and last name. The type of seniorNames will be IEnumerable.

The statement uses three inline lambda functions/closures, one which takes a Person and returns true/false indicating senior status, another which simple selects the lastname so that OrderBy can sort on that and finally a third which takes a Person instance and returns the synthesized name.

Maybe fully functional programming languages will not go mainstream, but functional programming as a discipline is definately breaking through in mainstream development. In just comes in through the back door by mainstream languages integrating the paradigm.

Functional programming also seems to hold distinctive advantages when developing multithreaded programs to take advantage of multiple cores.

However, Sun/JCP seems to have abandoned that kind of innovation for Java, instead focusing on scripting languages and JVM as a platform. It may actually work, but it is a dangerous strategy which risks alienating some loyal customers.

Many shops have deep investments in Java. If Java the language and some of the major APIs are being left to die (lacking innovation) they will soon be in the legacy category. That will prompt shops to come up with new strategies, and this time around there are some mighty stiff competition both in the enterprise and in the RIA space.

+1.
Well said Uffe.I was thinking there was no proper geek on this thread.I bet Sun is going to come up with a reason not to include FP in the language.Like "its unnatural", "it does'nt fully support adopted OOP principles" or any bureaucratic nonsense they see fit to cook up.

Hi Uffe,
Yes I agree. Microsoft has managed to leap frog Java with C#, even though Sun had a massive head start. How did they allow this to happen?
On the CLR lots of interesing things are happening. F# seems interesting. Your LINQ example makes Hibernate look postively old fashioned. API's and libraries aren't enough, what we need are more powerful language features. Microsoft seems to understand this, and Sun doesn't.
I never knew the day would come where I would have reason to praise Microsoft over Sun, but the simple truth is that they have been doing a lot of useful research and bringing innovative new ideas to market and Sun hasn't.
With regards to dynamic languages Sun had an head start on everyone with Self, an advance dynamic OO language, which they did nothing with. They also bought Strongtalk, using the Strongtalk VM expertise to create the Java Hotspot JIT VM, and burying the Strongtalk language itself...
Now they have open sourced Java. I'm not sure wehther this is a good thing or a bad thing. Is it a sign that they are no longer interest in developing the language? Then they have jumped onto (J)Ruby and (J)Python. Why? Is this just a cynical attempt to exploit the popular mood? Compared to Self and Strongtalk, the implementations of both these languages is postively amateurish. So why aren't Sun launching a shiny new dynamic language of their own?
I believe that the reason is that they have built up a brand around Java, and that they don't want to do anything to Jeopardise that brand. Hence no new language. Instead they choose to change their ticker tape symbol to JAVA.
This doesn't explain why they don't improve the Java language like Microsoft has done with C#. If I were to hazard a guess, I would say that it is because the JVM is less able to support functional features then the CLR. C# has had delegates from the beginning, so that could be the reason. Also C# and the CLR has generics supported in the byte code, whilst generics in Java is only supported by the compiler. So perhaps the problem is limitations in the JVM, when it comes to implementing new functional features and maintaining backward compatibility.
What ever the reason, Java has fallen behind C#, and I haven't even mentioned how Sun abandoned Applets, leaving the client side to Microsoft and Silverlight.
Why doesn't the Java community hold Sun to account for all this?

Yes I agree. Microsoft has managed to leap frog Java with C#, even though Sun had a massive head start. How did they allow this to happen?

Sun had a massive headstart? C# appeared at least five years after Java, is it a surprise it includes more modern concepts?

-- Cedric

Given history Yes.
Java appeared 15 years after Smalltalk, yet both Java and C# are still playing catch-up.
BTW. Strongtalk, which Sun bought in 1995ish, has static typing on top of a dynamic VM. So Java could have been implemented on top of the Strongtalk VM, with closures and everything. So static typing isn't an excuse :)
Paul.

Hi Uffe,
I just wanted to correct the record on a small point:
FP is being mixed with OO to become a powerful coctail. JavaFX, Python and Ruby may be seen as examples of this.
The idea of mixing funtional programming and OO isn't new. Smalltalk did it years ago in the 1970's
so in Smalltalk:
[x: | x > 5]
Is a lambda expression that takes the argument 'x'. But it is also an object too. It just so happens to be an object declared inline with no state. So in Smalltalk functions are objects too. To get the value of this expression all you need to do is send it a message:
[x: | x > 5] value 10.
The above statement would answer true. Of course lambda expressions can be assigned to varibales like any other object:
lambda := [x: | x > 5].
lambda value 10.
Will answer true too.
Finally, you could probably express your LINQ statement directly in Smalltalk. Let me try:
| seniorNames, dbQuery |
dbQuery := db query.
seniorNames :=
dbQuery from: people
where:[p: | (p DateOfBirth) >= (p LastName)]
orderBy:[p:| p LastName)]
select: [p: | (p firstName), p LastName].
In fact I believe there is a Smalltalk ORM that does this already called GORM, which was the fore-runner to Toplink and Hibernate. It's worth looking it up (even just to show that I've got my smalltalk code wrong :)).
Just proof that there is nothing new in Software.
Regards,
Paul.

FP is being mixed with OO to become a powerful coctail. JavaFX, Python and Ruby may be seen as examples of this.

The isn't quite true. The idea of mixing funtional programming and OO isn't new. Smalltalk did it years ago in the 1970's.

So in Smalltalk:

[x: | x > 5]

Is a lambda expression that takes the argument 'x'. But it is also an object too. It just so happens to be an object declared inline with no state. So in Smalltalk functions are objects too. To get the value of this expression all you need to do is send it a message:

[x: | x > 5] value 10.

The above statement would answer true. Of course lambda expressions can be assigned to varibales like any other object:

In fact I believe there is a Smalltalk ORM that does this already called GORM, which was the fore-runner to Toplink and Hibernate. It's worth looking it up (even just to show that I've got my smalltalk code wrong :)).

Paul, I hope I never said mixing OO and FP was something new. I took issue with the opinion that FP would never go mainstream. While I can see why pure FP languages have a hard time breaking through; I think it is obvious by now that our mainstream programming languages are now beginning to allow for more functional programming.
Your smalltalk sample is indeed very interesting, but AFAIK all languages but LISP lacks the final pillar of LINQ: Expression trees. Please correct me if I'm wrong, but I don't believe that even Smalltalk have the same ability to inspect expression code. I've seen clever attempts using operator overloading in (I believe) Python, but it's not quite the same.
Expression trees are indeed what makes LINQ rock; it's the reason that a developer will feel confident when he queries a database using the very same syntax as when he queries a collection or xml document: The ability for a LINQ provider, say NHibernate, to inspect and even rebuild the query expression before (and if) "compiling" and executing it.
So,
people.Where(p => p.LastName.StartsWith("A"))
is treated differently depending on whether people is of type IEnumerable or ITable. The implementation of Where for the latter will typically take an expression tree (instead of simply a functor), inspect it and generate the corresponding SQL instead of executing it for each candidate.
As far as I recall I have to go back to LISP and its deriviatives to find something similar.

Hi Uffe,
It's nice to see a genuine techie like yourself on a Java forum. Proof they do exists :)

Paul, I hope I never said mixing OO and FP was something new.

You didn't. I was just setting the record straight. A lot of people aren't as well informed as yourself. And some people may of thought that mixing OO and FP is a new idea.

Your smalltalk sample is indeed very interesting, but AFAIK all languages but LISP lacks the final pillar of LINQ: Expression trees. Please correct me if I'm wrong, but I don't believe that even Smalltalk have the same ability to inspect expression code.

I have only read articles about LINQ and was blown away. I haven't devlved into LINQ in detail. I do remember reading about expression trees though. It sounded like an abstract syntax tree. Similar perhaps to a S-expression in Lisp. I don't think the Smalltalk ORM I spoke of does this. It is possibly though I guess, since in Smalltalk all objects carry their source code around with them at run time (along with their byte code). So all the information is there to parse the expression as runtime and bind the query to a different datasource. Smalltalk, has a compiler object that can dynamically compile code. You can also dynamically write code so most things are possible.
You probably wouldn't do this in Smalltalk though, or at least it wouldn't be easy :). The Smalltalk way would be to use polymorphism. So there would be a generic Query protocol with DBQuery and XmlQuery concrete implementations. So you would plug-in the concrete implementation you required, perhaps at runtime.
Not sure if this approach is as powerful as LINQ though (probably not).
Thanks, for sharing. I'll take a closer look at LINQ when I get time.
Paul.

That is actually pretty cool! Through a hack (a doesNotUnderstand: handler) they are actually able to read the message and can then construct an expression tree. Cool.
This is roughly equivalent to what the LINQ "application" LINQ to SQL does. Generalize that and allow other libraries to leverage the same engine and you would be pretty close to LINQ. Smalltalk *is* a pretty cool language. Never occurred to me that you could do something like this.
BTW you are spot on with expression trees being syntax trees. By declaring a method like this:
public IEnumerable Where(Func selector) { ... }
Where becomes a method which can take a functor of type T => bool. But if we instead declare a method like this:
public IEnumerable Where(Expression> selector) { ... }
(note: the TSS cleansing code inserts an extra > after Func which shouldn't be there)
it can be called with the exact same argument, but selector now becomes an expression tree. Expression trees which capture the argument expression structure. They are like S-expressions (again spot-on) and can be inspected and even changed through code. You can also call Compile() on the on the top-level node and receive back a functor/closure which you can execute.
Personally I am blown away with the perspective of this. This goes far beyond querying collections, xml and databases. Think about what this can do for rule engines and declarative validation rules (if only C# allowed expression trees in metadata attributes - there's one of the shortcomings).
I miss this kind of innovation in Java. I have a lot of respect for dynamic languages, but I believe that most of the perceived advantages of dynamic languages are in reality more shortcomings of the static languages which could be overcome and still preserve the static typing.
From the looks of it, Sun could be silently abandoning Java and betting on the dynamic languages. They certainly hype JavaFX, JRuby, Jython and the JVM more than Java the language.
I feel Sun dropped the ball after 1.4. I don't understand how they could ever allow something like generics type erasure and autoboxing proliferate within Java. In retrospect their rejection of Microsofts request to extend Java with delegates (closures) comes across as a bit ironic.
The pendulum is certainly swinging towards the dynamic languages at this time. Which make the C# and Scala innovations all the more interesting because they can achieve most of the same advantages - and bypass in some areas - without sacrificing static typing. Shame about Java.

Do you actually know business reasons why generics were implemented erasure way?

Yes, I believe I do. Some esoteric meaning of "backwards compatibility" which - for the vast majority of developers and java shops - would have been a non-issue.
It was not - what many have been led to believe - about the JVM being able to execute pre-1.5 code unchanged.

While I do agree from software developer's perspective generics can be implemented in much better ways, we can not take from our discussion business requirements.
We gotta make clear distinction in our discussions between perfect solution in technical sense and good enough solution in business sense.
Neal Gafter explains potential consequences on entire supply chain below.
http://gafter.blogspot.com/2004/09/puzzling-through-erasure-answer.html

Neil Gafter explains how a dreamed-up scenario where products with intricate relationships from different vendors *may* benefit from the migration compatibility.
It is a niche issue, dreamed up at the start of the JCP. As the trade-off of type erasure became clear during JCP they basically failed to put the foot down and revisit the original constraint. The sad reality is that this migration compatibility was needed by very few (if any) customers and only under very select circumstances; for which there were plenty of mitigating factors.
Type erasure was designed for

a temporary situation - the migration period from pre-1.5 to 1.5,

customers who didn't have full control of their stack (i.e. no source access) and

where the customer used libraries from multiple suppliers

where the libraries were interdependent and

where one or more of the suppliers were lagging in porting to generics,

interdependencies was not wrappable because best practices had not been followed during the design.

said customer could not wait for the suppliers to have the libraries in synch because he presumably needed absolutely must-have features which were *only* being developed in the generics branch

Whoa - how many Java customers do you think that applies to?
Now contrast that to this list of pecularities because of type erasure which we will have to live with in the forseeable future, perhaps forever:

reference-type only generics,

proliferating unchecked warnings to the extent where even Sun had to supress warnings inside the JDK,

heap pollution risks,

bridge method clashes, base class clashes

incomplete reflection with parameterized types bolted on,

unable to use generic exception types

shared and clashing static members,

inability to take the class or test instanceof of a parameterized type,

inability to use the new operator on a parameterized type to create new instances,

inability to create arrays of a parameterized type

opaque overriding complexities (because types of signatures may be erased)

Runtime performance penalty from both runtime type checking and boxing/unboxing of primitives,

and I'm sure there's more. Was it worth it? I hope the the migrating customers from above are thankful towards JCP, because an entire community pay the price *every day* from now on, also after they have successfully migrated their libraries.
In retrospect (admittedly) Java generics are so problematic and diluted that the transition period has been prolonged.

So the JVM doesn't support Generics, But C# has them so Sun decides me too, only that they will implement it as syntactic sugar in the compiler instead. And they are calling this type erasure? I'm not a static man, but I'm sure type erasure is a means of making Generic programming more OO by hiding the parametric type. So you can do this in C# too. If I remember correctly there was an article about it on InfoQ.
Just like my point on static optimising compliers for both the JVM and CLR, leaving them with a crippled VM architecture. The excuse is that well we want type safety. Whilst the truth is that they didn't want to go to the trouble of implementing dynamic optimising compilers which compile at runtime, compiling interpreted code on the fly and caching it, and de-compiling code when needed so as to maintain full polymorphic semantics.
Sun invented these techniques, yet they have never released them in a supported language. Why?
Firstly, they needed to get a platform to market quickly to stop the Microsoft Juggernaut. This is forgivable. But why not go back and do the job properly later? And worst still, why lie to us?
I just don't think they believe us programmers are smart enough to know when we are being hood-winked. They think all they need to do is turn on the marketing charm and that we will toe the line,like lemmings.
The other way to look at it is that we are only getting what we deserve. Gosling wanted to limit the number of features in the Java language at the outset. The idea being that a simple language would have mass appeal. Well he was right. how many of us could forsee the problems laying in wait in the future? I didn't. I knew Java wasn't Smalltalk, and I did pause to question it's longevity, but I believed the hype just like everyone else.
If there is a moral to this story, then it is buyer beware. We owe it to ourselves to know exactly what we are investing our time into. So the bottom line is that we as programmers are partly responsible aswell.
This is why it infuriates me so that so few programmers take time to find out these things for themselves. I guess for most it's just a job :(
Paul.

I knew Java wasn't Smalltalk, and I did pause to question it's longevity, but I believed the hype just like everyone else.

So to you, Java is all hype and you wish it had followed the Smalltalk model.

Priceless.

-- Cedric

I don't know how you managed to read that. The point was that Java was sold as a good enough Smalltalk. It evidently isn't, otherwise RoR wouldn't exist.
Sun did hype Java as the platform of the future. "Write once and run anywhere". We were promised Java in our offices, homes, cars, and even in our jewelery :) Even if Java did turn out to a good enough Smalltalk, I never felt comfortable with the "one size fits all" model. The only way to get on the Java platform was with Java. Comparing this to the Unix platform, it always seemed pretty limiting to me. That model T Ford thing, any colour you like as long as it's black.
Then Microsoft came along and got the marketing right with the "Common Language Runtime", the only problem was that they didn't get the technology right. Choosing mostly to ape the JVMs mistakes.
So where are we today? Well we are in desperate need of a cross language platform, yet both of the mainstream contenders fall short. Don't wait for things like the DLR to deliver Strongtalk like performance any time soon :)
S what's your solution? Don't tell me use Java for everything forever right?
Now that sounds like a future proof suggestion :)
Paul.

how many of us could forsee the problems laying in wait in the future?

Honestly I haven't seen this much QQ since Backstreet Boys disbanded.
I have no idea what are you talking about, you make it sound like its the end of the world here, like current state of Java is soooo bad, like real development can not be done without closures or whatevar, like Sun has some conspiracy against the world.

Java is soooo bad, like real development can not be done without closures or whatevar,

Java was a blessing in 1995, especially compared to C++. Compared to what it could have been though, it was past its sell by date at birth. Lots of good stuff has been done in Java, but the Java ecosystem is running out of steam, mainly due to weakness in the language that were there at the outset and have never been addressed in a fundamental way. (I don't call using XML and annotations as an extension to the language, as fundamentally addressing problems in the Java language itself).

..(like) Sun has some conspiracy against the world.

Not I don't think they have a conspiracy. That would require some fore-thought and some planning :). No just plain old incompetence I think. Lots of companies are like Sun with no clear focus and vision for the future. This is not unusual. My question is, why have we as consumers done such a poor job at holding them to account?
Paul.

Hi Chief,
I know I sound opinionated. So I have spent a bit of time trying to track down some cooberating evidence. Google is great. I remember once reading an article about the history of Java. Googled a bit and found this:

[Bill Joy] was often comparing Oak to more complicated and elegant languages like Python and Beta. He would often go on at length about how great Oak would be if he could only add closures and continuations and parameterized types. While we all agreed these were very cool language features, we were all kind of hoping to finish this language in our lifetimes and get on to creating cool applications with it. The more we argued with Bill about making those changes the more strongly he would fight us. After a while it became a choice between not having Bill involved at all or losing control of the language. James [Gosling] and I got into a rather epic battle with Bill in his office in Aspen one evening about this issue. He started out by insulting both of us about how poorly Oak compared to better languages and then he volunteered to resign from being the Live Oak architect if we wanted him to. James and I agreed that would be best and walked out to go across the street to watch "Speed". What a rush.
The next day, Bill was pretty much his normal old nice guy self again, a little relieved, I think, to be out of the role of being directly responsible for our destiny. Bill is annoyingly smart, and I wouldn't put it past him to have planned that whole scenario the night before to force us to defend our positions and take ownership of our project. The interesting thing is that we were right about needing to finish the language even though it had missing features. It was a timing issue, there was only about a three-month window in which the whole Java phenomenon could have happened. We barely made it. It is also interesting that Bill was absolutely right about what Java needs long term. When I go look at the list of things he wanted to add back then, I want them all. He was right, he usually is.

I know I sound opinionated. So I have spent a bit of time trying to track down some cooberating evidence.

Its good to finally see discussion without discredit tactics.
While its ok to disagree, and I do understand Java has some problems, though I dont feel they are as big as you present them, it would be great to see short list of things you feel Java should have with pros and cons provided as well, because it seems we are jumping from one topic to another.
We are all techies after all, so lets keep things simple and clear, without novel-like speeches describing the things which are not related to discussion at all.
So if you are still interested to discuss, please provide list of things Java is missing and whether those proposals will solve some problems which can not be solved with current Java state.

I know I sound opinionated. So I have spent a bit of time trying to track down some cooberating evidence.

Its good to finally see discussion without discredit tactics.

While its ok to disagree, and I do understand Java has some problems, though I dont feel they are as big as you present them, it would be great to see short list of things you feel Java should have with pros and cons provided as well, because it seems we are jumping from one topic to another.

We are all techies after all, so lets keep things simple and clear, without novel-like speeches describing the things which are not related to discussion at all.

So if you are still interested to discuss, please provide list of things Java is missing and whether those proposals will solve some problems which can not be solved with current Java state.

Hi C heif,
I believe everything I've said is relevant to the subject: "Java has the Flu".
I can be as specific as you like. The problem is that we both start with a different prior context. I knew Smalltalk and programmed with Smalltalk before using Java. So this is my comparison. I am assuming that Java is meant to be an high level OO language for application programming, and not a system language like C++.
What features are valuable depends on what you are trying to do. The idea that you do need more features then are available in Java in an application language in order to raise the level of abstraction to an higher plane is self evident to me. I am assuming that application programmers want the highest level language pertinent to their domain that they can find. I am suggesting that DSL's are more powerful then APIs, and that certain language features are required to support the creation of powerful DSLs
My short list is:
* A uniform object model (everything is an object)
* Metaprogramming
* Closures,
* Mixins
* Open classes
* An expressive type system
I guess you don't share this view. Thats fine, but you need to ask specific questions, and I will try and answer them from my perspective. Or you need to make a case for your point of view (what ever that is).
BTW. There is a lot of material available publically. So you can research and find out a lot of this for yourself. My only goal here is to provide a different perspective, to that which is considered "gospel" amongst many in the mainstream programming community. Debunking what I see as myths.
I guess it is up to you to test my perspective independently if you choose. But I believe I have provided a lot of cooberating evidence including code examples (ORM in Smalltalk), links to superior platforms (Strongtalk) and references to a primary historical source (Patrick Naughton)
Paul.

Agree.
Can you please define concrete problem you are having in Java and how those features you mentioned map to them, for example problem you had in commercial Java development and you could NOT solve it due to limitations of Java language/platoform.
List you have provided seems more like your personal wish list, or how language should look like in an ideal world.
I feel that every feature you have lisited can be accomplished/emulated in Java in some way as of now.
While I do agree Java needs some polishing here and there, it is important to note that any major change you are promoting has global IT market impact, and we are talking here about billions of dollars of investement and is it crucial to discuss the level of risk the changes you are promoting can bring on global Java IT market.
Did you actually ever had situation where you like said to client "I can not satisfy your business requirements because of the limitations of Java language/platform"?

Can you please define concrete problem you are having in Java and how those features you mentioned map to them, for example problem you had in commercial Java development and you could NOT solve it due to limitations of Java language/platoform.

List you have provided seems more like your personal wish list, or how language should look like in an ideal world.

I feel that every feature you have lisited can be accomplished/emulated in Java in some way as of now.

While I do agree Java needs some polishing here and there, it is important to note that any major change you are promoting has global IT market impact, and we are talking here about billions of dollars of investement and is it crucial to discuss the level of risk the changes you are promoting can bring on global Java IT market.

Did you actually ever had situation where you like said to client "I can not satisfy your business requirements because of the limitations of Java language/platform"?

Hi Chief,
I don't need to justify my preferences in the same way that you don't need to justify yours. My list is based on my experience delivering enterprise applications.
Like I said before, the main issue should be choice. You get to choose your tools and I get to choose mine, then we compete in an open market place. A near monopoly is no good for anyone, especially customers.
Until very recently C# and Java where virtually the same thing, so as far as main stream programming is concerned there was little choice. Now we have viable dynamic alternatives like Ruby and Python to choose from. We also have advanced static languages like Scala too.
Interesting times... Let the competition begin!
Paul.

I don't need to justify my preferences in the same way that you don't need to justify yours.

Agree, and my posts definitely did not have that intent, though they might have sounded that way unintentionally.

A near monopoly is no good for anyone

I highly disagree with this statement. It seems that for the first time in the history of IT we have platform that provides free tools/frameworks for almost any domain imaginable, and that is what one calls a choice and not monopoly.
We have tools ranging from cluster, grid, build, test, develop, persistence, tx processing, infrastructure, scientific, reliable messaging, integration, search engine, rules engine, business process management, web UI, compiler generators, web server, enterprise content management, amazing XML tooling support, and many many more.

Well luckily we have duopoly and not monopoly, so people can work on .Net if they prefer. =)
Also, end customer/end party in supply chain is not suffering from duopoly, and it is even for their benefit to have stable ecosystem like Java.
There are simply too many investements in tools, human know-how to justify any big change, unless those changes would bring dramatical savings, and changes we have discussed here are hard to bring any significant savings, if any, when compared to lets say skilled Java developer.
Ecosystem ----> http://java-source.net/

Hi Paul,
First of all, I have to say I much prefer the tone of your more recent messages, because they are focused a lot more on technical details than personal attacks. Please keep it up :-)
I do agree with quite a few things you said in this message, but I'd like to pick on this particular part where I don't:

I am suggesting that DSL's are more powerful then APIs

First of all, I don't believe there is an absolute answer to this question, but on a subjective level, I am more and more inclined to disagree with this assertion. I used to be a strong supporter of DSL's, but after observing that they seem to be creating a lot more chaos than order, I'm slowly begining to suspect that their usefulness is being massively overhyped. Of course, Java's longevity and evolution over the years is also a testament to the fact that a syntactically rigid language can remain relevant with API's alone despite constant attacks on many technical fronts.
Having said that, there are two factors that could cause me to reconsider my position on this subject in the near term future:
1) So far, we haven't really seen statically typed DSL's, which is the main reason why their adoption is so awkward and not always a step forward in terms of maintainability and clarity of code. It will be interesting to see if LINQ will change that.
2) You could argue that the current DSL mess is just because we are in the first generation of DSL's, so hiccups are inevitable.
Until the dust surrounding these two points dissipates, I think that API's invoked with slightly more verbose constructs win hands down in mindshare and productivity over DSL's.
--
Cedric

Hi Cedric,
If these are your only objections then they are easily overcome:

1) So far, we haven't really seen statically typed DSL's, which is the main reason why their adoption is so awkward and not always a step forward in terms of maintainability and clarity of code. It will be interesting to see if LINQ will change that.

If you want Manifest type annotations with your DSLs, then this is possible. A few years ago Python was considering adding type annotations, and like I say Strongtalk has them. The advantage of this approach is that you get the documentation and tooling advantages of static typing without the downside of artificially constraining the computational model. Which is on of the reasons why it is difficult to write DSLs with Java, C#, C++ etc.

2) You could argue that the current DSL mess is just because we are in the first generation of DSL's, so hiccups are inevitable.

We are by no means "in the first generation of DSLs". It is true that Martin Fowler only coined the term DSL relatively recently, but if you look at the article where he came up with the term, he makes it clear that DSLs have been with us for a very long time, citing examples in Lisp, a language that goes back to the 1950's.
This has been my point all along. These ideas are well known and not new. They are only new to a mainstream audience. In the same way that "multi-tasking" was new to the public when Microsoft launched Windows 95. To those in the know, multi-tasking has a long history and can be traced back to Lisp and work performed by John McCarthy in the 1960's.
I apologies if you find my tone offensive, and I'm happy to clear up any other concerns you may have with what I am suggesting.
Paul.

I don't know, I don't really see how this story reflects so well on Bill Joy. Looking at a project and saying "we need to do more" is a very easy position to take. Computer science history is filled with such projects that died because they either collapsed under their own weight or because they missed their window.
I find it much harder to make compromises and to know when meeting a deadline is more important than adding a feature, and for that reason, Gosling has my respect much more than Bill Joy (who is undoubtedly a smart guy, but come on, he hasn't been exactly succesful with his projects... anyone remember Jini? JXTA?). Besides, even the features and concepts he wanted to add back then are still not considered a good idea even now (continuations? Getting more inspiration from Beta?).
--
Cedric

Neil Gafter explains how a dreamed-up scenario where products with intricate relationships from different vendors *may* benefit from the migration compatibility.

While your points are valid to certain extent, I still feel that business level decision they made was correct and sound, they simply wanted to protect businesses that have made investments in Java, and me, as representative of business that is currently investing in Java, is feeling more secure to adopt Java even further.

Hi Uffe,
documenting your code at compile time. Instead it was primarlily a way of providing information to the complier so that it could perform code optimisations. For example C has static types, but it is a weakly typed language, because the goal of the type system isn't type safety but code optimisation. We know better now (well actually we have known better since the early 90's when Self came up with it's polymorphic inline cache). Mostly due to research performed at Sun Microsystems :). This is why a Smalltalk style VM is infinitely more flexible then a VM like the CLR or JVM and why it is much easier to extend and modify Smalltalk then it is Java or C#. Self, Ruby, Python, Java. Scala, C# could all be compiled to run on a Smalltalk VM, all with good performance.
So the bottom line is that you can have both. Static types AND and a dynamic language. The two ideas are not orthogonal. This as been done too.
Paul.

The pendulum is certainly swinging towards the dynamic languages at this time. Which make the C# and Scala innovations all the more interesting because they can achieve most of the same advantages - and bypass in some areas - without sacrificing static typing. Shame about Java.

This static versus dynamic thing is another bit of mis-information. You can do static type analysis with on a dynamic language with a dynamic VM. Static analysis has nothing to do with what happens at runtime and doesn't have to be built into the byte code and the VM. Strongtalk with it' pluggable type system has shown this:
http://www.strongtalk.org/
What we have with the JVM and the CLR isn't just static analysis, but a bunch of bits full of magic numbers and offsets in the byte code. Once your code gets past the verifier, you are back to C land with offsets and pointers, all semantic meaning has been removed. This is a left over from the C/C++ days when static typing wasn't seen as a way of analysing and documenting your code at compile time. Instead it was primarlily a way of providing information to the complier so that it could perform code optimisations. For example C has static types, but it is a weakly typed language, because the goal of the type system isn't type safety but code optimisation. We know better now (well actually we have known better since the early 90's when Self came up with it's polymorphic inline cache). Mostly due to research performed at Sun Microsystems :). This is why a Smalltalk style VM is infinitely more flexible then a VM like the CLR or JVM and why it is much easier to extend and modify Smalltalk then it is Java or C#. Self, Ruby, Python, Java. Scala, C# could all be compiled to run on a Smalltalk VM, all with good performance.
So the bottom line is that you can have both. Static types AND a dynamic language. This as been done too.
Paul.

Your professor has been proven wrong. FP is being mixed with OO to become a powerful coctail.

Reread the question, it seems to me the professor was dead on. At least as of today.
Your example below is simply showing that C# with a mix of relational and functional theory is mainstream, but if you want to have some fun, join a functional programming mailing-list, go claim there that C# is a functional language and let us know how it goes.
As for your other point, the jury is still out about whether LINQ is a hit or not. I guess we'll find out in a couple of years.
If anything, I would say that closures are definitely making the cut and are being integrated in a bunch of programming languages, but I can't really think of any other core functional concepts in the same situation.
--
Cedric

As for your other point, the jury is still out about whether LINQ is a hit or not.

The jury is still out. What since the 1970's :) You make it sound as though the adoption by the mainstream is the acid test of whether a technology is a valid approach.
The main stream has been making bad decisions since before the Apple Mac lost out to MS-DOS.
I agree with you that the mainstream will continue to make pure choices. The issue (as I've mentioned on your blog), is whether the rest of us are obliged to make the same dumb choices too.
All that is needed is that the alternatives have the critical mass required to form their own viable ecosystem. Both Python and Ruby have achieved this (Mac OS X has now achieved this too :)), and it looks like other languages are well on the way to achieving the same aswell.
Like I said before, everyone doesn't want to run with the herd. I just want a viable alternative that works for me :)
Paul.

Reread the question, it seems to me the professor was dead on. At least as of today.

Cedric, I just wanted to make the point that while functional programming languages (the pure kind) may have a hard time breaking through, functional programming (the term used in the question) is indeed breaking through.

if you want to have some fun, join a functional programming mailing-list, go claim there that C# is a functional language and let us know how it goes.

lol. I would never venture a claim that C# is a functional programming language. C# is a very pragmatic language and as such it has incorporated constructs from functional programming. It allows you to use FP constructs where it makes sense, but C# is first and foremost an OO language.
Now C# definately also has issues, in some ways it is about to outgrow its heritage. When a language evolves by bulking things on top of it it will keel over at some point. Perhaps that is what Sun/JCP is afraid of with Java. In my experience bad design (in languages or in software systems) has a tendency to spread like wildfire. A design smell in one corner will soon force you to make compromises elsewhere.
But if that's the case I really don't see how Sun and JCP partners can justify the botched generics. That is a language smell if there ever was one.

As for your other point, the jury is still out about whether LINQ is a hit or not. I guess we'll find out in a couple of years.

Oh, LINQ is a hit. The Jury may still be out on whether something like LINQ to SQL is a good idea, but LINQ is taking .NET developers with storm. Remember, LINQ is not about databases access. It's just a number of language features, all of which have been seen in some other languages at some point. It may be used for database access among other things; indeed the .NET port of Hibernate, NHibernate offers a LINQ provider. My above example would look the same if it was used with a database mapped through NHibernate.
IMO Java (the language) is seriously lacking in a number of areas which translates directly into developer productivity. This is both small things, like properties and bigger features like closures, and yes, integrated query.
Java the platform is more alive than the language. Personally I think Scala is really cool, but that is probably just because I am and old static guy.
But the point of the original article was concerns that Java the language were being starved for resources because of the focus on new, more narrow languages/features such as JavaFX. I agree with that concern. In fact, over the last couple of years Sun has changed its marketing from Java (the language) to the JVM. They hype the new, dynamic languages in a way which must make any Java developer wonder how that is going to affect their big investments in skillset, libraries, education, ecosystem, software systems.
I know that libraries to some extent can be reused under the new languages, but being old in this business I think I have heard that one before. We will still be able to do Swing, use Hibernate or Spring under the new shiny dynamic languages, except for the fact that the feeling of orthogonality is gone.
We all know that a lot of design decisions of Hibernate was directly dictated by the features and limitations of Java. Another language - especially the dynamic ones - will have exhibit totally different features and limitations making something like Hibernate stand out as an anachronism.

I mean, if the future of Java is just handling complex and high volume business then I'm missing the downside.

You are absolutely right. Java is a powerful language and if it plays its cards right it could even have a long run like Cobol. My $0.02 is that Cobol lost out when it failed to take seriously the challenge of creating a client/server UI.
I think the same thing is happening now. Java has not seriously addressed the challenge of building a rich web UI (call it Web2.0 if you must).
Nowhere is it decreed that Java can't provide a powerful back-end for an equally powerful Ajax front end.
And while we're on the topic, is it my imagination or has TSS been invaded by a troupe of Adobe fan-boys? I thought we were all done with astroturfing now that Marc Fleury got his gazillion dollars from Red Hat ;-)?
Java and Javascript may have their faults, but at least you can do string manipulation in them without blowing a gasket.

Yet there's the entire realm of difficult to do programming where Java's reach and reliability have no parallel. That stuff isn't pretty, easy or fun. It's ugly, nearly impossible and excruciating ... which is why the people who can do it tend to get paid well ... like those COBOL folks.

This is why Java is a dead end. Complacency. Anyone who thinks a language that still has primitives, no means of declaring a lambda expression, and call it's self OO without supporting metaprogramming and OO abstractions like mixins has no "parallel" for "difficult to do programming" is either ignorant or totally deluded.
Java is not a high level language compared to something like Scala, and yes even "scripting" languages like Python and Ruby are higher level languages. Even it's sibling C# has the jump on Java with it comes to language features that support higher level abstractions like closures.
Don't confuse wide spread industry use with being fit for purpose. These is the same industry that bought into Visual Basic and which also decided that C/C++ was a great choice as an application language.
You can fool some of the people some of the time, but you can't fool all the people all of the time, and it is complacency like this that ensures that when the winds of change come (and they will) Java will not be the only thing with the Flu. A number of Java programmers without the skills to do anything else will end up catching the flu too.
Paid well? I would hazard a guess that most Cobol programmers have been squeezed out of a programming career all together and are now "doing other things".

Hi Mark,
As you know I have been posting on TSS for quite sometime now, and many of the things I was saying when I was just a lone voice have come to pass. Who would have guessed that a dynamic language like Groovy would be the hot thing on the Java platform 5 years ago?
Read the article and I think it makes my point:

"Without a doubt, it is a challenge to find a developer in Cobol who is not nearing retirement age,"

So where all the young university graduates trained in Cobol an eager to earn the big bucks?
Like I say a frank discussion about Java on TSS just wouldn't have happened even 2 years ago. And if the fate of Cobol is the sole remaining argument for sticking exclusively with Java, then the language and it's ecosystem is really in a bad shape.
Paul.

As you know I have been posting on TSS for quite sometime now, and many of the things I was saying when I was just a lone voice have come to pass. Who would have guessed that a dynamic language like Groovy would be the hot thing on the Java platform 5 years ago?

Read the article and I think it makes my point:

"Without a doubt, it is a challenge to find a developer in Cobol who is not nearing retirement age,"

So where all the young university graduates trained in Cobol an eager to earn the big bucks?

Like I say a frank discussion about Java on TSS just wouldn't have happened even 2 years ago. And if the fate of Cobol is the sole remaining argument for sticking exclusively with Java, then the language and it's ecosystem is really in a bad shape.

Paul.

These ROR and Groovy vs. Java debates echo the Tk/TCL,Perl,Python vs C/C++ of old. Every couple of years a new dynamic language appears that we should all jump ship for and each year they strive along and virtual mediocrity, IMO.
There's is plenty to pick up in the Java space, comparisons to COBOL notwithstanding. If Java is so lame, go to the Ruby boards. If frameworks are so bad, don't use them.
But let those who wish to continue riding this locomotive enjoy our delusions in peace. Sheesh.

As you know I have been posting on TSS for quite sometime now, and many of the things I was saying when I was just a lone voice have come to pass. Who would have guessed that a dynamic language like Groovy would be the hot thing on the Java platform 5 years ago?

Read the article and I think it makes my point:

"Without a doubt, it is a challenge to find a developer in Cobol who is not nearing retirement age,"

So where all the young university graduates trained in Cobol an eager to earn the big bucks?

Like I say a frank discussion about Java on TSS just wouldn't have happened even 2 years ago. And if the fate of Cobol is the sole remaining argument for sticking exclusively with Java, then the language and it's ecosystem is really in a bad shape.

Paul.

These ROR and Groovy vs. Java debates echo the Tk/TCL,Perl,Python vs C/C++ of old. Every couple of years a new dynamic language appears that we should all jump ship for and each year they strive along and virtual mediocrity, IMO.

There's is plenty to pick up in the Java space, comparisons to COBOL notwithstanding. If Java is so lame, go to the Ruby boards. If frameworks are so bad, don't use them.

But let those who wish to continue riding this locomotive enjoy our delusions in peace. Sheesh.

Good point. I was expecting reasoned debate here. I guess I'm the one who is deluded :)

Quotes from PB:
"You can fool some of the people some of the time, but you can't fool all the people all of the time,"
"I was expecting reasoned debate here. I guess I'm the one who is deluded :)"
No offense, but you are trolling. You come here and tell all these Java people that run millions of Java applications in production how they are deluded, how there is some great Java conspiracy, how we are ignorant et al.
I dont see Java developers trolling RoR forums, do you?
Face it, people use Java cause it is good, it gets job done, and its best platform currently on the market for any serious development, CRUD web apps excluded.

Quote from PB: no means of declaring a lambda expression, and call it's self OO without supporting metaprogramming and OO abstractions like mixins has no "parallel" for "difficult to do programming" is either ignorant or totally deluded.
Again obvious troll is obvious, if someone disagrees with you opinion he is "either ignorant or totally deluded", which is in itself ignorant.
You see, your vision of how main stream language should look like is not the ultimate truth, and hence if you wanted to have quality discussion you would not state that anyone disagreeing with your opinion is ignorant.

Scripting languages (Ruby, Groovy) are far from a panacea.
People seem to miss the point that Java has typesafe compile time checking by design, and for good reason.
People seem to tout dynamically, weakly typed languages as a silver bullet that Java should aspire to.
In my experience (of many years), scripting languages quickly become unmanageable-. Larger scale, longer lived systems are better served with stongly typed languages.
For large scale projects, with multiple teams that need to survive the test of time and maintainability my experience is that scripting languages deteriorate fast.
Being able to look at a method signature and clearly tell exactly what parameters it can handle, without necessarily needing to resort to documentation/comments or reading the internal is invaluable.
** The above point is not to be overstated. **
When I look at a signature for a scripting language (Ruby, Groovy, Python etc.) I haven't a clue what the interface contract is without resorting to reading comments or trawling through the internal code. Maintainability is a nightmare. Design by contract is loose at best.
How many systems out there started as small apps and grew to large scale quickly? I have come across many Python and Perl apps rewritten over the years due to them becoming unmanageable.

As you know I have been posting on TSS for quite sometime now, and many of the things I was saying when I was just a lone voice have come to pass. Who would have guessed that a dynamic language like Groovy would be the hot thing on the Java platform 5 years ago?

Read the article and I think it makes my point:

"Without a doubt, it is a challenge to find a developer in Cobol who is not nearing retirement age,"

So where all the young university graduates trained in Cobol an eager to earn the big bucks?

Like I say a frank discussion about Java on TSS just wouldn't have happened even 2 years ago. And if the fate of Cobol is the sole remaining argument for sticking exclusively with Java, then the language and it's ecosystem is really in a bad shape.

Paul.

I don't think you were exactly reading it right. I was looking for another article but got distracted. It is about schools putting out new and younger COBOLers to fill the gap being left by those retiring. I've done COBOL and Java. Java is not COBOL or acting like COBOL. There are many new things in Java and there is much left to learn. Is it perfect? No. Stagnant? No.
Honestly, I see little excitement about dynamic languages. I am sure there is some somewhere. They have their place and we need to learn them. But should I dump Java to do RoR webapps? I don't do pure webapps. I am still trying to figure out where those sort of things fit in to what I do. I don't want to be doing apps where I can be replaced by a robot.

As you know I have been posting on TSS for quite sometime now, and many of the things I was saying when I was just a lone voice have come to pass. Who would have guessed that a dynamic language like Groovy would be the hot thing on the Java platform 5 years ago?

Read the article and I think it makes my point:

"Without a doubt, it is a challenge to find a developer in Cobol who is not nearing retirement age,"

So where all the young university graduates trained in Cobol an eager to earn the big bucks?

Like I say a frank discussion about Java on TSS just wouldn't have happened even 2 years ago. And if the fate of Cobol is the sole remaining argument for sticking exclusively with Java, then the language and it's ecosystem is really in a bad shape.

Paul.

I don't think you were exactly reading it right. I was looking for another article but got distracted. It is about schools putting out new and younger COBOLers to fill the gap being left by those retiring. I've done COBOL and Java. Java is not COBOL or acting like COBOL. There are many new things in Java and there is much left to learn. Is it perfect? No. Stagnant? No.

Honestly, I see little excitement about dynamic languages. I am sure there is some somewhere. They have their place and we need to learn them. But should I dump Java to do RoR webapps? I don't do pure webapps. I am still trying to figure out where those sort of things fit in to what I do. I don't want to be doing apps where I can be replaced by a robot.

Hi Mark,
I think you missed my point too. The choice isn't Java or RoR, it is much wider then that. Also you don't need to commit to exclusively using one language or the other. That idea is so 90's :)
As a craftsman you should have several tools in your tool box, and be able and willing to select the right tool for the Job. At a moment in time Java was that tool in a lot of scenarios when compared to C++, but with moores law and the general improvement in both hardware and software technology , we know have more choices.
Groovy and Grails gives you the advantages of RoR, with a Java friendly syntax. You also still have access to all those "heavy weight", "industrial strength" Java/JEE APIs too :)
If you want to stick with static typing, you have the choice of Scala. You probably don't know it but the type system in Java is not very expressive, one of the reasons why standard libraries like Calendar are such a mess. Scala with it's more advanced Type system and language features allows you to do things in a more OO way. Then there is the client side, which Sun has gifted to Microsoft (Silverlight) and Adobe (Flex).
You strike me as an intelligent guy. Why wear blinkers and limit your options? It just doesn't make sense to me.

As a craftsman you should have several tools in your tool box, and be able and willing to select the right tool for the Job.

I know. And I do. But that means I get to choose Java when I think it is right (not be chastised for it, not looked down at for it and not be considered non-passionate). And it often is. And almost always is in the type of work I do. We've been down this path before.

You strike me as an intelligent guy. Why wear blinkers and limit your options? It just doesn't make sense to me.

Why do you think I am? Ask anyone who knows me (well not my wife) and see if they think I have blinders. I know you mean well Paul but your tone (on pretty much every thread) is - if we haven't dumped Java or defend it at all then we have blinders on. Like this -

But people that are passionate about what they do: Small independent startups and the like, will continue to choose Java less and less.

Sorry but I am VERY VERY passionate about what I do. Again, ask anyone who knows me (and this you can ask my wife). AND I am doing small independent startup in addition the Big shop stuff. I am still (mostly) choosing Java? Why? cause I can reuse and do more while doing less with Java. Sure, there is some Drools and Groovy tossed in.
From what i have seen Ruby and RoR is more like COBOL than Java. It is pretty good at "DB driven" web apps. But desktop apps? Desktop/Web/Batch/etc all in one apps? COBOL is pretty good at... . :)

As you know I have been posting on TSS for quite sometime now, and many of the things I was saying when I was just a lone voice have come to pass. Who would have guessed that a dynamic language like Groovy would be the hot thing on the Java platform 5 years ago?

As they say, "past performance is no guarantee of future results", but I have to say I find it quite puzzling that you choose to prove your prediction skills by mentioning Groovy.
We can agree on one point, though: in five years from now, Scala will probably be as popular and widespread as Groovy is now.
--
Cedric

As you know I have been posting on TSS for quite sometime now, and many of the things I was saying when I was just a lone voice have come to pass. Who would have guessed that a dynamic language like Groovy would be the hot thing on the Java platform 5 years ago?

As they say, "past performance is no guarantee of future results", but I have to say I find it quite puzzling that you choose to prove your prediction skills by mentioning Groovy.

We can agree on one point, though: in five years from now, Scala will probably be as popular and widespread as Groovy is now.

-- Cedric

Hi Cedric,
I think languages have an impact on the way you think. C/C++ people always had this obsession with optimisation and ofuscation. Do you remember the obfuscated C competitions? How much you could get C to do in a single line of Code. I haven't seen this with any other language.
There is also differences with levels of abstraction. Hiding irrelevant details, and allowing you to express your problem more directly. Smalltalk is great for this, and the dynamic scripting languages have picked up on this idea to some degree. Just compare iterating over a collection in C++/Java compared to sending a message to a collection with a lambda expression as a parameter.
Then, lastly there is elegance and beauty. I struggled trying to learn OO for years with the hybrid procedural/OO language C++. Moving to a pure language (Smalltalk), it came to me immediately. BTW I would say that most Java programmers still do not understand objects to this day, precisely because of this reason. The amount of procedural Java code (even in respected frameworks), I come across is amazing. Incidentally the idea of purity of concept and iniformity has never left me, which is why I am now learning Haskell to gain a fuller grasp of functional programming.
Lastly about Groovy. In the UK at least, it seems to be getting traction amongst Agile teams who are looking for something faster than Spring, but want to leverage their investment in Java.
Just the other day, I had a discussion with a Java guy over why we didn't need a couple dozen DAO's using generics for type safety, and why a single persistance manager object and the odd cast in our code was fine. Expecting the usual static language paranoia, I was surprised when he said, yes I see what you mean. Grails does something similar.
The world is changing and moving in my direction. But I don't see why this should be perceived as a threat by anyone. I see it as an opportunity. We have hit the limits of what API's can do in the Java world without more powerful, higher abstraction mechanism in the language itself.
A kid out of college, using a language written by a home hobbiest in his spare time, have managed to produce a framework that is an order of magnitude more productive then what the brightest and best have been able to do in the multi-million dollar Java industry. This should be a wake up call to everyone. Others are acting on it. Some in the Java community aren't, which is a shame because I was attracted to Java because it was brave and forward thinking (in comparison to C++). Over the years this spirit has been lost, and now in many ways Java is now part of the problem.
Like Alan Kay says, the computer revolution hasn't happened yet. We still have a long way to go and Java isn't the end of the line.
I agree with you about Scala's future. I just wish it wasn't so ugly :).
Paul.

BTW I would say that most Java programmers still do not understand objects to this day, precisely because of this reason. The amount of procedural Java code (even in respected frameworks), I come across is amazing. Incidentally the idea of purity of concept and iniformity has never left me, which is why I am now learning Haskell to gain a fuller grasp of functional programming.

All this talking about how programming languages should look like coming from someone who is yet to learn functional programming.
No offense.

BTW I would say that most Java programmers still do not understand objects to this day, precisely because of this reason. The amount of procedural Java code (even in respected frameworks), I come across is amazing. Incidentally the idea of purity of concept and iniformity has never left me, which is why I am now learning Haskell to gain a fuller grasp of functional programming.

All this talking about how programming languages should look like coming from someone who is yet to learn functional programming.

No offense.

Do I sense fear in your words? So we are back to personal attacks and shooting the messanger. Expert on pure functional programing, please explain to me what Monads are for?
After watching a presentation on Newspeak a New OO language from the guy who use to be responsible for the JVM (Gilad Bracha), I realised that dispite comming across lamda expressions in Smalltalk, Lisp and Ruby, there was still gaps in my understanding when it comes to pure functional programming. So I decided to plug the gaps, as past experiences has shown me that this will make me a better programmer overall in any language.
This is the problem with the mainstream. They read a "Learn Java in 21 days" book and then they think they know it all already. Well I'm quite happy to admit that I do not know it all, and that there is a lot for me still to learn!
I think it's time to leave Java land. My blood pressure is rising :)
Paul.

Come on, we all know Monads are banana-like fruit from Africa.
This is not meant to be personal attack, but you come here and preach, you don't express your opinion but rather try to teach and enlighten all these Java developers how you are right, and every Java developer is wrong, and if someone disagrees with your opinion than he is ignorant, lives in the box, close-minded.
If you think that regular visitors/readers/posters of this community are "Learn Java in 21 days"-like people you are very very wrong my friend.

This is why Java is a dead end. Complacency. Anyone who thinks a language that still has primitives, no means of declaring a lambda expression, and call it's self OO without supporting metaprogramming and OO abstractions like mixins has no "parallel" for "difficult to do programming" is either ignorant or totally deluded.

Do you seriously believe that languages matter that much? Really? This makes me wonder who is really deluded.
Hardly anyone cares about this stuff any more.
What makes Java invincible for the short and medium term future is the ecosystem that surrounds it. Mindshare.
Articles, books, mailing-lists, dozens of high quality frameworks (and hundreds of mediocre ones too) covering all the imaginable fields of technology and business, developer and user tools that run rings around similar tools developed just ten years ago.
I like Scala, Ruby and fun dynamically typed languages like the next programming language lover, but if you really think that Scala's native support of closures and mixins will make it the next superstar, I'd like to make an appointment with you in five years from now so we can have a good laugh.
On a related topic, I suggest reading the fun debate between Steve Yegge and myself on this very topic:
http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.htmlhttp://beust.com/weblog/archives/000483.html
--
Cedric

Cedric, I about choked with laughter about what you said about Emacs. :)

Hi Cedric,
I thought we where winning you over. What happened? Your blog entry is fun. At the end of the day though when it comes to the mainstream its hard to make any predictions and time may prove you right :)
I'm not as certain as I use to be, and I have gotten rid of my crystal ball :) The biggest factor as always are the people, and the best and the brightest are looking beyond Java I find.
In contrast, Java seems to be all the rage in offshore shops in India :)
To be honest, I don't want to run with the herd. I just want a viable alternative that works for me. I think this degree of choice now exists, and it isn't going away anytime soon.
Each of use gets to choose our own future. The debate rolls on...
Bye for now.
Paul.

Java is a terrific web-language. It is the best language for the most important part of a web-application: the back-end. There is no alternative for Java if you want your web-applications to scale properly.
Werner.

Java is a terrific web-language. It is the best language for the most important part of a web-application: the back-end. There is no alternative for Java if you want your web-applications to scale properly.

Java is a terrific web-language. It is the best language for the most important part of a web-application: the back-end. There is no alternative for Java if you want your web-applications to scale properly.

Werner.

QFT

J2EE has unarguable proven itself in a lot of scenarios, but I refuse to accept the view that Java is the best language for the most important part of a web-application: the back-end.
The backend could be the database server,messaging server,
an ESB,a BPM server or even an order processing system.J2EE has not been known to be the best platform for these kind of systems.
While with well architected application servers like Weblogic, J2EE back systems can scale admirably,Java is not suited for doing web apps.
Java/J2EE is not the best tool for doing web apps and that for one and many reasons.
The class of web apps defining the face of things to come attests to that, Facebook,WordPress,Drupal,Joomla for instance and the other host of collaboration-based web applications are not definitely written in Java(not to talk of having a Java "back-end").
The trend is towards Web 2.0 architectures and J2EE as we know it is not poised as a viable platform in that regards.
The technology stack alone is prohibitive, the mountain of specs one has climb to get the simplest thing done is not an incentive either.If you are someone who gets paid for handling complex stuff on J2EE projects, you'll probably not agree.
Also today's web apps are not necessarily "complex" and do not require "complex solutions" as bandied around by diehard J2EE zealots.Messaging using Plain Old Xml(POX),XML-RPC,REST services suffice for a lot of applications and can be implemented better and faster in languages like PHP without any of the bureaucratic claptrap associated with JEE.
The rules of the game are simplicity and productivity in a loosely connected environment, and Java is obviously not playing well in that field.

but I accept the view that Java is the best language for the most important part of a any serious application: the back-end.

Fixed it for you.

Please enlighten me what language can compete in real development with Java? And by real I mean back-end development.

Your question looks like a flame bait, so I'll try and be objective as possible.
Obviously the real challenge for working systems has been inter-operability.So if you are talking about the best language for developing back-end systems, I should ask- on all platforms or which specific platform?
Also which specific market are you targeting?SMEs? Multinational companies or mum-and-dad shops?As you might have guessed, it depends.
For a shop running *nix,J2EE should be a viable choice for developing serious backend systems with complex requirements
that cannot be met by PHP or a well designed Perl app or even a plain old TCP/IP sockets-based RPC service.
For those on Windows,J2EE is definitely a no-no.I will not describe the offerings on this platform like SharePoint,BizTalk,PerformancePoint,ASP.Net not to digress from the topic.
On the interoperability side,numerous choices abound for implementing the popular technologies like SOA,ESB and the like.So it is up to the architect to choose the right price/performance offering.
So all in all, J2EE cannot be presented as the best for backend systems.Since I'm primarily deploying .Net apps now after having tried my hands at various J2EE projects and got
burnt in the process,I should comment from my experience that .Net competes more than favourably well and even performs far better on many points than technologies available on the J2EE stack.
Cheers,
Ozzy

For those on Windows,J2EE is definitely a no-no.I will not describe the offerings on this platform like SharePoint,BizTalk,PerformancePoint,ASP.Net not to digress from the topic.

J2EE a no-no for Windows? This is simply not true.Regards,--Andrés

The statements are ofcourse my personal opinion and do not represent any official line.BTW, from market statistics and research polls, J2EE still has a viable market and a large developer community on Windows.This view is balanced by the counter that a lot of companies have been steadily migrating from J2EE to .Net as market statistics and research polls also
reveal.
Sorry if I distorted someone's company's official marketing line.
Cheers,
Ozzy

For those on Windows,J2EE is definitely a no-no.I will not describe the offerings on this platform like SharePoint,BizTalk,PerformancePoint,ASP.Net not to digress from the topic.

J2EE a no-no for Windows? This is simply not true.Regards,--Andrés

The statements are ofcourse my personal opinion and do not represent any official line.BTW, from market statistics and research polls, J2EE still has a viable market and a large developer community on Windows.This view is balanced by the counter that a lot of companies have been steadily migrating from J2EE to .Net as market statistics and research polls alsoreveal.Sorry if I distorted someone's company's official marketing line.

Cheers,Ozzy

This is not true and could you please provide some objective references to market research that showed these results?
If you can not provide objective relevant references, then your post is not your personal opinion but rather propaganda, mildly speaking.
I have been back-end Java dev for last 4 years, and in 90% of cases applications have been deployed on windows OS, simply because client has already invested in MSFT, and since Java can run on almost any OS, and I havent seen CSS/JSP/Servlets for a long long time.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.