Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] JCP or not (fork of Re: On Naming)

Profiles solve the "runtime", but not API compatibility. Payara is already aiming to provide a "legacy-free" runtime for Payara 5 [1] which I imagine will remove CORBA and JAX-RPC components. But compatibility at API level must be preserved for that approach to work.


Regards,

Guillermo González de Agüero

[1] http://blog.payara.fish/payara-server-5-alpha-1-release-is-here

El lun., 9 de octubre de 2017 9:36, Vitalij Zadneprovskij <vitalij_zad@xxxxxxxxx> escribió:

Hi everyone,

we could use profiles to solve this. We could create a legacy profile and a bleeding edge profile. What do you think about it?

Regards,

Vitalij Zadneprovskij


Il 09/10/2017 09:25, Rudy De Busscher ha scritto:
Steven,

I don't agree, backward compatibility is one of the major aspects of Java EE. And yes, there are different concerns today than 5 or 10 years ago.
But last year I did a migration for a customer from Java EE 5 to Java EE 7 (7 years old code, 550 000 LOC), and for them backward compatibility was very important. They wouldn't accept that the migration took several days!

So we need to be very careful with the backward compatibility.

regards
Rudy


On 9 October 2017 at 04:17, Steven Pousty <scitronp@xxxxxxxxxx> wrote:
I think we could actually break backwards compatibility moving forward. I don't say that lightly, as in "just burn it all to the ground", it's just there are different concerns for the community now then there were 5 years ago, let alone 10 years. 

One thing I would love to see now is more of a focus on lighterweight and composability - to make the server smaller (disk and memory) as well as Maven dependencies smaller. There is a good chunk of the the full spec that most developers don't need or care about.

On Sun, Oct 8, 2017 at 6:05 PM, Michael Nascimento <misterm@xxxxxxxxx> wrote:
Hi Emmanuel,

Nice interacting with you after such a long time ;-)

On Thu, Oct 5, 2017 at 12:09 PM, Emmanuel Bernard <ebernard@xxxxxxxxxx> wrote:
- when integrating one spec with another, it usually goes as fast as the slowest (could be improved within the JCP rules as it’s more organisational in nature)

True, however, if everything is Eclipse Foundation led under the same open source process, we should expect a faster pace now, right?
 
- there is a general black hole in lieu of feedback during the feedback phases

Feedback should be better in the age of Java EE guardians and the EE community.
 
- there are a bunch of non parallelizable steps (especially the feedback phases), this forces to do retroplanning and freeze work weeks before it becomes available

Yeah, this has been improved a little and could be further improved. Oracle wants to do 6 month releases of Java SE, so I'm sure we're naturally getting a shorter cycle.
 
- when Russian dolling specs, the retroplanning explodes quite a bit

You missed me in the Russian dolling part, have no clue what it means :-)
 
- there is no formal way for users to try WIP / newer specs, this leads to few to no feedback on it until the full Java EE is out.

That's where the community should help now.
 
- the “if you screw up it’s forever” strong backward compatibility guarantees also means we are thinking hard and long about things and go on the conservative side.

This part worries me here. That's what makes EE successful. Of course we could now have a concept of experimental APIs (even the JDK is doing that), but for the core platform, as much as it slow things down and the other downsides, that's our biggest selling point.
 
- updating the JCP process itself is a very long process

That part I'm aware (I'm part of SOUJava, in the EC for a while) 

BV 1.0 took I think between 1.5 to 2 years. That’s not what I would call a good pace :) Doing a 3 months increment on a spec would mean too little (work time) / (total time) ratio.

Assuming we're are keeping (a) EE is a standard that should have multiple implementations; (b) backwards compatibility is a must; (c) we want specs to be coherently adopted in the platform; I doubt we're getting better than 6 months, JCP or not. And if we're breaking one of those premises in EE4J, I'm *very* worried (and I'm sure some others here will be as well).

Regards,
Michael
 

I’m sure that’s not exhaustive and others might have a different view.

Emmanuel

On 3 Oct 2017, at 20:17, Michael Nascimento <misterm@xxxxxxxxx> wrote:

By that you mean BV 1.0 and CDI 1.0 suffered to go through the process? At least for BV, I remember once Red Hat took it over, it was completed in a good pace.

Regards,
Michael

On Tue, Oct 3, 2017 at 3:13 PM, Mark Little <mlittle@xxxxxxxxxx> wrote:
Revising an existing specification, as we have done with CDI and BV, is very different from doing something new.

On Tue, Oct 3, 2017 at 6:53 PM, Michael Nascimento <misterm@xxxxxxxxx> wrote:
On Sun, Oct 1, 2017 at 9:06 PM, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
  1. There is a strong desire for a lighter-weight, more nimble process.
Given Bean Validation and CDI seem to work just fine through the JCP, could someone from Red Hat comment on their perception about this point?
 
  1. The IP and process rules around the JCP are complex, and almost impossible to change. The intent will be to create a new process which provides a level playing field for all of the participants and stakeholders. A more open and egalitarian process will hopefully result in more participants and investment in the platform.

If the Eclipse Foundation is the one submitting the JSRs, wouldn't all IP from the specs belong to the Foundation? Wouldn't it be open and egalitarian?

Regards,
Michael

Virus-free. www.avg.com

_______________________________________________
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


_______________________________________________
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




_______________________________________________
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

Back to the top