You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by sebb <se...@gmail.com> on 2020/03/02 10:36:29 UTC
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
On Sat, 15 Feb 2020 at 11:51, Philippe Mouawad
<ph...@gmail.com> wrote:
>
> That might introduce issues in this case that will be hard to find.
> Does it silently default if it fails to bind to dll or does it break ?
JMeter is advertised as being 100% pure Java code.
Do we really wish to invalidate that?
Sebb.
> On Sat, Feb 15, 2020 at 12:44 PM Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
> > >Just wondering, why does it rely on jna ?
> >
> > I guess it is for
> > https://github.com/weisJ/darklaf/wiki/Features#native-window-decorations
> > (which is Windows-only for now)
> >
> > Vladimir
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 01.04.20 um 18:30 schrieb Antonio Gomes Rodrigues:
> Hi
>
> Good job, JMeter is much more beautiful now
>
> I have tested the last nighty in a fresh Ubuntu linux and I have two
> warnings when I launch JMeter
>
> Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
> WARNING: Could not create font Arial
> Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
> WARNING: Could not create font Arial
> Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
> WARNING: Could not create font Arial
> Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
> WARNING: Could not create font Arial
> Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
> WARNING: Could not create font Arial
> Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
> WARNING: Could not create font Arial
>
> I need to install Arial font with:
> sudo apt install ttf-mscorefonts-installer
>
> Gtk-Message: 17:25:36.748: Failed to load module "canberra-gtk-module"
> I need to insyall the module with:
> sudo apt install libcanberra-gtk-module
And only about one year later, we got rid of the warnings ;)
The svg had some references to the Arial font embedded, which it didn't
need.
Felix
>
>
>
> Le dim. 8 mars 2020 à 14:27, sebb <se...@gmail.com> a écrit :
>
>> On Thu, 5 Mar 2020 at 17:28, Vladimir Sitnikov
>> <si...@gmail.com> wrote:
>>>> Properties, XML, etc are not executed by the JVM; they are effectively
>>>> just data.
>>> BeanShell, JavaScript, and Groovy are not "just data", but it is code
>> which
>>> is a part of JMeter.
>>>
>>> So far I see no technical justification for requiring all transitive
>>> dependencies to be written in Java language only.
>> I'll try again.
>>
>> + The main reason is portability.
>>
>> Compiled Java source is portable to all systems that have a suitable JVM.
>>
>> Native code is inherently not portable.
>>
>> + Another reason is that compiled Java byte code cannot cause a JVM crash.
>> Native code can (and does) cause crashes, and these are generally very
>> difficult to debug.
>>
>> + A third reason is that Java source code only needs a JDK to compile it.
>> There is no need to install additional compilers.
>> Indeed you can compile the code on one OS and deploy on another.
>>
>> Native code usually means installing a C-compiler.
>> Unfortunately, there are lots of varieties of C-compilers with
>> incompatible options and syntax.
>> This make compiling native code rather difficult and error-prone
>> Also compilation generally has to be done on the same OS version.
>>
>> ===
>>
>> As far as JMeter is concerned, it is the first two reasons that are
>> most important.
>> The 3rd reason is of more concern to creators of distributions.
>>
>> ===
>>
>> Note that BeanShell, JavaScript (Rhino) and Groovy are themselves pure
>> Java - that is why the same jar can be used on all OSes.
>>
>> ===
>>
>> I hope you now understand what 100% Pure Java is about and why it is
>> important to JMeter?
>>
>>> Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
Hi
Good job, JMeter is much more beautiful now
I have tested the last nighty in a fresh Ubuntu linux and I have two
warnings when I launch JMeter
Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
WARNING: Could not create font Arial
Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
WARNING: Could not create font Arial
Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
WARNING: Could not create font Arial
Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
WARNING: Could not create font Arial
Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
WARNING: Could not create font Arial
Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
WARNING: Could not create font Arial
I need to install Arial font with:
sudo apt install ttf-mscorefonts-installer
Gtk-Message: 17:25:36.748: Failed to load module "canberra-gtk-module"
I need to insyall the module with:
sudo apt install libcanberra-gtk-module
Le dim. 8 mars 2020 à 14:27, sebb <se...@gmail.com> a écrit :
> On Thu, 5 Mar 2020 at 17:28, Vladimir Sitnikov
> <si...@gmail.com> wrote:
> >
> > >Properties, XML, etc are not executed by the JVM; they are effectively
> > >just data.
> >
> > BeanShell, JavaScript, and Groovy are not "just data", but it is code
> which
> > is a part of JMeter.
> >
> > So far I see no technical justification for requiring all transitive
> > dependencies to be written in Java language only.
>
> I'll try again.
>
> + The main reason is portability.
>
> Compiled Java source is portable to all systems that have a suitable JVM.
>
> Native code is inherently not portable.
>
> + Another reason is that compiled Java byte code cannot cause a JVM crash.
> Native code can (and does) cause crashes, and these are generally very
> difficult to debug.
>
> + A third reason is that Java source code only needs a JDK to compile it.
> There is no need to install additional compilers.
> Indeed you can compile the code on one OS and deploy on another.
>
> Native code usually means installing a C-compiler.
> Unfortunately, there are lots of varieties of C-compilers with
> incompatible options and syntax.
> This make compiling native code rather difficult and error-prone
> Also compilation generally has to be done on the same OS version.
>
> ===
>
> As far as JMeter is concerned, it is the first two reasons that are
> most important.
> The 3rd reason is of more concern to creators of distributions.
>
> ===
>
> Note that BeanShell, JavaScript (Rhino) and Groovy are themselves pure
> Java - that is why the same jar can be used on all OSes.
>
> ===
>
> I hope you now understand what 100% Pure Java is about and why it is
> important to JMeter?
>
> > Vladimir
>
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
Posted by sebb <se...@gmail.com>.
On Thu, 5 Mar 2020 at 17:28, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> >Properties, XML, etc are not executed by the JVM; they are effectively
> >just data.
>
> BeanShell, JavaScript, and Groovy are not "just data", but it is code which
> is a part of JMeter.
>
> So far I see no technical justification for requiring all transitive
> dependencies to be written in Java language only.
I'll try again.
+ The main reason is portability.
Compiled Java source is portable to all systems that have a suitable JVM.
Native code is inherently not portable.
+ Another reason is that compiled Java byte code cannot cause a JVM crash.
Native code can (and does) cause crashes, and these are generally very
difficult to debug.
+ A third reason is that Java source code only needs a JDK to compile it.
There is no need to install additional compilers.
Indeed you can compile the code on one OS and deploy on another.
Native code usually means installing a C-compiler.
Unfortunately, there are lots of varieties of C-compilers with
incompatible options and syntax.
This make compiling native code rather difficult and error-prone
Also compilation generally has to be done on the same OS version.
===
As far as JMeter is concerned, it is the first two reasons that are
most important.
The 3rd reason is of more concern to creators of distributions.
===
Note that BeanShell, JavaScript (Rhino) and Groovy are themselves pure
Java - that is why the same jar can be used on all OSes.
===
I hope you now understand what 100% Pure Java is about and why it is
important to JMeter?
> Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
Posted by Vladimir Sitnikov <si...@gmail.com>.
>Properties, XML, etc are not executed by the JVM; they are effectively
>just data.
BeanShell, JavaScript, and Groovy are not "just data", but it is code which
is a part of JMeter.
So far I see no technical justification for requiring all transitive
dependencies to be written in Java language only.
Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
Posted by sebb <se...@gmail.com>.
On Mon, 2 Mar 2020 at 14:09, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> >No, that's not exactly what 100% pure Java code means
>
> Pure Java means nothing.
> JMeter has lots of Properties, XML, XSLT, CSS, Groovy, BeanShell, and even,
> holy cow, JavaScript files.
>
> There's no point in making "100% pure X" without having a good definition
> of that.
>
Properties, XML, etc are not executed by the JVM; they are effectively
just data.
> >The Java code must of course comply with the appropriate Java language
>
> >Is Darklaf written entirely in Java?
> >Are all its dependencies written in Java?
>
> It is Java virtual machine compliant. Why does the language matter to you?
It does not matter, per se.
What matters is that JMeter is secure against crashing, and that it
will run on any system with a conforming JVM.
The JMeter jars contain Java byte code compiled from Java source files.
(Yes, there are properties and XML files, but these are not executable
by the JVM).
The JVM interprets the Java byte code, so is able to guarantee that it
will not cause a crash.
If the byte code is invalid, the JVM will throw an error at load time,
and similarly if there is a run-time error.
It can guarantee not to crash because it controls exactly how the JVMs
native code is invoked when processing the byte code.
Now the JVM also allows Java byte code to invoke native code in
external libraries.
It has no control over the content of such libraries, so cannot
guarantee that the are being called correctly.
Once you add external native code to a Java app, the JVM cannot prevent crashes.
Nor can one guarantee that the Java app will run on every conforming JVM.
> Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
Posted by Vladimir Sitnikov <si...@gmail.com>.
>No, that's not exactly what 100% pure Java code means
Pure Java means nothing.
JMeter has lots of Properties, XML, XSLT, CSS, Groovy, BeanShell, and even,
holy cow, JavaScript files.
There's no point in making "100% pure X" without having a good definition
of that.
>The Java code must of course comply with the appropriate Java language
>Is Darklaf written entirely in Java?
>Are all its dependencies written in Java?
It is Java virtual machine compliant. Why does the language matter to you?
Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
Posted by sebb <se...@gmail.com>.
On Mon, 2 Mar 2020 at 13:29, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> >Huh?
>
> Ok, so you mean Java specification.
No, that's not exactly what 100% pure Java code means.
The Java code must of course comply with the appropriate Java language
specification so it can be compiled.
But there is a further condition, which is that the code must only
rely on code that has itself been compiled from Java source.
i.e. all the code (apart from the JVM) is derived from Java source.
> In that sense, Darklaf follows the spec, and its code should be compatible
> with all Java virtual machines.
Is Darklaf written entirely in Java?
Are all its dependencies written in Java?
> Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
Posted by Vladimir Sitnikov <si...@gmail.com>.
>Huh?
Ok, so you mean Java specification.
In that sense, Darklaf follows the spec, and its code should be compatible
with all Java virtual machines.
Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
Posted by sebb <se...@gmail.com>.
On Mon, 2 Mar 2020 at 11:12, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> >Will JMeter remain 100% pure Java?
>
> Sorry, I don't understand the question.
> What do you mean by 100% Java?
Huh?
It means that the code is written entirely in Java.
This includes all libraries.
The only native code is in the JVM.
Advantages:
- if a JVM crash occurs, it must be due to a bug in the JVM.
It's not possible to directly cause a JVM crash from Java code except
by triggering a JVM bug.
- JMeter should work on all conforming JVMs.
There may be occasional issues if the code makes invalid assumptions
about the host OS, but in general the code should be portable to all
hosts that provide a suitable JVM.
Once native code is added, there are no guarantees: Java code can
cause a JVM crash if there is a bug in the native code.
Such crashes are generally very hard to debug.
Also native code may not be available for all hosts.
Generally 3rd party native code won't have had the same level of
testing as a JVM.
> >Are there really no standard LAFs that would suit JMeter?
>
> 1) Standard LAFs do not look and feel modern
> 2) No standard LAF has a dark scheme that might work better in the evening.
>
> Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
Posted by Vladimir Sitnikov <si...@gmail.com>.
>Will JMeter remain 100% pure Java?
Sorry, I don't understand the question.
What do you mean by 100% Java?
>Are there really no standard LAFs that would suit JMeter?
1) Standard LAFs do not look and feel modern
2) No standard LAF has a dark scheme that might work better in the evening.
Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
Posted by sebb <se...@gmail.com>.
On Mon, 2 Mar 2020 at 10:55, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> >JMeter is advertised as being 100% pure Java code.
>
> Darklaf has a native integration feature, however, it is optional.
>
What does that mean?
Will JMeter remain 100% pure Java?
> Currently, JMeter uses Darcula as a default look and feel now,
> there are multiple UI bugs in Darcula (e.g. tree indent is hard to see),
> Darcula has a single release only,
> nobody's going to fix Darcula issues in Darcula itself, because the code is
> just stale.
So why did JMeter switch to using Darcula?
> So I think we should drop Darcula theme completely, and migrate to Darklaf
> ( https://github.com/weisJ/darklaf ) or FlatLaf (
> https://github.com/JFormDesigner/FlatLaf )
>
> So far, Darklaf maintainer fixed all the JMeter-related LaF issues, and I
> think JMeter can just migrate to that LaF.
> The challenge for JMeter is that Darklaf uses **extensible** theming, so it
> is a single LaF with an ability to have multiple themes.
> JMeter's menu does not support that, and we probably need to configure that
> somehow (e.g. creating a submenu for themes).
That sounds like a lot of work, as well as extra complication for the user.
Are there really no standard LAFs that would suit JMeter?
Is it really necessary to use a 3rd party LAF that may or may not be
supported long-term?
> Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
Posted by Vladimir Sitnikov <si...@gmail.com>.
>JMeter is advertised as being 100% pure Java code.
Darklaf has a native integration feature, however, it is optional.
Currently, JMeter uses Darcula as a default look and feel now,
there are multiple UI bugs in Darcula (e.g. tree indent is hard to see),
Darcula has a single release only,
nobody's going to fix Darcula issues in Darcula itself, because the code is
just stale.
So I think we should drop Darcula theme completely, and migrate to Darklaf
( https://github.com/weisJ/darklaf ) or FlatLaf (
https://github.com/JFormDesigner/FlatLaf )
So far, Darklaf maintainer fixed all the JMeter-related LaF issues, and I
think JMeter can just migrate to that LaF.
The challenge for JMeter is that Darklaf uses **extensible** theming, so it
is a single LaF with an ability to have multiple themes.
JMeter's menu does not support that, and we probably need to configure that
somehow (e.g. creating a submenu for themes).
Vladimir