On JVMs with UTF-8 default encoding, this commit has no change in behavior.
On JVMs with ascii default encoding (like some minimal linux installa-
tions), this commit now uses UTF-8 for YamlConfiguration operations.
Because all ascii is valid UTF-8, there is no feature degradation or data
loss during the transition.
On JVMs with any non-unicode but ascii-compliant encoding, this commit now
forces YamlConfiguration to escape special characters when writing to
files, effectively rendering the encoding to be plain ascii. Any affected
file will now be able to migrate to UTF-8 in the future without data-loss
or explicit conversion. When reading files, YamlConfiguration will use the
system default encoding to handle any incoming non-utf8 data, with the
expectation that any newly written file is still compliant with the
system's default encoding.
On JVMs with any non-unicode, but ascii-incompliant encoding (this may be
the case for some Eastern character sets on Windows systems), this change
is breaking, but is justified in claim that these systems would otherwise
be unable to read YamlConfiguration for implementation dependent settings
or from plugins themselves. For these systems, all uses of the encoding
will be forced to use UTF-8 in all cases, and is effectively treated as if
it was configured to be UTF-8 by default.
On JVMs with unicode encoding of UTF-16 or UTF-32, the ability to load any
configurations from almost any source prior to this change would have been
unfeasible, if not impossible. As of this change, however, these systems
now behave as expected when writing or reading files. However, when
reading from any plugin jar, UTF-8 will be used, matching a super-majority
of plugin developer base and requirements for the plugin.yml.
Plugin developers may now mark their plugin as UTF-8 compliant, as
documented in the PluginDescriptionFile class. This change will cause the
appropriate APIs in JavaPlugin to ignore any system default encoding,
instead using a Reader with the UTF-8 encoding, effectively rendering the
jar system independent. This does not affect the aformentioned JVM
settings for reading and writing files.
To coincide with these changes, YamlConfiguration methods that utilize a
stream are now deprecated to encourage use of a more strict denotation.
File methods carry system-specific behaviors to prevent unncessary data
loss during the transitional phase, while Reader methods are now provided
that have a very well-defined encoder behavior. For the transition from
InputStream methods to Reader methods, an API has been added to JavaPlugin
to provide a Reader that matches the previous behavior as well as
compliance to the UTF-8 flag in the PluginDescriptionFile.
Addresses BUKKIT-314, BUKKIT-1466, BUKKIT-3377
By: Wesley Wolfe <wesley.d.wolfe+git@gmail.com>
This change drops the previous plugin data folder migration based on the
plugin's file name, and adapts the migration to now instead consider
plugins that have spaces in their original name.
By: Wesley Wolfe <weswolf@aol.com>
This change makes the lists of loadbefore, softdependency, and dependency
replace the spaces in the names with underscored to reflect the behavior
used with names.
By: Wesley Wolfe <weswolf@aol.com>
Currently, the only way to get a plugin is by name or using a static
variable. This adds two methods to get a plugin based on its classes,
utilizing the plugin classloader.
By: Wesley Wolfe <weswolf@aol.com>
This reverts commit ae4f1c05d825e232d7fc0483639ba65ad54d2db4, restoring
commit 27cb5e7c9c6b2cfc5419262df75d89bc6bfe7879 (mostly).
Shared class loading was removed as an explicit feature in the plugin.yml,
as all plugins implicitly share class loaders already.
Some deprecated, internal functionality is now (package) private, namely
some sections pointed out in 203de4180b40f069d2c175d763476bd4ce338c76.
By: Wesley Wolfe <weswolf@aol.com>
TimedRegisteredListener uses a reference to the first event fired. This
causes a memory leak in the server for any references that event has. This
changes TimedRegisteredListener to only store a reference to the class of
the event.
This change is intentionally a breaking change, as it is an obscure part
of the API. A non-breaking change would require the leak to be maintained
or an immediate update for any plugins using the method, as it would be an
indirect break.
A unit test is also included to check behavior of shared superclass
functionality.
By: Score_Under <seejay.11@gmail.com>
Permissions are stored as lower case names and referenced as such in all
appropriate methods but removePermission. This changes removePermission
to also convert names to lower case to be consistent with the rest of
the API.
By: Max A <maximilian.ammann@googlemail.com>
If the plugin.yml gets loaded but wasn't in the form of a map, the
server would crash. This safely checks to see if it can be cast,
throwing invalid description if it cannot.
By: Wesley Wolfe <weswolf@aol.com>
The warning message printed with the stack traces on the deprecated
methods mistakingly use the wrong method signature in the description.
By: Wesley Wolfe <weswolf@aol.com>
These methods are unnecessarily exposed. They are specific to a type of
implementation for the class loaders, and should have no external use.
Because these methods are exposed, it limits the versatility to change
how the internal class loading system works, including an inherent class
loader leak for some situations.
They are now replaced with internal, package-private methods. The public
facing methods will print a stack trace the first time one is activated.
Extending the classes also produces a stack trace, to indicate that
extension is not actively supported.
By: Wesley Wolfe <weswolf@aol.com>
These methods were never intended to be overwritten, and bukkit relies
on their internal functionality. Additionally, the methods were inlined
in JavaPlugin, but the finality maintains intention.
By: Wesley Wolfe <weswolf@aol.com>
CommandMap contains a method that will auto-complete commands
appropriately. Before the first space, it searches for commands of which
the sender has permission. After the first space, it delegates to the
individual command.
Vanilla commands contain implementations to mimic vanilla
implementation. Exception would be give, that allows for name matching;
a feature we already allowed as part of the command is now supported for
auto-complete as well.
Plugin commands can get a tab completer set to delegate the completion
for. If no tab completer is set, it can check the executor to see if it
implements the tab completion interface. It will also attempt to chain
calls if null gets returned from these interfaces. Plugins also
implement the new TabCompleter interface, to add ease-of-use for plugin
developers, similar to the onCommand() method.
The default command implementation simply searches for player names.
To help facilitate command completion, a utility class was added with
two functions. One checks two strings, to see if the specified string
starts with (ignoring case) the second. The other method uses the first
to selectively copy elements from one collection to another.
By: Score_Under <seejay.11@gmail.com>
When an exception occurs, the version of the plugin is not included.
Having this information would be beneficial to plugin authors performing
debug.
The list of authors for NagAuthorException verbose (although unused)
would be more appropriate to simply include all authors, as opposed to
the first appearing.
By: Wesley Wolfe <weswolf@aol.com>
This change lets JavaPluginLoader use a temporary HashSet to store
methods that could possibly have the EventHandler annotation. Duplicates
are prevented by the nature of a Set.
Registering parent listeners is a breaking change for any listener
extending another listener and expecting parent listeners to not be
called. Changing this is justified by the ease-of-use and proper object
inheritance design. If this is undesired behavior, the method may be
overridden without reapplying the method with the EventHandler notation.
By: Wesley Wolfe <weswolf@aol.com>
This metadata implementation has the following features:
- All metadata is lazy. Metadata values are not actually computed until another plugin requests them. Memory and CPU are conserved by not computing and storing unnecessary metadata values.
- All metadata is cached. Once a metadata value is computed its value is cached in the metadata store to prevent further unnecessary computation. An invalidation mechanism is provided to flush the cache and force recompilation of metadata values.
- All metadata is stored in basic data types. Convenience methods in the MetadataValue class allow for the conversion of metadata data types when possible. Restricting metadata to basic data types prevents the accidental linking of large object graphs into metadata. Metadata is persistent across the lifetime of the application and adding large object graphs would damage garbage collector performance.
- Metadata access is thread safe. Care has been taken to protect the internal data structures and access them in a thread safe manner.
- Metadata is exposed for all objects that descend from Entity, Block, and World. All Entity and World metadata is stored at the Server level and all Block metadata is stored at the World level.
- Metadata is NOT keyed on references to original objects - instead metadata is keyed off of unique fields within those objects. Doing this allows metadata to exist for blocks that are in chunks not currently in memory. Additionally, Player objects are keyed off of player name so that Player metadata remains consistent between logins.
- Metadata convenience methods have been added to all Entities, Players, Blocks, BlockStates, and World allowing direct access to an individual instance's metadata.
- Players and OfflinePlayers share a single metadata store, allowing player metadata to be manipulated regardless of the player's current online status.
By: rmichela <deltahat@gmail.com>
Removed internal collection leaks from PluginDescriptionFile
BREAKING: PluginDescriptionFile.getAuthors() now returns List instead of
ArrayList
Various places with unsafe generics, notably List<Object> getList() in
Configurations are now referenced as <?>. This is nonbreaking, but
sourcecode will need to be revised when compiled.
By: Wesley Wolfe <weswolf@aol.com>
