Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] About Y-Builds (was Re: 4.35 Y-Build: Y20250111-1000 - BUILD FAILED)
  • From: JAYAPRAKASH ARTHANAREESWARAN <jarthana@xxxxxxxxxx>
  • Date: Mon, 20 Jan 2025 09:46:54 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=in.ibm.com; dmarc=pass action=none header.from=in.ibm.com; dkim=pass header.d=in.ibm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zAXj50ddOWeOF7S4gznYOMFYEvYk3ZRKT2IeCgheVJY=; b=apr48z9OMCozeFi+OPzEh9DamEYLpx9E0513H1VjIrFqTh6j9brH80KwjlRvott3pZjhqc8eIS6CroE7bkehkLCZVHjYugbSABQHErIC1Ann0I5xBm0qZDiqpQ0o2sH26IAXGb78Df2+HYYDJDk0nquqUMGUh+7FpLqfoIFbLLQ+ZvVDAmWr/77kHihjTV1kviZKewyRao0nAx2mYxxQcjwMjVryAlZIIJztZcfx+Ob4JnOYGnj/3w9/ZDn2OvpwL1qbEzzChzdoOZHGPF6TrAu7Yl7iTSLENNnwWTrnv6Qs2lO7TMGAZ++/DYozQS1qMviekwksA6PCr7mxmSh+Hg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=D8HqzmFd1moD0lihK1KxUby38+A8LMdEwy/g0kgZG83JIJFS6r+d7gzXZJR9PEtPrP3DqwBGEB/G6EDmX1PkwD/vWoJ14WhE6V4Kn6P/fdk3FRpBmOTn8/q/NDHHIx4zoCv1Rc82mGmK4mKgJcKq4avUF2vYqMW6w5n5uZLglXw32lnjkIktdqbV0cLzpC5MHX5agW+q1Gm5H+MgHLOwIht/PIySph7vYXssnnZskDAei18dogYcYRvvlcccEVtpT3j/wwCaRCWr+/nUavXCeE+eNQhd4wM477qbV6OvjBI6stnIL+jOkzN3B3EKRBqHltLFr2H+GXaaHspnU8ShBw==
  • Delivered-to: jdt-dev@xxxxxxxxxxx
  • List-archive: <https://www.eclipse.org/mailman/private/jdt-dev/>
  • List-help: <mailto:jdt-dev-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/jdt-dev>, <mailto:jdt-dev-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/jdt-dev>, <mailto:jdt-dev-request@eclipse.org?subject=unsubscribe>
  • Thread-index: AQHbZTL3cp7vrkdVNE2FhhRVNCTZL7MUV3oAgADad4CAAKCUgIABf8zAgAA4vACAAfkngIABUhWAgAGqZwCAAIY7AIAAIJsAgAG6+oCAAJAWgIAAAXgg
  • Thread-topic: [EXTERNAL] Re: [jdt-dev] About Y-Builds (was Re: 4.35 Y-Build: Y20250111-1000 - BUILD FAILED)

> Master could easily include support for Java 24; as long as the file support Java 23, the Java 24 code wouldn't harm; just as it won't harm after Java 24 is released and the BETA_JAVA24 branch is merged.

 

I request you to look at the code around preview flags, for e.g., AST#isPreviewEnabled() . In master, preview can only be enabled with Java 23, but in BETA_JAVA24, preview can only be enabled with Java 24.

 

Similarly, JavaFeature that specifies the @since version a preview feature is supported, will change between master and BETA.

 

Regards,

Jay

 

 

From: jdt-dev <jdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Mickael Istria via jdt-dev
Sent: 20 January 2025 15:04
To: Eclipse JDT general developers list. <jdt-dev@xxxxxxxxxxx>
Cc: Mickael Istria <mistria@xxxxxxxxxx>
Subject: [EXTERNAL] Re: [jdt-dev] About Y-Builds (was Re: 4.35 Y-Build: Y20250111-1000 - BUILD FAILED)

 

Thanks all, I see some progress. @Mike thank you for the clear explicit recommendation; we're preparing an hopefully concise and precise enough mail for legal to ask for their assistance About the feature flags, I actually think that we

Thanks all, I see some progress.

@Mike thank you for the clear explicit recommendation; we're preparing an hopefully concise and precise enough mail for legal to ask for their assistance

 

About the feature flags, I actually think that we don't need them... more than we already do!

For example in the code of ECJ's `*Scope` classes, we can read in 39 places some patterns like: `if (level <= ClassFileConstants.JDK_NNN)`, (where level can be sourceLevel, complianceLevel...)

In the DOM, we have some `ASTNode.unsupportedInX_Y_Z()` methods which are extensively used and do act as a feature flag (throwing exceptions or disabling features when compilation doesn't target a recent enough Java version).

 

So basically instead of adding some new flags as I suggested earlier, we can just stick to the usual flags. Master could easily include support for Java 24; as long as the file support Java 23, the Java 24 code wouldn't harm; just as it won't harm after Java 24 is released and the BETA_JAVA24 branch is merged.

Just "hiding" the Java 24 source level from the UI seems enough to hide all Java 24 support. The Java 24 specific code is internal and basically not used.

So if we stick to this existing pattern, which I believe is enough, then we don't need a new process; things become just "working on the master branch" but with the same usual patterns of guarding the new features by the Java version which make them available.

 

Cheers,

Mickael

Back to the top