PeRV

It may sound weird, but even though these sorts of issues are controversial and the "whatever makes you happy" trope always seems tired, doing what actually makes you happy (even if it goes against a lot of the river's current) is solving a very important and complex problem within you. What's most awesome is that you found your thing. A lot of people never do. A lot of people are always too nervous to step into an uncomfortable zone as you were able to. Even though it took time, at least you had the treasure in the back of your mind and didn't let go after all these years. 'Now look at where you are! *Cheers*

@'Genusis': > […] the above code would be more efficient if you pre-created the buffer […] That's what any I/O stream class containing a flush method currently does. If you look into their fields (albeit "protected" access), you'll see one by the name of "buf" that is of _byte[][/i] type. But these things were already taken into account when base class abstraction classes were designed for streams. The only inefficiency of my class is probably everything coming in assumes by default to be a UTF8 string when that may not be the case always. Even so, nitpicking any of this is silly and a waste of time. I doubt anyone complaining about the implementation even cares to use this anyways (let alone even bother benchmarking some results). I made this library for people to create, not to complain (lol). Also: @'Dialectics': > Here's how you can convert a 32 bit integer into a byte array (big endian): > > byte[] byteArray = new byte[4]; > for (int i = 0; i < 4; i++) { > bytes _= (byte)(integerToConvert >>> (i * 8)); > } > > I don't know why you're being so picky with details when you didn't even bother to unroll an **n=4** for-loop. And don't even get me started on why you think we need cases for big endian and little endian; we're getting pretty tedious here. Also, why use multiplication for your **i*8** when you can just bitshift left by 3? All of this implementation counselling is a waste of our time. Micro optimizations will literally end you if you don't watch it–the mentality sucks the life out of developers who could otherwise be **actually spending their time making something; correctness first; efficiency second. > > –-Edit------------------------------** > On further thought, I am going to be changing this library to the name of "Pipo" and use an underlying ByteBuffer model to handle primitive data streaming. It'll still work with networking, but it will also work files and any other input and output accessible streams.__

@'Budweiser': > […] e.g. reflection? Is there a Java equivalent of Lidgren out there? I thought about it. I'm deciding on whether or not I should use serialization because then people can read objects and cast them to their class name. I'm still thinking though.

@'Dialectics': > These comments are cringe inducing. […] Then post them on some Stack Overflow cringe compilation… lol @'Dialectics': > Why are you […]? Just […]. I chose PrintWriter because it works as a nice sister class to BufferedReader. They both handle streams like line-by-line high level I/O. I guess I could push things in chunks as byte arrays, but the classes do that for me. Are you using this and noticing inefficiency? If so, then I'd also say that I should probably insert my own version of a lighter weight pseudo-TCP using UDP and efficient abstractions; otherwise, I feel like you're just pontificating. Please, show us some Java code that uses bit shifting and bitwise operations providing equally efficient abstraction at the level this class is. Yeah, it's possible, but **don't insult us by calling our comments "cringe."** On that defensive note, you're just being plain rude :D

@'Genusis': > […] The public everything idea is one reason why Java is red flagged as a huge security hole. […] I agree with this because it is definitely a form of **security through obscurity**. It'll save your ass more times than not. That's also why people always say (even Java coders) **composition over inheritance**. Composition requires that you yourself re-implement which methods should be exposed or even what should be visible in the first place.

@'pandacoder': > […] you should change […] I am familiar with Java coders and their obsession with the "public" keyword. When you stop using it as much and understand what kind of scope no access modifier gives you, not only does your code look less intimidating, but also: @'Marsh': > […] things are private for a reason. The class is used throughout your project. No package importing necessary since it defaults to package-private (default package). There's a reason why Java's default access modifier is not public, but nobody ever stops to ask why. I'd say it's because libraries made using no access modifier are lighter-weight and more casual on a per-project basis. It's like when your professor assigns a project where you use her helper class. You don't import a JAR necessarily. The simplest way is to just drop in their helper class' class file. If it has a package namespace, then you're going to import it. If not, you just start slinging away. The informalities are easier but less "corporate." @'pandacoder': > […] change your formatting so methods aren't starting on the same line as the end-bracket for the method before it in the code. I only do this for methods that are overloading each other. I could spread them out or put proper spacing in there, so I'll do that actually. They're still going to be back-to-back because it's part of this style guideline I follow, but I'll add more appropriate spacing because they'll be easier to read and plus it's also part of that same guideline.

I like what you're setting out to do here. I'm going to keep my eye on this thread and probably help alongside you if I'm around.

**DistributedSystem** ___________________________________________________________________ A childishly-simple system for sending and reading primitives ___________________________________________________________________ I made a very easy-to-use Java class that allows its users to communicate primitives across a network. Its as-is implementation is meant to work as a utility class and serve various purposes based on its innate flexibility (it's meant to be complete the way it is). Feel free to use and abuse it. The code is yours. I want this to help Java developers get their feet in the door with respect to online software development. Here is an example of how it could be used: ``` DistributedSystem server = new DistributedSystem(12345); server.send(123, 'a', "bc", true); ... DistributedSystem client = new DistributedSystem("69.420.619.42", 12345); int oneTwoThree = client.readInt(); char characterA = client.readChar(); String stringBC = client.readString(); boolean boolTru = client.readBoolean(); ``` Here is the GitHub page: * [github.com/piiearvi/DistributedSystem](https://github.com/piiearvi/DistributedSystem)