• Post Reply Bookmark Topic Watch Topic
  • New Topic

Java SE 8 changes for EE development  RSS feed

 
Dieter Quickfend
Bartender
Posts: 543
4
Java Netbeans IDE Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Hauke Ingmar Schmidt
Rancher
Posts: 436
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dieter Quickfend wrote:For instance, could JPA criteria be much faster and easier using Java 8?


Just for clarification: By "faster" you mean purely development speed?
 
Dieter Quickfend
Bartender
Posts: 543
4
Java Netbeans IDE Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
by "faster", I mean performance. by "easier", I mean development speed.
 
Claude Moore
Ranch Hand
Posts: 862
8
IBM DB2 Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMHO real bottleneck lies in actual data access (select, insert and so on)...
 
Hauke Ingmar Schmidt
Rancher
Posts: 436
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Dieter Quickfend
Bartender
Posts: 543
4
Java Netbeans IDE Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


I guess you need some more explanation. I am thinking of the evolvement of frameworks like JPA/Criteria API, EJB3.0 changes for managed threads / parallelism, etc. 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.

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...

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.
 
Hauke Ingmar Schmidt
Rancher
Posts: 436
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


That's why I asked and agreed with Claude. In my experience the data access is the bottleneck, not the Java part.

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.


Sorry, "performance" and "easy" are not clear at al without contextl. That is why I asked. And I can't see how you could read "Just for clarification: By "faster" you mean purely development speed?" as an insult. It was a true and faithful question - especially with "faster and easier" I honestly thought that you can't think of execution speed at all but all be about development speed. Better be specific and exact in the first place next time.
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Generally, changes in the EE spec specific APIs are what you should be looking at for what the changes will mean in the EE world if any.


Specifically,

Dieter Quickfend wrote:I am thinking of the evolvement of frameworks like JPA/Criteria API
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:
EJB3.0 changes for managed threads / parallelism, etc.

If here you are talking about the Java 8 runtime rather than language features then that will not affect how you write your code. Parallelism will still be achieved by approaches defined in the EJB spec. Perhaps you are confusing syntax language features with runtime behavior of a VM started by a container? Language features affect how you write your code not how it runs on the VM.
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.

Again, implementation of parallelism has nothing to do with the EE developer. It is concerned only with EE container developers. Whatever they implement in whatever version (or in fact language) just needs to adhere to the relevant EE spec documents for the features they are producing. If the EE developer writes code in an EJB, its parallelism will be determined by the EE spec and the implementation of the container not on whether the developer used Java 8 features or not.

 
Jaikiran Pai
Sheriff
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think Dieter is referring to the runtime parallelism that can be achieved by Java 8 streams and how that might be used within a EE application.
 
Richard Warburton
Author
Greenhorn
Posts: 22
7
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?


To my mind anyone who is a Java EE developer is also a Java SE developer because EE builds on SE. So even if there are no direct, immediate, benefits in the EE APIs you still get the benefits of improved core libraries and potentially improved third party libraries.

I don't think JPA could be made much better with lambdas directly, since even though the streams API has a series of operations which are SQL-Like they aren't being directly compiled into SQL code.

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. I know this may sound like the end of the world, but its not. You still get the benefit of cleaner code that streams bring without the parallelism. In some ways I think the parallelism idea has been oversold a bit - its more like the icing on the cake than the real motivation for me to use streams in my Java 8 code. I'm more worried about simpler, cleaner, more readable code.

Of course this isn't to say that future EE specifications can't benefits from lambda expressions, it'll just take time for these changes to come into play. Something which I personally would welcome is if it was easier to write asynchronous code. Servlets 3.0 allowed asynchronous servlets, but the API is a bit cumbersome to use and not that developer friendly. If you modelled the async side of things with events and callbacks then lambdas would be of huge benefit. That's the kind of area where I can see lambdas providing EE benefit in the long term.

Thanks for the question.
 
Jaikiran Pai
Sheriff
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


There was a discussion about this recently on the Wildfly (previously known as JBoss AS) dev list http://lists.jboss.org/pipermail/wildfly-dev/2014-May/002167.html
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!