Im learning java

safety from what?
from whatever retard uses your class and doesn't understand that data is read only?

elaborate

>#define
Stupid

>doesn't understand that data is read only
Wasn't a premise I responded to. public static final is fine in such a scenario.
>from whatever retard uses your class
Yes, because when you're developing for an enterprise system you need to make things as pajeet proof as possible. Ceding direct variable access to other classes means the class that holds the field is powerless to check that the input is valid beyond the type obviously.

Unless you want to "check validity" every time that field is invoked, and then you run into the issue of restoring the previous data if it is invalid.

Security beyond invalid values isn't so much an issue when you're dealing with primitives yeah, but when you're holding more complex classes you run a security risk if it can be modified willy nilly.

tl;dr Of course its fine for small, personal projects, but with growing complexity comes growing room for failure.

Then, I get why you'd do a get() function on a private resource.
But why extend it to public data?

Header declarations and such should be done in all caps typically

i don't really understand what you're trying to say. if your original comment was in response to the kotlin stuff please do the needful and look up val / var

yet it still works

You wouldn't. If you have a public reference, you access it directly-- the question is always whether or not it SHOULD be public. If there's an argument for why you'd have an accessor for a public field, I'm ignorant as it pertains to it.
In the context of Java or any similarly structured language, the getters/setters are necessary to ensure that the possessing class needs to be the final arbiter for its own dat so that it can ensure it is valid for the context its used in. I wouldn't know anything about Kotlin.

its time to stop and start learning Kotlin or Scala

>public class Constants2

wrong wrong wrong
in Java, you're supposed to write a factory which returns a value based on the arguments of a value, type of a value which is inputted, and type of a value you desire on the output. the class should multiply the value depending on the set options and return it without exposing the user to multiplication algorithms

Attached: 1523969963135.jpg (597x508, 43K)

>In the context of Java or any similarly structured language, the getters/setters are necessary to ensure that the possessing class needs to be the final arbiter for its own dat so that it can ensure it is valid for the context its used in.
is it really necessary to do that for every field though? i'm just saying... my dick is HARD for kotlin and i must EXPRESS MY FEELINGS

If it is intended to be modified, yes.

It would be nice if there was a "public-access" modifier, meaning that you can directly invoke the data, but still need to modify it through a method.

There's private, protected and public each with their own encapsulation uses

>In the context of Java or any similarly structured language, the getters/setters are necessary to ensure that the possessing class needs to be the final arbiter for its own dat so that it can ensure it is valid for the context its used in. I wouldn't know anything about Kotlin.
Or you could just say, "mutators make sure that the class they affect always has the power to reject or modify data that would be invalid or harmful for its purpose."
I guess "unsigned" ints in java are an example of this.

>you need to make things as pajeet proof as possible
>pajeet proof
kek

H-1B was a mistake. Thank fucking god "Software Engineer" is no longer classified as specialized skills by the Immigration Bureau or whatever the fuck.

And default. Don't forget default.

>Asks me why he has to make functions to get and set an object's variables.
>Tell him to just make them public.
>Never found a use case where it made any difference
If you have thousands or million lines of code, if you change the variable name or something related to it, you only need to make a change on place, inside the function, instead of manually changing it in all the files it is referenced.
Also to prevent anothrr person from changing the value to something stupid. Easy(er) to keep track of when you make a project on your own, hard to make safe when you have hundreds of people writing code.

Java was not designed for single person projects, it was designedfor large enterprise projects.

Think about all the horrible coders you have met, do you want them to change values in your code at will, or only access your code through your API you made? Which one is more safe to use?

If most/all of your object variables require get/set functions, your codebase is probably poorly designed to begin with; they're just structs LARPing as OOP classes.

No, that's the power of poor design. You don't need a class of constants like this.

OP.
If you want a set of constants don't make a class like this. Instead make the constants inside of energy interface that is implemented with a class or and enum

Idk, maybe they should just read the documentation I did before using my objects?

Remove "energy". Auto correct got me

>You don't need a class of constants like this
You could need something like this for configuration. Reading from a file/environment variables/default constants. Spreading configuration around your code-base is shit-tier.

> maybe they should just read the documentation
Kek, your code should be self-documenting, found the under-grad.

>Kek, your code should be self-documenting, found the under-grad.
Found the retard with no real world experience. 0 comments is an idealistic asymptote but in practice you need about 30-60% of your methods documented.

>found the under-grad.

Or I use tools that turn my commenting into documentation.
Anyways, retards will just use auto-completion to maneuver around foreign objects, before wondering why everything's broken.
They're not gonna look at the source code, even if provided, and even less at the documentation, before everything goes down the toilet.

You know you did this before.

And if you're too retarded to understand why you shouldn't be setting that variable, you're probably too retarded to even use the class.

There's also problem with it's usage. A constant like that is only useful for converting cm to inches. In actuality he's code is going to be littered with statements like
double y = x * CM_PER_INCH;

When it could be
double y = inchsAsCentimeters(x)
or
double y = inToCm(x)

>30-60% of your methods documented.
Wew lad, go back to school

Read a book sometimes, not even the XPfags will tell you that you can have code without comments

I know right, documentation makes you replaceable.
Always be the only one who can read your code.
Totaly serious :^)

Bucko, using comments sparingly is not the same thing as REQUIRING 30-60% to have an accompanying explanation AND documentation in order to grok what the fuck is going on.
Don't bother responding to me anymore, just continue delivering sub-par shit.
See above

>instead of manually changing it in all the files
>manually
so it's for idiots?

private void registerServletContainerInitializerToDriveServletContextInitializers(DeploymentInfo deployment, ServletContextInitializer... initializers)
github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/web/embedded/undertow/UndertowServletWebServerFactory.java

Attached: 1497038755516.jpg (249x249, 10K)

Yes. Assume that everything you build will be used by the dumbest idiot you can conceive of, and design it in a way that will allow them to do the least amount of damage possible.
This is unironically what being an effective programmer in large teams looks like. Your design should funnel people towards doing the right thing.

No, they are still protected by default.

Honestly, compared to C#, Java is such a fucking disgusting language to look at.

It really needs type inference, null conditional operators, properties, and LINQ.

it's not a requirement you retard it's the natural consequence of systems being complex
having no comments is just being lazy, you try to remove comments but it is impossible to remove all of them, if you worked for any kind of real world large scale project you would know that

if (person != null && person.getFriends() != null && person.getFriends().size() > 0) {

}

vs

if (person?.Friends?.Count > 0)
{

}

Spring Boot is actually fucking awesome. If you think internal-usage methods are clean in any big framework you probably should work on that CS101 asstard.

shouldn't that be
if ((person?.Friends?.Count ?? 0) > 0)