 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It seems to me that Oracle is doing their best to kill Java. One uses
Java 16 for "security" reasons and one uses Java 8 if one actually wants
the shit to work. (And Java 11 if you don't know which way to go, so
then you have neither).
I tried to light up my RenderFarm after, oh, 2 years off (already!).
https://www.buckosoft.com/bsac/meta/
I took me awhile to get it this far (just starting up without crashing)
because my basic java beans followed best practices from 5-10 years ago
and now that is verboten. And the best part was google didn't have
solutions to fix the brokenness, but it did have advice on how to get
Java to ignore the evil non-errors.
And so I'm stuck at my JDBC database connection doesn't work because it
needs SSL. Ugh. certs suck. I don't wanna add them to this flow.
Besides, since this is all one box, the private key and public key are
visible to both sides of the transaction, as well as anyone who breaks
into my computer. Encrypting the database on a localhost->localhost
connection helps nothing!
argh.
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Dick Balaska <dic### [at] buckosoft com> wrote:
> It seems to me that Oracle is doing their best to kill Java. One uses
> Java 16 for "security" reasons and one uses Java 8 if one actually wants
> the shit to work. (And Java 11 if you don't know which way to go, so
> then you have neither).
>
> I tried to light up my RenderFarm after, oh, 2 years off (already!).
> https://www.buckosoft.com/bsac/meta/
> I took me awhile to get it this far (just starting up without crashing)
> because my basic java beans followed best practices from 5-10 years ago
> and now that is verboten. And the best part was google didn't have
> solutions to fix the brokenness, but it did have advice on how to get
> Java to ignore the evil non-errors.
>
> And so I'm stuck at my JDBC database connection doesn't work because it
> needs SSL. Ugh. certs suck. I don't wanna add them to this flow.
> Besides, since this is all one box, the private key and public key are
> visible to both sides of the transaction, as well as anyone who breaks
> into my computer. Encrypting the database on a localhost->localhost
> connection helps nothing!
>
> argh.
maybe take it as "a sign" to start migrating?! ;-)
<https://www.developer.com/java/tcl-blend-makes-for-better-java/>
<https://www.tcl.tk/man/java1.1/Studio/studio.html>
(disclaimer: I don't use Java, so no 1st hand experience of the package(s))
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14.02.2022 22:13, Dick Balaska wrote:
> It seems to me that Oracle is doing their best to kill Java. One uses
> Java 16 for "security" reasons and one uses Java 8 if one actually wants
> the shit to work. (And Java 11 if you don't know which way to go, so
> then you have neither).
Oh never get me started on Java. If you want a real screwed up part, try
the accessibility layer, known as Java Access Bridge. On Windows up to
today it even has live-lock bugs on such simple functions as button
presses (reason: the call is synchronous and if the menu item or button
press displays a modal file dialog, you are locked out of accessing that
dialog because all communication tunnels through a single thread).
And documentation? Forget it. So for the record, Java isn't for the
disabled, and all existing screen readers use terrible hacks to somehow
work around all this. Honestly, how can this be in 2022? The liability
alone, especially in the US...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
