Skip to main content

[jsr342-experts] Re: Java EE 7 roadmap

  • From: Werner Keil <werner.keil@...>
  • To: jsr342-experts@...
  • Subject: [jsr342-experts] Re: Java EE 7 roadmap
  • Date: Fri, 31 Aug 2012 00:47:06 +0200

Antonio,

Thanks for your input, as to all the others before.
Sorry I mostly replied in the CDI thread, but a lot of it related to either CDI or other annotations.

If certain ways to "sharpen" how e.g. WARs can do things currently the domain of EAR can be done without breaking existing functionality and features that is a good suggestion, but honestly, it feels more PaaS friendly, so probably best to do some of these things right and carefully (without the rush that introduced e.g. some of the bugs, SE7 currently struggles with, though it has no real impact to EE in most cases;-)

Logging, I would personally prefer a real JSR for it if enough people like you feel the need and pain. There are a few JSRs, Money probably another good example, that cater to SE, but by their nature will have greater impact in the Enterprise world. 310 another example. Take BeanValidation, JSF or JDBC, you name it, they all use java.util.Date or Calendar.
Not all may be immediately changed to new types from these new JSRs, but some sure will benefit. If JDBC or JPA work more towards non Relational Databases, too, mapping or binding a Money type sure makes sense, too. With limitations it also does for RDBs.

I'd see some of those like JSR 330 which via CDI became more important to EE, than in most Desktop or Mobile use cases, too.
If you get a proper Logging JSR similar to what SLF4J does in many cases, then this certainly won't make it into EE7, I highly doubt, it makes sense in SE8 either, given without proper Modularity you can't throw out the old stuff, same goes for 310, too btw;-)
However I am very confident, some of those make great sense in EE8, especially with the PaaS focus, where an abstraction of logging ideally per tenant would come handy.

At my current client we also have to do that, with more than one container btw. Most of it by tweaking Log4J or other internally used loggers the right way. So if an abstraction that works similar in different containers existed, that would simplify not just how we provision our Private Cloud there.

Werner

Am 30.08.2012 21:43 schrieb "Linda DeMichiel" <linda.demichiel@...>:
Hi Antonio,

On 8/30/2012 11:39 AM, Antonio Goncalves wrote:
Hi all,

I feel happy about this news and disapointed at the same time. Many of us have expressed (at a very early stage) that
standardazing PaaS features in EE 7 was way too early. The JCP is full of "standardizing early" gotchas and we felt it
would be another one. So I'm happy that this is postponed (and to be honest, if it's not in EE 8 but in EE 9 it will not
hurt me). But I'm disapointed that we have spent so much energy in this topic and left some behind. A few months ago I
mentioned the pain that developers have with logging. Will we be able to solve it (like configuration, a single
container... and so on) ? It was clear to me that vendors where much more interested in standardising PaaS features
(where there's money to be made) rather than wasting time on defining a logging API (which is a day to day pain for
developers but doesn't have any business model behind).


Now that we can focus better on the non-cloud aspects, I hope that we can make better progress here.

As I said in my note, I'd like to see us getting going on at least some of these topics in advance of Java EE 8.

I hope we will take this into account, like we should have done with Entity CMP : standardizing too soon is a bad thing !

So let's keep the good work happening and, as you say Linda, focus on EE 7 to make it follow the path of EE 6 :
enhancements in simplification and usability.


thanks,

-Linda

See you soon on the mailing list

Antonio

On Thu, Aug 30, 2012 at 6:31 PM, Linda DeMichiel <linda.demichiel@... <mailto:linda.demichiel@oracle.com>> wrote:


    When we announced the Java EE 7 JSR back in early 2011, our plans were
    that we would release it by Q4 2012.  While this target date was three
    years after the release of Java EE 6 and certainly later than we would
    have liked, at the time it seemed like an aggressive schedule given
    the proposed scope of the release.  We have since adjusted this date
    once (to the spring of 2013) in order to accommodate the inclusion of
    additional JSRs of importance to the community (in particular, Web
    Sockets and JSON-P).

    As you know, our focus in the Java EE 7 release has been three-fold:
    to continue to invest in significant enhancements in simplification,
    usability, and functionality in updated versions of the JSRs that are
    currently part of the platform; to introduce new JSRs that reflect
    emerging needs in the community; and to add support for use in cloud
    environments.

    At this stage of the process, I think it is safe to say that
    maintaining the entirety of this agenda -- particularly the aspects
    related to PaaS enablement and multitenancy support -- puts our
    proposed dates at very significant risk.  We estimate that
    realistically we would not be ready with a release of Java EE 7
    until the spring of 2014.  In our opinion, that is way too long.

    After considerable soul-searching as to the causes of this delay --
    limited industry experience in the cloud area when we started this
    work, together with a lack of maturity in the space for provisioning,
    multi-tenancy, elasticity, and the deployment of applications in the
    cloud -- we are proposing that we defer to Java EE 8 the areas of PaaS
    enablement and multitenancy support.

    Of course, we continue to believe that Java EE is well-suited for use
    in the cloud, although such use might not be quite ready for full
    standardization.  Even today, without Java EE 7, vendors such as
    Oracle, Red Hat, IBM, and CloudBees have begun to offer the ability to
    run Java EE applications in the cloud.

    Postponing the remainder of the work on cloud support until Java EE 8
    will therefore also have the important advantage of enabling Java EE
    vendors to gain more experience with implementations in this area, and
    will thus help us avoid risks entailed by trying to standardize in an
    area that is arguably still some time away from being mature.

    It is important to note that the features that we have already added
    to Java EE 7 for cloud support -- such as resource definition
    metadata, improved security configuration, JPA schema generation --
    serve as enhancements to the Java EE 7 programming model in non-cloud
    environments as well.  The inclusion of these features in Java EE 7
    will help expedite a cloud-oriented release of Java EE 8 in the
    future.

    We plan to target this Java EE 8 release for the spring of 2015.  We
    expect to include new JSRs for application configuration, for
    JSON binding support, and others, which we hope to launch in advance
    of the completion of Java EE 7.

    This shift in the scope of Java EE 7 also allows us to better retain
    our focus on enhancements in simplification and usability and to
    deliver on schedule those features that have been most requested by
    developers.  These include the support for HTML 5 in the form of Web
    Sockets and JSON-P; the simplified JMS APIs; improved Managed Bean
    alignment, including transactional interceptors; the JAX-RS client
    API; support for method-level validation; a much more comprehensive
    _expression_ language; and more.

    To conclude, what we are proposing is to hold to the current dates for
    Java EE 7 (spring of next year); maintain the focus on all of the
    feature enhancements targeted at simplification and usability; retain
    the cloud-related features we have already defined; and defer the
    remaining portions of the cloud-oriented work to Java EE 8.

    We feel strongly that this is the right thing to do, in view of what
    we and our team have heard from members of the community.

    Please let us know if you have any major concerns with this proposed
    direction.

    thanks!

    -Linda




--
Antonio Goncalves
Software architect and Java Champion

Web site <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn
<http://www.linkedin.com/in/agoncal> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>


[jsr342-experts] Java EE 7 roadmap

Linda DeMichiel 08/30/2012

[jsr342-experts] Re: Java EE 7 roadmap

Pete Muir 08/30/2012

[jsr342-experts] Re: [javaee-spec users] Re: Java EE 7 roadmap

Linda DeMichiel 08/30/2012

[jsr342-experts] Re: Java EE 7 roadmap

Markus Eisele 08/30/2012

[jsr342-experts] Re: Java EE 7 roadmap

Linda DeMichiel 08/30/2012

[jsr342-experts] Re: Java EE 7 roadmap

Antonio Goncalves 08/30/2012

[jsr342-experts] Re: Java EE 7 roadmap

Linda DeMichiel 08/30/2012

[jsr342-experts] Re: Java EE 7 roadmap

Werner Keil 08/30/2012

[jsr342-experts] Re: Java EE 7 roadmap

Jevgeni Kabanov 08/30/2012

[jsr342-experts] Re: Java EE 7 roadmap

David Blevins 08/30/2012

[jsr342-experts] Re: Java EE 7 roadmap

Linda DeMichiel 08/30/2012

[jsr342-experts] Re: [javaee-spec users] Java EE 7 roadmap

Yoon Kyung Koo 08/30/2012

[jsr342-experts] Re: Java EE 7 roadmap

Jim Knutson 08/31/2012

[jsr342-experts] Re: Java EE 7 roadmap

Jevgeni Kabanov 08/31/2012
 
 
Close
loading
Please Confirm
Close