{"id":18691069,"url":"https://github.com/ffissore/brhconsole","last_synced_at":"2025-11-08T09:30:29.876Z","repository":{"id":145833394,"uuid":"1664732","full_name":"ffissore/BRHConsole","owner":"ffissore","description":"This was the java applet Blue Room Hosting used to connect via VNC to their virtual servers, open sourced when the company closed in 2010","archived":false,"fork":false,"pushed_at":"2011-04-26T12:17:07.000Z","size":188,"stargazers_count":2,"open_issues_count":0,"forks_count":1,"subscribers_count":3,"default_branch":"master","last_synced_at":"2024-12-28T02:43:37.604Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ffissore.png","metadata":{"files":{"readme":"README","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2011-04-26T12:15:38.000Z","updated_at":"2024-01-29T12:43:51.000Z","dependencies_parsed_at":"2023-03-23T03:30:05.460Z","dependency_job_id":null,"html_url":"https://github.com/ffissore/BRHConsole","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ffissore%2FBRHConsole","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ffissore%2FBRHConsole/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ffissore%2FBRHConsole/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ffissore%2FBRHConsole/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ffissore","download_url":"https://codeload.github.com/ffissore/BRHConsole/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":239550272,"owners_count":19657541,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-07T10:53:10.047Z","updated_at":"2025-11-08T09:30:29.826Z","avatar_url":"https://github.com/ffissore.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"  Blue Room Hosting Console\n\n======================================================================\n\nThis application is based on TightVNC.\n\nWhen compiling, it is necessary to have a copy of the cacerts used by\nthe server. This can be extracted from the compiled archive:\n\n    https://blueroomhosting.com/jars/BRHConsole.jar\n\n======================================================================\n\n  TightVNC Java Viewer version 1.3.9\n\n======================================================================\n\nThis distribution is based on the standard VNC source and includes new\nTightVNC-specific features and fixes, such as additional low-bandwidth\noptimizations, major GUI improvements, and more.\n\n\tCopyright (C) 1999 AT\u0026T Laboratories Cambridge.\n\tCopyright (C) 2000 Tridia Corp.\n\tCopyright (C) 2002-2003 RealVNC Ltd.\n\tCopyright (C) 2001-2004 HorizonLive.com, Inc.\n\tCopyright (C) 2000-2007 Constantin Kaplinsky\n\tCopyright (C) 2000-2007 TightVNC Group\n\tCopyright (C) 2008 RRD Labs Ltd\n\tAll rights reserved.\n\nThis software is distributed under the GNU General Public Licence as\npublished by the Free Software Foundation. See the file LICENCE.TXT for the\nconditions under which this software is made available. TightVNC also\ncontains code from other sources. See the Acknowledgements section below, and\nthe individual files for details of the conditions under which they are made\navailable.\n\n\nCompiling from the sources\n==========================\n\nTo compile all the .java files to .class files, simply do:\n\n\t% make all\n\nThis will also generate a JAR (Java archive) file containing all the classes. \nMost JVM (Java Virtual Machine) implementations are able to use either a set\nof .class files, or the JAR archive.\n\n\nInstallation\n============\n\nThere are three basic ways to use TightVNC Java viewer:\n\n  1. Running applet as part of TightVNC server installation.\n\n     Both the Unix and Windows versions of TightVNC servers include small\n     built-in HTTP server which can serve Java viewer to Web clients. This\n     enables easy Web access to the shared desktop without need to install\n     any software on the client computer. Unix and Windows versions of\n     TightVNC servers are different in the way they store the .class and .jar\n     files: the Unix server (Xvnc) is able to serve any set of files present\n     in a particular directory, while the Windows server (WinVNC) has all the\n     .class and .jar files inside the WinVNC executable file. Therefore, for\n     Xvnc, it's enough to copy the files into a correct directory, but for\n     WinVNC, the server binaries should be rebuild if the built-in Java\n     viewer should be updated.\n\n     To install the Java viewer under Xvnc, copy all the .class files, the\n     .jar file and the .vnc files to an installation directory (e.g.\n     /usr/local/vnc/classes):\n\n         cp *.class *.jar *.vnc /usr/local/vnc/classes\n\n     Also, make sure that the vncserver script is configured to point to the\n     installation directory (see the Xvnc manual page for the description of\n     the -httpd command-line option).\n\n  2. Running applet hosted on a standalone Web server.\n\n     Another possibility to use the Java viewer is to install it under a\n     fully-functional HTTP server such as Apache or IIS. Obviously, this\n     method requires running an HTTP server, and due to the Java security\n     restrictions, it's also required that the server should be installed on\n     the same machine which is running the TightVNC server. In this case,\n     installation is simply copying the .class and .jar files into a\n     directory that is under control of the HTTP server. Also, an HTML page\n     should be created which will act as a the base document for the viewer\n     applet (see an example named index.html in this distribution).\n\n     NOTE: Provided index.html page is an example only. Before using that\n     file, edit it with a text editor. See more information inside\n     index.html.\n\n  3. Running the viewer as a standalone application.\n\n     Finally, the Java viewer can be executed locally on the client machine,\n     but this method requires installation of either JRE (Java Runtime\n     Environment) or JDK (Java Development Kit). If all the .class files are\n     in the current directory, the Java viewer can be executed like this,\n     from the command line:\n\n         java VncViewer HOST vnchost PORT 5900\n\n     The parameters HOST and PORT are required, but there is a number of\n     optional parameters as well (see the Parameters section below).\n\nParameters\n==========\n\nTightVNC Java viewer supports a number of parameters allowing you to\ncustomize its behavior. Most parameters directly correspond to the settings\nfound in the Options window. However, there are parameters that do not\ncorrespond to those settings. For such parameters, you can see a note \"no GUI\nequivalent\", in the documentation below.\n\nParameters can be specified in one of the two ways, depending on how the Java\nviewer is used:\n\n  1. When the Java viewer is run as an applet (embedded within an HTML\n     document), parameters should be specified in the \u003cPARAM\u003e HTML tags,\n     within the appropriate \u003cAPPLET\u003e section. Here is an example:\n\n    \u003cAPPLET CODE=VncViewer.class ARCHIVE=VncViewer.jar WIDTH=400 HEIGHT=300\u003e\n      \u003cPARAM NAME=\"PORT\" VALUE=5901\u003e\n      \u003cPARAM NAME=\"Scaling factor\" VALUE=50\u003e\n    \u003c/APPLET\u003e\n\n  2. When run as a standalone application, the Java viewer reads parameters\n     from the command line. Command-line arguments should be specified in\n     pairs -- first goes parameter name, then parameter value. Here is a\n     command line example:\n\n     java VncViewer HOST vnchost PORT 5901 \"Scaling factor\" 50\n\nBoth parameter names and their values are case-insensitive. The only\nexception is the \"PASSWORD\" parameter, as VNC passwords are case-sensitive.\n\nHere is the complete list of parameters supported in TightVNC Java viewer:\n\n--\u003e \"HOST\" (no GUI equivalent)\n\n    Value: host name or IP address of the VNC server.\n    Default: in applet mode, the host from which the applet was loaded.\n\n    This parameter tells the viewer which server to connect to. It's not\n    needed in the applet mode, because default Java security policy allow\n    connections from applets to the only one host anyway, and that is the\n    host from which the applet was loaded. However, this parameter is\n    required if the viewer is used as a standalone application.\n\n--\u003e \"PORT\" (no GUI equivalent)\n\n    Value: TCP port number on the VNC server.\n    Default: none.\n\n    This parameter is required in all cases. Note that this port is not the\n    one used for HTTP connection from the browser, it is the port used for\n    RFB connection. Usually, VNC servers use ports 58xx for HTTP connections,\n    and ports 59xx for RFB connections. Thus, most likely, this parameter\n    should be set to something like 5900, 5901 etc.\n\n--\u003e \"PASSWORD\"\n\n    Value: session password in plain text.\n    Default: none, ask user.\n\n    DO NOT EVER USE THIS PARAMETER, unless you really know what you are\n    doing. It's extremely dangerous from the security point of view. When\n    this parameter is set, the viewer won't ever ask for a password.\n\n--\u003e \"ENCPASSWORD\"\n\n    Value: encrypted session password in hex-ascii.\n    Default: none, ask user.\n\n    The same as the \"PASSWORD\" parameter but DES-encrypted using a fixed key.\n    Its value should be represented in hex-ascii e.g. \"494015f9a35e8b22\".\n    This parameter has higher priority over the \"PASSWORD\" parameter. DO NOT\n    EVER USE THIS PARAMETER, unless you really know what you are doing. It's\n    extremely dangerous from the security point of view, and encryption does\n    not actually help here since the decryption key is always known.\n\n--\u003e \"Encoding\"\n\n    Values: \"Auto\", \"Raw\", \"RRE\", \"CoRRE\", \"Hextile\", \"ZRLE\", \"Zlib\", \"Tight\".\n    Default: \"Auto\".\n\n    The preferred encoding. If the value is \"Auto\", then the viewer will\n    continuously estimate average network throughput and request encodings\n    that are appropriate for current connection speed. \"Hextile\" is an\n    encoding that was designed for fast networks, while \"Tight\" is better\n    suited for low-bandwidth connections. From the other side, \"Tight\"\n    decoder in the TightVNC Java viewer seems to be more efficient than\n    \"Hextile\" decoder so it may be ok for fast networks too. \"ZRLE\" encoding\n    is similar to \"Tight\", but it does not support JPEG compression and\n    compression levels. Unlike \"Tight\" encoding, \"ZRLE\" is supported in\n    recent versions of RealVNC products. Other encodings are not efficient\n    and provided for compatibility reasons.\n\n--\u003e \"Compression level\"\n\n    Values: \"Default\", \"1\", \"2\", \"3\", \"4\", \"5\", \"6\", \"7\", \"8\", \"9\".\n    Default: \"Default\". ;-)\n\n    Use specified compression level for \"Tight\" and \"Zlib\" encodings. Level 1\n    uses minimum of CPU time on the server but achieves weak compression\n    ratios. Level 9 offers best compression but may be slow in terms of CPU\n    time consumption on the server side. Use high levels with very slow\n    network connections, and low levels when working over higher-speed\n    networks. The \"Default\" value means that the server's default compression\n    level should be used.\n\n--\u003e \"JPEG image quality\"\n\n    Values: \"JPEG off\", \"0\", \"1\", \"2\", \"3\", \"4\", \"5\", \"6\", \"7\", \"8\", \"9\".\n    Default: \"6\".\n\n    Use the specified image quality level in \"Tight\" encoding. Quality level\n    0 denotes bad image quality but very impressive compression ratios, while\n    level 9 offers very good image quality at lower compression ratios. If\n    the value is \"JPEG off\", the server will not use lossy JPEG compression\n    in \"Tight\" encoding.\n\n--\u003e \"Cursor shape updates\"\n\n    Values: \"Enable\", \"Ignore\", \"Disable\".\n    Default: \"Enable\".\n\n    Cursor shape updates is a protocol extension used to handle remote cursor\n    movements locally on the client side, saving bandwidth and eliminating\n    delays in mouse pointer movement. Note that current implementation of\n    cursor shape updates does not allow a client to track mouse cursor\n    position at the server side. This means that clients would not see mouse\n    cursor movements if mouse was moved either locally on the server, or by\n    another remote VNC client. Set this parameter to \"Disable\" if you always\n    want to see real cursor position on the remote side. Setting this option\n    to \"Ignore\" is similar to \"Enable\" but the remote cursor will not be\n    visible at all. This can be a reasonable setting if you don't care about\n    cursor shape and don't want to see two mouse cursors, one above another.\n\n--\u003e \"Use CopyRect\"\n\n    Values: \"Yes\", \"No\".\n    Default: \"Yes\".\n\n    The \"CopyRect\" encoding saves bandwidth and drawing time when parts of\n    the remote screen are moving around. Most likely, you don't want to\n    change this setting.\n\n--\u003e \"Restricted colors\"\n\n    Values: \"Yes\", \"No\".\n    Default: \"No\".\n\n    If set to \"No\", then 24-bit color format is used to represent pixel data. \n    If set to \"Yes\", then only 8 bits are used to represent each pixel. 8-bit\n    color format can save bandwidth, but colors may look very inaccurate.\n\n--\u003e \"Mouse buttons 2 and 3\"\n\n    Values: \"Normal\", \"Reversed\".\n    Default: \"Normal\".\n\n    If set to \"Reversed\", then right mouse button (button 2) will act as it\n    was middle mouse button (button 3), and vice versa.\n\n--\u003e \"View only\"\n\n    Values: \"Yes\", \"No\".\n    Default: \"No\".\n\n    If set to \"Yes\", then all keyboard and mouse events in the desktop window\n    will be silently ignored and will not be passed to the remote side.\n\n--\u003e \"Scale remote cursor\"\n\n    Values: \"No\", \"50%\", \"75%\", \"125%\", \"150%\".\n    Default: \"No\".\n\n    If a percentage value is specified, the remote cursor is reduced\n    or enlarged accordingly. Scaling takes place only when \"View only\"\n    is set to \"No\", and \"Cursor shape updates\" is set to \"Enable\".\n\n--\u003e \"Share desktop\"\n\n    Values: \"Yes\", \"No\".\n    Default: \"Yes\".\n\n    Share the connection with other clients on the same VNC server. The exact\n    behaviour in each case depends on the server configuration.\n\n--\u003e \"Open new window\" (no GUI equivalent, applicable only in the applet mode)\n\n    Values: \"Yes\", \"No\".\n    Default: \"No\".\n\n    Operate in a separate window. This makes possible resizing the desktop,\n    and adds scroll bars when necessary. If the server supports variable\n    desktop size, the window will resize automatically when remote desktop\n    size changes.\n\n--\u003e \"Scaling factor\" (no GUI equivalent)\n\n    Value: an integer in the range of [1..1000], or the string \"auto\".\n    Default: \"100\".\n\n    Scale local representation of the remote desktop. The value is\n    interpreted as scaling factor in percents. The default value of 100%\n    corresponds to the original framebuffer size. Values below 100 reduce\n    image size, values above 100 enlarge the image proportionally. If the\n    parameter is set to \"auto\", automatic scaling is performed. Auto-scaling\n    tries to choose scaling factor such way that the whole remote framebuffer\n    will fit on the local screen. Currently, auto-scaling is supported only\n    when the remote desktop is shown in a separate frame (always true in the\n    application mode, and also in the applet mode with \"Open new window\"\n    parameter set to \"yes\").\n\n--\u003e \"Show controls\" (no GUI equivalent)\n\n    Values: \"Yes\", \"No\".\n    Default: \"Yes\".\n\n    Set to \"No\" if you want to get rid of that button panel at the top.\n\n--\u003e \"Offer relogin\" (no GUI equivalent, not applicable in the applet mode)\n\n    Values: \"Yes\", \"No\".\n    Default: \"Yes\".\n\n    If set to \"No\", the buttons \"Login again\" and \"Close window\" won't be\n    shown on disconnects or after an error has occured.\n\n--\u003e \"Show offline desktop\" (no GUI equivalent)\n\n    Values: \"Yes\", \"No\".\n    Default: \"No\".\n\n    If set to \"Yes\", the viewer would continue to display desktop even\n    if the remote side has closed the connection. In this case, if the\n    button panel is enabled, then the \"Disconnect\" button would be\n    changed to \"Hide desktop\" after the connection is lost.\n\n--\u003e \"Defer screen updates\" (no GUI equivalent)\n\n    Value: time in milliseconds.\n    Default: \"20\".\n\n    When updating the desktop contents after receiving an update from server,\n    schedule repaint within the specified number of milliseconds. Small delay\n    helps to coalesce several small updates into one drawing operation,\n    improving CPU usage. Set this parameter to 0 to disable deferred updates.\n\n--\u003e \"Defer cursor updates\" (no GUI equivalent)\n\n    Value: time in milliseconds.\n    Default: \"10\".\n\n    When updating the desktop after moving the mouse, schedule repaint within\n    the specified number of milliseconds. This setting makes sense only when\n    \"Cursor shape updates\" parameter is set to \"Enable\". Small delay helps to\n    coalesce several small updates into one drawing operation, improving CPU\n    usage. Set this parameter to 0 to disable deferred cursor updates.\n\n--\u003e \"Defer update requests\" (no GUI equivalent)\n\n    Value: time in milliseconds.\n    Default: \"50\".\n\n    After processing an update received from server, wait for the specified\n    number of milliseconds before requesting next screen update. Such delay\n    will end immediately on every mouse or keyboard event if not in the \"view\n    only\" mode. Small delay helps the server to coalesce several small\n    updates into one framebuffer update, improving both bandwidth and CPU\n    usage. Increasing the parameter value does not affect responsiveness on\n    mouse and keyboard events, but causes delays in updating the screen when\n    there is no mouse and keyboard activity on the client side.\n\n--\u003e \"SocketFactory\" (no GUI equivalent)\n\n    Value: name of the class.\n    Default: none.\n\n    This option provides the way to define an alternate I/O implementation.\n    The dynamically referenced class must implement a SocketFactory\n    interface, and create a Socket, as configured by this parameter. See the\n    source in SocketFactory.java.\n\n\nRECORDING VNC SESSIONS\n======================\n\nCurrent version of the TightVNC Java viewer is able to record VNC (RFB)\nsessions in files for later playback. The data format in saved session files\nis compatible with the rfbproxy program written by Tim Waugh. Most important\nthing about session recording is that it's supported only if Java security\nmanager allows access to local filesystem. Typically, it would not work for\nunsigned applets. To use this feature, either use TightVNC Java viewer as a\nstandalone application (Java Runtime Environment or Java Development Kit\nshould be installed), or as a signed applet. The code checks if it's possible\nto support session recording, and if everything's fine, the new \"Record\"\nbutton should appear in the button panel. Pressing this button opens new\nwindow which controls session recording. The GUI is pretty self-explained.\n\nOther important facts about session recording:\n\n--\u003e All sessions are recorded in the 24-bit color format. If you use\n    restricted colors (8-bit format), it will be temporarly switched to\n    24-bit mode during session recording.\n\n--\u003e All sessions are recorded with cursor shape updates turned off. This is\n    necessary to represent remote cursor movements in recorded sessions.\n\n--\u003e Closing and re-opening the recording control window does not affect the\n    recording. It's not necessary to keep that window open during recording a\n    session.\n\n--\u003e Avoid using Zlib and ZRLE encodings when recording sessions. If you have\n    started recording BEFORE opening a VNC session, then you are ok. But\n    otherwise, all Zlib-encoded updates will be saved Raw-encoded (that is,\n    without compression at all). The case with ZRLE is even worse -- ZRLE\n    updates will not be saved at all, so the resulting session file may be\n    corrupted. Zlib decoding depends on the pixel data received earlier, thus\n    saving the data received from the server at an arbitrary moment is not\n    sufficient to decompress it correctly. And there is no way to tell Zlib\n    or ZRLE decoder to reset decompressor's state -- that's a limitation of\n    these encoders. The viewer could re-compress raw pixel data again before\n    saving Zlib-encoded sessions, but unfortunately Java API does not allow\n    to flush zlib data streams making it impossible to save Zlib-encoded RFB\n    pixel data without using native code.\n\n--\u003e Usually, Tight encoding is the most suitable one for session recording,\n    but some of the issues described above for the Zlib encoding affect the\n    Tight encoding as well. Unlike Zlib sessions, Tight-encoded sessions are\n    always saved Tight-encoded, but the viewer has to re-compress parts of\n    data to synchronize encoder's and decoder's zlib streams. And, due to\n    Java zlib API limitations, zlib streams' states have to be reset on each\n    compressed rectangle, causing compression ratios to be lower than in the\n    original VNC session. If you want to achieve the best possible\n    performance, turn recording on BEFORE connecting to the VNC server,\n    otherwise CPU usage and compression ratios may be notably less efficient.\n\n\nHINTS\n=====\n\n--\u003e To refresh remote desktop in the view-only mode, press \"r\" or \"R\"\n    on the keyboard.\n\n\nACKNOWLEDGEMENTS\n================\n\nThis distribution contains Java DES software by Dave Zimmerman\n\u003cdzimm@widget.com\u003e and Jef Poskanzer \u003cjef@acme.com\u003e.  This is:\n\n    Copyright (c) 1996 Widget Workshop, Inc. All Rights Reserved.\n\n    Permission to use, copy, modify, and distribute this software and its\n    documentation for NON-COMMERCIAL or COMMERCIAL purposes and without fee\n    is hereby granted, provided that this copyright notice is kept intact.\n    \n    WIDGET WORKSHOP MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE\n    SUITABILITY OF THE SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING BUT\n    NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A\n    PARTICULAR PURPOSE, OR NON-INFRINGEMENT. WIDGET WORKSHOP SHALL NOT BE\n    LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING,\n    MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES.\n    \n    THIS SOFTWARE IS NOT DESIGNED OR INTENDED FOR USE OR RESALE AS ON-LINE\n    CONTROL EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE\n    PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT\n    NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE\n    SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF THE\n    SOFTWARE COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR SEVERE\n    PHYSICAL OR ENVIRONMENTAL DAMAGE (\"HIGH RISK ACTIVITIES\").  WIDGET\n    WORKSHOP SPECIFICALLY DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY OF\n    FITNESS FOR HIGH RISK ACTIVITIES.\n\n    Copyright (C) 1996 by Jef Poskanzer \u003cjef@acme.com\u003e.  All rights\n    reserved.\n\n    Redistribution and use in source and binary forms, with or without\n    modification, are permitted provided that the following conditions\n    are met:\n    1. Redistributions of source code must retain the above copyright\n       notice, this list of conditions and the following disclaimer.\n    2. Redistributions in binary form must reproduce the above copyright\n       notice, this list of conditions and the following disclaimer in the\n       documentation and/or other materials provided with the distribution.\n\n    THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND\n    ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE\n    IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR\n    PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS\n    BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR\n    CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF\n    SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR\n    BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,\n    WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR\n    OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF\n    ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.\n\n    Visit the ACME Labs Java page for up-to-date versions of this and other\n    fine Java utilities: http://www.acme.com/java/\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fffissore%2Fbrhconsole","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fffissore%2Fbrhconsole","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fffissore%2Fbrhconsole/lists"}