[javaee-spec users] [jsr342-experts] Re: Wish-List for EE 8

From: Werner Keil <>
Date: Fri, 19 Jul 2013 12:24:51 +0200


Thanks for summing this up on Dzone, too:

I won't comment on all, especially those that are discussed elsewhere or
may require further consensus by at least some large stakeholders...

   - No buzzwords

   Agree, that is among reasons why a JSR around another buzzword, "Social"
   was turned down, allowing it however, to be fostered along the lines of
   Drools, Hibernate or Arquillian (by the same vendor[?]) and I wouldn't
   outrule some of it spilling back into the JCP either in a dedicated JSR or
   via others (351 being just one example where this already started[?])

   - Security

   See above, given the requirements for progress (or
   "hibernation", while of cource some JSRs that didn't get Final are still
   more alive and kicking than others that were declared Final[?]) we'll see
   an EDR of Identity API any time soon, and there's going to be a
   presentation at JavaOne, too. These and a few other Spec Leads also got
   your message for help with Java EE 8 session content[?]
   - Enterprise services and stereotypes

   This sounds like a great idea, once the definition of such "Service"
   could be standardized and agreed on, too. Plus with EE 8 having to carry
   the burden of SE 8 (see below, things aren't getting so modular and
   reusable as it seems, on the contrary[?]) it may be too early before
   Jigsaw or something similar makes Java modular enough for that (followed by
   EE 9[?])

   - CDI, CDI, CDI

   I can't agree more, and for SE and at least its Embedded version, it
   looks like future CDI Specs should support it. Unfortunately, the Java SE
   ecosystem as a whole got worse with Java 8, especially when it comes to
   reusability and modularization. Your Fellow Java Champion Lars Vogel did a
   nice tutorial on Java Date/Time

   Of course, with Java 8 this one won't go away, and while java.util.Date
   is the only one you may call portable as it works all the way down to ME
   Embedded, you got
      - java.util.Date/Calendar

   - java.util.concurrent.TimeUnit (especially relevant for e.g. new Java
      EE Concurrency[?])
      - java.time (incompatible with all the others except a tiny bridge to
      - javafx.util.Duration used anywhere in JavaFX
      - JSR 302 with a HighResolutionTime and API around it, at least for
      Embedded systems or other Security Critical applications, if any of it
      becomes relevant to Java EE 8, at least the estimated schedule
of both JSRs
      means, it should be available before or around the time Java EE 8 is

      plus others like ICU4J or JodaTime where projects use them already
      and do not get rewritten just for the sake of refactoring...

      As long as Java keeps growing into a large, monolithic block with
      half a dozen redundant implementations of a (relatively) trivial
thing like
      "What's the time?" CDI alone won't help, even if some or all of
these would
      be CDI-enabled and work with @Inject.

      One of the main problems are "leftover" JSRs like 302, 310 (now
      java.time) or even 107 (JCache, you mentioned it) carrying a
legacy from a
      different time (Java EE was still at EJB 2 then or earlier[?]) and now
      half-heartedly squeezed into a Java ecosystem of the 21st Century
      that evolved around technologies like CDI.
   - Standard artifacts and repositories

   This (aside from Logging, but I leave that aside for now, too[?]) could
   be the most difficult of your wishes. The "IP WG" of JSR 358 currently
   cares not a bit about public APIs, given its official scope is only RI/TCK.
   And depending on the Spec Lead's discretion (see I was the only EC Member who
   identified the problem and the only one with enough technical experience to
   care unfortunately, all others discuss legal and other "buzzwords" mostly,
   and a similar JIRA issue you may remember from DevoXX we heard, this is unlikely to
   happen where people with a more technical approach could deal with such

   Thus you'll end up having some JSRs where the API is considered part of
   the RI, hence its package name may be "com.somecompany.someapi.*" while
   others are defined either via the respective Forge or Foundation (org.*)
   and a few call it "javax.*" or see 310 it gets sucked into OpenJDK and ends
   up "java.*" also quite often the case we see "org.glassfish.*" JSRs now.

   Based on above JIRA ticket 358-49 almost every Java EE 7 Spec Lead and
   JSR (only 352 reacted too slow or probably still waits for the lawyers to
   talk to each other?[?]) as well as a vast majority of those catering
   towards EE 8 follows minimum requirements for the Spec License, but a
   majority of them also considers the scope of the "Spec" to be just a plain
   text document and the JavaDoc of the public API. The API itself usually
   ends up being part of the RI, hence there is no consistent package naming
   and it's almost impossible we'll see a consistent Maven or related artifact
   naming either.

Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel
Language Champion | Java Godfather | Mærsk DevOps Build Manager
Twitter @wernerkeil | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps
Skype werner.keil | Google+
* Eclipse DemoCamps Kepler 2013: June-August 2013, Germany, Denmark, Austria,
Norway. Werner Keil, UOMo Lead, Mærsk DevOps Build Manager will
present "Triple-E’class
DevOps with Hudson, Maven, Kokki, Multiconf & PyDev", "M4M 2 the Rescue of
On Tue, Jul 16, 2013 at 10:32 AM, Antonio Goncalves <> wrote:
> I think that is two different topics.
> Back at Devoxx BE 2009, Java EE 6 was going to be released and there was
> already talks about "Java EE 7 and the Cloud". Being involved in Java EE
> and the JCP, plenty of people came to me saying "really, Java EE 7 and the
> Cloud ?". I felt I had nothing to say : no consultation between spec leads
> and expert members. If I go to a 1h BOF at JavaOne about Java EE 8, what
> would I say ? I don't know what the spec leads have in mind. I don't know
> what Java EE 8 will be. I would just seat in the room and listen.
> What I am proposing is : let's kickoff Java EE 8, at least, between spec
> leads and expert members (if "adoptajsr" adepts want to join, great), agree
> on a road map, and then, we can all go to BOFs, conferences, gatherings...
> and present what Java EE 8 will be. With Java EE 7 I would always started
> my presentations saying "Oracle wants Cloud in Java EE 7, but most of the
> expert members don't". That's not a very positive message and doesn't bring
> cohesion to the group.
> Antonio
> On Mon, Jul 15, 2013 at 6:03 PM, Markus Eisele <> wrote:
>> Hi Antonio,
>> As John D. A. pointed out on twitter it might not be the right way to do
>> this in a closed circle round. I would offer my insights and I would for
>> sure accept such an invitation from oracle but I must say that I would love
>> to see a more open (transparent) approach here.
>> Might be this could be an adopt-a-JSR effort or some kind of survey.
>> Cheers,
>> M
>> Am Montag, 15. Juli 2013 schrieb Antonio Goncalves :
>> Hi all,
>>> I was wondering if we could use JavaOne to brainstorm on Java EE 8. And
>>> I'm not just talking about a one hour BOF between some spec leads/expert
>>> members and developers, I am more thinking of a half day with only spec
>>> leads and expert members.
>>> To be honest, I felt very frustrated when Oracle announced "Java EE 7
>>> being Cloudish". Nobody asked what the expert members thought of such
>>> announcement, of what they had in their mind for the future of the plaform.
>>> What do you think of physically meeting before/during/after JavaOne and
>>> start shaping the future of the platform ?
>>> Antonio
>>> On Mon, Jul 15, 2013 at 5:48 AM, Markus Eisele <> wrote:
>>>> Hi all,
>>>> after the buzz around the EE 7 release is silencing a bit I just
>>>> wanted to take the opportunity to send around a link I came across
>>>> yesterday:
>>>> Arjan compiled a list of things he would love to see in EE 8. Good to
>>>> see some of it already on the list but also some new things like
>>>> spending some time to modernize the security frameworks.
>>>> Cheers,
>>>> - Markus
>>> --
>>> Antonio Goncalves
>>> Software architect and Java Champion
>>> Web site <> | Twitter<>|
>>> LinkedIn <> | Paris JUG<> |
>>> Devoxx France <>
> --
> Antonio Goncalves
> Software architect and Java Champion
> Web site <> | Twitter<>|
> LinkedIn <> | Paris JUG<> |
> Devoxx France <>

(image/gif attachment: 35C.gif)

(image/gif attachment: 35F.gif)

(image/gif attachment: 329.gif)

(image/gif attachment: 326.gif)

(image/gif attachment: 362.gif)

(image/gif attachment: 347.gif)