Re: [ide-dev] Fwd: Simplified main methods -- what IDE users should expe

[Edward Willink <ed@xxxxxxxxxxxxx>]

Hi

(I try to stick to Java 8 so I prefer the 'old' way.)

But realistically, most of the source generators have a pop-up to 
configure, so

- provide a classic/compact check box
Classic greys out the following, compact enables with potentially 
dynamic contextual defaults
- provide a public check box
- provide a static check box
- provide a args check box

Regards

Ed Willink

On 08/05/2025 13:38, Stephan Herrmann via ide-dev wrote:
> Hi all,
>
> Please see Tagir's question below. I think it's great that he asks, so 
> we have a chance to coordinate the mental model between IDEs.
>
> See also 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2025-May/004274.html 
> for replies.
>
> If anybody has some convincing comments, I'd be happy to forward them 
> to the original list.
>
> best,
> Stephan
>
>
> -------- Weitergeleitete Nachricht --------
> Betreff:     Simplified main methods -- what IDE users should expect?
> Datum:     Thu, 8 May 2025 10:32:24 +0200
> Von:     Tagir Valeev <amaembo@xxxxxxxxx>
> An:     amber-spec-experts <amber-spec-experts@xxxxxxxxxxx>
>
>
>
> Hello, dear experts!
>
> This discussion is not exactly about Java specification, but I think 
> we have the right people here for this topic.
>
> The Java IDEs usually provide a way to automatically generate a main 
> method using some kind of template named 'main' or 'psvm' (which is 
> short for 'public static void main'). Historically, invoking such a 
> template generated a code like this:
>
> public static void main(String[] args) {
>    <caret is here>
> }
>
> However, when 'Compact Source Files and Instance Main Methods' feature 
> (JEP 512) is available, this doesn't look like a good default anymore. 
> Some of our colleagues advocate that keeping the old signature is good 
> because this is what people get used to, but I think we should 
> reconsider this.
>
> Now we have multiple ways to generate a main method:
> - 'public' may be present or not
> - 'static' may be present or not
> - 'String[] args' may be present or not
>
> So technically we have eight different variants. What would the user 
> expect by default?
>
> In my opinion, 'public' is simple: we should just drop it, as it 
> doesn't add any value. This reduces the number of options to four.
>
> The 'static' modifier is more difficult. 'static void main()' and 
> 'void main()' have different semantics: the latter involves automatic 
> class instantiation, it makes the main() method inheritable (so 
> inheritors if any may become launchable), and it requires a no-arg 
> constructor. We cannot generate `void main(){}` inside the class that 
> contains no default constructor, as this method will be non-functional 
> and users might be surprised and confused. We might consider adding 
> the `static` modifier only in classes without no-arg constructor, but 
> this might be inconsistent, as users might not understand why 
> sometimes `static` is generated and sometimes is not. Another case is 
> implicit classes where `static` looks really alien, and we never have 
> problems like no-arg constructors or inheritors. So I lean toward 
> generating 'static' by default for explicit classes (regardless of its 
> constructors) and no 'static' for implicit classes. However, I'm not 
> sure that it's the best solution.
>
> Skipping 'String[] args' by default seems nice, but it will worsen the 
> experience of people who actually need the args, as they will probably 
> need to type more. We can assume that the variable named 'args' is 
> implicitly available inside the method body, so the user may use it 
> via autocompletion, and upon the first use, it will be automatically 
> added to the method signature. This is possible but somewhat weird: 
> users should know in advance that something named 'args' can be used, 
> even if it's not explicitly available in the code.
>
> We can also create several templates (something like 'maina' for main 
> with arguments and 'mains' for static main), but this also complicates 
> things and increases the cognitive load to the users. Also, different 
> IDEs may solve this differently, and this may add confusion for people 
> who change IDE sometimes.
>
> I would be glad to hear your opinions. What would you expect from your 
> IDE when generating a main method in Java 25?
>
> With best regards,
> Tagir Valeev
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/ide-dev