IMHO

[ghost]

@md-5 proved that he is good and i was wrong.

[md-5]

Do you care to improve it then? The code needs to be complicated because the protocol and functions are. Maybe you should teach me then, because clearly after years of java development I'm not yet up to your standards. Instead of saying it's shit give specific examples.

[md-5]

I'm going to ignore you from now on because you are clearly an arrogant arsehole who has no idea what he is doing. If you had actually worked in a professional dev environment you would know size does not matter.Bungee itself is about 200kb. All the libraries are for the use of plugins, I don't even use some. The first working bungee had no libraries and was 60kb, doesn't matter. Saying it's big doesn't mean it's bad, I've worked with enterprise servers that are 100mb+. you haven't even stated what you mean by overloaded, surely not method inheritance. Just because you aren't skilled enough to fully comprehend my code doesn't mean it's bad.

Good day to you

[LaxWasHere]

I know BB code.

[necrodoom]

considering all you say is "THIS CODE SUCKS" "MY CODE IS GOOD" and the fact you cant properly speak english makes me believe you came here for the purpose of trolling.

[fpigerre]

:+1: @necrodoom

[md-5]

I like, how you rage.

I am not raging at all, I am merely expressing my disbelief that someone such as yourself can come along and call my code terrible, without providing specific examples of how or why it is terrible.

It's more funny, when you say, that you worked with enterprise servers.

Can you please explain why that is funny? I don't see how real world development in a professional environment is funny.

If you want see good code, look on netty. This guys write simple and so good code.

You must be a very good judge of the code quality of netty, see your recent ticket: https://github.com/netty/netty/issues/1691. Furthermore I believe in your ticket you posted a piece of code pertaining to a game server proxy, to which all you do is forward received messages - and you think that achievement is anything comparable to what exists here in Bungee.

Ofcourse, not only size matters.

Size doesn't matter at all. Its not like we are writing so that our programs fit on punchcards and vacuum tubes. The libraries are there so that developers like that of Netty can produce better code for us that we do not have to maintain.

I wrote same API for server and i use only snakeyaml.

No, its not the same API. Take for example the fact that I include MySQL and SQLite libraries in Bungee. These are not used by Bungee, and take up several megabytes by themself, however they are included so that developers may create plugins making use of these libraries, without packaging them repeatedly in their own jars.

I am aren't skilled enough? 2 years in java and more i work

You have one small Bukkit plugin on GitHub, and your only other contributions are a bug report (more like a help me please) to Netty, and this ticket.

more i understand how bad write mojang and others.

All you seem to do is understand how bad my code is, and how bad 'others' code is. In this case my own code. As a Java developer of two years, it seems that all you can do is say other peoples code is good or bad, and provide no real basis for it. If you want to continue this discussion with me, please provide specific examples and code snippets of where my code is bad, and what can be done to improve it, and I will kindly take it into consideration.

[Homie20006]

/me dims the light for cinema atmosphere*

You talk about bad code and your awesomely much better coded programs. Its useless trying to demonstrate your cleverness without responding to md-5's posts with a bit of seriousness... -.-

[ryantheleach]

@ensirius it sounds like you do not understand the purpose of bungee.

Bungee is NOT a SIMPLE proxy, it is designed, so that to the Minecraft client, it is completely transparent that they are connecting to multiple servers.

It allows for clients to change servers, without kicking them, without dropping them, without client-side modifications, as well as adding an API, so things like multi-server chat and player-lists can continue to function.

[ghost]

@ryantheleach i all correctly understand ;)

[ammaraskar]

lol

[andrewphorn]

@ensirius Then perhaps stop saying that your program is the same and is just as complex, when it's quite clear that it is not. ;)

[md-5]

All my work are in private repositors. This code are from server to client. I currently dont need modify or do other stuff with packets from server. As i sayed, whole code are overloaded and for my personal usage, i rewrited it from 0 (This not means, i just cut out parts, which i just dont need) This thinks happens all time. I rewrited currently almost all except client. Maybe, my attitude more negative to mojang than you (Collisions Logic <3). Actually the packets do need to be modified, the entity IDs must be remapped to the original ones, otherwise strange behaviour may occur, and additionally you probably want to be able to provide APIs for stuff like chat and proxy side commands.

Since you won't point out where my code is bad, I'll point out where yours is: coming soon

[corin12355]

tl;dr @ensirius doesn't know what he's talking about and gets called out on it. Then trys to maintain damage control but fails badly.

lol 10/10 issue

[md-5]

Code Review of enLogger (https://github.com/Ensemplix/enLogger/)

• The author has put no less than 3 binary files in the libs/ folder. As this project is stored in a DVCS repository, this is not ideal behaviour. Instead a dependency resolving build system such as Maven should be used to allow consistent compilation and depend resolution, as well as allowing easy building of the project by users and continuous integration servers alike.
• The author has prefixed all class names with "en". This is incorrect for a number of reasons. Convention and Java specification dictates that class names should be entirely in CamelCase. Failure to do so may result in incorrect behaviour of IDEs and other build tools. As well as failing to meet casing standards, the use of "en" to prefix every class name leads to the so called Smurf naming convention. If every class has the same prefix, drop the prefix, it is just a useless waste of space.
• The interface enLogType, fails to conform to the implied guidelines of Java interfaces. In Java, every method in an interface is both abstract and public. Explicitly declaring the contained methods as such is a waste of time, and may lead to ambiguity, causing the code to look like it is part of abstract class, when it is in fact part of an interface.
• In the class enExecutor the author has seemingly reimplemented the helper methods present in java.util.concurrent.Executors. Additionally this reimplementation is very bad an inefficient for a number of reasons. The core pool size, as well as the max pool size are both set very low. Under high loads this may lead to resource starvation whereupon new jobs may not be able to be executed in a timely manner. Additionally the ExecutorService has a keep alive time of 0 seconds. This entirely defeats the purpose of using this class, as the result is no caching of created threads. Finally the author has set the internal queue used to be an ArrayBlockingQueue. Unless there is particular reasoning behind this, it is recommended that the ThreadPoolExecutor internal pool is that of a SynchronousQueue.
• In the main plugin class, enLogger, the author has provided a public field for access to a logging service. Unfortunately this field violates the Java convention that a Logger should be declared both static, and final. Additionally this field is a gets the logger entitled "Minecraft". This application is designed to run as a plugin for the popular Minecraft plugin container named Bukkit. Unfortunately the Bukkit API specification itself makes no guarantees about the existence of any logger named "Minecraft", the appropriate getter should be used instead. This brings up the next point. Each time a message is logged to the aforementioned logger, the message is manually concated to the prefix string "[enLogger]", this is redundant and messy, as the Bukkit API provides a builtin method to do this. In order to solve these two logging problems, the logger should be replaced with a reference to JavaPlugin.getLogger(). This has the guarantees that the logger will exist, and will automatically prepend the prefix.
• Also in the main plugin class, there is a method named addQueue. Quite simply this method is bloated and horrible. Instead of directly wrapping the method call in a Runnable which is then passed for execution, it is instead wrapped in a anonymous Callback of return type Void. This is a violation of the contract and general design of Callable. The result returned by the Callable.call method is meant to be usable. Void is not a usable type, and is present in the JVM to represent exactly this, a type with no instance. To make things worse, this callable is then wrapped in a FutureTask before being handed off for submission.
• This application makes no use of the built in Bukkit scheduling APIs. Standard Bukkit implementations are bundled with a highly optimized and tuned scheduler designed specifically to make cleanup after plugin disabling easy. Unfortunately this application bypasses the scheduler entirely. The application author should remove the addQueue method, and instead run an async task, enclosed in a Runnable via the Bukkit scheduler for maximum efficiency and code clarity.
• Error handling and catching is in general, poor. The try catch scopes used are too wide (catching Exception, as opposed to subtypes), and the handling of these errors is very limited. Some major examples of this include the enPropertyManager init() method. This method attempts to create and initialise a folder and configuration file should they not already exist. However it also silently catches and swallows any methods which are thrown in this initialisation process. Instead of then trying to recover or load default settings, it proceeds straight to try and read the initialised values. This leads to the obvious case, that if initial initialisation failed, then so will the actual reading of the values. My recommendation here is to abort loading of the application if configuration cannot be correctly initialised.
• Another example of poor error handling can be found in the class enDatabaseExecutor and its method, getConnection(). If this method encounters any errors at all in getting a connection, it catches and logs Exception, just like a Pokemon. Before promptly returning null. This now leads to the case that instead of catching a declared exception, the caller has to null check before performing any operations on a potentially unstable connection. In order to conform to proper API guidelines, the getConnection() method should declare SQLException as one of its thrown types, and let the caller deal with any cleanup and error handling that may result if a connection is unable to be retrieved.

This is just a small insight attempting to enlighten you about the comparatively poor quality of your publicly released code. Before attempting to attack the code of others, and claim many years of Java programming experience, I suggested you conduct a review of your own code and take this into account. If you have any disagreements about the comments I have made I suggest you bring them up with me. Additionally I suggest that you perform a small review similar to this one, on some of the classes present in my projects such as BungeeCord, so that I may get a better idea of what exactly is overloaded and bad. Thanks for your time in reading and considering this review. md_5

[ryantheleach]

Wow, If only getting free code reviews was this easy all the time.

[corin12355]

ruined

[lazertester]

Came here a bit too late, will eat popcorn anyway.

[fpigerre]

Umm no, now you're just denying stuff.

Also, I don't see how @md-5 's 'code review' can be crap, when it's written in proper english, by somebody who's been coding Java for 2+ years, and has published many successful plugins...

[md-5]

2) Provided code review crap. 3) Still, my code are better.

Can you please back up those two statements. I backed up mine with a code review, now back up both of yours.

[corin12355]

This is pure gold, you still have yet to prove that your masterrace code is best code. Yet you have the audacity to call something that multiple people worked hard on bad when you're not giving us anything to compare it against.

[BearWoolley]

If your code is so much better, then why did you remove your plugin from github? Surely if your code is better you would leave it.

[libraryaddict]

@ensirius you are my hero.

You put him in place with your cold hard calculated facts. You provided examples of your code explaining how his is inferior.

You provided a case where we could do nothing other then admit @md-5 needed to go back to school.

No wait. Nvrm. You just hid all your code and screamed he is a noob.

[corin12355]

@ensirius

[md-5]

Since you love the size of code so much, how about we have a code off? Smallest Minecraft server which responds to server list pings and kicks the player when they try to join wins. Jar must be executable with Java -jar myjarhere.jar Are you interested?

[libraryaddict]

@ensirius My mum is calling me to dinner. So you win this time!1!!11ONE

[ghost]

@md-5 lets try.

[corin12355]

This is going to be beautiful.

[TheReverend403]

_

[libraryaddict]

I think he went to bed.

[corin12355]

@ensirius He spoke about it in the CookieSlap development channel, pretty sure he finished it already.

[TheReverend403]

Yeah, he finished it about 5 minutes after he last posted here, and it works.

top lel.

[columb]

/me bookmarked @ensirius, you've made my summer.

[nvx]

Wow, @ensirius is giving SirSengir a run for his money for most retarded modder award.

I liked your code review @md-5 :)

[CrypticStorm]

That code review made me change half my code... At least it's better now.

[zSwayz]

This made me moist.

[andrewphorn]

@ensirius is my idol

I hope one day to write terrible code just like him.

[vemacs]

I lost ;_;

@md-5 The server list ping and kick reply can be the same, right? They're both 0xFF

[vemacs]

Looks like @ensirius lost.

FYI, for(;;){ is shorter than while(true){, and you can throws Exception instead of doing the try catch.

See lib's below response for some basic simplification.

[libraryaddict]

http://paste.md-5.net/tomixedomo.tex

[ryantheleach]

does MCSignOnDoor Count/Lose as well? https://forums.bukkit.org/threads/admin-mcsignondoor-1-9-so-your-server-can-say-gone-fishin-back-in-five.8814/

[andrewphorn]

@ensirius stop post

[vemacs]

Since the 0xFF response is a kick packet, I say that this meets the requirements. Without the s variable, it only works once, due to the socket not being closed. Thus, we can't fit the network on 1 line. Thanks to @ammaraskar for tips.

import java.net.*;

//thanks to ammar2 for initializer, and suggestion for base64 instead of hex
//md_5, i think this is somewhat of a recode of fakemcserver
//packets are still strings <3

class c {
    static {
        try {
            ServerSocket s = new ServerSocket(25565);
            for (;;)
                new java.io.DataOutputStream(s.accept().getOutputStream()).write(javax.xml.bind.DatatypeConverter.parseBase64Binary("/wAGAEgAaQCnADAApwAxADA="));
        } catch (Exception e) {
        }
    }
}

<ammar2> it will error at the end complaining about not having a main method but it will work

Minified:

import java.net.*;class c{static{try{ServerSocket s=new ServerSocket(25565);for(;;)new java.io.DataOutputStream(s.accept().getOutputStream()).write(javax.xml.bind.DatatypeConverter.parseBase64Binary("/wAGAEgAaQCnADAApwAxADA="));}catch(Exception e){}}}

Use /wAQAKcAMQAAADYAMQAAADEALgA1AAAAaABpAAAAMAAAADE= for the Base64 to have a modern protocol.

@ensirius Why'd you remove it?

[andrewphorn]

@ensirius or maybe it has to do with your incompetence. stop posting.

[ammaraskar]

lol

[vemacs]

lel

[ammaraskar]

@md-5 should just accept defeat at this point @ensirius has shown himself to be the better coder compared to md-5's shit code

Artistic depiction of this issue:

[treestompz]

@ensirius

[libraryaddict]

[andrewphorn]

@ensirius tell me more o master of code. while you're at it, stop posting.

[md-5]

At precisely 513 bytes when compiled (557 uncompiled), this is the best I can do:

.class S
.super java/lang/Object

.method public static main([Ljava/lang/String;)V
  .limit stack 3
  new java/net/ServerSocket
  dup
  sipush 25565
  invokespecial java/net/ServerSocket/<init>(I)V
  astore_0
  l:
   aload_0
   invokevirtual java/net/ServerSocket/accept()Ljava/net/Socket;
   invokevirtual java/net/Socket/getOutputStream()Ljava/io/OutputStream;
   ldc "/wAGAEgAaQCnADAApwAxADA="
   invokestatic javax/xml/bind/DatatypeConverter/parseBase64Binary(Ljava/lang/String;)[B
   invokevirtual java/io/OutputStream/write([B)V
   goto l
.end method