Re: Where to put driver JAR

[Richard Grin]

Window Services > Databases > Drivers.

New Driver... and add the jar of the MySQL driver; Driver class 
com.mysq.cj.jdbc.Driver (for version 8 of MySQL).


Le 02/11/2021 à 06:31, Greenberg, Gary a écrit :


Just got a new laptop and installed NB 12.5 on it.
Need to connect to mySQL (remote host).

I did run mysql-jconnect MSI file which suppose to install the driver 
on my box.


However Netbeans cannot find it.

I can extract JAR from MSI, but not sure where shall I drop it in the 
Netbeans installation.


Can someone please advise?

Thanks,

*Gary Greenberg*

Staff Software Engineer

Where to put driver JAR

[Greenberg, Gary]

Just got a new laptop and installed NB 12.5 on it.
Need to connect to mySQL (remote host).
I did run mysql-jconnect MSI file which suppose to install the driver on my box.
However Netbeans cannot find it.
I can extract JAR from MSI, but not sure where shall I drop it in the Netbeans 
installation.
Can someone please advise?
Thanks,
Gary Greenberg
Staff Software Engineer

Re: OT perhaps (better directed to Oracle?): Suggestions for improving checked exceptions in Java.

[Owen Thomas]

On Fri, 29 Oct 2021 at 11:48, Owen Thomas 
wrote:

> I say the following. Have an abstract checked exception class in the Java
> SE API. Call it, say, Checked*Managed*Exception. Descendents of this
> class behave like any other checked exception, with perhaps a few caveats
> [covered in the conversation we are having]...
>

Re: OT perhaps (better directed to Oracle?): Suggestions for improving checked exceptions in Java.

[Owen Thomas]

On Tue, 2 Nov 2021 at 06:35, Emilian Bold  wrote:

> It looks to me that the JVM doesn't have the concept of checked
> exceptions, only Java has. So, it may be valid bytecode to just rip out
> checked exception from the method signatures. New compilations, targeting a
> modified JAR, will not complain about the checked exception. At runtime
> they will be handled by the normal try-catch chain.
>
> Which is to say, bytecode processing may be sufficient. No need for
> language-wide changes.
>
> --emi
>

I think I understand that checked exceptions are only relevant to the Java
compiler; the "checking" is only performed by the compiler and the JVM
doesn't care about whether a calling method throws or catches checked
exceptions. This is, as I understand, why a language like Kotlin can omit
the feature from its compiler and call Java methods that throw checked
exceptions without problems. So, I think some small and contained changes
to the runtime might be appropriate, but the changes would not be too
invasive. The changes would be relevant only in the circumstance where a
Java module descriptor specifies which managed exceptions are thrown,
caught or ignored and so these changes would be backwards compatible.

I now think I prefer this "managed" term in place of "checked" because the
runtime environment doesn't care about checked exceptions, and I don't
think it a good idea to change this behaviour. Maybe the feature I am
describing would also be deemed fit to be appropriated by others like
Kotlin.

If a feature like this can garner broader support, I might even make it
official and look at how to apply through the JCP.

  Owen.


> On Mon, Nov 1, 2021 at 9:23 PM Alonso Del Arte 
> wrote:
>
>> > Might it be good to have a way to indicate to others that your module
>> can guarantee that checked exceptions have not been buried inside unchecked
>> ones?
>>
>> Okay, that might be good to know. We can certainly write that in the
>> Javadoc, but without a system like what you're proposing we would be on the
>> honor system.
>>
>> As you might know, Scala inventor Martin Odersky wrote the Java 1.3
>> compiler. Java was not evolving as fast as he wanted it to. He put a lot of
>> things into Scala that Java eventually adopted later, and some that will be
>> added to future versions of Java.
>>
>> But his approach was to make all exceptions unchecked, though you can add
>> an @throws annotation for the sake of interoperability with Java.
>> Clearly that's something Java will never adopt.Your idea of managed
>> exceptions seems likelier to be added.
>>
>> Suppose that Java 19 adds managed exceptions. What changes would an IDE
>> like NetBeans have to make in response to that?
>>
>> Al
>>
>> On Sun, Oct 31, 2021 at 11:22 PM Owen Thomas 
>> wrote:
>>
>>>
>>>
>>> On Mon, 1 Nov 2021 at 09:51, Alonso Del Arte 
>>> wrote:
>>>
 >  Although I do it often enough, I'm not a fan of wrapping a checked
 exception in a RuntimeException or even another checked exception like
 IOException.

 I'm not either. Nor do I like how AssertionError has a constructor
 that takes an Object rather than specifically a Throwable. But usually
 (though not always), a better way occurs to me during refactoring. I'm not
 sure I see the benefit of managed exceptions.

>>>
>>> Might it be good to have a way to indicate to others that your module
>>> can guarantee that checked exceptions have not been buried inside unchecked
>>> ones?
>>>
>>> I'm wondering if perhaps it might be good to generate a compile error in
>>> code that threw anything other than the type of managed exception that was
>>> indicated to be thrown in an associated module descriptor?
>>>
>>>   Owen.
>>>
>>
>>
>> --
>> Alonso del Arte
>> Author at SmashWords.com
>> 
>> Musician at ReverbNation.com 
>>
>

Re: OT perhaps (better directed to Oracle?): Suggestions for improving checked exceptions in Java.

[Emilian Bold]

It looks to me that the JVM doesn't have the concept of checked exceptions,
only Java has. So, it may be valid bytecode to just rip out checked
exception from the method signatures. New compilations, targeting a
modified JAR, will not complain about the checked exception. At runtime
they will be handled by the normal try-catch chain.

Which is to say, bytecode processing may be sufficient. No need for
language-wide changes.

--emi


On Mon, Nov 1, 2021 at 9:23 PM Alonso Del Arte 
wrote:

> > Might it be good to have a way to indicate to others that your module
> can guarantee that checked exceptions have not been buried inside unchecked
> ones?
>
> Okay, that might be good to know. We can certainly write that in the
> Javadoc, but without a system like what you're proposing we would be on the
> honor system.
>
> As you might know, Scala inventor Martin Odersky wrote the Java 1.3
> compiler. Java was not evolving as fast as he wanted it to. He put a lot of
> things into Scala that Java eventually adopted later, and some that will be
> added to future versions of Java.
>
> But his approach was to make all exceptions unchecked, though you can add
> an @throws annotation for the sake of interoperability with Java. Clearly
> that's something Java will never adopt.Your idea of managed exceptions
> seems likelier to be added.
>
> Suppose that Java 19 adds managed exceptions. What changes would an IDE
> like NetBeans have to make in response to that?
>
> Al
>
> On Sun, Oct 31, 2021 at 11:22 PM Owen Thomas 
> wrote:
>
>>
>>
>> On Mon, 1 Nov 2021 at 09:51, Alonso Del Arte 
>> wrote:
>>
>>> >  Although I do it often enough, I'm not a fan of wrapping a checked
>>> exception in a RuntimeException or even another checked exception like
>>> IOException.
>>>
>>> I'm not either. Nor do I like how AssertionError has a constructor that
>>> takes an Object rather than specifically a Throwable. But usually
>>> (though not always), a better way occurs to me during refactoring. I'm not
>>> sure I see the benefit of managed exceptions.
>>>
>>
>> Might it be good to have a way to indicate to others that your module can
>> guarantee that checked exceptions have not been buried inside unchecked
>> ones?
>>
>> I'm wondering if perhaps it might be good to generate a compile error in
>> code that threw anything other than the type of managed exception that was
>> indicated to be thrown in an associated module descriptor?
>>
>>   Owen.
>>
>
>
> --
> Alonso del Arte
> Author at SmashWords.com
> 
> Musician at ReverbNation.com 
>

Re: OT perhaps (better directed to Oracle?): Suggestions for improving checked exceptions in Java.

[Alonso Del Arte]

> Might it be good to have a way to indicate to others that your module can
guarantee that checked exceptions have not been buried inside unchecked
ones?

Okay, that might be good to know. We can certainly write that in the
Javadoc, but without a system like what you're proposing we would be on the
honor system.

As you might know, Scala inventor Martin Odersky wrote the Java 1.3
compiler. Java was not evolving as fast as he wanted it to. He put a lot of
things into Scala that Java eventually adopted later, and some that will be
added to future versions of Java.

But his approach was to make all exceptions unchecked, though you can add
an @throws annotation for the sake of interoperability with Java. Clearly
that's something Java will never adopt.Your idea of managed exceptions
seems likelier to be added.

Suppose that Java 19 adds managed exceptions. What changes would an IDE
like NetBeans have to make in response to that?

Al

On Sun, Oct 31, 2021 at 11:22 PM Owen Thomas 
wrote:

>
>
> On Mon, 1 Nov 2021 at 09:51, Alonso Del Arte 
> wrote:
>
>> >  Although I do it often enough, I'm not a fan of wrapping a checked
>> exception in a RuntimeException or even another checked exception like
>> IOException.
>>
>> I'm not either. Nor do I like how AssertionError has a constructor that
>> takes an Object rather than specifically a Throwable. But usually
>> (though not always), a better way occurs to me during refactoring. I'm not
>> sure I see the benefit of managed exceptions.
>>
>
> Might it be good to have a way to indicate to others that your module can
> guarantee that checked exceptions have not been buried inside unchecked
> ones?
>
> I'm wondering if perhaps it might be good to generate a compile error in
> code that threw anything other than the type of managed exception that was
> indicated to be thrown in an associated module descriptor?
>
>   Owen.
>


-- 
Alonso del Arte
Author at SmashWords.com

Musician at ReverbNation.com 

"Go to Type" & JDK class loading/decompilation anomaly

[Giles Winstanley]

Trying to examine source of JDK class (e.g. JTable), so bring up "Go to
Source" window, type name, and click OK. I have multiple Java Platforms
defined, each of which has its sources defined/attached as populated by
default Netbeans discovery on definition.

The first time I lookup a class in this way it seems to provide a
decompiled version. The second time and thereafter it provides the
version from source. I'm assuming this isn't the expected behaviour &
should be providing the source version first time, so either flagging
for developers, or wondering if I need to adjust my expectations of what
should be happening.

Note, this behaviour seems to happen irrespective of whether I've
specified a netbeans_jdkhome in netbeans.conf.

Netbeans 12.5, Adoptium JDK 16.0.2, macOS 10.14.6
Also installed: Adoptium JDK 17 (not defined in Netbeans), Adoptium JDK
11, Oracle JDK 1.8.0_301

Regards,
Stan


-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists