Model class transformation related function support

[944332213]

java package
javax.validation.constraints.*
to C# package
System.ComponentModel.DataAnnotations.*
support.

lombok.Data support C# { get; set; }

Java attribute hump named to C# PASCAL naming style

Java Integer
At present for
C# int
Try to
int?

[paulirwin]

I think I understand item 1 above, but can you elaborate on numbers 2-4?

[paulirwin]

Coming back to this after a while. Since the original questions went unanswered, I went through the codebase to work out what each item would actually require. Recording that here so this issue is actionable.

My reading is that all four items describe the same scenario: converting a Java "model class" (a DTO/entity/POJO) into an idiomatic C# model class. That framing makes items 2-4 much clearer than they read in isolation.

1. javax.validation.constraints.* → System.ComponentModel.DataAnnotations.*

Mapping Bean Validation annotations to their .NET equivalents: @NotNull→[Required], @Size→[StringLength], @Min/@Max→[Range], @Email→[EmailAddress], @Pattern→[RegularExpression].

There's a partial mechanism already — SyntaxMapping has YAML-driven ImportMappings and AnnotationMappings. Four gaps block this use case:

• AnnotationMappings is only consulted in MethodDeclarationVisitor.cs:127. FieldDeclarationVisitor never calls getAnnotations(), so field annotations — where validation constraints actually live — are dropped.
• Class-level annotations (ClassOrInterfaceDeclarationVisitor.cs:329-354) only special-case @Deprecated and ignore AnnotationMappings entirely.
• Annotation arguments are discarded. MethodDeclarationVisitor.cs:129-131 builds a bare attribute from the name only, so @Size(max=50) can't become [StringLength(50)]. This is the hard part — the arguments need translating too, and the parameter names differ between the two libraries.
• ImportMappings is keyed on the exact full import string (UsingsHelper.cs:35), so the wildcard form in the original request wouldn't match.

Worth noting the current default output is actively wrong rather than merely missing: UsingsHelper.cs:31-32 capitalizes each segment, so javax.validation.constraints.NotNull becomes using Javax.Validation;.

Also relevant: ImportMappings/AnnotationMappings both default to empty, so today this requires a hand-written YAML file via --mappings-file. Part of this request is really "ship sensible defaults," not just "add a mechanism." And SyntaxMappings isn't exposed in the GUI at all (JavaToCSharpGui/CurrentOptions.cs), so a mappings-only fix would be CLI/library-only.

2. Lombok @Data → { get; set; }

Lombok generates accessors at compile time, so the Java source has only bare private fields. The request is for a @Data-annotated class to emit C# auto-properties.

There is no Lombok handling anywhere today — @Data falls through the unmapped-annotation path and is silently dropped, leaving private fields with no accessors.

This is the largest and most opinionated of the four. @Data also implies equals/hashCode/toString, and there's a family of related annotations (@Getter, @Setter, @Value, @Builder) with different semantics. Probably worth scoping to @Data/@Getter/@Setter initially, if it's taken on at all.

3. camelCase → PascalCase

"Hump" here is 驼峰 — camelCase. The request is to rename members to PascalCase per .NET convention.

This is narrower than it first appears: method names are already unconditionally PascalCased via TypeHelper.Capitalize, applied consistently at declarations (MethodDeclarationVisitor.cs:40,84), call sites (MethodCallExpressionVisitor.cs:19), and method references (MethodReferenceExpressionVisitor.cs:36). So this item is really only about fields, which use getNameAsString() verbatim (FieldDeclarationVisitor.cs:38,56,61).

The method-renaming machinery is a useful precedent — it shows the "must rewrite every reference site, not just the declaration" problem is already solved once in this codebase. Renaming fields still carries real risk (reflection, serialization names, string-based lookups), so this should be opt-in.

4. Integer → int?

Java's boxed Integer is nullable; C# int is not. On a model class, Integer usually means "optional field," so int? preserves the semantics.

TypeHelper.cs:24 maps Integer→int unconditionally (same for Boolean, Long, Float). Changing this can't be unconditional — it would be breaking for non-model code — so it needs an opt-in option.

There's a related plain bug worth separating out: Double, Character, Short, Byte, BigDecimal, and BigInteger have no entry in the table at all and pass through unchanged. Character in particular produces non-compiling C#. That's fixable on its own with no new option.

One implementation note: _typeNameConversions is private static and mutated at conversion time by AddOrUpdateTypeNameConversions, so it's process-global and leaks interface renames across conversions. Making the boxed-type behavior configurable likely means making that table context-scoped first.

Suggested decomposition

These are really six separate pieces of work:

1. Extend AnnotationMappings to fields and classes, including argument passthrough (unblocks item 1 generically)
2. Ship built-in javax.validation.constraints → DataAnnotations mappings (depends on 1)
3. Add the missing boxed-type mappings — pure bug fix, no new option
4. Opt-in Integer→int? (likely depends on making the type table context-scoped)
5. Opt-in field PascalCasing
6. Lombok @Data → auto-properties

Best value-to-risk is 3 (self-contained bug fix) and 1 (unlocks a whole category via the existing extension point). I'd lean toward splitting these into separate issues and closing this one as the umbrella.

---

Analysis generated with Claude Code.