Drop To Frame sometimes disabled, sometimes not - java

I often use the Eclipse Debgugging function Drop To Frame, but sometimes it is not available when debugging. I found another question on SO and an Eclipse Help entry, which says:
Note this command is only available if the current VM supports drop to frame and the selected stackframe is not the top frame or a frame in a native method.
My problem is, while debugging the same function (its not the top stack frame, and neither it or its parent is a native method - though there is one 3 levels higher) I sometimes find that Drop to Frame is enabled and I sometimes find it is disabled.
Do you know any more limitations to Drop To Frame, which could be a reason for it not being available? Note: I use the same JVM all the time, and I can't quite imagine it sometimes supports Drop To Frame and sometimes it doesn't.

In case someone has the same problem: Since we switched from an earlier Eclipse Version (I think Luna) to Neon, the problem doesn't occur anymore. Maybe it was a bug that was fixed in newer Eclipse versions and only occured from time to time.

Related

The cursor randomly disappears in Eclipse 2019-09 and sometimes stops writing

I have a very annoying problem with Eclipse 2019-09 (4.13.0) version: while I'm editing code (often when I copy and paste things or after accepting a code completion suggestion) the cursor (I'm talking about the text cursor: |) disappears completely! I cannot see it anymore, so I'm not able to detect on which part of the line I am! This is very annoying. I found a partial fix by installing the extension 'Vrapper': enabling and disabling it makes the cursor appear again.
Another problem I experience every time I press Ctrl+Space to ask for code completion suggestions, the cursor stops writing. After doing random things like switching tabs or opening new files the cursor starts to write again, but then the keyboard shortcuts stop working and I have to restart the entire IDE.
This behavior is intolerable, so I was wondering whether somebody else has had the same problem and how they have dealt with it.
The configuration of my system is:
OS: Debian, using i3wm+compton as a window manager on Xserver.
Thanks in advance.
Dead place, but I'm currently dealing with the same. The weird thing is that it happens on a per-file basis. Eclipse also treats that file as if it was not open, i.e. I can only save it through the 'Save all' method, not Ctrl-S ('Save') as I usually do. It's hellishly annoying, but it usually is fixed by reopening the file in question, and editing other files between the closing and reopening of other files.
If you have a better answer than this that you've found since, please, please post it here. It's annoying as all hell.
Minimize eclipse and maximize again.
Happened to me on Eclipse 2022-09 (4.25.0).

Lot of issues with Eclipse mars and java-openjdk8 under ubuntu 16.04

Are there any known issues regarding Eclipse Mars (4.5.2) under Ubuntu Mate 16.04 and java-openjdk8?
-Since upgrade, the GUI is responding VERY slow (a real handicap so far, taking away all the coding fun)..
To be more specific, for example, any hover mouse-action does not work unless waiting several time with cursor on the text.
-And the console does not update itself sometimes.. Which mean, if i run, i have to change the view and change it back (e.g. click on 'snippets'-tab and then on 'console' again.
-If the console print any links to classes (e.g. in error-logs) They do not work until i change the view again (which means click on the link-->click on the tab 'snippets'. Then the linked class gets opened.
It's so strange that i think of downgrade again (ubuntu15.10, java-openjdk7) But i also upgraded to android studio 2.1 which needs java8 jdk..
Edit:
Codecompletion does not work. I wonder wtf? Simply nothing works.
All issues are temporary thus not to reproduce or to describe more detailed.. Its very very unstable.
Did i miss something? Is some of the listed software incompatible?
Most of the problems due to new GTK3 library/default theme used. Switch to GTK2 will resolve the problems. See this bug.
How to force eclipse to use GTK2

What is the difference between JRE options java.awt.headless and java.awt.headlesslib?

I have used the former many times (-Djava.awt.headless=true) in order to prevent the infamous "no DISPLAY found" error for some applications which used some graphics methods in the JRE.
But since then I have also learned of the existence of the second one. In spite of hours of searching around, I cannot find a difference between both.
And to make matters worse, I am no GUI expert at all... So, is there an actual difference? What code would work with one and not the other, or would require both etc?
java.awt.headlesslib is part of a temporary workaround added in 2001 in response of bug JDK-4407772.
If you download the source code of openjdk6, openjdk7 or openjdk8 and grep all the source files looking for java.awt.headlesslib you will see no results.
So the effect of setting java.awt.headlesslib is null and the effect of setting java.awt.headless is to activate the headless mode.

Sporadic GUI freeze on the (java) application start

we have a strange problem with our GUI after changing to Java 1.7.
Sometimes if the user starts our Application it seems to be freezed, but probably there is just no repaint, because if user tries for example to scroll, changes the window and comes back to application the scroll changes are visible.
And the problem will be solved if the users change to fullscreen.
I tried to search for this problem, but the only thing most related to it was an unanswered question here:
http://www.java-forums.org/awt-swing/31107-intermittent-freeze-javawebstart-swing-app.html
May be anyone of you had the problem and know the solution?
The migration to Java 7 may have exposed a latent problem in the original code. Here are some things to look at:
Some APIs, especially among the text components listed here, are no longer marked thread safe in Java 7.
You can search for EDT violations using one of the approaches cited here.
Resizing the enclosing Window generates an automatic repaint(); if your updates are otherwise correctly synchronized, you can sequence your own repaint() using invokeLater().
Verify that setVisible() is last in your initialization, after pack().

Java Applet fail / disappear when another frame is reloaded in IE10

Does anyone face this problem?
Applet disappear when another frame is reloaded in IE10.
I found a related bug report in Java bug Database
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193503
Any other solutions beside trigger repaint()?
By the way, how to vote the bug in Java Bug Database?
Any other solutions beside trigger repaint()?
3 posibilities jump to mind.
Launch the applet free-floating using Java Web Start.
Don't use frames.
Use an earlier version of IE, or a different UA.
By the way, how to vote the bug in Java Bug Database?
Step one is to join the OTN. Note that OTN members have complained about not being able to access the bug DB.
I have tried to trigger repaint() which still cannot solve the problem.
I think the components positions in applet are wrong after the frame is reloaded.
The workaround is resize the window by Javascript call.

Categories