Oracle Certified Professional: Java SE 6 Programmer && Oracle Certified Expert: (JEE 6 Web Component Developer && JEE 6 EJB Developer)
Dieter Quickfend wrote:For instance, could JPA criteria be much faster and easier using Java 8?
Oracle Certified Professional: Java SE 6 Programmer && Oracle Certified Expert: (JEE 6 Web Component Developer && JEE 6 EJB Developer)
Dieter Quickfend wrote:by "faster", I mean performance.
Dieter Quickfend wrote:by "easier", I mean development speed.
Hauke Ingmar Schmidt wrote:
Dieter Quickfend wrote:by "faster", I mean performance.
That is a tautology. I guess you are thinking of execution speed of the Java part. And I agree with Claude Moore, that typically is not a bottleneck. Is it one for you? Is it a promise for Java 8 constructs in general to execute faster (even when not in an EE context)?
Dieter Quickfend wrote:by "easier", I mean development speed.
Those are not synonym IMHO. In fact more abstract constructs can be easier for experienced developers, and harder for inexperienced ones. They could make the development of the former faster, and of the latter slower.
And that is exactly what I expect of these new constructs. You need more knowledge and need to read more careful. Bad for mediocre developers. It may not be one of Java's shiniest properties but IMHO one of its strengths was that it wasn't overly complex on the language part and thus suited for not-so-die-hard developers (who are the majority, and who are doing something right, not to be misunderstood). I don't know if the new features really help the majority. And you need to know everything the language offers, you read more code than you write.
On the other hand a language needs to evolve with time and needs to appeal to decision makers to be relevant at all.
Oracle Certified Professional: Java SE 6 Programmer && Oracle Certified Expert: (JEE 6 Web Component Developer && JEE 6 EJB Developer)
Dieter Quickfend wrote:Java code is never a bottleneck? Really? It is when the only way of asynchronous communication before Java EE 6 was complex MDB behavior. I work with code bottlenecks every day, where you have to make the decision to sacrifice design fluidity for performance reasons.
Dieter Quickfend wrote:In the future, please mind the way you formulate your response. I think my original question was clear in its intent. Instead of answers, I get rhetorical questions and condescending semantics talk completely beside the point. It is difficult not to interpret your post as an insult.
If you wrote generic search methods that use lots of recursion/looping you might be able to refactor them into less lines of code. This applies to all methods in general though and has nothing to do with whether the code is written in EE classes or not. How fast the code will actually run will be determined more by your JPA implementation and database bottlenecks.Dieter Quickfend wrote:I am thinking of the evolvement of frameworks like JPA/Criteria API
Dieter Quickfend wrote:
EJB3.0 changes for managed threads / parallelism, etc.
Dieter Quickfend wrote:
When I think of things that might change with Java SE 8, I'm thinking of the implementation of parallelism and its feasibility in a managed environment, I'm thinking of default methods in EJB interfaces, I'm thinking of the Stream API that might radically change the Criteria API in the future...
t.
Dieter Quickfend wrote:We all hear a lot of what Java SE 8 will mean for the Java SE developers, but for all the EE developers under us, will anything change drastically? For instance, could JPA criteria be much faster and easier using Java 8? Will we be able to leverage parallelism in an EJB container's managed thread pool? Is anyone thinking along those lines at all?
Richard Warburton wrote:
As to the parallelism in a container's thread-pool the answer is a little complex. All of the parallel streams code backs onto the fork-join framework underneath, with a pluggable fork-join thread pool. An EJB container would be free to put its own thread pool in there and the default will actually be to disable parallelism.