Plugin development support for C++ and Java/JavaScript

There should be support for C++ Java and JavaScript for coding plugins with C++ it would be like this int getEconomyAPI and for Java and JavaScript it would be different and since MCPE was coded in C++ and other people are good with other coding languages except not php

Plugins can only be written in the language the software is written in. PocketMine is written in PHp, therefore plugins must be written in php. If you want to make Java plugins, use Nukkit, C# plugins for MiNET or whatever other software you desire.

And why are you making Java snd Javascript sound like they are related in some way? They are are totally different languages used for different things.

I never said they were the same

He never said that you said that they're the same.

You are sounding like they're the same. Java and JavaScript are completely different to each other.

It is possible. My concept is like this (I am more familiar with Java within the other languages mentioned, so I will use Java as example):

• PocketMine-end plugin loader (you can register new plugin loaders in PocketMine like DevTools) (I will call it PHP End in the future) starts a Java process (I call it Java End).
• When a Java plugin should be loaded, the PHP End, through a stdin pipe, sends a signal to the Java End.
• The Java End should expose API methods in Java prototypes. To implement these methods, use the stdout pipe to send a signal to the PHP End.
• The PHP End can use the stdin pipe to send signals to the Java End to trigger certain methods, such as PluginBase:nCommand(), event handlers, etc.

But when I read again what I wrote, it seems like that you would simply make the server more laggy if you do it this way. All those signal sending processes may slightly to vigorously increase server load, unless it is done in a separate thread. But in this way, it won't be able to do un-delay-able things like cancelling events. Though, there is also a way to overcome them - say, if you want to cancel an EntityDamageEvent, it mightn't hurt to cancel it first then fire it again (and implement what would happen if it is not cancelled). Or would it? This greatly depends. Overall, it is not a good idea to create a Java bridge with this method.