Mats Henricson has written a PDF summarizing many current and upcoming technologies for server side Java programming. Covered areas include Annotations, Dependency Injection, Hibernate, EJB 3.0 Entity and Session beans, AOP, Mustang and Dolphin features, Web Service metadata, scripting languages and testing tools.

It's been written primarily for a presentation of sorts, and as such doesn't go into a lot of detail for each subject, except through slides. It's still an excellent summary of many of the technologies.

Which technologies would you cover? For example, it doesn't address the Java Message Service APIs, or the Java Content Repository. That said, it should be noted that it's easy to become entranced by newer APIs, which can create the impression that they're more popular than they are. Is their exclusion representative of what people anticipate enterprise programming in Java to be?

It's very much a tutorial / key points rather than an analysis of the "state of the art".

Still, 85 slides! And you're complaining that it's not detailed enough and he missed some topics?

Mats has done a great job.

as a committer of jmeter, I'd like to say thanks for mentioning us. we plan to post 2.1 release candidate soon.

peter

as a committer of jmeter, I'd like to say thanks for mentioning us. we plan to post 2.1 release candidate soon.peter

Hi Peter
    Can you tell me if there is any book on jmeter out yet ? also what new cool features you are planning for next release >

as a committer of jmeter, I'd like to say thanks for mentioning us. we plan to post 2.1 release candidate soon.peter

Hi Peter    Can you tell me if there is any book on jmeter out yet ? also what new cool features you are planning for next release >

there aren't any books, but we have been working on the documentation over the last few months. A couple of notable things coming in jmeter 2.1

1. ability to save components as PNG images like the listeners, config elements, and samplers
2. JMS sampler for topic and queue messages
3. a developer tutorial written by mike and I
4. 2 presentations for jmeter
5. minor clean up of existing documents
6. new set of icons http://people.apache.org/~woolfel/new_icons9.png
7. various bug fixes

my apologies for plugging jmeter. I don't mean to hijack the thread.

peter

What about comparision against Grinder?

What about comparision against Grinder?

I haven't used grinder, so I can't say. There are several mature stress testing applications out there for webapps, like TestMaker, Grinder, JMeter and commercial tools like mercury. Any of them will work for most cases.

peter

I'm a bit off on a limb in my slides about testing tools for Java, so if someone else wants to pick up that area and maintain a site devoted to listing them all and categorizing them, plus giving an opinion as to which are good and bad - be my guest!

I've heard about Grinder, once, but haven't tested it, which is why I didn't list it. Sorry if that miffed someone.

What about comparision against Grinder?

I haven't used Grinder either, but on the first look, it's rather similar to Test Maker - it need jython scripts and is prepared for complicated testing. JMeter looks simpler, I use it mainly for simple stress tests (but it has also scripting capabilities afair)

...I don't mean to hijack the thread.peter

Yes you did.

I would have rather called it "What's en vogue", but that's more a matter of taste.

Since the major question for each new technology still remains:

"How much of what the abstraction abstracts from do I still need to understand to do the programming."

Examples for rather good abstractions (IMH): Servlet Container, Proxy AOP for simple things (logging, auditing), Simple declarative annotations, simple ORM, "Injection" of critical factories

Example for rather weak abstractions: EJB Containers, complex AOP, multilayered annotations, "complex" ORM (mapping function calls), most transaction handling, Injection of everything

The presentation gives a nice example, where it claims that with dependency injection "the programmer need not care if it is a singleton". Well yeah, sure, as long as you do not call a mutator or any method that says "synchronized"....

"Examples for rather good abstractions (IMH): Servlet Container.... Example for rather weak abstractions: EJB Containers....

OK...other than the seemingly requisite bashing of anything EJB these days, would you care to go into more detail as to why a servlet container is a "good" abstraction and an EJB container a "weak" one?

IMO, both types of containers host objects that run within an environment that provides services to them. Both require (at least EJB does prior to 3.0) that those objects extend certain "framework" interfaces in order for the container to provide those services. In the case of a servlet container they are network, rendering and presentation services; in the case of an EJB container they're network, transaction and persistence-related services (among others). While the types of provided services differ, both are "service-providing environments."

"Examples for rather good abstractions (IMH): Servlet Container.... Example for rather weak abstractions: EJB Containers....

OK...other than the seemingly requisite bashing of anything EJB these days, would you care to go into more detail as to why a servlet container is a "good" abstraction and an EJB container a "weak" one?

All too happy. With an EJB container, you need to be aware of a lot of things going in inside your container and your deevlopment envirinment that directly affect design and planning. A lot of are related to the fact that EJBs can be used from actual remote clients. So of my favorites:

- EJBs used to call other EJBs within the same app server.
- Behavior for multithreaded clients.
- You usually need precise understanding of how the security context works and how it is implemented, rather than just "log yourself in",
- You were and are often restricted in using basic inheritance because tools of the application vendor/ide do not support interface and inherited methods.
- Simple tasks, like using EJBs from one vendor from a remote container of another vendor put you in bizarre situation.

I would have rather called it "What's en vogue", but that's more a matter of taste.

Well, since the concepts popularized by Spring are making their way into the EJB standard AND the likes of Oracle and BEA are clearly supporting not only the DI concept but Spring itself, at what point will the transition from "vogue" to accepted standard be achieved?

After all, Struts was never a "standard", but attained a status that surpassed standards such as EJB.

I would have rather called it "What's en vogue", but that's more a matter of taste.

Well, since the concepts popularized by Spring are making their way into the EJB standard AND the likes of Oracle and BEA are clearly supporting not only the DI concept but Spring itself, at what point will the transition from "vogue" to accepted standard be achieved?After all, Struts was never a "standard", but attained a status that surpassed standards such as EJB.

Ha, well said! And given that everyone poured over struts when by 1999 it should have been pretty much obvious that any decent web framework should support things like back button protection, auto redirection, once and only once submittals and so on always remained quite a mystery for me. Actually, I would aggree that technologies like dependency injection are becoming more and more mainstream now... I even hear from pretty basic mainstream customers lost in debugging hell because of their overly optimistic use of AOP-Proxies and dependency injection ("Where the heck does that come from???"). As with all spices, it's all in the mix :-)

I would have rather called it "What's en vogue", but that's more a matter of taste.

Well, since the concepts popularized by Spring are making their way into the EJB standard AND the likes of Oracle and BEA are clearly supporting not only the DI concept but Spring itself, at what point will the transition from "vogue" to accepted standard be achieved?After all, Struts was never a "standard", but attained a status that surpassed standards such as EJB.

Ha, well said! And given that everyone poured over struts when by 1999 it should have been pretty much obvious that any decent web framework should support things like back button protection, auto redirection, once and only once submittals and so on always remained quite a mystery for me. Actually, I would aggree that technologies like dependency injection are becoming more and more mainstream now... I even hear from pretty basic mainstream customers lost in debugging hell because of their overly optimistic use of AOP-Proxies and dependency injection ("Where the heck does that come from???"). As with all spices, it's all in the mix :-)

Well, as we al know, any technology can be misused. However, I think that Struts did have a means to handled one and only once submissions.

However, I can solve the Struts success mistery for you. Struts made writing web apps easier. It did this by handling most items well. Because of this, many used it and many sought it. This positive feedback loop propelled it into wide acceptance.

Spring, like Struts, does the same thing without the claim of perfection that your hindsight suggests.

Well I would not subscribe to "easier". But I would agree it made writing web apps more predicatable and allowed easier knowledge transfer. On top of that (and this _is_ important) it was free. At the same time a lot of the actual problems for creating webapps were solved by various commercial packages like WebObjects to name but one. But most came with bizarre price tags and some promise of business intelligence (whenever was business intelligent).

Well I would not subscribe to "easier". But I would agree it made writing web apps more predicatable and allowed easier knowledge transfer. On top of that (and this _is_ important) it was free. At the same time a lot of the actual problems for creating webapps were solved by various commercial packages like WebObjects to name but one. But most came with bizarre price tags and some promise of business intelligence (whenever was business intelligent).

Well, I would. I don't know any developers or any people would would use something that made their lives harder.

Even for free.

Struts made form processing easier, request processing easier, made it easier to make the implementation more architecturally sound, no matter how you slice. Struts was not perfect and didn't solve every problem for everybody, but solved most for most.


There were tons of web frameworks, even free ones. Struts did it better. As opposed to say entity beans which did persistence worse.

Well, I would. I don't know any developers or any people would would use something that made their lives harder.Even for free.

David read carefully: Making your live easier is *not* the same than making *development* easier :-).

Your definition of easier is a bit weird, as this infers that web development using Struts and Servlets was hard in the first place. I do not think the choice here was "easier" vs "harder", maybe "faster" vs "slower", maybe quick learning curve etc. I give you all that. Struts had its place but by 2001 it was pretty much clear, we need something like JSF or Tapestry to even keep up with .NET.

A prime reason for using Struts was that it made people's *lives* easier (not a bad thing for sure), because (a) it was free and (b) it implemented one of Sun infamous "J2EE patterns", called Model 2 or whatever, so it was "sellable" to your boss and management.

It is my opinion that Struts made development easier.

Just because X is harder than Y doesn't mean that X is hard. It means that it is harder than Y. By the same token, saying Y is easier than X doesn't mean X is hard. Just that Y is easier.

I think that your cause and effect are skewed. My contention is that Struts made web developement easier. Because of this, word got around and more people used it. Because of this, it got popular emerging as the de facto standard we all enjoy.

This is not saying that Struts is the pinnacle of web develepment technology.

In my experience, telling customers and management that we should use something because it implements a pattern(and MVC preceeded J2EE by several years) was a surefire way to puzzled looks and the door leaving your boss office.

When I started my current job, they still were using an in-house web-frame that I moved us off of. That "quick learning curve, etc..." that you dismiss is one of the things that made Struts both easier and faster.

From what I read on the site, Luntbuild seems te be a good continuous build tool.

I should include PicoContainer for IoC. Spring is the EJB of IoC world, too much XML.

FYI, virtually everything in Spring is completely agnostic about the actual configuration format. The entire AOP framework, transaction abstraction, data access support, etc is based on plain Java APIs. Even the core container itself can be used either with plain Java APIs or with higher-level configuration formats built on top of them.

As an illustration, the entire XML bean definition format is handled in 1 (!) single class in the entire core Spring distribution: DefaultXmlBeanDefinitionParser. Same goes for Spring's less well-known properties-based bean definition format. The actual runtime handling of bean definitions resides in the format-agnostic DefaultListableBeanFactory.

Spring's core container actually offers a dedicated configuration API, with a straightforward way to programmatically register BeanDefinition objects. All externalized bean definition formats are implemented in BeanDefinitionReaders on top of that API. This is directly analogous to PicoContainer plus NanoContainer on top of it.

That said, we do believe in the value of externalized configuration. Often, the very point of using an overall application framework is to externalize the overall application configuration through a unified and consistent mechanism. Such externalized configuration offers a high degree of flexibility beyond hard-coded Java bootstrap code.

Juergen

As an illustration, the entire XML bean definition format is handled in 1 (!) single class in the entire core Spring distribution: DefaultXmlBeanDefinitionParser.

I would hope that this would inject itself into itself :-)

Such externalized configuration offers a high degree of flexibility beyond hard-coded Java bootstrap code.Juergen

I don't really believe in that because I never ever ones have experienced a real live example where I only had to change something in the xml on a running production server. For any other scenario I don't see the need for XML configuration because it is terrible to maintain. Yeah sure some tools rename class files in non-java files , but to they rename properties? No they don't. Eventually you end up with a big headache wondering where everything is coming from.

Such externalized configuration offers a high degree of flexibility beyond hard-coded Java bootstrap code.Juergen

I don't really believe in that because I never ever ones have experienced a real live example where I only had to change something in the xml on a running production server. For any other scenario I don't see the need for XML configuration because it is terrible to maintain. Yeah sure some tools rename class files in non-java files , but to they rename properties? No they don't. Eventually you end up with a big headache wondering where everything is coming from.

Well, see here is the rub. The software developement world is so big, that it is easy to say that one has never had to do something. I've been doing java for years and I've never done Swing. So does that invalidate Swing? Not only have I had to make changes on production systems(and I'm sure I'm not alone), but tend to use the same set of configuration files for different projects and I'm moving toward having resuable modules where I can just change the configurtation files.

I've been using Spring since 6/04 on 4 projects now and I can say that it ISN'T hard to maintain provided you put a trivial bit of thought into your config files. The XML simply isn't terrible to maintain. It's easy.

It seems to me Java got too much into competition with .NET languages feature and lost it's elegance, simplicity and beauty. Aspects,Attributes, Autoboxing... adding 100 of hardly used features every year to a language just becuase it is part of some other language is is not a good thing in my personal opinion.

But the problem is that now a days every one is a language guru, specially on the serverside.com:-) since when adding every esoteric feature in a language beocmes norm. The last time I checked almost all real expert agrees it is not good

Variable Arg: Why we need it? I bet 90% of the folks on this forum hardly ever debuged a variable arg method and know the pain but they must be itching to use this feature:-) Ok if 1% of the programmer really need to use it let them use C/C++. What happened to low coupling high coheshion. Isn't that why we felt the need for method overlaoding. It is bad, remeber that is why we devaiated from C.

It seems to me Java got too much into competition with .NET languages feature and lost it's elegance, simplicity and beauty. Aspects,Attributes, Autoboxing... adding 100 of hardly used features every year to a language just becuase it is part of some other language is is not a good thing in my personal opinion.

Well said. But maybe folks figured it is bad for job security, if code is elegant, nice and simple. After all, you could all to fast be replaced by a bunch of Elbonian programming servants. So features were invented to take us back to the days of unreadable, undebuggable (yet on its own right elegant) code. And the really cool catch is the claim, that these tools are so much needed to enable the Elbonians to code in the first place...

It seems to me Java got too much into competition with .NET languages feature and lost it's elegance, simplicity and beauty. Aspects,Attributes, Autoboxing... adding 100 of hardly used features every year to a language just becuase it is part of some other language is is not a good thing in my personal opinion. But the problem is that now a days every one is a language guru, specially on the serverside.com:-) since when adding every esoteric feature in a language beocmes norm. The last time I checked almost all real expert agrees it is not goodVariable Arg: Why we need it? I bet 90% of the folks on this forum hardly ever debuged a variable arg method and know the pain but they must be itching to use this feature:-) Ok if 1% of the programmer really need to use it let them use C/C++. What happened to low coupling high coheshion. Isn't that why we felt the need for method overlaoding. It is bad, remeber that is why we devaiated from C.

I would hardly call Aspects, Annotations, Autoboxing esoteric or hardly used. I think such features do the exact opposite of what you suggest - they make previously ugly and messy Java code elegant and simple. Let me give an example. Here is some code in Java 1.4:

Double result = new Double(((Double) collection.get(index)).doubleValue() * 1.25);

Here is the same code in Java 1.5 using autoboxing:

Double result = collection.get(index) * 1.25;

I know which of these I would consider elegant and simple (the second).

As for varargs, this may be needed rarely, but when it is needed, it is really needed. The alternative is a lot of very ugly code.

We moved away from C because it made too much explicit - memory management, pointers etc. New features such as Aspects, Attributes, Autoboxing etc. are required because plain old Java makes too much explicit - it can lead to code full of type casts, exception handling statements, transaction code etc. that is a distraction from the basic logic.

Double result = new Double(((Double) collection.get(index)).doubleValue() * 1.25);

Here is the same code in Java 1.5 using autoboxing:

Double result = collection.get(index) * 1.25;

I know which of these I would consider elegant and simple (the second).

Short is not the same than "elegant" or "simple". I moved away from C++ because it made it all too easy too mess things up. Given clever classing and libraries and use of macros, it was about as "explicit" as Java in the actual code.

Now we are introducing a lot of things into Java that will it make very easy for the average developer to "mess things up" yet again (and that are extremely ugly in their own right: Think annotation syntax, yuck!).

Double result = new Double(((Double) collection.get(index)).doubleValue() * 1.25);Here is the same code in Java 1.5 using autoboxing:Double result = collection.get(index) * 1.25;I know which of these I would consider elegant and simple (the second).

Short is not the same than "elegant" or "simple".

Given the option of short clear code, or code filled with repeated code and casts that obscure the logic, shorter certainly is elegant and simple.

Now we are introducing a lot of things into Java that will it make very easy for the average developer to "mess things up" yet again (and that are extremely ugly in their own right: Think annotation syntax, yuck!).

I completely disagree. The alternative is a high volume of uncessarily repeated code. It is far easier to mess things up, and far more difficult to debug things, if the logic for something like transactions is spread all over the place rather than in one place in, for example, an aspect. A developer will mess things up less if they can concentrate on simply writing logic, and not having deal with all sorts of other concerns (persistence, logging, exceptions etc.) at the same time.

A simpler programming language does not necessarily mean that the language is more elegant, or that it helps to produce simple and elegant code. We could make Java really simple by removing interfaces and classes and exception handling etc.

I completely disagree. The alternative is a high volume of uncessarily repeated code. It is far easier to mess things up, and far more difficult to debug things, if the logic for something like transactions is spread all over the place rather than in one place in, for example, an aspect.

Ah, well that is a bold statement. Given aspects it is actually quite easy to mess things up, since essentially the "business coder" must know which aspects will eventually will act on his code, if the code does do something more meaningful than merely logging. Just the same, the acpect applier must exactly know how the actual code behaves (whitebox knowledge required). This is commonly known as a "broken abstraction". So essentially the "business coder" will more often than not turn out to be the "aspect applier" and actually "aspect developer".

Transactions are one of the more interesting examples, since I must know how transactions span over my code stack, in order not to code something wrong or dangerous.

And if anything has to be done that deviates slightly from the default, it is a *very* good idea to make it as explicit as possible! Thus declaring non-default transaction behaviour in code (annotations or library calls) or in dedicated configuration files is much better practice than doing that in huge XML configuration or hiding them in Aspect Code.

A developer will mess things up less if they can concentrate on simply writing logic, and not having deal with all sorts of other concerns (persistence, logging, exceptions etc.) at the same time.

Unfortunately, a developer is also very likely to mess things up even more, if he has wrong assumptions about how the code he writes behaves.

I completely disagree. The alternative is a high volume of uncessarily repeated code. It is far easier to mess things up, and far more difficult to debug things, if the logic for something like transactions is spread all over the place rather than in one place in, for example, an aspect.

Ah, well that is a bold statement. Given aspects it is actually quite easy to mess things up, since essentially the "business coder" must know which aspects will eventually will act on his code, if the code does do something more meaningful than merely logging.

I would suggest that if the business user has to know which aspects will act on his/her code, then things have been designed wrong. The idea is to separate concerns.

Transactions are one of the more interesting examples, since I must know how transactions span over my code stack, in order not to code something wrong or dangerous.

That does not mean that verbose code dealing with transactions has to be placed in each method.

And if anything has to be done that deviates slightly from the default, it is a *very* good idea to make it as explicit as possible!

You are making it explicit if you define this using annotations. You are making it far clearer with a meaningful annotation than with many lines of Java code.

Thus declaring non-default transaction behaviour in code (annotations or library calls) or in dedicated configuration files is much better practice than doing that in huge XML configuration or hiding them in Aspect Code.

Sorry, but this sounds confused to me. Annotations can be used with Aspects - they aren't replacements for them. They can define which aspects are applied. Also, things are far more hidden in proprietary dedicated configuration files than in XML, where the markup is clearly defined, searchable and transformable.

A developer will mess things up less if they can concentrate on simply writing logic, and not having deal with all sorts of other concerns (persistence, logging, exceptions etc.) at the same time.

Unfortunately, a developer is also very likely to mess things up even more, if he has wrong assumptions about how the code he writes behaves.

Exactly, but with features such as aspects the assumptions are coded in just one place, and so are easier to change. This is far better than having the assumptions explicitly expressed as repeated Java statements in numerous methods.

Sorry, but this sounds confused to me. Annotations can be used with Aspects - they aren't replacements for them. They can define which aspects are applied. Also, things are far more hidden in proprietary dedicated configuration files than in XML, where the markup is clearly defined, searchable and transformable.

If it is in the source, even using an annotation, it is not AOP any more (at least to me) because the concern is not really separated. Instead it is right there in your source, like say:

@transaction(isolationLevel="optimistic", type="XA")

Of course one could understand the transaction as a semantical hint and it is up to whatever framework to act correctly upon that hint. So that might be developed using AOP or using simply proxys.

Exactly, but with features such as aspects the assumptions are coded in just one place.

The same statement holds true for functions. What you probabaly mean to say is that their *application* is defined in just one place. This is, quite simply, not true. They are defined *elsewhere*. The can be defined repeatedly or scattered (take the example of hinting to AOP frameworks using various technologies like XML Descriptors, explicit coding and annotation all at the same time).

If it is in the source, even using an annotation, it is not AOP any more (at least to me)

The only response I can give to this statement is that, as I understand things, it certainly is still considered AOP by almost everyone else.

because the concern is not really separated. Instead it is right there in your source, like say:@transaction(isolationLevel="optimistic", type="XA")Of course one could understand the transaction as a semantical hint and it is up to whatever framework to act correctly upon that hint.

Exactly. It is a hint, and that hint can be in XML or defined in some specialised language extension (AspectJ) or as annotations. The concern can be considered separated because you aren't having to include any code related to that concern in the business logic.

I do understand your point of view. I prefer some aspects (such as logging) to be entirely separated from the Java source file, as these aspects really have nothing at all to do with the logic and can be easily turned on and off independently.

So that might be developed using AOP or using simply proxys.

Some would say that if you use a proxy to do things you are, effectively, using AOP but only on a single instance of a class, and there is little advantage in doing this as against using an AOP framework where you can define code that can be generally used. Indeed, some frameworks provide AOP by automatically generating proxys for you - why bother to do this yourself?

Exactly, but with features such as aspects the assumptions are coded in just one place.

The same statement holds true for functions. What you probabaly mean to say is that their *application* is defined in just one place. This is, quite simply, not true. They are defined *elsewhere*. The can be defined repeatedly or scattered (take the example of hinting to AOP frameworks using various technologies like XML Descriptors, explicit coding and annotation all at the same time).
No - this is not what I meant to say. What I meant was that the logic of the aspect - its implementation - is defined in one place. Definitions of where the aspect is actually applied may certainly scattered, but that does not matter. When you need to change what an aspect does, or debug it, you are only looking in one place, in direct contrast to what you would have to do with explicit code scattered throughout an application. Of course, if you use features of certain frameworks, the application of the aspect can be defined in one place right along with the logic of the aspect; there is no scattering at all.

You are right that this is like functions, but it can do powerful things that functions can't do, such as handling exceptions for code. It can do things transparently when the appropriate hint or method signature is encountered. The use of functions is not transparent. I like this transparency. I don't see why my code to calculate tax should have to include any Java statements dealing with logging or transactions.

I don't see why my code to calculate tax should have to include any Java statements dealing with logging or transactions.

Agree on most of statements. Just a different point of view :-). The above statement has a very simple answer, of course: Because the developer of the aspect does not have the slightest idea what you need to log (let alone audit) in your code, as this is a business requirement :-).

Aspects can of course be wonderful for invocation tracing and logging API input. There is still a slight catch of course: Your logged output may still never reach your code, because another aspect intercepts the invocation. This is a bit of a problem, since in some (most the last time I looked but that is some time ago) programming systems aspects are not first class citizens (no aspects on aspects).

I don't see why my code to calculate tax should have to include any Java statements dealing with logging or transactions.

Agree on most of statements. Just a different point of view :-).

Agreed.

The above statement has a very simple answer, of course: Because the developer of the aspect does not have the slightest idea what you need to log (let alone audit) in your code, as this is a business requirement :-).

I would say the same applies to things like transactions. The developer (or provider) of transaction handling should have no idea about what code needs to be within a transaction. Also, the person who writes the tax calculation should not have to know or care if that calculation is within a transaction.

This is a bit of a problem, since in some (most the last time I looked but that is some time ago) programming systems aspects are not first class citizens (no aspects on aspects).

This works with AspectJ and, I would imagine, with all modern AOP systems for Java.

I would hardly call Aspects, Annotations, Autoboxing esoteric or hardly used. I think such features do the exact opposite of what you suggest - they make previously ugly and messy Java code elegant and simple. Let me give an example. Here is some code in Java 1.4:Double result = new Double(((Double) collection.get(index)).doubleValue() * 1.25);Here is the same code in Java 1.5 using autoboxing:Double result = collection.get(index) * 1.25;I know which of these I would consider elegant and simple (the second).

Steve it's been long time ago, I have been out from the language war and write code for living:-) but correct me if I am wrong; isn't the code above can be very well written(even better becuase the type can be checked at compile time) by using Generics (in my list I never mentioned Generic as an esoteric feature).

isn't the code above can be very well written(even better becuase the type can be checked at compile time) by using Generics (in my list I never mentioned Generic as an esoteric feature).

It can't. You can't use generics to allow a Double to be converted to a double for math.

Generics and autoboxing work well together. Consider the statement

Double result = list.get(index) * 2.0;

Generics means that the list can be defined as a collection of type Double. This means that no cast is required and the Double retrieved can be automatically converted to 'double', multiplied, then converted back to Double. This gives clear and simple code that is easily read and understood. Java 1.5 is, in my opinion, a significant advance for writing clear business logic.

isn't the code above can be very well written(even better becuase the type can be checked at compile time) by using Generics (in my list I never mentioned Generic as an esoteric feature).

It can't. You can't use generics to allow a Double to be converted to a double for math.Generics and autoboxing work well together. Consider the statementDouble result = list.get(index) * 2.0

I don't know what are you talking about. The above statement only requires generic collection that binds to a double at compile time, no autoboxing is required.

Yes adding/removing a double to an object based collection can be benifited by Boxing/Unboxing, so you can avoid explicit casting.

isn't the code above can be very well written(even better becuase the type can be checked at compile time) by using Generics (in my list I never mentioned Generic as an esoteric feature).

It can't. You can't use generics to allow a Double to be converted to a double for math.Generics and autoboxing work well together. Consider the statementDouble result = list.get(index) * 2.0

I don't know what are you talking about. The above statement only requires generic collection that binds to a double at compile time, no autoboxing is required. Yes adding/removing a double to an object based collection can be benifited by Boxing/Unboxing, so you can avoid explicit casting.

I might be missing something, but "list.get(index) * 2.0" would require autoboxing to get a primitive from list. How can you "bind to a double" at compile time?

isn't the code above can be very well written(even better becuase the type can be checked at compile time) by using Generics (in my list I never mentioned Generic as an esoteric feature).

It can't. You can't use generics to allow a Double to be converted to a double for math.Generics and autoboxing work well together. Consider the statementDouble result = list.get(index) * 2.0

I don't know what are you talking about. The above statement only requires generic collection that binds to a double at compile time, no autoboxing is required. Yes adding/removing a double to an object based collection can be benifited by Boxing/Unboxing, so you can avoid explicit casting.

You can't bind a collection to a 'double', you can only bind to a 'Double'. Collections handle Object subclasses, not primitives. That Double needs to be unboxed to double to do the math, then boxed back to a Double.

What I don't understand, is why the various Script languages (SL) going to be integrated in Jave SE.

I definitely don't need 5-10-15 various SL in Java SE. Why just not add instructions in JVM to better support SL (that planned in JavaSE 7.0), add integration points, and STOP here.

We easily can download .jar with appropriate language, if some our software or tool need it.

Not get the point

There seems to be an awful lot of moaning on TSS. Any chance of intelligent analysis or critique?

There seems to be an awful lot of moaning on TSS. Any chance of intelligent analysis or critique?

You must be new here.

You must be new here.

LMAO ;)

There seems to be an awful lot of moaning on TSS. Any chance of intelligent analysis or critique?

Things really used to be a lot better. Maybe they can turn around :-)

TSS has gone a bit like my inbox (with spam). I used to learn a lot on TSS. Now I have to filter out a huge amount of noise.

Rgds
Rod

Well, I am happy some trolls just left the forum, they were major source of noise. I think it got down to a much more acceptable level now, and should remain so until they come back.

BTW, why haven't anyone commented on this (OnJava's Spring versus EJB3) yet? IMO the arcticle is biased towards EJB, some people regarded that to author's being a JBoss employer.

Regards,
Henrique Steckelberg

Well, I am happy some trolls just left the forum, they were major source of noise. I think it got down to a much more acceptable level now, and should remain so until they come back.BTW, why haven't anyone commented on this (OnJava's Spring versus EJB3) yet? IMO the arcticle is biased towards EJB, some people regarded that to author's being a JBoss employer.Regards,Henrique Steckelberg

I read that article. Shrug. He calls Spring non-standard and claims that "Spring applications are locked into both Spring itself and the specific services you choose to integrate in Spring". Sure.

But yet, he has no problem with recommending JBoss's incomplete, Beta EJB3 spec. That's objective alright.

Well, I am happy some trolls just left the forum, they were major source of noise. I think it got down to a much more acceptable level now, and should remain so until they come back.BTW, why haven't anyone commented on this (OnJava's Spring versus EJB3) yet? IMO the arcticle is biased towards EJB, some people regarded that to author's being a JBoss employer.Regards,Henrique Steckelberg

I read that article. Shrug. He calls Spring non-standard and claims that "Spring applications are locked into both Spring itself and the specific services you choose to integrate in Spring". Sure. But yet, he has no problem with recommending JBoss's incomplete, Beta EJB3 spec. That's objective alright.

well, since one of his "advisors" is Bill "Jboss" Burke, what do you expect? Jboss has a vested interest in seeing Spring painted in a bad light.