Community
Participate
Working Groups
Bug 542579 will provide the user a way to change the --enable-preview for workspace/project. We can define for workspace only if the default compliance of workspace is 12 and still if there are pre existing project settings, users will have to literally change it in each project. Java 12 has only 1 major feature and that needs --enable-preview. I think Eclipse as an IDE should make the life easier for users to use this feature. While adding the Java 12 JRE through Installed JREs(or edit later), user should be able to specify the default value of --enable-preview, and JDT core could pick up this value rather that defaulting it to false. This will still allow to obey all the other rules of compliance, source, target and --release option.
-1. That would be a hidden feature that users won't understand. Having said that, I get your point. We could enable the option even if compliance is below 12 and add a hint to the label that it only has an effect for source > 11. We could also reconsider to move the option as sibling to the --release option.
(In reply to Dani Megert from comment #1) > -1. > > That would be a hidden feature that users won't understand. Will it help if we have a quick fix saying enable preview feature for all projects using this JRE ? > > Having said that, I get your point. > > We could enable the option even if compliance is below 12 and add a hint to > the label that it only has an effect for source > 11. We could also > reconsider to move the option as sibling to the --release option. +1 Both the changes can go independently and will help the user as second option does not help for cases with Project defining their own settings.
(In reply to Sarika Sinha from comment #2) > (In reply to Dani Megert from comment #1) > > -1. > > > > That would be a hidden feature that users won't understand. > Will it help if we have a quick fix saying enable preview feature for all > projects using this JRE ? Where would you show that quick fix? > Both the changes can go independently and will help the user as second > option does not help for cases with Project defining their own settings. I can't parse that sentence, sorry. Please try again. Thanks.
(In reply to Dani Megert from comment #3) > (In reply to Sarika Sinha from comment #2) > > (In reply to Dani Megert from comment #1) > > > -1. > > > > > > That would be a hidden feature that users won't understand. > > Will it help if we have a quick fix saying enable preview feature for all > > projects using this JRE ? > Where would you show that quick fix? As default is --enable-preview false, Compiler will show error on the java editor using switch expressions. We can provide this quick fix along with the quick fix to enable preview preference for workspace/project > > > > Both the changes can go independently and will help the user as second > > option does not help for cases with Project defining their own settings. > I can't parse that sentence, sorry. Please try again. Thanks. I meant we can do both the things, add --enable-preview default value for JRE, as well as allow the user to set workspace setting even though default compliance is not 12. If project settings exist for the project it will not be able to use --enable-preview for workspace but still can use JRE's default value.
I am against adding a relationship from JREs to the compiler preferences. I also don't like to add a quick fix that changes the settings for all projects. Keep in mind that the preview features are things that can go away and are not enabled by default, hence most users won't enable this. (In reply to Dani Megert from comment #1) > We could enable the option even if compliance is below 12 and add a hint to > the label that it only has an effect for source > 11. We could also > reconsider to move the option as sibling to the --release option. In order to do the first part we would also have to move the option, because otherwise it would be disabled. Not something I really like. I suggest we don't do anything at the moment. We can reconsider this if we get concrete requests/complaints.
(In reply to Dani Megert from comment #5) > I suggest we don't do anything at the moment. We can reconsider this if we > get concrete requests/complaints. The important part is to have the quick fix (bug 543668). That quick fix could show a list of all projects that are setup for Java 12. Similar to Configure > Convert to Plug-in Projects... Jay, Noopur what do you think?
The problem described here exists for all the preferences where we have project-specific settings, which goes to bug 194414. It will be good to have a general solution via that bug. Here, bug 543668 is to provide a quick fix on a preview feature error in a Java project to open the Compiler preference page in its project properties or the workspace page (if no project settings are defined) where the user can enable the checkbox (after changing other settings if applicable). If we go for another quick fix to show a list of all Java 12 projects, I am not sure where it will be invoked from and how the flow will be for opening the Compiler pages for all those projects. We will have to think more about it. I am fine with not doing anything here at the moment. We should reconsider it after other more important enhancements and fixes are done for the J12 release as I think this will need time to discuss, finalize and implement. For now, if the user is having project-specific settings, then he/she should enable the preview checkbox also while updating the project settings to use Java 12 initially. If using workspace settings for the project, then I don't think we have an issue here.
(In reply to Noopur Gupta from comment #7) > The problem described here exists for all the preferences where we have > project-specific settings, which goes to bug 194414. It will be good to have > a general solution via that bug. +1 > Here, bug 543668 is to provide a quick fix on a preview feature error in a > Java project to open the Compiler preference page in its project properties > or the workspace page Why? Why not just do the necessary changes, unless of course the defaults have already been tweaked by the user. > If we go for another quick fix to show a list of all Java 12 projects, I am > not sure where it will be invoked from No additional quick fix. In the editor where the error/warning is seen we'll show the list (if there are more than one Java 12 projects).
(In reply to Dani Megert from comment #8) > > Here, bug 543668 is to provide a quick fix on a preview feature error in a > > Java project to open the Compiler preference page in its project properties > > or the workspace page > Why? Why not just do the necessary changes, unless of course the defaults > have already been tweaked by the user. See 543668 comment #2.
(In reply to Noopur Gupta from comment #9) > (In reply to Dani Megert from comment #8) > > > Here, bug 543668 is to provide a quick fix on a preview feature error in a > > > Java project to open the Compiler preference page in its project properties > > > or the workspace page > > Why? Why not just do the necessary changes, unless of course the defaults > > have already been tweaked by the user. > See 543668 comment #2. I think we could handle both cases. The workspace case is the exceptions since we create Java projects with project specific settings for years.
I have released the QF in bug 543668 based on my initial plan. Please try it out and let me know what changes are required there for this bug.
(In reply to Noopur Gupta from comment #11) > I have released the QF in bug 543668 based on my initial plan. Please try it > out and let me know what changes are required there for this bug. Done. I suggest we work on 543668 and look at multi-project QF when we get a request.
