Fuck Java

That's because you rarely use the Integer class.

Most places won't let Pajeets near InfoSec. It may be the one area where there is an actual labor shortage because of how much they screw up.

rails
MEAN

shouldnt be using == instead of equals() to compare non-primitives anyway?
i suppose the real weakness in Java here is allowing the cached 0-127 ints to be effectively passed as a reference during auto-boxing, when assigned to a boxed variable so that they pass a comparison, but i don't really see this causing a problem (and if it does, the programmer who used a primitive comparator is at least partially to blame)

It's also the same in Python, where small integers are cached, but larger ones may not be. I'd assume the same in many other languages.

>shouldnt be using == instead of equals() to compare non-primitives anyway?
Yes, but he shouldn't be using boxed integers to begin with.

i work on an enterprise-scale system the backend is almost entirely Java and Integers are used in place of ints everywhere where classes communicate (even internally i.e, between methods). primitives are only used for small bits of logic and dont survive beyond that scope and that appears to be a conscious design choice, at least where i work

i think the motivation is to be consistent in only passing objects around, because they are more logger-friendly (i think?) and also (again not sure, but my intuition tells me this at least) easier for jboss or whatever middleware you're on to 'handle' because they all have Object methods. half talking out my ass here but it seems like boxed methods exist for a good reason, especially in larger scale systems

The reason you use Integer or other boxed primitives is
a) Data Objects that serialize to something like json, where a value can be null
b) Data Objects for storing in a database, where null values can also occur

Using Integer instead of int isn't bad, as long as you don't use it for math or create them in a loop

C# seems to have no problem with using primitives or bare metal strings in serialization. You can make an object with primitives and it's viable for any popular JSON parser library.

There's also a special notation for nullable primitives which also can be serialized.

That's nice but we're talking Java. Call me when C# comes close to Java in techempower.com/benchmarks/#section=test&runid=60fab9eb-a5ad-49cb-aefe-24ad0f377122&hw=ph&test=query

Blank strings vs null strings wew

Retarded boxed primitive comparisons aren't necessary for performance.

We were talking about Java and your input is basically
>but muh c# does it better
It's of no relevance

His input was that it can be done in a way that isn't retarded and java designers and java apologist pajeets are retarded for doing it in a way that has no benefits and only risks.

Meanwhile your input is pretty retarded - you try to argue against non-performance-related design choices by using performance as an argument.

Additionally, you have to use boxed primitives when using generic classes, unless the class explicitly provides primitive versions like IntStream.

I'll always see java to be retarded now.

The alternative is languages like python or JS where you only get access to boxed versions, which is horribly inefficient and requires the use of third party libraries like numpy to work around for data-heavy applications.

What do you use instead of Spring then?

>Most places won't let Pajeets near InfoSec
>Actually believing this

I work in infosec as a junior pentester and a lot of my colleagues are pajeets. In the conferences and events we attend, there's a lot of other pajeets from other security firms too. They aren't actually bad like Jow Forums pretends and know more than me as my manager has OSEE so he's clearly not fucking around in Bombay, but to say there aren't pajeets in infosec is a complete lie.

Pajeets are everywhere in IT. That is just a hard fact. The reason why you think there aren't any pajeets in infosec is because infosec roles aren't outsourced. That doesn't stop them just coming in locally...

Attached: 1526451399638.gif (200x250, 2.65M)

vert.x

hibernate

great bait

>benchmarksgame-team.pages.debian.net/benchmarksgame/faster/java-csharpcore.html
Done

start your own company, faggot. why would they hire some nobody that has no ambitions?

>throws Exception
>not handling all Throwables
fucking idiots

>vertx shill
>has to use over 9000 optimization flags
>github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/vertx/vertx.dockerfile
>still fails plain text
>techempower.com/benchmarks/previews/round16/#section=data-r16&hw=ph&test=plaintext

trends.builtwith.com/framework
Lmao @ urlife

At one point I used a Map to enable both String and Integer valued IDs to be mapped. I used Comparable as an arbitrary superclass of both, but in the end I could've chosen any other interface.

by that I mean any other they both implement.

why would you permit IDs of different types to begin with?

>implying you can reliably autocollect data on what backend framework is used for a piece of user-facing content
what a retard
builtwith.com/amazon.com
amazon is mostly java yet this useless website only lists php

That's because C# does the same thing as Java - it implicitly boxes and unboxes them. 'bare metal strings' don't exist in C#, they're a referential type. The reason why you use boxed Integers in Java is to avoid the overhead that comes with boxing and unboxing large amounts of integers during serialization.

C# literally works the same way. You're just too much of a pajeet to understand that syntax != semantics.

Pajeets are, by definition, outsourced. Indians that aren't outsourced workers are just normal dudes.

They are not boxed you retard

We're doing integration with multiple retarded legacy systems.

For data to be serialized in C#, it must have the SerializableAttribute attribute. Therefore it must an object. Therefore, any value types must be implicitly converted to reference types before they can be serialized. This is what boxing and unboxing *is*.

Literally go back to school, pajeet. This is basic shit.

>what is try catch

God you are retarded. ValueTypes ARE objects (i.e you can ToString) but they are not reference types unless you cast or assign them to "object" type which is a reference type hence it is boxed you idiot.
Do you also think List is boxed, pajeet?

[AttributeUsageAttribute(AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Enum | AttributeTargets.Delegate, Inherited = false)]
[ComVisibleAttribute(true)]
public sealed class SerializableAttribute : Attribute

begs to differ

what the fuck are you trying to say?

What an excellent thread. You're right OP we should move all enterprise systems to nodejs

RuntimeExceptions maybe? java exception hierarchy is messed up

declaring a method as throwing Throwable is a catastrophically stupid idea. declaring it as throwing a RuntimeException is also stupid and doesn't do anything

Yeah but that is probably what the other user meant by ">not handling all Throwables"

>declare anyone that can write decent code as "overqualified"
>Shit that never happens
>Coping this hard

This is why nobody likes whites.

there are better solutions you could have implemented

you put the throws clause on main so you dont have to try/catch in your fizzbuzz

stinky ugly shitskins