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>
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>
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>
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>
Soft dependencies allow plugins to request to be loaded after another plugin, but they will not throw an UnknownDependency exception if the other plugin is not present.
By: Raphfrk <raphfrk@gmail.com>
This now uses an annoymous class implementing IExecutor that facilitates direct event method handler calling
Changed commands from being executed exclusively by a player to by a CommandSender to facilitate external command callers such as rcon
Fixed CustomEventListener
Merged in additional events
Added getFullName to PluginDescriptionFile which returns the combination of Name and Version
There's also a few bits of reformatting as it seems someones been editing with either tabs or dos eol :(
By: stevenh <steven.hartland@multiplay.co.uk>
