richard | 4 Sep 20:33 2015

Trying out the new JDEE


I've just grabbed this from git with a few to trying it out
and possibly contributing subject to need / time / whatever.

I've noticed a few glitches:

1. Line 71 in jdee-imenu.el contains the following:
    ("static"        . ?§)              ; §

When I load JDEE on my system, it fails with the error 
load-with-code-conversion: Invalid read syntax: "?" I think it's
a charset problem but I'm not sure what's supposed to be here.
Commenting it out makes JDEE load file

2. Cask isn't listed as a dependency. Since the makefile doesn't
work without it, I'm guessing it should be.

3. If I open a simple Java file from my home dir it tries sucking
up the entire tree as a classpath. This takes forever and seems a
bit silly. I tried adding some system.out/err messages to the code
to troubleshoot it but the messages didn't appear in the *Messages*
buffer. I can't see where in the code is the bit that makes this
work. Any pointers?



(Continue reading)

Sudong Lei | 3 Sep 03:51 2015

about bsh classpath

sorry for my poor english.
when I use jdee git version, copy jdee-bundle.jar to my jdee-server-dir, M-x jdee-compile,it poped a message "java.lang.ClassNotFoundException:", then I copy tools.jar from jdk lib dir to jdee-server-dir, it work fine; but I compare the "jdee-bsh.el" file between version 2.4.1 and git version, I found out that in version 2.4.1, method bsh-launch set jdee-global-classpath and several paths to cp and git version just set the jar files in jdee-server-dir to cp.
now, I don't know which way is better(modify jdee-bsh.el to add more paths to cp or just copy tools.jar to jdee-server-dir)
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
jdee-devel mailing list
jdee-devel <at>
Przemysław Wojnowski | 24 Aug 21:24 2015

Purpose of which.el

Hello everybody,

Anyone knows what is the purpose of which.el?

AFAIK it is not used and can be removed.


jdee-devel mailing list
jdee-devel <at>
Przemysław Wojnowski | 24 Aug 11:49 2015

Recent changes

Hello everybody,

Recently I did a couple of updates to move JDEE to MELPA:
1. Renamed every "jde" to "jdee" match project name and packaging naming 
conventions (rules?).
This means that if you've got an old config with "jde" vars you'll have 
to rename them to "jdee".
Nobody has implemented auto conversion. Sorry. :-)

2. jdee-server-dir is required to have support from JVM side.
The jar from jdee/jdee-server have to be copied to some directory and 
jdee-server-dir should point to it (the dir).
If it is unset then user will see a message on the first call to JVM 

3. Since we're on melpa, we can use other packages.

4. We can work on other things in parallel.


jdee-devel mailing list
jdee-devel <at>
Lee Hinman | 18 Aug 23:32 2015

Re: Proposed New Structure (starter for 10)

Re-added the jdee-devel list

Phillip Lord writes:

> Lee Hinman <leehinman <at>> writes:
>> This looks neat to me, and I'm interested in contributing. What's the
>> best place to start with this? (Assuming this is adopted)
> The roadblock for me at the moment is understanding mvn. If you have
> any time to research this, it would be appreciated. In particular, how
> to add dependencies or plugins without changing the pom.
> Phil

So I looked into this briefly, it looks like this can be added to
${user.home}/.m2/settings.xml, specifically, one can specify plugin
groups with:


The docs say: "This element contains a list of pluginGroup elements,
each contains a groupId. The list is searched when a plugin is used and
the groupId is not provided in the command line."

So if we provided a jdee-mvn plugin and added the groupId here, someone
could use

mvn jde:jack-in (or whatever it is called)

And it would search the `org.jdee.plugin` groupId for the plugin.

There is also a "pluginRepositories" element that can be used to add a
repository for downloading plugins, which I could see as being useful
for providing the plugin for download somewhere.



;; Lee

Lee Hinman | 16 Aug 20:03 2015

Where to contribute?

Hi All,

So, I'd like to contribute to jdee, but with the latest discussion, I'm
slightly confused on where to focus my efforts. I see there are a few
different options:

- jdee master branch (on Github)
- jdee "cask" branch (based on the recent jdee-devel discussion)
- jde-with-clojure-backend (

Where's the best place to contribute to?


;; Lee

Phillip Lord | 14 Aug 18:51 2015

Proposed New Structure (starter for 10)

So, I wanted to put some meat onto the bone of my proposed new
structure for JDEE.

It doesn't work yet, of course, but I think that it can in a relatively
short space of time.

The four components are:

jde -- this will be the Java centric major mode. It will involve NO JVM
interaction and not depend on any of the other parts. The "minimal
viable product" here is a ELPA packaged major mode that is a child of
Java mode and adds no functionality.

jde-interactive (crappy name, sorry) -- a minor mode which will be
active once the JVM (bsh interpreter equivalent) has been started and is
running. In the short term, this will have a dependency on cider, but
eventually this may just become a dependency on nrepl-client.el. I say
may, because, I think quite a bit of the cider functionality (like the
inspector) is JVM centric and entirely relevant.

The MVP here is to use maven inside a project to launch an nrepl, and
then to invoke a call to get the version number of the jde-nrepl
middleware and check that it is consistent with the version of jde-interactive.

jde-nrepl -- this is the nrepl middleware that provides all the backend
functionality, like class look up and the like. The MVP here is to
install some middleware into a nrepl, which returns a version map for
checking my jde-interactive, and which is packaged as a maven dependency
on clojars.

jdee-sample -- this is a sample project. Requirements in the short term
are that the project depend on jde-nrepl and to provide the nrepl
functionality we need. Typing "maven jde:nrepl" or equivalent should
result in a nrepl session.

MVP having a packaged jde-interactive that can install, that starts when
we open "" in jdee-sample, and which can then invoke a method of
the class object coming from

In the long term, I would expect that all four of these would be
separate repos.

That's the idea. The lisp packaging already works (as you can see form
the dist directories that I should not have checked in). Most of the
rest can be stolen from cider.



Stephen Leake | 14 Aug 01:12 2015

Re: [jdee] Automated Build (#3)

Phil Lord <notifications <at>> writes:

> I think we just need to decide. I would argue that broad architectural
> decisions should be on the mailing list. Specific bug reports and
> discussion about them might as well be github.

Bug report discussions should be on the bug report, not on a general git
hub list.


-- Stephe

Stephen Leake | 14 Aug 01:08 2015

Re: [jdee] Automated Build (#3)

Phil Lord <notifications <at>> writes:

> Paul Landes <notifications <at>> writes:
>> I believe you submit .tar files.  The jar would go in the .tar file.
>> On Aug 12, 2015, at 3:13 PM, Przemysław Wojnowski <notifications <at>>
>> wrote:
>>> But what to do with Java code? Is it possible to upload a JAR to (m)ELPA?
> We probably also need to make a rough decision about github vs mailing
> list conversations!

A moot point to me; they all show up in the same Gnus group :).

There is a difference in searching for things later; you have to search
two databases.


-- Stephe

jdee-devel mailing list
jdee-devel <at>
Stephen Leake | 14 Aug 01:07 2015

Re: [jdee] Automated Build (#3)

Phil Lord <notifications <at>> writes:

> With Marmalade, this would be possible, I think, unless Nic has
> specially blocked it. With ELPA this might be possible, but ELPA
> requires copyright assignment, which is just not going to happen short
> term. 

The term "ELPA" means "Emacs Lisp Package Archive"; it does not refer to
any particular repository of packages. It means a repository that can be
accessed by the Emacs package API.

I believe you are actually refering to "Gnu ELPA" here; the ELPA
repository containing FSF packages, at

> JDEE currently has the nightmare of Emacs Lisp build with ant. Let's
> build emacs-lisp with cask, Java with maven. Any otherway lies, well,
> lies this:
>     <exec dir="${build.lisp.escaped.dir}"
> 	  executable="${build.bin.emacs}" failonerror="true">
>       <arg value="--no-site-file"/>
>       <arg value="--batch"/>
>       <arg value="--load"/>
>       <arg value="${build.lisp.dst.escaped.file}"/>
>     </exec>

I was tempted to complain about that as well :). My reaction was
"exactly how is this better than a Makefile line?".


-- Stephe

Przemysław Wojnowski | 12 Aug 22:09 2015

Purpose of jde-autoloads

Hello everybody,

I was thinking about purpose of autoloads and IIUC its sole purpose is to lazy 
load parts of JDEE. But what for? Maybe 10-15 years ago it was speeding up 
loading of JDEE, but now the difference is marginal. The only function I would 
see in autoloads would be something like this:
(defun jde-start ()
   "Start JDEE."
  (require 'jde))

Rationale: If someone would install JDEE (e.g. from elpa) it wouldn't slow down 
Emacs startup. But user could load it anytime using M-x jde-start when s/he 
would like to open a Java project.

What do you think about it?
I nobody mind or answer by the end of the week I'll reduce jde-autoload to the 
one method.


jdee-devel mailing list
jdee-devel <at>