Bug 531716 - [13] Support for JEP 355 Text Block
Summary: [13] Support for JEP 355 Text Block
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.8   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: BETA J13   Edit
Assignee: Jay Arthanareeswaran CLA
QA Contact: Jay Arthanareeswaran CLA
URL:
Whiteboard:
Keywords:
Depends on: 549199 549835
Blocks: 539066 541254 549473
  Show dependency tree
 
Reported: 2018-02-27 03:16 EST by Manoj N Palat CLA
Modified: 2019-08-29 07:49 EDT (History)
7 users (show)

See Also:


Attachments
java.g and assoc parser changes - wip (167.15 KB, patch)
2018-06-19 10:50 EDT, Manoj N Palat CLA
no flags Details | Diff
Scanner changes - WIP (dated) (10.50 KB, patch)
2018-06-19 10:51 EDT, Manoj N Palat CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Manoj N Palat CLA 2018-02-27 03:16:38 EST
https://bugs.openjdk.java.net/browse/JDK-8196004
Comment 1 Jesper Moller CLA 2018-06-18 18:49:26 EDT
I'll take a look at this one, then.
Comment 2 Manoj N Palat CLA 2018-06-19 10:50:40 EDT
Created attachment 274535 [details]
java.g and assoc parser changes - wip

(In reply to Jesper Moller from comment #1)
> I'll take a look at this one, then.

Thanks Jesper. As of now this is not targeted - will have to wait until next week to be sure.
[I had tried this initially - attaching those patches - they are dated  - if it helps let  it]
Comment 3 Manoj N Palat CLA 2018-06-19 10:51:08 EDT
Created attachment 274536 [details]
Scanner changes - WIP (dated)
Comment 4 Jesper Moller CLA 2018-10-26 08:59:20 EDT
@Manoj: I've had some problems getting to a clean test result in the BETA_JAVA_12 branch, just running RunAllJava11Tests under JDK 11.0.0.

It's like the Java version switches are wrong in some cases, since the failures are about stuff like nested class names and the use of synthetic accessors.

I'll investigate further.
Comment 5 Jay Arthanareeswaran CLA 2018-11-08 03:46:29 EST
(In reply to Jesper Moller from comment #4)
> @Manoj: I've had some problems getting to a clean test result in the
> BETA_JAVA_12 branch, just running RunAllJava11Tests under JDK 11.0.0.
> 
> It's like the Java version switches are wrong in some cases, since the
> failures are about stuff like nested class names and the use of synthetic
> accessors.
> 
> I'll investigate further.

Jesper, I released some changes recently. Can you try now?
Comment 6 Jay Arthanareeswaran CLA 2018-11-16 04:54:57 EST
Looks like the grammar and scanner changes are good enough for me to continue the work into the resolution. I will take this up.
Comment 7 Jay Arthanareeswaran CLA 2018-11-19 05:49:58 EST
The grammar and scanner changes passed my simple tests. Had to make some changes in resolution phase to make things work. I will be adding more complex tests and making changes as required. 

At a quick glance, debug seems unaffected too.

I have raised 541254 for code assist.
Comment 8 Jay Arthanareeswaran CLA 2018-11-20 03:59:03 EST
Note, this will be a preview feature.
Comment 9 Manoj N Palat CLA 2018-12-11 22:39:33 EST
JEP 326 may be dropped as per https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html
Comment 10 Dani Megert CLA 2018-12-14 10:33:41 EST
(In reply to Manoj Palat from comment #9)
> JEP 326 may be dropped as per
> https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html

Most likely now. It's already listed in the plan:
http://openjdk.java.net/projects/jdk/12/#Schedule
Comment 11 Manoj N Palat CLA 2018-12-20 00:52:55 EST
(In reply to Dani Megert from comment #10)
> (In reply to Manoj Palat from comment #9)
> > JEP 326 may be dropped as per
> > https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html
> 
> Most likely now. It's already listed in the plan:
> http://openjdk.java.net/projects/jdk/12/#Schedule


Dropped - ref https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002469.html
Comment 12 Manoj N Palat CLA 2019-03-18 19:50:16 EDT
This is appearing in the JEP 388 Java 13 dashboard - Hence keeping in radar.
Comment 13 Manoj N Palat CLA 2019-04-17 19:30:17 EDT
@Jay: You may want to check out this discussion : https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-April/001119.html
Comment 14 Manoj N Palat CLA 2019-05-15 02:22:12 EDT
A new Avatar : https://bugs.openjdk.java.net/browse/JDK-8222530
Comment 15 Manoj N Palat CLA 2019-05-28 01:18:01 EDT
(In reply to Manoj Palat from comment #14)
> A new Avatar : https://bugs.openjdk.java.net/browse/JDK-8222530

And the JEP 355 (Preview) available here:
http://cr.openjdk.java.net/~abuckley/jep355/text-blocks-jls.html
Comment 16 Eclipse Genie CLA 2019-05-30 10:38:24 EDT
New Gerrit change created: https://git.eclipse.org/r/143065
Comment 18 Jay Arthanareeswaran CLA 2019-06-20 06:17:45 EDT
(In reply to Eclipse Genie from comment #17)
> Gerrit change https://git.eclipse.org/r/143065 was merged to [BETA_JAVA13].
> Commit:
> http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=0beb35f8f1d9f23acdb771167f1d97e01aa3e597
> 

Released the change along with support for Unicode and indentation. The error reporting on incomplete text block is not aggressive just to make sure we don't deviate from previous error reporting, for e.g. the below code:

String s = """""";

Ideally we would like to report the missing newline after the opening delimiter """, but that would mean we change some of the existing tests. Perhaps we can revisit at a later point to cover these. 

Another IMPORTANT NOTE:

After this grammar change and the previous grammar changes in the branch, I started seeing some nasty errors (mostly AIOOBE) in the parser. Investigation revealed that we reached the boundary of 128 (max a byte can store). The table in question is Parser#scope_la, which was previously a byte[] but no longer enough to store 128, which when converted to int, became -127 and hence all the index related operations started throwing exception. This change is now part of the fix.

The ParserUpdater tool of JDT needs corresponding change too. Luckily, looking at the source code of Jikespg, I see that it is programmed to handle both byte and char and correctly generates char[] for the scope_la and it is our internal tool that wasn't prepared for this.
Comment 19 Jay Arthanareeswaran CLA 2019-06-20 13:31:57 EDT
Things to do to complete this:

1. Add more tests, like using text blocks as argument, using them interchangeably with strings etc.
2. Move the new tests to the new test bundle suggested in bug 546473, so that we can compare our test results with the new String APIs in JDK 13, such as stripIndent, translateEscapes etc.
3. Run/write performance tests to make sure performance for regular String operations are unaffected by the new code in Scanner.
Comment 20 Manoj N Palat CLA 2019-06-21 03:13:32 EDT
@Jay: looks like commit 7b27f6aee778dd071b90ede7982881541c81dc47 inadvertently removed the changes in  .api_filters for 548208 - the api issue - could you please recheck the commit and change accordingly
Comment 21 Eclipse Genie CLA 2019-06-21 03:39:16 EDT
New Gerrit change created: https://git.eclipse.org/r/144595
Comment 22 Eclipse Genie CLA 2019-06-21 06:03:22 EDT
New Gerrit change created: https://git.eclipse.org/r/144614
Comment 24 Sarika Sinha CLA 2019-06-21 06:07:06 EDT
(In reply to Eclipse Genie from comment #21)
> New Gerrit change created: https://git.eclipse.org/r/144595

After discussing with Manoj, Abandoned this in favour of  https://git.eclipse.org/r/144614
Comment 25 Jay Arthanareeswaran CLA 2019-06-25 04:22:23 EDT
Turns out we had another boundary reached in Parser#term_check. I am upgrading that one as well to two bytes instead of a single byte. This was causing the failures in NullTypeAnnotationTest (probably others too). I will post a patch shortly for this.
Comment 26 Eclipse Genie CLA 2019-06-25 04:42:32 EDT
New Gerrit change created: https://git.eclipse.org/r/144812
Comment 28 Eclipse Genie CLA 2019-06-26 04:11:17 EDT
New Gerrit change created: https://git.eclipse.org/r/144901
Comment 30 Eclipse Genie CLA 2019-06-28 11:45:25 EDT
New Gerrit change created: https://git.eclipse.org/r/145127
Comment 32 Eclipse Genie CLA 2019-07-05 00:24:05 EDT
New Gerrit change created: https://git.eclipse.org/r/145497
Comment 34 Eclipse Genie CLA 2019-07-18 01:55:39 EDT
New Gerrit change created: https://git.eclipse.org/r/146288
Comment 36 Eclipse Genie CLA 2019-07-22 10:17:21 EDT
New Gerrit change created: https://git.eclipse.org/r/146460
Comment 38 Eclipse Genie CLA 2019-07-24 02:47:58 EDT
New Gerrit change created: https://git.eclipse.org/r/146541
Comment 40 Manoj N Palat CLA 2019-08-13 03:58:30 EDT
Additional material on text blocks- http://cr.openjdk.java.net/~jlaskey/Strings/TextBlocksGuide_v8.html
Comment 41 Manoj N Palat CLA 2019-08-20 19:14:22 EDT
@Jay: with -Xlint:text-blocks on, javac provides some warnings- for eg, given the following code:
@SuppressWarnings("preview")
class X {
    public static void main(String[] args) {
		String t = """
			   trailing white space         
			    """;
		System.out.println(t);
     }
}

$ javac13 --enable-preview -source 13 -Xlint:text-blocks X.java
X.java:4: warning: [text-blocks] trailing white space will be removed
                String t = """
                           ^

Here the 
			   trailing white space         

has trailing white space. 
I think ecj should also flag a warning in this case.
Comment 42 Jay Arthanareeswaran CLA 2019-08-29 07:49:42 EDT
(In reply to Manoj Palat from comment #41)
> @Jay: with -Xlint:text-blocks on, javac provides some warnings- for eg,
> given the following code:
> @SuppressWarnings("preview")
> class X {
>     public static void main(String[] args) {
> 		String t = """
> 			   trailing white space         
> 			    """;
> 		System.out.println(t);
>      }
> }
> 
> $ javac13 --enable-preview -source 13 -Xlint:text-blocks X.java
> X.java:4: warning: [text-blocks] trailing white space will be removed
>                 String t = """
>                            ^
> 
> Here the 
> 			   trailing white space         
> 
> has trailing white space. 
> I think ecj should also flag a warning in this case.

That'll be nice to have and the spec doesn't say anything. We can keep that on another bug. I am closing this one.