[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)

I don't think backward compatibility has stopped to be a concern for people. At least for me, BC is one of the key strengths of Java EE.

I've recently had to migrate some Java EE 5 applications from GlassFish 2 to WildFly 10 with no susprises and minimal changes (basically propietary deployment descriptors). Java EE image would be seriously damaged if sd break this promise.

Yet I agree we should experiment more and move faster, but there Microprofile comes to play, and even Java 9 incubator modules.

Wether we use the JCP or not, the same rules should be maintained IMO.


Regards,

Guillermo GonzÃlez de AgÃero

El lun., 9 de octubre de 2017 4:18, Steven Pousty <scitronp@xxxxxxxxxx> escribiÃ:
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