@Data注解时生成的getter,setter方法在有些属性会有问题！！！

[initcap]

eg:private String cMc;

@DaTa时：public String getCMc(){};
但是idea自动生成的是public String getcMc(){};

造成的实质性后果：
SpringMVC处理@DaTa注解时，返回给前端时cmc
SpringMVC处理idea生成的时，返回给前端的是cMc

导致前端拿这个返回字段给后端时，后端不能接收cmc的值。

[victorwss]

Translating that into English with the help of Google translator, it seems to be that:

Eg:

private String cMc;

@Data: public String getCMc(){};

But idea automatically generates a public String getcMc(){};

Substantial consequences:

When SpringMVC processes the @Data annotation, it returns to the frontend when cmc
When SpringMVC processes the idea generation, it is cMc that is returned to the front end.

When the front end takes this return field to the backend, the backend cannot receive the value of cmc.

Seems to be another duplicate of #757, #1453, #1454, #1496 and #1661 and possibly others.

[initcap]

public static void main(String[] args) {
String prefix = "get";
String suffix = "oFo";
log.info("【源码结果】:{}",buildAccessorName(prefix,suffix));
log.info("【改正结果】:{}",buildAccessorNameModified(prefix,suffix));
}

/**
 * 【lombok源码问题片段】
 * 位置:git@github.com:rzwitserloot/lombok.git/src/core/lombok/core/handlers/Handler.java 434行
 */
public static String buildAccessorName(String prefix, String suffix) {
	if (suffix.length() == 0) return prefix;
	if (prefix.length() == 0) return suffix;

	char first = suffix.charAt(0);
	if (Character.isLowerCase(first)) {
		boolean useUpperCase = suffix.length() > 2 &&
				(Character.isTitleCase(suffix.charAt(1)) || Character.isUpperCase(suffix.charAt(1)));
		suffix = String.format("%s%s",
				useUpperCase ? Character.toUpperCase(first) : Character.toTitleCase(first),
				suffix.subSequence(1, suffix.length()));
	}
	return String.format("%s%s", prefix, suffix);
}

public static String buildAccessorNameModified(String prefix, String suffix) {
	if (suffix.length() == 0) return prefix;
	if (prefix.length() == 0) return suffix;

	char first = suffix.charAt(0);
	if (Character.isLowerCase(first)) {
		boolean useUpperCase = suffix.length() > 2 &&
				(Character.isTitleCase(suffix.charAt(1)) || Character.isUpperCase(suffix.charAt(1)));
		suffix = String.format("%s%s",
				useUpperCase ? first : Character.toTitleCase(first),
				suffix.subSequence(1, suffix.length()));
	}
	return String.format("%s%s", prefix, suffix);
}

[victorwss]

Ok, lets translate that:
源码结果 -> Source code results
改正结果 -> Correct result (or perhaps, expected result)
lombok源码问题片段 -> Lombok source code fragment
位置 -> at
434行 -> Line 434

Well, there is no class Handler. Maybe you are referring to this: https://github.com/rzwitserloot/lombok/blob/ad21a1573bab57c63ffd5b9867f8e19ac7f0c94b/src/core/lombok/core/handlers/HandlerUtil.java#L434-L447

I see that your suggestion is to use just first in the place of Character.toUpperCase(first). But this have some problems about retrocompatibility and that the Java Beans spec is basically broken in this corner case.

Further duplicates: #504, #1023, #1129, #1225, #1030.

So, please:

• Read the text of the duplicates.
• Read this discussion: https://groups.google.com/d/msg/project-lombok/c9WKYhlfe8k/XQJnL2ABbXYJ
• Don't post text in Chinese here because very few people in this community would be able to understand it. If you can't write in English, use google translator (or whatever tool you have) just as I did even if the result is not very precise.

[victorwss]

Oh, very relevant to this: https://stackoverflow.com/a/49348966/540552

[Maaartinus]

In the Google Groups thread, Reinier wrote

this corner case is definitely not worth a config key in our opinion.

but given that how often it comes, I'd suggest to reconsider.

@rzwitserloot Would you accept a PR introducing a config key, ensuring backwards compatibility and providing the alternate behavior?

If so, then someone interested in the crapspec could make the PR and we could get rid of this coming up again and again.

[initcap]

Ok, thank you, you are correct, I have learned a lot, thank you very much!

[rspilker]

@Maaartinus No, but we would accept a pull request that does change the behavior and breaks backwards compatibility. Counting the number of issues, we made a mistake.

We would most likely use the 2.x release to introduce this change.

We do not want to introduce config keys because that clutters up the code, resulting in more code to maintain than if we make a clean break.

For us, the best pull request is already squashed to a single changeset, and includes also the modified test code.

Please keep in mind that this might also affect other code like @Builder and @Wither.

[TGhoul]

@qingqingmanong 你好，请问你的问题解决了吗？

[Achieve777]

the best way to resolve it using "overload"

[gtskaushik]

I am facing the same issue. I understand the compatibility issue. But recommend to re-consider since this has affected a lot many users

[janrieke]

Then do something instead of posting those +1's. The maintainers already stated over a year ago that they'd accept a PR that changes this.