Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Eclipse is still behind the current state of Java EE 8

Hi,

Wildfly 12 was just released with some Java EE 8 support:
http://wildfly.org/news/2018/02/28/WildFly12-Final-Released/

Unfortunately at least JSR 375 is missing from that list.

@Mark or others is there a reason for that?

It seems there are a lot of things going on with the Keycloak/PicketLink merge.
One would expect unless Wildfly simply uses Soteria, that Keycloak: http://www.keycloak.org/ should provide a JSR 375 implementation like those by Oracle/JSR 375 EG or IBM in Liberty.

Are we likely to see that in Wildfly 12 or only the next release?

Werner


On Thu, Mar 1, 2018 at 3:06 PM, <ee4j-community-request@xxxxxxxxxxx> wrote:
Send ee4j-community mailing list submissions to
        ee4j-community@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        https://dev.eclipse.org/mailman/listinfo/ee4j-community
or, via email, send a message with subject or body 'help' to
        ee4j-community-request@eclipse.org

You can reach the person managing the list at
        ee4j-community-owner@eclipse.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."


Today's Topics:

   1. Re: Eclipse is still behind the current state of Java EE 8
      (Mrinal Kanti)


----------------------------------------------------------------------

Message: 1
Date: Thu, 1 Mar 2018 19:36:39 +0530
From: Mrinal Kanti <mrinal.kanti@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Eclipse is still behind the current
        state of Java EE 8
Message-ID:
        <CAAenm--0eZc0wBNJqyULaq-8VHxX8JrT9i1qxTuWXiRxGXtn_A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

A minor correction - Oracle's AppXray is not a profiling tool and is
intended for IDE support only. WebLogic provides various profiling and
performance tuning options.

On Thu, Mar 1, 2018 at 7:02 PM, Mrinal Kanti <mrinal.kanti@xxxxxxxxx> wrote:

> I think a more appropriate question at this point would be to ask which
> areas would be benefited most from the Java EE tooling support?
>
>
>
> Looking at https://www.eclipse.org/webtools/, I can think of a few areas
> and how the landscape has evolved over the last decade for some of them:
>
>
>
> *Server Tools*: These were primarily app server connectors which were
> responsible to call the appropriate startup/shutdown/restart or deploy
> hooks of their respective app servers from within the IDE. There is little
> room for improvement in that area so long as the tools are kept updated
> with the latest app server versions.
>
>
>
> *Server Profiling*: This is a very grey area. Eclipse used to have TPTP
> which was retired long back. However, IBM continued to provide a very
> similar functionality in their WAS profiling. Oracle have their own
> proprietary AppXRay and I think even JBoss had(?) its own profiler project
> based on JVMPI and JVMTI. Besides, the profiling landscape has changed a
> lot to catch up with the demands of the industry. The need has shifted from
> server profiling to application profiling as enterprises are finding
> themselves in heterogeneous environments. They are looking for specialized
> context aware profiling tools (such as APM tools for end-to-end transaction
> profiling) which are provided by third party vendors. The application
> profiling tools market is pretty competitive here and with the need to
> support profiling for cloud based deployments or in heterogeneous
> environments, I don?t think any vendor would be willing to wait for Eclipse
> tools to catch up and provide a base for them. Also with the evolution of
> Restful APIs and the cloud based service models many of the profiling
> capabilities are built into the API management tools themselves which
> require them for monitoring SLAs.
>
>
>
> *Web UI tooling*: There was a time when companies like Exadel,
> Genuitec(MyEclipse IDE), Instantiations(GWT designer) had a thriving market
> for the UI tools they provided on top of Eclipse. Those days are long past.
> The tooling support was needed because the UI components were being
> generated on the server for most of the web frameworks available during
> that time. And server-side programmers did not have the necessary skills or
> time to create attractive UI. Today, in order to facilitate lean
> multi-channel architectures, enterprises require building channel specific
> UI on top of their RESTful  services. Today we speak of rich-clients
> which are not just browser based but have to cater to mobile platforms as
> well. The current crop of UI libraries and frameworks do not require much
> IDE support to build rich UI on top of REST APIs. (Btw, if we are speaking
> about supporting the current crop of UI frameworks and libraries then it is
> worth mentioning that Jetbrains has a solid presence and a clear lead there
> which leaves little room for Eclipse to establish itself). Even on the
> server-side, thanks to annotation based approaches, we no longer require
> scaffolding code to publish or consume REST services, so not much need for
> IDE support there as well.
>
>
> *Database tooling*: JPA is widely used for relational databases and its
> support for NoSQL data is still not mature enough. So unless the
> specifications become mature and stable on that front, there is little to
> benefit from tooling, as the JPA implementations continue to provide their
> own approaches for NoSQL access. On the relational front, I think the
> current tooling capabilities are sufficient.
>
> *DevOps and the Invasion of scripting environments*: I remember those
> nostalgic days when WebLogic used to provide WLST. It made life simple for
> automating so many configuration management and deployment tasks. Today,
> DevOps have evolved into a discipline of its own and even developers are
> relying on console based tools for automating some their development tasks.
> The scripting extensions are far more easier to build and customize than
> building a set of Eclipse plugins to perform the same tasks.
>
> Summarily, we need to re-evaluate where the webtools projects are headed
> and how relevant are those tools in the current enterprise web-development
> landscape.
>
> My 2 cents.
>
> -Mrinal
>
>
>
> On Wed, Feb 28, 2018 at 7:22 PM, reza_rahman <reza_rahman@xxxxxxxxx>
> wrote:
>
>> We can definitely try to do that, identifying it as a clear gap area. One
>> issue of course is that the current Java EE Guardians community at least is
>> very NetBeans heavy. The same may or may not be true of the current broader
>> Java EE community as well.
>>
>> If it's not too stupid a question - besides IBM, who would the other
>> potential vendors be to stand behind Eclipse IDE Java EE support?
>>
>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>>
>> -------- Original message --------
>> From: Mark Little <mlittle@xxxxxxxxxx>
>> Date: 2/28/18 5:15 AM (GMT-05:00)
>> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
>> Subject: Re: [ee4j-community] Eclipse is still behind the current state
>> of Java EE 8
>>
>> I agree but unfortunately many non-Red Hat Eclipse IDE contributors have
>> dropped away. The community needs to step up and help or convince other
>> vendors to come back.
>>
>> Mark.
>>
>>
>> On 27 Feb 2018, at 13:55, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
>>
>> While I myself am an avid NetBeans user, I do agree excellent support in
>> the Eclipse IDE is extremely important for the success of Jakarata EE for
>> the reasons stated.
>>
>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>>
>> -------- Original message --------
>> From: Alexander Salvanos <salvanos@xxxxxx>
>> Date: 2/27/18 5:29 AM (GMT-05:00)
>> To: ee4j-community@xxxxxxxxxxx
>> Subject: Re: [ee4j-community] Eclipse is still behind the current state
>> of Java EE 8
>>
>> Hi Ryan,
>>
>> thank your for your reply. Well, in my project we use IntelliJ as the IDE
>> for the consulters.
>> Our client is using the Eclipse IDE though, since they are from the
>> public sector and cannot buy the expensive license.
>> NetBeans was not an option, because of several problems we were having
>> integrating our server.
>> However, the problem is that the Eclipse IDE is being used in the market
>> by far more then 70% of the Java EE developers.
>> This is a statistic that was automatically collected last year by the
>> Consulter-Agency GULP here in Germany.
>> And now that Java EE 8 is under the hood of the Eclipse Foundation, it
>> would be beneficial to have a good support of Java EE 8 in the Eclipse IDE.
>>
>> Kind Regards,
>> Alex
>>
>>
>> *Gesendet:* Dienstag, 27. Februar 2018 um 03:45 Uhr
>> *Von:* "Ryan Cuprak" <rcuprak@xxxxxxxxx>
>> *An:* "EE4J community discussions" <ee4j-community@xxxxxxxxxxx>
>> *Betreff:* Re: [ee4j-community] Eclipse is still behind the current
>> state of Java EE 8
>> Hi Alexander,
>>  Both Intellij (Ultimate) and NetBeans have excellent support for Java
>> EE. Eclipse is definitely way behind, its support for _javascript_
>> is absolutely abysmal as well. This has been the case fo many years now. I
>> would raise this issue with the Eclipse IDE and in the meantime recommend
>> checking out either NetBeans or IntelliJ Ultimate. When I give Java EE
>> training classes at work I always use NetBeans as it is free and includes
>> GlassFish (integrated).
>>
>>  Note, Oracle donated NetBeans to Apache, that donation looks to be going
>> pretty well.
>>
>>  Excluding Eclipse, the state of Java EE tooling is pretty good.
>>
>> -Ryan
>>
>>
>> On Feb 25, 2018, at 5:37 AM, Alexander Salvanos <salvanos@xxxxxx> wrote:
>>
>> Dear Colleagues,
>>
>> the current version of "Java EE for Developers" (with Eclipse Oxygen) is
>> still far behind the current state of Java EE 8.
>> This not only concerns the GlassFish tools, but also WTP.
>> Almost all technologies aren't referred updated.
>> E.g. When using JSF, still the deprecated "managed bean package" way is
>> offered.
>> When using project facets, alsmost all the technologies are been offered
>> in older versions.
>> We need to be vigorously and decidedly updating here, because not only
>> does this endanger the Eclipse IDE,
>> but also the Java EE 8 standard, since Eclipse is the most widely used
>> IDE for Java EE.
>>
>> Best Regards,
>> Alex
>>
>> Alexander Salvanos
>> Goebenstr.5
>> D-53113 Bonn
>> Telefon: +49 (151) 24296962
>> _______________________________________________
>> ee4j-community mailing list
>> ee4j-community@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/ee4j-community
>>
>> _______________________________________________ ee4j-community mailing
>> list ee4j-community@xxxxxxxxxxx To change your delivery options,
>> retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/ee4j-community
>> _______________________________________________
>> ee4j-community mailing list
>> ee4j-community@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/ee4j-community
>>
>>
>> ---
>> Mark Little
>> mlittle@xxxxxxxxxx
>>
>> JBoss, by Red Hat
>> Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale
>> Road, Co. Cork.
>> Registered in the Companies Registration Office, Parnell House, 14
>> Parnell Square, Dublin 1, Ireland, No.304873
>> Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
>> Keith Phelan, Matt Parson (USA)
>>
>>
>> _______________________________________________
>> ee4j-community mailing list
>> ee4j-community@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/ee4j-community
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20180301/086f4098/attachment.html>

------------------------------

_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community


End of ee4j-community Digest, Vol 7, Issue 4
********************************************


Back to the top